前言：

得物在生产环境进行压测之前是通过在 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 脚本进行压测，能够结合相关性能分析组件给出优化意见。

得物压测平台一直在持续完善和提升中，希望本文能抛砖引玉，提供压测平台建设方面的一些参考经验。

*文 /史一鑫

关注得物技术 @得物技术公众号