前言：
得物在生产环境进行压测之前是通过在1:1还原的在单独环境进行压测的。这个压测方案除了不仿真外，服务外包括数据存储也是独立的一套。为了降低压测成本，同时保证压测的高拟仿真度，我们采用了全链路生产环境压测的方案。
全链路压测的核心问题之一是要解决数据隔离问题。压测的流量不能污染线上数据。我们通过中间件平台研发的fusion脚手架，在RPC、Redis、DB、MQ、跨线程中透传压测标，如果是压测流量，产生的数据会写入影子库，实现了中间件层面可支撑全链路压测的基础能力。
之前我们是使用的一个开源的压测平台。但是我们经过几年的使用发现这个平台维护成本比较高，架构设计也不太适合得物的基础设施。因此我们自研了得物的新压测平台（二开JMeter），并很好地支撑了大促压测。自研平台支持多种协议比如Dubbo、HTTP、GRPC、Websocket、Java等。并可支持多种发压方式，如指定QPS/TPS，指定线程数压测等等。压测结束后，能够自动生成全面的压测报告数据，协助分析、排查问题。压测平台底层完全使用得物的基础设施，压测平台使用的压力机也全都容器化，让发压更稳定，成本更低。通过自建压测平台，实现了平台层面的全链路压测的支撑能力。
这里着重讲一下为什么要支持固定QPS模式压测，随着公司的业务发展，对线上稳定性方面有了更高的要求和挑战，这势必要求能够摸底各个域应用的性能的瓶颈，针对线上的摸高，无疑是如履薄冰。因此按照并发数盲目的去压力测试，很有可能造成线上故障，能够把控压测的流量，且很精准，结合各个域给出的QPS/TPS目标值压测，很大程度减少了大促准备时间，投入人力也逐年减少，同时也减少了因压测带来的稳定性问题。
1. 压测平台功能简介
压测平台为了降低压测平台维护成本，压测流程提效，提升压测的易用性和体验性，保障压测期间的稳定性而建设。面对当今大流量的时代背景，无疑不是一件摸底应用性能瓶颈的利器，也是一份技术保障。
新压测平台采用JMeter引擎，核心特色功能如下：
- 支持全链路高并发压测
- 支持多协议HTTP、Dubbo、Websocket、GRPC、JDBC、Java
- 支持多种压测模式，并发模式，吞吐量模式
- 支持内外网，全网通访问压测
- 支持在线脚本施压配置联动更改
- 支持多种资源池模式，动态资源池即压力机动态容器申请，即用即启，即停即释放的高效资源利用模式以及固定资源池模式
- 支持无主发压模式，高效发压破除主控机瓶颈
- 支持压测机自监控
- 支持自动生成全面的压测报告数据和压测QPS&响应时间曲线图
- 支持定时任务自动化脚本执行
单笔调试功能
2. 压测平台架构设计
整体架构和旧版开源压测平台对比：
3. 压测平台核心压测逻辑
3.1 施压流程
该阶段包括施压前场景的创建、压力机容器的动态创建、施压、压测报告上报。
压测执行时序图：
压测节点的流转：
吞吐模式限流的实现：
吞吐模式即固定QPS进行压测，实现逻辑如下图：
3.2 压测生命周期
压测生命周期大体分三个阶段：压测前、压测中、压测后，接下来安装这三个阶段来进行讲述压测平台在每个阶段的主要工作和流程，希望能够帮助你理解压测逻辑和到底都做了哪些事情。
压测前
压测前的压测平台的准备工作：压力机资源的预估和申请、压测脚本文件JMX的开发和调试、参数文件的开发和上传（上传到压测平台），压测线程组下接口QPS目标值的设置。
压测中
管控页面针对上传的JMX文件自动填充JMeter监听器BackendListener监听器并设置InfluxDB时序库实例地址进行压测数据的收集，利用得物自建的grafana进行压测数据的拉取进行渲染，其中监控包括：接口总请求数、总错误数、总QPS/TPS、接口维度QPS/TPS、压力机维度QPS/TPS、平均RT、95lineRT进行监控绘图直观展示，图如下：
压测后
压测报告在压测结束后进行计算生产，在压力机上报结束状态心跳时候，压测管控服务通过压测唯一编号进行异步获取InfluxDB中的压测数据，计算并存储到MySQL，折线图元数据信息通过JSON文件信息保存到得物自建的分布式文件系统HDFS。
压测结果
压力机CPU平均使用率30%，内存平均使用率50%，自建influnDB服务器内存、IO都很健康。
4. 压测总结
压测平台主要解决JMeter集群去master中心化，解决掉单点瓶颈，需要考虑三点：
首先，需要考虑集群方式和启动方式（这里就不进行架构图展示了），JMeter中心化集群是通过配置文件配置各个节点的IP和PORT通Java的RMI协议进行远程启动各个slave节点，去中心化后，没有master节点进行管理，去除掉了集群配置文件，每个节点都是master节点，没有相互依赖关系，通过发送shell命令并发远程启动各个节点。
其次，要考虑存储压测元数据存储DB（InfluxDB时序库）的压力。这点要说明一下，因为JMeter集群上报压测元数据信息逻辑是通过slave节点通过Java的RMI协议上报给到Master节点（这里也就是Master节点性能瓶颈的原因），master节点在通过配置的监听器上报给到InfluxDB，去中心化后，不存在master-slave的概念，因此每个节点都要会上报压测元数据到时序库，因此influxDB存在较大的写压力和读压力，这里需要考虑influxDB的性能优化了，如集群化部署、性能调优等。
然后，压测报告的收集聚合，压测中的监控结合grafana进行定制化配置聚合脚本语句完成，压测报告也是同样的原理，继承influxdb客户端写聚合脚本来进行计算存储。在解决了上述三个问题后，高并发的全链路压测就可以根据压测目标来进行压力机数量的配置来满足压测需求了。
5. 未来展望
压测平台经历多轮大促压测的锤炼，目前已满足高吞吐压测的能力。
针对后面得物压测平台的发展在提效、功能易用，性能自动化分析等方面，我们也做了后续规划：
- 通过数据清洗与数据脱敏、数据放大，来构造压测数据，以减少数据构造的压力；
- 支持在线压测吞吐量的修改；
- 支持在线编辑JMX主要组件（面向用户更傻瓜容易上手，屏蔽JMeter的学习成本）；
- 支持用户提出的其他协议压测，eg: RocketMQ等；支持压测结果自动分析判断接口达标率；
- 支持接口自熔断，无需人工盯盘；支持压测预案自动化；
- 支持联动流量录制自动生成JMX脚本进行压测，能够结合相关性能分析组件给出优化意见。
得物压测平台一直在持续完善和提升中，希望本文能抛砖引玉，提供压测平台建设方面的一些参考经验。
*文/史一鑫
@得物技术公众号