把API网关从炫技工具用成团队日常搭子

上个月在南京跟朋友吃龙虾，吃到一半他接了个电话，筷子一放就往公司跑。我跟着凑过去看，大促当天的活动流量刚冲上来，API网关直接卡死，三个业务线的请求堵在入口，运维小哥蹲在工位上翻日志，翻到一半发现是三个月前已经下线的测试服务，还挂在网关的路由表里，近三成的请求全被导到了没人维护的测试环境，连个错误返回都没有。

当时整个办公室的空气都僵住了。

最先被搞崩的从来不是写业务的人

很多团队刚搭微服务的时候，总把API网关当成解决所有架构问题的万能补丁。服务拆得七零八落？上网关。鉴权逻辑重复写？上网关。跨服务调用太乱？上网关。

真上了之后才发现，这东西用不好，比没有网关的时候还乱。

我见过最离谱的配置，是一个做本地生活的团队，把用户下单后的积分计算规则直接写在网关的插件代码里。最开始写的时候觉得挺聪明——所有请求都过网关，在这里算积分，不用每个订单服务、活动服务都重复写同样的逻辑。结果呢？积分规则半年改了四版，每改一次就要停网关发版，本来两个开发三天能做完的需求，光等网关排期发版就要耗一周，业务方意见大到能把会议室的门堵上。

更离谱的是后来他们把用户优惠券的核销逻辑也塞了进去，一次配置写错，直接给所有用户的订单多减了20块钱，一晚上亏了小十万。现在想起来都肉疼。

别把网关当第二个业务层用

踩的坑多了大家才反应过来，API网关的能力边界其实特别清楚。

它本质上是整个服务集群的“小区保安”。

你让保安查个来访登记、给临时访客指个路、拦一下没带门禁的陌生人，这都是他该干的事。但你要是让保安帮你查快递、算物业费、甚至帮业主在家带孩子，那不出问题才怪。对吧？你让保安干超出职责的事，效率低不说，还容易出乱子。

说白了，网关该干的事就三类：把请求按规则准确路由到对应的后端服务，在请求进服务之前做统一的拦截校验（比如身份鉴权、IP黑白名单、基础的参数格式校验），把所有跨服务都需要的横切逻辑收上来——比如统一的请求日志、链路追踪埋点、全局限流阈值。

真别把业务逻辑往上搬。之前有个做电商的团队，把商品详情页的多服务数据拼接全放在网关层，前端请求打过来，网关先找商品服务拿基础信息，再找营销服务算优惠券，再找用户服务拉会员等级，拼完一整包数据再返回给前端。听起来挺高效对吧？结果某次营销服务因为日志量太大抖了三秒，整个商品详情页直接全挂，本来只是优惠券模块加载不出来的小问题，直接升级成全站核心链路故障，那天的GMV掉了快两成。

真正用顺了的团队都在偷偷省什么事

我见过把网关用得最爽的团队，是杭州一个做跨境工具的小队伍，总共就8个后端，连专门的运维都没有。

人家的网关从来没装过乱七八糟的插件。

首先路由自动注册根本不用手动配。所有的后端服务启动的时候，会自动把自己的访问路径、版本号、健康检查地址推送到网关上，服务下线的时候，网关会自动把对应的路由条目删掉，根本不会出现那种服务已经删了半个月，网关还傻乎乎往那转请求的蠢事。

然后限流规则也是按服务维度拆的。哪个服务扛不住高并发了，单独给那个服务加个QPS阈值就行，根本不用动其他服务的配置，更不会出现全局限流把所有请求都拦下来的情况——别上来就搞个全局1000QPS的阈值，到时候哪个服务出问题，全链路跟着陪葬。

最让我眼红的是他们的灰度发布流程。新写好的接口上线，根本不用等全量部署，直接在网关上给10%的内部测试账号开个通道，把这部分用户的请求导到新版本的服务上，观察个半天没出问题，再逐步把流量切过去。真出了问题更简单，在网关的控制台点一下，把流量全部切回老版本，半分钟都用不了，根本不用半夜爬起来重启服务。

说真的，我当时跟着他们看了一次完整的发布流程，整个上线过程连五分钟都用不了，对比我之前见过的那些上线要提前一周写预案、发版要停半小时服务的团队，爽到离谱。

当然，用网关的坑永远踩不完。

比如之前有团队在网关上设了个全局的请求体大小限制是1M，结果他们做压缩包上传的接口，要传20M的文件，请求刚到网关就被直接拦下来，开发查了两天后端代码，差点把整个服务拆了重写。

还有的团队网关上的配置从来不用版本管理，谁想改就改，上次改了个路径规则没保存，过了一周想找都找不到。

其实刚上网关的时候真的别贪多。先把最基础的路由跑通，再加鉴权，再加日志，最后再碰限流和灰度。所有的配置规则，必须跟代码一样进Git仓库，做好配置版本管理，每次改动都要走审核流程。

毕竟这东西是整个系统的入口。

入口堵了，后面的服务再强，用户也看不见。