從ISTIO熔斷提及-輕舟網關熔斷

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

從熔斷提及

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

Istio熔斷

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

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

一、consecuitiveErrors:連續錯誤次數。對於HTTP服務，50二、50三、504會被認爲異常，TPC服務，鏈接超時即異常

二、intervals：驅逐的時間間隔，默認是10秒

三、baseEjectionTime:最小驅逐時間。驅逐時間會隨着錯誤次數增長而增長。即錯誤次數\*最小驅逐時間

四、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。

網關熔斷配圖005.png

經過控制檯的配置，能夠將具體的配置轉換成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，限流，動態降級，靜態降級，熔斷，鑑權等插件。有興趣的同窗能夠了解下輕舟網關。