Cadence/Temporal新项目设计要点及设计评审流程、模板咨询

设计阶段优先把框架特有约束考虑清楚，别等上线踩坑再补，核心要抓这几点：

• 逻辑边界划分：不要把全链路业务揉成单个巨型工作流，按业务域拆分流程粒度。严格区分Workflow和Activity的职责：Workflow内只允许写确定性逻辑，所有涉及外部IO调用、系统时间获取、随机数生成、非固定分支判断的逻辑全部放到Activity实现——这是新手踩坑最多的点，非确定性逻辑放在Workflow里会在历史重放时直接触发状态不一致故障。短平快的本地事务逻辑不要硬套工作流实现，避免不必要的持久化开销。
• 可靠性规则配置：所有Activity默认存在重试机制，业务实现必须保证幂等，不要依赖框架规避重复调用。针对不同场景配置差异化重试策略：比如支付、通知这类对外调用要配置指数退避、明确最大重试时长，无副作用的查询类接口可以放宽重试限制，参数错误、业务规则校验失败这类明确不可重试的场景，要主动抛出非重试类型异常避免无效资源消耗。长生命周期流程必须提前设计Continue-As-New触发阈值，单工作流历史事件数/大小不要碰框架硬限制（5万事件/50MB），否则流程会直接执行失败。
• 可观测性前置规划：不要用随机UUID作为工作流ID，要和业务主键做绑定映射，否则线上排查问题时根本无法快速定位对应流程。提前梳理需要检索的流程维度，配置对应的Search Attribute——这部分配置上线后无法补全历史流程的检索属性，临时加会导致历史数据无法按维度筛选。提前定义Signal、Query的接口字段规则，后续迭代要保证向下兼容，避免老运行中流程无法响应信号/查询。
• 版本与运维成本预估：工作流上线后必然会迭代逻辑，提前规划版本控制方案，通过框架提供的版本API做新老逻辑分支，禁止直接修改运行中老流程的执行逻辑，否则会触发重放故障。Worker部署不要混部所有类型任务：高CPU消耗、高IO延迟的Activity要单独划分Task Queue、独立部署节点池，避免和低延迟任务抢占资源影响整体可用性。

评审流程 #

正式评审没有强制统一的行业标准，团队落地时一般按三个阶段走：

• 前置准备阶段：设计负责人提前2-3个工作日将设计文档同步给所有参与方（业务开发、SRE、框架运维、测试），文档中必须单独列出Cadence/Temporal相关的专属设计内容，不要只写通用业务逻辑。
• 正式评审阶段：
  1. 先校验逻辑映射合理性：确认业务节点和Workflow/Activity/Child Workflow/Signal的对应关系是否正确，排查是否存在非确定性逻辑放在Workflow中的设计问题
  2. 再校验可靠性覆盖度：逐个核对每个Activity的超时、重试、幂等方案，检查长流程的Continue-As-New配置、异常场景的Saga补偿逻辑是否覆盖全
  3. 最后校验运维可落地性：确认Search Attribute配置、核心监控告警项（工作流失败率、Activity超时、Worker存活状态）、故障处理预案（卡单重跑、异常流程终止、数据修复方案）是否完备
• 评审收尾阶段：所有评审提出的问题闭环后文档归档，上线前由框架运维侧校验命名空间、Task Queue、权限、集群容量配置是否符合要求。

专属记录模板核心字段 #

没有官方强制的统一模板，实际落地时文档里只要单独辟出Cadence/Temporal专属板块，覆盖以下信息就不会漏项：

• 基础配置项：使用的框架版本、对应集群命名空间、Task Queue划分规则、工作流ID生成规则
• 流程结构定义：每个Workflow的输入输出结构、关联的Activity清单（含每个Activity的超时、重试规则、幂等实现方案）、Child Workflow调用关系、Signal/Query的接口字段定义
• 可靠性规则：Continue-As-New触发阈值、工作流版本兼容方案、异常补偿流程、不可重试错误类型清单
• 运维相关配置：需要新增的Search Attribute清单、核心监控告警规则、常见故障处理预案、Worker部署规格与扩缩容规则

内容的提问来源于stack exchange，提问作者Long Quanzheng