上周帮朋友排障，他的网关把正常用户拦在外面，后台服务还在慢悠悠跑死循环。
太蠢了？
真不是。
很多人把这套配置当后台点几下的参数填充，根本没停下来想过每个规则背后对应的取舍和代价。
先搞清楚限流到底限的是什么
很多人接手网关的第一反应，是找网上的教程抄个QPS阈值，比如Nginx的limit_req模块填个1000，Spring Cloud Gateway配个令牌桶参数，就觉得流量安全了。错。
限流限的从来不是数字本身，是你能给后端服务留的安全冗余。
你拿压测出来的服务极限值当阈值，相当于给高速路设的限速比车辆的极限速度还高，稍微有个颠簸就直接撞护栏。比如你的订单服务，压测出来单核最大能扛800QPS，你在网关配1000的阈值，纯纯是给后端找事。更别提有的接口是读操作，有的是写操作，写接口的性能可能只有读接口的三分之一，没人做区分，全用同一个阈值拦，不出问题才怪。
麻烦在于，很多团队的压测数据是三个月前的，服务迭代了三版，依赖的数据库索引改了两次，第三方依赖的接口响应慢了200毫秒，还拿老的阈值配，不炸才怪。还有那种用固定窗口算法配的限流，刚好卡在时间窗口的边界，把挤进来的正常请求直接打回，用户点三次付款都报错，客服的咨询量能在五分钟内涨三倍。
这种冤种故障，我见过没有十次也有八次。
没人愿意记。
熔断不是开关，是给后端留的喘息窗口
不少人对熔断的理解有偏差，觉得触发熔断就是把服务整个切掉，给用户返回错误页面。不对。
说白了，熔断触发的瞬间，网关要做的不是把所有请求一刀砍死，是快速返回兜底数据，同时把打给后端的请求量砍到原来的十分之一，让后端能从慢查询、连接池耗尽、线程阻塞的状态里缓过来。
很多人踩的坑是熔断时间设得太短，比如设个5秒，刚把后端的压力降下来，5秒一到又全量把请求放过去，后端直接被打回原形，进入“触发熔断-半开试探-再触发熔断”的死循环。我上次碰到一个创业团队，熔断时间设的3秒，半开状态放10个请求过去，刚好这10个请求都命中了没建索引的慢查询，直接把刚缓过来的数据库连接池占满，循环了四十多分钟，最后还是运维手动把整个服务集群重启才恢复。
还有的人把熔断的判断条件设得特别死板，比如只要接口错误率到5%就触发熔断，根本不拆分错误类型。如果是客户端传参不对导致的400错误，或者是请求路径不对的404错误，这类问题跟后端服务的稳定性半毛钱关系没有，你要是把这类错误算进熔断指标，那随便有人瞎调接口，就能把正常运行的服务给熔断了。
离谱吧？
真有人这么配。
别拿通用模板套所有业务场景
网上随便搜出来的限流熔断配置模板，什么阈值设多少，熔断时间设多久，半开放多少请求，全是放之四海而皆不准的通用内容。你要是原封不动抄到自己的系统里，早晚要出问题。
比如你公司的内部OA系统，总共就一百来个员工用，你给配个每秒限1000请求，跟不限有啥区别？反过来，你面向C端的活动报名接口，峰值流量可能是日常的20倍，你要是按日常的流量水平配阈值，活动一开始就直接把用户拦在外面。还有那种长连接的消息推送接口，你要是按普通HTTP请求的计数逻辑做限流，根本不准——人家一个长连接挂着，半小时推100条消息，你按请求数算的话，一下就超了阈值，直接把正常的推送通道掐断。
这里面从来没有什么最优配置，只有取舍。你配限流规则的时候，是优先保证核心交易链路的资源，还是优先给非核心的推荐、评论接口留带宽？没人能两全，你要是把大部分资源分给非核心接口，到了大促高峰期，付款接口被限流，业务方能追着你骂三条街。
这事没那么玄。不用背一堆令牌桶、漏桶、滑动窗口的算法名词，你把每个接口的实际性能摸透，把不同接口的优先级排清楚，比在配置文件里抄十个复杂参数有用。
上周帮朋友排障的那个项目，最后他把原来统一的阈值全拆了，核心交易链路留了70%的性能冗余，非核心的内容浏览接口限到总带宽的20%，熔断时间从5秒调到了30秒，半开状态只放1%的请求过去观察后端状态。现在跑了快三周，没再出过之前那种把正常用户拦在外面的乌龙。
配置从来不是抄来的。
是踩坑踩出来的。