那天凌晨三点的电话，我这辈子都忘不掉。
朋友所在的电商团队，赶在双11前两周仓促上了API网关，把所有业务接口的入口全收上来。上线当天确实顺，之前散在各个服务里的重复鉴权代码删了大半，开发群里一片欢呼。结果大促前三天的压测环节，某个负责优惠券计算的服务写错了限流阈值，每秒100的请求额度直接被压测流量打满，更要命的是网关没有做单服务的熔断，所有打过来的请求全在网关上排队，十分钟不到，整个站点的正常用户访问全卡成了加载圈。
朋友在电话里的声音哑得像砂纸磨过，说之前总觉得上了网关就万事大吉，没想到第一个大故障就是网关搞出来的。
别把API网关当流量垃圾桶
说真的，我见过太多团队走一模一样的弯路。刚接触API网关的时候，谁不被它统一入口的魅力打动？所有进来的流量先过一道，鉴权、路由、日志、限流，全在这一层处理完，后面的业务服务只管专心写业务逻辑就行，多爽。
但爽过头了就是坑。
有个做在线教育的客户，当初上了网关之后，干脆把所有课程的静态视频切片、用户上传的课件文件，全让网关做鉴权后直接转发。平时几百QPS的时候啥事没有，开学季流量一冲，网关的CPU直接干到100%，整个站点连登录页都刷不出来，运营在大群里@技术负责人的消息刷了几百条，谁看谁头大。
网关的核心定位是“薄代理”，不是全能业务容器。它该干的事其实很明确：把流量按规则路由到对应的后端服务、做统一的身份校验、按预设规则做基础的流量控制、完成不同协议的转换。那些和流量调度没关系的重逻辑——比如静态资源转发、用户行为画像计算、甚至复杂的业务规则判断，真的别往上堆。堆得越多，网关的性能损耗越大，最后本来用来提效的组件，反而成了整个系统最脆弱的单点。
很多人对“薄”的尺度没概念。这么说吧，你要是在网关层加的逻辑，处理单请求的耗时超过了1ms，就得停下来想想，这玩意是不是放错位置了。网关的请求转发链路本来就短，多一毫秒的处理时间，乘以每秒上万的QPS，累积起来的延迟感，用户是能实实在在感受到的。
踩过的坑比写过的配置多
帮十几个团队做过API网关的落地改造，我踩过的坑，比我当时写过的配置文件都多。
最常见的就是限流粒度错配。很多团队一开始搭网关，图省事直接配全局限流——比如整个网关集群每秒最多扛1万请求，超了就直接返回503。听着挺合理对吧？结果呢？某次新上的秒杀接口突然冲上来8000的QPS，剩下2000的额度根本不够其他正常接口用，用户查个订单、看个商品，全被拦在外面，投诉电话直接被打爆。
对吧，这种事真的见太多了。
正确的限流逻辑从来不是拍个全局数字就完事。得把粒度拆细：普通商品查询接口的额度给多少，订单提交接口的优先级怎么算，秒杀接口的独立限流池怎么配，VIP用户的请求要不要拉高优先级，这些细节抠不明白，限流规则就是个摆设。
还有个坑我至今想起来都头疼。之前有个团队，把JWT校验的密钥直接硬编码在网关的静态配置文件里，上次因为安全要求要轮换密钥，三个工程师熬了半宿挨个节点改配置，结果漏了一个灰度环境的节点，导致所有灰度用户的登录态全失效，客服接投诉电话接到嗓子哑。
所有需要动态变更的配置，一定要接统一的配置中心，别写死在网关的静态配置文件里。我后来帮团队做改造的时候，专门给网关的配置变更加了自动审计：谁改了哪个接口的路由规则、哪个参数的限流阈值，改完之后的5分钟内系统自动监控对应接口的错误率，一旦超过10%就自动回滚到上一个版本。就这么一个小功能，前前后后帮我们省了至少三次半夜爬起来救火的麻烦。
别等流量打穿了才想起补能力
很多人对API网关的认知，停留在“我有个统一的流量入口”就够了。真不是。
去年接触过一个做生鲜配送的团队，他们的网关后面接了12个业务服务，其中库存服务因为数据库慢查询突然响应变慢，所有打到这个服务的请求全在网关上排队，越堆越多，最后网关自己的连接池被占满，直接整个集群挂掉，所有服务跟着遭殃——本来只是一个服务的小问题，最后演变成全站不可用的大故障。
这就是典型的没给网关加保护能力。你想啊，网关就像小区的大门，要是后面某栋楼的电梯坏了，堵在电梯口的人越来越多，最后把大门的通道全占了，那整个小区的人都出不去进不来。所以网关必须要有熔断降级的保护逻辑：当某个后端服务的响应时间超过预设阈值，或者连续错误率超过警戒线，就直接把这个服务的请求拦下来，返回个简单的兜底提示，别让请求在网关上无限排队，把整个系统拖垮。
真的，别被网上那些动辄“API网关高阶玩法”的文章忽悠了。什么灰度路由、服务网格集成、全链路压测联动，这些高级能力当然好，但大部分中小团队的业务量，根本到不上玩这些花活的程度。你把最基础的三件事做好：把网关的职责边界划清楚，别乱塞重逻辑；把限流规则拆到接口级，别搞一竿子打死的全局限流；把熔断保护的阈值调对，别让单个服务的问题拖垮全站——就这三点，你搭的API网关已经能稳稳当当扛住大部分业务的流量了。
上周和之前的老同事吃饭，他们说去年改造完的API网关，今年618的时候扛了平时5倍的流量，整个过程没出一次故障，运营团队甚至都不知道技术团队在背后调整了哪些配置。其实技术这东西从来不是越复杂越好。你别把它当万能筐啥都往里装，把该做的边界守好，该堵的漏洞补上，它自然就能安安稳稳给你干活。