斷路器模式

處理在連線到遠端服務或資源時，可能需要一段時間才能復原的錯誤。 此模式可以改善應用程式的穩定性和復原能力。

內容和問題

在分散式環境中，遠端資源和服務的呼叫可能會因為暫時性錯誤而失敗，例如網路連線緩慢、逾時，或資源被過度認可或暫時無法使用。 這些錯誤通常會在短時間內自行更正，而強固的雲端應用程式應該使用重試模式等策略來處理這些錯誤。

不過，也可能有錯誤是由於非預期的事件，而且可能需要更長的時間才能修正。 這些錯誤的嚴重性可能從失去部分連線到服務完全失敗。 在這些情況下，應用程式可能會毫無意義地持續重試不太可能成功的作業，而應用程式應該快速接受作業失敗並據以處理此失敗。

此外，如果服務非常忙碌，系統某個部分中的失敗可能會導致串聯失敗。 例如，叫用服務的作業可以設定為實作逾時，並在服務在此期間內無法回應時回復失敗訊息。 不過，此策略可能會導致對相同作業的許多並行要求遭到封鎖，直到逾時期間到期為止。 這些封鎖的要求可能會保存重要的系統資源，例如記憶體、線程、資料庫連線等等。 因此，這些資源可能會耗盡，導致需要使用相同的資源之系統其他可能不相關的部分失敗。 在這些情況下，最好讓作業立即失敗，而且只有在服務可能成功時才會嘗試叫用服務。 設定較短的逾時可能有助於解決此問題，但逾時應該不會太短，以至於作業大部分時間都失敗，即使對服務的要求最終會成功也一樣。

解決方案

斷路器模式可以防止應用程式重複嘗試執行可能失敗的作業。 允許它繼續，而不等待錯誤被修正或浪費 CPU 週期，同時判斷該錯誤是持久的。 斷路器模式也可讓應用程式偵測是否已解決錯誤。 如果問題似乎已修正，應用程式可以嘗試叫用作業。

斷路器模式的目的與重試模式不同。 重試模式可讓應用程式在預期作業成功時重試作業。 斷路器模式可防止應用程式執行可能失敗的作業。 應用程式可以結合這兩種模式，使用重試模式透過斷路器來叫用作業。 不過，重試邏輯應該會受到斷路器所傳回之任何例外狀況的影響，而且如果斷路器指出錯誤不是暫時的，就應該放棄重試嘗試。

斷路器可作為可能失敗之作業的 Proxy。 Proxy 應該監視最近發生的失敗數目，並使用這項資訊來決定是否允許作業繼續，或立即傳回例外狀況。

Proxy 可以實作為狀態機器，並具有下列模擬斷路器功能的狀態機器：

• 已關閉：從應用程式的要求會路由傳送至作業。 Proxy 會維護最近失敗次數的計數，如果對作業的呼叫失敗失敗，Proxy 就會遞增此計數。 如果最近失敗的數目超過指定時段內的指定臨界值，Proxy 就會進入 Open 狀態。 此時，Proxy 會啟動逾時定時器，而且當此定時器過期時，Proxy 會進入 半開啟 狀態。

  逾時定時器的目的是讓系統有時間修正導致失敗的問題，再讓應用程式嘗試再次執行作業。

• 開啟：來自應用程式的要求會立即失敗，並傳回例外狀況給應用程式。

• 半開啟：允許來自應用程式的有限數目要求通過並叫用作業。 如果這些要求成功，則假設先前造成失敗的錯誤已修正，而斷路器會切換至 [已關閉 ] 狀態（失敗計數器已重設）。 如果有任何要求失敗，斷路器會假設錯誤仍然存在，因此它會還原為 Open 狀態，並重新啟動逾時定時器，讓系統有進一步的時間從失敗中復原。

  半開啟狀態有助於防止復原服務突然被要求淹沒。 當服務復原時，在復原完成之前，它可能會支援有限的要求量，但復原正在進行時，大量工作可能會導致服務逾時或再次失敗。

在此圖中，關閉狀態所使用的失敗計數器是以時間為基礎。 它會定期自動重設。 此設計有助於防止斷路器在偶爾發生失敗時進入 Open 狀態。 只有在指定的間隔期間發生指定的失敗數目時，才會達到將斷路器 進入 Open 狀態的失敗臨界值。 Half-Open 狀態所使用的計數器會記錄成功叫用作業的嘗試次數。 斷路器會在指定數目的連續作業調用成功之後，還原為 已關閉 狀態。 如果有任何調用失敗，斷路器會立即進入 Open 狀態，而成功計數器會在下次進入 半開啟 狀態時重設。

系統在外部復原的方式，可能是藉由還原或重新啟動失敗的元件或修復網路連線來處理。

斷路器模式在系統從失敗中復原時提供穩定性，並將效能的影響降到最低。 它可藉由快速拒絕可能失敗的作業要求，而不是等待作業逾時或永不傳回，來協助維護系統的回應時間。 如果斷路器在每次變更狀態時引發事件，這項資訊可用來監視受斷路器保護之系統部分的健康情況，或在斷路器前往 開啟 狀態時警示系統管理員。

模式是可自定義的，而且可以根據可能的失敗類型進行調整。 例如，您可以將增加的逾時定時器套用至斷路器。 一開始，您可以將斷路器置於 Open 狀態，然後如果失敗尚未解決，請將逾時增加至幾分鐘，依此方式。 在某些情況下，相較於 Open 狀態傳回失敗並引發例外狀況，傳回對應用程式有意義的預設值可能很有用。

問題和考量

決定如何實作此模式時，您應該考慮下列幾點：

例外狀況處理：如果作業無法使用，就必須準備透過斷路器叫用作業的應用程式來處理引發的例外狀況。 處理例外狀況的方式會是應用程式特定的。 例如，應用程式可能會暫時降低其功能、叫用替代作業以嘗試執行相同的工作或取得相同的數據，或向使用者報告例外狀況，並要求他們稍後再試一次。

例外狀況類型：要求可能會因為許多原因而失敗，其中有些可能表示比其他失敗類型更嚴重。 例如，要求可能會因為遠端服務損毀而失敗，而且需要幾分鐘的時間才能復原，或因為服務暫時超載而逾時。 斷路器可能會檢查發生的例外狀況類型，並根據這些例外狀況的性質來調整其策略。 例如，相較於服務完全無法使用，可能需要大量的逾時例外狀況，將斷路器移至 Open 狀態。

監視：斷路器應該為失敗和成功的要求提供明確的可觀察性，讓作業小組能夠評估系統健康情況。 使用分散式追蹤來取得服務之間的端對端可見度。

可復原性：您應該將斷路器設定為符合它所保護之作業的可能復原模式。 例如，如果斷路器長時間維持在 Open 狀態，即使失敗的原因已解決，也可能引發例外狀況。 同樣地，如果斷路器從 Open 狀態切換至半開啟狀態太快，斷路器可能會波動並降低應用程式的回應時間。

測試失敗的作業：在 開啟 狀態中，而不是使用定時器來判斷何時切換至 半開啟 狀態，斷路器可以改為定期 ping 遠端服務或資源，以判斷它是否再次可供使用。 此 Ping 可能採用嘗試叫用先前失敗的作業的形式，或者可以使用遠端服務特別提供的特殊作業來測試服務的健康情況，如健康情況端點監視模式所述。

手動覆寫：在失敗作業的復原時間極其可變的系統中，提供手動重設選項會很有説明，讓系統管理員關閉斷路器（並重設失敗計數器）。 同樣地，如果斷路器保護的作業暫時無法使用，系統管理員可以將斷路器強制進入 開啟 狀態（並重新啟動逾時定時器）。

並行：應用程式的大量並行實例可以存取相同的斷路器。 實作不應該封鎖並行要求，或對作業的每個呼叫增加過多的額外負荷。

資源差異：如果有多個基礎獨立提供者，請在針對一種資源使用單一斷路器時，請小心。 例如，在包含多個分區的數據存放區中，當另一個分區遇到暫時性問題時，可能會完全存取一個分區。 如果合併這些案例中的錯誤回應，應用程式可能會嘗試存取某些分區，即使失敗的可能性很高，但存取其他分區可能會遭到封鎖，即使可能成功也一樣。

加速斷路器中斷：有時故障回應可以包含足夠的資訊，讓斷路器立即旅行，並保持最少的時間。 例如，多載共用資源的錯誤回應可能表示不建議立即重試，而且應用程式應該在幾分鐘內再試一次。

多區域部署：斷路器可以針對單一或多區域部署而設計。 後者可以使用全域負載平衡器或自定義區域感知電路中斷策略來實作，以確保受控故障轉移、延遲優化和法規合規性。

服務網格斷路器：斷路器可以在應用層實作，也可以實作為交叉、抽象化的功能。 例如，服務網格通常會支援以 側車 或獨立功能的形式中斷線路，而不需修改應用程式程序代碼。

重新執行失敗的要求：在 Open 狀態中，斷路器也可以記錄每個要求的詳細數據給日誌，並安排在遠端資源或服務可用時重新執行這些要求。

外部服務上的不當逾時：斷路器可能無法完全保護應用程式免於在設定長時間逾時的外部服務中失敗的作業。 如果逾時時間過長，執行斷路器的線程可能會在斷路器指出作業失敗之前封鎖一段很長的期間。 在這一次，許多其他應用程式實例可能也會嘗試透過斷路器叫用服務，並在線程全部失敗之前系結大量的線程。

計算多樣化的適應性：斷路器應該考慮不同的計算環境，從無伺服器到容器化工作負載，其中冷啟動和延展性影響失敗處理等因素。 調適型方法可以根據計算類型動態調整策略，確保異質架構之間的復原能力。

使用此模式的時機

使用此模式：

• 如果這些作業極有可能失敗，藉由停止遠端服務過度叫用或存取共用資源的要求，以防止串聯失敗。
• 若要根據即時失敗訊號以智慧方式路由傳送流量，以增強多重區域復原能力。
• 為了防止相依性變慢，協助您跟上服務等級目標（SLO），並避免因高延遲服務而降低效能。
• 處理間歇性連線問題，並減少分散式環境中的要求失敗。

不建議使用此模式：

• 用於處理應用程式中本機私人資源的存取，例如記憶體內部數據結構。 在此環境中，使用斷路器會增加系統的額外負荷。
• 替代在應用程式的商業規則中處理例外狀況。
• 當已知的重試演算法已足夠，且您的相依性設計用來處理重試機制時。 在此情況下，在您的應用程式中實作斷路器可能會為您的系統新增不必要的複雜度。
• 等候斷路器重設時，可能會造成無法接受的延遲。
• 如果您有訊息驅動或事件驅動架構，因為它們通常會將失敗的訊息路由傳送至寄不出的信件佇列 （DLQ），以進行手動或延遲處理。 這些設計中通常實作的內建失敗隔離和重試機制通常就已足夠。
• 如果失敗復原是在基礎結構或平臺層級進行管理，例如全域負載平衡器或服務網狀結構中的健康情況檢查，可能不需要斷路器。

工作負載設計

架構設計人員應該評估斷路器模式在工作負載的設計中如何使用，以解決 Azure 架構良好架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

相關資源

實作此模式時，下列模式可能也很有用：

• 可靠的 Web 應用程式模式示範如何將斷路器模式 套用至聚合在雲端上的 Web 應用程式。

• 重試模式。 描述當應用程式嘗試連線到服務或網路資源時，如何透過透明地重試先前失敗的作業來處理預期的暫時失敗。

• 健全狀況端點監視模式。 斷路器可能會藉由將要求傳送至服務所公開的端點，測試服務的健康情況。 服務應該會傳回指出其狀態的資訊。