題目與適用場景
bootstrap 端點編排三個下游呼叫。資料和權限是正確渲染外殼所必需，資訊流可以陳舊或缺失。端點必須返回具型別的回應，讓用戶端分別渲染安全區塊。p95 預算 300 毫秒包含編排開銷，並要說明哪些資料可以快取、快取多久。
面試官考察點
- 從使用者需求推導並行度、逾時預算和失敗語意。
- 區分缺失資料、空結果和依賴錯誤。
- 組合重試、熔斷、艙壁和快取策略，避免放大負載。
- 設計可演進回應協定與有用的運行訊號。
回答前需要釐清的問題
確認權限是否允許陳舊、資訊流的新鮮度上限、用戶端是否支援漸進渲染，以及呼叫是否共享租戶與授權上下文。權限不能陳舊時必須留在關鍵路徑；資訊流若允許五分鐘陳舊，可以用 stale-while-revalidate 快取保護延遲。
30 秒回答框架
閘道先完成一次驗證，並行呼叫資料、權限和資訊流，然後為組裝預留截止時間。必要區塊失敗時拒絕或返回安全狀態；可選區塊返回帶原因碼和資料時間的明確不可用狀態。重試只用於瞬時且冪等的讀取，並消耗共享預算。每個依賴設定逾時、艙壁、熔斷和陳舊快取，避免一次故障讓外殼空白。指標記錄區塊成功率、截止時間耗盡、陳舊回應和依賴飽和。
分步深入解答
1. 設定時間和並發預算
每秒 2000 次請求下，三個串行呼叫會耗盡 300 毫秒預算。並行呼叫，為每個依賴設定低於總截止時間的局部截止時間，並在剩餘時間內完成組裝與序列化。限制連線池，使用每請求取消訊號，讓逾時依賴停止繼續消耗資源。
2. 定義部分回應語意
返回穩定外殼，為每個區塊標記 ready、stale 或 unavailable，並附機器可讀原因和資料時間，但不洩露內部主機名稱。資料或權限錯誤應拒絕或返回登入/操作狀態；資訊流逾時可以保留可用外殼。遵循 RFC 9457 的錯誤物件可以描述請求級錯誤，同時不假裝所有區塊都失敗。
3. 保護依賴免受重試和故障影響
只重試瞬時錯誤、冪等讀取，而且只能在共享截止時間內重試一次。加入抖動，熔斷打開後停止重試。每個依賴的艙壁限制並發；陳舊快取或有界預設值處理可選資訊流。熔斷器能防止反覆故障耗盡閘道容量，但不能替代逾時和恢復探測。
4. 演進並觀測協定
以追加欄位方式版本化，讓用戶端忽略未知區塊，並攜帶請求關聯識別碼。記錄依賴延遲、逾時原因、熔斷狀態、快取年齡、區塊狀態和回應大小。為扇出樹建立追蹤，抽樣慢請求，並監控必要區塊失敗率、陳舊時間和重試量。協定測試涵蓋權限就緒、資料陳舊、資訊流不可用等混合結果。
高品質示範回答
我會先確認新鮮度和是否允許漸進渲染。閘道完成一次驗證，呼叫三個讀取服務，並在總預算 300 毫秒內分配局部截止時間。回應按區塊返回 ready、stale 或 unavailable。身分和權限失敗時拒絕，資訊流可使用有界陳舊快取。瞬時冪等讀取只允許一次帶抖動的重試，並由依賴艙壁和熔斷保護。指標和追蹤暴露區塊失敗與截止時間壓力，追加欄位保證舊用戶端繼續工作。
常見錯誤
- 串行呼叫依賴 → 延遲相加超過預算 → 有界並行並設定截止時間。
- 用含糊的 null 返回 HTTP 200 → 用戶端無法區分空資料和失敗 → 使用明確區塊狀態和原因碼。
- 每層都重試所有錯誤 → 故障變成重試風暴 → 分類錯誤並執行共享重試預算。
- 沒有策略就快取權限 → 授權可能過期仍被使用 → 定義新鮮度上限或失敗關閉。
- 使用一個全域熔斷器 → 資訊流故障阻塞身分資料 → 按依賴隔離熔斷和艙壁。
- 只記錄總延遲 → 無法區分可選與必要失敗 → 輸出區塊指標和追蹤。
追問及應對
資訊流很慢，但使用者要立即看到外殼，怎麼辦？
縮短資訊流截止時間，在允許的年齡內返回有界陳舊結果，否則返回 unavailable。外殼保持獨立，用戶端之後再載入資訊流。
某區域權限資料陳舊，可以返回嗎？
只有授權策略明確允許該陳舊程度，且回應傳達資料年齡時才可以。敏感操作應重新向權威來源檢查，不確定時失敗關閉。
如何防止重試延長到 300 毫秒之後？
透過扇出上下文傳遞一個絕對截止時間。每次重試前預留嘗試與組裝時間；沒有剩餘時間就返回區塊逾時狀態，不啟動注定無法完成的工作。
熔斷打開後依賴恢復，如何恢復流量？
冷卻後傳送少量半開探測。只有探測滿足相同逾時和錯誤標準才關閉熔斷，否則保持打開並暴露下次探測時間。