題幹與適用場景
平台有數百個閘道實例和多個區域。產品團隊希望按租戶、應用、端點和計費方案設定每秒請求數、並發數和每日額度，策略更新要在分鐘內生效。系統必須避免單一租戶占滿資源，同時在配額服務短暫故障時保留核心 API 的可用性。
題目考察控制面與資料面分離、計數模型、分發一致性、跨區域權衡和失敗策略。Envoy 文件區分本地與全域限流，RFC 9331 定義 HTTP RateLimit 欄位；候選人需要把協定、產品策略和執行時執行連接起來。
面試官考察點
重點包括策略模型、版本與審批、描述符鍵設計、令牌桶或滑動視窗、熱門租戶、跨區域計數、設定分發、快取、fail-open/fail-closed、配額回應標頭、稽核和成本。
回答前需要釐清的問題
- 配額是硬限制、軟告警還是兩者並存，是否允許突發和借用未來額度？
- 哪些維度必須全域精確，哪些維度允許區域近似？
- 策略更新的生效延遲和回滾目標是什麼，閘道斷開控制面多久算過期？
- 超限請求需要穩定的重試時間、客戶可見剩餘額度和計費事件嗎？
- 哪些核心 API 在限流服務故障時必須繼續服務？
30 秒回答框架
「控制面儲存經審批的版本化策略，編譯成閘道可執行的描述符並增量分發。資料面在本地快速判定，只有需要全域精度的維度才呼叫共用限流服務。令牌桶處理突發，配額計數按租戶和端點隔離；策略帶 TTL、校驗和與回滾版本。故障時按端點風險選擇 fail-open 或 fail-closed，並返回標準 RateLimit 資訊和可稽核的決策原因。」
分步驟深入解答
第一步：定義策略與發布工作流
策略物件包含租戶、應用、端點、視窗、速率、容量、並發、每日額度、區域範圍和優先級。避免讓閘道直接解釋任意產品欄位；控制面將策略編譯為穩定的限流描述符。
policy v42:
subject: tenant:acme / app:billing
route: POST /invoices
rate: 200 requests/second
burst: 400
scope: global發布流程需要審批、靜態衝突檢查、模擬流量和版本簽章。每個版本保留變更人、原因、預計影響和回滾指標，禁止未經稽核的直接覆蓋。
第二步：選擇計數與分片模型
閘道本地用令牌桶快速吸收短突發；全域維度可由共用限流服務按描述符計數。對每日額度，使用按視窗的原子計數或分片配額，明確視窗邊界和時鐘來源。
按租戶、應用和端點分片，避免單一熱門鍵成為瓶頸。熱門租戶可採用分層令牌、預分配配額或專用分片，但必須說明短暫超發和最終帳單的處理。
第三步：設計控制面分發與一致性
控制面把策略編譯結果透過帶版本和校驗和的流分發到閘道。閘道只接受單調遞增且簽章有效的版本，啟動時載入最後一個有效快照；缺失更新時按 TTL 標記 stale 並產生告警。
區域內優先本地分發，跨區域策略用全域版本號和明確的生效時間。回滾也是新版本，不能改寫歷史；閘道確認接收後回報版本覆蓋率。
第四步：處理一致性、突發與公平性
全域精確計數會引入網路延遲和共用狀態成本，因此只對高風險、強合約約束的維度使用強協調，其餘維度允許有界誤差。突發容量應與後端並發預算對齊，不能只提高閘道桶容量。
多租戶公平性需要防止單一租戶占滿共用連線池。把配額判定與並發艙壁、佇列長度和優先級聯動，記錄被拒絕或排隊的原因，避免只返回一個數字讓客戶無法診斷。
第五步：定義故障與降級策略
限流服務不可達時，低風險唯讀 API 可使用最近本地快照和有限 fail-open；寫入、計費和高成本端點使用 fail-closed 或更嚴格的本地上限。所有降級決定帶過期時間，恢復後補發計數或標記近似。
閘道重啟、時鐘漂移、訊息重複和分發中斷都要有演練。策略快照損壞時拒絕載入並保留上一份有效版本，不能把空設定當成無限額度。
第六步：協定、稽核與可觀測性
超限回應返回穩定的 429 語意，並按 RFC 9331 暴露可解釋的限制、剩餘量和重置時間；對不適合公開精確數字的租戶可使用分級提示。內部記錄決策版本、描述符、區域、計數來源、降級狀態和請求追蹤。
監控版本覆蓋率、判定延遲、拒絕率、熱門鍵、計數誤差、降級時長和策略回滾。用影子策略評估新規則，比較拒絕變化後再正式發布。
高品質示範回答
我會把經審批的策略編譯成版本化描述符，由控制面增量分發；閘道用本地令牌桶處理低延遲判定，只有需要全域精度的維度呼叫共用服務。策略帶簽章、TTL、校驗和與回滾版本，按租戶、應用、端點和區域隔離。故障時依端點風險選擇降級，返回穩定的 429 與 RateLimit 資訊，並記錄版本、計數來源和近似狀態。
常見錯誤
- 所有請求都走中心計數器 → 延遲和故障域擴大 → 本地快速判定，按風險選擇全域協調。
- 設定直接覆蓋 → 無法稽核或回滾 → 使用審批、簽章和單調版本。
- 只設定速率不設定突發與並發 → 後端仍會被瞬時壓垮 → 聯動令牌、並發艙壁和佇列。
- 故障時一律放行 → 寫入和計費端點失控 → 按端點風險區分降級。
- 返回模糊錯誤 → 客戶無法調整請求 → 提供穩定狀態、重置時間和可稽核原因。
追問及應對
追問一：為什麼不要求所有維度強一致？
強一致需要共用狀態和網路往返，成本與可用性下降。把強一致留給合約和安全要求高的維度，其餘使用有界誤差並公開誤差模型。
追問二：如何處理跨區域突發？
按區域預分配令牌並設定全域上限；高價值流量可短時借用，但記錄借用量、歸還或結算規則，避免區域獨占。
追問三：策略分發延遲期間誰負責？
閘道繼續使用上一有效版本並標記 stale，控制面監控覆蓋率；超過 TTL 後按端點風險收緊或暫停，不能靜默恢復為無限額度。
追問四：如何證明新策略沒有誤傷？
先用影子評估和歷史流量回放比較拒絕率、延遲和分租戶差異，設定自動門禁，再小範圍灰度並保留一鍵回滾版本。