任务编排基础：工作流引擎概述、DAG 模型、任务依赖与状态管理
在平台工程中，弹性伸缩并非单一动作，而是一系列有序任务的组合：先检测指标、再决策扩容、接着调用 API 启动实例、最后等待健康检查通过。任务编排正是将这些原子操作组织成可执行、可观测、可恢复的工作流。本章聚焦工作流引擎的核心概念、DAG 模型、任务依赖关系与状态管理，为后续的开发者体验优化奠定理论基础。
3.1 工作流引擎概述
工作流引擎是负责解析、调度、执行和监控任务序列的运行时系统。在弹性伸缩场景下，它承担以下职责：
- 任务解析：将 YAML/JSON 或 DSL 定义的工作流描述转换为内存中的执行图。
- 调度执行：根据依赖关系决定任务启动顺序，支持并行与串行。
- 状态持久化：记录每个任务的当前状态、输入输出、重试次数。
- 异常处理：超时、失败、重试、回滚策略的自动执行。
- 可观测性：暴露进度、耗时、错误率等指标供 SRE 监控。
| 特性 | 传统脚本编排 | 工作流引擎编排 |
|---|---|---|
| 任务依赖 | 隐式（脚本顺序） | 显式（DAG 定义） |
| 失败恢复 | 手动重跑 | 自动重试 + 断点续跑 |
| 并行能力 | 需自行实现并发控制 | 引擎原生支持 |
| 可观测性 | 日志分散 | 统一状态 + 事件流 |
| 开发者体验 | 调试困难 | 可视化 + 状态回溯 |
平台工程视角：选择工作流引擎时，应优先考虑与现有基础设施（Kubernetes、消息队列、CI/CD）的集成能力，而非单纯追求功能丰富度。开发者体验的起点是“低心智负担的编排定义”。
3.2 DAG（有向无环图）模型
DAG 是任务编排的数学基础。每个任务是一个节点，任务间的依赖关系是一条有向边，整个图不允许存在环——即不能出现 A 依赖 B、B 又依赖 A 的死锁情况。
在弹性伸缩工作流中，典型的 DAG 结构包含以下节点类型：
- 源节点：无入边，通常为触发事件或指标采集。
- 处理节点：执行具体操作，如调用云 API、执行脚本。
- 判断节点：根据条件选择下游分支（类似编程中的 if/else）。
- 汇聚节点：等待多个前置任务完成后统一执行下一步。
- 终节点：无出边，表示工作流结束。
关键原则：DAG 的无环特性保证了工作流必然终止。在平台工程中，应通过静态校验（如拓扑排序）在部署阶段就检测出循环依赖，避免运行时死锁。
3.3 任务依赖与状态管理
3.3.1 任务依赖类型
任务依赖定义了节点间的执行约束。在弹性伸缩场景中，常见的依赖关系包括：
| 依赖类型 | 语义 | 弹性伸缩示例 |
|---|---|---|
| 顺序依赖 | B 必须在 A 完成后才能开始 | 先创建实例，再配置负载均衡 |
| 条件依赖 | B 仅在 A 的特定结果下执行 | 扩容成功后才更新 DNS |
| 并行依赖 | 多个任务无依赖关系，可同时执行 | 同时调用多个云区域 API |
| 汇聚依赖 | C 必须等待 A 和 B 都完成 | 所有实例就绪后执行健康检查 |
| 超时依赖 | B 在 A 超时后自动触发降级 | 扩容超时后触发回滚 |
3.3.2 任务状态机
每个任务实例在其生命周期中经历一系列状态。标准的状态模型如下：
- PENDING：任务已定义，但尚未满足依赖条件。
- READY：所有前置依赖已满足，等待调度。
- RUNNING：任务正在执行中。
- SUCCEEDED：任务正常完成。
- FAILED：任务执行出错。
- SKIPPED：条件判断导致跳过。
- RETRYING：失败后进入重试流程。
- TIMED_OUT：超过预设时间仍未完成。
3.3.3 状态持久化与恢复
工作流引擎必须将状态持久化到外部存储（数据库、etcd、Redis），以支持以下场景：
- 断点续跑：引擎重启后，从最后一个持久化的状态继续执行，而非从头开始。
- 审计追溯：SRE 可以查询任意历史工作流的每个任务状态、耗时、错误信息。
- 并发控制：通过乐观锁或分布式锁防止同一工作流被多次调度。
常见陷阱：状态持久化本身可能成为性能瓶颈。在弹性伸缩高频场景下（如每秒触发数十次扩容），应使用异步写 + 缓存策略，避免每次状态变更都同步写数据库。
3.4 开发者体验优化切入点
基于上述基础概念，平台工程团队可以从以下维度优化开发者体验：
| 维度 | 当前痛点 | 优化方向 |
|---|---|---|
| 编排定义 | YAML 冗长、易出错 | 提供可视化 DAG 编辑器 + 模板库 |
| 调试体验 | 失败后需手动分析日志 | 状态回溯 + 任务级重跑按钮 |
| 可观测性 | 状态分散在多个系统 | 统一工作流仪表盘 + 事件推送 |
| 错误处理 | 重试策略需硬编码 | 声明式重试 + 超时策略 |
| 测试能力 | 难以模拟依赖失败 | 沙箱模式 + 故障注入 |
核心思路：将工作流引擎的底层复杂性（DAG 解析、状态机、持久化）封装为平台能力，让开发者只需关注业务逻辑——定义“做什么”，而非“怎么做”。