MeterSphere性能测试框架理解

整体架构：

 

组件说明¶

• Frontend: MeterSphere 的前端工程, 基于 Vue.js 进行开发
• Backend: MeterSphere 的后端工程, 基于 Spring Boot 进行开发, 为 MeterSphere 的功能主体
• Chrome plugin: 浏览器插件, 录制 Web 访问请求生成 JMeter 脚本并导入到 MeterSphere 中用于接口测试及性能测试
• Jenkins plugin: Jenkins 插件，在 Jenkins 中安装该插件后可将 Jenkins 任务中添加 MeterSphere 构建环节，用户在该构建环节中配置 MeterSphere 平台的认证信息后，可选择指定项目下的接口/性能测试进行触发执行。
• Node controller: 为性能测试提供独立节点类型的测试资源池, 接收来自系统的性能测试任务, 动态的启动 JMeter容器完成性能测试
• MySQL: MeterSphere 项目的主要数据均存储在 MySQL
• Redis: MeterSphere 项目登录用户的session存储在 Redis
• Kafka: 接收 JMeter 产生的接口测试或者性能测试的结果数据
• Prometheus: 收集压力机及被测系统的监控数据
• Data streaming: 从 Kafka 中获取接口测试或者性能测试结果数据进行处理后存入 MySQL 数据库
• Docker engine: 为 Node Controller 提供 JMeter 容器运行环境

组建关系图理解：

粗浅解释：

        这个平台是基于Docker的集群部署架构，而且通过NodeController实现了分布式压测部署，性能测试任务会被下发到NodeController，一个NodeController就是一个资源池（界面上能看到这么个概念）。

        NodeController在接收到测试任务后，就会创建一个Docker的Jmeter引擎，这个jmeter实例并不是我们通常所理解的slave或jmeter-server进程，而就是独立的jmeter（master），所以它们之间不存在端口1099的冲突问题，这样就可以无限创建多个Docker引擎，比如在多个宿主机上分别创建NodeController。

        而一个NodeController下，可以创建多个jmeter-docker实例（一个任务起一个实例，压测完后，自动回收）。

        每个jmeter-docker实例（多任务）压测完后，都会保留独立的测试报告（相当于是多个jmeter独立并行测试）。

架构官方文档：https://metersphere.io/docs/system_arch/

其他博主参考分析：关于MeterSphere的性能测试架构理解 - 云+社区 - 腾讯云