Envoy 可以作為 Sevice Mesh 微服務框架中的代理實現方案,Rainbond 內建的微服務框架同樣基於 Envoy 實現。本文所描述的熔斷實踐基於 Rainbond 特有的外掛機制實現。
Envoy 熔斷機制介紹
熔斷是分散式系統的重要組成部分。快速失敗並儘快給下游施加壓力,可以防止整個微服務系統進入糟糕的級聯雪崩狀態。這是Envoy 網格的主要優點之一,Envoy 在網路級別實現強制斷路限制,而不必獨立配置和編寫每個應用程式。Envoy 支援各種型別的完全分佈(不協調)的熔斷:
-
叢集最大連線數(MaxConnections):Envoy將為上游群集中的所有主機建立的最大連線數。實際上,這僅適用於HTTP/1.1群集,因為HTTP/2使用到每個主機的單個連線。
-
叢集最大掛起請求數(MaxPendingRequests):在等待就緒連線池連線時將排隊的最大請求數。實際上,這僅適用於HTTP/1.1群集,因為HTTP/2連線池不會排隊請求。HTTP/2請求立即複用。如果這個斷路器溢位,叢集的
upstream_rq_pending_overflow
計數器將增加。 -
叢集最大請求數(MaxRequests):在任何給定時間,群集中所有主機可以處理的最大請求數。實際上,這適用於HTTP/2群集,因為HTTP/1.1群集由最大連線斷路器控制。如果這個斷路器溢位,叢集的
upstream_rq_pending_overflow
計數器將增加。 -
叢集最大活動重試次數(MaxRetries):在任何給定時間,叢集中所有主機可以執行的最大重試次數。一般來說,我們建議積極進行斷路重試,以便允許零星故障重試,但整體重試量不能爆炸並導致大規模級聯故障。如果這個斷路器溢位,叢集的
upstream_rq_retry_overflow
計數器將遞增。
每個熔斷閾值可以按照每個上游叢集和每個優先順序進行配置和跟蹤。這允許分散式系統的不同元件被獨立地調整並且具有不同的熔斷配置。
基於外掛機制實現的熔斷
Rainbond 雲原生應用管理平臺通過自有的外掛機制實現指定的微服務面向下游元件的熔斷。
預設安裝的 Rainbond 中已經整合了 出口網路治理外掛
以及 綜合網路治理外掛
,二者都基於 Envoy
實現,可以對安裝了外掛的微服務的網路出口方向進行較為全面的網路治理。其中就包括對熔斷機制的實現。
為了更好的描述這個過程,特意準備了一個示例。
基於 Locust 實現的壓力生成器作為客戶端,安裝 綜合網路治理外掛
,Java-maven 元件作為服務端。壓力生成器可以根據圖形化介面設定併發使用者數量,對 Java-maven 的服務地址進行壓力測試,在此期間,我們可以收集到觸發熔斷機制時的各種現象。
綜合網路治理外掛
的安裝很簡單,在請求發起的客戶端(示例中的壓力生成器)服務元件的外掛頁面中點選安裝指定的外掛即可。
設定熔斷閾值
Java-maven 元件基於 Http/1.1 版本協議實現,根據首節對 Envoy 熔斷機制的解釋,我們可以通過限制 叢集最大連線數(MaxConnections) 和 叢集最大掛起請求數(MaxPendingRequests) 來設定熔斷條件。
點選壓力生成器元件的外掛,檢視 出口網路治理外掛
配置,就可以進入其配置頁面。
綜合網路治理外掛
分為入站網路治理配置和出站網路治理配置兩個配置區域,熔斷閾值的設定位於出站網路治理配置區域。
為了突出實驗的效果,我將 MaxConnections
和 MaxPendingRequests
兩項均設定為較小的值。
圖中的配置,意味著叢集最大連線數為 6 ,最大等待的請求數為 1 (這二者的預設值均為 1024)。這一配置,相當於為 Envoy 生成了以下配置:
"circuit_breakers": {
"default": {
"max_connections": 6,
"max_pending_requests": 1
}
}
為下游應用 Java-maven 的 5000 埠設定的 Domains
也很重要,壓力生成器可以通過訪問 java-maven
這一域名,將壓力施加於 Java-maven 的 5000 埠。
觸發熔斷
基於 Locust 的 Web 頁面可以設定併發條件,在這個實驗中,我為域名 http://java-maven
設定了 97 個使用者的併發請求。 Locust 的頁面中會體現出發起請求的總數,以及處於失敗狀態的請求數。
所有的錯誤請求,都獲得了由熔斷機制返回的 503 狀態碼。
為了確認壓力生成器與 Java-maven 元件間的 Tcp 連線數量的確得到了限制,可以進入 Java
-maven 的 Web終端用命令檢視。
命令中的 172.20.1.74
是壓力生成器元件的 Pod IP 地址。
這裡需要注意,不要去壓力生成器中查詢 Tcp 連線的生成數量,這個數量會多於 6 個,實際上應該是 97,因為發起請求的 Locust 程式會根據併發使用者數量來生成 Tcp 連線,這個過程不受熔斷機制限制,然而請求經過 Envoy 時,向 Java-maven 這一服務端,最終只會成功建立並保持 6 個連線。
提升熔斷閾值
接下來,通過調整 綜合網路治理外掛
的配置,調整熔斷的閾值,將 MaxConnections
提升至 66。
點選更新配置後,改動將會直接生效,而不需要重啟元件。
在壓力生成器中適當提升併發使用者數到 250,重新開始發起壓力測試,可以發現,不再生成錯誤請求。
重新在 Java-maven 的環境中查詢建立的 tcp 連線數量,發現已經不再是 6 ,而是有所上升,但並未到達閾值66。
持續提升併發使用者數量,則可以再次觸發熔斷。
總結
熔斷是微服務網路治理體系中非常重要的一環。Rainbond 結合 Envoy 實現的 ServiceMesh 微服務框架中,通過外掛實現的熔斷機制易於上手,且支援動態生效,對操作人員非常友好。
下一篇,我們將介紹全侷限流的實現,敬請期待。