凌晨一点线上告警把我从床上叫起来。运营搞了一波促销流量比平时涨了五倍我们服务入口的QPS直接冲到峰值。诡异的是数据库、Redis、下游支付回调都还没到瓶颈整个API却先“自杀”了——大量请求超时、线程池被打满、错误率直线上升。后来复盘才发现限流阈值是配了但配得太宽松形同虚设熔断虽然开了但下游抖动了一下就立刻恢复根本来不及触发。那一次事故让我意识到一个很现实的问题大多数系统不是没有限流和熔断而是从来没人认真测过它们到底能不能在关键时刻起作用。这篇文章想聊聊怎么系统地去测试API的限流和熔断能力。也就是所谓的“API韧性测试”通过人为制造流量过载、下游故障验证系统在最坏情况下能不能按设计好的方式兜住。文章会包含测试前的指标设计、限流和熔断的实操步骤、压测工具的选型以及我踩过的一堆坑。适合正在做网关、微服务或者对外开放API的同行参考。1. 限流和熔断到底在保护什么测试之前先把机制想透很多测试同学拿到限流熔断需求第一反应是“找工具压一下看返回啥”。这没有错但容易忽略一个前提你连这两个机制各自保护什么、失效后果是什么都没想清楚测出来的结果只能叫现象不叫结论。1.1 限流是控制入口熔断是切断故障我习惯用两个生活里的东西来类比。限流就是地铁站进站口的闸机。不管里面站台能装多少人闸机每分钟放进多少人是有数的。它保护的是“自己”不被超出处理能力的流量击穿。哪怕后端机器性能很好入口流量超出额定容量后服务的线程、内存、数据库连接都会被打爆。熔断则是家里配电箱里的保险丝。当线路里的电流异常变大或者有设备出故障时保险丝先断掉切断整个回路保护后面的电器不被烧毁。它保护的是“调用链上的下游依赖”不被故障拖垮更保护“自己”不被下游的故障拖入泥潭。在API场景下两者的边界非常清楚限流针对的是“进来的请求太多”对应的是自身容量上限。熔断针对的是“调用的下游不可用或变慢”对应的是外部依赖的故障。一个典型的例子你的API调用第三方支付网关支付网关偶尔超时。如果网关超时5秒而你所有线程都在等这个5秒很快就没线程处理其他正常请求了。这时应该熔断让后续请求直接快速失败而不是继续排队等一个大概率会失败的调用。而限流测的是当入口QPS超过你配置的阈值比如单机200 QPS多出来的请求是被拒绝、还是排队、还是走了降级逻辑。1.2 混为一谈的代价我见过的最常见的配置错误这个例子我印象特别深。有一个团队上线前配置了Sentinel的限流和熔断规则但测试的时候只做了一件事把QPS压到阈值以上看到有请求返回“Blocked”就认为功能验证完了。结果上线没两天下游MySQL一抖动服务端线程全部hang住。为什么因为他们的熔断规则配的是“慢调用比例超过50%才熔断”但当时慢调用的判定阈值是1000ms而MySQL抖动的耗时只有800ms。800ms的调用不计入“慢调用”熔断器根本不动作线程池照样被拖死。这个案例说明一个道理测试限流熔断不只是测试“配置是否生效”而是要测试“失效条件是否匹配真实故障场景”。限流阈值设多少、熔断的慢调用阈值是多少毫秒、错误比例达多少触发、半开状态下放多少探测流量这些参数之间是联动的。测试人员的核心工作就是把每个参数背后的行为逻辑验证一遍。所以在写压测脚本之前先把下面几个问题想明白限流阈值是多少在哪一层限流网关、应用、还是DB连接池超限后是返回429还是503客户端拿到这个状态码会怎么做熔断打开后请求是抛异常、返回兜底数据、还是直接快速失败多久之后进入半开半开期间放多少请求过去这些问题没有标准答案取决于你的业务场景。但测试用例必须按照你系统的设计来写。2. 测试环境与指标设计避免测了个寂寞韧性测试最忌讳的事是在一个和线上差异很大的环境里跑得出一个看起来很完美、实际上没用的结果。我通常把准备阶段拆成三块环境怎么搭、指标怎么定、流量怎么造。2.1 隔离环境怎么搭如果条件允许尽量在独立的测试环境或预发环境的独立分组里做不要直接在线上主链路做全量压测。我踩过的坑是直接在预发环境压结果把预发依赖的公共Redis连接打满了吓得运维把整个预发集群重启了一遍。比较可靠的做法是用Docker Compose拉起一套最小化拓扑被测API服务一个或两个实例依赖的下游服务用Mock实现可以动态注入故障Redis用于分布式限流或状态存储Prometheus Grafana观测指标下面这个Compose片段是我常用的基础模板version: 3 services: api: build: ./api ports: - 8080:8080 depends_on: - mock-upstream - redis mock-upstream: build: ./mock-upstream ports: - 9090:9090 redis: image: redis:7-alpine prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml注意一个细节被测服务和Mock服务的时钟最好通过NTP同步或者统一用容器宿主机的时间。限流很多是基于时间窗口的比如固定窗口每秒重置如果服务容器和Redis的时钟差了几秒限流的周期会变得乱七八糟测出来的数据根本没法解释。这一点后面我会专门讲一个真实案例。2.2 定义你关心的指标限流阈值、拒绝码、恢复时间在开始压测之前我建议先列一张指标表明确每个指标的期望值和观测方法。没有这张表你压完只会得到一堆孤立的数字不知道到底算通过还是失败。下面是我做限流熔断测试时常用的指标表指标期望值示例观测方法实际触发限流的QPS不超过配置阈值的±5%服务端日志、网关access log、Prometheus QPS曲线限流拒绝的状态码429或503按设计约定压测脚本统计响应码分布限流拒绝的延迟10ms压测工具输出熔断打开时间达到错误率阈值后立即快速失败调用链监控、熔断器状态指标熔断半开探测成功后的恢复时间按配置比如5秒内连续观测请求成功比例故障注入期间的系统错误率用户侧错误率受控在可接受范围错误率监控有一点特别重要压测脚本里不要只统计“请求总数”和“失败数”要区分“业务成功”和“被限流拒绝”。被限流拒绝其实不是系统错误而是系统正常工作。我见过有团队把429当成错误率统计导致告警震天响实际上系统一切正常。2.3 压测工具的流量模型怎么选工欲善其事必先利其器。压测工具这件事上没有银弹只有适不适合。我的习惯是小验证用wrk或ab复杂场景用k6精细控制用Locust或自研脚本。几款工具的快速对比工具优势短板ab简单装完就能用只适合低并发简单压测wrk高性能单机可以打出很高QPS脚本能力有限统计维度少k6云原生友好JS脚本灵活内置指标丰富学习成本比wrk高LocustPython写脚本协程并发高并发能力取决于Python性能做韧性测试和普通压测有个核心区别流量模型必须是变化的。千万不要只用恒定速率打。限流测试要验证的是系统在“超过阈值”和“低于阈值”之间切换时的行为所以至少要有三种模型阶梯式每30秒提高一档QPS逐步越过阈值观察限流器生效点。突发式维持整体平均QPS低于阈值但每隔几秒打一波高QPS脉冲观察突发是否被削平。波浪式QPS在阈值上下周期性摆动观察系统能否快速适应不会振荡。这几种模型针对的是不同限流算法。固定窗口限流在突发场景下可能有双倍流量漏洞令牌桶限流则允许一定突发。不把流量模型设计好根本测不出算法之间的差异。3. 限流测试怎么打从阈值校验到算法行为验证限流测试看起来最简单压一压就行但真测的时候细节非常多。这一节按我的实操顺序讲先验证阈值再验证算法行为最后验证限流后的业务表现。3.1 阈值生效性验证200 QPS压一个100 QPS的接口第一步永远是最基础的确认配置的限流阈值真实生效。假设你在API网关里给某个接口配置了单实例100 QPS的限流规则。我的做法是先用120 QPS的恒定流量压5分钟再换成80 QPS压5分钟观察被拒绝的请求数量变化。120 QPS阶段应该能看到持续有请求被拒绝拒绝数约为20 QPS。80 QPS阶段不应该有拒绝。这里有个大坑分布式限流场景下阈值是每实例还是全局如果规则是每实例100 QPS而你压测流量经过负载均衡分发到了两个实例那么总入口QPS到了200 QPS才会有拒绝。你在压测脚本里看到“入口都150 QPS了还没拒绝”先别急着怀疑配置先确认一下是不是被负载均衡分摊了。这个误判我至少见过三次。用k6写一个简单脚本验证阈值非常方便import http from k6/http; import { check, sleep } from k6; export const options { scenarios: { constant_load: { executor: constant-arrival-rate, rate: 120, // 目标RPS duration: 5m, preAllocatedVUs: 50, }, }, }; export default function () { const res http.get(http://api.example.com/test); check(res, { 200 received: (r) r.status 200, 429 expected under limit: (r) r.status 429, }); }跑完之后看两个数200的分布和429的分布。如果120 RPS下429数量很稳定地保持在一个值附近说明限流生效如果429数量忽高忽低说明后端可能有多实例或网络引入的不确定性要去排查流量分发。3.2 算法差异会改变你的测试结论限流算法不是只有一种而不同算法的测试表现差异很大。常见的几种固定窗口按时间窗口计数窗口结束就清零。实现简单但窗口切换瞬间可能出现两倍流量“冲进来”。滑动窗口按子桶统计平滑度更好但实现复杂些。令牌桶以固定速率往桶里放令牌桶有容量上限。允许一定程度的突发整体平均速率受限。漏桶请求以固定速率被处理超出部分排队或丢弃。削峰效果强但可能增加延迟。我自己的一个实测案例某平台的网关用的是固定窗口限流配置的是100 QPS。我用突发模型测试每个窗口的最后100ms打进来150个请求结果这150个请求几乎全部通过了。原因是在窗口末尾计数还没到100所以不拒绝等窗口翻转计数清零新的请求又畅通无阻。这个双倍流量漏洞只有在窗口边界才会出现用恒定速率压测根本测不出来。所以测试限流算法至少要覆盖下面几个场景场景期望行为测试方法恒定流量低于阈值全部通过恒定RPS压测恒定流量高于阈值超出部分被拒绝恒定RPS压测突发流量跨窗口边界可能短暂超过阈值突发脉冲压测流量从高位降到低位系统快速恢复正常阶梯式压测你在测试报告里应该能写清楚“这个限流器允许什么样的突发”而不是只写“限流生效”。3.3 限流后的表现拒绝、排队、降级都要验证限流并不保证一定会直接拒绝请求。有的系统设计是返回429有的是让请求排队等待还有的是直接走缓存降级。测试的时候这三种表现是三种完全不同的用例。直接拒绝模式最好验证超过阈值就立刻返回特定状态码响应时间极短。排队模式要小心请求不会立即失败而是挂在队列里等。如果队列积压太多请求最终会超时。测试排队模式时我会重点关注“最大排队时间”和“队列溢出后的表现”。压测脚本里要分别统计成功、超时、直接被拒、队列溢出四类请求的数量。降级模式最复杂。比如商品详情页的库存接口限流了你不能直接报错应该返回缓存中的库存数据。这时候限流测试的断言不是“状态码是429”而是“返回的数据是否来自降级缓存响应时间是否在预期内”。在Mock服务里要造好缓存数据让降级响应和正常响应用字段区分开比如返回体里加一个source: cache标记。另外客户端拿到限流响应后的行为同样重要。如果你的客户端代码看到429就无限重试那限流永远挡不住流量因为重试请求会一波接一波打进来。这在业内有个专门叫法重试风暴。我在测试报告里一定会附上“客户端重试策略检查”这一项确认客户端是等待一段时间再重试还是直接放弃。4. 熔断测试怎么打让下游真实“坏”一次熔断测试的核心动作是故障注入。难点在于你要让下游真实地坏一次又不能把整个测试环境搞到无法恢复。4.1 故障注入的三种可行方式做熔断测试一般有三种方式制造下游故障方式一在Mock服务里开一个“故障开关”这是我最推荐的方式。写一个Mock下游服务暴露两个接口正常接口和故障注入配置接口。通过配置接口可以动态设置延迟多少毫秒比如固定延迟2000ms返回什么状态码500、503、429错误比例是多少比如50%的概率返回500这样测试时只需要调用一次配置接口Mock服务就会按规则开始故障测完再调一次接口恢复。整个过程完全可控。用Spring Boot写这种Mock很简单核心逻辑类似RestController public class FakeUpstreamController { private volatile int delayMs 0; private volatile int errorRate 0; PostMapping(/fault/config) public void config(RequestBody FaultConfig config) { this.delayMs config.getDelayMs(); this.errorRate config.getErrorRate(); } GetMapping(/api/upstream) public String getData() { if (delayMs 0) { try { Thread.sleep(delayMs); } catch (InterruptedException e) { } } if (errorRate 0 ThreadLocalRandom.current().nextInt(100) errorRate) { throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR); } return ok; } }方式二用网络层工具模拟延迟和丢包比如用Linux的tc命令在容器网络接口上注入延迟tc qdisc add dev eth0 root netem delay 2000ms恢复时删掉规则tc qdisc del dev eth0 root这种方式更接近真实网络问题但影响范围是整个容器不能只针对某个接口。适合验证“网络层异常时熔断是否兜得住”。方式三在限流熔断框架里直接触发规则像Sentinel、Hystrix这类框架都提供了手动降级或设置阈值的接口。你可以在测试时把错误比例阈值临时调得很低让熔断器快速进入打开状态。这种方式适合验证“规则配置是否正确”但不适合验证“真实故障能不能被识别”。建议前两种为主这种方式作为补充。无论用哪种方式故障注入一定要有自动恢复机制。我最担心的是有人在测试环境留了个500%错误率的Mock配置第二天别人跑自动化测试跑出一堆莫名其妙的问题排查半天才发现是故障没恢复。4.2 验证熔断的三个状态关闭、打开、半开熔断器有三个状态关闭Closed、打开Open、半开Half-Open。测试的目标是确保状态转换符合预期。我用一个具体流程说明假设熔断规则是10秒内错误率超过50%触发熔断熔断持续5秒半开放行5个探测请求若成功则关闭熔断。测试步骤初始校验关闭状态正常流量调用下游确认所有请求都成功熔断器保持在关闭状态。制造故障把Mock服务错误比例调成100%。观察打开状态持续调用一段时间超过统计窗口看到熔断器状态变为打开。此时继续请求应该立即返回快速失败不再等待下游响应。用压测脚本统计打开状态下请求的平均延迟应该远小于正常调用延迟因为根本没往下游发。撤除故障把Mock错误比例调回0%。等待半开熔断器的半开时间到了它会放行少量探测请求。如果探测请求成功熔断器关闭后续请求恢复正常如果探测失败熔断器重新打开重新计时。验证每个状态时我习惯用状态机视角来组织用例状态触发条件预期行为观测点Closed错误率低于阈值正常转发请求下游调用次数正常Open错误率超过阈值快速失败不调用下游下游调用次数骤降为0Half-OpenOpen持续到计时结束放行少量探测请求下游调用次数很低的尖峰Closed恢复探测成功率达到阈值全部流量恢复下游调用次数恢复正常这里有一个细节很多人会忽略熔断器打开后不是所有请求都走快速失败而是要走你预先设计好的降级逻辑。比如返回兜底数据、返回空列表、返回本地缓存。测试断言里要检查的是“熔断后返回的到底是什么”而不只是“请求没超时”。4.3 客户端重试与半开探测的联动测试熔断测试做到后面一定要把“上游客户端的重试行为”纳入范围。但我还要提醒一句必须避开“代理”这个词用“网关层”“接入层”表达就好。我见过一个真实事故熔断器正常打开了上游客户端也正常收到了快速失败的错误码。但客户端重试策略是“失败后立即重试5次”等到熔断器半开时瞬间涌入了大量重试请求。本来半开只放行5个探测请求结果因为那些重试请求也在路上直接超过了下游的承受能力。下游刚恢复被这一波重试又打挂了。这就是典型的“熔断恢复过程引发的二次故障”。因此测试用例里要专门验证客户端在熔断打开期间重试次数是否受限客户端重试的间隔是否采用了指数退避熔断进入半开后探测请求和正常请求、重试请求混在一起时是否会挤爆下游我通常的做法是在压测脚本里同时模拟两类客户端一类是“老实的客户端”收到快速失败就停手另一类是“激进的重试客户端”收到错误就疯狂重试。然后观察熔断器半开状态下系统表现是否仍然可控。如果不可控问题不在熔断器而在客户端的重试策略这个结论会写进报告里直接推动客户端改造。5. 那些坑我们的测试把自己坑了韧性测试做了几年很多坑都是自己踩出来的。踩得多了我发现它们大多不是技术上的“疑难杂症”而是很基础的问题。单独拿出来说是想让后来的人少花点冤枉时间。5.1 压测统计口径不一致第一次做限流测试的时候我用wrk压接口wrk显示QPS是950压测机网卡都快打满了。但到服务端看日志实际收到的请求只有800 QPS。差了150 QPS这个数字直接让我判断限流“提前生效”了。后来查了半天原因是wrk为了维持高并发让大量连接处于Keep-Alive复用状态但服务端连接池有上限一部分请求在TCP层就被拒了根本没进到应用层。所以压测工具输出的是“客户端发出的请求数”服务端统计的是“应用层收到的请求数”两者天然就不一样。结论以服务端日志和中间件指标为准压测工具的QPS只做参考。以后我做限流测试所有阈值判断都看服务端监控曲线客户端统计只用来看状态码分布。5.2 分布式限流的时间问题这个坑特别隐蔽。我们用Redis做分布式限流限流窗口是每秒一个。压测的时候发现一个奇怪现象限流后拒绝的请求不是均匀分布的而是每隔10秒集中出现一次。用Grafana看曲线每秒的通过量像锯齿一样忽高忽低。排查下来是网关服务器和Redis服务器之间的时间不一致差了大约10秒。网关取本地时间计算窗口但Redis存储和过期用的是它自己的时间两边一错位本来应该每秒重置的计数变成了每隔10秒才重置一次。解决办法统一用NTP同步所有节点时间或者限流逻辑里不使用本地时钟把窗口计算的基准也放到Redis端。测试的时候我会专门加一个检查项看限流器的重置周期是否精确等于你配置的窗口周期。5.3 半开探测是“隐形老虎”刚开始做熔断测试我以为只要验证“半开时能放请求过去”就完了。直到有一次我把熔断恢复的阈值配置成“5秒内连续成功30次”但没有限制半开时的并发数。结果下游故障恢复后系统进入半开一瞬间所有积压的请求加上正常请求全部涌向下游直接把刚恢复的下游又打挂了。后来学乖了半开期间的探测流量一定是受限且低速的。测试用例里要明确验证半开期间下游收到的请求速率被限制在一个安全范围而不是让一堆请求去试错。这实际上是“限流”能力在熔断状态里的一种特殊应用两者并不割裂。5.4 测试流量污染监控数据做韧性测试的时候如果测试流量没有特殊标记它和真实流量混在一起会污染监控和告警。我就曾经在压测的时候忘了在请求头里加测试标记结果值班同学看到错误率飙升差点按了线上回滚按钮。从那以后我所有压测脚本的请求头里都会带一个统一标识比如X-Test-Mode: resilience-test然后在监控大盘上把这些流量单独分到一个面板或者直接过滤掉。另一个办法是使用独立的测试域名或测试端口从入口就把流量分开。6. 把韧性测试变成日常从手动到自动做完一次完整的限流熔断测试不代表以后就高枕无忧了。系统会变配置会改依赖的第三方服务也在迭代。韧性测试这件事最好做成一套可以重复执行的机制而不是一次性项目。6.1 一份可以重复执行的Checklist我把多次实战中沉淀下来的检查项整理成了一张清单每次版本发布前跑一遍。你可以直接拿过去改。注意不含任何“代理”字样只针对API自身能力。检查项建议频率说明限流阈值是否与当前容量匹配每次容量变更后比如扩容后单机QPS阈值需要同步上调限流响应状态码是否符合客户端预期每次发布客户端的异常处理逻辑依赖这个状态码熔断慢调用阈值是否覆盖真实下游SLA每月第三方接口变慢时现有阈值能否识别半开探测流量是否安全每次规则变更防止恢复瞬间压垮下游统一时钟是否正常每季度分布式限流的准确性依赖它故障注入开关是否全部恢复每次演练结束防止残留故障影响后续测试6.2 在CI/CD里嵌入韧性测试基础的限流熔断验证完全可以做成自动化冒烟测试。我在CI流水线里的做法是预发环境部署好之后跑一组k6脚本固定压几个关键API到阈值以上。断言“超过阈值后返回的状态码符合预期”和“低于阈值时全部成功”。熔断相关测试没法每次都跑全量故障注入因为成本高、耗时长。我会拆成两层常规CI只跑“规则静态校验”比如配置里的阈值是不是负数、状态码是不是合法真正的故障演练走定时任务比如每周一次全自动故障注入生成报告推送到团队群。下面是一个GitLab CI里嵌限流冒烟测试的简化写法stages: - resilience resilience-smoke: stage: resilience script: - k6 run scripts/rate-limit-smoke.js rules: - if: $CI_PIPELINE_SOURCE merge_request_event如果你的CI不好跑k6也可以用Go或Python写个小工具直接调被测API发请求逻辑一样只是性能不如k6。不管用什么只要能截获“超过阈值后行为不一致”的回归就达到了目的。6.3 结合容量评估动态调整参数限流阈值和熔断参数不是“配一次管一年”的东西。最理想的节奏是每次做容量评估后同步调整限流阈值每次下游依赖做重大变更后重跑熔断测试。容量评估本身也需要用到限流测试的数据比如你在压测中发现单实例在250 QPS时CPU才到50%内存还很充裕那么阈值可以设在180-200 QPS留一些余量给突发流量。这个“留余量”的比例取决于你对业务突发的容忍程度。如果业务允许一定排队阈值可以设得贴近容量上限如果不能接受任何排队阈值要更保守。我个人的经验是限流阈值不要只参考CPU和内存还要参考下游依赖能承受的QPS。如果你的API调用的下游数据库只能扛500 QPS你给自己配1000 QPS的限流毫无意义因为下游先倒。所以韧性测试报告里我会把“全链路各节点的容量上限”也列出来限流配置最终要取整条链路上的最小值作为上限参考。在我实际操作中的体会是测试API韧性这件事最大的障碍往往不是工具而是心理上“敢不敢让系统真的坏一次”。很多团队怕出问题故障注入只敢做到“模拟错误码返回”不敢真的把下游延迟拉到三秒。但恰恰是这种真实延迟才能暴露出线程池耗尽、连接池排队、客户端重试风暴这些藏在纸面规则背后的问题。每次完整跑完一轮限流和熔断测试我几乎都能在配置里发现至少一个“以为没问题但实际有问题”的点。这些点早发现一天线上就少一分事故概率。最后再分享一个小技巧每次演练结束把当时的压测报告、配置快照、故障注入参数一起归档。下次系统参数调整后直接拿同一套脚本重跑看数据对比就知道哪些改动是正向的哪些是负向的。这个习惯帮了我很多次。 
长河君 · 2026/10/13 2:05:28 · 阅读 1.2k 系统化测试API限流与熔断：关键步骤、工具与避坑指南
凌晨一点线上告警把我从床上叫起来。运营搞了一波促销流量比平时涨了五倍我们服务入口的QPS直接冲到峰值。诡异的是数据库、Redis、下游支付回调都还没到瓶颈整个API却先“自杀”了——大量请求超时、线程池被打满、错误率直线上升。后来复盘才发现限流阈值是配了但配得太宽松形同虚设熔断虽然开了但下游抖动了一下就立刻恢复根本来不及触发。那一次事故让我意识到一个很现实的问题大多数系统不是没有限流和熔断而是从来没人认真测过它们到底能不能在关键时刻起作用。这篇文章想聊聊怎么系统地去测试API的限流和熔断能力。也就是所谓的“API韧性测试”通过人为制造流量过载、下游故障验证系统在最坏情况下能不能按设计好的方式兜住。文章会包含测试前的指标设计、限流和熔断的实操步骤、压测工具的选型以及我踩过的一堆坑。适合正在做网关、微服务或者对外开放API的同行参考。1. 限流和熔断到底在保护什么测试之前先把机制想透很多测试同学拿到限流熔断需求第一反应是“找工具压一下看返回啥”。这没有错但容易忽略一个前提你连这两个机制各自保护什么、失效后果是什么都没想清楚测出来的结果只能叫现象不叫结论。1.1 限流是控制入口熔断是切断故障我习惯用两个生活里的东西来类比。限流就是地铁站进站口的闸机。不管里面站台能装多少人闸机每分钟放进多少人是有数的。它保护的是“自己”不被超出处理能力的流量击穿。哪怕后端机器性能很好入口流量超出额定容量后服务的线程、内存、数据库连接都会被打爆。熔断则是家里配电箱里的保险丝。当线路里的电流异常变大或者有设备出故障时保险丝先断掉切断整个回路保护后面的电器不被烧毁。它保护的是“调用链上的下游依赖”不被故障拖垮更保护“自己”不被下游的故障拖入泥潭。在API场景下两者的边界非常清楚限流针对的是“进来的请求太多”对应的是自身容量上限。熔断针对的是“调用的下游不可用或变慢”对应的是外部依赖的故障。一个典型的例子你的API调用第三方支付网关支付网关偶尔超时。如果网关超时5秒而你所有线程都在等这个5秒很快就没线程处理其他正常请求了。这时应该熔断让后续请求直接快速失败而不是继续排队等一个大概率会失败的调用。而限流测的是当入口QPS超过你配置的阈值比如单机200 QPS多出来的请求是被拒绝、还是排队、还是走了降级逻辑。1.2 混为一谈的代价我见过的最常见的配置错误这个例子我印象特别深。有一个团队上线前配置了Sentinel的限流和熔断规则但测试的时候只做了一件事把QPS压到阈值以上看到有请求返回“Blocked”就认为功能验证完了。结果上线没两天下游MySQL一抖动服务端线程全部hang住。为什么因为他们的熔断规则配的是“慢调用比例超过50%才熔断”但当时慢调用的判定阈值是1000ms而MySQL抖动的耗时只有800ms。800ms的调用不计入“慢调用”熔断器根本不动作线程池照样被拖死。这个案例说明一个道理测试限流熔断不只是测试“配置是否生效”而是要测试“失效条件是否匹配真实故障场景”。限流阈值设多少、熔断的慢调用阈值是多少毫秒、错误比例达多少触发、半开状态下放多少探测流量这些参数之间是联动的。测试人员的核心工作就是把每个参数背后的行为逻辑验证一遍。所以在写压测脚本之前先把下面几个问题想明白限流阈值是多少在哪一层限流网关、应用、还是DB连接池超限后是返回429还是503客户端拿到这个状态码会怎么做熔断打开后请求是抛异常、返回兜底数据、还是直接快速失败多久之后进入半开半开期间放多少请求过去这些问题没有标准答案取决于你的业务场景。但测试用例必须按照你系统的设计来写。2. 测试环境与指标设计避免测了个寂寞韧性测试最忌讳的事是在一个和线上差异很大的环境里跑得出一个看起来很完美、实际上没用的结果。我通常把准备阶段拆成三块环境怎么搭、指标怎么定、流量怎么造。2.1 隔离环境怎么搭如果条件允许尽量在独立的测试环境或预发环境的独立分组里做不要直接在线上主链路做全量压测。我踩过的坑是直接在预发环境压结果把预发依赖的公共Redis连接打满了吓得运维把整个预发集群重启了一遍。比较可靠的做法是用Docker Compose拉起一套最小化拓扑被测API服务一个或两个实例依赖的下游服务用Mock实现可以动态注入故障Redis用于分布式限流或状态存储Prometheus Grafana观测指标下面这个Compose片段是我常用的基础模板version: 3 services: api: build: ./api ports: - 8080:8080 depends_on: - mock-upstream - redis mock-upstream: build: ./mock-upstream ports: - 9090:9090 redis: image: redis:7-alpine prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml注意一个细节被测服务和Mock服务的时钟最好通过NTP同步或者统一用容器宿主机的时间。限流很多是基于时间窗口的比如固定窗口每秒重置如果服务容器和Redis的时钟差了几秒限流的周期会变得乱七八糟测出来的数据根本没法解释。这一点后面我会专门讲一个真实案例。2.2 定义你关心的指标限流阈值、拒绝码、恢复时间在开始压测之前我建议先列一张指标表明确每个指标的期望值和观测方法。没有这张表你压完只会得到一堆孤立的数字不知道到底算通过还是失败。下面是我做限流熔断测试时常用的指标表指标期望值示例观测方法实际触发限流的QPS不超过配置阈值的±5%服务端日志、网关access log、Prometheus QPS曲线限流拒绝的状态码429或503按设计约定压测脚本统计响应码分布限流拒绝的延迟10ms压测工具输出熔断打开时间达到错误率阈值后立即快速失败调用链监控、熔断器状态指标熔断半开探测成功后的恢复时间按配置比如5秒内连续观测请求成功比例故障注入期间的系统错误率用户侧错误率受控在可接受范围错误率监控有一点特别重要压测脚本里不要只统计“请求总数”和“失败数”要区分“业务成功”和“被限流拒绝”。被限流拒绝其实不是系统错误而是系统正常工作。我见过有团队把429当成错误率统计导致告警震天响实际上系统一切正常。2.3 压测工具的流量模型怎么选工欲善其事必先利其器。压测工具这件事上没有银弹只有适不适合。我的习惯是小验证用wrk或ab复杂场景用k6精细控制用Locust或自研脚本。几款工具的快速对比工具优势短板ab简单装完就能用只适合低并发简单压测wrk高性能单机可以打出很高QPS脚本能力有限统计维度少k6云原生友好JS脚本灵活内置指标丰富学习成本比wrk高LocustPython写脚本协程并发高并发能力取决于Python性能做韧性测试和普通压测有个核心区别流量模型必须是变化的。千万不要只用恒定速率打。限流测试要验证的是系统在“超过阈值”和“低于阈值”之间切换时的行为所以至少要有三种模型阶梯式每30秒提高一档QPS逐步越过阈值观察限流器生效点。突发式维持整体平均QPS低于阈值但每隔几秒打一波高QPS脉冲观察突发是否被削平。波浪式QPS在阈值上下周期性摆动观察系统能否快速适应不会振荡。这几种模型针对的是不同限流算法。固定窗口限流在突发场景下可能有双倍流量漏洞令牌桶限流则允许一定突发。不把流量模型设计好根本测不出算法之间的差异。3. 限流测试怎么打从阈值校验到算法行为验证限流测试看起来最简单压一压就行但真测的时候细节非常多。这一节按我的实操顺序讲先验证阈值再验证算法行为最后验证限流后的业务表现。3.1 阈值生效性验证200 QPS压一个100 QPS的接口第一步永远是最基础的确认配置的限流阈值真实生效。假设你在API网关里给某个接口配置了单实例100 QPS的限流规则。我的做法是先用120 QPS的恒定流量压5分钟再换成80 QPS压5分钟观察被拒绝的请求数量变化。120 QPS阶段应该能看到持续有请求被拒绝拒绝数约为20 QPS。80 QPS阶段不应该有拒绝。这里有个大坑分布式限流场景下阈值是每实例还是全局如果规则是每实例100 QPS而你压测流量经过负载均衡分发到了两个实例那么总入口QPS到了200 QPS才会有拒绝。你在压测脚本里看到“入口都150 QPS了还没拒绝”先别急着怀疑配置先确认一下是不是被负载均衡分摊了。这个误判我至少见过三次。用k6写一个简单脚本验证阈值非常方便import http from k6/http; import { check, sleep } from k6; export const options { scenarios: { constant_load: { executor: constant-arrival-rate, rate: 120, // 目标RPS duration: 5m, preAllocatedVUs: 50, }, }, }; export default function () { const res http.get(http://api.example.com/test); check(res, { 200 received: (r) r.status 200, 429 expected under limit: (r) r.status 429, }); }跑完之后看两个数200的分布和429的分布。如果120 RPS下429数量很稳定地保持在一个值附近说明限流生效如果429数量忽高忽低说明后端可能有多实例或网络引入的不确定性要去排查流量分发。3.2 算法差异会改变你的测试结论限流算法不是只有一种而不同算法的测试表现差异很大。常见的几种固定窗口按时间窗口计数窗口结束就清零。实现简单但窗口切换瞬间可能出现两倍流量“冲进来”。滑动窗口按子桶统计平滑度更好但实现复杂些。令牌桶以固定速率往桶里放令牌桶有容量上限。允许一定程度的突发整体平均速率受限。漏桶请求以固定速率被处理超出部分排队或丢弃。削峰效果强但可能增加延迟。我自己的一个实测案例某平台的网关用的是固定窗口限流配置的是100 QPS。我用突发模型测试每个窗口的最后100ms打进来150个请求结果这150个请求几乎全部通过了。原因是在窗口末尾计数还没到100所以不拒绝等窗口翻转计数清零新的请求又畅通无阻。这个双倍流量漏洞只有在窗口边界才会出现用恒定速率压测根本测不出来。所以测试限流算法至少要覆盖下面几个场景场景期望行为测试方法恒定流量低于阈值全部通过恒定RPS压测恒定流量高于阈值超出部分被拒绝恒定RPS压测突发流量跨窗口边界可能短暂超过阈值突发脉冲压测流量从高位降到低位系统快速恢复正常阶梯式压测你在测试报告里应该能写清楚“这个限流器允许什么样的突发”而不是只写“限流生效”。3.3 限流后的表现拒绝、排队、降级都要验证限流并不保证一定会直接拒绝请求。有的系统设计是返回429有的是让请求排队等待还有的是直接走缓存降级。测试的时候这三种表现是三种完全不同的用例。直接拒绝模式最好验证超过阈值就立刻返回特定状态码响应时间极短。排队模式要小心请求不会立即失败而是挂在队列里等。如果队列积压太多请求最终会超时。测试排队模式时我会重点关注“最大排队时间”和“队列溢出后的表现”。压测脚本里要分别统计成功、超时、直接被拒、队列溢出四类请求的数量。降级模式最复杂。比如商品详情页的库存接口限流了你不能直接报错应该返回缓存中的库存数据。这时候限流测试的断言不是“状态码是429”而是“返回的数据是否来自降级缓存响应时间是否在预期内”。在Mock服务里要造好缓存数据让降级响应和正常响应用字段区分开比如返回体里加一个source: cache标记。另外客户端拿到限流响应后的行为同样重要。如果你的客户端代码看到429就无限重试那限流永远挡不住流量因为重试请求会一波接一波打进来。这在业内有个专门叫法重试风暴。我在测试报告里一定会附上“客户端重试策略检查”这一项确认客户端是等待一段时间再重试还是直接放弃。4. 熔断测试怎么打让下游真实“坏”一次熔断测试的核心动作是故障注入。难点在于你要让下游真实地坏一次又不能把整个测试环境搞到无法恢复。4.1 故障注入的三种可行方式做熔断测试一般有三种方式制造下游故障方式一在Mock服务里开一个“故障开关”这是我最推荐的方式。写一个Mock下游服务暴露两个接口正常接口和故障注入配置接口。通过配置接口可以动态设置延迟多少毫秒比如固定延迟2000ms返回什么状态码500、503、429错误比例是多少比如50%的概率返回500这样测试时只需要调用一次配置接口Mock服务就会按规则开始故障测完再调一次接口恢复。整个过程完全可控。用Spring Boot写这种Mock很简单核心逻辑类似RestController public class FakeUpstreamController { private volatile int delayMs 0; private volatile int errorRate 0; PostMapping(/fault/config) public void config(RequestBody FaultConfig config) { this.delayMs config.getDelayMs(); this.errorRate config.getErrorRate(); } GetMapping(/api/upstream) public String getData() { if (delayMs 0) { try { Thread.sleep(delayMs); } catch (InterruptedException e) { } } if (errorRate 0 ThreadLocalRandom.current().nextInt(100) errorRate) { throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR); } return ok; } }方式二用网络层工具模拟延迟和丢包比如用Linux的tc命令在容器网络接口上注入延迟tc qdisc add dev eth0 root netem delay 2000ms恢复时删掉规则tc qdisc del dev eth0 root这种方式更接近真实网络问题但影响范围是整个容器不能只针对某个接口。适合验证“网络层异常时熔断是否兜得住”。方式三在限流熔断框架里直接触发规则像Sentinel、Hystrix这类框架都提供了手动降级或设置阈值的接口。你可以在测试时把错误比例阈值临时调得很低让熔断器快速进入打开状态。这种方式适合验证“规则配置是否正确”但不适合验证“真实故障能不能被识别”。建议前两种为主这种方式作为补充。无论用哪种方式故障注入一定要有自动恢复机制。我最担心的是有人在测试环境留了个500%错误率的Mock配置第二天别人跑自动化测试跑出一堆莫名其妙的问题排查半天才发现是故障没恢复。4.2 验证熔断的三个状态关闭、打开、半开熔断器有三个状态关闭Closed、打开Open、半开Half-Open。测试的目标是确保状态转换符合预期。我用一个具体流程说明假设熔断规则是10秒内错误率超过50%触发熔断熔断持续5秒半开放行5个探测请求若成功则关闭熔断。测试步骤初始校验关闭状态正常流量调用下游确认所有请求都成功熔断器保持在关闭状态。制造故障把Mock服务错误比例调成100%。观察打开状态持续调用一段时间超过统计窗口看到熔断器状态变为打开。此时继续请求应该立即返回快速失败不再等待下游响应。用压测脚本统计打开状态下请求的平均延迟应该远小于正常调用延迟因为根本没往下游发。撤除故障把Mock错误比例调回0%。等待半开熔断器的半开时间到了它会放行少量探测请求。如果探测请求成功熔断器关闭后续请求恢复正常如果探测失败熔断器重新打开重新计时。验证每个状态时我习惯用状态机视角来组织用例状态触发条件预期行为观测点Closed错误率低于阈值正常转发请求下游调用次数正常Open错误率超过阈值快速失败不调用下游下游调用次数骤降为0Half-OpenOpen持续到计时结束放行少量探测请求下游调用次数很低的尖峰Closed恢复探测成功率达到阈值全部流量恢复下游调用次数恢复正常这里有一个细节很多人会忽略熔断器打开后不是所有请求都走快速失败而是要走你预先设计好的降级逻辑。比如返回兜底数据、返回空列表、返回本地缓存。测试断言里要检查的是“熔断后返回的到底是什么”而不只是“请求没超时”。4.3 客户端重试与半开探测的联动测试熔断测试做到后面一定要把“上游客户端的重试行为”纳入范围。但我还要提醒一句必须避开“代理”这个词用“网关层”“接入层”表达就好。我见过一个真实事故熔断器正常打开了上游客户端也正常收到了快速失败的错误码。但客户端重试策略是“失败后立即重试5次”等到熔断器半开时瞬间涌入了大量重试请求。本来半开只放行5个探测请求结果因为那些重试请求也在路上直接超过了下游的承受能力。下游刚恢复被这一波重试又打挂了。这就是典型的“熔断恢复过程引发的二次故障”。因此测试用例里要专门验证客户端在熔断打开期间重试次数是否受限客户端重试的间隔是否采用了指数退避熔断进入半开后探测请求和正常请求、重试请求混在一起时是否会挤爆下游我通常的做法是在压测脚本里同时模拟两类客户端一类是“老实的客户端”收到快速失败就停手另一类是“激进的重试客户端”收到错误就疯狂重试。然后观察熔断器半开状态下系统表现是否仍然可控。如果不可控问题不在熔断器而在客户端的重试策略这个结论会写进报告里直接推动客户端改造。5. 那些坑我们的测试把自己坑了韧性测试做了几年很多坑都是自己踩出来的。踩得多了我发现它们大多不是技术上的“疑难杂症”而是很基础的问题。单独拿出来说是想让后来的人少花点冤枉时间。5.1 压测统计口径不一致第一次做限流测试的时候我用wrk压接口wrk显示QPS是950压测机网卡都快打满了。但到服务端看日志实际收到的请求只有800 QPS。差了150 QPS这个数字直接让我判断限流“提前生效”了。后来查了半天原因是wrk为了维持高并发让大量连接处于Keep-Alive复用状态但服务端连接池有上限一部分请求在TCP层就被拒了根本没进到应用层。所以压测工具输出的是“客户端发出的请求数”服务端统计的是“应用层收到的请求数”两者天然就不一样。结论以服务端日志和中间件指标为准压测工具的QPS只做参考。以后我做限流测试所有阈值判断都看服务端监控曲线客户端统计只用来看状态码分布。5.2 分布式限流的时间问题这个坑特别隐蔽。我们用Redis做分布式限流限流窗口是每秒一个。压测的时候发现一个奇怪现象限流后拒绝的请求不是均匀分布的而是每隔10秒集中出现一次。用Grafana看曲线每秒的通过量像锯齿一样忽高忽低。排查下来是网关服务器和Redis服务器之间的时间不一致差了大约10秒。网关取本地时间计算窗口但Redis存储和过期用的是它自己的时间两边一错位本来应该每秒重置的计数变成了每隔10秒才重置一次。解决办法统一用NTP同步所有节点时间或者限流逻辑里不使用本地时钟把窗口计算的基准也放到Redis端。测试的时候我会专门加一个检查项看限流器的重置周期是否精确等于你配置的窗口周期。5.3 半开探测是“隐形老虎”刚开始做熔断测试我以为只要验证“半开时能放请求过去”就完了。直到有一次我把熔断恢复的阈值配置成“5秒内连续成功30次”但没有限制半开时的并发数。结果下游故障恢复后系统进入半开一瞬间所有积压的请求加上正常请求全部涌向下游直接把刚恢复的下游又打挂了。后来学乖了半开期间的探测流量一定是受限且低速的。测试用例里要明确验证半开期间下游收到的请求速率被限制在一个安全范围而不是让一堆请求去试错。这实际上是“限流”能力在熔断状态里的一种特殊应用两者并不割裂。5.4 测试流量污染监控数据做韧性测试的时候如果测试流量没有特殊标记它和真实流量混在一起会污染监控和告警。我就曾经在压测的时候忘了在请求头里加测试标记结果值班同学看到错误率飙升差点按了线上回滚按钮。从那以后我所有压测脚本的请求头里都会带一个统一标识比如X-Test-Mode: resilience-test然后在监控大盘上把这些流量单独分到一个面板或者直接过滤掉。另一个办法是使用独立的测试域名或测试端口从入口就把流量分开。6. 把韧性测试变成日常从手动到自动做完一次完整的限流熔断测试不代表以后就高枕无忧了。系统会变配置会改依赖的第三方服务也在迭代。韧性测试这件事最好做成一套可以重复执行的机制而不是一次性项目。6.1 一份可以重复执行的Checklist我把多次实战中沉淀下来的检查项整理成了一张清单每次版本发布前跑一遍。你可以直接拿过去改。注意不含任何“代理”字样只针对API自身能力。检查项建议频率说明限流阈值是否与当前容量匹配每次容量变更后比如扩容后单机QPS阈值需要同步上调限流响应状态码是否符合客户端预期每次发布客户端的异常处理逻辑依赖这个状态码熔断慢调用阈值是否覆盖真实下游SLA每月第三方接口变慢时现有阈值能否识别半开探测流量是否安全每次规则变更防止恢复瞬间压垮下游统一时钟是否正常每季度分布式限流的准确性依赖它故障注入开关是否全部恢复每次演练结束防止残留故障影响后续测试6.2 在CI/CD里嵌入韧性测试基础的限流熔断验证完全可以做成自动化冒烟测试。我在CI流水线里的做法是预发环境部署好之后跑一组k6脚本固定压几个关键API到阈值以上。断言“超过阈值后返回的状态码符合预期”和“低于阈值时全部成功”。熔断相关测试没法每次都跑全量故障注入因为成本高、耗时长。我会拆成两层常规CI只跑“规则静态校验”比如配置里的阈值是不是负数、状态码是不是合法真正的故障演练走定时任务比如每周一次全自动故障注入生成报告推送到团队群。下面是一个GitLab CI里嵌限流冒烟测试的简化写法stages: - resilience resilience-smoke: stage: resilience script: - k6 run scripts/rate-limit-smoke.js rules: - if: $CI_PIPELINE_SOURCE merge_request_event如果你的CI不好跑k6也可以用Go或Python写个小工具直接调被测API发请求逻辑一样只是性能不如k6。不管用什么只要能截获“超过阈值后行为不一致”的回归就达到了目的。6.3 结合容量评估动态调整参数限流阈值和熔断参数不是“配一次管一年”的东西。最理想的节奏是每次做容量评估后同步调整限流阈值每次下游依赖做重大变更后重跑熔断测试。容量评估本身也需要用到限流测试的数据比如你在压测中发现单实例在250 QPS时CPU才到50%内存还很充裕那么阈值可以设在180-200 QPS留一些余量给突发流量。这个“留余量”的比例取决于你对业务突发的容忍程度。如果业务允许一定排队阈值可以设得贴近容量上限如果不能接受任何排队阈值要更保守。我个人的经验是限流阈值不要只参考CPU和内存还要参考下游依赖能承受的QPS。如果你的API调用的下游数据库只能扛500 QPS你给自己配1000 QPS的限流毫无意义因为下游先倒。所以韧性测试报告里我会把“全链路各节点的容量上限”也列出来限流配置最终要取整条链路上的最小值作为上限参考。在我实际操作中的体会是测试API韧性这件事最大的障碍往往不是工具而是心理上“敢不敢让系统真的坏一次”。很多团队怕出问题故障注入只敢做到“模拟错误码返回”不敢真的把下游延迟拉到三秒。但恰恰是这种真实延迟才能暴露出线程池耗尽、连接池排队、客户端重试风暴这些藏在纸面规则背后的问题。每次完整跑完一轮限流和熔断测试我几乎都能在配置里发现至少一个“以为没问题但实际有问题”的点。这些点早发现一天线上就少一分事故概率。最后再分享一个小技巧每次演练结束把当时的压测报告、配置快照、故障注入参数一起归档。下次系统参数调整后直接拿同一套脚本重跑看数据对比就知道哪些改动是正向的哪些是负向的。这个习惯帮了我很多次。