API网关限流实践：用三层策略守住后端服务的底线

一次营销活动上线后，接口流量在十分钟内涨了二十多倍，下游数据库连接很快被打满，正常请求也开始排队超时。问题不在业务逻辑，而在于缺少一道统一的流量关口。从那以后，我习惯先在API网关层把限流做扎实，再谈服务内部优化。

第一层是接口级限流。给核心下单、支付类接口设置每秒请求上限，超出部分直接返回友好提示，不再向后转发。这样既能保护数据库，也能让客户端明确知道是流量受限，而不是服务不可用。阈值要依据压测结果和日常峰值设定，留出合理余量。

第二层是用户级限流。按用户标识或令牌做配额，防止单个调用方占满全部容量。内部系统和外部合作方应分开配置，重要客户可以适当放宽，普通调用方则严格一些。配额耗尽时要给出剩余时间和重试建议，避免客户端无间隔重试放大流量。

第三层是全局熔断与降级。当后端错误率持续升高或响应时间明显变长时，网关先短暂拦截部分非核心流量，保证核心链路可用。降级不是简单返回错误，而是返回缓存数据或简化结果，让用户至少能完成关键操作，待指标恢复后再逐步放开。

落地时还有三个细节值得注意。限流规则要支持热更新，避免每次调整都要重启网关；限流事件必须进日志和监控，方便事后复盘；上线前一定要用高于峰值两倍的流量做压测，验证限流生效且核心接口不受影响。限流不是限制业务，而是给系统留出喘息空间。