Hystrix斷路器是如何工做的

前言

20181130，Hystrix已經再也不維護，這裏是學習記錄。12月1日才完成，沒有完成11月的諾言，捐款記錄以上動彈。 https://my.oschina.net/floor/tweet/19421296

Hystrix是什麼

Hystrix是一個java類庫，提供了服務容錯保護

遇到的問題

• 請求響應時間過長，形成資源不能被及時釋放。短時巨量請求形成資源耗盡，最終形成系統沒法響應。
• 系統中一個服務服務出現故障，影響其餘系統，形成系統級聯故障。
• 請求不受約束或者未進行批處理，系統會逐漸變慢失去響應 注 (資源多是，線程，網絡鏈接，內存等)

Hystrix解決方案

• 超時後取消與外部服務的鏈接;釋放系統資源，並使系統響應 線程和網絡使用受到線程池和信號量的限制。
• 當資源消耗到它們的約束時，以後的請求將失敗，而不是排隊
• 當發生故障時，能夠在適當的時候使用fallback;
• 可使用批處理請求;更有效地利用本地及外來服務資源

工做流程

官方工做流程圖一共9步以下，邏輯簡單。

1. 建立對象HystrixCommand和HystrixObservableCommand對象
2. 命令執行
3. 緩存中是否有結果
4. 斷路器是否打開
5. 信號量/線程池是否拒絕
6. HystrixObservableCommand.construct()或者HystrixCommand.run()
7. 計算斷路器的健康度
8. fallback處理
9. 返回成功的響應

斷路器原理

其原理說明以下：

1. 假設請求量達到必定的閾值(HystrixCommandProperties.circuitBreakerRequestVolumeThreshold())
2. 假設錯誤百分比超過閾值錯誤百分比 (HystrixCommandProperties.circuitBreakerErrorThresholdPercentage())
3. 知足其一，打開斷路器。
4. 當短路其打開，短路全部進過該短路器的請求。
5. 一段時間後(HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds())， 容許一個請求經過（此時短路器爲半開狀態）,若是該請求成功，短路其設置爲打開，不然將短路器設置爲關閉，從1開始再進行判斷。

依賴隔離

Hystrix使用「艙壁模式」。默認使用線程池。 爲每個依賴服務建立一個獨立的線程池，這樣若是一個依賴服務出現故障，只對該依賴服務的調用產生影響，不會拖累其餘服務。以下圖所示：

• 線程池隔離優勢

• 當服務從失效恢復正常後，線程池會被清理，立刻恢復健康的服務，而容器級別要滿不少。

• 失敗次數，延遲，超時，拒絕等指標，會快速反應出問題，結合Spring Cloud 能夠實現動態刷新。

• 線程池內置了併發實現，爲同步依賴服務構建異步訪問。

請求合併

解決，通訊佔用和鏈接消耗問題。在一個很短的時間窗口（默認10ms）內對多個請求進行合併以批處理的方式發送請求。 缺點：

• 形成單個響應的延遲，若是單個響應是5ms，默認時間窗口是10ms，這個請求的響應就變爲了15ms
• 用戶須要實現批量化服務和處理，增長了一些成本。 請求合併示意圖以下：