問題與範圍
平台位於多個 API 服務前方。流量可能在一分鐘內升高 20 倍，下游資料庫、搜尋或第三方依賴容量不同。請設計請求分類、准入、排隊、負載削減、降級回應和恢復機制。閘道不負責業務授權、完整 WAF 規則或替下游修復容量問題。
面試官在考察什麼
重點是區分「限流」與「過載保護」：限流常按身分或時間窗限制速率，准入控制則依目前並發、佇列年齡和依賴健康決定是否接收工作。高品質回答會說明丟棄什麼、為何丟棄、如何避免低優先級流量餓死，以及恢復時如何避免流量瞬間回灌。
回答前要釐清的問題
- 哪些請求是關鍵路徑，哪些可以延遲、快取或回傳降級結果？
- 目標是保護閘道、某個依賴、某個租戶，還是所有邊界？
- 允許排隊多久？逾時後客戶端應重試、輪詢還是接受空結果？
- 高峰時是否需要按租戶、區域、API 或成本公平分配容量？
- 哪些狀態碼、標頭和指標對呼叫方可見？
30 秒回答框架
「我會在入口解析請求類、租戶和成本標籤，先做硬性並發與預算檢查，再把可接受工作送入按優先級和租戶分區的有限佇列。准入控制器根據 in-flight、佇列年齡、錯誤率和依賴訊號動態調整目標並發；過載時優先拒絕可重試或低價值工作，為關鍵請求保留容量。可快取或可近似的操作走降級路徑，拒絕回應帶明確重試時間。恢復採漸進放量和受控探測，避免恢復風暴。」
分步深入設計
入口先驗證請求大小、逾時預算和租戶配額，再映射到 criticality、cost、retryability 與 dependency 標籤。標籤由受信任路由設定產生，不能讓客戶端自報關鍵。健康檢查和管理流量使用獨立保留池，避免資料流量耗盡控制面。
每個 API 和依賴維護 in-flight 上限、排隊上限和逾時預算。使用信號量或租約計數保護真實資源；佇列必須有界，不能用無限訊息積壓掩蓋過載。准入成功後才消耗預算，取消或逾時要釋放租約。串流請求按連線和位元組另設預算。
調度器按優先級、租戶權重和老化時間選擇工作。關鍵請求擁有保底並發，低優先級請求可丟棄或轉入延遲佇列；老化機制防止長期飢餓。一個租戶的突發不能借用其他租戶保底額度。跨區域時可在本地快速拒絕，避免為全域精確計數增加故障依賴。
控制器每個短窗口更新目標並發：當 p95 延遲、佇列年齡或下游錯誤超過閾值時降低窗口；穩定時緩慢增加。訊號要平滑並帶遲滯，避免閾值附近抖動。客戶端重試不能當作健康訊號；記錄重試放大倍數，透過 Retry-After、隨機抖動和重試預算限制回流。
負載削減按請求語意選擇。推薦、統計和預覽可回傳快取或近似結果；寫入、支付、權限變更等關鍵操作通常快速失敗並要求安全重試。降級結果必須帶版本、時間和新鮮度，不能假裝完整資料。閘道不應在不理解業務時任意丟棄不可重試副作用。
依賴出現逾時或錯誤時，依賴隔離池限制連線、並發和重試預算，斷路器只允許受控探測。快取和靜態回應在隔離池內服務；探測成功後漸進恢復。回應記錄准入決策、策略版本、拒絕原因、佇列等待和依賴訊號。
監控准入率、按優先級和租戶的拒絕率、最老佇列年齡、in-flight、p95/p99 延遲、下游錯誤、重試放大、降級新鮮度和恢復斜率。對帳資源預算與實際連線、執行緒、資料庫連線和佇列工作。故障注入涵蓋突發流量、慢依賴、設定錯誤、控制器失聯、區域分割和重放風暴。
高品質示範回答
「我會在閘道入口給請求標記受信任的關鍵性、成本、可重試性和依賴。每個 API/依賴都有有限並發、有限佇列和保底容量；調度器按優先級、租戶權重和老化時間取工作。控制器用 p95 延遲、佇列年齡和下游錯誤調節目標並發，帶遲滯避免抖動。過載時優先拒絕低價值、可重試工作，關鍵寫入保留額度；推薦和預覽可回傳帶新鮮度的快取結果。
所有拒絕回應帶穩定原因、Retry-After 和請求 ID。依賴隔離池、重試預算和受控探測防止級聯失敗，恢復採漸進放量。指標涵蓋拒絕公平性、重試放大、降級新鮮度和恢復斜率；故障注入驗證控制器失聯、區域分割和重放風暴。」
常見錯誤
- 只加固定 QPS 限流 → 真實瓶頸可能是連線、CPU 或下游錯誤 → 結合並發、佇列和依賴訊號。
- 使用無限佇列 → 延遲失控並掩蓋容量不足 → 設定有界佇列和明確拒絕。
- 所有請求同等優先 → 關鍵路徑被低價值工作擠占 → 按語意保留容量並加老化。
- 客戶端可自報高優先級 → 惡意呼叫者繞過保護 → 由受信任路由分類。
- 過載時無限重試 → 重試放大讓依賴更快崩潰 → 預算、抖動和
Retry-After。 - 降級回傳無時間資訊 → 使用者把舊結果當事實 → 標記版本、新鮮度和來源。
- 恢復立即放開全部流量 → 重放風暴再次壓垮系統 → 漸進放量和受控探測。
- 追求精確全域計數 → 保護路徑依賴更多故障組件 → 本地快速決策並接受有界誤差。
追問與回答
追問一：准入控制和限流有什麼不同？
限流約束身分在時間窗內的請求數；准入控制決定工作是否能占用真實資源，考慮並發、佇列等待、成本和依賴健康。兩者可同時存在。
追問二：如何避免關鍵租戶被低優先級租戶擠出？
為關鍵租戶保留獨立並發池或保底配額，再在共享容量按權重調度。每租戶也要有最大預算，防止無限借用保留池。
追問三：為什麼不讓請求一直排隊？
等待超過業務截止時間後，排隊只會製造逾時和重試。有限佇列讓系統明確拒絕過量工作。
追問四：控制器使用哪些訊號？
至少包括 p95/p99 延遲、in-flight、最老佇列年齡、依賴錯誤率和資源利用率。訊號需平滑並帶遲滯，區分客戶端重試流量。
追問五：關鍵寫入可以降級嗎？
只有業務明確允許時才可以，例如先寫入持久佇列後非同步完成。支付、權限和庫存等副作用不能回傳假成功。
追問六：如何驗證恢復不會再次過載？
注入依賴恢復、積壓工作和客戶端重試，觀察漸進放量、保底容量、佇列年齡和錯誤率。控制器需有最大增幅、冷卻窗和人工暫停。