本文主要是介绍ElasticJob 的产品定位与新版本设计理念，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

• 背景
• ElasticJob 是什么？
• ElasticJob 调度模型
• ElasticJob 功能列表
• ElasticJob 典型应用场景
• ElasticJob 新版本设计理念
• 未来规划
• 关于 ElasticJob 社区

导读： 调度（Scheduling）在计算机领域是个庞大概念，CPU 调度、内存调度、进程调度等都可称之为调度。它是指在特定的时机分配合理的资源去处理预先确定的任务，用于在适当的时机触发一个包含业务逻辑的应用。调度无论在单机还是分布式环境中都是很重要的课题。在单机环境，调度与底层操作系统脱离不了干系；而在分布式环境中，调度直接决定运行集群的投入和产出。调度的两个核心要素是资源治理和触发时机。

背景

ElasticJob 诞生于 2015 年，当时业界虽然有 QuartZ 等出类拔萃的定时任务框架，但缺乏分布式方面的探索。分布式调度云平台产品的缺失，使得 ElasticJob 从出现伊始便备受关注。它有效的弥补了作业在分布式领域的短板，并且提供了一站式的自动化运维管控端。

ElasticJob 在技术选型时，选择站在了巨人的肩膀上而不是重复制造轮子的理念，将定时任务事实标准的 QuartZ 与 分布式协调的利器 ZooKeeper 完美结合，快速而稳定的搭建了全新概念的分布式调度框架。

ElasticJob 是什么？

ElasticJob 是一个分布式调度解决方案，由两个相互独立的子项目 ElasticJob Lite 和 ElasticJob Cloud 组成。ElasticJob Lite 定位为轻量级无中心化解决方案，使用 jar 的形式提供分布式任务的协调服务；ElasticJob Cloud 采用自研 Mesos Framework 的解决方案，额外提供资源治理、应用分发以及进程隔离等功能。它通过弹性调度、资源管控、以及作业治理的功能，打造一个适用于互联网场景的分布式调度解决方案，并通过开放的架构设计，提供多元化的作业生态。

使用 ElasticJob 能够让开发工程师不再担心任务的线性吞吐量提升等非功能需求，使开发工程师能够更加专注于面向业务编码设计；同时，它能够解放运维工程师，使他们不必再担心任务的可用性和相关管理需求，只通过轻松的增加服务节点即可达到自动化运维的目的。

ElasticJob 调度模型

与大部分的作业平台不同，ElasticJob 的调度模型划分为支持线程级别调度的进程内调度 ElasticJob Lite，和进程级别调度的 ElasticJob Cloud。

进程内调度

ElasticJob Lite 是面向进程内的线程级调度框架。通过 ElasticJob ，作业能够透明化的与业务应用系统相结合。它能够方便的与 Spring 、Dubbo 等 Java 框架配合使用，在作业中可自由使用 Spring 注入的 Bean，如数据源连接池、Dubbo 远程服务等，更加方便的贴合业务开发。

ElasticJob Lite 与业务应用部署在一起，其生命周期与业务应用保持一致，是典型的嵌入式轻量级架构。ElasticJob Lite 非常适合于资源使用稳定、部署架构简单的普通 Java 应用，可以理解为 Java 开发框架。

ElasticJob Lite 本身是无中心化架构，无需独立的中心化调度节点，分布式下的每个任务节点均是以自调度的方式适时的调度作业。任务之间只需要一个注册中心来对分布式场景下的任务状态进行协调即可，目前支持 ZooKeeper 和 ETCD 作为注册中心。

架构图如下：

ElasticJob 的产品定位与新版本设计理念

通过图中可看出，ElasticJob Lite 的分布式作业节点通过选举获取主节点，并通过主节点进行分片。分片完毕后，主节点与从节点并无二致，均以自我调度的方式执行任务。

进程级调度

ElasticJob Cloud 拥有进程内调度和进程级别调度两种方式。由于 ElasticJob Cloud 能够对作业服务器的资源进行控制，因此其作业类型可划分为常驻任务和瞬时任务。常驻任务类似于 ElasticJob Lite，是进程内调度；瞬时任务则完全不同，它充分的利用了资源分配的削峰填谷能力，是进程级的调度，每次任务的会启动全新的进程处理。

ElasticJob Cloud 需要通过 Mesos 对资源进行控制，并且通过部署在 Mesos Master 的调度器进行任务和资源的分配。Cloud 采用中心化架构，将调度中心的高可用交由 Mesos 管理。

它的架构图如下：

ElasticJob 的产品定位与新版本设计理念

通过图中可看出，ElasticJob Cloud 除了拥有 Lite 的全部能力之外，还拥有资源分配和任务分发的能力。它将作业的开发、打包、分发、调度、治理、分片等一些列的生命周期完全托管，是真正的作业云调度系统。

相比于 ElasticJob Lite 的简单易用，ElasticJob Cloud 对 Mesos 的强依赖增加了系统部署的复杂度，因此更加适合大规模的作业系统。

ElasticJob 功能列表

ElasticJob 功能主要有弹性调度、资源分配、作业治理和可视化管控。

弹性调度

弹性调度是 ElasticJob 最重要的功能，也是这款产品名称的由来。它是一款能够让任务通过分片进行水平扩展的任务处理系统。

ElasticJob 中任务分片项的概念，使得任务可以在分布式的环境下运行，每台任务服务器只运行分配给该服务器的分片。随着服务器的增加或宕机，ElasticJob 会近乎实时的感知服务器数量的变更，从而重新为分布式的任务服务器分配更加合理的任务分片项，使得任务可以随着资源的增加而提升效率。

举例说明，如果作业分为 4 片，用两台服务器执行，则每个服务器分到 2 片，如下图所示。

ElasticJob 的产品定位与新版本设计理念

当新增加作业服务器时，ElasticJob 会通过注册中心的临时节点的变化感知到新服务器的存在，并在下次任务调度的时候重新分片，新的服务器会承载一部分作业分片，分片如下图所示。

ElasticJob 的产品定位与新版本设计理念

当作业服务器在运行中宕机时，注册中心同样会通过临时节点感知，并将在下次运行时将分片转移至仍存活的服务器，以达到作业高可用的效果。本次由于服务器宕机而未执行完的作业，则可以通过失效转移的方式继续执行。作业高可用如下图所示：

ElasticJob 的产品定位与新版本设计理念

资源分配

在导读中提到过，调度是指在适合的时间将适合的资源分配给任务，并使其生效。ElasticJob 具备资源分配的能力，它能够像二手地图分布式的操作系统一样调度任务。资源分配是借由 Mesos 实现的，由 Mesos 负责分配任务声明的所需资源（CPU 和内存），并将分配出去的资源进行隔离。ElasticJob 在获取到资源之后才会执行任务。

考虑到 Mesos 系统部署相对复杂，因此 ElasticJob 将这部分拆分至 ElasticJob cloud 部分，供高级用户使用。随着 Kubernetes 的强劲发展，ElasticJob 未来也会完成 cloud 部分与它的对接。

作业治理

作业在分布式场景下的高可用、失效转移、错过作业重新执行等行为的治理和协调。

可视化管控端

主要包括作业的增删改查管控端、执行历史记录查询、配置中心的管理等。

ElasticJob 典型应用场景

ElasticJob 着重解决与复杂任务、资源导向任务和业务应用任务这几个方面的问题。

复杂任务

数据迁移。如果将百亿的数据从一组数据库集群迁移至另一组数据库集群，单线程的作业可能需要几天到几周不等。通过 ElasticJob 的弹性分片能力，可以大幅减少海量数据迁移所需要的时间。

资源导向任务

占用大量计算资源的报表作业。如果每天凌晨需要花费数小时计算 T+1 的业务报表，没有资源的管控，则无论报表作业是否启动，都要为其分配足够的资源。ElasticJob 将作业分为常驻作业和瞬时作业，对于报表类作业，瞬时作业是非常适合的。它能否在作业启动时获取资源，在作业结束后归还资源，做到真正的削峰填谷，更加合理的利用资源。

业务应用

订单拉取作业。订单系统大多采用消息中间件或作业的方式实现订单拉取，用于将订单生成系统和后端履约系统解耦，以便于前后端流量分离。采用作业实现的订单系统，可以通过 ElasticJob 实现订单相关业务逻辑，可以方便的利用外围系统所提供的依赖注入服务，无缝的融入业务端研发。

ElasticJob 新版本设计理念

经过了一个多月的开发，ElasticJob 社区近期计划发布 3.0.0-alpha，以作为它进入 Apache 软件基金会的第一个发布版本。它的主要功能包括：

作业生态圈

灵活定制化作业是 3.x 版本的最重要设计变革。新版本基于 Apache ShardingSphere 可插拔架构的设计理念，打造了全新作业 API。意在使开发者能够更加便捷且相互隔离的方式拓展作业类型，打造 ElasticJob 作业的生态圈。

ElasticJob 提供灵活的作业 API，它将作业解耦为作业接口和执行器接口。用户可以定制化全新的作业类型，诸如脚本执行、HTTP 服务执行、大数据类作业、文件类作业等。目前 ElasticJob 内置了脚本执行作业，并且完全开放了扩展接口，开发者可以通过 SPI 的方式引入新的作业类型，并且可以便捷的回馈至社区。

多元化调度器

在保留原有的基于 cron 的时间触发调度器的基础上，增加了一次性的调度 API，为 ElasticJob 增加了时间维度之外的全新调度维度。

微内核 & 生态分离

抽象作业内核模块，将作业执行轨迹追踪等辅助功能以及作业生态等可扩展模块从内核模块完全抽离。作业执行轨迹追踪模块作为二级生态，修改了之前只支持 MySQL 作为存储介质的限制，完全开放持久化的适配。

未来规划

3.0.0 的版本作为一个快速给社区回馈的版本，并未进行颠覆性的革新，而是尝试将项目内核一点一滴的解耦。在未来的规划中，ElasticJob 将大刀阔斧的向前迈进，主要的规划如下。

作业依赖

支持基于有向无环图（DAG）的作业依赖。依赖包含基于作业整体维度的依赖，以及基于作业分片项的依赖，打造更加灵活的作业治理解决方案。

调度执行分离

将调度器和执行器完全分离。调度器可以与执行器一起部署，即为 ElasticJob lite 的无中心化轻量级版本；调度器可以与执行器分离部署，即为 ElasticJob cloud 的资源管控的一站式分布式调度系统。

更加易用的云管产品

将目前仅支持 Mesos 的 ElasticJob cloud 打造为支持 Mesos 和 Kubernetes 的作业云管平台，并提供无 Mesos 和 Kubernetes 也能够独立使用的不包含资源管控的纯作业管控平台。

可插拔生态

与 Apache ShardingSphere 一脉相承，ElasticJob 也将提供更加可插拔和模块化架构，为开发者提供基础设施。开发者可以方便的基于 ElasticJob 二次开发，添加各种定制化功能，包括但不限于作业类型（如：大数据作业、HTTP 作业等）、注册中心类型（如：Eureka 等）、执行轨迹存储介质（如其他数据库类型）等。ElasticJob 的定位如下图所示。

ElasticJob 的产品定位与新版本设计理念

关于 ElasticJob 社区

ElasticJob 社区的目标是成为和 Apache ShardingSphere 一样的 Apache 软件基金会的顶级项目，达成更广泛的应用。项目重启的这段时间，ElasticJob 持续在 GitHub 的周和月度排行榜上有名:

最近一个月，ElasticJob 社区合并了 152 个 Pull Requests，关闭了 105 个 Issues；25个提交者总共 158 次提交，完成了4w+ 行代码的改动。

这篇关于ElasticJob 的产品定位与新版本设计理念的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！