在微服務架構中，存在著多個微服務，彼此之間可能存在依賴關系，當某個單元出現故障或者網絡不通時，就會因為依賴關系形成故障蔓延，最終導致整個系統的癱瘓，相對於傳統架構更加不穩定。為了解決這樣的問題，因此產生了斷路器模式。
斷路器本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，“斷路器”能夠及時切斷故障電源，防止發生過載、發熱甚至起火等嚴重後果。
在分布式架構中，斷路器模式的作用是類似的，當某個微服務發生故障時，通過斷路器的故障監控，向調用方返回一個錯誤響應，而不是長時間的等待，這樣就不會使得線程因調用故障服務被長時間占用不釋放，避免了故障在分布式系統中的蔓延。

斷路器工作原理

服務端的服務降級邏輯會因為hystrix命令調用依賴服務超時而觸發，也就是說調用服務超時會進入斷路回調邏輯處理。但是即使這樣，受限於Hystrix超時時間的問題，調用依然會有可能產生堆積。

這個時候斷路器就會發揮作用。這裏涉及到斷路器的三個重要參數：
快照時間窗
斷路器確定是否打開需要統計一些請求和錯誤數據，而統計的時間範圍就是快照時間窗，默認為最近的10秒。

請求總數下限
在快照時間窗內，必須滿足請求總數下限才有資格熔斷。默認為20，意味著在10秒內，如果該hystrix命令的調用次數不足20，即使所有的請求都超時或者其他原因失敗，斷路器都不會打開。

歡迎大家一起學習研究相關技術願意了解源碼的朋友直接求求交流分享技術：2147775633

錯誤百分比下限
當請求總數在快照時間窗口內超過了下限，比如發生了30次調用，如果在這30次調用中有16次發生了超時異常，也就是超過了50%錯誤百分比，在默認設定50%下限情況下，這時候就會將斷路器打開。

因此，斷路器打開的條件是：在時間快照窗口期（默認為10s）內，至少發生20次服務調用，並且服務調用錯誤率超過50%。

不滿足條件時斷路器並不會打開，服務調用錯誤只會觸發服務降級，也就是調用fallback函數，每個請求時間延遲就是近似hystrix的超時時間。如果將超時時間設置為5秒，那麽每個請求都要延遲5每秒才會返回。當斷路器在10秒內發現請求總數超過20並且錯誤率超過50%，這時候斷路器會打開。之後再有請求調用的時候，將不會調用主邏輯，而是直接調用降級邏輯，這個時候就不會等待5秒之後才會返回fallback。通過斷路器實現自動發現錯誤並將降級邏輯切換為主邏輯，減少響應延遲的效果。

在斷路器打開之後，處理邏輯並沒有結束，此時降級邏輯已經被切換為主邏輯了，那麽原來的主邏輯要如何恢復呢？實際上hystrix也實現了這一點：當斷路器打開，對主邏輯進行熔斷之後，hystrix會啟動一個休眠時間窗，在這個時間窗內，降級邏輯是臨時的主邏輯，當休眠時間窗到期，斷路器將進入半開狀態，釋放一次請求到原來的主邏輯，如果此次請求正常返回，那麽斷路器將進行閉合，主邏輯恢復，如果這次請求依然有問題，斷路器繼續進入打開狀態，休眠時間窗重新計時。

換句話說，斷路器每隔一段時間進行一次重試，看看原來的主邏輯是否可用，可用就關閉，不可用就繼續打開。

通過上面的機制，hystrix的斷路器實現了對依賴資源故障的處理，對降級策略的自動切換以及對主邏輯的自動恢復。這使得我們的微服務在依賴外部服務或資源的時候得到了非常好的保護，同時對於一些具備降級邏輯的業務需求可以實現自動化的切換和恢復，相比於設置開關由監控和運維來進行切換的傳統實現方式顯得更為智能和高效。

SpringCloud基礎之斷路器