3. 压测作业平台概述
压测作业平台是容量保障体系中的核心执行层，向上对接 CI/CD 流水线的门禁触发信号，向下调度压测引擎与数据源。平台定位为“可编程、可观测、可门禁”的一站式压测作业管理底座，解决传统压测中脚本散落、数据混乱、报告割裂、无法与流水线联动的痛点。
3.1 平台定位
| 维度 | 定位描述 |
|---|---|
| 业务视角 | 为研发、测试、SRE 提供统一的压测作业入口，降低压测门槛 |
| 技术视角 | 解耦压测引擎（如 JMeter / Locust / wrk），抽象为标准化作业模型 |
| 流水线视角 | 作为 CI/CD 门禁的“度量节点”，输出通过/阻断信号 |
| 数据视角 | 集中管理压测脚本、参数化数据、历史报告，形成可复用的资产库 |
关键认知：压测作业平台不是“压测工具”，而是“压测作业的编排与治理平台”。它让每一次压测都成为可追溯、可比较、可自动化的标准化作业。
3.2 核心功能模块
平台围绕压测作业的完整生命周期，划分为四个核心功能模块：
- 任务管理：作业的创建、调度、执行、停止、重试。支持定时触发、事件触发（如流水线回调）、手动触发。任务状态机包含：待执行 → 执行中 → 执行完成 / 执行失败 / 超时中断。
- 脚本管理：压测脚本的版本管理、参数化、在线编辑与校验。支持多引擎脚本格式（JMX / Python / Shell），并提供脚本模板库。
- 数据管理：压测参数化数据（CSV / JSON / 数据库连接串）的上传、绑定、脱敏与版本管理。支持数据预加载与动态数据生成。
- 报告管理：压测执行结果的聚合、对比、导出。包含实时指标（TPS / RT / Error%）与离线分析（分位线、火焰图、瓶颈分析）。
3.3 平台架构设计原则
压测作业平台在架构设计上遵循以下五项核心原则，确保平台能够支撑大规模、高并发的流水线门禁场景：
- 作业与引擎分离：平台只负责作业编排与状态管理，不绑定具体压测引擎。通过 SPI 机制适配 JMeter、Locust、wrk 等引擎，支持未来扩展。
- 无状态 + 水平扩展：平台自身不持有压测状态，所有作业状态写入分布式存储（如 Redis + MySQL）。调度节点可水平扩展，避免单点瓶颈。
- 异步非阻塞：任务提交后立即返回作业 ID，执行结果通过回调或轮询获取。避免流水线长时间阻塞等待。
- 可观测性优先：每个作业从创建到完成，全链路埋点。平台暴露 Prometheus 指标（作业排队数、执行时长、成功率），支持 Grafana 大盘。
- 门禁契约化：平台输出标准化的门禁结果（通过 / 阻断 / 警告），不关心流水线业务逻辑。门禁阈值由流水线侧配置，平台只提供度量数据。
架构决策记录：在早期版本中，平台曾尝试将压测引擎内嵌到平台进程中，导致引擎升级必须重启平台，且资源隔离困难。重构为“作业与引擎分离”后，每个压测任务独立运行在容器或 K8s Job 中，平台仅通过 API 控制启停，资源隔离性与扩展性得到质的提升。
3.4 平台与 CI/CD 流水线的集成关系
压测作业平台在 CI/CD 流水线中扮演“质量门禁执行器”的角色。典型的集成流程如下：
| 步骤 | 流水线侧动作 | 平台侧动作 |
|---|---|---|
| 1 | 构建完成后，调用平台 API 创建压测任务 | 校验脚本与数据完整性，返回作业 ID |
| 2 | 轮询或等待回调，获取作业状态 | 调度压测引擎执行，实时上报进度 |
| 3 | 收到完成信号，拉取门禁结果 | 聚合指标，与门禁阈值比对，输出通过/阻断 |
| 4 | 根据门禁结果决定是否继续部署 | 归档报告，清理临时资源 |
常见误区：不要将压测平台设计为“同步调用”。如果流水线直接等待压测完成（尤其是长时间压测），会导致流水线资源长时间占用，甚至超时失败。务必采用“异步提交 + 回调/轮询”模式。