健康度异步计算方案调研

前言

健康度的计算是耗时的，按照需求每分钟都需要计算一次所有应用的健康度，当应用多起来的时候就需要提高性能和扩展计算能力了。

提高性能可通过开线程来处理，扩展计算能力无非是集群部署，每个节点计算一部分。这里介绍说明一下App360里面的计算方案调研。

Spring Scheduler

简介

Spring Scheduler是Spring框架自带的定时任务处理方案，其包含TaskExecutor和TaskScheduler，分别为任务执行和任务调度。

优点

与Spring无缝衔接，使用方便，快速上手。

缺点

致命缺点，在集群环境下会同时运行，如果有任务只能在某一台主机上执行，无法控制，最好不要使用。

如果想把任务拆分在不同机器执行，也可以通过数据库查询分片等执行，但是一旦该节点挂了，那就再也不会执行这部分任务了。

Spring + Quartz

简介

quartz是一个非常流行的开源任务调度的框架，其中quartz集群通过故障切换和负载平衡的功能，能给调度器带来高可用性和伸缩性。

quartz也是Java事实上的定时任务标准。

优点

通过数据库，配置集群模式。可解决多台主机同时运行相同的任务，解决了Spring Schduler的致命问题。

缺点

当集群内有多台主机时，同时只有一台主机在执行任务，只有当执行任务的那台挂掉了，才会切换到另外一台。

如果有非常多的任务需要周期执行的话，没有把硬件资源有效的利用起来，说到底还是单点执行。

缺少分布式并行调度的功能。

Spring Scheduler + Redis

简介

这个其实是公司内部自己提出的一种解决方式，定时执行还是靠Spring Scheduler，但是通过Redis暂存当前每台执行的主机和任务的信息。

然后在执行完后再清理Redis暂存数据。

优点

有效的利用硬件资源，可保证集群内每台主机都同时执行不同的任务。

缺点

从设计思路到真正实现，需要走不少坑。虽然实现起来简单，但是需要考虑的问题还有很多。

比如：应用首次启动，所有主机都会同时执行相同任务。Redis节点任务信息需要自己维护，容易产生集群多台主机执行相同任务等等

XXL-JOB

简介

XXL-JOB是一个轻量级分布式任务调度框架，其设计思路采用的是中心式设计。

优点

支持通过 Web 页面对任务进行 CRUD 操作，支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，支持在线配置调度任务入参和在线查看调度结果。

多节点任务不会重复执行，其动态分片功能也是一大亮点。

方案成熟，久经生产环境考验。

缺点

使用的是Quartz基于数据库的分布式功能，需要新建很多调度数据库表，侵入性强，太过中心化。

服务器超出一定数量会给数据库造成一定的压力。

Elastic-JOB

简介

Elastic-JOB分为Elastic-Job-Lite 和 Elastic-Job-Cloud，这里我们只说Elastic-Job-Lite。

Elastic-Job-Lite是当当开源的去中心化轻量级的分布式任务调度框架，使用 jar 包的形式提供分布式任务的协调服务。

支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。

优点

重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心，不依赖数据库了。

去中心化设计保证了水平弹性扩容较好。

幂等性，保证了集群内不会重复执行已运行的作业任务项。

方案成熟，久经生产环境考验。

缺点

动态分片支持不够好，只有产生以下3种情况时，才会触发分片算法：

1、新的Job实例加入集群；
2、现有的Job实例下线（如果下线的是leader节点，那么先选举然后触发分片算法的执行）；
3、主节点选举。

由于是去中心化的设计，无法通过管理控制台，添加新的作业，也无法控制作业进程的启停。

总结

总结以上这些解决方案，推荐使用市场上已有的成熟解决方案。其中XXL-JOB和Elastic-Job比较适合。

这里再对比一下这两种相同点和不同点：

相同点

两者都是市面上比较成熟的分布式任务调度方案，拥有完整的技术文档和广大的用户基数。也都能满足我们的定时任务的基本功能需求。

不同点

XXL-JOB 设计理念为中心化，侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。

推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用。

Elastic-Job 设计理解为去中心化，关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。

但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用。

目前健康度异步计算第一版实现为公司指定Spring Scheduler + Redis方案，不过考虑到后续问题可能较多，现也已实现第二版Elastic-JOB方案。

当然除了这里已列出的调度方案，还有很多其他很好的框架。