Disgn

熔斷並不是「修補不穩定」的設計，而是預防連鎖崩潰的一種保險。
就像電路裡的保險絲，當某個服務過載或回應過慢時，熔斷器會暫時中斷請求，防止所有流量一起壓垮整個系統。
這其實是一種「系統彈性」設計哲學

熔斷後要多久恢復？如果恢復太慢會影響體驗，太快又可能反覆熔斷？

這是一種「穩定 vs 敏捷」的矛盾。恢復時間太短，會導致「抖動效應」——服務剛好起來又被壓垮；太長則使用者體驗差。理想的策略是設一個半開狀態（Half-Open）：部分流量試探性放行

假設支付服務在 10 秒內失敗了 5 次後被熔斷。30 秒後熔斷器自動進入「半開」，只允許 10% 的請求通過測試；若成功率高於 80%，則恢復正常運行

熔斷與重試（Retry）會不會互相衝突

「重試」希望挽救暫時錯誤，「熔斷」希望阻止持續錯誤，若兩者交錯使用不當，會導致雪崩效應（大量重試瞬間壓垮服務）

在支付請求中若每次失敗都重試3次，而熔斷器設定在10次錯誤觸發，實際上只要4個使用者同時錯誤，就可能觸發熔斷。