1. 课程导论：微服务事务边界问题的背景、为什么需要专门测试验证、课程目标与学习路径

1.1 微服务事务边界问题的背景

在单体架构中，事务边界通常由数据库的本地事务（ACID）直接管理。一个业务操作往往对应一个数据库连接、一个事务提交或回滚。然而，当系统拆分为微服务架构后，一个完整的业务操作往往需要跨越多个独立的服务、数据库甚至消息队列。这种“跨服务、跨数据源”的特性，使得传统的事务管理机制失效，从而产生了微服务事务边界问题。

事务边界问题的核心矛盾在于：业务一致性要求与微服务独立部署、独立数据存储之间的冲突。具体表现为：

• 本地事务失效：每个微服务拥有独立的数据库，无法使用单库的 BEGIN TRANSACTION 和 COMMIT 来保证跨服务的数据一致性。
• 分布式事务的复杂性：引入两阶段提交（2PC）、Saga、TCC（Try-Confirm/Cancel）等模式，但这些模式本身存在协调者单点、补偿逻辑复杂、隔离性弱化等问题。
• API 调用成为事务边界：在 Kubernetes 环境中，服务间通过 REST/gRPC API 进行通信，每一次 API 调用都可能成为事务的边界点。API 的超时、重试、幂等性、网络分区等问题，直接决定了事务的最终一致性。
• Kubernetes 动态环境放大不确定性：Pod 的扩缩容、滚动更新、节点故障、网络策略变更等，使得 API 调用的成功率和延迟更加不可预测，进一步加剧了事务边界的脆弱性。

1.2 为什么需要专门测试验证

传统的单元测试、集成测试或端到端测试，往往无法有效覆盖微服务事务边界问题。原因在于：

专门的事务边界测试验证，需要解决以下核心挑战：

1. 状态一致性验证：在多个服务的数据源中，验证最终数据状态是否满足业务约束（如账户扣款与订单创建必须同时成功或同时回滚）。
2. 异常路径覆盖：模拟 API 超时、服务不可用、消息丢失、Kubernetes Pod 重启等故障，验证 Saga/TCC 的补偿逻辑是否正确触发。
3. 幂等性与重试机制：验证 API 在重复调用、乱序到达时的行为是否符合预期。
4. Kubernetes 环境下的混沌测试：利用 Kubernetes 的弹性能力（如 Chaos Mesh、Litmus），主动注入 Pod 故障、网络延迟、DNS 解析失败等，观察事务边界的韧性。

1.3 课程目标与学习路径

本课程旨在帮助学员建立一套系统化的 Kubernetes 微服务 API 事务边界测试验证方法。通过本课程的学习，你将能够：

• 理解：微服务事务边界的本质、常见模式（Saga、TCC、Outbox）及其在 Kubernetes 环境下的特殊性。
• 设计：针对不同事务模式，设计可执行的测试用例，包括正常流程、异常流程、补偿流程和幂等性验证。
• 实现：使用 Go 或 Java 编写测试框架，结合 Kubernetes 原生 API 和混沌工程工具，自动化执行事务边界验证。
• 度量：定义事务边界测试的覆盖率指标（如补偿路径覆盖率、异常注入覆盖率），并集成到 CI/CD 流水线中。

课程学习路径分为四个阶段：

下图展示了本课程的核心知识体系与学习路径：