📚 课程目录第4章任务编排引擎设计

4. 任务编排引擎设计：基于DAG的任务依赖模型与状态机

在平台工程变更风险评估的上下文中，任务编排引擎是核心调度中枢。它负责将复杂的风险评估流程拆解为可独立执行、可并行、可重试的原子任务，并确保这些任务按照正确的依赖关系有序执行。本章将详细阐述基于DAG（有向无环图）的任务依赖模型以及任务状态机的设计，这是实现Argo CD移植适配的关键基础。

4.1 基于DAG的任务依赖模型

传统的线性或硬编码的任务编排方式在面对多分支、条件判断和并行执行的复杂场景时，显得僵化且难以维护。DAG模型通过定义任务节点（Vertex）和依赖边（Edge），天然支持复杂的执行逻辑，且无环的特性保证了流程不会陷入死循环。

在变更风险评估场景中，一个典型的DAG可能包含以下节点类型：

数据采集节点：从CMDB、监控系统、代码仓库拉取变更元数据。
静态分析节点：对变更代码或配置进行语法、合规性扫描。
影响范围计算节点：基于服务依赖拓扑图计算变更的潜在爆炸半径。
并行检查节点：同时执行安全扫描、性能基线比对、容量评估。
聚合决策节点：汇总所有检查结果，输出最终风险等级（低/中/高/阻断）。

    设计原则：DAG中的每个节点应保持原子性（只做一件事），依赖关系应明确为“前置条件”而非“数据传递”，数据传递通过共享的上下文（Context）对象完成。

下表对比了传统线性编排与DAG编排在关键维度上的差异：

维度	传统线性编排	DAG编排
执行顺序	严格串行，无法跳过	支持并行、串行、条件跳过
扩展性	修改流程需重写代码	通过添加/删除节点和边即可调整
失败处理	整体失败，回滚困难	支持局部重试、跳过、降级
可视化	难以直观展示	天然支持图形化展示
适用场景	简单、固定的流水线	复杂、多分支的风险评估

以下SVG图展示了一个简化的变更风险评估DAG模型，其中包含了并行分支和条件聚合节点：

4.2 任务状态机设计

每个DAG节点（即任务）在其生命周期中会经历多个状态。一个清晰、完备的状态机是保证任务可观测性、可恢复性和可审计性的基础。我们为变更风险评估任务定义了以下五种核心状态：

Pending（待执行）：任务已创建，但前置依赖尚未全部满足，等待调度。
Running（运行中）：任务已被调度器分配给执行器，正在执行。
Succeeded（成功）：任务执行完毕，返回结果符合预期。
Failed（失败）：任务执行过程中发生不可恢复的错误。
Skipped（跳过）：任务因前置条件不满足（如上游任务失败且策略为“跳过”）或条件判断为假而被跳过。

设计要点：在Argo CD的移植适配中，Skipped状态尤为重要。它允许我们在风险评估流程中实现“短路”逻辑。例如，如果“静态分析”发现代码存在高危漏洞，则后续的“性能测试”节点可以被标记为Skipped，从而节省计算资源并加速反馈。

以下状态转换表定义了所有合法的状态跃迁路径：

当前状态	触发事件	下一状态	说明
Pending	所有前置依赖满足	Running	调度器分配资源
Pending	上游任务Failed且策略为Skip	Skipped	条件跳过
Running	任务正常完成	Succeeded	输出结果写入上下文
Running	任务抛出异常或超时	Failed	记录错误信息
Failed	手动重试或自动重试策略触发	Pending	重新入队等待调度
Skipped	（终态）	—	不可转换到其他状态
Succeeded	（终态）	—	不可转换到其他状态

下面的SVG图展示了任务状态机的完整流转路径，包括重试回退机制：

4.3 状态机与DAG的协同工作

DAG模型定义了任务的静态拓扑结构，而状态机则管理每个任务的动态生命周期。编排引擎的核心逻辑在于：

调度决策：引擎持续扫描DAG中所有状态为Pending的节点，检查其所有上游节点的状态是否为Succeeded或Skipped。如果满足，则将该节点状态转换为Running并分配执行。
失败传播：当一个节点进入Failed状态时，引擎根据预设的失败策略（阻断/跳过）来决定其下游节点的命运。若策略为“阻断”，则下游节点保持Pending状态，整个DAG暂停；若策略为“跳过”，则下游节点直接进入Skipped状态。
上下文传递：每个任务执行完毕后，其输出结果（如风险评分、检查报告）会被写入一个全局的WorkflowContext对象中。下游任务可以通过表达式（如{{context.tasks.static_analysis.result}}）引用这些数据，实现条件分支判断。

移植适配注意：在将上述模型移植到Argo CD时，需要特别注意Argo Workflows的when表达式和continueOn字段的映射关系。Argo原生不支持Skipped状态，通常通过when: "{{tasks.previous.status}} != Failed"来实现类似效果。我们的适配层需要封装这一差异，对外暴露统一的状态机接口。

4.4 任务编排引擎核心接口定义

为了实现与Argo CD的无缝集成，我们定义了以下核心接口，用于抽象DAG和状态机的操作：

// TaskNode 定义DAG中的一个任务节点
type TaskNode struct {
    ID          string            // 唯一标识
    Name        string            // 任务名称
    Dependencies []string         // 依赖的上游节点ID列表
    Action      string            // 执行动作（如：http_call, script_run）
    InputParams map[string]string // 输入参数
    RetryPolicy *RetryPolicy      // 重试策略
    SkipOnFail  bool              // 上游失败时是否跳过
}

// TaskStatus 定义任务状态
type TaskStatus string

const (
    StatusPending   TaskStatus = "Pending"
    StatusRunning   TaskStatus = "Running"
    StatusSucceeded TaskStatus = "Succeeded"
    StatusFailed    TaskStatus = "Failed"
    StatusSkipped   TaskStatus = "Skipped"
)

// Engine 编排引擎接口
type Engine interface {
    // SubmitDAG 提交一个DAG定义，返回工作流实例ID
    SubmitDAG(dag *DAGDefinition) (string, error)
    // GetTaskStatus 查询指定工作流中某个任务的状态
    GetTaskStatus(workflowID, taskID string) (TaskStatus, error)
    // CancelWorkflow 取消一个正在运行的工作流
    CancelWorkflow(workflowID string) error
    // RetryTask 重试一个失败的任务
    RetryTask(workflowID, taskID string) error
}

通过上述接口设计，上层风险评估应用无需关心底层是直接调用Kubernetes Job还是Argo Workflows，只需面向DAG和状态机编程即可。这为后续的Argo CD移植适配提供了清晰的抽象边界。