分散式系統裡，「慢」比「死」更致命——一個龜速的下游會把上游的連線與執行緒耗光，整站陪葬。熔斷器、逾時、隔艙就是這條止血線。
🧠 Core Ideas
TIP
熔斷器＝連續失敗 N 次就「開」，之後請求快速失敗、不再打已經在燒的下游；過一陣子放少量探測，健康就重置。正常情境下 fail fast 遠勝 fail slow。
- 真實教訓：某舊服務只是變慢（沒掛），上游 connection pool 沒設逾時 → 執行緒越積越多 → 崩潰。
- 失敗是規模下的統計必然：別耗力氣阻止失敗，把力氣花在優雅處理它。
- 韌性不只程式碼——降級成什麼樣、要多可靠，都要回到跨功能需求（CFR / SLO）與產品判斷。
⚖️ Tradeoffs
逾時 (Time-outs) — 每個跨行程呼叫都要設
- 看下游正常回應時間（多半 ms 級），設略高於正常範圍就好（把 30 秒改 1 秒——用戶 30 秒早重整五次了）。
- 除了單次逾時，對整個操作設 total budget：預算用光就中止，即使單一呼叫還沒到 timeout。
隔艙 (Bulkheads) — 別共用同一個池
- 出自《Release It!》：船艙漏水能封閉、保住其他艙。
- 關鍵錯誤是所有下游共用同一個 connection pool → 一個慢下游拖垮全部。正解：每個下游一個獨立 pool。
- 資源緊張時主動拒絕請求（load shedding）；切細微服務本身就是一種隔艙。
熔斷器 (Circuit Breaker) — 同步下游建議「強制」加
- 連續失敗 → open → 後續請求快速失敗，不再打下游；定時探測、健康則重置。
- 額外用途：當自動的隔艙密封；維護時手動開斷，避免請求打到下線服務；操作前先看狀態，已 open 就直接放棄。
- 與重試搭配：可重試錯誤（503/504）才重試、且要退避，別在下游燒起來時猛打。
🔑 Takeaways
- latency kills：慢下游比死下游更危險，逾時 + 熔斷把「慢」轉成「快速失敗」。
- 三件套：逾時（含 total budget）、隔艙（每下游獨立 pool）、熔斷器（同步下游強制加）。
- 假設失敗必然發生，設計成優雅降級，並用 SLO 定義「多韌才夠」。
No notes yet — jot your takeaways or Q&A here.