熔斷器模式 (Circuit Breaker)

引言：「級聯失效」問題

在微服務架構中，服務 A 調用服務 B。如果服務 B 響應變慢，服務 A 的執行緒就會開始堆積等待。很快，服務 A 耗盡記憶體並崩潰。接著，調用服務 A 的服務 C 也會跟著崩潰。這就是 級聯失效 (Cascading Failure)。

熔斷器 就像家裡電路的保險絲。如果某個服務開始頻繁報錯，熔斷器就會「跳閘」，停止所有對該服務的調用，給她喘息和恢復的時間，同時向使用者返回一個優雅的降級錯誤。

演算法要解決什麼問題？

• 輸入： 服務調用的成功/失敗信號。
• 輸出： 連接的狀態（關閉, 開啟, 或 半開）。
• 承諾： 穩定性。防止單一組件的故障拖垮整個系統。

核心狀態 (工作原理)

1. 關閉 (Closed - 健康)： 一切正常，流量正常流向服務。
2. 開啟 (Open - 故障)： 如果失敗率超過閾值（如 1 分鐘內 50% 失敗），熔斷器就會 跳閘 (開啟)。後續所有請求都會立即失敗，不再發往故障服務。
3. 半開 (Half-Open - 探測)： 在等待一段時間（如 30 秒）後，熔斷器允許 少量 測試請求通過。
   • 如果成功：熔斷器恢復到 關閉 狀態。
   • 如果失敗：重新回到 開啟 狀態。

服務降級 (Fallback)：「B 計劃」

當熔斷器開啟時，系統不應只顯示冰冷的「500 錯誤」，而應執行 降級邏輯：

• 預設值： 「功能暫時不可用，請稍後再試」。
• 靜態快取： 顯示上一次成功獲取的舊數據。
• 簡化邏輯： 比如關閉「個性化推薦」板塊，但保證基礎商品詳情能正常顯示。

典型業務場景

• ✅ 支付閘道： 如果支付服務宕機，熔斷器跳閘，前端提示「支付功能維護中」，防止使用者瘋狂點擊提交。
• ✅ 微服務通訊： 保護高負載的搜尋服務，當其資料庫壓力過大時自動限流。
• ✅ 第三方 API： 避免在對方 API 報錯期間繼續調用，浪費配額或增加成本。

性能與複雜度總結

• 開銷： 極低。她只是一個帶有計數器的狀態機。
• 工具： Resilience4j, Netflix Hystrix (已過時), 或 Istio 等 Service Mesh 自帶的熔斷功能。

小結：一句話記住它

「熔斷器是雲端的『保險絲』。她阻止你往火坑裡繼續添柴，給那些搖搖欲墜的服務一個呼吸和重生的機會。」