整体架构:
组件说明¶
- 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的性能测试架构理解 - 云+社区 - 腾讯云