共计 1795 个字符，预计需要花费 5 分钟才能阅读完成。
工作流定义的核心价值
Cadence（工作流引擎）的核心价值在于将业务逻辑与执行逻辑分离。与普通代码相比，工作流定义（Workflow Definition）具有三个显著特点：
-
持久化状态 ：工作流状态自动持久化，即使进程重启也能恢复执行。这使得开发者无需手动处理状态存储和恢复。
-
确定性执行 ：工作流代码必须是确定性的（Deterministic），这意味着相同的输入必须产生相同的输出。这与普通代码可以包含随机因素不同。
-
长时间运行 ：工作流可以运行数天甚至数月，而普通代码通常是短期执行的。
典型错误模式分析
1. 未处理信号丢失
信号（Signal）是工作流间通信的重要方式。常见错误是假设信号一定会被接收，而忽略了网络分区或工作流重启等情况。
# 错误示例：直接使用信号值而不检查是否存在
signalValue := workflow.GetSignalChannel(ctx, "signalName").Receive(ctx, nil)2. 超时设置不合理
超时（Timeout）设置过短会导致工作流频繁超时，设置过长则会影响系统响应速度。
# 错误示例：活动任务超时设置不当
- name: ProcessOrder
timeout: 1s # 对于数据库操作来说太短 3. 未考虑幂等性
工作流可能因各种原因重试，如果不实现幂等性（Idempotency），可能导致重复操作。
// 错误示例：非幂等的订单处理
func ProcessOrder(ctx context.Context, orderID string) error {
// 直接创建订单，没有检查是否已存在
return db.CreateOrder(orderID)
}Skill 文件标准结构
一个完整的 Skill 文件应包含以下部分：
- metadata：工作流的基本信息，如名称、版本等。
- workflow：工作流的具体定义，包括状态、信号、查询等。
- activities：活动任务的列表和配置。
- retryPolicy：重试策略配置。
- timeouts：超时设置。
# YAML 示例
metadata:
name: OrderProcessingWorkflow
version: 1.0
workflow:
states:
- name: ProcessOrder
type: activity
activity: ProcessOrder
retryPolicy:
initialInterval: 1s
maximumInterval: 60s
activities:
- name: ProcessOrder
type: function
timeout: 30s幂等性实现
以下是 Go 语言中实现幂等性的示例：
func ProcessOrder(ctx workflow.Context, orderID string) error {
// 检查订单是否已处理
var processed bool
if err := workflow.SideEffect(ctx, func(ctx workflow.Context) interface{} {return db.OrderExists(orderID)
}).Get(&processed); err != nil {return err}
if processed {return nil // 已处理，直接返回}
// 处理订单
return workflow.ExecuteActivity(ctx, ProcessOrderActivity, orderID).Get(ctx, nil)
}性能考量
历史分片数量估算
历史分片（History Shard）数量的估算公式为：
分片数 = 最大工作流数 / 单分片承载能力 通常单分片能承载约 10,000 个活跃工作流。
活动任务超时与重试的黄金比例
推荐的超时与重试比例为：
初始间隔 * 2^(重试次数 -1) ≤ 总超时时间 例如，初始间隔 1s，最大间隔 60s，最大重试次数 6 次。
生产环境检查清单
- 信号去重方案 ：使用唯一 ID 标识信号，并在工作流中记录已处理的信号 ID。
- 跨版本兼容策略 ：工作流定义变更时，确保旧版本工作流能继续执行。
- 监控指标埋点 ：监控工作流执行时间、活动任务成功率等关键指标。
开放式问题
- 如何设计补偿工作流（Compensation Workflow）来处理失败的操作？
- 在工作流中如何优雅地处理第三方服务的速率限制（Rate Limiting）？
通过本文的介绍，希望您能掌握 Cadence 工作流定义的核心要点，构建出可靠、高效的工作流系统。
正文完
