高可用的三大利器是熔斷、限流和降級。它們都是在分散式系統中用於保障系統穩定性和可用性的重要策略。熔斷（Circuit Breaker）：熔斷是一種防止故障擴散的機制。當一個服務出現故障或超時，熔斷器會打開並快速失敗，拒絕後續的請求，避免請求堆積和資源耗盡。熔斷器會暫時屏蔽該服務，併在一段時間後嘗試恢... ...
高可用的三大利器是熔斷、限流和降級。它們都是在分散式系統中用於保障系統穩定性和可用性的重要策略。
熔斷（Circuit Breaker）：熔斷是一種防止故障擴散的機制。當一個服務出現故障或超時，熔斷器會打開並快速失敗，拒絕後續的請求，避免請求堆積和資源耗盡。熔斷器會暫時屏蔽該服務，併在一段時間後嘗試恢復。熔斷器的狀態變化可用於監控系統健康和提供告警信息。
限流（Rate Limiting）：限流是一種控制系統請求流量的機制。通過設置一個請求速率閾值，限流可以限制每個客戶端或用戶在特定時間內的請求次數。這樣可以防止過多的請求涌入系統，保護系統免受過載和壓力衝擊。限流可以平滑流量，避免系統突發流量的影響。
降級（Fallback）：降級是一種在面對特殊業務或異常情況時保持系統可用的策略。當服務不可用時，降級服務會代替提供一些基本功能或返回預設的預設值，以確保系統依然能夠提供有限的功能或服務；或者某些特定活動場景（雙十一）下優先保障計算資源業務傾向的服務而降級邊緣服務。
本篇主要介紹熔斷相關內容。
熔斷（Circuit Breaker）
在現代分散式架構中，一個服務通常會與多個外部服務進行交互，這些外部服務可能是RPC介面、資料庫、第三方API等。例如，在支付過程中，可能需要調用銀聯提供的API；而查詢某個商品的價格，則可能需要進行營銷活動查詢。然而，除了自身服務外，依賴的外部服務的穩定性無法絕對保證。
當依賴的第三方服務出現不穩定的情況時，例如響應時間延長，會導致服務自身調用第三方服務的響應時間也變長，形成級聯效應。這樣一來，服務自身的線程可能會積壓，最終可能耗盡業務自身的線程池，導致服務本身變得不可用。
熔斷（Circuit Breaker）是一種用於處理分散式系統中故障和超時的設計，它可以幫助系統在出現問題時保持穩定，防止故障進一步擴散，同時也能在一段時間後重新嘗試恢復正常操作。避免局部不穩定因素導致整個分散式系統的雪崩。熔斷作為保護服務自身的手段，通常在客戶端（調用端）進行配置。
熔斷器模式（Circuit Breaker Pattern），Michael Nygard在他的著作《Release It!》中推薦使用，可以防止應用程式反覆嘗試執行可能會失敗的操作，使其能夠繼續進行而無需等待故障被修複，也無需浪費CPU周期來確定故障是否持久。Circuit Breaker模式還使應用程式能夠檢測故障是否已解決。如果問題似乎已經解決，應用程式可以嘗試調用該操作。
註：這種設計也是典型的 快速失敗原則（Fail-Fast Principle） 的應用。強調在面對錯誤或異常情況時，系統應該儘早地檢測並快速失敗，而不是繼續執行可能導致更嚴重後果的操作。這個原則的目的是儘早發現問題並及時處理，避免故障進一步擴大，從而提高系統的穩定性和可靠性。
熔斷器的三種狀態：
-
Closed狀態：來自應用程式的請求被 Proxy 操作。Proxy 維護最近故障次數的計數，如果對操作的調用不成功，Proxy 會增加這個計數。如果在給定的時間段內最近故障的次數超過了指定的閾值，Proxy 將進入Open狀態。此時，Proxy 啟動一個超時計時器，當計時器到達閾值時，Proxy 將進入Half-Open狀態。（這裡 Proxy 代指 Resilience4j、Sentinel、Hystrix類似框架）
-
Open狀態：來自應用程式的請求立即失敗，並嚮應用程式返回異常。
-
Half-Open狀態：應用程式允許有限數量的請求通過並調用操作。如果這些請求成功，假定之前導致失敗的故障已經修複，將切換到Closed狀態（故障計數器被重置）。如果任何請求失敗，會認為故障仍然存在，因此它會回退到Open狀態，並重新啟動超時計時器，為系統提供進一步的時間來從故障中恢復。
推薦開源框架選擇 Resilience4j、Sentinel，Hystrix已經宣佈不維護了.
附上，一張網上廣泛流傳的對比表格 [1]
熔斷要考慮的問題
熔斷異常應該如何處理：三方服務處於在熔斷 Open狀態下，應該如何進行服務的返回。比如：用一個預設值來替代三方服務的返回結果；返回異常頁面告知用戶稍後再重試；調用其他的服務來替代原來的功能等。異常往往多樣的，也可以考慮不同異常下設置不同的處理方式。
應該記錄詳細日誌：註意異常日誌的記錄，確保關鍵信息都寫入日誌，往往線上故障異常的多樣的；好的日誌格式/日誌設計能夠快速的定位問題、監控熔斷策略符合預期。熔斷狀態的轉換需要詳細寫入，方便復盤熔斷策略。
是否需要診斷定時程式：當處於熔斷 Open狀態時，考慮是否需要來做個定時程式 測試三方服務是否恢復並轉換 到 Half-Open狀態，更靈活的恢復服務。
管理熔斷的工具：由於異常是多樣的，某些情況下意外觸發了熔斷；此時管理員可以通過熔斷工具來恢復相關狀態，應對熔斷策略出現問題的情況。
註意三方服務耗時：有時候三方服務能夠正常返回但耗時很長，這樣可能會導致自身服務的超時；針對這種情況應該進行相關超時熔斷處理，應該關註這種隱蔽的超時異常。
參考文獻
- sentinel 限流熔斷神器詳細介紹 https://blog.csdn.net/a745233700/article/details/122733366
- Release It! Second Edition https://pragprog.com/titles/mnee2/release-it-second-edition/
