2. DAG边界定义
在 Temporal 工作流架构中，DAG 边界是区分“工作流内部确定性执行”与“外部非确定性世界”的核心分界线。理解边界的位置、表现形式及其与状态机的关系，是设计可靠工作流的基础。
2.1 什么是工作流 DAG 边界
工作流 DAG（有向无环图）由一系列任务节点和依赖边组成。DAG 边界定义了工作流代码能够直接控制的确定性范围：
- 边界内部：工作流代码、状态变量、决策逻辑、定时器、以及通过
Workflow.newRandom()等 API 生成的确定性随机数。所有操作必须满足确定性要求。 - 边界外部：远程服务调用、数据库读写、文件系统操作、第三方 API 请求等非确定性操作。这些操作必须通过 Activity 封装，由 Temporal 调度执行。
核心原则：工作流代码永远不能直接执行 I/O 操作。任何可能产生非确定性结果的行为都必须跨越 DAG 边界，由 Activity 在 Worker 上执行。
2.2 边界在 Temporal 中的表现形式
Temporal 通过以下机制显式定义和强制执行 DAG 边界：
| 表现形式 | 说明 | 示例 |
|---|---|---|
| Activity 调用 | 工作流通过 ActivityStub 调用外部操作，调用点即为边界跨越点 |
activity.call(input) |
| Workflow.sideEffect | 允许在边界内执行一次非确定性代码，结果被记录到事件历史 | Workflow.sideEffect(() -> random.nextInt()) |
| Signal 接收 | 外部事件通过 Signal 跨越边界进入工作流状态机 | Workflow.await(() -> signalReceived) |
| Query 处理 | 外部查询边界内的工作流状态，不改变状态机 | @QueryMethod 注解方法 |
| Child Workflow | 子工作流调用形成嵌套 DAG 边界 | ChildWorkflowStub 调用 |
| Timer/Future | 时间等待和异步操作在边界内创建确定性调度点 | Workflow.sleep(duration) |
最佳实践：每个 Activity 调用都是显式的边界跨越点。在代码审查时，应确保工作流代码中没有任何直接的网络调用、文件读写或线程操作——这些都必须封装在 Activity 中。
2.3 边界与工作流状态机的关系
工作流状态机是 DAG 边界的运行时实现。每一次边界跨越都会在事件历史中生成一个事件记录，驱动状态机转换：
- 决策任务生成：当工作流代码执行到边界点（如 Activity 调用），Temporal Server 记录事件并生成新的决策任务。
- 状态快照：边界点之间的工作流状态（局部变量、栈帧）被序列化保存，用于故障恢复。
- 重放验证：在 Worker 重启或故障转移时，工作流从事件历史重放，所有边界跨越点必须产生与原始执行完全一致的结果。
2.4 边界对状态机转换的影响
DAG 边界直接决定了状态机的转换粒度和恢复点：
- 细粒度边界：每个 Activity 调用都作为独立状态转换，事件历史增长快，但恢复精度高。
- 粗粒度边界：将多个操作合并到一个 Activity 中，减少状态转换次数，但恢复时需要重做更多工作。
- 边界内状态：工作流变量、计数器、集合等状态在边界内维护，通过
Workflow.upsertSearchAttributes等 API 暴露给外部。
常见陷阱：在工作流代码中直接调用
Thread.sleep() 或 System.currentTimeMillis() 会破坏确定性，导致状态机重放失败。必须使用 Workflow.sleep() 和 Workflow.currentTimeMillis() 等 Temporal 提供的确定性替代 API。
2.5 边界设计原则总结
| 原则 | 说明 | 违反后果 |
|---|---|---|
| 显式边界 | 所有外部操作必须通过 Activity/Signal 等显式机制跨越边界 | 工作流重放不一致，导致决策错误 |
| 最小化边界跨越 | 减少不必要的 Activity 调用，合并相关操作 | 事件历史膨胀，性能下降 |
| 边界幂等性 | Activity 必须设计为幂等，支持重复执行 | 数据重复或状态不一致 |
| 边界可观测性 | 通过 Query 暴露边界内状态，便于监控和调试 | 故障排查困难，运维成本高 |
通过明确定义 DAG 边界，Temporal 工作流能够在保证强一致性的同时，灵活地与外部系统交互。边界是工作流可靠性的基石，也是状态机正确运行的保障。