压力测试的“破防挑战”：魔改现场下你的系统能撑到第几关？
做后端开发的人，最怕的往往不是需求复杂，而是某个平平无奇的周三下午，线上系统突然扛不住流量，“破防”了。平时三五十的 QPS 跑得稳稳当当，活动一来，上千请求涌进来，服务直接超时、报错、重启，集群里的机器一台接一台“躺平”。这时候生产环境还不允许随便改代码，只能先扩容、重启、限流，等流量过去再复盘。
如果只是流量突增，问题还好定位。更麻烦的是另一种情况：系统本身已经被“魔改”过很多轮。为了赶需求，接口里塞了临时判断；为了兼容旧逻辑，SQL 里多了一堆关联；为了快速上线，线程池参数被调到一个“看着能用”的值。短期看速度确实上来了，但没人能说清楚系统真正的容量边界在哪里。
这类系统，我习惯用“魔改现场”来形容。它通常具备几个典型特征：接口文档滞后、负责人多次变更、依赖关系链路混乱、没人敢动核心配置。平时运行看不出问题，等到压力测试或真实流量来临时，所有前期欠下的技术债一起兑现。
这篇文章要把“破防”这件事工程化。我们会用一个常见的 Web 服务作为测试对象，设计一套分级压力测试方案，用 Apache Bench（ab）、JMeter 和简单的监控手段，一步步把系统压到极限，找到它的“破防点”，并给出排查思路。读完以后，你可以把这套方法直接用在团队的项目上，至少在下一个大促或活动流量到来之前，心里有个底。
1. 这篇文章真正要解决的问题
1.1 为什么“魔改”过的系统容易破防
先讲一个很常见的场景。
某个订单查询接口，最初版本只有两步：查订单表，查订单明细表，然后组装返回。后来产品说要在列表页显示用户昵称，于是开发加了一步查用户表；再后来运营说需要显示优惠券抵扣金额，于是又加了一张优惠券表的关联；再后来，为了兼容某个老客户端的特殊参数，开发在接口入口多了一段全局异常吞掉的逻辑。
每一次改动都不大，每段逻辑单独看也说得过去。但半年之后，这个接口真实的资源消耗已经没人能准确说出来了。它到底查了几张表？缓存是否全部走通？有没有一次性把几千条数据加载到内存里过滤？线上监控面板上的平均耗时并没有明显上升，因为低峰期的样本掩盖了问题。
这类系统的共同点是：容量边界完全是个黑盒。你说它能扛多少流量，没人敢拍胸脯。你说它哪里会先崩，没人能给出确定答案。而压力测试的意义，就是把这个黑盒打开，用可控的流量把问题逼出来。
1.2 压测分级为什么有效
如果把所有流量一次性压到系统上，你会发现结果很难分析。系统直接崩溃、连接池打满、数据库 CPU 飙高、GC 频繁触发，多个问题同时发生，你根本分不清哪个是诱因。
分级压测的思路是：像游戏闯关一样，先把系统放到一个“轻松”的档位，确认它能正常运行；再提高到“有压力”的档位，观察哪个环节开始出现劣化；最后一次提到“扛不住”的档位，验证系统在极限状态下的表现和恢复能力。
这样做有三个直接收益：
- 每一关都能得到一组有效的观测数据，方便定位瓶颈。
- 破防时的影响面是可控的，不会把测试环境或预发环境一次性打挂。
- 可以形成一份“容量表”：系统在什么流量级别下表现正常，什么级别开始降级，什么级别必须触发限流。
这套方法不依赖特定的技术栈。Java、Go、Python、Node.js 服务都可以用，框架是 Spring Boot、Gin、FastAPI、Express 也都能套上同样的思路。
2. 基础概念：QPS、TPS、RT、线程数与破防点
2.1 四个核心指标
压力测试里经常出现一组缩写，如果不把这些概念的口径对齐，后面分析数据时很容易产生误解。
| 指标 | 英文全称 | 含义 | 日常关注点 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 对读接口更常用 |
| TPS | Transactions Per Second | 每秒事务数 | 对写操作、完整业务链路更常用 |
| RT | Response Time | 响应时间 | 均值、P99、P95 分别代表不同的体感 |
| 线程数 | Concurrent Threads | 模拟的并发用户数 | 压测工具发起的并发连接数量 |
这里特别想说明 QPS 和 TPS 的区别。很多文章把它们混用，但在实际场景里，一个下单接口的 TPS 是 100，代表着每秒能成功完成 100 笔下单事务；而一个商品详情页的 QPS 是 2000，代表每秒能处理 2000 次查询请求。对一个混合业务系统，压测报告中最好分别标注。
RT 这个指标更值得反复琢磨。只看平均值会掩盖大量问题。举个例子：
- 某个接口平均 RT 是 80ms，但 P99 是 1.2s。
- 说明 99% 的请求在 1.2 秒内完成，但仍有 1% 的请求体验极差。
- 在低并发下，P99 可能正常；一旦并发上来，P99 可能迅速恶化到 3 秒以上。
- 因此压测时，不仅要看平均值，更要盯住 P95、P99 的变化趋势。
2.2 破防点在哪里
所谓“破防点”，我理解为系统从性能稳定区跌落到性能劣化区的那个流量阈值。在这个阈值之前，并发数翻倍，吞吐量也接近翻倍；超过这个阈值后，吞吐量不升反降，RT 快速上涨，错误率开始出现。
这个点在技术上通常对应着某一类资源被耗尽：
- 数据库连接池被打满，获取连接的等待时间变长。
- 应用线程池排队堆积，请求在队列里等不到执行。
- CPU 达到饱和，GC 线程抢占业务线程。
- 文件句柄数达到上限，新连接无法建立。
- 下游接口超时，调用方被拖垮。
所以压力测试不只是把一个接口“打得很慢”，而是要找到第一块倒下的多米诺骨牌。
2.3 新手最容易误解的一件事
很多人第一次做压测，关注点全放在“压测工具能不能打出更高的数字”上。比如跑到场地里调大并发线程数，看到 JVM 报错，就得出结论“系统太弱了”。
其实压测工具打到的是客户端一侧的数字。真正要分析的是更全面的数据：客户端侧 RT、TPS、错误率，服务端侧 CPU、内存、GC、线程池、连接池、数据库慢查询、日志中的异常堆栈。把这些数据放到同一条时间线上看，才能定位破防的真正原因。
3. 环境准备与前置条件
3.1 工具与运行环境
压测不需要非常复杂的工具链，最少可以只用一台测试机、一个压测工具、一个监控命令行。
| 类别 | 工具 | 用途 |
|---|---|---|
| 压测工具 | Apache Bench（ab） | 简单接口压测，适合快速摸底 |
| 压测工具 | Apache JMeter | 复杂场景压测，支持链路和断言 |
| 监控 | top / free / vmstat | 查看服务器 CPU、内存、IO |
| 监控 | JVM 自带命令 jstat / jstack | 排查 Java 应用线程和 GC 问题 |
| 监控 | Prometheus + Grafana | 长期监控和可视化（可选） |
需要说明的是，版本号请以你实际环境为准，本文重点演示通用思路。安装方面，Ubuntu/CentOS 系统一般可以通过包管理器安装 ab，JMeter 则从 Apache 官网下载二进制包解压即用。
3.2 准备一个测试服务
为了让方案可复现，我们准备一个非常简单的 HTTP 接口服务。它提供两个接口：
/api/hello：一个轻量级返回接口，模拟最简单的无状态服务。/api/order/{id}：一个模拟查询订单详情的接口，内部会做一次模拟数据库查询，并加入可控的随机休眠时间。
服务采用 Python 的 FastAPI 编写。选择它是因为示例代码短、可读性好、不依赖复杂的工程骨架。如果你实际项目是 Java 或 Go，这个概念验证方案完全迁移得过去。
# 文件路径：app/main.py import random import time from fastapi import FastAPI from fastapi.responses import JSONResponse app = FastAPI(title="pressure-demo") # 模拟数据库查询耗时：正常情况返回 20~50ms def mock_db_query(): time.sleep(random.randint(20, 50) / 1000) @app.get("/api/hello") async def hello(): return {"code": 0, "message": "ok"} @app.get("/api/order/{order_id}") async def order_detail(order_id: int): mock_db_query() # 模拟部分请求出现偶发慢查询 if order_id % 100 == 0: time.sleep(0.5) return JSONResponse({"code": 0, "data": {"orderId": order_id, "status": "paid"}})启动方式：
pip install fastapi uvicorn uvicorn app.main:app --host 0.0.0.0 --port 8080注意这个服务中故意埋了一个小坑：所有以 100 结尾的订单号，都会触发 500ms 的休眠，模拟数据库慢查询。这个设计是为了后续演示“偶发慢查询如何拖垮整体吞吐”的问题。
4. 核心流程拆解：三级关卡怎么设计
我把压测过程拆成三个关卡。每一关都有明确的验证目标、压测参数和通过标准。
4.1 第一关：单接口基准压测
这一关的目标是拿到系统在没有业务压力时的基线数据。
操作方式相对简单：用 ab 直接请求/api/hello，初始并发数从 1 开始，逐渐增加到 5、10、20。每个档位运行 30 秒，记录 RPS（每秒请求数）和平均 RT。
这关通过的标准是：所有档位的错误率都低于 0.1%，平均 RT 不超过 50ms，并且随着并发数增加，RPS 呈近似线性增长。
第一关通常能暴露的问题包括：服务启动参数明显不合理、文件句柄过小、操作系统网络参数限制等。
4.2 第二关：业务链路压测
业务链路压测的目标是模拟真实用户行为，而不是单接口打满。
这里需要建立一个更接近生产的请求模型。比如一个商城系统中，一次压测脚本可以包含：
- 进入首页，请求一次商品列表。
- 打开商品详情，请求一次商品详情接口。
- 点击下单，请求一次订单创建接口。
- 查询订单状态，请求一次订单查询接口。
每个请求占的比例，按照真实流量来分配。在没有真实流量模型时，可以先用等比模型，比如 6:2:2:1。
这一关的关键是设置正确的思考时间。很多压测脚本为了尽量打出高指标，把思考时间设成 0，导致请求像雨点一样无间隔地砸向服务。这样测出来的数字很“好看”，但并不能反映真实用户行为。真实用户在页面之间会有阅读、点击、输入等一系列延迟，这些延迟会显著降低服务端的瞬时压力。
第二关通过的标准：按照预估的业务峰值 1.5 倍压测时，P99 RT 不超过业务预定的 SLA（比如 500ms），错误率低于 1%。
这一关最容易暴露的问题：单接口没问题，但链路中的数据库连接池不够用、缓存穿透严重、下游接口性能参差不齐。
4.3 第三关：异常与恢复压测
第三关是最接近生产故障的一关。前面两关都把系统控制在“正常运行的边缘”，第三关要故意压垮它，然后观察恢复过程。
操作方式是：在第二关的基础上，逐步增加并发数，每次增加 50%，持续观察。当错误率明显上升、RT 超过 3 秒时，停止加压，保持当前并发继续运行 2 分钟，再逐步卸载压力。
这一关要回答的问题包括：
- 系统破防时，是平滑劣化还是瞬间崩溃？
- 破防后，服务还能不能响应健康检查？
- 压力卸载后，QPS 和 RT 能不能回到破防前水平？
- 有没有内存泄漏、连接未释放、线程卡死等问题？
第三关的关键结论不是“系统最多能扛多少”，而是“系统扛不住之后会不会留下后遗症”。有些系统被压垮一次，即使流量已经退去，数据库连接池也回不了满血状态，这就是典型的恢复能力不行。
5. 完整示例与代码实现
5.1 使用 ab 做第一关压测
ab 是 Apache 自带的压测工具，优点是单条命令即可运行，适合快速验证。
# 并发 10，总共发送 10000 个请求 ab -n 10000 -c 10 http://127.0.0.1:8080/api/hello输出中的几个关键字段：
- Complete requests：成功完成的请求数。
- Failed requests：失败请求数，如果大于 0，需要排查。
- Requests per second：即 QPS。
- Time per request：平均每个请求的耗时。
# 并发 50，加重压 ab -n 50000 -c 50 http://127.0.0.1:8080/api/hello比较两次结果的 QPS、平均 RT、错误率，就能初步判断这个服务在轻量级接口上的容量边界。
5.2 编写 JMeter 测试计划
ab 比较适合单 URL 压测，遇到需要登录态、参数传递、多接口组合的场景，JMeter 更合适。
JMeter 的测试计划本质上是一个 XML 文件，扩展名是.jmx。用 JMeter 图形界面创建测试计划后，可以保存为.jmx文件放进仓库。
下面提供一个简化的 JMX 片段，它创建了一个线程组，模拟 50 个并发用户，循环请求/api/order/{id}：
<!-- 文件路径：jmeter/pressure-test.jmx（节选） --> <TestPlan> <HashTree> <Thread> <stringProp name="ThreadGroup.num_threads">50</stringProp> <stringProp name="ThreadGroup.ramp_time">10</stringProp> <stringProp name="ThreadGroup.duration">120</stringProp> <stringProp name="ThreadGroup.on_sample_error">continue</stringProp> </Thread> <HashTree> <HTTPSampler> <stringProp name="HTTPSampler.domain">127.0.0.1</stringProp> <stringProp name="HTTPSampler.port">8080</stringProp> <stringProp name="HTTPSampler.path">/api/order/${__Random(1,10000)}</stringProp> <stringProp name="HTTPSampler.method">GET</stringProp> </HTTPSampler> </HashTree> </HashTree> </TestPlan>这段配置只是可读性示例，实际 JMX 文件会有更完整的结构。更稳妥的方式是：打开 JMeter 图形界面，添加线程组、HTTP 请求、聚合报告监听器，然后保存。如果用命令行执行，可以这样：
jmeter -n -t pressure-test.jmx -l result.jtl -e -o ./report-n表示非 GUI 模式。-t指定测试计划文件。-l输出原始结果文件。-e和-o生成 HTML 汇总报告。
5.3 用脚本观察服务端状态
压测过程中，实时观察服务端状态比事后看报告更直观。下面是一组简单的 Linux 命令：
# 每 2 秒刷新一次 CPU 和内存信息 top -d 2 # 查看 TCP 连接状态，重点关注 TIME_WAIT 和 ESTABLISHED ss -s # 查看进程占用和线程数 pidstat -p $(pgrep -f uvicorn) 2 # 如果是 Java 应用，还可以用 jstat 观察 GC jstat -gcutil $(pgrep -f DemoApplication) 2000这组命令不用装额外工具，在大多数 Linux 发行版可以直接执行。
5.4 一个简单的 Python 压测脚本
如果你的测试机不允许装 JMeter，或者只想快速验证某个接口，可以用 Python 写一个轻量压测脚本。它用线程模拟并发请求，并统计 P50、P95、P99。
# 文件路径：tools/pressure.py import concurrent.futures import random import statistics import time import urllib.request URL = "http://127.0.0.1:8080/api/order/{}" def send_request(order_id: int) -> float: url = URL.format(order_id) start = time.perf_counter() with urllib.request.urlopen(url, timeout=3) as resp: if resp.status != 200: raise RuntimeError(f"bad status: {resp.status}") return time.perf_counter() - start def run(concurrency: int, requests: int): rts = [] errors = [] with concurrent.futures.ThreadPoolExecutor(max_workers=concurrency) as executor: future_map = {executor.submit(send_request, random.randint(1, 10000)): i for i in range(requests)} for future in concurrent.futures.as_completed(future_map): try: rts.append(future.result()) except Exception as exc: errors.append(repr(exc)) if rts: rts.sort() print(f"并发数: {concurrency}, 请求数: {requests}") print(f"成功数: {len(rts)}, 失败数: {len(errors)}") print(f"QPS: {len(rts) / (sum(rts) or 1):.1f}") print(f"P50: {statistics.median(rts) * 1000:.1f}ms") print(f"P95: {rts[int(len(rts) * 0.95)] * 1000:.1f}ms") print(f"P99: {rts[int(len(rts) * 0.99)] * 1000:.1f}ms") if __name__ == "__main__": run(concurrency=20, requests=2000)这个脚本虽然简单，但已经具备并发请求、结果收集、分位数统计的基本能力。实际使用时，可以把它改成读取 CSV 或 YAML 中的用例配置，从而适配更多场景。
6. 运行结果与效果验证
6.1 预期输出
以 5.1 中的 ab 为例，压测完成后会看到类似下面的输出：
Server Software: uvicorn Document Path: /api/hello Document Length: 30 bytes Concurrency Level: 50 Time taken for tests: 8.123 seconds Complete requests: 50000 Failed requests: 0 Requests per second: 6155.38 [#/sec] (mean) Time per request: 8.122 [ms] (mean)不同机器配置的绝对数值差别会很大，不必追求某一个具体数字。要关注的是趋势：并发从 10 增加到 50，QPS 是否保持增长；RT 是否还在可接受区间。
如果用 5.4 的 Python 脚本压测/api/order/{id}，因为接口内部有 20~50ms 的数据库模拟耗时，且每 100 个请求会触发一次 500ms 的慢查询，输出大致是：
并发数: 20, 请求数: 2000 成功数: 1995, 失败数: 5 QPS: 213.5 P50: 52.1ms P95: 230.4ms P99: 502.8ms这里出现失败需要先确认超时时间设置。如果urlopen的超时时间是 3 秒，而慢查询接口耗时超过 3 秒，就可能抛超时异常。此时并不一定是系统负载过高，而是模拟的慢请求已经超过了客户端等待阈值。
6.2 如何判断系统撑到第几关
判断逻辑可以总结为一个四步走：
- 先看错误率。错误率超过 1% 就说明当前档位已经进入风险区。
- 再看 P99 RT。如果 P99 出现拐点式上升，说明系统内部已经开始排队。
- 然后看系统资源。CPU 是否接近 100%，GC 是否频繁，连接池是否打满。
- 最后看恢复情况。停止压测后，指标回到基线的时间越短，系统恢复能力越强。
把这三条记录到一个简单的表格里，随版本迭代持续积累数据，团队的容量认知就能逐步从“感觉能扛”变成“实测能扛”。
| 压测关卡 | 并发数 | QPS | P99 RT | 错误率 | 破防点 |
|---|---|---|---|---|---|
| 第一关 | 20 | 3200 | 15ms | 0% | 未破防 |
| 第二关 | 100 | 4600 | 180ms | 0.2% | 开始排队 |
| 第三关 | 300 | 2100 | 3200ms | 8% | 数据库连接池耗尽 |
这张表是示意，目的是展示压测报告应该呈现的信息结构。
7. 常见问题与排查思路
压测过程中遇到的问题往往比压测方法本身更值得记录。下面整理高频问题。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| QPS 从某档位开始下降 | 应用线程池或数据库连接池达到上限 | 查看线程池活跃数、连接池等待时间 | 增大线程池上限，或优化业务处理耗时 |
| 错误率突然升高 | 下游接口超时或数据库连接被耗尽 | 查看调用链和慢 SQL日志 | 对下游增加超时时间和重试策略 |
| CPU 使用率很高但 QPS 不升 | 频繁 GC 或死循环 | jstat 观察 GC 频率；jstack 查看线程栈 | 调整 JVM 堆参数，优化对象创建 |
| RT 出现周期性尖刺 | 定时任务、日志刷盘、缓存过期 | 对齐监控时间戳定位尖刺来源 | 错峰执行定时任务，分离日志目录 |
| P50 正常但 P99 很高 | 偶发慢请求引发长尾效应 | 查看慢请求样本，定位耗时点 | 增加缓存，改造慢 SQL，设置降级开关 |
| 压力卸载后连接数居高不下 | 连接没有归还或连接池泄漏 | 检查数据库连接池活跃连接数 | 检查代码中连接管理，启用连接回收 |
这里特别提一下“偶发慢请求引发长尾效应”。很多系统在平均 RT 上表现很好，但用户投诉却集中在“有时卡一下”。这种卡顿通常来自少数慢请求占据了线程池中的线程，导致后续请求排队。比如我们在示例服务中设置的每 100 个订单号触发一次 500ms 慢查询，在低并发时影响不明显；但并发升高后，这种慢请求会让线程池快速堆满，大量正常请求被堵在队列里。
排查这种问题，建议先看服务端的线程池队列长度和活跃线程数，再看慢日志是否集中在某几个接口或某类参数上。不要一上来就优化数据库索引，因为瓶颈可能根本不在数据库。
8. 最佳实践与工程建议
压力测试不能只在项目要上线时才做一次。更合理的方式是把它放进日常研发流程。以下几点是我在实际项目中体会最深的。
8.1 压测环境尽量和生产保持同构
如果测试环境只有单机，生产是四节点集群，那么测试出来的单机 QPS 不能直接乘以 4 当作生产容量。网络拓扑、带宽、数据库规格、缓存规格都会影响最终结果。更稳妥的做法是，在预发环境或独立压测环境复刻生产的部署结构和数据量。
8.2 测试数据不能太少
一个常见的坑是：库表里只有几千条数据，所有查询都命中缓存或索引，压测结果非常好。一旦生产环境有几千万条数据，SQL 执行计划完全不一样。压测前，要将核心表的数据量补充到接近生产环境的规模，至少要保证索引区分度和慢查询特征与生产一致。
8.3 把压测结果沉淀成容量报告
每次压测完成后，除了口头沟通，还要生成一份结构化报告。报告至少包含以下内容：
- 测试时间、测试环境、服务版本。
- 压测模型和并发档位。
- 各档位的 QPS、RT、错误率、系统资源。
- 发现的问题、对应优化项、负责人、截止时间。
有了这份报告，后续优化才有据可查，新同学接手时也不用反复打听“这个系统到底能扛多少”。
8.4 结合限流和熔断一起验证
压测不仅要测系统“能扛多少”，还要验证“扛不住时怎么办”。如果服务配置了限流规则，那么在第三关压测时，应该观察到部分请求被快速拒绝，而不是全部请求都进入后端排队。被拒绝的请求应该返回类似 429 的明确状态码，而不是长时间挂起。
如果下游依赖可能故障，需要验证熔断逻辑是否按预期生效。一个很常用的做法是：在下游服务上人为注入延迟或异常，观察上游是否会快速失败，而不是把线程池拖垮。
8.5 线上压测要做好安全边界
如果必须在生产环境做压测，务必做到以下几点：
- 选择在业务低峰期执行。
- 从最小并发开始逐步增加。
- 提前确认扩容预案和回滚方案。
- 只在隔离的集群节点上执行，并做好标记，避免压测流量进入真实用户链路。
- 压测结束后立即恢复路由和负载均衡配置。
风险控制永远是第一位的，不要在业务高峰期做任何可能影响线上稳定性的验证。
9. 总结与后续学习方向
这篇文章围绕“魔改现场如何破防”这个场景，拆解了一套完整的压力测试思路：先理解 QPS、TPS、RT、P99 这些核心指标，再设计单接口基准、业务链路、异常恢复三个关卡，最后结合 ab、JMeter、监控命令去定位和解决瓶颈。
对于正处于技术债累积期的项目，最重要的是先把容量边界摸清。一旦知道了系统的破防点在哪里，很多决策就变得简单了：什么时候该扩容、什么时候该限流、哪个接口最值得优先优化、哪段代码魔改带来的代价最大。
建议你从自己的项目里选一个核心读接口，按本文的流程做一轮第一关压测，用 ab 或 JMeter 跑上一组数据，输出一份包含并发、QPS、P99 和错误的简单报告。这个动作本身不需要太久，但换来的是对系统容量从猜测到实测的转变。
后续可以继续深入的方向包括：全链路压测平台的建设、基于流量回放的真实验证、性能监控指标与告警阈值的制定，以及限流降级策略与压测结果的联动。把这些环节逐步补齐之后，你就不会再害怕流量突增的“破防挑战”了。
)
