高可用三大利器 — 熔斷

高可用的三大利器是熔斷、限流和降級。它們都是在分散式系統中用於保障系統穩定性和可用性的重要策略。

熔斷（Circuit Breaker）：熔斷是一種防止故障擴散的機制。當一個服務出現故障或超時，熔斷器會開啟並快速失敗，拒絕後續的請求，避免請求堆積和資源耗盡。熔斷器會暫時遮蔽該服務，並在一段時間後嘗試恢復。熔斷器的狀態變化可用於監控系統健康和提供告警資訊。

限流（Rate Limiting）：限流是一種控制系統請求流量的機制。通過設定一個請求速率閾值，限流可以限制每個使用者端或使用者在特定時間內的請求次數。這樣可以防止過多的請求湧入系統，保護系統免受過載和壓力衝擊。限流可以平滑流量，避免系統突發流量的影響。

降級（Fallback）：降級是一種在面對特殊業務或異常情況時保持系統可用的策略。當服務不可用時，降級服務會代替提供一些基本功能或返回預設的預設值，以確保系統依然能夠提供有限的功能或服務；或者某些特定活動場景（雙十一）下優先保障計算資源業務傾向的服務而降級邊緣服務。

本篇主要介紹熔斷相關內容。

熔斷（Circuit Breaker Pattern）

在現代分散式架構中，一個服務通常會與多個外部服務進行互動，這些外部服務可能是RPC介面、資料庫、第三方API等。例如，在支付過程中，可能需要呼叫銀聯提供的API；而查詢某個商品的價格，則可能需要進行行銷活動查詢。然而，除了自身服務外，依賴的外部服務的穩定性無法絕對保證。

當依賴的第三方服務出現不穩定的情況時，例如響應時間延長，會導致服務自身呼叫第三方服務的響應時間也變長，形成級聯效應。這樣一來，服務自身的執行緒可能會積壓，最終可能耗盡業務自身的執行緒池，導致服務本身變得不可用。

熔斷（Circuit Breaker）是一種用於處理分散式系統中故障和超時的設計，它可以幫助系統在出現問題時保持穩定，防止故障進一步擴散，同時也能在一段時間後重新嘗試恢復正常操作。避免區域性不穩定因素導致整個分散式系統的雪崩。熔斷作為保護服務自身的手段，通常在使用者端（呼叫端）進行設定。

熔斷器模式（Circuit Breaker Pattern），由Michael Nygard在他的著作《Release It!》中推薦的，可以防止應用程式反覆嘗試執行可能會失敗的操作，使其能夠繼續進行而無需等待故障被修復，也無需浪費CPU週期來確定故障是否持久。Circuit Breaker模式還使應用程式能夠檢測故障是否已解決。如果問題似乎已經解決，應用程式可以嘗試呼叫該操作。

注：這種設計也是典型的 快速失敗原則（Fail-Fast Principle） 的應用。強調在面對錯誤或異常情況時，系統應該儘早地檢測並快速失敗，而不是繼續執行可能導致更嚴重後果的操作。這個原則的目的是儘早發現問題並及時處理，避免故障進一步擴大，從而提高系統的穩定性和可靠性。

熔斷器的三種狀態：

• Closed狀態：來自應用程式的請求被路由到操作。代理維護最近故障次數的計數，如果對操作的呼叫不成功，代理會增加這個計數。如果在給定的時間段內最近故障的次數超過了指定的閾值，代理將進入Open狀態。此時，代理啟動一個超時計時器，當計時器到期時，代理將進入Half-Open狀態。

• Open狀態：來自應用程式的請求立即失敗，並嚮應用程式返回異常。

• Half-Open狀態：應用程式允許有限數量的請求通過並呼叫操作。如果這些請求成功，假定之前導致失敗的故障已經修復，斷路器將切換到Closed狀態（故障計數器被重置）。如果任何請求失敗，斷路器會認為故障仍然存在，因此它會回退到Open狀態，並重新啟動超時計時器，為系統提供進一步的時間來從故障中恢復。

推薦開源框架選擇 Resilience4j、Sentinel，Hystrix已經宣佈不維護了.

附上，一張網上廣泛流傳的對比表格 [1]

熔斷要考慮的問題

熔斷異常應該如何處理：三方服務處於在熔斷 Open狀態下，應該如何進行服務的返回。比如：用一個預設值來替代三方服務的返回結果；返回異常頁面告知使用者稍後再重試；呼叫其他的服務來替代原來的功能等。異常往往多樣的，也可以考慮不同異常下設定不同的處理方式。

應該記錄詳細紀錄檔：注意異常紀錄檔的記錄，確保關鍵資訊都寫入紀錄檔，往往線上故障異常的多樣的；好的紀錄檔格式/紀錄檔設計能夠快速的定位問題、監控熔斷策略符合預期。熔斷狀態的轉換需要詳細寫入，方便覆盤熔斷策略。

是否需要診斷定時程式：當處於熔斷 Open狀態時，考慮是否需要來做個定時程式 測試三方服務是否恢復並轉換 到 Half-Open狀態，更靈活的恢復服務。

管理熔斷的工具：由於異常是多樣的，某些情況下意外觸發了熔斷；此時管理員可以通過熔斷工具來恢復相關狀態，應對熔斷策略出現問題的情況。

注意三方服務耗時：有時候三方服務能夠正常返回但耗時很長，這樣可能會導致自身服務的超時；針對這種情況應該進行相關超時熔斷處理，應該關注這種隱蔽的超時異常。

參考文獻

1. sentinel 限流熔斷神器詳細介紹 https://blog.csdn.net/a745233700/article/details/122733366
2. Release It! Second Edition https://pragprog.com/titles/mnee2/release-it-second-edition/