3. 压测场景库设计原则
压测场景库是分布式事务压测体系的核心资产。一个设计良好的场景库，必须遵循层次结构清晰、场景可复用、参数可配置、运行可观测四大原则。本章从架构视角拆解这些原则，并给出具体的实现指引。
3.1 场景库的层次结构
场景库采用三级分层模型：原子场景 → 复合场景 → 业务场景。每一层向下依赖、向上抽象，形成可组合的压测能力树。
核心思想： 原子场景不可再分，复合场景编排原子操作，业务场景映射真实用户旅程。
3.1.1 原子场景
原子场景是压测的最小操作单元，不可再拆分。每个原子场景对应一个确定的分布式事务动作，例如：
- 事务开启： 发起全局事务（如 Seata 的 GlobalTransaction.begin）
- 分支注册： 注册 XA/TCC/SAGA 分支事务
- 本地提交： 执行本地数据库事务并提交
- 事务回滚： 触发全局回滚或分支回滚
- 补偿调用： 执行 SAGA 或 TCC 的补偿逻辑
- 状态查询： 查询全局事务状态或分支状态
3.1.2 复合场景
复合场景由多个原子场景按事务协议编排而成。典型复合场景包括：
| 复合场景名称 | 编排的原子场景序列 | 适用协议 |
|---|---|---|
| TCC Try 阶段 | 事务开启 → 分支注册 → Try 本地事务提交 | TCC |
| TCC Confirm 阶段 | 分支注册 → Confirm 本地事务提交 → 全局提交 | TCC |
| SAGA 正向流程 | 事务开启 → 分支注册 → 本地提交 → 消息发送 | SAGA |
| SAGA 补偿流程 | 事务开启 → 分支注册 → 本地提交 → 补偿调用 → 全局回滚 | SAGA |
| XA 两阶段提交 | 事务开启 → 分支注册 → Prepare → Commit/Rollback | XA |
3.1.3 业务场景
业务场景直接映射真实用户请求链路，例如“下单支付”、“库存扣减”、“账户转账”。一个业务场景通常包含多个复合场景，并引入并发控制、超时策略、数据校验等业务逻辑。
最佳实践： 业务场景应直接来源于生产环境的全链路追踪数据（如 Jaeger/SkyWalking），确保压测场景与真实流量一致。
3.2 可复用性设计原则
可复用性是场景库降低维护成本的关键。遵循DRY（Don't Repeat Yourself）原则，避免场景定义冗余。
- 原子场景复用： 所有复合场景共享同一套原子场景定义，修改原子场景自动影响所有上层场景。
- 参数模板化： 场景定义中不硬编码 IP、端口、超时时间、重试次数，全部通过参数模板注入。
- 协议无关接口： 原子场景对外暴露统一接口（如
execute(context)），底层可切换 Seata、TCC-Transaction、自研框架。 - 场景组合器： 提供 YAML/JSON 格式的场景组合描述文件，支持动态加载和编排。
# 场景组合描述示例（YAML）
scenario:
name: "order_pay_tcc"
type: composite
steps:
- atomic: "tcc_try"
params:
branch_type: "order"
timeout_ms: 5000
- atomic: "tcc_confirm"
params:
branch_type: "order"
retry_count: 3
- atomic: "state_query"
params:
query_type: "global"
3.3 可配置性设计原则
可配置性让压测场景能够在不修改代码的前提下适应不同环境、不同负载模型。
| 配置维度 | 配置项示例 | 配置方式 |
|---|---|---|
| 环境配置 | TC 地址、数据库连接串、MQ 集群 | 环境变量 / 配置文件 |
| 负载配置 | 并发数、Ramp-up 时间、持续时长 | 压测引擎参数 |
| 事务配置 | 超时时间、重试次数、隔离级别 | 场景参数模板 |
| 数据配置 | 用户 ID 范围、订单金额分布、库存量 | 数据源 / CSV 文件 |
| 协议配置 | TCC/SAGA/XA 切换、消息序列化方式 | 场景组合描述 |
注意： 配置项必须提供默认值，避免因配置缺失导致压测启动失败。建议使用配置中心（如 Nacos/Consul）实现运行时动态调整。
3.4 可观测性设计原则
可观测性是压测场景库的“眼睛”。没有可观测性，压测结果无法解释，问题无法定位。
3.4.1 日志规范
每个原子场景和复合场景必须输出结构化日志，包含以下字段：
traceId：全局事务追踪 IDscenarioName：场景名称action：操作类型（begin/commit/rollback/compensate）status：成功/失败durationMs：耗时（毫秒）errorMessage：异常信息（仅失败时）
3.4.2 指标暴露
场景库内置 Prometheus 指标端点，暴露以下核心指标：
| 指标名称 | 类型 | 标签 | 说明 |
|---|---|---|---|
txn_total | Counter | scenario, protocol, status | 事务总数 |
txn_duration_seconds | Histogram | scenario, protocol | 事务耗时分布 |
txn_rollback_total | Counter | scenario, reason | 回滚次数及原因 |
branch_register_total | Counter | branch_type, status | 分支注册次数 |
3.4.3 链路追踪
所有场景执行必须接入分布式链路追踪系统（如 Jaeger/Zipkin），确保每个全局事务的完整调用链可追溯。链路中应包含：
- 全局事务发起时间
- 每个分支事务的注册、提交/回滚时间
- TC（Transaction Coordinator）处理耗时
- 网络传输耗时
可观测性检查清单： 每个场景上线前，必须验证日志是否完整、指标是否暴露、链路是否可追踪。缺少任何一项，该场景不得进入压测执行阶段。
3.5 设计原则总结
| 原则 | 核心要求 | 验收标准 |
|---|---|---|
| 层次结构 | 原子 → 复合 → 业务，三级分层 | 每个场景可明确归入某一层级 |
| 可复用性 | 原子场景共享、参数模板化、协议无关 | 新增业务场景无需重复定义原子操作 |
| 可配置性 | 环境/负载/事务/数据/协议五维可配 | 修改配置即可切换环境或协议 |
| 可观测性 | 日志结构化、指标标准化、链路完整化 | Prometheus + Jaeger + ELK 三端数据齐全 |
遵循以上四大原则，压测场景库将具备高内聚、低耦合、易扩展、可诊断的特性，为后续的自动化压测执行和结果分析奠定坚实基础。