1.斷路器
在微服務架構中，存在著多個微服務，彼此之間可能存在依賴關係，當某個單元出現故障或者網路不通時，就會因為依賴關係形成故障蔓延，最終導致整個系統的癱瘓，相對於傳統架構更加不穩定。為了解決這樣的問題，因此產生了斷路器模式。 斷路器本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，“斷路器”能夠及時切斷故障電源，防止發生過載、發熱甚至起火等嚴重後果。 在分散式架構中，斷路器模式的作用是類似的，當某個微服務發生故障時，通過斷路器的故障監控，向呼叫方返回一個錯誤響應，而不是長時間的等待，這樣就不會使得執行緒因呼叫故障服務被長時間佔用不釋放，避免了故障在分散式系統中的蔓延。 Netflix Hystrix 在Spring Cloud中使用了Hystrix來實現斷路器的功能。Hystrix是Netflix的分散式套件之一，該框架目標在於通過控制那些訪問遠端系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備擁有回退機制和斷路器功能的執行緒和訊號隔離，請求快取和請求打包，以及監控和配置等功能。 在前文中，已經建立過服務註冊中心，兩個服務提供者，兩個服務消費者。
斷路器工作原理
服務端的服務降級邏輯會因為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的斷路器實現了對依賴資源故障的處理，對降級策略的自動切換以及對主邏輯的自動恢復。這使得我們的微服務在依賴外部服務或資源的時候得到了非常好的保護，同時對於一些具備降級邏輯的業務需求可以實現自動化的切換和恢復，相比於設定開關由監控和運維來進行切換的傳統實現方式顯得更為智慧和高效。