消息队列和应用工具产品体系（三）

前面两节解决的是"故障发生时怎么扛住"。这一节问一个更根本的问题：系统到底能扛多大的量，不能靠猜，得靠压测提前摸出来。真实流量一来才发现扛不住，那就已经晚了。

想验证哪种负载

性能测试不是单一的一种测试，常见的有几类，各自回答不同的问题：

类型	加压方式	回答的问题
负载测试	逐步加压到预期负载	在预期的正常流量下，系统表现达标吗
压力测试	逐步超过预期负载，在约定的停止条件内探测边界	系统何时不再满足目标，瓶颈在哪里
稳定性测试	长时间维持一定负载	长时间运行会不会出现内存泄漏这类累积性问题

行业里常见的开源压测工具有 JMeter、Locust 这些，但自己搭建压测集群本身成本不低——要模拟真实的高并发流量，压测端自己就得有很强的发压能力，这也是阿里云把压测做成云服务的原因。

用 PTS 怎样施压

PTS（Performance Testing Service，性能测试服务）的前身，是阿里巴巴为了应对双 11 零点全国用户同时涌入而摸索出来的全链路压测方法论。早在 2010 年，阿里内部就提出了线上压测的概念，用单机引流的方式获取单机性能极限；后来发展成全链路压测——通过应用系统改造，让线上环境能够同时承载正常用户流量和压测流量，在不影响真实用户访问的前提下，获得最贴近真实大促场景的承载能力数据。

PTS 正是这套内部实践的产品化延伸：不用自己搭建压测集群，PTS 从云端按需调度压测节点，轻松发起百万级别的并发流量，并且能对流量做精准的脉冲控制。

并发还是 RPS

PTS 的两种压测模式控制的目标不同：

模式	控制目标	适合场景
并发模式	控制同时在线的虚拟用户数（VU）	模拟真实用户行为，验证系统在特定并发量下的表现
RPS 模式	设置目标请求速率（Requests Per Second）	验证特定到达速率下的处理能力

目标 RPS 不等于成功完成的请求数；系统变慢时，在途请求还可能堆积。PTS 压力模型说明区分了这两种施压方式。

一次压测怎么跑

1. 创建压测场景：录制或编写请求脚本，选择并发模式或 RPS 模式，配置目标值
2. 配置加压方式：阶梯式逐步加压，或者直接冲高到目标流量
3. 启动压测：施压的同时实时观察被压测系统的各项监控指标
4. 生成压测报告：压测结束后自动汇总结果

压测报告怎么看

先约定业务可接受的响应时间、错误率和持续运行时长，再判断哪档负载可用。图中只是趋势示意；出现错误还要看错误样本，不能一概归因于容量不足。PTS 报告可以关联成功率、RT、吞吐和采样日志，见报告说明。

指标查阅时可以分开看：

指标	看什么
RT	单次请求的响应时间；平均值可能掩盖慢请求
P95 / P99	95% / 99% 的样本响应时间不高于该值；最慢的一部分仍可能更慢
TPS / QPS	每秒完成的事务数或查询/请求数，先确认报告的统计口径
错误率	失败请求占比，还要区分超时、协议错误与业务校验失败
资源使用率	CPU、内存、网络及依赖服务的水位，用于继续定位瓶颈

如何把结果用于容量规划

容量规划指的是根据业务预期（比如预计大促流量是日常的多少倍）反推需要准备多少台机器、多少实例才够扛住，压测就是用来验证这个规划靠不靠谱的手段。

压测模式上，还有一个关键区分：

• 单场景压测：只针对某一个接口或某一条链路加压，适合验证局部瓶颈
• 全链路压测：模拟真实用户从进入网站到完成下单支付的完整路径，更贴近真实大促场景——这种方式能发现链路上任何一环的短板，因为整体承载能力取决于链路上最弱的那一环（木桶效应），单独测某一个接口很可能测不出这种跨环节的瓶颈

压测毕竟是模拟。真实线上运行时到底什么状态，还得靠持续监控，下一节看 ARMS。