继上一篇JMeter的基本使用介绍（使用Apache JMeter做压力测试），本文介绍如何做SpringCloud分布式系统的全链路压测。
测试策略如上图，基本思路是基于月活跃用户确定执行的并发数，然后用工具模拟压力输出报告，最终我们关心的三个最重要的指标是响应时间、错误率、吞吐量。
吞吐量是反馈系统整体性能很重要的一个指标，也有几个衡量的维度，如QPS、TPS、网络收发的数据量，不同的系统应该采用不同的衡量标准，一般的业务系统会选取TPS，但也不一定客观，因为在系统跟系统横向对比的时候不一定能量化系统性能，因为实际的吞吐量受到调用栈、报文大小和网络环境等的影响，所以还是要因地制宜。
过程中要执行强弱并发压测、极值测试、数据翻倍测试来对当前的系统性能现状客观评估，并对未来长时间的运营提供足够建议。
核心目标由于各系统在系统架构和部署方式千差万别，需要具体分析，设置好一个比较合理的标的是非常重要的。如某系统我们设置的核心目标是各场景在100并发下，超时率<=5%，单接口响应时间<=3s，总体吞吐量TPS >= 100。
可以先不论目标的高低、系统的优劣，只讨论测试本身，那么为了达到这样的目标，数据要翻倍，环境要监控，脚本要录制，另外很重要的是开发团队是要做一些配合修改的，大的层面可以从前后端调优、数据库调优、部署参数调优等各方面考虑。
技术选型| 序号 | 方案 | 优点 | 缺点 | 备注 |
| 1 | LoadRunner | 1、高度自动化 2、可推广性强 | 1、环境准备复杂，需要更长的环境准备时间 2、无法排除网络干扰（丢包的情况下压测不通过，无法生成报告，大并发量无法模拟） | 优先考虑 |
| 2 | 阿里云PTS | 1、不需要准备环境，可直接使用 2、可VPC内网连接测试环境，排除网络干扰，成功率高 | 1、需要购买资源包 | PTS资费：预付费¥1,058.00/年(40万VUM) |
| 3 | JMetter | 1、低成本，环境准备时间短 2、可推广性强 | 1、需要手动编排压测场景API，人力投入大 2、无法排除网络干扰 | 最终选择 |
如上，技术路线上，最终的选择是基于JMeter的各种控制器以及集合点的设置，模拟强弱并发和不同用户访问系统的情况。
报告输出压测报告是承载系统性能现状很重要的体现，一个好的压测报告不仅要客观的反映现状，还需要提出合理化建议，体现出专业性和洞察力。
图1. 聚合报告
图2. 服务器资源采集
图3. 推导分析
总结分布式系统全链路压测重点：
- 测试策略：强弱并发、极值测试
- 衡量指标：响应时间、错误率、吞吐量
- 目标设定：各场景在xxx并发下，超时率<=x.x%，单接口响应时间<=x，总体吞吐量TPS >= xxx
- 技术选型和环境准备：JMeter足以应付绝大部分场景，注意Linux服务器CLI运行可以有效屏蔽网络干扰，环境准备上要留意测试环境的数据量，合理翻倍数据
- 报告整理：现状和未来，体现专业性和洞察力
