网关限流配置翻车实录，固定窗口算法致200请求瞬时冲击，AI服务雪崩始末

某SaaS客服系统在一次大促活动中遭遇严重服务中断，网关面板显示请求速率（RPM）始终未超设定阈值，但下游AI模型供应商持续返回429错误，大量用户咨询失败，客服群内投诉刷屏。事后排查发现，问题根源并非流量突增本身，而是网关限流策略存在三重设计缺陷——其中最致命的是对固定窗口算法边界的误判。

该系统为每个租户配置了「每60秒100请求」的固定窗口限流规则，表面看相当于1.7 QPS，日常负载下运行平稳。然而大促开启瞬间，流量陡增十倍，网关在时间窗口切换点（如第59.9秒与60.1秒）分别放行满额100请求，两批请求在0.2秒内集中抵达下游，形成200请求的瞬时洪峰。而理论允许峰值仅为100/60秒，即约1.7 QPS。这种「边界放大效应」是固定窗口算法固有缺陷：它仅在窗口结束时清零计数器，无法平滑过渡，导致周期性尖峰。

图中清晰呈现四类主流限流算法特性。固定窗口虽实现简单、内存恒定（O(1)），但允许突发量达理论值2倍，精度低，且不适用于高并发或脆弱下游场景；滑动窗口日志精度最高，但内存随请求数线性增长（O(n)），不适合高吞吐网关；滑动窗口计数器为折中方案；而令牌桶（Token Bucket）允许突发至桶容量后按速率补充，既接纳合理突发（如促销开门流量），又保障长期速率稳定——Anthropic官方明确推荐其用于API网关层。漏桶则彻底削峰，适合写库等绝对不可抖动的链路。

对于AI网关而言，令牌桶通常是更优解。它承认现实中的流量脉冲（例如用户点击“发送”后批量发起请求），同时通过速率限制防止下游被瞬间压垮。若该SaaS系统采用令牌桶并设桶容量为100、填充速率为100/60s，则即使突发100请求，后续也会被平滑延后处理，避免200请求齐发的灾难。

第二重失误在于流式响应的准入时机。大模型接口普遍采用SSE（Server-Sent Events）流式输出，前端边接收token边渲染。该系统将限流判断置于首个token发出之后——即「先发后掐」模式。当预算超限时，已向客户端发送数千字节的半截JSON流，前端解析失败直接白屏，而网关日志仅记录429，无法还原真实故障路径。

正确做法应为「先准入后发」：在第一个token生成前完成配额校验，超限则立即返回429，不发送任何数据。此时前端收到标准错误，可触发降级逻辑（如提示“请求繁忙，请稍后重试”），用户体验可控，运维可观测。

第三重认知偏差是将限流简化为单一维度的请求计数（RPM）。AI服务的实际资源消耗由三要素共同决定：请求次数（RPM）、token总量（TPM）、并发连接数。

一个典型反例：网关仅限制RPM≤100/min，放行了一个50,000 token的长文档摘要请求与多个100 token的常规问答。两者在网关层面均视为“1个请求”，全部通过。但下游供应商按TPM配额计费与限流，单个50k token请求瞬间耗尽当日token额度，其余请求全被拒，雪崩由此触发——故障点不在网关，而在下游的token预算被无声耗尽。

此外，并发连接数常被忽视。流式API连接会长期占用后端连接池，若10个租户各维持50个长连接，总计500并发，极易击穿模型供应商的连接上限。OpenAI虽未显式暴露并发限制，但其RPM与平均延迟隐式约束了并发；Anthropic则明确分层定义RPM、TPM与并发上限。网关层必须主动实施三层限流，不能依赖下游兜底。

行业实践表明，成熟AI网关需构建多级防护体系：

• 第一层：RPM限流——按租户/应用维度控制请求频次，推荐令牌桶算法；
• 第二层：TPM限流——预估或实时统计请求token量，动态扣减配额，避免单请求耗尽全局额度；
• 第三层：并发限流——限制同时活跃的流连接数，防止连接池溢出；
• 第四层：熔断与降级——当下游返回连续429或超时，自动触发短时熔断，避免无效重试加剧拥塞。

值得注意的是，部分团队试图通过NAT网关设置带宽上限来规避风险，但这属于网络层防护，无法解决应用层的语义级过载问题。带宽限制可防DDoS式流量洪泛，却无法阻止合法但高消耗的AI请求（如单次上传10MB上下文）打穿模型服务。真正的防护必须深入到API语义层。

此次事件最终以紧急回滚配置、临时扩容下游配额收场，但暴露的问题具有普遍性。据多位云原生架构师反馈，中小SaaS厂商在接入大模型API时，70%以上初期仅配置RPM限流，30%仍使用固定窗口算法。随着企业级AI应用普及，网关不再只是流量转发器，而成为服务质量的第一道闸门。

限流不是拍个数字贴上去就完事，它是对业务流量模式、下游服务能力与协议特性的综合建模。一次配置失误，可能让整个租户生态陷入连锁故障。技术细节的疏忽，往往在高并发时刻才显露代价。