上周帮杭州一个做社区生鲜的小团队排障。
大促当天。
他们的订单接口卡了整整40分钟。
查了半天才发现，问题根本不在订单服务本身——他们把用户优惠券计算、配送范围校验、甚至商品库存的实时扣减逻辑，全塞进了API网关里。
网关那台8核16G的机器，平时扛个两万QPS本来松松垮垮，那天光跑这些嵌套的业务逻辑，CPU直接干到99%，连最基础的转发请求都卡成PPT。
说实话很多团队对API网关的认知，还停留在”把所有公共功能全扔进去就完事”的阶段。
你以为的公共能力，其实是网关的负担
很多人刚接触微服务的时候，觉得API网关就是个万能垃圾桶：什么鉴权、限流、日志、跨域、参数校验、甚至业务规则，全往上堆。
但其实真正适合放在网关层的能力，只有那些和流量入口直接相关的通用逻辑——比如统一的身份校验、基础的流量阈值限制、请求路径的路由转发、跨域配置、全链路追踪的埋点。
什么叫和流量入口相关？就是所有请求不管你后面要走哪个服务，只要过了入口就得统一处理的东西。
剩下的？别塞。
举个例子，你要是把”满30减5″的优惠券计算逻辑放网关里，后面要加个”新用户首单减10块”的规则，你是不是得改网关代码？改完整个网关全量发版？
出了bug谁背锅？
对了，之前见过更离谱的，有团队把用户头像的CDN回源逻辑都放网关里，就为了省一个Nginx的配置。
网关的核心职责是什么？是把进来的请求，稳稳当当地转发到后面对应的服务上，延迟要低，稳定性要够。你给它塞越多非必要的逻辑，它的稳定性就越没保障。
你想啊，本来它就是个高速路的收费站，你现在让它顺便查车辆的年检有效期、算过路费的优惠折扣、甚至帮车主把后备箱的货搬下来。
能快才怪。
那些看起来很美的配置，其实性价比极低
很多人刚上网关，就把所有的限流规则、熔断规则全配得特别细，甚至每个接口的每个用户的限流阈值都不一样。
结果呢？
配置文件写了快一千行，每次加个新接口，都要翻半天找对应的配置段。上次有个团队的运维，改个限流规则把整个生产环境的路由给删了，导致所有接口404，停了半小时。
其实大部分中小团队，根本不需要那么细的配置。
你就记住几个核心的配置原则就行：全局的基础限流阈值先设好，比如单IP每秒最多100次请求，超过的直接拦；核心路径的路由规则提前配好，比如/api/order开头的全转到订单服务集群，/api/user开头的转到用户服务集群；剩下的特殊规则，真的需要的时候再加。
别一开始就追求”完美配置”。
完美是最没用的东西。
还有个常见的坑，就是很多团队把网关当日志收集的核心节点。
所有请求的请求体、响应体、用户参数全存在网关的本地磁盘上，结果大促的时候磁盘打满，网关直接挂掉。
要知道日志收集本来就该是旁路的事，你网关最多打个请求的路径、状态码、耗时就够了，详细的业务日志，让后面的服务自己往消息队列里扔，网关别瞎掺和。
真要用好网关，先把这几件事落地
先把之前塞在网关里的所有非通用业务逻辑全拆出去。什么优惠券计算、库存校验、用户画像标签匹配，这些全挪回对应的业务服务里。网关就留最基础的鉴权、路由、限流、跨域、追踪埋点。
别觉得麻烦。
上次那个生鲜团队拆完这些逻辑之后，网关的CPU占用直接从大促时的99%降到了12%，转发请求的平均延迟从200多毫秒降到了15毫秒，比之前快了十多倍。
再就是给网关的配置做版本管理。别谁都能直接登生产环境改配置，所有的配置变更都要走代码评审，提交到Git仓库里，每次变更留痕，出了问题能一秒回滚。
之前那个误删路由的团队，后来把所有网关配置都放到Git里做版本管理，再没出过类似的低级错误。
还有，别给网关配太高的资源规格，也别给它配太低的。就按你平时峰值QPS的1.5倍来算资源就行，多了浪费，少了扛不住。
对了，一定要给网关做健康检查。
别等整个服务全挂了才发现出问题。
很多技术选型的坑，本质上都是把本来该做一件事的组件，硬塞了太多不属于它的功能。
网关不是万能的。
它就是个守大门的。
你别让守大门的人去干财务的活，也别让他干客服的活。
把门守好，把该拦的坏请求拦下来，把进来的人指对路，就够了。