前言

在前兩篇《Spring Cloud構建微服務架構：服務容錯保護（Hystrix服務降級）》和《Spring Cloud構建微服務架構：服務容錯保護（Hystrix依賴隔離）》中，我們對Hystrix提供的服務降級和依賴隔離有了基本的認識。下面我們將繼續說說Hystrix的另外一個重要元件：斷路器。

斷路器

斷路器模式源於Martin Fowler的Circuit Breaker一文。“斷路器”本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，“斷路器”能夠及時的切斷故障電路，防止發生過載、發熱、甚至起火等嚴重後果。

在分布式架構中，斷路器模式的作用也是類似的，當某個服務單元發生故障（類似用電器發生短路）之後，通過斷路器的故障監控（類似熔斷保險絲），直接切斷原來的主邏輯調用。但是，在Hystrix中的斷路器除了切斷主邏輯的功能之外，還有更復雜的邏輯，下面我們來看看它更為深層次的處理邏輯。

以在《Spring Cloud構建微服務架構：服務容錯保護（Hystrix服務降級）》一文中實現的服務降級例子為示例，我們來說說斷路器的工作原理。當我們把服務提供者eureka-client中加入了模擬的時間延遲之後，在服務消費端的服務降級邏輯因為hystrix命令調用依賴服務超時，觸發了降級邏輯，但是即使這樣，受限於Hystrix超時時間的問題，我們的調用依然很有可能產生堆積。

這個時候斷路器就會發揮作用，那麽斷路器是在什麽情況下開始起作用呢？這裏涉及到斷路器的三個重要參數：快照時間窗、請求總數下限、錯誤百分比下限。這個參數的作用分別是：

• 快照時間窗：斷路器確定是否打開需要統計一些請求和錯誤數據，而統計的時間範圍就是快照時間窗，默認為最近的10秒。
• 請求總數下限：在快照時間窗內，必須滿足請求總數下限才有資格根據熔斷。默認為20，意味著在10秒內，如果該hystrix命令的調用此時不足20次，即時所有的請求都超時或其他原因失敗，斷路器都不會打開。
• 錯誤百分比下限：當請求總數在快照時間窗內超過了下限，比如發生了30次調用，如果在這30次調用中，有16次發生了超時異常，也就是超過50%的錯誤百分比，在默認設定50%下限情況下，這時候就會將斷路器打開。

那麽當斷路器打開之後會發生什麽呢？我們先來說說斷路器未打開之前，對於之前那個示例的情況就是每個請求都會在當hystrix超時之後返回fallback，每個請求時間延遲就是近似hystrix的超時時間，如果設置為5秒，那麽每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發現請求總數超過20，並且錯誤百分比超過50%，這個時候熔斷器打開。打開之後，再有請求調用的時候，將不會調用主邏輯，而是直接調用降級邏輯，這個時候就不會等待5秒之後才返回fallback。通過斷路器，實現了自動地發現錯誤並將降級邏輯切換為主邏輯，減少響應延遲的效果。

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

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

更多Spring Cloud內容請持續關註我的博客更新或在《Spring Cloud微服務實戰》中獲取。

代碼示例

樣例工程將沿用之前在碼雲和GitHub上創建的SpringCloud-Learning項目，重新做了一下整理。通過不同目錄來區分Brixton和Dalston的示例。

• 碼雲：點擊查看
• GitHub：點擊查看
  

再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://www.cnblogs.com/captainbed

Spring Cloud構建微服務架構 服務容錯保護（Hystrix斷路器）【Dalston版】