API网关是大促流量入口的限流第一道防线，通过集中式流量管控保护后端服务，避免系统被瞬间峰值打垮，同时保障正常用户体验。大促场景下，流量不是缓慢爬坡，而是开场几分钟内涌进几倍甚至几十倍请求，没有限流，数据库连接池会先被占满，紧接着应用线程阻塞，最终整个链路雪崩，API网关作为所有请求的统一入口，天然适合执行限流规则，把超额流量挡在系统之外。
大促流量入口为什么必须靠API网关限流？
流量冲击的真实场景
每年双十一、618这类大促，开场瞬间的并发量能达到平时峰值的数倍甚至一个量级，用户疯狂点击秒杀按钮、反复刷新购物车，请求像潮水一样涌向服务器，如果让这些流量直接打到后端应用，不仅秒杀接口扛不住，连普通的商品查询、订单查询也会跟着遭殃。
业内的典型做法是：所有请求先经过API网关，网关根据预设的规则判断放行还是拒绝，被拒绝的请求快速返回“系统繁忙”提示，放行的请求继续往后端转发，这个过程发生在网关层，不占用业务应用的计算资源，响应时间极短。
没有限流会怎样
想象一个电商系统的秒杀接口能处理每秒1000个请求,大促瞬间来了每秒5000个，没有网关限流，这5000个请求全部进入应用层，应用层线程池迅速耗尽，新请求排队等待，同时数据库连接数飙高，最终导致接口响应超时，更麻烦的是，某个接口的故障会通过调用链传染到其他服务，比如商品服务挂了，推荐服务、搜索服务也跟着连环崩。
行业共识认为,大促时系统崩溃的大部分原因不是硬件性能不足，而是缺乏有效的流量准入控制，API网关限流的关键在于：即使后端容量有限，也能通过网关的“人工闸门”把流量控制在安全范围，牺牲一小部分请求来保住整体系统的可用性。
API网关限流怎么配置？常用算法与实操要点
三种限流算法对比
配置限流前,先明确算法选择，网关常用的限流算法有固定窗口、滑动窗口、令牌桶和漏桶。
| 算法 | 原理 | 适用场景 | 特点 |
|---|---|---|---|
| 固定窗口 | 按时间窗口计数，窗口内超过阈值即拒绝 | 简单统计类接口 | 实现简单，但窗口边界处可能突发双倍流量 |
| 滑动窗口 | 将窗口细分为多个小格，滑动计数 | 对突发敏感的业务 | 比固定窗口平滑，精度更高 |
| 令牌桶 | 以固定速率生成令牌，请求需拿到令牌才放行 | 允许一定突发流量 | 能应对短时突发，大促秒杀常用 |
| 漏桶 | 请求进入队列，以固定速率流出 | 平滑流量，防止突发 | 严格匀速，但可能增加排队延迟 |
配置实操要点
以常见的开源网关Kong和云厂商API网关为例,配置限流时需要注意：
- 先设定阈值：根据压测结果确定每个接口的最大QPS，留出20%-30%冗余，避免限流误伤正常用户
- 分维度限流：按IP、用户ID、接口路径分别设置阈值，比如秒杀接口对单个用户限流1次/秒，对全局限流1000次/秒
- 设置应急开关：大促期间运维人员需要能快速调整限流阈值，而不需要重启网关，网关控制台应提供动态配置接口
- 观察限流日志：被拒绝的请求要记录日志，确认限流规则是否合理，如果拒绝比例接近30%，说明后端容量不足，需要扩容
一个常见的配置错误是只做接口维度限流,忽略了用户维度，比如某个用户用脚本频繁刷接口，占用了大量配额，导致正常用户请求被限，正确做法是组合使用IP限流和用户限流，再配合验证码机制。
API网关限流和熔断有什么区别？别再混为一谈
两者的核心差异
限流和熔断经常被放在一起讨论,但作用阶段完全不同。限流发生在请求进入系统前，关注的是流量大小；熔断发生在调用后端服务时，关注的是服务健康状况。
用大白话比喻：限流是门口的保安，看到人太多就暂时不让进；熔断是家里装了自动跳闸，电器一短路就切断电源避免火灾，保安管的是进门人数，跳闸管的是线路安全。
实际配合方式
在大促场景中,两者经常联合使用，比如API网关对某个接口设置限流规则，每秒最多放行500个请求，但即使只有200个请求，如果后端数据库出现慢查询，接口成功率下降，这时候熔断器就会打开，直接快速失败，不再等待后端超时。
对比表格更清晰：
| 维度 | 限流 | 熔断 |
|---|---|---|
| 关注点 | 流量速率 | 服务健康状态 |
| 触发条件 | 达到设定QPS/并发阈值 | 错误率、超时率达到阈值 |
| 处理动作 | 拒绝新请求或排队 | 短路调用，直接返回降级响应 |
| 恢复方式 | 窗口期内逐渐恢复 | 时间窗口后试探性放行 |
大促场景下的限流策略：从单机到集群
分布式限流的难点
单机限流很好做,每个网关节点独立计数即可，但大促入口通常有多个网关节点，如果每个节点只统计自己的请求数，总体流量就会是节点数乘以单机阈值，导致总配额远远超过设计值。
分布式限流需要把计数集中放在Redis或专门的限流服务中,每次请求都要从Redis读取当前计数器并原子加一，这样做会引入额外网络延迟，但为了精确控制总量，这个成本必须承担，业内常用的方案是使用Sentinel或自研限流中间件，把限流统计逻辑从网关业务中抽离出来。
按用户、接口、地域分流
大促流量不是均匀的,不同用户、不同接口、不同地域的流量特点差异很大。
- 按用户等级分流：会员等级高的用户优先放行，普通用户排队等待，这能提升核心用户的体验
- 按接口优先级分流：下单、支付接口的优先级高于商品推荐、历史订单查询，网关配置多套限流规则，低优先级接口在大促时可以适当调低配额
- 按地域分流：华南地区的用户访问量高，华东地区相对较低，可以为不同地域的接入点配置不同的限流阈值，避免极端情况。
实际操作中,网关通常支持多级限流策略，比如先按用户ID限流，再按接口限流，最后按全局总流量限流，多级规则之间是“与”的关系，任何一级达到阈值都会拒绝请求，这样可以精细控制整个流量的形状。
API网关限流的价格与选型建议
对于技术团队来说,选择自建开源网关还是购买云厂商网关，主要看成本和运维能力。
开源网关的隐形成本
Kong、APISIX、ShenYu等开源网关本身免费，但需要自己部署、监控、调优，限流功能往往需要额外开发，比如接入Redis实现分布式计数、设计控制台动态调整阈值，一个中等规模团队维护网关的成本，算上人力投入，一年下来并不比云厂商便宜。
如果用自建网关,建议优先选择内置限流插件丰富的项目，例如APISIX提供limit-req（漏桶）、limit-count（固定窗口/滑动窗口）等插件，开箱即用，Kong的rate-limiting插件也支持本地和Redis模式，可以直接配置。
云厂商网关的性价比
以简米云、酷番云、华为云为例，API网关产品通常按调用次数计费，每月有免费额度，超出后按量付费，例如简米云API网关的按量付费价格约为每百万次调用几十元到上百元不等，具体因地域和规格而定。
云厂商的最大优势是免运维、高可用，限流功能在控制台上点选即可完成，支持实时监控和自动告警，对于中小团队来说，购买云网关的支出远低于自建运维成本，但对有特殊定制需求的大厂，自建网关才能掌控完全的控制力。
选型建议：如果团队具备较强的中间件开发能力，且流量规模极大，选择自建开源网关，如果追求快速上线、稳定可靠，且调用量在千万级以下，直接购买云厂商API网关更划算。
大促前你需要做的三项限流检查
- 压测验证：大促前两周，用压测工具模拟真实峰值流量，观察网关限流是否生效，后端系统是否稳定运行
- 配置巡检：核对每个核心接口的限流阈值是否与压测结果匹配，确认分布式限流依赖的Redis集群容量充足
- 演练预案：模拟限流触发后的用户体验，确认返回的提示信息是否友好，避免出现“503 Service Unavailable”这类生硬的错误
这三项工作做扎实,大促流量入口才能真正稳如磐石，限流的最高境界不是拒绝所有超额请求，而是让系统在超负荷状态下依然提供可用的核心服务，API网关在其中扮演的是那个冷静的守门员，知道什么时候该放行，什么时候该拦截，用最小的成本换来整体系统的稳定。
关于API网关限流的常见疑问
API网关限流会误杀正常用户吗？
会,但可以通过精细规则降低误杀概率，比如固定窗口算法在窗口切换时可能瞬间放行两倍流量，改用滑动窗口或令牌桶算法后，流量曲线更平滑，同时针对不同用户ID设置独立配额，避免单一用户刷接口拖垮全局，如果正常用户被限流，大概率是后端容量已经达到瓶颈，此时扩容比调整限流更有效。
大促时API网关限流的阈值应该设置多少？
没有统一数字,取决于后端实际容量，正确做法是通过压测找到每个接口的最大可承受QPS，然后乘以0.7-0.8的系数作为初始阈值，比如压测显示下单接口最高能支撑每秒3000个请求，网关阈值就设为2400左右，大促期间每分钟观察监控面板，如果拒绝比例持续偏高，适当放宽阈值并同步扩容后端。
API网关限流和CDN缓存能互相替代吗？
不能,CDN缓存主要分担静态资源的读取压力，比如商品图片、页面框架，它回源到应用层的请求依然不受控制，API网关限流则直接管理动态API的请求速率，两者是不同层面的流量治理工具，大促时通常会同时启用，静态资源走CDN，动态请求走网关限流，各司其职才能保证整体链路通畅。