运维体系管理课番外稳定性压测实战用真实数据把令牌桶限流说透本文是《运维体系管理课四极端场景下的稳定性保障》的配套压测实战番外。代码能跑、指标能看但「你写的限流真的限得住吗」——这个问题只有压测能回答。全部数据来自对真实公网网关1.92.121.130:5000的请求未做任何修饰。一、引言限流代码再漂亮不压测就是“我以为它能扛”在四里我们用一个真实跑在云服务器上的 gateway backend 双服务 Demo把令牌桶限流、全链路追踪、Prometheus 监控讲了一遍。代码能跑、指标能看但有一个问题没回答你写的限流真的限得住吗限流逻辑写得再优雅不经过压测验证就是「我以为它能扛」。本文是对那篇实验的真实压测实战用一段纯标准库脚本对公网网关发起真实流量用数据回答三个问题——突发流量下桶容量到底能放多少稳态下成功吞吐被锁在多少 QPS限流会不会污染业务延迟被测服务令牌桶参数容量 capacity10补充速率 fill_rate2 个/秒。二、测试设计场景配置要验证什么A · 冷启动突发20 次顺序请求桶容量决定的「一次性突发放行数」B · 持续高并发20 线程并发持续 30s稳态限流速率 成功请求延迟水位指标对账压测前后抓取/metrics用 Prometheus Counter 增量交叉验证本地统计。压测脚本lab/stability/stress_test.py纯标准库实现任意机器可跑。三、场景 A突发不是你想的「10 个就满」实际状态码序列200 200 200 200 200 200 200 200 200 200 200 200 429 200 429 429 429 200 429 429指标结果总请求20200放行14429限流63.1 为什么不是理想化的「10 个 200 10 个 429」很多人会直觉认为容量 10所以前 10 个过、后 10 个限流。但真实网络顺序请求是有耗时的——20 次 curl 跨公网往返约 2 秒期间令牌桶按2 个/秒持续补充额外给了约 4 个令牌可放行总数 初始容量(10) 补充令牌(2/s × ~2s ≈ 4) 14 → 与实测 14 个 200 完全吻合 ✅这正是令牌桶「允许突发 速率约束」本质的现场证据桶不是「一次性 10 个就清空」而是边消耗边补充。这个数据比理想化的 10/10 更有教学价值——它证明限流速率是真的在「流动」的而不是一个静态阈值。四、场景 B稳态把成功吞吐死死锁在 2 QPS指标结果总请求5660200放行70429限流5590成功吞吐≈ 2.33 QPS延迟 P500.116 s延迟 P950.128 s延迟 P990.131 s延迟 Max0.132 s4.1 稳态放行数 10 2×30数学完全闭合场景 B 前程序sleep(6s)让桶重新补满容量 10。因此成功请求数 初始突发(10) 稳态速率(2/s) × 时长(30s) 10 60 70 → 与实测 70 完全吻合 ✅20 并发持续轰击下系统始终把成功吞吐锁在fill_rate2/s附近实测 2.33 QPS含初始突发摊薄其余98.8%流量被果断拒绝。429 占比 5590 / 5660 ≈ 98.8%有损保护生效核心链路backend 调用只承接了它扛得住的流量。4.2 限流不污染业务延迟成功请求延迟稳定在 P50≈116ms / P99≈131ms含 gateway→backend 本机调用。被限流的 429 在中间件层直接返回未进入业务处理、未计入http_request_latency_seconds——这正是不让限流逻辑本身污染延迟指标的正确设计。看板上不会出现「因为限流导致延迟飙升」的假警报。五、Prometheus 指标对账Counter压测前压测后增量压测统计对照http_requests_total2157015680场景 A(20) 场景 B(5660) 5680 ✅rate_limited_total1056065596场景 A(6) 场景 B(5590) 5596 ✅Counter 增量与压测脚本本地统计逐项一致证明指标采集链路可信可直接作为 Grafana 看板与告警的数据源。六、接上 Grafana 看板压测过程全程可见把/metrics接入 Prometheus Grafanalab/stability/monitoring/提供一键docker-compose导入grafana-dashboard.json9 个面板压测期间可实时观察请求速率按状态200 速率被锁在 ~2/s429 速率随并发陡增到数百/s限流占比迅速逼近 100%延迟分位P50/P95/P99保持平稳无限流导致的延迟尖刺限流触发速率 / 限流总数与rate_limited_total增量同步爬升。看板让「限流生效」从一句断言变成一条可观测的曲线。七、结论与运维启示令牌桶参数即 SLA 旋钮capacity决定抗压突发能力fill_rate决定长期承载能力。本实验2/s的稳态吞吐就是该接口在「保质量」前提下能承诺的上限。限流是「有损保核心」不是「尽量扛」98.8% 的流量被拒但 backend 始终只处理它能处理的量系统不崩、延迟不劣化。可观测性是限流的前提没有http_requests_total/rate_limited_total/ 延迟直方图你根本不知道限流是否生效、阈值该不该调。压测要打「稳态」单次顺序突发只能看容量持续并发才能暴露稳态速率与延迟水位——两者结合才构成完整的容量画像。复现命令cdlab/stability python3 stress_test.py--burst20--workers20--duration30# 结果写入 stress_results.json看板见 monitoring/ grafana-dashboard.json八、小结本文用一次真实压测把四里那个「能跑的限流」变成了「验证过的限流」突发场景下14×200 / 6×429印证了令牌桶边消耗边补充的本质稳态场景下成功吞吐锁在 2.33 QPS、429 占比 98.8%证明有损保护真实生效Prometheus 指标与本地统计逐项闭合为 Grafana 看板与告警奠定可信数据基础。限流不是写完就完事而是「写了 → 压了 → 看见了 → 能调了」的闭环。下一篇如果想看我可以接着写「基于压测结果的限流阈值动态调优」。配套源码 / 监控看板完整代码、Grafana 看板 JSON、Prometheus 抓取配置与压测脚本见 Giteehttps://gitee.com/LiaCin/ops-management-course 的lab/stability目录含STRESS_TEST_REPORT.md完整技术报告。