【开源推荐】 Cadence 长时任务管理

Ryan SU2025/10/10大约 12 分钟

【开源推荐】 Cadence 长时任务管理

一、Cadence 的核心定位与诞生背景

在 Uber 等大型互联网公司的业务场景中，存在大量跨服务、跨节点、长期运行的复杂任务，例如：

网约车订单的全生命周期管理（派单→接驾→行程→支付→发票）；
数据管道的批处理任务（数据采集→清洗→转换→存储→校验）；
微服务间的事务协调（如订单创建后，同步扣库存、减优惠券、生成物流单）。

这些任务面临三大核心挑战：

故障恢复：单个节点宕机、网络波动可能导致任务中断，需确保“从断点继续执行”；
状态管理：任务状态分散在多个服务中，难以追踪全局进度；
复杂性控制：手动编写重试、超时、并发逻辑会导致代码臃肿，可维护性差。

为解决这些问题，Uber 于 2016 年内部开发了 Cadence，并在 2018 年正式开源（基于 MIT 许可证）。它的设计灵感源于 Amazon 的分布式工作流服务 SWF（Simple Workflow Service），但在性能、扩展性和易用性上进行了大幅优化。

二、Cadence 的核心概念

要理解 Cadence，必须先掌握其定义的几个核心抽象概念，这些概念构成了工作流编排的基础：

概念（英文）	核心定义	作用
Workflow（工作流）	定义“业务逻辑的执行流程”，是一个确定性的状态机（输入相同则输出必相同）	描述“要做什么”，例如“订单处理流程”
Activity（活动）	工作流中的具体执行单元，通常是耗时操作或外部依赖调用（如调用 API、操作数据库）	执行“具体任务”，例如“调用支付服务”“发送短信通知”
Worker（工作节点）	运行 Workflow 和 Activity 代码的进程/线程	负责“执行工作流和活动”，可分布式部署以扩展算力
Task（任务）	Cadence 内部拆分的执行单元，分为两种： - Workflow Task：驱动 Workflow 状态机推进； - Activity Task：触发 Activity 执行	作为 Worker 与 Cadence 服务通信的最小单位
Domain（域）	Cadence 中的资源隔离单元，类似“命名空间”	隔离不同业务线的工作流（如“网约车域”“外卖域”），可独立配置权限、存储、重试策略
History（历史记录）	记录 Workflow 从创建到完成的所有状态变更（如“开始→执行 Activity→Activity 成功→结束”）	用于故障恢复（重启时通过 History 重建状态）和审计追溯

三、Cadence 的核心特性

Cadence 之所以能成为分布式工作流领域的主流方案，源于其强大的特性设计，覆盖可靠性、扩展性、易用性等关键维度：

1. 绝对的可靠性：基于“状态持久化”和“重放”

状态持久化：Workflow 的所有状态变更（如执行步骤、Activity 结果）都会被持久化到数据库（默认支持 Cassandra、MySQL、PostgreSQL），即使 Worker 或 Cadence 服务宕机，状态也不会丢失。
Workflow 重放（Replay）：当 Workflow 需恢复时，Cadence 会基于 History 记录，“重放”整个执行过程，重建出当前的状态，确保从断点继续执行，而非重新开始。
- 关键前提：Workflow 代码必须是确定性的（不能包含随机数、当前时间等非确定性逻辑，需通过 Cadence 提供的“确定性工具”规避）。

2. 强大的容错与自愈能力

自动重试：支持为 Activity 配置重试策略（如重试次数、重试间隔、指数退避），无需开发者手动编写重试逻辑；若 Activity 因网络超时、外部服务不可用失败，Cadence 会自动重试。
超时控制：支持多层级超时配置（Workflow 总超时、Activity 超时、Task 超时），避免任务无限阻塞。
故障转移：若执行某个 Activity 的 Worker 宕机，Cadence 会将该 Activity Task 重新分配给其他健康的 Worker，确保任务不中断。

3. 高扩展性：支持海量工作流并发

水平扩展：
- Worker 可无限横向扩展（多节点部署），Cadence 会自动将 Task 分发到空闲 Worker；
- Cadence 服务本身也支持集群部署，通过分片（Sharding）机制拆分任务，支持每秒处理数万级 Task。
存储扩展：支持对接分布式数据库（如 Cassandra），应对海量 History 数据的存储需求。

4. 灵活的任务编排能力

Cadence 支持几乎所有复杂的流程控制逻辑，满足不同业务场景：

顺序执行：按步骤依次执行 Activity（如“创建订单→扣库存→发起支付”）；
并发执行：同时执行多个 Activity（如“并行调用三个不同的数据分析服务”），并支持“等待所有完成”或“等待任意一个完成”；
分支与条件判断：基于 Activity 结果动态选择执行分支（如“支付成功则发送确认短信，失败则取消订单”）；
循环执行：支持固定次数循环或条件循环（如“每天凌晨执行数据同步，持续 30 天”）；
子工作流：支持在一个 Workflow 中嵌套另一个 Workflow（子 Workflow），实现逻辑解耦（如“订单处理 Workflow”嵌套“发票生成子 Workflow”）。

5. 易用的开发者体验

多语言 SDK：官方提供 Java、Go、Python、TypeScript 等主流语言的 SDK，开发者可基于熟悉的语言编写 Workflow 和 Activity 代码；

以 Go SDK 为例，Workflow 代码通过“结构体+方法”定义，Activity 通过普通函数定义，语法简洁：

// 定义 Activity
func PaymentActivity(ctx context.Context, orderID string, amount float64) (bool, error) {
    // 调用支付服务的逻辑
    return true, nil
}

// 定义 Workflow
func OrderWorkflow(ctx context.Context, orderID string, amount float64) error {
    // 1. 执行扣库存 Activity
    if err := workflow.ExecuteActivity(ctx, InventoryActivity, orderID).Get(ctx, nil); err != nil {
        return err
    }
    // 2. 执行支付 Activity（带重试策略）
    retryPolicy := &activity.RetryPolicy{MaximumAttempts: 3}
    if err := workflow.ExecuteActivity(ctx, workflow.WithRetryPolicy(retryPolicy), PaymentActivity, orderID, amount).Get(ctx, nil); err != nil {
        return err
    }
    // 3. 执行发送通知 Activity
    return workflow.ExecuteActivity(ctx, NotifyActivity, orderID).Get(ctx, nil)
}

可视化管理：提供 Web UI（Cadence Web），支持查看 Workflow 的状态、History 记录、Worker 健康度，便于问题排查和运维。

6. 其他关键特性

信号（Signal）与查询（Query）：支持外部系统向运行中的 Workflow 发送“信号”（如“用户取消订单”），或查询 Workflow 的当前状态（如“查询订单处理进度”）；
死信队列（Dead Letter Queue）：多次重试失败的 Activity 会被放入死信队列，避免反复重试占用资源，同时便于后续人工处理；
权限控制：基于 Domain 实现细粒度权限管理（如“只读权限”“执行权限”），确保业务数据安全。

四、Cadence 的架构设计

Cadence 采用“服务端-客户端（Worker）”架构，核心组件分为Cadence 服务集群和Worker 集群两部分，整体架构如下：

1. 核心组件拆解

（1）Cadence 服务集群（Server）

服务端是 Cadence 的“大脑”，负责 Workflow 的状态管理、Task 分发、故障协调等核心逻辑，包含以下组件：

Frontend Service：对外提供 API 接口（如创建 Workflow、发送 Signal、查询状态），负责请求验证、权限检查、负载均衡；
History Service：核心组件，负责管理 Workflow 的 History 记录、维护 Workflow 状态机、生成 Workflow Task 和 Activity Task；
Matching Service：负责“匹配”Task 和 Worker，将 Task 分发到注册了对应 Task Type 的 Worker；
Worker Service：内部 Worker，负责处理一些系统级任务（如清理过期 Workflow、迁移数据）；
Persistence Layer：存储层，对接数据库（Cassandra/MySQL 等），持久化 Workflow History、Domain 配置、Task 元数据等。

（2）Worker 集群（客户端）

Worker 是“执行者”，由开发者部署，负责运行 Workflow 和 Activity 代码，包含以下组件：

Workflow Worker：注册到 Cadence 服务，领取并执行 Workflow Task，驱动 Workflow 状态机推进；
Activity Worker：注册到 Cadence 服务，领取并执行 Activity Task，调用外部服务或执行具体业务逻辑；
SDK：提供与 Cadence 服务通信的接口（如任务领取、结果上报），并封装了重试、超时、重放等底层逻辑。

2. 核心工作流程（以“订单处理”为例）

以一个简单的“创建订单→扣库存→支付”Workflow 为例，Cadence 的执行流程如下：

创建 Workflow：客户端（如订单服务）通过 Cadence SDK 调用 Frontend Service，请求创建“OrderWorkflow”，并传入订单 ID、金额等参数；
生成 Workflow Task：Frontend Service 将请求转发给 History Service，History Service 创建 Workflow 记录，生成第一个 Workflow Task；
分发 Workflow Task：Matching Service 从 History Service 获取 Workflow Task，分发给注册了“OrderWorkflow”的 Workflow Worker；
执行 Workflow 逻辑：Workflow Worker 执行 Workflow Task，按代码逻辑触发第一个 Activity（如“扣库存”），并将“需要执行 Activity”的请求上报给 History Service；
生成 Activity Task：History Service 记录状态变更，生成“扣库存”的 Activity Task，由 Matching Service 分发给 Activity Worker；
执行 Activity 并上报结果：Activity Worker 执行“扣库存”逻辑，完成后将结果（成功/失败）上报给 History Service；
推进 Workflow：History Service 更新 History 记录，生成下一个 Workflow Task，重复步骤 3-6，直到执行完“支付”“通知”等所有步骤；
完成 Workflow：所有步骤执行完成后，History Service 标记 Workflow 为“完成”，并通知客户端。

五、Cadence 的典型应用场景

Cadence 适用于所有需要“可靠协调分布式任务”的场景，尤其在以下领域表现突出：

1. 业务流程自动化

场景：订单全生命周期管理、用户注册流程（验证→开户→发送欢迎礼）、供应链审批流程（下单→备货→发货→签收）；
价值：确保流程不中断，即使中间环节失败也能自动恢复，减少人工干预。

2. 数据处理与ETL

场景：批处理数据管道（日志采集→清洗→脱敏→存储→分析→生成报表）、数据同步（跨数据库/跨地域数据定时同步）；
价值：支持并发处理和失败重试，确保海量数据处理的可靠性，避免数据丢失。

3. 微服务事务协调

场景：跨服务事务（如“订单创建”需同步调用库存、支付、物流服务），替代传统的 2PC（两阶段提交）或 TCC（补偿事务）；
价值：通过“分步执行+状态记录”实现最终一致性，避免 2PC 的性能瓶颈和阻塞问题。

4. 定时任务与延迟执行

场景：延迟通知（订单创建后 30 分钟未支付则自动取消）、定时任务（每天凌晨执行数据备份）；
价值：支持精确的定时触发，且即使服务宕机，恢复后仍能补执行，比传统定时任务（如 Crontab）更可靠。

六、Cadence 的生态与社区

Cadence 作为 Uber 开源的顶级项目，拥有活跃的社区和丰富的生态工具，降低了落地门槛：

1. 官方工具

Cadence Web：可视化管理界面，支持查看 Workflow 列表、状态、History 记录、Worker 状态，支持搜索和筛选；
Cadence CLI：命令行工具，用于 Domain 管理（创建/删除/配置）、Workflow 操作（启动/终止/查询）、日志查看等；
Cadence Bench：性能测试工具，用于模拟海量 Workflow 并发，验证系统性能极限。

2. 社区生态

SDK 扩展：社区基于官方 SDK 开发了更多语言的绑定（如 Rust、PHP）；
集成方案：支持与主流微服务框架（如 Spring Boot、Gin）、消息队列（如 Kafka、RabbitMQ）集成；
案例与文档：Uber、Lyft、Slack 等公司均公开了 Cadence 的落地案例，官方文档（Cadence Docs）详细覆盖从入门到进阶的所有内容。

3. 社区活跃度

代码托管：GitHub 仓库（uber/cadence）拥有 15k+ Star，持续更新；
交流渠道：通过 Slack、GitHub Issues、邮件列表进行社区交流，官方团队响应及时。

七、Cadence 与同类项目的对比

在分布式工作流领域，Cadence 常与 Airbnb 的 Airflow、Netflix 的 Conductor 等项目对比，三者的核心差异如下：

特性	Cadence	Airflow	Conductor（Netflix）
核心定位	通用分布式工作流引擎（长/短任务）	数据管道与定时任务编排（侧重批处理）	微服务工作流协调（侧重跨服务）
任务类型	支持长期运行任务（数小时/天）	侧重短期任务（分钟/小时级）	支持长/短期任务
可靠性	基于 History 重放，故障恢复强	依赖本地元数据，故障恢复较弱	基于状态持久化，恢复能力较强
易用性	多语言 SDK，语法简洁	基于 DAG 文件，Python 生态丰富	支持 UI 定义流程，API 驱动
典型场景	业务流程、微服务事务、数据同步	ETL 批处理、定时报表生成	微服务协调、API 编排

选择建议：

若需处理长期运行、高可靠性的业务流程（如订单、交易），优先选 Cadence；
若需专注数据批处理、定时任务（如 ETL、报表），优先选 Airflow；
若需可视化定义流程、轻量级微服务协调，可考虑 Conductor。

八、Cadence 的落地注意事项

虽然 Cadence 功能强大，但在实际落地时需注意以下问题：

Workflow 确定性原则：必须确保 Workflow 代码无随机数、当前时间、外部状态依赖等非确定性逻辑，否则会导致重放失败；可使用 Cadence SDK 提供的 workflow.Now()（替代系统时间）、workflow.RandomUUID()（替代随机数）等工具规避。
存储成本控制：Workflow 的 History 会随着执行步骤增加而膨胀，需配置历史记录保留策略（如过期自动清理），避免存储成本过高。
Worker 资源规划：根据 Workflow 和 Activity 的执行耗时、并发量，合理规划 Worker 的数量和资源（CPU/内存），避免 Worker 成为瓶颈。
权限与安全：通过 Domain 隔离不同业务线，配置最小权限（如仅允许业务服务调用对应 Domain 的 API），避免越权操作。