上周跟某支付团队的运维聊到凌晨三点，就为了线上大促时网关的502报错。查了半天才发现，限流阈值设错了不说，熔断的半开探测逻辑还没开。说白了，大部分团队的API网关限流与熔断配置，都是照着官方文档抄完就上线，根本没摸过自己的流量底。
别上来就抄官方的阈值
很多人配限流的第一步，就是翻网关的官方文档，看到示例里写着单接口QPS 1000，直接抄过来就用。根本不管自己后端服务的实际承载能力。
限流阈值的核心不是拍脑袋定数字，而是测出来的后端服务单实例最大稳定QPS。
之前见过电商团队把商品详情接口的限流设到单实例200QPS，结果后端的商品聚合查询每次要调3个下游，实际单实例扛到120就开始超时，大促时直接把下游打挂。还有人只按IP做限流维度，内部服务的出口IP都是同一个，上次某团队把内部调用的限流设成单IP 100QPS，结果所有内部服务的调用全被拦了，业务直接停了半小时。
麻烦在于，很多人连自己用的网关默认是哪种限流算法都不知道。Spring Cloud Gateway默认的令牌桶，和Nginx的漏桶，适用场景完全不一样。
令牌桶适合应对突发流量，漏桶适合把请求匀成稳定速率打给后端。
做活动的时候，瞬时流量突增，用漏桶的话直接把请求拦在网关，用户点半天没反应，体验差；但要是后端是那种扛不住突发的老服务，用令牌桶又会把后端冲垮。没有万能的算法，只有适合当前业务的选择。
别光盯着核心接口做限流。那些冷门的、没人注意的接口，比如后台的导出接口、爬虫常爬的内容详情接口，往往是最容易把网关打挂的地方。你以为你设的1000QPS阈值是安全的，实际上当某个突发的爬虫流量直接打到你的某个冷门接口上，哪怕这个接口的QPS只有100，也可能把整个网关的连接池占满，导致其他核心接口全部超时。
熔断不是等服务挂了才开
踩过的最大的坑，就是把熔断当成了“后端挂了之后的兜底”。
之前遇到过，某个优惠计算接口因为下游优惠券服务超时，本来网关只要连续10次超时就触发熔断，结果配置的时候把阈值设成了100次，等触发的时候，网关的线程已经全被打满，连登录接口都跟着挂了。
熔断的核心作用是及时止损，而不是等故障扩散到整个系统。
很多人配熔断的时候，只关注触发条件，完全不管半开状态的配置。把半开的探测时间设成30秒，甚至直接关了，结果熔断之后一直不恢复，哪怕下游已经修好了，还是一直返回降级页，用户骂了半天才发现配置错了。
还有的团队配完熔断，降级返回直接写个“系统繁忙”。但其实关键接口的降级要返回兜底数据，比如商品详情的库存接口挂了，降级返回“暂时无法查询库存，请稍后再试”甚至返回预估库存，总比直接给用户看报错强。
限流和熔断完全不是一回事。别拿限流当熔断用，也别拿熔断当限流用。限流是在入口就把超出能力的请求挡掉，减少后端的压力；熔断是当后端已经出问题的时候，快速切断请求，不让故障蔓延。两者是配合的，不是替代的。
配置完别直接跑线上
这事没那么玄。API网关限流与熔断配置完，不做混沌演练，等于白配。
之前见过团队配完限流，直接把阈值设成100，结果内部测试的时候，自己团队的监控脚本每秒发200个请求，直接把网关拦了，监控全断了，出问题都没人发现。
所有的限流熔断规则，上线前必须经过流量回放和故障注入测试。
用压测工具往网关注入突发流量，看限流是不是真的生效，会不会把正常的请求也拦了；然后故意把下游服务搞挂，看熔断是不是能在预期时间内触发，半开探测是不是能正常恢复。
说实话，我见过不少团队的网关配置全是乱的，同一个接口，在网关设了一层限流，在应用里又设了一层限流，阈值还不一样，最后线上出问题了，查半天不知道是哪层拦的。
还有人把规则全写在配置文件里，没有版本管理，改的时候直接在生产环境改，改完也不记录，过半个月出了问题，连当初是谁改的、为什么改都不知道。
别偷懒。
很多线上的大故障，追根溯源都是当初随手写的几行配置，没人管，没人测，最后攒成了大事故。你花十分钟好好测一下限流熔断的规则，可能就省得后面花三天三夜排线上故障。