4. 作业平台架构：作业调度引擎、任务队列、资源池管理、结果存储模块
容量压测作业平台的核心在于将一次复杂的压测任务拆解为可调度、可排队、可分配、可追溯的原子操作。本章深入剖析作业平台的四大核心模块：作业调度引擎、任务队列、资源池管理与结果存储模块，揭示它们如何协同工作以支撑大规模、高并发的压测作业。
4.1 整体架构概览
下图展示了作业平台内部四大模块的协作关系与数据流转路径。用户通过自助服务接口提交压测请求后，调度引擎负责解析并编排作业，任务队列实现削峰填谷与异步解耦，资源池管理动态分配压测节点，最终结果存储模块负责持久化压测数据。
4.2 作业调度引擎
调度引擎是整个作业平台的大脑，负责接收用户提交的压测请求，将其解析为可执行的作业单元，并根据依赖关系与触发条件进行编排。
4.2.1 核心职责
- 作业解析：将自助服务接口传入的 JSON/YAML 配置转换为内部作业对象模型（Job Object Model）。
- 依赖编排：识别作业间的依赖关系（如“先预热后正式压测”），构建有向无环图（DAG）执行计划。
- 触发策略：支持立即执行、定时执行、事件触发、循环执行等多种触发方式。
- 状态管理：维护作业生命周期状态（待调度、运行中、成功、失败、取消）。
4.2.2 调度策略对比
| 策略类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| FIFO（先进先出） | 低并发、简单压测 | 实现简单，公平性高 | 无法处理优先级，长作业阻塞短作业 |
| 优先级队列 | 多租户、紧急压测 | 高优任务快速响应 | 可能导致低优任务饥饿 |
| 时间片轮转 | 长时间压测任务 | 避免单个任务独占资源 | 上下文切换开销较大 |
| DAG 依赖调度 | 复杂多阶段压测 | 严格保证执行顺序 | 编排复杂度高 |
实践建议：生产环境中通常采用“优先级队列 + DAG 依赖调度”的组合策略。紧急压测任务可设置高优先级插队执行，同时通过 DAG 确保多阶段任务的顺序正确性。
4.3 任务队列
任务队列位于调度引擎与资源池之间，起到削峰填谷和异步解耦的关键作用。当大量压测请求瞬间涌入时，队列可以缓冲压力，防止资源池被击穿。
4.3.1 队列模型
- 内存队列：基于 Redis List 或 Disruptor 实现，延迟极低，适合高吞吐场景。
- 持久化队列：基于 Kafka / RabbitMQ / Pulsar 实现，支持消息持久化与回溯消费。
- 优先级子队列：按任务优先级拆分为多个子队列，调度引擎按权重消费。
4.3.2 队列关键指标
| 指标名称 | 说明 | 健康阈值 |
|---|---|---|
| 队列深度 | 当前排队任务数量 | < 10000 |
| 消费延迟 | 任务入队到被消费的时间间隔 | < 5 秒 |
| 消费速率 | 每秒出队的任务数 | ≥ 生产速率 |
| 重试次数 | 消费失败后的重试计数 | ≤ 3 次 |
注意：当队列深度持续增长且消费延迟超过 30 秒时，说明资源池处理能力不足，应触发自动扩容或告警通知。
4.4 资源池管理
资源池管理模块负责维护所有可用的压测执行节点（Agent/Worker），并根据任务需求动态分配和回收资源。
4.4.1 资源池生命周期
- 节点注册：压测节点启动后向资源池管理中心上报自身信息（IP、CPU、内存、最大并发数）。
- 健康检查：管理中心定期发送心跳探测，标记失联节点为“不可用”。
- 资源分配：根据任务所需的并发数、地域、标签等条件，从可用节点中选择最优组合。
- 资源回收：任务执行完毕后，释放节点资源，将其归还到空闲池。
4.4.2 分配策略
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 轮询分配 | 按节点列表顺序依次分配任务 | 节点规格一致 |
| 最少连接数 | 优先分配给当前负载最低的节点 | 节点性能异构 |
| 标签亲和性 | 按节点标签（如地域、机房）匹配任务 | 就近压测、合规要求 |
| 资源预留 | 为高优任务预留独占节点 | 核心业务压测 |
4.5 结果存储模块
结果存储模块负责接收压测执行过程中产生的海量时序数据、日志和最终报告，并提供高效的查询与聚合能力。
4.5.1 数据分类与存储方案
| 数据类型 | 存储引擎 | 保留周期 | 典型数据量 |
|---|---|---|---|
| 实时指标（TPS、RT、错误率） | InfluxDB / Prometheus | 7 天 | 每秒数千点 |
| 详细采样日志 | Elasticsearch | 30 天 | 每任务数万条 |
| 压测报告与聚合数据 | MySQL / PostgreSQL | 永久 | 每任务数 KB |
| 原始网络包（pcap） | 对象存储（S3/MinIO） | 按需 | 每任务数 GB |
4.5.2 写入与查询路径
- 写入路径：压测节点通过 gRPC 流式传输实时指标 → 消息队列缓冲 → 时序数据库批量写入。
- 查询路径：前端仪表盘 → API 网关 → 查询聚合层 → 多存储引擎并行查询 → 结果合并返回。
- 数据降采样：对于超过 7 天的历史数据，自动降采样为分钟级或小时级聚合，减少存储开销。
架构要点：结果存储模块采用“热数据 + 温数据 + 冷数据”分层架构。热数据（最近 1 小时）全量保留在内存中，温数据（1 小时 ~ 7 天）存储在时序数据库，冷数据（超过 7 天）降采样后归档至对象存储。这种分层设计在查询性能与存储成本之间取得了良好平衡。
4.6 模块间协作流程
一次完整的压测作业在四大模块间的流转过程如下：
- 提交：用户通过自助服务接口提交压测配置，调度引擎接收并解析为作业对象。
- 编排：调度引擎根据依赖关系生成 DAG 执行计划，将可并行执行的子任务拆分为多个任务单元。
- 入队：任务单元按优先级写入任务队列，等待资源池消费。
- 分配：资源池管理模块从队列中拉取任务，根据分配策略选择最优节点，下发执行指令。
- 执行与上报：压测节点开始执行，实时指标通过流式通道写入结果存储模块。
- 完成与回收：任务执行完毕后，节点资源归还资源池，调度引擎更新作业状态为“成功”。
避坑指南：在模块间协作中，最容易出现的问题包括：队列消费速率低于生产速率导致任务堆积、资源池节点因网络抖动被误判为不可用、结果存储写入压力过大导致背压。建议为每个模块设置独立的监控告警，并预留至少 20% 的容量缓冲。