大多数线上故障并不是突然发生的，而是容量问题在高峰期被放大后的结果。等到真实用户把流量打上来再去定位瓶颈，代价往往是服务不可用。把性能压测前置到上线之前，用可控的模拟流量把系统逼到临界点，是把风险从生产环境挪到测试环境的有效做法。

为什么要在上线前做压测

压测的本质不是"证明系统很快"，而是回答三个问题：系统能扛住多少、在什么条件下会先撑不住、撑不住时会发生什么。

• 成本更低：测试环境暴露的问题，修复成本远低于生产事故；
• 决策有据：扩容多少台、加多少带宽、要不要拆分数据库，都需要压测数据支撑，而不是凭经验估算；
• 验证预案：限流、降级、熔断等保护机制只有在压力下才能真正验证是否生效；
• 建立基线：每次迭代前后对比同一套压测结果，可以及早发现性能回退。

先定义压测目标，再选工具

没有目标的压测只会得到一堆无意义的数字。开始之前应先明确要观测的指标：

• 吞吐能力：QPS、TPS，以业务口径为准，而不是以单个接口为准；
• 响应时间：关注 P95、P99 等分位值，平均值会掩盖长尾问题；
• 错误率：超时、5xx、连接被拒的比例；
• 资源水位：CPU、内存、磁盘 IO、网络带宽、文件句柄、连接数；
• 饱和点：继续加压时吞吐不再上升、响应时间明显抬升的拐点。

工具选择上，JMeter、Locust、k6、Gatling、wrk 等都可以完成基础压测，关键不在工具，而在于压测机本身不能成为瓶颈，并且压力模型要贴近真实业务。

压测场景怎么设计

1. 单接口基准测试

逐个摸清核心接口的处理能力，得到单点的性能上限，作为后续混合场景的基础。

2. 业务混合场景

按真实流量比例混合读写请求。很多系统单接口表现良好，一旦读写在同一条链路上竞争资源，瓶颈会立刻显现。

3. 峰值与尖峰测试

模拟秒杀、开抢、定时任务集中触发等瞬时冲击，观察队列积压、连接池耗尽和自动扩容的响应速度。

4. 稳定性测试

以中等压力持续运行较长时间，用于发现内存泄漏、连接未释放、日志暴涨、磁盘写满等缓慢累积的问题。

5. 破坏性测试与故障注入

主动制造节点宕机、依赖超时、中间件抖动，验证集群的故障转移与降级逻辑是否按预期工作。

让压测环境尽量接近生产

• 数据量要够：在空表上压出来的结果没有参考价值，索引和查询计划会完全不同；
• 拓扑要一致：网关、负载均衡、缓存、数据库、消息队列的层级和配置应尽量对齐；
• 做好隔离：压测流量不能污染生产数据，必要时使用影子表、影子库或独立命名空间；
• 全链路压测：涉及多服务调用时，在链路上打标，让压测请求贯穿上下游而只写入隔离的数据通道。

瓶颈通常出现在哪里

压测中最常暴露的问题，一般集中在以下几类：

1. 应用层：线程池或连接池配置过小、同步阻塞调用、锁竞争、频繁 Full GC、日志同步落盘；
2. 数据库：慢 SQL、缺失索引、大事务、连接数打满、读写相互影响；
3. 缓存：命中率偏低导致请求穿透到数据库，或热点 Key 集中到单个节点；
4. 中间件：消息堆积、消费能力不足、队列深度配置不合理；
5. 网络与网关：带宽跑满、TIME_WAIT 过多、TLS 握手开销、NAT 或四层转发成为单点；
6. 下游依赖：第三方接口限流或超时，把上游线程全部拖住。

定位瓶颈时要结合压测端的错误分布、服务端的监控曲线和链路追踪数据一起看，单看某一层容易误判。

从压测结果到扩容与优化

拿到瓶颈结论后，处理顺序建议是先优化、再扩容，因为无效的优化往往会被无意义的扩容掩盖。

• 代码与配置优化：消除慢查询、增加合理缓存、改同步为异步、调整线程池与连接池、压缩日志输出；
• 架构优化：读写分离、分库分表、热点数据拆分、引入消息队列削峰；
• 保护机制：配置限流阈值、降级开关和熔断策略，让系统在超载时优先保住核心链路；
• 横向扩容：无状态服务优先通过增加实例分摊压力，并同步确认数据库、缓存、带宽等共享资源是否同步扩容，避免出现"应用扩了、数据库先崩"的情况；
• 纵向扩容：针对内存、CPU 密集型场景升级单机规格，但要注意单机上限与故障影响面。

常见误区

• 只压单个接口，不看混合链路；
• 用配置远低于生产的测试环境得出结论；
• 忽略下游依赖，把压力全部压在自家服务上；
• 只看平均值，不看长尾延迟；
• 压测结束后没有沉淀容量基线，下次又从零开始。

把压测变成常态

一次压测只能说明某一个版本、某一种配置下的状态。更可靠的做法是把它纳入常规流程：新版本上线前跑一遍核心场景，大促或业务增长前做容量评估，日常保留一套可复用的压测脚本和监控看板，并记录每次结果的容量水位。这样当流量真正上涨时，扩容依据来自数据，而不是来自事后的估算。