共计 2667 个字符，预计需要花费 7 分钟才能阅读完成。
前言：
得物在生产环境进行压测之前是通过在 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 脚本进行压测，可能联合相干性能剖析组件给出优化意见。
得物压测平台始终在继续欠缺和晋升中，心愿本文能抛砖引玉，提供压测平台建设方面的一些参考教训。
* 文 / 史一鑫
@得物技术公众号