2. 任务调度平台核心架构：调度器、执行器、任务队列、状态管理、监控告警模块的职责与交互
任务调度平台的核心架构围绕“调度-执行-反馈”闭环设计，由五个关键模块协同工作：调度器、执行器、任务队列、状态管理和监控告警。每个模块承担独立职责，并通过定义良好的接口进行交互，共同保障任务从触发到完成的全生命周期可靠性。
2.1 模块职责定义
下表梳理了各核心模块的职责边界与关键能力：
| 模块 | 核心职责 | 关键能力 |
|---|---|---|
| 调度器 | 任务触发、路由、分发与重试策略执行 | 时间轮调度、负载均衡、分片策略、失败转移 |
| 执行器 | 任务实例的实际运行、日志采集与心跳上报 | 线程池管理、资源隔离、结果回传、优雅关闭 |
| 任务队列 | 任务消息的异步缓冲、削峰填谷与顺序保障 | 消息持久化、分区顺序、消费进度管理、死信处理 |
| 状态管理 | 任务实例状态持久化、版本控制与一致性维护 | 状态机转换、分布式锁、快照恢复、幂等校验 |
| 监控告警 | 全链路指标采集、异常检测与通知触达 | 延迟/成功率/积压指标、阈值告警、链路追踪 |
2.2 模块交互流程
一次完整的任务调度生命周期包含以下关键交互步骤：
- 任务注册：用户通过 OpenAPI 提交任务定义，调度器将任务元数据写入状态管理模块，并初始化调度策略。
- 触发与入队：调度器根据 Cron 表达式或事件触发条件，生成任务实例，将任务消息投递到任务队列（Kafka Topic）。
- 分发与执行：执行器从任务队列消费消息，根据路由规则（如一致性哈希、轮询）获取任务上下文，启动线程池执行。
- 状态上报：执行器在任务运行期间持续上报心跳和阶段性状态（RUNNING/SUCCESS/FAILED）至状态管理模块。
- 结果回传：任务完成后，执行器将执行结果（含日志摘要、输出参数）写入状态管理，并触发回调通知。
- 监控采集：监控告警模块从任务队列、状态管理、执行器三个维度拉取指标，进行实时计算与告警判定。
架构要点：任务队列作为异步解耦的核心枢纽，将调度器与执行器彻底分离。调度器只负责“何时触发”，执行器只负责“如何执行”，两者通过消息队列实现生产-消费模型，避免直接 RPC 调用带来的耦合与雪崩风险。
2.3 核心架构交互图
下图展示了五个模块之间的数据流与控制流关系：
2.4 模块间交互的三大关键模式
2.4.1 异步消息驱动模式（调度器 ↔ 任务队列 ↔ 执行器）
- 生产-消费解耦：调度器作为消息生产者，将任务实例序列化为 Kafka 消息；执行器作为消费者，从指定分区拉取消息。
- 分区与顺序：相同任务 ID 的消息路由到同一分区，保证同一任务的多次触发按序消费。
- 重试与死信：消费失败的消息根据重试策略重新入队，超过最大重试次数后转入死信 Topic 供人工处理。
2.4.2 状态同步与回调模式（执行器 ↔ 状态管理 ↔ 调度器）
- 心跳保活：执行器每隔 5-10 秒向状态管理上报心跳，超时未上报则调度器判定执行器失联，触发任务迁移。
- 状态机转换：任务实例状态严格遵循 INITIALIZED → RUNNING → SUCCESS/FAILED/TIMEOUT 的有限状态机，状态管理保证转换的原子性。
- 回调通知：任务终态写入后，状态管理通过事件总线通知调度器，调度器据此更新任务调度记录并触发后续依赖任务。
2.4.3 全链路监控采集模式（监控告警 ↔ 所有模块）
- 指标来源：监控告警模块通过拉取（Prometheus 风格）或推送（Agent 上报）方式，从调度器获取调度延迟/失败率，从任务队列获取积压量/消费延迟，从执行器获取任务执行耗时/JVM 指标。
- 阈值告警：支持多级阈值配置（如任务积压 > 1000 触发 Warning，> 5000 触发 Critical），告警通过钉钉/邮件/Webhook 触达。
- 链路追踪：每个任务实例携带全局 TraceID，串联调度器入队、队列消费、执行器运行、状态回写全链路日志，便于问题定位。
设计建议：在 Kafka 集成场景下，建议将任务队列 Topic 的副本数设置为 3，min.insync.replicas 设置为 2，以平衡可用性与一致性。同时，执行器消费端应启用
enable.auto.commit=false，采用手动提交 offset 的方式，确保任务执行完成后再提交消费进度，避免消息丢失。
2.5 模块交互的时序关系
下图以一次定时任务触发为例，展示各模块在时间轴上的交互顺序：
2.6 模块交互中的关键设计考量
| 考量维度 | 设计策略 | 对应模块 |
|---|---|---|
| 数据一致性 | 任务队列使用 Kafka 事务或至少一次语义；状态管理采用乐观锁 + 版本号防止并发覆盖 | 任务队列、状态管理 |
| 高可用 | 调度器多节点无状态部署，通过分布式锁选主；执行器集群支持水平扩展 | 调度器、执行器 |
| 流量控制 | 任务队列通过分区数控制消费并发度；执行器线程池设置最大并发数，防止资源耗尽 | 任务队列、执行器 |
| 可观测性 | 全模块暴露 Prometheus 指标端点；日志结构化输出，集成 TraceID | 监控告警 |
| 安全隔离 | 任务队列 Topic 按租户/业务线隔离；执行器沙箱运行，限制文件/网络权限 | 任务队列、执行器 |
常见陷阱：调度器直接调用执行器 RPC 接口会导致强耦合，一旦执行器集群扩容或重启，调度器需感知节点变化，增加复杂度。务必通过任务队列（Kafka）进行异步解耦，调度器只关心“消息已投递”，不关心“消息何时被消费”。
2.7 模块交互与 OpenAPI 的关系
OpenAPI 作为平台对外的统一接口层，与核心模块的交互体现在以下方面：
- 任务定义管理：OpenAPI 接收用户创建/更新/删除任务的请求，写入状态管理模块，并通知调度器重新加载调度策略。
- 任务实例查询：OpenAPI 查询任务实例状态时，直接从状态管理模块读取，不经过任务队列，保证查询的低延迟。
- 手动触发：OpenAPI 的手动触发接口直接调用调度器的触发逻辑，将任务实例投递到任务队列，与定时触发走同一链路。
- 告警配置：OpenAPI 提供告警规则 CRUD 接口，配置写入监控告警模块的规则引擎。
通过清晰的模块职责划分与标准化的交互协议，任务调度平台能够支撑高吞吐、低延迟、高可用的分布式任务调度场景，并为后续的 Kafka 集成优化奠定坚实的架构基础。