HDUO Lab

深入 API 网关限流陷阱排查：Token Bucket 容量失控引发的微突发穿透与熔断震荡实战

作者：

ningniu

在

,

排查某业务线核心 API 网关间歇性 503 告警时，发现了一个极其经典的防御性配置失效案例。结论先行：网关层的 Token Bucket（令牌桶）限流算法中，burst（桶容量）配置过大，导致毫秒级微突发流量直接穿透网关，瞬间击垮下游服务线程池。更要命的是，熔断器配置缺乏防抖逻辑，导致在“熔断-半开-放行-再次击垮”之间形成了高频震荡（Thrashing）。

解决思路很简单：将 burst 值严格限制在下游最大并发承载能力之内，或者针对这种重计算型下游改用 Leaky Bucket（漏桶）算法进行流量整形（Traffic Shaping），同时为熔断器加入指数退避冷却时间。

案发现场与指标异常

监控大盘上的表象非常诡异。网关层统计的平均 QPS 稳定在 2,000 左右，并未达到设定的 3,000 QPS 报警水位。但下游订单服务的 P99 延迟却会毫无规律地从 50ms 飙升至 5,000ms 以上，随后伴随大量的 context deadline exceeded 报错。

查看下游宿主机的 Node Exporter 指标，Load Average 在几秒内冲高到正常核心数的 4 倍，CPU 软中断（si）陡增。

抓取网关层的 Envoy（或基于 Go 自研的网关）日志，看到大量 503 状态码以及频繁的熔断状态切换：

[gw-error] downstream_connection_error: upstream_reset_before_response_started
[circuit_breaker] state changed: CLOSED -> OPEN, reason: 5xx_rate_exceeded
[circuit_breaker] state changed: OPEN -> HALF_OPEN
[circuit_breaker] state changed: HALF_OPEN -> CLOSED
[circuit_breaker] state changed: CLOSED -> OPEN, reason: 5xx_rate_exceeded

愚蠢的配置与技术逻辑剖析

直接调出网关的限流配置片段，问题一目了然：

# 某网关 Token Bucket 限流配置片段
rate_limit:
  token_bucket:
    max_tokens: 15000       # 桶的总容量 (Burst)
    tokens_per_fill: 3000   # 每次填充的令牌数
    fill_interval: 1s       # 填充间隔

写出这段配置的研发可能对限流算法有什么误解。他认为“平时流量 2,000，限制在 3,000，为了防止大促时的流量尖刺，把 max_tokens 设成 15,000 留足缓冲”。

这是毫无系统边界意识的典型表现。 Token Bucket 的核心特性是允许一定程度的突发流量。当业务处于低谷时，令牌桶会很快被填满（15,000 个令牌）。此时如果客户端利用并发压测工具或因为重试风暴，在 10 毫秒内打过来 10,000 个请求，网关会认为“桶里有足够的令牌”，瞬间全部放行。

下游订单服务是个典型的 Java Spring Boot 配合 Tomcat 的同步阻塞架构，Tomcat 最大线程数才配置了 800，数据库连接池 200。这 10,000 个并发砸下去，直接导致：

  1. Tomcat 线程池瞬间打满，后续请求全部进入 Accept 队列。

  2. 数据库连接池耗尽，获取 Connection 发生等待。

  3. 线程疯狂上下文切换，CPU 资源被内耗殆尽。

网关层的限流不仅没有保护下游，反而成了帮凶。你以为的“缓冲”，其实是积攒了一发核弹交给了客户端。

熔断震荡（Circuit Breaker Thrashing）的雪上加霜

下游瘫痪后，网关的熔断器（Circuit Breaker）触发了 OPEN 状态，切断流量，下游开始缓慢恢复。但随后的恢复过程暴露了熔断器设计的另一个缺陷。

现有的熔断半开（HALF_OPEN）策略是：等待 5 秒后，放行 10 个请求，如果全成功，则关闭熔断器（CLOSED）。 因为这 10 个探路请求下去时，下游服务刚刚喘过气，处理极快。熔断器一看，非常健康，瞬间切回 CLOSED。结果桶里早就又攒满了 15,000 个令牌，下一波微突发（Micro-burst）再次穿透，下游再次暴毙。

这种简单的状态机没有考虑到下游服务的冷启动缓冲和并发水位线，导致系统在可用与不可用之间剧烈震荡，P99 延迟曲线变成了梳子状。

避坑指南与底层调优

解决这类问题，必须摒弃“一厢情愿”的配置，回归到底层容量规划上来：

1. 重新校准 Token Bucket，或者改用 Leaky Bucket 如果下游服务对瞬间并发极度敏感（如涉及复杂事务、慢 SQL 的 DB 操作），首选 Leaky Bucket（漏桶）。漏桶就像一个队列，强行将请求以恒定速率滴漏给下游（Traffic Shaping），完全抹平突发。 如果必须用 Token Bucket，max_tokens（Burst）的绝对上限，必须小于下游服务能够承受的最大瞬时并发数（通常是 线程池大小 + 队列长度的小部分）。

修正后的配置：

rate_limit:
  token_bucket:
    max_tokens: 800         # 严格卡住瞬间并发上限
    tokens_per_fill: 3000
    fill_interval: 1s

(注：如果使用 Go 的 golang.org/x/time/rate，Limit 控制速率，Burst 就是这个 max_tokens，务必小心设置。)

2. 引入滑动窗口与指数退避熔断 放弃拍脑袋的连续错误计数熔断，改用基于时间滑动窗口（Sliding Window）的错误率熔断。半开状态的探测必须具备平滑放量能力，而不是简单的“成功 10 个就完全放开”。冷却时间必须使用指数退避（Exponential Backoff，如 5s -> 10s -> 20s），并引入 Jitter（随机抖动）防止探路请求形成新的微并发。

3. 监控维度的降维打击：从秒级到毫秒级 只看秒级（QPS）的监控，永远抓不到微突发。在排查阶段，通过抓包或高频采样，将吞吐量统计粒度降到 10ms 或 100ms，你会清楚地看到流量的尖刺。

排查清单（同类问题速查）

  1. 核对 Burst/Capacity 配置：检查网关限流器中代表突发容量的字段（如 burst, max_tokens），其值是否远大于下游服务的可用线程数/连接池数。

  2. 区分流量整形需求：评估下游是否能处理突发。如果不能，立刻将 Token Bucket 替换为 Leaky Bucket，或在 Nginx 中严格使用 limit_req 且不加 burst（或者加 nodelay 时严格控制大小）。

  3. 检查熔断震荡日志：在日志系统中聚合分析 CLOSED -> OPEN -> HALF_OPEN -> CLOSED 的时间差。如果发生频率在秒级切换，说明探路策略过于激进，需增大退避时间和放量步长。

  4. 排查毫秒级微突发：如果 1s 内的 QPS 正常但 P99 飙升，使用 Prometheus 的 rate(metric[1m]) 是看不出来的，必须拉取网关 Access Log 按照 100ms 粒度做 count 聚合分析。

更多文章