去年618前的周三，我前同事阿凯，在杭州那家做美妆电商的，刚下班啃着卤味准备开黑，群里直接炸了——小程序的商品详情页全是undefined，用户截图刷出来的都是”商品名称”四个字占满半屏。
查了半小时才找到原因：商品组的后端为了加个会员专属价的字段，把原来的goods_name改成了sku_name，连个通知都没发，就合并到生产分支了。那时候前端和小程序的人都在赶别的需求，根本没同步到这个变更，最后拉了个18人的临时会，从晚上8点改到凌晨2点，把所有调用了商品接口的地方都补了字段映射。
谁懂啊，这种锅真的甩都甩不掉。
谁都不想当接口变更的背锅侠
扯起因的时候更闹心。商品组说自己只是加了个字段，没改原有逻辑，不算 breaking change。前端说接口字段名变了，等于所有调用方都要跟着改，凭什么不提前通知？最后扯了俩小时，还是前端自己默默把所有地方的字段名都改了，连个加班费都没捞着。
我见过太多团队，接口对接全靠微信群喊，喊到最后谁都记不住哪个接口改了啥，出了问题全靠翻几百页的聊天记录找责任人。服务少的时候还好，等你拆到十几个服务，对接了好几个第三方合作方，这种问题会像定时炸弹一样，指不定哪天就炸在大促或者上线的节骨眼上。
API网关不是只做转发的传声筒
很多人对API网关的认知还停留在”就是个高级nginx，帮我把请求转到对应的后端服务”。真不是。
要是阿凯他们早半年把API网关搭起来，那天的事10分钟就能搞定。网关的第一个核心作用，就是做统一的字段适配层。商品组改了字段名？直接在网关里加一条映射规则，把上游传过来的sku_name自动映射回原来的goods_name，所有下游的调用方——不管是前端、小程序还是第三方合作方——都感知不到这个变更，根本不用改任何业务代码。
除此之外，网关还能把所有服务都要复用的通用能力都收上来。比如鉴权，原来每个后端服务都要写一遍token校验的代码，现在网关统一校验，没带有效token的请求直接拦在外面，后端连日志都收不到。比如限流，去年他们大促的时候，优惠券接口被人恶意刷，直接在网关层加个规则，同一个IP每分钟最多调10次，恶意请求直接被拦，后端服务连压力都没有。
说白了，原来这些散落在各个服务里的重复逻辑，现在都收到网关这一个地方管，改一次所有服务都生效，根本不用挨个通知。
别一上来就堆最贵的方案
不过话说回来，也别一听API网关就觉得要上最复杂的开源方案。我见过一个10人的本地家政创业团队，总共就3个后端服务，上来就折腾APISIX集群，还搭了三节点的etcd，运维天天怕集群崩，最后只用了个路由功能，连个自定义插件都没写，纯纯浪费人力。
真没必要。刚起步的小团队，服务少于5个的，直接用nginx加Lua脚本就能搞定基础的网关能力，路由、简单的字段映射、token校验都能做，成本几乎为零。等你服务拆到15个以上，跨团队对接的需求多到天天要改适配了，再上成熟的开源方案，比如Kong或者APISIX，完全来得及。
还有个坑千万别踩：别把业务逻辑塞到网关里。什么订单计算、用户积分抵扣，这些跟具体业务绑定的逻辑，绝对不能放网关。网关就管所有服务都要用到的通用能力，要是把业务逻辑塞进去，后面改一次需求就要全量回归所有服务，反而把问题搞复杂了。我之前帮那个家政团队调网关的时候，他们原来写了个专门的第三方适配接口，用来转字段，后来直接在网关里加了一行映射规则，那个适配接口直接下线了，省了后端每次改字段都要动适配代码的功夫。
前阵子我去那家美妆电商做复盘，他们现在已经把所有跨服务的接口都迁到网关后面了。上次商品组改了个接口字段，直接在网关里加了条映射，前端连知道都不用知道，大促的时候也没再出过接口适配的问题。
说白了，技术工具从来都不是为了炫技的。要是能少熬几个夜，少背几个莫名其妙的锅，那这网关就没白搭。