SpringCloud分布式系统全链路压测

前言

继上一篇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. 推导分析 

总结

分布式系统全链路压测重点：

1. 测试策略：强弱并发、极值测试
2. 衡量指标：响应时间、错误率、吞吐量
3. 目标设定：各场景在xxx并发下，超时率<=x.x%，单接口响应时间<=x，总体吞吐量TPS >= xxx
4. 技术选型和环境准备：JMeter足以应付绝大部分场景，注意Linux服务器CLI运行可以有效屏蔽网络干扰，环境准备上要留意测试环境的数据量，合理翻倍数据
5. 报告整理：现状和未来，体现专业性和洞察力