关于数据库:ElasticJob-300打造面向互联网生态和海量任务的分布式调度解决方案

0次阅读

共计 3954 个字符，预计需要花费 10 分钟才能阅读完成。

ElasticJob 于 2020 年 5 月 28 日重启并成为 Apache ShardingSphere 子项目。新版本借鉴了 ShardingSphere 可拔插架构的设计理念，对内核进行了大量解耦和重构，打造了全新的作业 API，晋升我的项目的易用性。自重启以来，社区活跃度大幅减少，目前我的项目累计播种超过 7,000 Star，奉献了超过 2,000 次 commits， 面向互联网生态和海量数据的散布式调度平台将进一步被大规模应用，解决用户的作业调度难以程度扩大、可用性无限的问题。

本文将给各位介绍 ElasticJob 3.0.0 到底做出了怎么的扭转。

吴伟杰

SphereEx 中间件研发工程师，Apache ShardingSphere committer，ElasticJob 3.0.0 版本 Release Manager。目前专一于 Apache ShardingSphere 及其子项目 ElasticJob 的研发。

ElasticJob 是面向互联网生态和海量工作的散布式调度解决方案，由两个互相独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。它通过弹性调度、资源管控、以及作业治理的性能，打造一个实用于互联网场景的散布式调度解决方案，并通过凋谢的架构设计，提供多元化的作业生态。它的各个产品应用对立的作业 API，开发者仅需一次开发，即可随便部署。

新版本的 ElasticJob，打造了全新的作业 API。 开发者不再局限于框架预置的作业类型，可能借助 SPI 扩大作业执行器类型，打造更贴合理论场景的作业逻辑。除此之外，得益于新的模块化架构，开发者能够不便地向社区回馈独立、通用的作业类型。

以 ElasticJob 2.1.5 版本为例，作业执行器的类型曾经固定在代码逻辑中，传入的参数如果不是内置的作业执行器类型，则间接抛出异样，开发者无奈间接扩大。

public static AbstractElasticJobExecutor getJobExecutor(final ElasticJob elasticJob, final JobFacade jobFacade) {if (null == elasticJob) {return new ScriptJobExecutor(jobFacade);
    }
    if (elasticJob instanceof SimpleJob) {return new SimpleJobExecutor((SimpleJob) elasticJob, jobFacade);
    }
    if (elasticJob instanceof DataflowJob) {return new DataflowJobExecutor((DataflowJob) elasticJob, jobFacade);
    }
    throw new JobConfigurationException("Cannot support job type'%s'", elasticJob.getClass().getCanonicalName()

在 ElasticJob 3.0.0，作业执行器通过从新设计，分为 Classed 与 Typed 两类。须要编写作业逻辑的 Simple、Dataflow 作业属于 Classed 类型作业，通过配置执行的 Script、HTTP 作业属于 Typed 类型作业。
基于这种设计，开发者只须要三个步骤就能够自行扩大更贴合业务场景的 Class 类型作业执行器。举个例子：

先扩大 ElasticJob 顶层接口定义作业逻辑的执行接口：

public interface BackupJob extends ElasticJob {void backup(Collection<AvailableData> availableData) throws IOException;
}

而后实现一个 ClassedJobItemExecutor<BackupJob> 命名为 MyBackupJobExecutor：

public class MyBackupJobExecutor implements ClassedJobItemExecutor<BackupJob> {

    @SneakyThrows
    @Override
    public void process(BackupJob elasticJob, JobConfiguration jobConfig, JobFacade jobFacade, ShardingContext shardingContext) {Collection<AvailableData> availableData = getAvaiableData(shardingContext);
        elasticJob.backup(availableData);
    }

    @Override
    public Class<BackupJob> getElasticJobClass() {return BackupJob.class;}
}

把本人实现的 MyBackupJobExecutor 通过 Java SPI 的形式申明实现类。

如果是扩大 Type 类型的作业执行器，只须要进行前面两步。实现了以上步骤，就能够在作业中应用本人定制的作业执行器了。

二、作业调度形式多元化

全新引入的“一次性调度”让 ElasticJob Lite 的作业调度不再局限于“定时”。 本来基于 Cron 表达式调度的形式重构为 ScheduleJobBootstrap，OneOffJobBootstrap 是 ElasticJob 3.0.0 新增的调度形式。

应用 ElasticJob 2.x 时，如果要实现一个可能自在触发的作业，须要通过以下步骤：

创立一个短时间内不会触发的作业，例如设置 Cron 表达式为 59 59 23 31 12 ? 2099；
在我的项目中引入 elasticjob-lite-lifecycle 模块依赖；
创立一个 JobOperationAPI 的实例；
调用 JobOperationAPI 的 trigger 办法。

在 ElasticJob 3.0.0 能够这么操作：

OneOffJobBootstrap job = new OneOffJobBootstrap(regCenter, elasticjob, jobConfig);
job.execute();

无论是操作复杂度还是代码优雅性，新的 API 都更胜一筹。新的调度形式将为 ElasticJob 的利用减少更多的可能性。

三、微内核 & 生态拆散

作业谬误处理器、执行轨迹追踪等可扩大模块从内核模块齐全抽离， 全新的 API 联合 SPI 机制，让开发者能够灵便扩大各个模块的性能，促成 ElasticJob 生态对接。

在 3.0.0 版本中，作业谬误处理器预置了企业微信、钉钉、邮件 3 种告诉渠道。

执行轨迹追踪模块数据源不再局限于 MySQL，现已反对 PostgreSQL、Oracle、H2、DB2、SQLServer 以及其余遵循 SQL92 规范的数据库。

值得一提的是，以上提到的 ElasticJob 3.0.0 生态裁减的内容，均是由社区的同学们奉献的。

四、ElasticJob Lite 提供官网的 Spring Boot Starter

Spring 利用引入 ElasticJob Lite 时能够不再编写繁琐的 XML 文件了。新版本提供了全新的 Spring Boot Starter，在我的项目中应用 ElasticJob 定时调度只需两个步骤。

在作业逻辑的类上加上 @Component 注解：

@Component
public class DataRefreshJob implements SimpleJob {
    @Override
    public void execute(final ShardingContext shardingContext) {// Do something here}
}

在 Spring 配置文件中配置作业：

elasticjob:
  regCenter:
    serverLists: zookeeper0:2181,zookeeper1:2181,zookeeper2:2181
    namespace: schedule-jobs
  jobs:
    dataRefreshJob:
      elasticJobClass: org.path.to.DataRefreshJob
      cron: 0 0 0/6 * * ?
      shardingTotalCount: 3
      shardingItemParameters: 0=Beijing,1=Shanghai,2=Guangzhou

实现以上配置后，ElasticJob 的作业就会随着 Spring Boot 启动了。

后续版本还将实现基于注解配置作业，提供更多样化的配置形式，更进一步简化配置。

五、可观测性

通过 APM，辅以 ElasticJob 的作业执行轨迹追踪模块， 以 ElasticJob 调度为终点的作业全链路能够和盘托出。 后续打算基于 OpenTracing 等形式开发托管在 ElasticJob 仓库的 Agent。

例如，SkyWalking 实现了反对 ElasticJob 3.x 版本的主动探针。

六、对多网卡环境的反对更欠缺

ElasticJob 在运行过程中会获取以后过程所在环境的 IP 地址，在一些多网卡的环境下，主动获取 IP 地址的逻辑可能会获取到非用户所预期的地址，对管控界面的展现或作业管理对带来一些不便之处。ElasticJob 3.0.0 将容许用户指定优先应用的网卡，使节点信息更合乎用户的预期。在后续版本打算反对正则表达式匹配等形式进行网卡的抉择。

自 ShardingSphere ElasticJob 重启以来，有至多 62 位 Contributors（局部 Contributors 邮箱设置不正确没有被统计到）的 653 个 PR 被合并，感激各位 Contributors！