题干与适用场景
平台有数百个网关实例和多个区域。产品团队希望按租户、应用、端点和计费套餐设置每秒请求数、并发数和每日额度，策略更新要在分钟内生效。系统必须避免单个租户占满资源，同时在配额服务短暂故障时保留核心 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 后按端点风险收紧或暂停，不能静默恢复为无限额度。
追问四：如何证明新策略没有误伤？
先用影子评估和历史流量回放比较拒绝率、延迟和分租户差异，设置自动门禁，再小范围灰度并保留一键回滚版本。