如何选型一个合适的框架-分布式任务调度框架

1.背景

定时任务是大家再开发中一个不可避免的业务,比如在一些电商系统中可能会定时给用户发送生日券,一些对账系统中可能会定时去对账。大概再很久以前每个服务可能就一台机器,再这台机器上直接搞个Timerschedule基本上就能满足我们的业务需求,但是随着时代的变迁,单台机器已经远远不能满足我们的需要,这个时候我们可能需要10台,20台甚至更多机器来运行我们的业务,接受我们的流量,这就是我们所说的横向扩展。但是这里就有个问题,这么多台机器如果还用我们的Timerschedule去做会发生什么呢?在上面的电商系统中有可能会给某个用户发很多张生日券,对公司造成很多损失,所以我们需要一些其他方法,让定时任务在多台机器上只执行一次。

这里想问下大家在没有了解过或使用过分布式任务调度框架之前,大家是如何做定时任务的呢?在Spring项目中大家肯定都知道Spring-Scheduler,只需要在Spring中的bean的对应方法上加上@Scheduler注解即可完成我们的定时任务,但是光是用这个注解还远远不能保证定时任务执行多次,我们需要一些其他手段的保证,一般来说方法可能不外乎下面几种(都是基于Spring的项目来说):

  • 一台机器,我们可以将一些不太重要的定时任务,可以使用一个专门的服务台承载,然后使用单机跑,就算挂了只要我们再可接受的时间之内将其恢复,我们的业务也不会受到影响。
  • 多台机器,加分布式锁,只要我们执行任务的时候首先获取一把分布式锁,如果获取失败那么久证明有其他服务已经再运行,如果获取成功那么证明没有服务在运行定时任务,那么就可以执行。
  • 多台机器,利用ZooKeeper对Leader机器执行定时任务,有很多业务已经使用了ZK,那么执行定时任务的时候判断自己是否是Leader,如果不是则不执行,如果是则执行业务逻辑,这样也能达到我们的目的。

目前我们公司做定时任务也是使用的上面三种方法,在业务初期使用这些方法基本也能大体满足,但是随着时间的迁移,我们遇到的问题越来越多,这里和大家分享一下:

  • 首先是单机问题,如何划分一个业务不是很重要,这一块本来就比较复杂,有可能每个人都说自己的业务都重要,其次是如果单机挂了 这个挂有可能是宕机,有可能是其他的一些情况,这个时间如何能保证我们再可接受的范围之间恢复,这些都是难点。
  • 目前我们使用定时任务的时候,如果想让它马上执行一次,这个时候可能就需要额外再写一个Rest接口或者再另外写一个单独的Job。
  • 还有个是我们需要更改定时任务执行时间,比如现在有个需求是从每12个小时执行一次变成每6小时执行一次,我们又得修改代码,提交pr,然后打包上线,只是修改一个时间又得花费我们很多时间。
  • 无法暂停我们的定时任务,当我们的定时任务可能出现一些问题,比如一些定时报警的需求,当报警突然变得很多,这个时候需要暂停一下让其停止发送报警,这个时候可能我们可以用一些分布式配置的开关去做,再逻辑中判断定时任务开关是否打开,然后来做。这样做虽然也比较简单,但是我们这样需要新添加一些与任务无关的逻辑。
  • 缺少对定时任务的监控,任务失败之后开发人员无从得知,有人说不是有Error日志吗,如果一个Error日志就一次报警那你们的服务能受得了吗,一般来说连续几次Error才会触发报警,而我们定时任务的周期性的特性是不容易触发连续的Error。

当然还有一些或多或少的小问题这里就不一一列举了,如果大家有这种经历可以自己慢慢体会发现。

2. 调研的基本原则

上面第一章讲了我们框架的原因,不论你要引入或改进什么,都需要原因,因为做任何事都有成本,我经常看到一些很小的项目就开始搞引入消息队列,或者分布式事务等等,这样做反而是本末倒置,比如可能有一些博客系统就搞个消息队列削峰减流,这样做有可能还没有同步调用来得快。

当我们有了原因之后,就可以着手做一些调研或者技术方案的设计。这里我讲一下我的调研框架一些基本原则,如果大家以后有类似的调研框架的需求都可以往这个里面来套。

  • 简单-对开发者接入简单,对使用者使用简单。
  • 丰富的文档,有很多开源的项目文档少之又少,当然还有一些开源项目只有英文文档,如果你英文不是很行,那可能需要考虑中文居多的文档。
  • 有管理界面,很方便执行操作和统计数据。
  • 支持主流框架:比如Spring,Springboot等,当然这个至少要支持你们业务中的主流框架。
  • 框架轻量级,方便根据自己的需求进行定制化。
  • 高性能,高可靠,高可用:不能让框架成为业务中的瓶颈。
  • 代码更新频率和社区使用情况:使用的公司越多证明其越受更多人的喜爱,代码更新频率越高证明出现问题就会越少,最好是由大厂开源并且维护。
  • 多语言需求:如果在你们业务中有多语言需求,比如你们公司用的开发语言很多,都需要调度框架那么你需要使用多语言支持。比如Rpc支持多语言的代表就是Thrift。
  • 能否解决当前的痛点:这个是最重要的,如果连你问题都解决不了那使用这个还有什么意义呢?

当我们有了上述的几大原则之后,我们接下来可以进入调研。

3.调研框架

3.1 TBSchedule

一般调研Java系的一些框架,可以先看看阿里是不是有开源的,毕竟最近这几年阿里在开源这一块做得是非常的好,再网上搜索到阿里在12年开源了一个调度框架叫TBSchedule,现在再去搜索代码,发现已经人走茶凉,代码都被清理干净了。当然还有一个个人项目将其Fork出来再不断维护,但是使用者实在是少这里就不说明了。 github地址:https://github.com/taobao/TBSchedule

3.2 elastic-job

elastic-Job 是当当开源的一个分布式调度解决方案,由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。定位为轻量级无中心化解决方案,使用 jar 包的形式提供分布式任务的协调服务。支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。

这个框架大概在2年前很火,当时使用的公司很多,想必很多人也听过了,但是很可惜现在已经不在维护了,代码已经有2年没有更新了,这里违反了更新频率的原则,如果出现问题可能都没什么人帮助你,所以我们并不是很推荐使用。

github地址:https://github.com/elasticjob/elastic-job-lite

3.3 一些比较小众的

在网上有一些比较小众的github star很少,更新频率也很少: Uncode-Schedule,LTS,openCron等等,这些也不符合我们的原则,都不予以考虑

3.4 XXL-JOB

由于分布式定时任务现在还没有基金会比如CNCF,Apache等,抉择起来可能不是那么难。不像消息队列再Apache里面就有好几个:Kafka、rocketmq、plusar等等,每一个的社区都很庞大,可能选择是比较困难的。那么我们基本就还剩下两个选择,一个是自研,这种任务调度框架,再研发的困难程度上是远远比不上消息队列的研发,所以其实很多公司都选择了自研,比如:美团的Crane这些。但是对于一些消息队列这些复杂的中间件可能会选择二次开发,比如美团的mafka就是基于kafka二次开发,滴滴的DDMQ也是基于Rocketmq。而我们目前如果选择自研再资源上来说是明显不够的,这里我们还是使用的是二次开发框架的策略。

当然这里还剩下一个XXL-Job:www.xuxueli.com/xxl-job 的选择,其基本符合我们的原则,目前代码也在持续更新,issue作者也在积极的回复,使用的公司也有200多家,其中包括之前的点评,同时其他的原则也很符合。一般来说当你决定选择某个框架的时候需要详细的列举一下优点,好让其他人得以信服。

xxl-job有下面一些特点:

  • 简单:支持通过Web页面对任务进行CRUD操作,操作简单,一分钟上手;
  • 动态:支持动态修改任务状态、启动/停止任务,以及终止运行中任务,即时生效;
  • 调度中心HA(中心式):调度采用中心式设计,“调度中心”自研调度组件并支持集群部署,可保证调度中心HA;
  • 执行器HA(分布式):任务分布式执行,任务"执行器"支持集群部署,可保证任务执行HA;
  • 注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时,也支持手动录入执行器地址;
  • 弹性扩容缩容:一旦有新执行器机器上线或者下线,下次调度时将会重新分配任务;
  • 路由策略:执行器集群部署时提供丰富的路由策略,包括:第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等;
  • 故障转移:任务路由策略选择"故障转移"情况下,如果执行器集群中某一台机器故障,将会自动Failover切换到一台正常的执行器发送调度请求。
  • 阻塞处理策略:调度过于密集执行器来不及处理时的处理策略,策略包括:单机串行(默认)、丢弃后续调度、覆盖之前调度;
  • 事件触发:除了"Cron方式"和"任务依赖方式"触发任务执行之外,支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务,可根据业务事件灵活触发。
  • 任务进度监控:支持实时监控任务进度;
  • Rolling实时日志:支持在线查看调度结果,并且支持以Rolling方式实时查看执行器输出的完整的执行日志

基本上上面的一些特点都是我们业务中所需要的,所以这里最后选择了XXL-JOB

4.总结

俗话说:授人以鱼不如授人以渔,之前的文章每次都是介绍某某框架,这一次我偏向于介绍我是如何选择的这款框架,让大家再以后调研的过程中也可以按照这个思路,如果说你也有好的并且不同的调研思路,欢迎留言或者加群交流。当然一般调研完毕之后,作为一个调研人如果你不弄清楚这个框架的源码和实现原理,那么就是一个不合格的调研人,所以下一篇文章我会详细的介绍XXL-Job的实现原理。