最近大家經常被熔斷洗腦，股市的動蕩，讓熔斷再次出現在大家眼前。微服務中的熔斷即服務提供方在一定時間内，因為通路壓力太大或依賴異常等原因，而出現異常傳回或慢響應，熔斷即停止該服務的通路，防止發生雪崩效應。輕舟網關基于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配置 | Envoy配置 | 含義 | 備注 |
|---|---|---|---|
| maxConnection | cluster.circuit_breakers.max_connections | Envoy為上遊叢集建立的最大連接配接數 | |
| http1MaxPendingRequests | cluster.circuit_breakers.max_pending_requests | 最大等待HTTP請求數，預設1024 | 如果超過，cluster的upstream_rq_pending_overflow計數器增加 |
| http2MaxRequests | cluster.circuit_breaker.maxRequests | HTTP2最大連接配接數 | 僅适用HTTP2, HTTP1由maxConnection控制。如果超出，cluster的upstream_rq_pending_overflow計數器增加，可以由stat檢視 |
| maxRetries | cluster.circuit_breaker.max_retries | 最大重試次數 | 在指定時間内，叢集所有主機能夠執行的最大重試次水。如果超出，cluster的upstream_rq_retry_overflow計數器增加 |
| connectionTimeOut | cluster.connection_timeout_ms | cluster.connection_timeout_ms | |
| maxRequestsPerConnection | cluster.max_request_per_connection | 每個連接配接最大請求數 |
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，限流，動态降級，靜态降級，熔斷，鑒權等插件。有興趣的同學可以了解下輕舟網關。