上周跟南京做社区团购的老周吃鸭血粉丝。
他把筷子往碗上一搁，说去年618团队熬了三个通宵压测，所有服务的扩容预案都做满，结果开场十分钟，App直接弹”网络错误”。
查了快四个小时，最后发现是API网关的IP白名单配错了——把新上的CDN出口段漏了，所有用户请求刚到网关就被当异常流量拦了。
你给网关塞了多少不该它干的活
很多团队刚上微服务的时候，上来就把所有杂活都往网关切：鉴权、限流、日志、参数校验、协议转换、甚至业务侧的用户等级判断——比如给VIP用户跳专属的后端服务集群。
说实话，我见过最离谱的配置，是把满屏的if判断写在网关的插件里，什么”用户昵称带‘测试’两个字就跳内网环境”，这种代码写在网关层，谁改谁懵。
问题从来不是网关能力不够。
真的。
是我们总忍不住给它加戏。
网关本来的定位是什么？是流量的门卫，不是跑业务逻辑的临时仓库。你把太多业务逻辑塞进去，每次改个规则都要重启网关集群，万一配置写错，就是全链路的故障——就像老周那次，本来只是想加个防刷规则，手滑把白名单的IP段删了一段，直接把正常流量全挡了。
我之前还见过一个团队，把用户的积分计算逻辑写在网关里，每次用户请求过来，网关要先去查用户的积分余额，算完等级再把请求转发给后端，结果一次数据库连接池打满，所有请求全卡在网关层，连首页的静态资源都刷不出来。
想想都气。
冤不冤？
别拿大厂的网关配置往自己身上套
总有人刷到阿里、腾讯的技术博客，说他们的网关能扛百万级QPS，转头就照着抄配置往自己的集群上堆。
真的，别这么干。
大厂的网关背后是专门的团队7*24小时盯着，配置变更走三个人交叉审批，出问题五分钟就能精准回滚。你一个十几个人的小团队，运维兼着开发，产品提需求说”要给新用户加个弹窗提示”，你直接把弹窗判断的逻辑写在网关的响应插件里，哪天插件版本更新，弹窗弹错了，用户投诉到客服，你都不知道去哪查日志。
这里其实有个很容易被忽略的边界：所有跟流量入口强相关的通用能力，才是网关该承接的范围。比如基础鉴权、全局限流、HTTPS卸载、协议转换、统一的错误码返回，这些是放对地方的。那什么不该放？所有跟业务逻辑强绑定的判断，比如”用户满18岁才能访问成人内容””订单满200块才能跳专属物流通道”，这些必须沉到对应的业务服务里去。
你要是把业务判断全堆在网关，相当于把小区的保安拉去当财务，不仅干不好，哪天保安临时有事，整个小区的门都没人守。
落地的时候别上来就搞大而全
很多团队刚决定上API网关，就想着一步到位，把所有能想到的功能全配上，结果配置越堆越乱，最后没人敢碰，成了个黑盒子。
其实最稳妥的节奏，是先把核心功能跑通，再一点点加能力。
第一步，先把统一入口、HTTPS配置这些最基础的流量转发功能跑稳，跑个一两周，确认没有乱转发、丢请求的问题，就算过了第一关。第二步，等流量稳定了，再加全局限流规则，防止突发流量把后端服务冲垮。第三步，再把之前散落在各个服务里的重复鉴权逻辑抽出来，放到网关层，减少重复代码。
别着急。
真的，你要是第一天就把所有功能全配上，出了问题你都不知道是哪块配置出的错。我见过太多团队，网关刚上线就把日志采集、流量染色、灰度发布、用户画像全配上，结果光配置项就写了几百行，稍微改个参数就要测试半天，最后反而拖慢了整个迭代的节奏。
对了，监控的事千万别忘。
网关是所有流量的必经之路，你必须盯着几个核心指标：网关层的请求成功率、平均响应时间、被限流拦截的请求量。上次老周那次故障，要是他的网关能在拦截量突增10倍的时候自动给运维发告警，根本不会等用户投诉了才去查。
其实API网关这东西，从来不是什么架构升级的炫技道具。
它就是个入口的收费站。
你别让收费站的工作人员顺便帮你查快递、帮你算税费、帮你给车做保养——人家就是负责抬杆、收费、把车引导到对应的车道，干好这几件事，就够了，对吧？
你要是给它塞太多活，哪天收费站的工作人员撂挑子，整条高速就全堵死了。