API网关是微服务架构的入口，也是保护后端服务的第一道防线。当流量突增或后端服务出现故障时，如果没有合理的保护机制，一个慢服务就可能引发级联故障，拖垮整个系统。速率限制和断路器正是API网关中最核心的两个防护组件——前者控制“量”，后者控制“质”。

为什么需要速率限制和断路器

在微服务架构中，一个用户请求往往需要经过多个后端服务的协同处理。当某个下游服务响应变慢或失败时，如果网关继续将请求转发过去，线程会不断堆积等待响应，连接池很快被耗尽，最终导致整个调用链路雪崩。

速率限制的作用是在流量进入应用之前就拦住超额请求，不消耗应用线程资源。断路器的作用则是在下游服务已经出现故障时快速失败，避免线程池被拖死。两者的定位不同——限流是主动拒绝，熔断是依赖出问题时的快速失败。

速率限制的配置

算法选择

速率限制的核心是选择合适的算法。令牌桶是目前最广泛部署的方案，因为它将“持续速率”和“突发容量”两个维度分开控制。一个容量100、速率10/s的令牌桶，允许瞬间处理100个请求，之后以每秒10个的速度持续放行，直到桶重新填满。

滑动窗口则解决了固定窗口的边界突发问题。固定窗口在窗口切换的瞬间可能放行两倍于限制的请求，而滑动窗口通过持续移动的时间窗口精确控制速率。对于多租户API场景，滑动窗口的精确性更重要。

Nginx配置示例

Nginx的`ngx_http_limit_req_module`模块基于令牌桶算法实现请求速率限制。以下配置限制每个IP的API请求速率为2次/秒，允许10个突发请求：

nginx

http {

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

server {

location /api/ {

limit_req zone=api_limit burst=10 nodelay;

proxy_pass http://127.0.0.1:8080;

}

}

}

`burst=10`表示允许瞬间突发10个请求，`nodelay`表示超出的请求直接拒绝而非排队等待。对于登录、注册等敏感接口，建议将速率压到1r/s，进一步降低暴力破解的成功率。

`limit_conn`模块则用于限制并发连接数，适合大文件下载或流媒体场景。组合使用两个模块可以实现“每IP最多5个连接、每秒最多3次请求”的双重防护。

分布式场景的注意事项

在多个网关实例的集群中，每个实例独立维护计数器会导致实际放行量是配置值的N倍（N为实例数）。解决方案是使用Redis集中存储计数器，通过原子Lua脚本保证跨实例的速率一致性。

断路器的配置

三状态模型

断路器的核心是三个状态之间的自动转换：

- Closed（关闭） ：正常放行请求，持续统计失败次数

- Open（打开） ：失败次数超过阈值后，断路器打开，请求立即返回错误，不再转发到后端

- Half-Open（半开） ：等待一段时间后，允许少量试探请求通过，测试后端是否恢复。成功则关闭断路器，失败则继续保持打开状态

关键参数配置

以Sentinel的慢调用比例熔断为例，以下配置表示：当会员查询接口的调用超过500ms即被判定为慢调用，统计窗口为60秒，慢调用比例超过50%时触发熔断，熔断持续30秒，且至少需要20个请求才触发统计：

java

DegradeRule degrade = new DegradeRule("member:query")

.setGrade(RuleConstant.DEGRADE_GRADE_RT)

.setCount(500)

.setSlowRatioThreshold(0.5)

.setStatIntervalMs(60_000)

.setMinRequestAmount(20)

.setTimeWindow(30);

如果使用Resilience4j，对应的配置如下：

yaml

resilience4j:

circuitbreaker:

configs:

default:

slow-call-duration-threshold: 6s

slow-call-rate-threshold: 60

sliding-window-size: 10

permitted-number-of-calls-in-half-open-state: 4

`slow-call-duration-threshold`定义超过多少秒算慢调用，`slow-call-rate-threshold`定义慢调用比例阈值，`permitted-number-of-calls-in-half-open-state`控制半开状态下允许的试探请求数量。

半开恢复的调优

半开状态是断路器最容易出问题的地方。时间窗口设置太短会导致反复横跳——下游还没恢复就放流量进去，失败后又打开，不断循环。建议将`timeWindow`设置在30秒以上，给下游服务足够的恢复时间。

速率限制与断路器的协同

两者需要分层部署，各司其职：

第一层：API网关速率限制。 按来源IP或API Key配置QPS上限，防止单个客户端占用过多资源。这一层在流量进入应用之前就完成拦截，不消耗后端线程。

第二层：应用侧断路器。 对每个下游依赖配置独立的断路器，当某个服务响应变慢或错误率升高时触发熔断，快速返回降级结果。

降级返回的处理同样需要区分。限流触发时应返回429状态码（Too Many Requests），并携带`Retry-After`头告知客户端何时重试。熔断触发时应返回503状态码，引导前端展示静态缓存页或友好提示。

华纳云：为API网关提供稳定的底层网络

速率限制和断路器的配置能保护应用层不被拖垮，但如果底层网络本身就不稳定，再好的配置也只是在补救。API网关的响应时间中，相当一部分来自网络传输环节。如果服务器线路在晚高峰频繁丢包，网关的超时判定会被频繁触发，断路器可能因为网络问题而非后端故障被“误伤”打开。

华纳云香港及美国节点接入CN2 GIA精品线路，三网直连优化，晚高峰丢包率稳定在0.1%以下。全系标配独享带宽，不存在“邻居抢带宽”导致API响应波动的问题。对于需要部署API网关、承载高频请求的业务，一条稳定的线路能让速率限制和断路器的判定更加准确，避免因网络抖动引发不必要的熔断。