2. 平台整体架构设计：模块划分与交互流程
自助服务容量压测作业平台采用微服务 + 事件驱动的架构风格，将压测全生命周期拆解为五个核心模块：前端展示层、后端服务层、调度引擎层、数据存储层和监控告警层。各模块职责清晰、接口契约明确，通过异步消息与REST API协同工作，支撑从场景配置到报告生成的完整闭环。
2.1 模块职责与边界
| 模块名称 | 核心职责 | 关键组件 | 对外接口 |
|---|---|---|---|
| 前端展示层 | 用户交互、场景配置可视化、实时看板、报告展示 | Vue3 SPA、WebSocket客户端、ECharts图表 | HTTP REST / WebSocket |
| 后端服务层 | 业务逻辑编排、场景校验、任务管理、用户权限 | Spring Boot、RabbitMQ Producer、Redis缓存 | REST API / AMQP |
| 调度引擎层 | 压测任务分发、分布式施压机管理、流量控制 | Kubernetes Job、自定义调度器、Agent集群 | gRPC / 消息队列 |
| 数据存储层 | 场景元数据、压测结果、时序指标、日志归档 | MySQL + InfluxDB + MinIO + Elasticsearch | JDBC / HTTP / SQL |
| 监控告警层 | 实时指标采集、阈值判定、告警通知、链路追踪 | Prometheus + Alertmanager + Grafana + Jaeger | PromQL / Webhook |
架构设计原则：调度引擎层与后端服务层通过异步消息队列解耦，避免压测执行期间的高并发请求阻塞业务API。数据存储层采用混合存储策略，结构化元数据用MySQL，时序数据用InfluxDB，压测日志和报告文件用MinIO对象存储。
2.2 核心交互流程
一次完整的压测任务从创建到完成，经历以下六个关键步骤，涉及全部五个模块的协同工作：
- 场景配置与提交：用户在前端通过拖拽式向导完成压测场景配置（并发数、持续时间、请求参数等），点击“提交”后，前端将配置JSON通过REST API发送至后端服务层。
- 校验与持久化：后端服务层对场景配置进行完整性校验（参数范围、资源配额、依赖检查），校验通过后写入MySQL数据库，并返回任务ID给前端。
- 任务入队与调度：后端将压测任务消息发布到RabbitMQ队列，调度引擎层监听队列，根据集群资源情况选择合适的施压机节点，通过Kubernetes Job拉起压测容器。
- 压测执行与数据采集：调度引擎层向施压机下发压测脚本和参数，施压机开始执行并发请求。同时，Prometheus主动拉取施压机的CPU、内存、网络IO以及业务响应时间等指标。
- 实时反馈与看板：调度引擎层通过WebSocket将实时TPS、成功率、P99延迟等指标推送到前端看板，用户可随时观察压测进展。
- 结果归档与报告生成：压测结束后，调度引擎层汇总所有施压机的原始数据，写入InfluxDB和MinIO。后端服务层异步生成PDF/HTML压测报告，并触发告警规则检查。
2.3 模块间通信协议与数据流
各模块之间的通信方式根据实时性要求和数据量级选择不同的协议：
| 交互链路 | 通信协议 | 数据格式 | 典型数据量 | 实时性要求 |
|---|---|---|---|---|
| 前端 ↔ 后端 | HTTP/1.1 REST + WebSocket | JSON | KB级（配置/状态） | 中（配置秒级，看板毫秒级） |
| 后端 → 调度引擎 | AMQP (RabbitMQ) | JSON + Protobuf | KB级（任务消息） | 低（允许秒级延迟） |
| 调度引擎 ↔ 施压机 | gRPC (双向流) | Protobuf | KB级（控制指令） | 高（毫秒级） |
| 施压机 → 监控告警 | HTTP / Pushgateway | Prometheus Metrics | MB级（每秒指标） | 高（秒级采集） |
| 调度引擎 → 数据存储 | InfluxDB Line Protocol / S3 API | 行协议 / 二进制 | GB级（结果数据） | 低（允许分钟级写入） |
性能关键路径：施压机 → 监控告警链路是平台性能瓶颈点。当并发施压机数量超过100台时，建议启用指标聚合代理（如Prometheus Agent模式），在施压机本地先做预聚合，再批量上报，避免监控中心被瞬时指标洪峰冲垮。
2.4 部署视图与容错设计
平台采用Kubernetes原生部署，所有模块均以容器化方式运行。关键容错策略如下：
- 前端展示层：无状态，通过Nginx Ingress负载均衡，支持水平扩展。
- 后端服务层：无状态，Pod副本数≥2，通过Redis分布式会话管理。
- 调度引擎层：有状态，调度器主节点通过Leader Election选主，Agent节点自动注册与心跳检测。
- 数据存储层：MySQL主从复制 + InfluxDB集群 + MinIO纠删码模式，保障数据不丢失。
- 监控告警层：Prometheus采用Thanos架构实现高可用，Alertmanager配置多副本去重。
2.5 架构设计决策记录
在架构选型过程中，团队针对以下关键问题进行了技术权衡：
| 决策点 | 选型方案 | 备选方案 | 决策理由 |
|---|---|---|---|
| 调度引擎与后端通信方式 | 异步消息队列 (RabbitMQ) | 同步REST调用 | 避免压测高峰阻塞后端API，支持削峰填谷和任务重试 |
| 施压机控制协议 | gRPC 双向流 | HTTP/1.1 轮询 | gRPC低延迟、支持流式控制，适合高频指令下发 |
| 时序数据库选型 | InfluxDB | Prometheus TSDB / TimescaleDB | InfluxDB写入性能高，支持降采样和连续查询，适合压测指标存储 |
| 监控指标采集模式 | Pull + Push 混合 | 纯Pull / 纯Push | 施压机动态扩缩容场景下，Push模式更可靠；稳态服务用Pull减少耦合 |
架构避坑提示：不要将调度引擎与后端服务部署在同一个进程或Pod中。压测执行期间调度引擎CPU和内存消耗极高，若与业务API混部，会导致前端配置提交超时、任务创建失败等连锁故障。务必通过消息队列做物理隔离。