1. 课程导论：分布式事务与契约测试的碰撞，为什么需要这门课
1.1 分布式事务的困境：从 CAP 到压测的“黑盒”
在微服务架构中，一个业务操作往往跨越多个服务、多个数据库实例。分布式事务（Distributed Transaction）通过 2PC、TCC、Saga 或 最终一致性 等模式来保证数据最终一致。然而，当这些事务模式进入压测场景时，传统测试手段暴露出三个致命短板：
- 状态不可观测：压测期间，事务的 Prepare、Commit、Rollback 状态散落在不同服务日志中，难以实时聚合。
- 契约漂移：事务协调器与参与者之间的 gRPC 接口（如
Prepare、Confirm、Cancel）在迭代中频繁变更，压测脚本与真实接口脱节。 - 回滚路径验证缺失：压测只关注吞吐量，很少验证补偿事务（Compensating Transaction）在压力下的正确性。
核心矛盾：分布式事务的正确性依赖服务间严格的接口契约，而压测场景的复杂性和动态性使得契约验证被长期忽视。
1.2 契约测试：为分布式事务加上“形式化护栏”
契约测试（Contract Testing）通过定义、验证和版本化服务间的交互协议，确保通信双方对请求/响应的结构、语义和边界条件达成一致。在 gRPC 生态中，契约测试通常基于 protobuf 文件 和 消费者驱动契约（CDC） 模式。
| 维度 | 传统集成测试 | gRPC 契约测试 |
|---|---|---|
| 验证粒度 | 端到端业务流 | 单个 RPC 方法的请求/响应结构 |
| 依赖环境 | 需要完整部署所有服务 | Mock 服务端或客户端，轻量运行 |
| 变更反馈 | 数小时甚至数天 | 秒级，CI 阶段即可阻断 |
| 压测适配性 | 脚本硬编码，接口变更后失效 | 契约驱动压测数据生成，自动适配 |
将契约测试引入分布式事务压测场景，本质上是为每个事务参与者的 gRPC 接口建立 可执行规范，压测工具（如 ghz、Locust）直接基于契约生成合法请求，并自动校验响应是否符合预期。
1.3 碰撞的价值：从“压测通过”到“事务正确”
当分布式事务与契约测试在压测场景中碰撞，产生三个关键收益：
- 压测脚本自修复：契约版本变更后，压测数据生成器自动调整字段类型、枚举值、必填参数，无需人工修改脚本。
- 事务状态机验证：契约不仅描述单个 RPC，还描述事务状态转换规则（如
Prepare → Confirm或Prepare → Cancel），压测时可自动校验状态机合法性。 - 回滚路径压力覆盖：基于契约生成大量异常场景（超时、重复请求、非法状态），验证补偿事务在高并发下的幂等性和一致性。
实战案例：某金融核心系统在压测 TCC 事务时，因
Cancel 接口的响应字段从 bool success 改为 int32 code，导致回滚逻辑失效。引入契约测试后，该变更在 CI 阶段即被捕获，避免了线上资损。
1.4 课程全景图：从理论到压测场景库
本课程围绕 gRPC 契约测试 + 分布式事务压测 构建完整知识体系，覆盖以下核心模块：
1.5 为什么需要这门课？—— 三个不可回避的理由
| 理由 | 现状痛点 | 课程解决方案 |
|---|---|---|
| 接口变更频繁 | 分布式事务接口每周变更 3-5 次，压测脚本维护成本占 40% | 契约驱动压测数据自动生成，接口变更后脚本零修改 |
| 回滚路径被忽视 | 压测只关注成功路径，补偿事务在高并发下的正确性从未验证 | 基于契约注入异常场景，自动验证 Cancel/Compensate 接口的幂等性 |
| 团队协作断裂 | 开发定义接口、测试编写脚本、运维执行压测，三方信息不对称 | 契约作为唯一真相源，开发/测试/运维共享同一份可执行规范 |
警告：如果继续使用硬编码压测脚本 + 手工验证事务状态，当系统规模超过 10 个微服务时，接口变更导致的压测失效将成为常态，分布式事务的正确性将完全依赖运气。
1.6 谁应该学习这门课？
- 测试架构师：需要设计可维护、可复用的分布式系统压测方案。
- 后端开发工程师：负责实现分布式事务逻辑，希望减少接口变更带来的联调成本。
- SRE / 运维工程师：执行压测并关注系统稳定性，需要自动化契约验证能力。
- 技术管理者：评估团队在微服务质量保障上的投入产出比，推动工程效能改进。
本课程不要求你精通 gRPC 或分布式事务理论，但希望你具备基本的微服务架构认知和一定的编程基础（Go / Java / Python 任一即可）。