1. 课程导论：分布式事务的挑战与事件风暴的价值
在微服务架构与云原生技术广泛普及的今天，分布式事务已成为企业级应用落地过程中最棘手的技术难题之一。传统单体架构下的本地事务（ACID）在面对跨服务、跨数据库、跨消息队列的场景时，往往力不从心。本章将系统梳理分布式事务的核心挑战，并引入事件风暴（Event Storming）这一协作建模方法，揭示其如何帮助团队在架构选型前精准定位事务边界与一致性需求。
1.1 分布式事务的核心挑战
分布式事务的本质是在多个独立的数据节点或服务之间维持数据一致性。与单机事务不同，分布式环境引入了网络延迟、节点故障、时钟偏差等不确定性因素，使得传统的事务机制难以直接适用。以下是分布式事务面临的主要挑战：
| 挑战维度 | 具体问题 | 典型场景 |
|---|---|---|
| 网络不可靠 | 请求超时、重试、乱序、丢包 | 跨服务调用时，下游服务已成功但响应丢失 |
| 节点故障 | 部分节点宕机、磁盘损坏、内存数据丢失 | 订单服务写入成功，但库存服务崩溃 |
| 数据一致性 | 强一致性 vs 最终一致性选择困难 | 支付扣款与积分增加必须原子完成 |
| 事务隔离性 | 分布式锁、幻读、脏读 | 并发下单导致超卖 |
| 性能与吞吐 | 两阶段提交（2PC）阻塞、锁竞争 | 高并发秒杀场景下事务响应时间飙升 |
| 运维复杂度 | 事务日志、补偿机制、监控告警 | 补偿事务（Saga）的回滚链路难以追踪 |
关键认知： 分布式事务没有银弹。不同的业务场景对一致性、可用性、性能的要求各不相同，架构师必须在 CAP 定理 与 BASE 理论 的指导下，根据实际业务需求进行权衡与选型。
1.2 从业务事件出发：事件风暴的引入
面对上述挑战，许多团队在架构选型时容易陷入“技术驱动”的误区——先选定一种分布式事务方案（如 Seata、Saga、TCC），再试图将业务逻辑硬塞进该方案的框架中。这种做法往往导致事务边界划分错误、补偿逻辑混乱、最终一致性难以保证。
事件风暴（Event Storming） 是由 Alberto Brandolini 提出的一种协作建模方法，它通过“领域事件”作为核心驱动，帮助业务专家与技术人员在短时间内共同梳理出完整的业务流程、聚合边界、以及一致性需求。其核心价值在于：在写任何代码之前，先用事件把业务“跑一遍”。
实践建议： 在分布式事务架构选型前，至少组织一次 2-4 小时的事件风暴工作坊。参与角色应包括业务方、产品经理、开发工程师、测试工程师和架构师。使用实体便签或在线白板工具，按照“事件 → 命令 → 聚合 → 限界上下文”的顺序逐步展开。
1.3 事件风暴如何解决分布式事务选型难题
事件风暴并非直接提供分布式事务的技术实现，而是通过以下四个步骤，为架构选型奠定坚实的业务基础：
- 发现领域事件： 识别业务过程中发生的“已经完成”的事实（如“订单已创建”、“库存已扣减”），这些事件往往是分布式事务的边界点。
- 识别命令与角色： 明确是谁、在什么条件下触发了这些事件，从而定位事务的发起方与参与者。
- 划分聚合与限界上下文： 将强一致性的操作封装在同一个聚合内，将最终一致性的操作通过事件驱动跨上下文传递。
- 标记一致性需求： 在事件流上标注“必须同时成功/失败”的节点，这些节点就是分布式事务的候选范围。
下图展示了事件风暴如何将模糊的业务需求转化为清晰的分布式事务边界：
1.4 事件风暴画布与分布式事务的映射关系
在事件风暴工作坊中，团队通常使用时间线画布来组织事件流。这张画布天然适合映射分布式事务的决策点。下表总结了画布上的关键元素与分布式事务选型的对应关系：
| 事件风暴画布元素 | 颜色标记 | 分布式事务含义 | 推荐事务方案 |
|---|---|---|---|
| 领域事件（Domain Event） | 橙色便签 | 事务完成后的状态变更 | 事件驱动 + 最终一致性 |
| 命令（Command） | 蓝色便签 | 事务发起请求 | 幂等性设计 + 重试机制 |
| 聚合（Aggregate） | 黄色便签 | 强一致性边界 | 本地事务 / 2PC / TCC |
| 限界上下文（Bounded Context） | 绿色便签 | 分布式事务的物理边界 | Saga / 异步消息 |
| 策略（Policy） | 紫色便签 | 补偿逻辑 / 超时处理 | 补偿事务 / 定时任务 |
| 外部系统（External System） | 粉色便签 | 不可控的事务参与者 | 补偿 + 人工介入 |
常见误区： 不要试图在事件风暴画布上直接画出分布式事务的技术实现细节（如 XA 协议、事务协调器）。事件风暴的目的是发现业务一致性需求，而不是设计技术方案。技术选型应在事件风暴产出之后，由架构师根据业务边界和一致性要求独立进行。