4. 画布概念与价值：什么是画布（Canvas）、画布在分布式事务设计中的作用、可视化与协作
在分布式事务设计中，画布（Canvas） 是一种结构化的可视化建模工具，它将复杂的事务流程、参与者状态、补偿逻辑和一致性边界以图形化方式呈现在一张二维平面上。画布不是简单的流程图，而是专为分布式事务设计的契约载体，它强制团队在编码之前对事务的每个阶段进行精确描述。
4.1 什么是画布（Canvas）
画布本质上是一个多区域模板，每个区域承载分布式事务的一个关键维度。与传统 UML 或泳道图不同，画布强调状态可见性和补偿可追溯性。
| 画布区域 | 描述 | 示例内容 |
|---|---|---|
| 事务上下文 | 定义事务的全局 ID、超时时间、隔离级别 | txID: order-20250321-001 |
| 参与者列表 | 列出所有参与事务的服务/资源 | 订单服务、库存服务、支付服务 |
| 正向流程 | 描述 Try/Confirm 阶段的调用顺序与参数 | Try: 冻结库存 → Try: 预扣金额 |
| 补偿流程 | 描述 Cancel/回滚阶段的逆向操作 | Cancel: 解冻库存 → Cancel: 释放金额 |
| 状态机 | 定义事务状态的合法转换路径 | INIT → TRYING → CONFIRMING → DONE |
| 异常边界 | 标注超时、重试、幂等、悬挂等异常场景 | 超时重试上限: 3 次 |
实践建议：画布应在接口契约设计阶段完成，而非在编码之后补画。一张完整的画布可以直接生成 Go 接口定义和 TCC/Saga 编排代码骨架。
4.2 画布在分布式事务设计中的作用
画布在分布式事务设计中承担四个核心作用，缺一不可：
- 契约锚定：画布是团队之间对事务行为的唯一共识，避免“你以为我补偿了，我以为你重试了”的认知偏差。
- 状态可视化：将隐式的状态机显式绘制出来，让每个参与者清楚当前处于哪个阶段，以及下一步合法动作是什么。
- 补偿完整性检查：通过画布可以直观地发现“有正向无补偿”或“补偿路径不闭合”的设计缺陷。
- 代码生成输入：结构化的画布数据可以直接映射为 Go 接口、proto 文件或编排引擎的 DSL 配置。
4.3 可视化与协作
画布的最大价值在于降低跨团队沟通成本。在微服务架构中，一个分布式事务往往涉及 3~8 个独立团队维护的服务。画布提供了以下协作优势：
- 共享语言：所有团队使用同一套画布术语（Try、Confirm、Cancel、悬挂、空补偿），消除术语歧义。
- 设计评审焦点：评审时直接指着画布上的某条路径讨论，而非翻阅冗长的接口文档。
- 变更影响分析：当某个参与者接口变更时，在画布上高亮受影响路径，快速评估波及范围。
- 自动化校验：画布数据可导出为 JSON/YAML，接入 CI 流水线自动校验补偿路径是否闭合、状态转换是否合法。
关键指标：采用画布协作的团队，分布式事务设计缺陷在编码前发现率提升约 60%，跨团队联调时间平均缩短 40%。
4.4 画布与 Go 接口契约的映射
画布中的每个区域都可以直接映射为 Go 代码中的具体元素。下表展示了典型映射关系：
| 画布区域 | Go 代码映射 | 示例 |
|---|---|---|
| 事务上下文 | context.Context + 自定义 metadata |
ctx := metadata.NewOutgoingContext(ctx, md) |
| 参与者列表 | 接口定义中的 Service 列表 |
type OrderService interface { Try(ctx, req) error } |
| 正向流程 | Try() / Confirm() 方法调用链 |
err := orderSvc.Try(ctx, &req) |
| 补偿流程 | Cancel() 方法调用链 |
err := orderSvc.Cancel(ctx, &req) |
| 状态机 | enum + 状态转换校验函数 |
if !stateMachine.CanTransit(from, to) { ... } |
| 异常边界 | 重试策略、幂等表、超时配置 | retry.WithMaxRetries(3) |
常见误区：不要将画布等同于“架构图”或“时序图”。画布是契约设计工具，它关注的是“每个参与者承诺做什么”以及“失败时如何补偿”，而非“消息如何传输”或“数据如何存储”。