斷路器（CircuitBreaker）設計模式

時間 2019-11-12

標籤斷路器 circuitbreaker 設計模式简体版

原文原文鏈接

斷路器是電器時代的一個重要組成部分，後面老是有保險絲熔斷或跳閘的斷路器是安全的重要保障。html

微服務最近幾年成爲軟件架構的熱門話題，其益處多多。但須要知道的是，一旦開始將單塊系統進行分解，就上了分佈式系統的山頭。java

在雲或分佈式系統環境中，任何對一致性或可靠性的表述就是謊話。咱們必須假設微服務的行爲或其服務器位置會常常變更，其結果就是組件有時會提供低質量服務甚至可能完全沒法提供服務。這些微服務的故障若是沒有處理好，將致使整個系統的故障。git

微服務的故障多是瞬時故障：如慢的網絡鏈接、超時，資源過分使用而暫時不可用；也多是不容易預見的突發事件的狀況下須要更長時間來糾正的故障。github

分佈式服務的容錯是一個不得不考慮的問題，一般的作法有兩種：設計模式

重試機制：對於預期的短暫故障問題，經過重試模式是能夠解決的。
斷路器（CircuitBreaker）模式：將受保護的服務封裝在一個能夠監控故障的斷路器對象中，當故障達到必定門限，斷路器將跳閘（trip），所有後繼調用將不會發往受保護的服務而由斷路器對象之間返回錯誤。對於須要更長時間解決的故障問題，不斷重試就沒有太大意義了，可使用斷路器模式。

斷路器模式設計狀態機

注意事項

在決定如何實現這個模式時，您應考慮如下幾點：安全

異常處理。經過斷路器調用操做的應用程序必須可以處理在操做不可用時可能被拋出的異常，該類異常的處理方式都是應用程序特有的。例如，應用程序會暫時降級其功能，調用備選操做嘗試相同的任務或獲取相同的數據，或者將異常通知給用戶讓其稍後重試。
異常類型。一個請求可能因爲各類緣由失敗，其中有一些可能代表故障嚴重類型高於其餘故障。例如，一個請求可能因爲須要幾分鐘才能恢復的遠程服務崩潰而失敗，也可能因爲服務暫時超載形成的超時而失敗。斷路器有可能能夠檢查發生的異常類型，並根據這些異常本質調整策略。例如，促使切換到開狀態（跳閘）的服務超時異常個數要遠多於服務徹底不可用致使的故障個數。
日誌記錄。一個斷路器應記錄全部失敗的請求（若是可能的話記錄全部請求），以使管理員可以監視它封裝下受保護操做的運行狀態。
可恢復性。應該配置斷路器成與受保護操做最匹配的恢復模式。例如，若是斷路器設定出入開狀態的時間很長，即便底層操做故障已經解決它還會返回錯誤。若是開狀態到半開狀態切換過快，底層操做故障還沒解決它就會再次調用受保護操做。
測試失敗的操做。在開狀態下，斷路器可能不用計時器來肯定什麼時候切換到半開狀態，而是經過週期性地查驗遠程服務或資源以肯定它是否已經再次可用。這個檢查可能採用上次失敗的操做的形式，也可使用由遠程服務提供的專門用於測試服務健康情況的特殊操做。
手動復位。在一個系統中，若是一個失敗的操做的恢復時間差別很大，提供一個手動復位選項以使管理員可以強行關閉斷路器（和復位故障計數器）多是有益的。一樣，若是受保護操做暫時不可用，管理員能夠強制斷路器進入放狀態（並從新啓動超時定時器）。
併發。同一斷路器能夠被應用程序的大量併發實例訪問。斷路器實現不該阻塞併發請求或對每一請求增長額外開銷。
資源分化。當斷路器使用某類可能有多個底層獨立數據提供者的資源時須要特別當心。例如，一個數據存儲包含多個分區(shard)，部分分區出現暫時的問題，其餘分區可能徹底工做正常。若是該場景中的錯誤響應是合併響應，應用程序在部分故障分區極可能會阻塞整個請求時仍會試圖訪問某些工做正常的分區。
加速斷路。有時失敗響應對於斷路器實現來講包含足夠的信息用於斷定應當當即跳閘並保持最小時間量的跳閘狀態。例如，從過載共享資源的錯誤響應可能指示不推薦當即重試，且應用程序應當隔幾分鐘時間以後重試。
若是一個請求的服務對於特定Web服務器不可用，能夠返回HTTP協議定義的「HTTP 503 Service Unavailable」響應。該響應能夠包含額外的信息，例如預期延遲持續時間。
重試失敗請求。在開狀態下，斷路器能夠不是快速地簡單返回失敗，而是將每一個請求的詳細信息記錄日誌並在遠程資源或服務從新可用時安排重試。
對外部服務的不恰當超時。當對外部服務配置的超時很大時，斷路器可能沒法保護其故障操做，斷路器內的線程在指示操做失敗以前仍將阻塞到外部服務上，同時不少其餘應用實例仍會視圖經過斷路器調用服務。