工作流编排是什么
工作流编排引擎用流程定义或状态机描述多步骤任务的执行顺序，并由引擎持久化每一步的状态。它与 crontab 加脚本的关键差别在于：步骤状态落库、失败可重试、跨系统失败可补偿、人工节点可挂起等待、全链路执行历史可查。订单、审批、数据处理、资源开通这类跨越多个系统且必须可靠跑完的流程，通常交给编排引擎而不是脚本串行调用。
基本信息
| 核心要素 | 流程定义、状态与迁移、步骤幂等、重试与退避、超时、补偿、人工节点 |
|---|---|
| 常见实现 | Temporal/Cadence（代码即流程）、Camunda/Zeebe（BPMN 建模）、Airflow（数据管道调度）、Argo Workflows（Kubernetes 内编排） |
| 选型维度 | 与现有系统集成成本、可观测性、流程改版与灰度能力、社区活跃度、运维复杂度 |
| 运行前提 | 业务动作自身幂等，引擎侧才能安全重试 |
典型使用场景
- 交易与订单：下单、扣库存、支付、发货、通知跨系统串联，任一步失败要回滚
- 审批流：请假、采购、上线申请，中途挂起等人工决策再继续
- 数据处理：抽取、清洗、入仓、报表，按依赖关系调度并重跑失败任务
- 基础设施自动化：开通云资源、下发配置、部署到 Kubernetes，失败自动回收半成品
- 跨系统对账：定时拉取两侧数据比对，差异生成工单而非直接改账
步骤定义要点
步骤定义要点
步骤名：deduct_stock
幂等键：order_id # 同一订单重复执行不重复扣减
重试策略：最多 3 次，指数退避 1s/4s/16s # 仅对超时等可重试错误生效
超时：30s # 超时按失败处理
补偿动作：restore_stock # 后续步骤失败时按逆序执行
留痕：每步输入输出、执行人、耗时入库常见编排模式
| 模式 | 用途 | 典型风险 |
|---|---|---|
| 重试加退避 | 应对网络抖动、下游限流等临时故障 | 无上限重试放大下游压力 |
| 补偿事务 | 跨系统一致性，按逆序撤销已完成步骤 | 补偿动作自身失败后需人工兜底 |
| 人工审批节点 | 关键步骤须有人把关 | 审批人缺席导致流程长期挂起 |
| 并行与汇聚 | 多路任务同时执行后合并等待 | 一路超时未设超时策略会拖住整个流程 |
| 定时与事件触发 | 按周期跑批或由消息驱动 | 重复投递引发重复执行 |
引擎保证的是“流程会推进且状态不丢”，不保证业务动作恰好执行一次。真实网络里至少一次投递更常见，因此每个会改数据的步骤都要自带幂等键或去重表，否则重试就会变成重复扣款。
流程定义会不断改版，但线上往往有正在执行的长流程实例。主流引擎通过流程版本化处理：新实例走新版本，老实例按启动时的版本跑完，改版前要确认兼容性，不要直接覆盖运行中流程的定义。