API网关限流与熔断配置落地真实经验

上周跟一个做支付系统的朋友吃饭，他刚因为线上突发故障熬了三个通宵。问题说起来不复杂——大促流量压过来的时候，网关没拦住，下游核心交易线程池直接打满，连锁反应拖垮了三个关联服务。

限流阈值从来不是拍脑袋定的数

很多团队配限流的第一步，就是去网上抄别人的参数。看到某大厂的网关配置写着单路由1200QPS，自己也跟着填一样的数，根本不管自己下游服务的实际承载能力。限流的本质是给系统装一道安全阀，阈值设低了，正常用户被拦，客诉能把客服邮箱塞爆；设高了，等于这道阀根本没装。

我见过最离谱的配置，是把网关的限流阈值设到跟服务器网卡带宽上限齐平，完全跳过了下游服务的处理能力评估。之前帮一个团队做压测，单实例的订单查询服务满负载也就扛300QPS，结果网关上直接给这个路由配了1500QPS的上限。流量刚爬到800的时候，服务的响应时间已经从200ms飘到了3s，熔断还没触发，请求已经在网关的等待队列里堆成了山。

真的。这种配置等于你在小区门口装了个限高杆，杆的高度比消防车还高，真出事的时候根本挡不住闯进来的大货车。

熔断触发的时机比规则本身重要

不少团队配熔断，就是照着开源组件的默认参数填。比如Sentinel默认的慢调用比例阈值50%，熔断时长10s，连改都不改，直接往生产环境推。要知道默认参数是给通用场景设计的，根本适配不了你家的业务特性。

比如核心交易接口，平时的平均响应时间是100ms，你把慢调用的判定阈值设成500ms，那超过500ms的请求本来就是已经卡得没法用了。等50%的请求都慢到这个程度才触发熔断，其实已经晚了。熔断是要在服务还没完全挂、响应已经开始劣化的时候就切断请求，给下游留够恢复的时间，不是等整个服务瘫了才反应。

之前遇到过一个做内容推荐的团队，他们的推荐服务依赖下游的用户画像接口。一开始把熔断规则配成异常比例超过30%才触发，结果下游画像接口因为JVM长时间GC停顿，连续3次请求超时，推荐服务的线程直接被占满，连正常的健康检查请求都响应不了，整个服务直接挂死。后来改了规则，只要连续5次请求的响应时间超过200ms，就直接熔断15s，给下游留够GC的时间，之后再也没出现过连锁挂死的情况。

别把限流和熔断的职责搞混了

好多人配着配着就糊涂了，觉得限流和熔断是一回事。其实完全是两码事。限流是提前设防，在入口处拦着多余的流量，不让你进到系统内部；熔断是事后止损，在系统内部已经出问题的时候，暂时切断有问题的调用链路，不让故障扩散。

我见过最乌龙的配置，是把熔断的逻辑直接放到了网关层。本来应该是服务内部根据自身状态触发的熔断，结果网关直接把所有到这个服务的流量全拦了，哪怕服务其实已经恢复了，网关还在按之前的熔断规则拦，平白丢了好多流量。

还有的团队，在网关层配了限流，下游服务自己也配了一模一样的限流，结果两层限流叠加，实际能过去的流量比预期少了一半。运营在后台看转化率掉了，查了半天都没找到原因。有个做电商的朋友，去年大促的时候就是因为这个问题，本来准备了1000QPS的承载能力，实际只放过去了300QPS，前面的用户排队排了十分钟都进不来，差点把活动搞砸。

不过话说回来，好多人觉得限流熔断就是网关控制台里点几下鼠标的事，真不是。配完规则根本不做验证的团队太多了。规则写在配置中心里，看着逻辑都对，结果真到上线的时候才发现，路由匹配规则写错了，之前配的限流规则根本没匹配上对应的流量。

这事没那么玄。你配完规则，自己拿个压测脚本打个1分钟，看看是不是到阈值就返回限流提示，是不是熔断触发之后就走降级逻辑，比你在会议室里讨论两小时参数有用得多。

上次跟那个熬了三个通宵的朋友复盘，他说之前总觉得网关的限流熔断配置是运维的事，开发写完接口就可以撒手不管。现在才知道，规则配错了，比没配还坑。毕竟线上故障从来不会因为你参数写得好看就绕开你。