4. 调度引擎架构：调度器、任务队列、执行器、状态管理组件

调度引擎是 OpenAPI 领域边界编排的核心执行单元。它负责将领域边界定义转化为可运行的任务实例，并确保任务在分布式环境下的可靠执行。本章深入剖析调度引擎的四大核心组件：调度器、任务队列、执行器与状态管理组件，以及它们之间的协作关系。

4.1 调度引擎整体架构

调度引擎采用生产者-消费者模型，调度器作为生产者，执行器作为消费者，任务队列作为缓冲层，状态管理组件作为全局协调者。下图展示了调度引擎的核心架构与数据流。

4.2 调度器（Scheduler）

调度器是调度引擎的决策中枢，负责根据预定义的触发策略生成任务实例。调度器不直接执行任务，而是将任务描述推入任务队列，实现调度与执行的解耦。

4.2.1 调度器核心职责

4.2.2 调度策略对比

4.3 任务队列（Task Queue）

任务队列是调度器与执行器之间的缓冲层，承担削峰填谷、异步解耦和任务持久化的职责。任务队列的选择直接影响调度引擎的吞吐量和可靠性。

4.3.1 任务队列核心能力

• 消息持久化：任务入队后写入磁盘，防止宕机丢失
• 消费确认：执行器处理完成后显式确认，未确认任务重新投递
• 延迟队列：支持任务延迟执行，用于重试策略
• 优先级队列：高优先级任务优先被消费
• 死信队列：超过重试次数的任务转入死信，人工介入处理

4.3.2 主流任务队列选型对比

4.4 执行器（Executor）

执行器是调度引擎的工作节点，负责从任务队列拉取任务，执行 OpenAPI 调用，并将结果回传给状态管理组件。执行器通常以集群方式部署，支持水平扩展。

4.4.1 执行器工作流程

1. 任务拉取：从任务队列拉取待处理任务，支持批量拉取提升效率
2. 参数解析：解析任务参数，构建 OpenAPI 请求对象
3. API 调用：执行 HTTP 请求，支持超时、重试、熔断策略
4. 结果处理：解析响应数据，提取业务结果
5. 状态上报：将执行结果、状态码、耗时等信息上报给状态管理组件
6. 消费确认：向任务队列发送 ACK，标记任务完成

4.4.2 执行器关键配置

executor:
  # 并发拉取线程数
  fetch_concurrency: 10
  # 单次批量拉取任务数
  batch_size: 20
  # 任务超时时间（秒）
  task_timeout: 30
  # 重试策略
  retry:
    max_attempts: 3
    backoff: exponential
    initial_interval: 1s
    max_interval: 30s
  # 熔断器配置
  circuit_breaker:
    failure_threshold: 5
    recovery_timeout: 60s
  # 结果上报缓冲区
  report_buffer_size: 100

4.5 状态管理组件（State Manager）

状态管理组件是调度引擎的"记忆体"，负责持久化所有任务的生命周期状态，提供状态查询、恢复和监控能力。它是调度引擎可靠性的基石。

4.5.1 任务状态模型

每个任务实例在其生命周期中经历以下状态转换：

4.5.2 状态存储设计

4.5.3 状态恢复机制

当执行器或调度器发生故障时，状态管理组件提供以下恢复能力：

• 执行中任务恢复：检测到执行器心跳超时后，将"执行中"状态的任务重新标记为"排队中"，由其他执行器重新消费
• 调度断点续传：调度器重启后，从状态管理组件读取上次调度偏移量，继续后续调度
• 幂等去重：基于任务指纹（边界 ID + 触发时间 + 参数哈希）判断任务是否已执行，避免重复
• 死信人工介入：超过最大重试次数的任务转入死信表，提供管理 API 供运维人员手动重试或跳过

4.6 组件协作时序

以下时序图展示了调度引擎四大组件在一次完整任务执行中的协作过程：

4.7 架构设计要点总结