基于事件风暴画布的分布式事务环境配置与接口调试 - 第1节
1.1 分布式事务的根源与挑战
在单体应用向微服务架构迁移的过程中，数据一致性从“本地事务”演变为“跨服务、跨数据库”的分布式事务问题。分布式事务的核心矛盾在于：如何在不牺牲可用性与性能的前提下，保证多个独立服务之间的数据最终一致。
1.1.1 分布式事务的典型场景
| 场景 | 参与服务 | 一致性要求 |
|---|---|---|
| 订单创建 | 订单服务、库存服务、支付服务 | 扣库存成功 → 支付成功 → 订单状态更新 |
| 用户注册送券 | 用户服务、积分服务、优惠券服务 | 注册成功 → 积分增加 → 优惠券发放 |
| 跨行转账 | 账户A服务、账户B服务、清算服务 | 扣款成功 → 入账成功 → 清算记录 |
1.1.2 分布式事务面临的四大挑战
- 网络不确定性：服务间调用可能超时、重试、乱序，导致状态不一致。
- 数据分区与隔离：每个服务拥有独立数据库，无法使用本地ACID事务跨库保证一致性。
- 协调者单点与性能瓶颈：传统XA两阶段提交（2PC）的协调者容易成为性能瓶颈，且阻塞资源。
- 业务补偿复杂性：失败时需设计逆向操作（如退款、回滚库存），补偿逻辑容易遗漏或出错。
关键认知：分布式事务没有“银弹”。不同场景需要选择不同的最终一致性模型（如TCC、Saga、可靠消息），而选择的前提是准确理解业务边界与事件流。
1.2 事件风暴：从业务混沌到事务边界
事件风暴（Event Storming）是由Alberto Brandolini提出的一种协作建模方法，通过“领域事件”驱动，让业务专家与技术人员在同一画布上快速对齐业务全貌。在分布式事务设计中，事件风暴的价值体现在三个层面：
- 发现事务边界：通过事件流识别哪些操作必须在一个事务内完成，哪些可以异步最终一致。
- 识别补偿点：在事件流中标记失败回滚的触发条件与补偿动作。
- 统一语言：业务术语与技术实现之间建立精确映射，减少沟通偏差。
1.2.1 事件风暴画布的核心元素
| 元素 | 颜色（参考） | 含义 | 在分布式事务中的角色 |
|---|---|---|---|
| 领域事件 | 橙色 | 业务中已发生的事实（如“订单已创建”） | 事务的触发点或完成标志 |
| 命令 | 蓝色 | 触发事件的用户或系统动作 | 事务的发起入口 |
| 聚合 | 黄色 | 业务一致性边界内的实体与值对象 | 事务的原子操作单元 |
| 外部系统 | 粉色 | 与当前系统交互的第三方服务 | 事务中可能引入网络不确定性的外部依赖 |
| 策略/规则 | 紫色 | 业务决策逻辑 | 决定事务分支是否执行或回滚 |
实践建议：在事件风暴工作坊中，建议使用物理便签纸（橙色、蓝色、黄色、粉色、紫色）贴在墙上，让所有参与者动手移动便签，快速迭代事务边界。本课程后续章节将演示如何将物理便签映射为数字画布。
1.3 分布式事务模式与事件风暴的映射
事件风暴画布上识别出的“领域事件”和“聚合”可以直接指导分布式事务模式的选择。下表展示了三种主流模式与事件风暴元素的对应关系：
| 分布式事务模式 | 核心思想 | 事件风暴映射 | 适用场景 |
|---|---|---|---|
| TCC（Try-Confirm-Cancel） | 预留资源 → 确认/回滚 | 每个聚合对应一个TCC分支；Try阶段对应命令，Confirm/Cancel对应领域事件 | 短事务、高一致性要求（如支付、库存扣减） |
| Saga（编排/协同） | 长事务拆分为本地事务+补偿 | 每个领域事件对应一个本地事务；补偿事件对应逆向操作 | 长事务、允许最终一致（如订单流程、审批流） |
| 可靠消息（本地消息表/事务消息） | 消息持久化+异步投递 | 命令产生事件消息，聚合消费消息并执行本地事务 | 异步解耦、跨团队协作（如通知、积分发放） |
常见误区：不要试图用事件风暴直接画出分布式事务的技术实现细节（如消息队列、数据库锁）。事件风暴的产出是业务事件流，技术选型应在事件风暴之后，根据事件流特征（如事件数量、时效性、失败概率）进行。
1.4 从事件流到事务配置：课程全景图
本课程围绕“事件风暴画布 → 分布式事务配置 → 接口调试”这条主线展开。下图展示了课程的核心知识结构：
1.5 本章小结：事件风暴是分布式事务设计的起点
- 分布式事务的核心挑战来自网络不确定性、数据分区、协调者瓶颈、补偿复杂性。
- 事件风暴通过领域事件、命令、聚合等元素，帮助团队在业务层面快速划定事务边界。
- 不同分布式事务模式（TCC、Saga、可靠消息）可以映射到事件风暴画布上的不同元素组合。
- 本课程后续章节将基于事件风暴的产出，逐步展开环境配置、代码实现、接口调试的完整实践。