從ISTIO熔斷說起-輕舟網關熔斷

• 2020 年 3 月 31 日
• 筆記

最近大家經常被熔斷洗腦，股市的動蕩，讓熔斷再次出現在大家眼前。微服務中的熔斷即服務提供方在一定時間內，因為訪問壓力太大或依賴異常等原因，而出現異常返回或慢響應，熔斷即停止該服務的訪問，防止發生雪崩效應。輕舟網關基於Envoy實現，在社區熔斷思路上進行擴展。本文從Istio中熔斷說起，撥雲見日，漫談輕舟網關熔斷。

從熔斷說起

最近大家經常被熔斷洗腦，股市的動蕩，有幸兩周內見證了美股的四次熔斷。那究竟什麼是熔斷呢，在股票界熔斷實際上就是自動停盤，股市在跌到一定的程度後，暫停股票交易。對比股市，微服務中的熔斷即服務提供方在一定時間內，因為訪問壓力太大或依賴異常等原因，而出現異常返回或響應變慢等。熔斷即停止對該服務的調用，防止發生“雪崩效應”。從服務網關的角度看，熔斷即是在網關側阻止對服務提供方（upstream）的調用。本文從服務網關的角度窺探ISTIO中如何進行熔斷，保護後端業務。

Istio熔斷

Istio提供了豐富的熔斷手段，通過異常點檢測以及連接池配置起到保護後端的效果。異常點檢測動態確定上游集群中的健康狀態，如果出現連續訪問異常，則將異常後端從負載均衡實例中驅逐，在一段時間內不向其中打流量。過一段時間，加入到負載均衡集群中，繼續提供服務，若還是不正常，加大隔離時間。ISTIO提供了主動和被動健康檢查，異常檢測可以認為是被動的的健康檢查，數據面Envoy提供了主動健康檢查，在上游集群上配置健康檢查介面，主動和被動一起使用，作為一個整體的健康檢查方案，保障上游集群高可用。

異常點檢測在控制面配置在DestionRule CRD中，對應到數據面Envoy中體現在Cluster上的配置。主要的配置項包括：

1、consecuitiveErrors:連續錯誤次數。對於HTTP服務，502、503、504會被認為異常，TPC服務，連接超時即異常  2、intervals：驅逐的時間間隔，默認是10秒  3、baseEjectionTime:最小驅逐時間。驅逐時間會隨著錯誤次數增加而增加。即錯誤次數*最小驅逐時間  4、maxEjectionPercent:負載均衡池中可以被驅逐的實例的最大比例。以免某個介面瞬時不可用，導致太多實例被驅逐，進而導致服務整體全部不可用。  

同時Istio還提供了連接池配置，通過針對四層TCP以及七層HTTP連接的配置，進行客戶端訪問的限流。具體的配置主要包括：TCP連接池配置以及HTTP連接池配置。配置項主要包括：

HTTP連接池配置和TCP連接設置配合使用。對應到數據面Envoy上根據業務屬性進行劃分，一部分劃分為cluster.circuit_breakers，另一部分屬於cluster的配置。

Istio熔斷與Hystrix熔斷

Hystrix是微服務領域成熟的熔斷框架，是Netflix開源的熔斷框架。不過從18年底已經不在積極維護了。Hystrix對請求進行封裝，相關的邏輯在獨立的執行緒中運行，通過執行緒池達到資源隔離的效果。Hystrix提供了熔斷能力，具備自動檢測與恢復，斷路開關在Open,Half-Open以及Closed狀態間進行自動切換；同時提供了FallBack方法，便於用戶在後端服務熔斷情況下進行降級。

任何架構都有不同的使用場景，正如沒有完美的架構只有合適的架構一樣。靈活的配置以及可擴展性使得Hystrix融合在SpringCloud體系下，為SpringCloud微服務框架提供熔斷功能。但是與之帶來的是在使用Hystrix過程中，必須引入Hystrix依賴包。可以把Hystrix認為是一個白盒，開發人員可以針對業務進行相關的訂製，包括降級方法的編寫等。雖然，可以通過SDK模式從程式碼上解耦業務和相關熔斷治理，但是業務和SDK還是需要一起編譯。同時，Hystrix僅適用於java語言。

而Istio的熔斷對業務完全是透明的，無需對業務有任何依賴；在sidecar模式下，做到和業務集群無縫連接。不過Istio的熔斷更多是基於集群進行配置，熔斷力度相較於某些業務場景還有一定的薄弱。

熔斷示例
輕舟網關提供了豐富的熔斷配置頁面，通過輕舟網關的控制台，可以配置連接池配置。具體配置如下：TCP最大連接數配置為1，HTTP最大pending請求數配置為1。

通過控制台的配置，可以將具體的配置轉換成Istio中VirtualService的trafficPolicy的配置。具體如下

串列請求5次服務介面，查看數據面envoy stat的狀態，可以看到5次請求均返回200。

並發5次請求服務介面，客戶端收到三個503，2個200狀態返回，查看數據面envoy stat可以看到對應的2xx為2次，5xx為三次。5xx產生的原因為upstream_rq_pending_overflow。即因為max_pending數配置為1 ，請求被熔斷。

輕舟網關熔斷
輕舟網關基於Istio的熔斷實現了服務級別的熔斷限流。提供了服務維度的主動健康檢查、被動健康檢查以及連接池配置。同時，輕舟網關在服務的基礎上，擴展了路由級別的熔斷，結合hystrix的思路，使用滑動窗口來統計錯誤率和RT。實現了熔斷插件，作用於路由和virtualhost級別。具體的流程如下：

輕舟網關同時提供了豐富的限流策略起到對後端業務的保護，基於rate-limit-server實現。提供基於百分比請求的流控，基於條件的頻控，包括Header等維度的限流，具體的配置頁面如下：這是一個最簡單的配置，配置為請求Header中帶有IP:127.0.0.1的請求，每分鐘請求100次，超過100次觸發限流，返回429。

輕舟網關目前提供了豐富的網關10幾種插件，擴展envoy原生路由功能。包括快取，cors，jsonp，限流，動態降級，靜態降級，熔斷，鑒權等插件。有興趣的同學可以了解下輕舟網關。