API网关限流与熔断配置 没人提前说的落地细节

上周跟三个做后端的朋友撸串，俩刚因为线上网关配置背了通报。一个把限流阈值设高了，大促的时候把下游服务直接打挂，连带支付接口卡了四十分钟。另一个更冤，熔断阈值设到了0.1秒，正常的网络抖动就触发熔断，用户刷付款码连续失败三次，直接在门店拍了短视频骂。

这事没那么玄。很多人拿着官方文档抄配置，根本没算自己的服务实际能扛多少。限流不是设个数字就完事，是要把你所有下游服务的承压能力拆到每一个接口上的。

说白了，你订单服务总共能扛每秒一千次请求，那你给订单查询、创建、取消三个接口分的限流额度加起来，绝对不能超过九百，留一百的冗余给突发的重试流量。很多人图省事，直接给整个路由设个一千的阈值，结果某一个接口被爬虫爬的时候，把剩下两个正常接口的额度也占了。

限流阈值到底怎么定才不拍脑袋

麻烦在于，没有通用公式。你要是拿网上给的什么“每秒多少请求”的模板套，迟早出问题。我见过最稳的一个团队，定限流阈值之前，先把所有接口压测了三遍——不是压测网关本身，是压测网关后面挂的每一个服务实例，拿到每个实例的最大QPS，乘以实例数，再打个七折，就是这个路由的全局限流值。所有的限流配置，都不能超过后端服务的真实承压能力，超了就是拿生产环境当试验场。

还有个容易被忽略的点，就是限流的粒度。很多人只在全局路由设限流，根本不管单个用户、单个IP的维度。去年有个做电商的朋友跟我说，他们大促的时候有个黄牛脚本用一千个账号刷优惠券，全局限流明明设的是每秒两千，但是一千个账号每个每秒发两次请求，直接把优惠券服务打挂了。后来加了单用户每秒最多两次请求的限流，才把这个口子堵上。别觉得加细粒度限流会增加网关的性能消耗，现在主流的网关，不管是Nginx还是APISIX，单节点扛十万级别的细粒度限流匹配完全没压力，你要是因为怕耗性能不加，等出了故障的代价比这点性能消耗高一百倍。

熔断不是为了把用户请求拦在外面

很多人对熔断的理解错了。觉得熔断就是只要下游超时就直接给用户返回错误，省得占着网关的连接资源。不对。熔断的本质是给正在出问题的下游服务留恢复的时间，不是为了甩锅。

比如你下游的一个服务因为GC停顿卡了两秒，这时候你要是设的熔断规则是连续三次超时就直接熔断三十秒，那这三十秒里所有打到这个服务的请求都直接返回失败，用户什么都干不了。但实际上可能那个服务停顿个五秒就自己恢复了，你直接熔断三十秒，平白无故把故障时间拉长了五倍。熔断的触发阈值，一定要和你服务的实际容错能力匹配，不是越严越好。比如你的服务平时正常响应时间是50毫秒，P99是200毫秒，那你把熔断的超时阈值设成500毫秒就够了，别设成100毫秒——那点正常的网络抖动都能把你触发熔断。还有熔断的时长，别一上来就设三十秒，先设五秒，等熔断打开之后，放百分之五的请求进去探活，要是这些探活的请求能正常返回，就慢慢把流量放回去，别等时间到了一下子全放开，那很容易把刚恢复的服务又打挂。

之前有个团队把熔断的探活比例设成了百分之百，就是熔断时间到了直接把全部流量打回去，结果服务刚从GC停顿里缓过来，本来CPU就还有点高，一下子所有请求涌进来，直接触发OOM重启，又卡了两分钟。说白了，熔断的整套逻辑，是个动态的保护机制，不是个写死的开关。

配置完不做演练等于白配

你配置再好，不上故障演练测一遍，到线上出问题的时候根本不知道会不会生效。我见过太多团队，把限流熔断的规则写在配置文件里，上线之后就再也没碰过，结果大促的时候真的流量超了，才发现规则根本没加载上——之前改配置的时候把规则的缩进搞错了，网关启动的时候直接跳过了这段配置，日志里打了个warning，没人看。

还有更离谱的，有人配限流的时候，把规则绑定到了测试环境的路由上，生产环境的路由根本没加，出问题的时候翻了半小时配置才找到原因。所有的限流和熔断配置，上线之前必须在预发环境模拟一次触发场景，确认规则真的能拦住不该过的流量。别觉得这是浪费时间，你花十分钟测一次，可能能省下来线上故障排查的几个小时。

还有个细节，很多人配完限流之后，没把限流触发的告警接进来。就是真的触发限流了，系统自己安安静静把请求拒了，连个告警都不发，等用户打电话来投诉，才知道已经拦了几千个请求了。你想想，要是你某个接口突然被刷，限流触发了，你至少得有个告警告诉运维，这个接口的请求量突然上来了，得赶紧看是不是有异常流量，不然光靠限流拦着，根本不知道后面发生了什么。

说实话，这些事没有什么高大上的技术，都是踩过坑才攒出来的经验。别拿着网上的最佳实践直接往生产上搬，每个团队的服务承压能力不一样，业务场景不一样，配置自然也不一样。你要是真的把限流熔断的逻辑摸透了，就会发现这俩东西本质上就是给你的系统加个安全气囊——不是为了让你开快车，是真的撞的时候，能少受点伤。