Envoy熔斷限流實踐（一）基於Rainbond插件實現熔斷

• 2022 年 4 月 19 日
• 筆記

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 頁面可以設定並發條件，在這個實驗中，我為域名 //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 微服務框架中，通過插件實現的熔斷機制易於上手，且支援動態生效，對操作人員非常友好。

下一篇，我們將介紹全局限流的實現，敬請期待。