上周陪朋友去软件大道那边的创业公司排障，刚进门就看到运维小哥盯着监控屏冒冷汗——生鲜大促的流量刚冲起来，整个站点全挂了。查了半小时才发现，扛了所有流量的API网关，CPU直接干到98%。
说真的，当时看到他们网关里塞的那些插件，我人都傻了。光一个计算用户当日累计下单金额的逻辑，就写了两百多行代码跑在网关插件里，每次请求进来都要实时查三次Redis算金额，不卡才怪。
当初为什么要上API网关
最早他们没网关的时候，前端要对接十几个后端服务，用户登录、商品列表、库存、配送员位置，每个服务的鉴权逻辑都写得乱七八糟，前端光写请求拦截就改了三版，还有跨域问题，每次后端加个新接口，前端要改代码发版，运营那边上活动要调接口，还要找开发开权限，乱成一锅粥。
后来听隔壁同园区的团队说上API网关能统一管，就直接照着文档搭了一套。一开始确实爽，所有请求先打到网关，跨域、鉴权、限流都在可视化界面配，前端不用改啥，后端也不用重复写鉴权代码，上线效率一下提了不少。
那段时间团队还专门开了个庆功会，说选对了中间件，后面的业务扩张肯定能顺风顺水。
塞得太满的网关迟早要炸
问题出在业务跑了半年之后。大家发现网关既然能跑自定义插件，什么杂事都想往上面堆：日志上报要在网关层做，参数校验要在网关层做，甚至那个给用户发满减优惠券的规则计算，也直接写进了网关插件里。更离谱的是，他们把第三方支付的回调地址也直接挂在网关后面，连静态资源的缓存都丢给网关处理。
网关不是垃圾桶。
API网关的核心定位是流量的统一入口，只做最通用、最无业务属性的流量治理工作。统一鉴权、路由转发、基础IP限流、跨域处理，这些是它的本职工作，但凡带点业务逻辑的内容，比如优惠券计算、订单金额校验、用户标签匹配，根本就不该放在网关层。不然哪天网关的插件逻辑出bug，后面所有的业务服务连请求都收不到，全链路直接瘫痪，连兜底的机会都没有。
上次出故障就是因为改优惠券插件的逻辑，没测全分支，上线之后只要是带满减参数的请求，全在网关层抛了异常，后面的订单服务根本收不到请求。本来后端服务扛个几万QPS完全没问题，结果网关自己先被复杂的插件逻辑拖垮了。
真要落地别踩这些隐形的坑
帮他们排查完问题之后，我给列了几个最基本的调整规则，都是踩过无数坑攒出来的经验。首先是给网关的插件逻辑划死边界，所有插件的执行逻辑必须保证毫秒级返回，绝对不能塞复杂的业务计算，比如要做用户标签匹配，网关只需要在鉴权通过后把用户ID透传到请求头里，后面的业务服务自己去查标签库就行，别在网关里实时跑查询逻辑。
然后是限流规则要和后端服务的实际承载能力匹配，别为了显得安全就把网关的限流阈值配得特别高，上次他们给商品详情接口配的限流是2000QPS，结果后面扛这个接口的服务最多只能扛300QPS，就算网关没限住，流量打过去照样把后端打崩。
还有个很多人忽略的点，别把内部服务的调用链路也绕到公网入口的网关上。内部服务之间的调用走自己的内网专线就行，没必要把所有流量都绕到对外的网关里，平白多了好几个故障节点。就像他们之前把内部的库存同步接口也挂在网关后面，上次网关出故障的时候，连内部的库存同步都断了，仓库的配送员半天看不到最新的库存数，耽误了好几个订单的配送。
上周跟进的时候，他们已经把网关里的业务逻辑全拆出去了，大促剩下的三天，网关的CPU稳定在30%左右，再也没出过告警。其实技术选型从来没有什么万能方案，API网关是个好用的工具，但你要是给它塞太多不属于它的活，它迟早会给你甩脸子。
对吧。