一、项目背景

网关早期用固定阈值限流，结果两头不讨好。有的调用方一到活动就突发刷屏，把整批算力打满，其他正常业务被拖垮；有的调用方日常高峰本来就该多跑，却被固定阈值误伤。配额还靠人工在后台配，超了才发现，临时扩容手忙脚乱。算力像一块公共地，谁猛冲谁占便宜，守规矩的反吃亏。那次大促，一个营销调用方瞬间打了八倍流量，客服实时链路 P99 直接飙红，被投诉了一整晚。

我们复盘时发现，固定阈值本质上是用"某一瞬"去卡"一整段"，既挡不住短时突发，又错杀正常波动。要治这个，得换个看流量的尺子，还得给守规矩的调用方留点弹性，不然大家都不想当那个被限的。

二、落地场景

我们换成了滑动窗口限流，不再看固定时刻的瞬时值，而是看一小段时间内的平均流量，尖峰被平滑掉。突发配额给每个调用方留了弹性空间，平时按基线，活动期可临时借用额度。配额分配和预警做到位，快到上限就提醒，超限的走降级或排队而不是硬拒。限流看板让每个调用方都能看到自己的水位，吵架的少了，谁超了谁自己先看见。

为了让配额合理，我们按调用方的历史基线自动给默认值，活动前可申请临时上调，审批走管控台。超限降级也分层，轻微超限先排队，严重超限才拒，体验比一刀切好太多。

三、关键技术挑战与解决思路

窗口粒度是最难调的。太短，流量一抖就限，误伤正常请求；太长，真来了突发又反应慢，该挡没挡住。我们按业务特性分了档，对延迟敏感的用短窗口快速反应，对批处理用长窗口平滑。突发配额的借用也要有度，借了不还其他调用方就饿着，我们设了借用上限和归还窗口，超时强制回收。

超限降级不能简单扔错误，能排队就排队，排不下再拒，体验好很多。配额预警要提前，等超了再通知，扩容永远慢半拍。我们踩过一个坑：最早预警设在超限那一刻，调用方收到时已经晚了，后来改成到达上限的八成就开始提醒，扩容易多了。

案例片段（已脱敏）： 滑动窗口限流与突发配额的核心配置如下：yaml ratelimit:  algorithm: sliding_window  window:    sensitive: 5s       # 敏感业务短窗口    batch: 60s          # 批处理长窗口 burst_quota:  borrow_cap: 1.5       # 最多借用基线1.5倍  repay_window: 30s     # 30秒内归还 action_on_exceed: queue # 先排队，排不下再拒某活动调用方突发 8 倍流量，滑动窗口将其削平，未影响其他业务 P99，借用额度在窗口内正常归还。

配额的自助申请我们也做通了。调用方在管控台提交临时上调，写明活动时段和预估增量，审批走轻量流程，分钟级就能生效。早期配额全靠运维手动改，活动前排着队等，现在调用方自己能预见、能申请，运维从救火配额度变成审一眼。治理的最高境界大概就是这样，把规则交给该操心的人，平台只兜底异常。

四、效果数据

限流误伤率从固定阈值时期的约百分之九，降到百分之二以内，正常高峰不再被错杀。突发吸收率提升到九成以上，活动期那波尖峰被平滑承接，其他业务 P99 几乎没波动。配额利用率从之前忙闲两极，变成稳定在八成左右，资源不再被少数调用方占死。超限次数下降约七成，且基本都走了排队而非硬拒，调用方感知友好很多。那次大促的客服链路，这次稳稳扛住了，再没人半夜被叫起来。

五、可复用经验总结

网关限流不能只设一个死阈值，滑动窗口加突发配额是更贴近真实流量的做法，尖峰被削平，该放过的放过。窗口粒度必须按业务分档，敏感和批处理用同一套窗口，怎么调都是错，这点我们调了很久才认。突发借用要有上限和归还机制，不然公共算力变成谁狠谁占，守规矩的反而吃亏，借用不还可能比不借更糟。超限先排队后拒绝，体验差别很大，别图省事直接甩错误。讲句实话，限流的本质是保护多数人，规则设计得让"守规矩的"不吃亏，系统才稳得住，大家才服气。

容量规划也因此有了抓手。每个调用方的历史水位和突发弹性都看得见，我们做季度扩容不再拍脑袋，而是按峰值借用量和借用频率算，该加的加、该收的收，整体算力利用率比之前高了十几个点。限流治的是眼前，数据沉淀治的是长远。

限流的误报我们专门跟踪过，早期窗口粒度没调好时，误伤主要集中在活动开头的瞬时抖动，后来把敏感业务的窗口从三秒提到五秒，这类误伤基本消失。治理参数没有终点，得跟着业务的真实波形持续微调，这也是为什么我们把所有限流指标都接到了长期曲线上看。

结语

后来我们把配额预警接到了调用方的自助后台，快到顶了自己就去申请扩容，工单量反而降了。让人看见自己的水位，比在背后限他更有效，治理这件事，透明往往比强制省力。