### Hystrix熔斷原理 服務容錯組件，實現了斷路器模式，為依賴服務的出錯和延遲提供了容錯能力； Netflix的開源組件Hystrix的流程：  圖中流程的說明: 1. 將遠程服務調用邏輯封裝進一個HystrixCommand。 2. 對于每次服務調用可以使用同步或異步機制，對應執行execute()或queue()。 3. 判斷熔斷器(circuit-breaker)是否打開或者半打開狀態，如果打開跳到步驟8，進行回退策略，如果關閉進入步驟4。 4. 判斷線程池/隊列/信號量（使用了艙壁隔離模式）是否跑滿，如果跑滿進入回退步驟8，否則繼續后續步驟5。 5. run方法中執行了實際的服務調用。 a. 服務調用發生超時時，進入步驟8。 6. 判斷run方法中的代碼是否執行成功。 a. 執行成功返回結果。 b. 執行中出現錯誤則進入步驟8。 7. 所有的運行狀態(成功，失敗，拒絕，超時)上報給熔斷器，用于統計從而影響熔斷器狀態。 8. 進入getFallback()回退邏輯。 a. 沒有實現getFallback()回退邏輯的調用將直接拋出異常。 b. 回退邏輯調用成功直接返回。 c. 回退邏輯調用失敗拋出異常。 9. 返回執行成功結果。 注意：熔斷是否開啟熔斷器主要由依賴調用的錯誤比率決定的，依賴調用的錯誤比率=請求失敗數/請求總數。Hystrix中斷路器打開的默認請求錯誤比率為50%（這里暫時稱為請求錯誤率），還有一個參數，用于設置在一個滾動窗口中，打開斷路器的最少請求數（這里暫時稱為滾動窗口最小請求數），這里舉個具體的例子：如果滾動窗口最小請求數為默認20，在一個窗口內（默認10秒，統計滾動窗口的時間可以設置），收到19個請求，即使這19個請求都失敗了，此時請求錯誤率高達95%，但是斷路器也不會打開。對于被熔斷的請求，并不是永久被切斷，而是被暫停一段時間（默認是5000ms）之后，允許部分請求通過，若請求都是健康的（ResponseTime<250ms）則對請求健康恢復（取消熔斷），如果不是健康的，則繼續熔斷。（這里很容易出現一種錯覺：多個請求失敗但是沒有觸發熔斷。這是因為在一個滾動窗口內的失敗請求數沒有達到打開斷路器的最少請求數）