Spring Cloud構建微服務架構-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的斷路器實現了對依賴資源故障的端口、對降級策略的自動切換以及對主邏輯的自動恢復機制。這使得咱們的微服務在依賴外部服務或資源的時候獲得了很是好的保護，同時對於一些具有降級邏輯的業務需求能夠實現自動化的切換與恢復，相比於設置開關由監控和運維來進行切換的傳統實現方式顯得更爲智能和高效。

 

從如今開始，我這邊會將近期研發的springcloud微服務雲架構的搭建過程和精髓記錄下來，幫助更多有興趣研發spring cloud框架的朋友，但願能夠幫助更多的好學者。你們來一塊兒探討spring cloud架構的搭建過程及如何運用於企業項目。源碼來源