3、任务编排引擎架构：引擎分层设计、调度器、执行器、状态管理器
任务编排引擎是变更风险评估平台的核心执行单元，负责将用户定义的 DAG（有向无环图）任务拓扑解析为可调度、可追踪、可容错的执行流。本章从分层架构出发，逐一剖析调度器、执行器与状态管理器的职责边界、协作模式及性能关键点。
3.1 引擎分层设计
引擎采用经典的三层架构：调度层、执行层、状态管理层。层间通过异步消息通道解耦，避免同步阻塞导致级联故障。
| 层级 | 核心职责 | 典型组件 | 性能关注点 |
|---|---|---|---|
| 调度层 | DAG 解析、依赖拓扑排序、并发度控制、任务分发 | DAG 解析器、优先级队列、分发器 | 拓扑排序延迟、队列积压、分发吞吐 |
| 执行层 | 任务实例化、资源绑定、本地执行或远程调用、结果回写 | Worker 池、插件加载器、超时控制器 | 线程池饱和度、上下文切换、I/O 等待 |
| 状态管理层 | 任务状态持久化、快照恢复、事件通知、审计追踪 | 状态机、事件总线、存储适配器 | 写入延迟、状态冲突、存储 IOPS |
设计原则：调度层不感知具体执行逻辑，执行层不持有全局状态，状态管理层不参与任务调度决策。这种职责分离使每一层都可以独立扩缩容，避免单点瓶颈。
3.2 调度器（Scheduler）
调度器是引擎的“大脑”，负责将 DAG 定义转化为可执行的调度单元。其核心流程包括：
- DAG 解析与校验：读取用户提交的 JSON/YAML 拓扑，校验节点依赖是否存在环、参数是否完整。
- 拓扑排序：使用 Kahn 算法或 DFS 生成线性执行序列，标记可并行执行的节点。
- 并发度控制：根据全局并发配额（如 maxParallelism=32）和节点资源标签，决定同时下发的任务数。
- 任务分发：将就绪任务封装为消息，推送到执行层的消费队列。
性能调优要点：
- 拓扑排序使用邻接表 + 队列实现，时间复杂度 O(V+E)，避免递归 DFS 导致栈溢出。
- 并发度控制采用令牌桶算法，防止突发流量打满执行层。
- 分发器使用批量提交（batch size 50~200）减少网络往返。
3.3 执行器（Executor）
执行器是引擎的“四肢”，负责实际运行任务。每个执行器实例维护一个 Worker 线程池，从调度队列拉取任务并执行。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| corePoolSize | CPU 核数 × 2 | 核心线程数，处理 CPU 密集型任务 |
| maxPoolSize | CPU 核数 × 4 | 最大线程数，应对 I/O 等待场景 |
| queueCapacity | 1024 ~ 4096 | 等待队列容量，防止内存溢出 |
| keepAliveTime | 60s | 空闲线程回收时间 |
| taskTimeout | 300s（可配置） | 单任务超时，防止僵尸任务 |
常见故障模式：当执行器线程池被慢任务占满时，后续任务会堆积在队列中，导致调度器分发超时。建议为不同优先级任务配置独立线程池，或使用
Semaphore 限制慢任务并发数。
3.4 状态管理器（State Manager）
状态管理器维护每个任务的完整生命周期状态，支持故障恢复与审计查询。状态机定义如下：
状态转换规则（简化版）：
PENDING → RUNNING → SUCCESS
PENDING → RUNNING → FAILED → RETRYING → RUNNING
PENDING → RUNNING → TIMEOUT → RETRYING → RUNNING
PENDING → SKIPPED（依赖失败时）
RUNNING → CANCELED（用户手动终止）状态存储选型对比：
| 存储后端 | 写入延迟（P99） | 一致性模型 | 适用场景 |
|---|---|---|---|
| MySQL（InnoDB） | 5~15ms | 强一致 | 中小规模（节点数 < 10K） |
| Redis（AOF） | 1~3ms | 最终一致 | 高吞吐、可接受短暂不一致 |
| etcd（Raft） | 3~8ms | 线性一致 | 分布式锁、选主、关键状态 |
快照恢复策略：状态管理器每隔 N 个状态变更或固定时间间隔（如 30s）生成一次快照。引擎重启时，从最新快照恢复，再回放快照之后的增量事件日志，实现秒级恢复。
3.5 三层协作时序
一次完整的任务执行流程在三层间的协作时序如下：
1. 用户提交 DAG → 调度器接收并解析
2. 调度器拓扑排序 → 生成就绪任务列表
3. 调度器将就绪任务推送到执行队列（Kafka Topic: executor-in）
4. 执行器消费队列 → 分配 Worker 线程 → 执行任务
5. 执行器将结果写入状态队列（Kafka Topic: state-in）
6. 状态管理器消费状态队列 → 更新状态机 → 持久化
7. 状态管理器发布状态变更事件（Event Bus）→ 调度器监听
8. 调度器收到 SUCCESS/FAILED 事件 → 解锁下游依赖 → 重复步骤 3~7
性能关键路径：步骤 3→4→5→6 构成核心链路。瓶颈通常出现在状态写入（步骤 6）和事件通知（步骤 7）。建议将状态写入异步化，使用批量刷盘 + 内存缓冲降低 P99 延迟。
3.6 故障排查清单
| 现象 | 可能原因 | 排查命令 / 工具 |
|---|---|---|
| 任务一直 PENDING | 调度器队列积压 / 依赖死锁 | kafka-consumer-groups --describe 查看 lag |
| 任务执行超时 | Worker 线程池耗尽 / 慢任务阻塞 | jstack 查看线程状态 |
| 状态更新丢失 | 状态队列消费失败 / 存储写入失败 | 检查状态队列 offset 与存储日志 |
| 引擎重启后状态不一致 | 快照损坏 / 事件日志不完整 | 校验快照 checksum，回放事件日志 |
避坑提示：不要将状态管理器与调度器部署在同一 JVM 进程内。状态写入的 GC 停顿会直接阻塞调度决策，导致全局任务延迟飙升。建议状态管理器独立部署，使用单独的 JVM 参数（如 -Xmx4G -XX:+UseG1GC）。