Cadence Skill脚本实战：如何解决复杂工作流编排中的状态管理难题

1次阅读

共计 1756 个字符，预计需要花费 5 分钟才能阅读完成。

在分布式系统开发中，工作流的状态管理一直是个头疼的问题。特别是当涉及到长事务时，传统的解决方案往往力不从心。

数据库事务补偿：
需要手动编写大量补偿逻辑
难以处理跨服务的复杂事务
补偿失败时系统状态可能不一致
消息队列 + 本地表：
消息丢失或重复消费问题
状态恢复复杂
监控和调试困难

相比之下，Cadence 提供了一种全新的思路。它通过持久化虚拟调用栈和事件溯源模式，使得工作流的状态管理变得简单可靠。

持久化虚拟调用栈
每个工作流执行都会保存完整的调用栈
重启后可以从断点继续执行
实现原理类似于操作系统的进程上下文切换
事件溯源模式的状态恢复
所有状态变更都记录为事件
通过重放事件重建状态
确保崩溃后能准确恢复
信号 / 查询 API 设计
信号 (Signal) 用于外部触发工作流
查询 (Query) 用于获取工作流状态
API 设计简洁高效

// 订单处理工作流定义
func OrderProcessingWorkflow(ctx workflow.Context, orderID string) error {
    // 设置活动重试策略
    ao := workflow.ActivityOptions{
        ScheduleToStartTimeout: time.Minute,
        StartToCloseTimeout:    time.Minute,
        RetryPolicy: &cadence.RetryPolicy{
            InitialInterval:    time.Second,
            BackoffCoefficient: 2.0,
            MaximumInterval:    time.Minute,
            ExpirationInterval: time.Hour * 24,
        },
    }
    ctx = workflow.WithActivityOptions(ctx, ao)

    // 处理支付
    err := workflow.ExecuteActivity(ctx, ProcessPayment, orderID).Get(ctx, nil)
    if err != nil {return err}

    // 处理库存
    err = workflow.ExecuteActivity(ctx, UpdateInventory, orderID).Get(ctx, nil)
    if err != nil {
        // 触发补偿逻辑
        _ = workflow.ExecuteActivity(ctx, RefundPayment, orderID).Get(ctx, nil)
        return err
    }

    // 监听取消信号
    var cancelSignal string
    workflow.GetSignalChannel(ctx, "cancel_order").Receive(ctx, &cancelSignal)
    if cancelSignal == "true" {
        // 处理订单取消
        _ = workflow.ExecuteActivity(ctx, CancelOrder, orderID).Get(ctx, nil)
        return errors.New("order cancelled")
    }

    return nil
}