网关层限流：Nginx 与 Spring Cloud Gateway

闸门装在入口

分布式限流解决了「总量怎么算准」，还有一个问题悬着：闸门装在哪一层最划算。答案从最外层说起——被拒绝的请求越早死，浪费越少：在网关被拒，只花了一次网关转发的资源；漏进应用层再拒，线程、连接池、序列化全白花了。所以网关层限流是性价比最高的一道闸，本篇看两位入口常客怎么装闸。

Nginx limit_req：漏桶的教科书实现

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
}

三行配置三个关键参数。rate=10r/s：恒定放行速率，每秒 10 个——这就是第 4 篇漏桶的「桶底小孔」。burst=20：桶容量 20，允许排队（或暂存）20 个超额请求，突发不至于被一刀切。nodelay：突发额度内的请求不排队、立即放行，超出的直接拒绝——不加 nodelay 是纯漏桶（排队匀速放），加了是「带突发宽容的漏桶」，接近令牌桶的手感。limit_req_zone 的 $binary_remote_addr 是按 IP 维度分桶（二进制存储省内存），10m 的共享内存能存十几万个 IP 状态。另有 limit_conn 管并发连接数，与 limit_req 管速率互补。

Spring Cloud Gateway：令牌桶进网关

微服务体系里网关常是 Spring Cloud Gateway，限流过滤器直接内置 Redis 令牌桶（第 6 篇 Lua 的官方封装版）：

spring:
  cloud:
    gateway:
      routes:
        - id: order-route
          uri: lb://order-service
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 200    # 每秒发牌 200
                redis-rate-limiter.burstCapacity: 400    # 桶容量 400
                key-resolver: "#{@userKeyResolver}"      # 按什么维度分桶

@Bean
public KeyResolver userKeyResolver() {
    return exchange -> Mono.just(
        exchange.getRequest().getHeaders().getFirst("X-User-Id"));  // 按用户
}

replenishRate 是发牌速率，burstCapacity 是桶容量——令牌桶的两个旋钮原样暴露。真正的灵活性在 KeyResolver：按用户 ID、按 IP、按接口路径、按 Header 里的租户标识，分桶维度随业务定义，Redis 里每个 key 一个独立的桶。

网关的边界：看不见业务上下文

网关限流的盲区也在 KeyResolver 够不到的地方：「黄金会员每秒 10 单、普通会员 1 单」「下单要同时校验商品维度库存」——这些规则需要解析请求体、查会员等级，网关做业务解析既慢又危险（网关是全局咽喉，挂不得）。所以分工要清楚：网关卡粗的（IP 防刷、路由级总量、明显的恶意流量），应用层管细的（业务维度、方法级配额、精确到参数的规则）。网关层还有一个纪律：限流组件自身不能是单点——Redis 挂了网关限流失效，要有 fail-open 或本地兜底（第 6 篇的策略原样适用）。

不止一层闸

Nginx 或 SCG 的网关限流只是最外圈。老王的系统里，同样的流量从外到内要过三道闸：网关层挡 IP 防刷与路由总量；应用层用注解切面管业务维度配额（第 5 篇）；数据层——连接池上限、慢查询超时，是最后的物理防线。三层阈值逐层收紧还是逐层放宽？下一篇把多级限流的设计讲透：怎么分配额度、怎么避免内层闸白装、怎么让三层打配合。