【譯】Consul負載均衡策略

Consul是一個免費的開源工具, 它提供服務發現、健康檢查、負載均衡和全局分佈的鍵值存儲。此外, 它還提供了一組用於構建業務流程工做流和工具的基礎元素。在微服務體系結構中, 應用程序一般跨越多個IP地址運行, 並綁定到各類端口。服務發現有助於查找這些不一樣的服務, 而無論它們位於何處。

因爲同一個服務的多個實例一般同時運行在微服務體系結構中, 所以在實例健康變化時，實例數量變化時，以及集羣狀態變化時，咱們須要一種策略去平等地均衡全部到健康實例的流量。這就是負載均衡層的工做。本文討論了在微服務體系結構中與Consul進行負載均衡的幾種經常使用策略。

直接使用Consul

對Consul進行負載均衡的一種方法是使用Consul的內置負載均衡功能。Consul將健康檢查與服務發現結合在一塊兒。這意味着不健康的主機永遠不會經過查詢返回到服務發現層。在這種模式下, 每次應用程序和服務但願在數據中心查找其餘服務時，他們直接與Consul進行對話。

請考慮如下配置文件, 其中包括某個後端服務的IP地址:

services: 
  backend: 10.2.5.391
複製代碼

一般狀況下，對於IP地址進行硬編碼(尤爲是在微服務體系結構中)，被認爲是一種很差的作法。隨着應用程序在整個系統中運行, 將此配置文件保持爲最新, 尤爲是在計算機集羣上，變得很是困難。相反, 更好的方法是利用Consul的DNS發現層。

services: 
  backend: backend.service.consul
複製代碼

就像"www.hashicorp.com"是一個web地址, "backend.service.consul"也是。這裏，TLD 或域後綴（domain suffix）是可配置的, 但默認值爲.Consul。任何以該TLD結尾的請求都將被解析到Consul。這裏.service命名空間告訴Consul查找服務 (而不是機器的節點)，. backend是要查找的服務的名稱。對 "backend.service.consul"的請求被解析到一組IP地址, 就像"www.hashicorp.com"被解析爲一組IP地址同樣。然而, 對於Consul, 該解析發生在服務發現層，並集成了健康檢查機制。

每次應用程序或內核解析該DNS條目時, 它都會收到一個與集羣中的健康服務對應的 IP 地址列表的隨機循環（round-robin）響應。DNS接口基本上提供了零配置（zero-touch）服務發現，並能集成到任何應用程序中。

優勢：

• 不依賴外部工具或流程
• 沒有其餘服務用於監視或維護
• 默認狀況下高度可用
• 儘量接近實時
• DNS易於使用, 工做量極小
• 健康檢查是分佈式的, 集羣負載極小

缺點：

• 單點故障-即便Consul在默認狀況下是高度可用的, 但若是Consul不可用或沒法訪問, 此模式不提供故障轉移
• 要求在應用程序中直接使用HTTP API, 或進行 DNS 查詢, 假定端口或進行兩個 DNS 查詢以查找地址和端口
• 應用與Consul強耦合

Fabio

Fabio是一個開源工具, 它爲Consul管理的服務提供快速、現代、零配置的負載均衡HTTP(s)和TCP路由器。用戶在Consul註冊服務，並提供健康檢查，Fabio將自動把流量路由到他們。不須要額外配置。

用戶註冊一項服務, 採用以urlprefix-開頭的tag, 如:

urlprefix-/my-service
複製代碼

在本示例中, 當在/my-service上，對Fabio發出請求時, Fabio將自動將流量路由到集羣中的健康服務上。Fabio還支持更高級的路由配置。

優勢：

• 與Consul豐富集成
• 比DNS方法更多控制負載均衡
• 強大的社區支持和超過4000的GitHub star
• 支持TCP代理
• 訪問日誌記錄和一系列其餘使人稱讚的功能
• 集成HashiCorp Vault
• 用於路由可視化的可選Web UI
• 很是詳細的開源文檔

缺點：

• 須要額外的服務才能運行和監視
• 與Consul和Consul tag緊密耦合

Nginx/HAProxy with Consul Template

對Consul進行負載均衡的另外一種方法是使用第三方工具 （如Nginx 或 HAProxy） 來平衡流量，並使用開源工具 （如Consul Template） 來管理配置。在這種模式下, Consul Template動態管理 nginx.conf 或 haproxy.conf配置文件, 它定義負載均衡器和服務列表。此列表是模板化的, Consul Template做爲服務運行以保持模板爲最新。 Consul Template與Consul羣集有持續的鏈接, 當服務池發生更改時, Consul Template會寫入一個新的配置文件, 併發出信號讓Nginx或HAProxy進程從新加載其配置。這裏是一個示例的Nginx的Consul Template模板:

upstream myapp {
{{ range service "myapp" }}
  server {{ .Address }}:{{ .Port }}
{{ end }}
}
複製代碼

在此示例中, Consul Template將監視全部名爲 "myapp" 的服務。若是它們的任何狀態發生更改, Consul Template將產生一個新的配置文件, 並指示 Nginx 進程從新加載。上面的模板在nginx.conf中呈現爲這樣:

upstream myapp {
  server 10.2.5.60:13845
  server 10.6.96.234:45033
  server 10.10.20.123:18677
}
複製代碼

必須指出, 在這種模式下, Nginx 和 HAProxy 都不知道Consul的存在;它們只是讀取它們的配置, 就好像這些值是由操做員或配置管理工具硬編碼的同樣。

優勢：

• 處理在非默認端口上運行的應用程序, 而無需額外的API 請求
• Nginx 和 HAProxy 都是通過線上考驗的工具
• 團隊可能已經擁有這些工具的專業知識或現有的基礎設施
• 若是Consul離線, 仍然有最後已知良好的服務狀態的一個記錄
• Consul template也可與Vault集成, 若是配置文件具備像TLS 私鑰或共享密碼等機密數據時，這使得它一個理想的解決方案,。

缺點：

• 須要兩個額外的服務來管理和監視-Nginx/HAProxy 和Consul Template
• 因爲阻塞查詢, 低效模板可能給Consul羣集形成巨大壓力
• 對實踐 "一個容器一個服務" 範式的挑戰
• 一個 "飛行豬" 羣集 （服務在健康和不健康之間翻轉的羣集或具備大量連續快速流失的羣集） 可能致使 Nginx/HAproxy 配置不穩定

Nginx with Custom Module

最近, 我開始嘗試移除Consul Template, 但保持通過時間考驗的靈活性和熟悉度的Nginx。社會上有一些很是有趣和創新的作法, 即:

• Dynamic Nginx Upstreams for Consul via lua-nginx-module by Zachary Schneider
• Nginx upsync module
• Nginx Pro DNS resolution
• ngx_http_set_backend which inspired binding Nginx modules in C to Consul in Golang

最終, 這些方法要麼涉及太多的移動部件, 要麼包括Consul的基本服務發現以外的擴展功能。所以, 我寫的 ngx_http_consul_backend_module, 對於每一個導向nginx的請求，動態選擇upstream。

它看起來這樣:

http {
  server {
    listen       80;
    server_name  example.com;

    location /my-service {
      consul $backend service-name;
      proxy_pass http://$backend;
    }
  }
}
複製代碼

對於每一個請求, consul關鍵字告訴 Nginx 委託給自定義模塊並選擇一個隨機的健康後端服務, 而後將請求代理到該後端服務。確定有改進的地方, 可是這個概念驗證代表, 沒有中介工具，也 可能直接鏈接 Nginx 和Consul。

優勢：

• 處理非默認端口上運行的應用程序, 而無需額外的 API 請求
• 沒有外部工具-只是運行 Nginx 並直接指向Consul
• 使用正式Consul SDK客戶端庫提供的HTTP/二、stale queries等等

缺點：

• 須要從源代碼編譯 Nginx 以安裝自定義模塊
• 每一個到後端的請求，調用Consul（每一個請求須要消耗請求的RTT和Consul解析的RTT）
• 須要 Nginx 定製模塊的知識來完成任務
• 對於TLS私鑰或共享密碼，不能與Vault集成
• 模塊通過線上嚴苛測試 （還沒有）

HAProxy 1.8

HAProxy 1.8 （當前在撰寫本篇文章時發佈的候選版本） 在不使用第三方工具或模塊的狀況下, 經過 DNS 添加了服務發現的內置功能。HAProxy 已經內置 DNS 解決方案有一段時間了, 但 HAProxy 1.8 經過 SRV 記錄和支持 EDNS 爲端口帶來了解決方案, 使其與Consul完美配對。

優勢：

• 沒有外部工具-只是運行HAProxy，並直接指向Consul
• 優雅的處理從新加載, TTLs 等。
• 也支持 Kubernetes 和Docker Swarm服務發現

缺點：

• 須要 HAProxy
• 相較於Consul Template，對於失敗場景，更少的靈活性

結論

對於採用Consul的應用，有許多負載均衡的策略和技術。這篇文章詳細介紹了一些最多見的技術, 並但願激發靈感, 以新的，振奮人心的方式集成行業標準的負載均衡工具和Consul。不管您是直接使用Consul, 彌合與Consul模板的差距, 編譯本身的Nginx定製版本, 或嘗試HAProxy 1.8候選發佈版本, 咱們期待聽到您如何負載均衡您的微服務應用。

原文連接：www.hashicorp.com/blog/load-b…