没投过票？千万别说你来过 OSC
ElasticJob 创始人张亮 11 月 4 日发布 ElasticJob 后续设计规划。
ElasticJob 是一个分布式调度解决方案。分布式环境中，调度直接决定运行集群的投入和产出。调度的两个核心要素是资源治理和触发时机。
ElasticJob 由两个相互独立的子项目 ElasticJob Lite 和 ElasticJob Cloud 组成。ElasticJob Lite 定位为轻量级无中心化解决方案，使用 jar 的形式提供分布式任务的协调服务；ElasticJob Cloud 采用自研 Mesos Framework 的解决方案，额外提供资源治理、应用分发以及进程隔离等功能。以下为刚发布的规划信息。
产品定位
ElasticJob 目前是基于定时任务的分片调度中间件，在 ElasticJob-Cloud 中增加了资源治理的能力。未来 ElasticJob 希望将功能划分为独立的三个部分：任务触发、资源管理、任务治理。
任务触发是必选模块，其他两个模块是可选的。只有任务触发，相当于降级为 QuartZ。
任务触发 + 任务治理可以理解为 ElasticJob 的现状。在任务触发的同时，增加分布式治理和任务分片的能力，未来的基于有向无环图的任务编排也属于任务治理模块。
任务触发 + 资源治理可以理解为类似于操作系统的任务调度机制。在任务执行时增加资源的管控，在资源不足的情况下将任务排队，资源管控可以对接 Kubernetes 和 Apache Mesos。目前的 ElasticJob-Cloud 则是任务触发 + Mesos 资源治理实现方式。
任务触发 + 任务治理 + 资源治理是 ElasticJob 未来的全部能力，而 ElasticJob-Lite 和 ElasticJob-Cloud 则仅仅是部署形态不同。
架构设计
ElasticJob 希望采用可插拔架构设计，将功能模块通过 SPI 动态织入现有架构体系。针对于当前设计的三大功能模块，其可插拔设计分别是：
任务触发：目前是基于 CRON 表达式和一次性调度两种触发形式。希望调整为调度 SPI + 调度实现（CRON，One-Off，其他...）。
资源治理：目前没有独立的资源治理抽象层。希望未来在增加资源治理 SPI 的同时，增加基于Apache Mesos、Kubernetes 和 NoDep 的资源治理实现模块。
任务治理：目前只有任务分片和高可用治理两部分。希望未来提供任务治理 SPI，并将分片和高可用作为其实现模块，并在此基础上增加 DAG 治理能力。任务治理的各个模块相互隔离且可叠加。
ElasticJob-Lite 和 ElasticJob-Cloud 调整
ElasticJob-Lite 和 ElasticJob-Cloud 调整为仅仅是部署形态不同。
ElasticJob-Lite 采用无中心化的 jar 部署形态，提供 spring 等框架的接入层，适用于轻量级应用。
ElasticJob-Cloud 采用中心化的 server 部署形态，适用于集中化的作业云管平台。
模块规划
任务触发：
Trigger API
Trigger SPI
Trigger Kernel
CRON Trigger
One-Off Trigger
Customized Trigger
资源治理：
Resource Management API
Resource Management SPI
Resource Management Kernel
NoDep Resource Management
Mesos Resource Management
Kubernetes Resource Management
任务治理：
Job Governance API
Job Governance SPI
Job Governance Kernel
Sharding Job
HA Job
DAG Job
产品形态：
ElasticJob-Lite 架构调整
ElasticJob-Cloud 架构调整
ElasticJob-Cloud 剥离 Mesos
