2.1 为什么要搭建性能测试平台

搭建性能测试平台对于软件开发和运维团队来说是一个重要的实践。主要原因包括：

1. 性能测试平台可以帮助评估系统在不同条件下的性能。这包括在正常负载、峰值负载和异常负载下的表现。这对于确保系统在实际使用中具有足够的性能和响应速度至关重要。

2. 通过模拟大量用户和负载，性能测试平台可以帮助发现系统中的瓶颈和潜在的问题。这有助于提前识别和解决性能瓶颈，从而提高系统的稳定性和可用性。

3. 性能测试平台可以用于规划系统的容量。通过模拟未来的用户增长和负载变化，团队可以确定所需的硬件资源，以确保系统在扩展时仍然能够提供稳定的性能。

4. 将性能测试集成到持续集成和持续交付流程中，可以在每个代码更改的早期阶段发现性能问题。这有助于降低修复问题的成本，并提高软件交付的质量。

5. 性能测试可以确保系统在各种条件下都能够提供一致的用户体验。这对于维护用户满意度和品牌声誉非常重要。

6. 通过模拟高负载和大规模用户同时访问系统的场景，性能测试可以评估系统的可伸缩性。这对于确保系统能够有效地处理不断增长的用户量非常关键。

7. 性能测试可以帮助团队预测系统在生产环境中可能遇到的问题，并采取措施来预防潜在的生产故障。

8. 基于性能测试的结果，团队可以更好地做出关于系统架构、硬件投资和性能优化的决策。

2.2 平台优势

开源免费

该平台由企业基于开源库独立开发，不依赖于第三方平台，降低企业的软件采购和使用成本。这意味着企业可以用更少的资金来获得更高质量的软件，从而提高了企业的竞争力和盈利能力。

效率提升

平台的可定制性可以满足企业的个性化需求，从而提高了企业的工作效率和生产力。如：支持线程组前端可配置、选择不同发压策略、支持单接口和脚本类型。同时支持发压机的扩缩容，以满足发压任务。

易用性

平台使用方法简单，只需要通过前端页面选择必要参数，就可以实现发压任务，发压过程中支持实时监控数据更新，发压完成后生成发压报告和可视化压测结果面板，上手简单，使用方便。

促进创新

独立平台搭建促进了更多的开发者参与到软件的创新和改进中来，从而可以帮助企业不断地推出新的产品和服务，并优化企业的业务流程和管理模式。

除了以上这些优势，平台还具有稳定、可靠、可维护等特点。

2.3 平台整体架构介绍

前端工程：基于Vue.js开发

后端工程：基于Spring Boot开发，主要功能是场景构造和测试报告的生成，并对外提供任务调度引擎的接口

任务调度引擎：整个系统的核心，负责任务的调度、状态转移和发压资源的分配；

InfluxDB：是一个开源分布式时序、时间和指标数据库。用于测试数据的存储

Grafana：仪表板，用于展示测试数据

夜莺：监控发压机状态

Zookeeper：项目中是任务调度引擎各角色具像化的媒介

2.4 去中心化的Jmeter分布式集群

Jmeter随附一个GraphiteBackendListenerClient，它可以帮助用户将测试数据发送到Graphite Backend，又引入InfluxDBBackendListenerClient，它允许用户使用UDP或HTTP协议将指标发送到influxDB后端。InfluxDBBackendListenerClient可以自定义数据采集时间，并将测试过程中的数据存入InfluxDB，这使得我们搭建一个去中心化的Jmeter发压集群成为可能。

使用这种方式，我们不再需要Master节点负责各节点测试数据的收集和处理（各Jmeter线程只需要运行自己的测试计划，同时把测试数据发送到influxDB），从而实现了发压集群的去中心化。只要资源足够，我们就可以调度多个任务同时运行，并可借助Grafana即时展示任务在测试过程中的各项指标。测试结束后，可根据用户需求生成包含丰富数据和图表的测试报告。

3.1 场景准备

3.2 发压准备

3.3 发压执行

任务提交后，交给Agent 为任务调度引擎的各环节分配角色，推进任务状态的转换。任务调度引擎的角色主要有4个：

User：负责任务的提交和任务执行结果的汇总

Control Center：按时间顺序充当一个有序队列，用于存储所有提交上来的任务，维护任务当前状态，并保存每个任务的详细数据

Process：负责任务的具体执行，包括环境的准备，状态的推进和任务的下发。Process会实时监听Control Center的队首，取出最新提交的任务，并维护当前任务执行进度的偏移量

Client（发压机）：Client可能有多个，主要负责运行Process下发的指令，并收集运行时日志

4.1 任务调度引擎工作原理

任务调度引擎的各环节分配角色，各司其职的推进任务状态的转换。

任务流转流程：

流程解释说明：

1. 任务调度引擎会分两种角色部署，manager和client，manager节点负责在zookeeper上注册和监听Control Center和Process，client节点负责注册和监听Client

2. 系统启动后manager在zookeeper上创建control、process等路径，并监听各路径下的事件，client创建client路径，并监听

3. 用户提交任务后，Control Center会在control目录下创建一个子路径，并生成该任务在队列中的偏移量。若该任务的偏移量与Process所持偏移量一致，Process会为该任务创建一个子路径，并拷贝任务数据到该路径下

4. Process会根据任务中配置的执行节点，将测试计划、测试数据等文件上传至client节点；

5. 当所有准备工作完毕后，Process会在各Client路径下创建该任务，然后通过zookeeper事务提交

6. Client监听到执行任务的命令后，会在选中的发压节点运行任务中封装的jmeter命令

7. 事务执行完毕后，Process会更新该任务的状态，并通知Control Center修改任务状态

8. 当Control Center中该任务的状态为finish时，会通知Client和Process销毁zookeeper上和该任务相关的数据，process只保留当前已执行任务的偏移量

9. 最后Control Center通知User，任务执行完成
   

4.2 ZK监听机制

Zookeeper：是一个分布式、开源的分布式应用程序的协调服务。项目中是任务调度引擎各角色具像化的媒介。

有新增、更新、删除 节点就触发监听，ZK结构化图如下所示

stpresource:  节点下为存活的服务节点

stpcontroller:  user，保存提交的任务，充当有序队列

stpprocess：实时监听Controller最新提交的任务，节点下面是正在执行的压测任务

stpmonitor:  充当manager角色，任务分发到client

stpclient：发压机 运行Process下发的指令，并收集运行时日志

4.3 ZK监听机制简化流程

controller把收集的任务存到消息队列中去，Process从队列中取出任务，通知manger去下发任务，manager将任务分发到各个client，client运行Process下发的指令。

4.4 任务提交流程

该平台目前发压次数8k+，使用人数170+，企业内各个业务方使用覆盖率100%，并得到良好的收益和反馈。平台的出现解决了单机模式下的Jmeter不能满足并发要求的问题，并且可以指定发压机，选择发压策略和脚本类型以及各种线程组配置，满足各种场景的压测需求，为寒暑假行课、业务高峰与日常工作压测提供便捷可行的途径。

下一步平台规划：

1. 压测结果与异常日志平台可视化

2. Agent容器化实现

3. 发压资源的自动申请与释放

此外，在使用压测平台时，需要仔细考虑到特定项目和组织的需求。综合使用压测平台、监控工具以及实际用户反馈，可以更全面地了解和优化系统的性能。