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

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

性能测试：不同的加压方式，回答不同的问题

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

类型	加压方式	回答的问题
负载测试	逐步加压到预期负载	在预期的正常流量下，系统表现达标吗
压力测试	持续加压，超过预期负载直到系统崩溃	系统真实的上限在哪里
稳定性测试	长时间维持一定负载	长时间运行会不会出现内存泄漏这类累积性问题

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

PTS：脱胎于阿里双 11 全链路压测

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

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

基本压测流程：

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

容量规划：压测是用来验证规划对不对的

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

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

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

压测报告怎么看

几个核心指标：

RT（响应时间）：一次请求耗时多久。除了平均值，更要看 P99（99% 的请求响应时间都低于这个值）这类分位数指标——平均值容易被大多数正常请求"拉低"，掩盖极端情况下少数用户的糟糕体验，P99/P95 更能反映真实的用户体验下限
TPS / QPS：系统每秒能处理的事务或请求数，衡量吞吐能力
错误率：压测过程中失败请求占比，超过阈值说明系统已经顶不住了
系统资源使用率：CPU、内存、网络的实时占用，结合监控（下一节的 ARMS）一起看，能判断瓶颈具体卡在哪一层——是应用本身，还是数据库，还是网络

压测告诉你系统的极限在哪、瓶颈在哪一层。但压测毕竟是模拟，真实线上运行时到底什么状态，还得靠监控。下一节看 ARMS。