Consul是一個(gè)免費(fèi)的開源工具，它提供了服務(wù)發(fā)現(xiàn)、健康檢查、負(fù)載均衡和全局分布式的鍵值存儲(chǔ)。此外，它還提供了一組用于構(gòu)建編排工作流和工具的原型。在微服務(wù)體系架構(gòu)中，應(yīng)用程序通常運(yùn)行在許多IP地址上，并綁定到各種端口。服務(wù)發(fā)現(xiàn)有助于發(fā)現(xiàn)這些不同的服務(wù)，而不管它們位于何處。

由于同一服務(wù)的多個(gè)實(shí)例常常在微服務(wù)體系架構(gòu)中同時(shí)運(yùn)行，因此我們需要一種策略，以便在處理健康狀態(tài)的更改、實(shí)例數(shù)量的更改和集群狀態(tài)的更改時(shí)，均衡地平衡服務(wù)的所有健康實(shí)例的流量。這是負(fù)載均衡層的工作。本文討論了在微服務(wù)體系架構(gòu)中與Consul負(fù)載均衡的一些常見策略。

Consul Directly

與Consul負(fù)載均衡的一種方法是使用Consul的內(nèi)置負(fù)載均衡功能。Consul集成健康檢查與服務(wù)發(fā)現(xiàn)。這意味著不健康的主機(jī)永遠(yuǎn)不會(huì)從查詢返回到服務(wù)發(fā)現(xiàn)層。在這種模式下，每當(dāng)應(yīng)用程序和服務(wù)希望在數(shù)據(jù)中心中找到其他服務(wù)時(shí)，它們都直接與Consul進(jìn)行通信。

請(qǐng)考慮以下配置文件，其中包含后端服務(wù)的IP地址:

services:backend: 10.2.5.391

通常認(rèn)為硬編碼IP地址是一種不好的做法，尤其是在微服務(wù)體系結(jié)構(gòu)中。隨著應(yīng)用程序在整個(gè)系統(tǒng)中移動(dòng)，使這個(gè)配置文件保持最新變得很有挑戰(zhàn)性，特別是在計(jì)算機(jī)集群中。相反，更好的方法是利用Consul的DNS發(fā)現(xiàn)層。

services:backend: backend.service.consul

正如“www.hashicorp.com”是一個(gè)web地址，“backend.service.consul”也是一樣。TLD或域后綴是可配置的，但默認(rèn)值是.consul。以TLD結(jié)尾的任何請(qǐng)求都將被解析到Consul。.service命名空間告訴Consul查找服務(wù)(與機(jī)器節(jié)點(diǎn)相對(duì)照)。backend 是要查找的服務(wù)的名稱。請(qǐng)求“backend.service.consul"解析到一組IP地址，就像請(qǐng)求“www.hashicorp.com”解析到一組IP地址一樣。然而，對(duì)于Consul，解析發(fā)生在服務(wù)發(fā)現(xiàn)層，并集成到健康檢查機(jī)制中。

每當(dāng)應(yīng)用程序或內(nèi)核解析這個(gè)DNS條目時(shí)，它將收到一組IP地址的隨機(jī)round-robin響應(yīng)，這些地址對(duì)應(yīng)于集群中的健康服務(wù)。DNS接口基本上提供了與任何應(yīng)用程序的零接觸服務(wù)發(fā)現(xiàn)集成。

優(yōu)點(diǎn)

• 不依賴外部工具或進(jìn)程
• 不需要監(jiān)視或維護(hù)其他服務(wù)
• 默認(rèn)高度可用
• 盡可能接近實(shí)時(shí)
• DNS很容易使用，工作量很小
• 健康檢查是分布式的，集群負(fù)載最小

缺點(diǎn)

• 單點(diǎn)故障——即使Consul在默認(rèn)情況下高度可用，如果Consul不可用或不可訪問，這種模式不會(huì)提供故障轉(zhuǎn)移
• 要求直接在應(yīng)用程序中使用HTTP API或進(jìn)行DNS查詢，并假設(shè)端口或進(jìn)行兩個(gè)DNS查詢以查找地址和端口
• 應(yīng)用程序和Consul之間的緊耦合

Fabio

Fabio是一個(gè)開源工具，它為Consul管理的服務(wù)提供了快速、現(xiàn)代、零配置負(fù)載均衡HTTP(S)和TCP路由器。用戶注冊(cè)服務(wù)和健康檢查到Consul，fabio將自動(dòng)路由流量到他們，不需要額外的配置。

用戶注冊(cè)一個(gè)以urlprefix-開頭的標(biāo)簽的服務(wù)，例如:

urlprefix-/my-service

在本例中，當(dāng)對(duì)fabio 發(fā)出/my-service請(qǐng)求時(shí)，fabio將自動(dòng)將流量路由到集群中的健康服務(wù)。Fabio還支持更高級(jí)的路由配置。

優(yōu)點(diǎn)

• 與Consul的豐富整合
• 比DNS方法更能控制負(fù)載均衡
• 在GitHub上超過4000星的支持和采用
• 支持TCP代理
• 訪問日志和許多其他很棒的特性
• 集成HashiCorp Vault
• 用于路由可視化的可選Web UI
• 非常詳細(xì)的開源文檔

缺點(diǎn)

• 需要額外的服務(wù)來運(yùn)行和監(jiān)視
• 與Consul和Consul標(biāo)簽緊耦合

Nginx/HAProxy與Consul模板

Consul負(fù)載均衡的另一種方法是使用第三方工具(如Nginx或HAProxy)來平衡流量，以及使用開源工具(如 Consul Template)來管理配置。在這種模式下， Consul Template動(dòng)態(tài)地管理nginx.conf或haproxy.conf配置文件，它定義負(fù)載均衡器和服務(wù)器列表。這個(gè)列表是模板化的，Consul Template作為一個(gè)服務(wù)運(yùn)行，以保持模板是最新的。Consul Template與Consul集群有持續(xù)的連接，當(dāng)發(fā)生對(duì)服務(wù)池的更改時(shí)， Consul Template寫入一個(gè)新的配置文件，并向Nginx或HAProxy進(jìn)程發(fā)送信號(hào)，以重新加載其配置。下面是一個(gè)示例Nginx Consul Template模板:

upstream myapp { {{ range service "myapp" }}server {{ .Address }}:{{ .Port }} {{ end }} }

在本例中，Consul Template將監(jiān)視所有名為“myapp”的服務(wù)。如果他們的狀態(tài)發(fā)生了更改，Consul Template將渲染一個(gè)新的配置文件，并向Nginx進(jìn)程發(fā)出重新加載的信號(hào)。上面的模板將渲染nginx.conf成下面這樣:

upstream myapp {server 10.2.5.60:13845server 10.6.96.234:45033server 10.10.20.123:18677 }

需要注意的是，在這種模式下，無論是Nginx還是HAProxy都不知道Consul的存在;它們只是讀取配置，就好像值是由操作符或配置管理工具硬編碼的一樣。

優(yōu)點(diǎn)

• 處理在非默認(rèn)端口上運(yùn)行的應(yīng)用程序，而不需要額外的API請(qǐng)求
• Nginx和HAProxy都是經(jīng)過實(shí)戰(zhàn)檢驗(yàn)的工具
• 組織可能已經(jīng)擁有使用這些工具的專業(yè)知識(shí)或現(xiàn)有基礎(chǔ)結(jié)構(gòu)
• 如果Consul離線，仍然有記錄的最后已知的良好狀態(tài)的服務(wù)
• Consul Template還集成了Vault，如果配置文件具有TLS私鑰或共享密碼等機(jī)密數(shù)據(jù)，那么這是一個(gè)理想的解決方案

缺點(diǎn)

• 需要兩個(gè)額外的服務(wù)來管理和監(jiān)控- Nginx/HAProxy和Consul Template
• 由于阻塞查詢，低效的模板會(huì)給Consul集群帶來巨大的壓力
• 實(shí)踐“每個(gè)容器一個(gè)服務(wù)”范式具有挑戰(zhàn)性
• 一個(gè)“flappy”集群(一個(gè)服務(wù)在健康和不健康之間切換的集群，或者一個(gè)持續(xù)快速變化的集群)可能會(huì)導(dǎo)致Nginx/HAproxy配置的不穩(wěn)定性

Nginx自定義模塊

最近，我制定了一個(gè)目標(biāo)，試圖從等式中刪除 Consul Template，但要保持Nginx經(jīng)過時(shí)間考驗(yàn)的靈活性和熟悉性。社區(qū)內(nèi)有一些非常有趣和創(chuàng)新的方法，即:

• Dynamic Nginx Upstreams for Consul via lua-nginx-module by Zachary Schneider
• Nginx upsync module
• Nginx Pro DNS resolution
• ngx_http_set_backend?啟發(fā)了將C中的Nginx模塊綁定到Golang中的Consul

最終，這些方法要么涉及太多的活動(dòng)部件，要么包含超出Consul公司基本服務(wù)發(fā)現(xiàn)范圍的特性。因此，我編寫了ngx_http_consul_backend_module模塊，該模塊對(duì)每個(gè)nginx請(qǐng)求動(dòng)態(tài)地選擇上游。

就像這樣:

http {server {listen 80;server_name example.com;location /my-service {consul $backend service-name;proxy_pass http://$backend;}} }

對(duì)于每個(gè)請(qǐng)求，Consul密鑰告訴Nginx將委托給自定義模塊并選擇一個(gè)隨機(jī)的健康后端，然后將請(qǐng)求代理給該后端。確實(shí)有需要改進(jìn)的地方，但是這種概念驗(yàn)證表明，在沒有中介工具的情況下，Nginx和Consul可以直接連接在一起。

優(yōu)點(diǎn)

• 處理在非默認(rèn)端口上運(yùn)行的應(yīng)用程序，而不需要額外的API請(qǐng)求
• 沒有外部工具-只是運(yùn)行Nginx并直接指向Consul
• 使用官方Consul SDK客戶端庫提供HTTP/2、陳舊的查詢以及更多開箱即用的東西

缺點(diǎn)

• 需要從源代碼編譯Nginx以安裝自定義模塊
• 每個(gè)請(qǐng)求調(diào)用Consul到后端(每個(gè)請(qǐng)求吃掉請(qǐng)求的RTT和Consul解決方案的RTT)
• 需要了解Nginx定制模塊的知識(shí)
• 不與Vault集成TLS私鑰或共享密碼
• 模塊還沒有經(jīng)過實(shí)戰(zhàn)測(cè)試

HAProxy 1.8

HAProxy 1.8(目前是本文撰寫時(shí)的發(fā)布候選版本)添加了內(nèi)置功能，無需使用第三方工具或模塊，即可通過DNS找到服務(wù)。HAProxy已經(jīng)有內(nèi)置DNS解析器一段時(shí)間了，但是HAProxy 1.8通過SRV記錄和EDNS的支持為端口帶來了解析，使其與Consul完美地匹配。

優(yōu)點(diǎn)

• 沒有外部工具-只是運(yùn)行HAProxy和直接指向Consul
• 優(yōu)雅的處理重載，TTLs等
• 支持Kubernetes和Docker群集服務(wù)發(fā)現(xiàn)

缺點(diǎn)

• 需要HAProxy
• 在失敗場(chǎng)景上的靈活性不如Consul Template

結(jié)論

Consul負(fù)載均衡的微服務(wù)應(yīng)用有很多策略和技術(shù)。這篇文章詳細(xì)介紹了一些最常見的技術(shù)，并希望能夠激發(fā)靈感，找到新的和令人興奮的方法來集成行業(yè)標(biāo)準(zhǔn)負(fù)載平衡工具和Consul。無論您是直接使用Consul，橋接與Consul Template的差距，編譯自定義的Nginx自己，或嘗試HAProxy 1.8發(fā)布候選，我們期待聽到您如何平衡您的微服務(wù)負(fù)載。

總結(jié)

以上是生活随笔為你收集整理的Consul负载均衡策略的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。