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

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

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的实现原理。

（编辑：ASP站长网）