題幹與適用場景
服務同時呼叫資料庫、支付和推薦依賴。推薦服務從 10ms 變成 1s 後，請求並發因等待時間增加而膨脹，執行緒池和連線池被占滿，連不依賴推薦的 API 也失敗。請設計 bulkhead，讓慢依賴的影響停留在相關功能。
AWS Builders’ Library 將這種問題歸因於延遲驅動的並發過載：逾時不能替代並發上限，必須圍繞每個客戶端或依賴隔離資源。方案要同時保護本服務與下游，不能只增加逾時或重試。
面試官考察點
- 能否解釋 Little’s Law 直覺：延遲上升會在相同到達率下推高在途請求。
- 是否按依賴、API、租戶或資源池劃分並發預算，避免一個慢依賴耗盡全域資源。
- 是否區分硬配額、軟配額、動態分配，並說明公平性與利用率取捨。
- 是否設計快速拒絕、降級、逾時、熔斷、恢復和可觀測性。
- 是否驗證無關 API 仍可用，且隔離不會造成佇列爆炸或飢餓。
回答前需要釐清的問題
- 哪些 API 呼叫推薦依賴，哪些是關鍵路徑？請求是否可降級？
- 執行緒、連線、記憶體和佇列的上限及目前並發分布是什麼？
- 下游是否支援取消、冪等、批量或快取？呼叫方 deadline 如何傳遞？
- 預算按 API、依賴、租戶還是可用區隔離？是否需要動態借用？
- 故障時的使用者體驗、錯誤契約和恢復目標是什麼？
30 秒回答框架
「我為每個依賴建立獨立並發艙壁和有限佇列，關鍵 API 與可降級 API 分池。請求攜帶 deadline，超過預算立即快速失敗或回傳快取；不把逾時當並發保護。先用軟配額提高利用率，再用硬上限保護全域，動態借用必須有最大值。指標按依賴和 API 觀察在途數、拒絕、等待、逾時和恢復，壓測慢依賴驗證無關功能仍可用。」
分步驟深入解答
第一步：量化延遲驅動的並發
記錄每個依賴的到達率、服務時間、在途請求和逾時。服務時間從 10ms 變 1s 時，即使請求率不變，在途量也可能擴大約 100 倍。先找到資源瓶頸，再決定艙壁大小。
第二步：劃分資源艙壁
按依賴建立獨立連線池、信號量和佇列；對同一依賴的關鍵與可降級 API 再分池。避免隔離名義上存在、實際仍共用執行緒或連線。
第三步：選擇硬、軟和動態配額
硬配額保證單個 API 不超限，但流量偏斜時利用率低；軟配額允許空閒預算借用，仍需全域上限；動態配額依負載調整，必須有最小保障、最大上限和變更速率。
global_limit = 500
payments = hard 150
recommendations = soft 200, borrow <= 100
other_apis = reserved 50第四步：設計拒絕與降級
取得並發許可失敗時快速返回明確錯誤或快取結果，不把請求塞入無限佇列。下游逾時遵守呼叫方 deadline，取消未完成工作；重試必須有限額、退避和冪等條件。
第五步：恢復與防止振盪
慢依賴恢復後逐步增加配額，用熔斷或半開探測避免瞬時洪峰。保留拒絕、逾時和佇列水位時間序列，按依賴、API、租戶和 cell 分析。設定變更需要版本和回滾。
第六步：驗證隔離邊界
注入單一依賴延遲、錯誤和連線耗盡，觀察推薦 API 拒絕率、關鍵支付 API 成功率、全域執行緒/連線使用和尾延遲。測試突發、租戶傾斜、設定更新和 cell 故障；驗收無關 API 仍達標且佇列有界。
高品質示範回答
「我先用到達率、服務時間和在途量證明推薦依賴變慢會放大並發。每個依賴有獨立信號量、連線池和有界佇列，關鍵與可降級 API 分開。支付設硬保留，推薦使用軟配額並限制借用；所有呼叫傳播 deadline，許可不足快速失敗或回傳快取。」
「恢復時半開探測並逐步增加額度。指標包含在途數、許可拒絕、等待、逾時、降級命中、下游錯誤和恢復時間。故障演練只拖慢推薦，驗證支付和其他 API 的尾延遲、連線池和執行緒池不越界。」
常見錯誤
- 只調大逾時 → 在途請求膨脹 → 設定依賴級並發上限。
- 所有 API 共用執行緒和連線池 → 慢依賴拖垮全站 → 按依賴和關鍵性分池。
- 無限佇列緩衝 → 記憶體和延遲失控 → 有界佇列並快速拒絕。
- 硬配額靜態切死 → 流量偏斜時資源閒置 → 軟借用但保留最大邊界。
- 重試無預算 → 放大下游過載 → 傳播 deadline、限制次數並要求冪等。
- 只測故障依賴 → 無法證明隔離 → 同時驗證無關 API 的 SLO。
追問及應對
為什麼逾時不能替代並發隔離？
逾時只限制單次等待時間；等待期間仍占用執行緒、連線和記憶體。依賴延遲上升會讓更多請求同時在途，必須限制許可數量。
軟配額如何避免一個 API 借光資源？
設定全域上限、每 API 最小保留、單次借用最大值和回收速度；借用方達到上限後快速失敗，不能無限增長。
什麼時候回傳快取？
讀取且業務允許陳舊時可回傳帶時間戳的快取；支付、權限和寫入結果不能用過期資料靜默替代。
如何判斷隔離真的生效？
注入單依賴慢和錯誤，檢查無關 API 的在途、尾延遲、執行緒/連線占用和成功率；若仍同步下降，說明共用資源或佇列邊界未隔離。