3. 任务调度平台架构概览：调度器、执行器、任务队列、存储层的典型架构，以及API网关在其中的位置
一个生产级的任务调度平台，其架构通常由四个核心组件构成：调度器、执行器、任务队列和存储层。API网关作为统一的流量入口，位于客户端与调度集群之间，承担着协议转换、认证鉴权、流量控制与契约校验的职责。理解这五者的协作关系，是后续进行OpenAPI契约设计与性能调优的基础。
3.1 核心组件与职责
| 组件 | 核心职责 | 典型实现 | 性能关注点 |
|---|---|---|---|
| 调度器 | 解析任务定义、计算触发时间、分发任务到执行器 | Quartz、Elastic-Job、XXL-JOB | 调度吞吐量、时间轮精度、Leader选举延迟 |
| 执行器 | 接收调度指令、运行任务逻辑、上报执行状态 | Java/Go Worker、容器化Pod | 资源隔离、线程池饱和、日志回传带宽 |
| 任务队列 | 削峰填谷、异步解耦、保证任务不丢失 | Redis List、RabbitMQ、Kafka | 消息堆积、消费延迟、ACK机制 |
| 存储层 | 持久化任务定义、调度记录、执行日志 | MySQL、PostgreSQL、TiDB | 分表策略、慢查询、连接池水位 |
| API网关 | 统一入口、协议适配、限流熔断、契约校验 | Kong、APISIX、Spring Cloud Gateway | 路由延迟、请求体校验开销、连接数 |
架构原则：调度器不直接持有任务数据，而是通过任务队列与执行器解耦；存储层只做持久化，不参与实时调度路径。这种分层设计使得每一层都可以独立扩缩容。
3.2 典型架构交互流程
下图展示了任务从提交到执行完成的完整数据流，以及API网关在其中的边界位置。
3.3 API网关在架构中的位置与作用
API网关并非调度平台的功能核心，但它是契约治理与流量防护的第一道关卡。在微服务架构下，网关承担以下关键职责：
- 协议转换：将外部HTTP/HTTPS请求转换为内部RPC或消息协议，屏蔽后端异构性。
- 契约校验：基于OpenAPI规范对请求参数、请求体进行格式校验，拒绝非法请求，避免脏数据进入调度器。
- 流量控制：针对不同客户端或API Key实施令牌桶限流，防止突发流量打垮调度集群。
- 认证鉴权：统一校验JWT Token或API Key，将用户身份注入请求头，供下游服务使用。
- 请求审计：记录每一次API调用的来源、时间、参数与响应状态，为后续性能分析提供数据基础。
性能调优视角：API网关的请求体校验（如JSON Schema校验）是CPU密集型操作。在OpenAPI契约设计时，应避免在网关层做深层次嵌套校验，将复杂业务校验下沉到调度器内部，以降低网关延迟。
3.4 分层架构的扩展性设计
为了支撑海量任务调度，各层需要具备独立的水平扩展能力。下表总结了各层的扩展策略与约束：
| 组件 | 水平扩展方式 | 关键约束 | 推荐实践 |
|---|---|---|---|
| API网关 | 无状态多实例 + 负载均衡 | 路由规则一致性 | 使用一致性哈希路由，避免缓存失效 |
| 调度器 | 分片 + Leader选举 | 任务分片不能重复 | 基于任务ID哈希分片，使用分布式锁协调 |
| 任务队列 | 分区 + 消费者组 | 分区数决定最大并行度 | Kafka分区数 = 执行器节点数 × 2 |
| 执行器 | 无状态Worker + 动态注册 | 资源配额与任务亲和性 | 使用K8s HPA自动扩缩容 |
| 存储层 | 读写分离 + 分库分表 | 跨分片事务限制 | 按任务ID取模分表，避免分布式事务 |
常见陷阱：调度器与存储层之间如果采用强一致性读写，会严重限制调度吞吐量。建议调度器只从存储层读取任务定义，而将任务状态变更通过异步消息写入，避免在调度路径上出现数据库锁竞争。
3.5 架构演进：从单体到分布式
下图展示了调度平台从单体架构向分布式架构的演进路径，帮助理解各组件是如何逐步分离的。
3.6 本章小结
- 任务调度平台由调度器、执行器、任务队列、存储层四大核心组件构成，API网关作为统一入口位于最前端。
- 调度器负责任务触发与分发，执行器负责任务运行，任务队列负责削峰填谷，存储层负责持久化。
- API网关承担协议转换、契约校验、限流熔断、认证鉴权等非功能性职责，是性能调优的第一道关卡。
- 架构演进遵循从单体到分层再到分布式的路径，每一层的扩展策略与约束不同，需要针对性设计。
- 理解各组件之间的数据流与依赖关系，是后续进行OpenAPI契约设计与性能优化的前提。