无论是互联网应用或则企业级应用,都参杂着大量的批处理任务。我们往往须要一些任务调度系统来帮助解决问题。随着微服务化构架的逐渐演变查看linux是什么系统,单体构架逐步演化为分布式、微服务构架。在此背景下,好多原本的任务调度平台早已不能满足业务系统的需求,于是出现了一些基于分布式的任务调度平台。
1.1分布式任务调度的演化
在实际业务开发过程中,好多时侯我们无可防止地须要使用一些定时任务来解决问题。一般我们会有多种解决方案:使用Crontab或SpringCron(其实这些情况可能机器极少并且任务简单又不是好多的情况下)。但是,当应用复杂度下降、定时任务数目增多且任务之间形成依赖关系时,Crontab进行定时任务的管理配置都会特别混乱,严重影响工作效率。这时都会形成一系列问题:
随着互联网的发展,分布式服务构架势越来越流行。相应的也须要一个分布式任务调度系统来管理分布式构架中的定时任务。
1.2分布式任务调度构架
当垂直应用越来越多,应用之间交互也会越来越复杂,一般我们采用分布式或则微服务构架,将核心业务抽取下来,产生单独的服务。一个独立的微服务群体日渐产生稳定的服务中心,致使业务应用能更快地响应多变的市场需求。
此时,用于提升业务复用及整合的分布式服务框架成为关键。同时,因为服务独立,通常能做到定时任务独立的情况,任务的修改对于整体系统的影响小之又小。一般我们会采用任务与调度分离的方法(如上图所示),任务的执行逻辑无需关注调度与编排,同时可以保证执行器和调度的高可用,便于开发和维护。
1.3分布式任务调度优势
在分布式服务构架的基础上,因为独立业务的数目可能好多,此时若果定时任务单独在该服务中实现,很可能会出现无法管理的情况,且避开不了因为定时任务的修改而造成的业务重启。因而,一个独立的分布式任务调度系统是很必要的,可以拿来全局统筹管理所有的定时任务。同时,将任务的配置单独抽离下来,作为该分布式任务调度系统的功能,能够做到定时任务的修改不影响任何业务,也不影响整个系统:
二、分布式任务调度技术选型2.1分布式任务调度考虑诱因
2.2SIA-TASK与其它分布式任务调度技术比较
SIA是宜信公司基础开发平台SimpleisAwesome的简称,SIA-TASK(微服务任务调度平台)是其中的一项重要产品,SIA-TASK契合当前微服务构架模式,具有跨平台、可编排、高可用、无侵入、一致性、异步并行、动态扩充、实时监控等特性。
开源地址:
我们先对比市场上主流的开源分布式任务调度框架,剖析其优劣点,之后再介绍我们的技术选型。
下边我们简单对比下SIA-TASK与那些任务调度框架:
任务编排任务分片跨平台高可用故障转移实时监控
SIA-TASK
√
√
√
√
√
√
Quartz
×
×
.NET
√
×
API监控
TBSchedule
×
√
×
√
√
√
Elastic-Job
×
√
×
√
√
√
Saturn
×
√
√
√
√
√
Antares
√
√
×
√
√
√
Uncode-Schedule
×
×
×
√
√
√
XXL-JOB
子任务依赖
√
×
√
√
√
可以发觉,这种调度框架基本上都支持高可用、故障转移与实时监控等功能,并且对于任务编排、任务分片与跨平台等功能的支持各有优缺。SIA-TASK将全面支持这种功能。
三、SIA-TASK介绍3.1SIA-TASK技术选型
3.2SIA-TASK设计思想
SIA-TASK借鉴微服务设计思想,获取分布在每位执行器节点上的任务(Task)元数据,进行汇报,上传注册中心。借助在线可编辑方法支持任务在线编排、动态更改任务时钟;使用Http合同作为交互传输合同。数据交互格式统一使用Json。用户通过编排器(下文会做介绍)进行操作,触发风波,调度器接收风波,由调度中心进行时钟解析,执行任务流程,进行任务通知。
3.3SIA-TASK基本概念
SIA-TASK采用任务和调度分离的方法,业务的执行任务逻辑和调度逻辑完全分离。系统组成共涉及以下几个核心概念:
3.4SIA-TASK系统构架
SIA-TASK可以分为三大模块(调度中心、编排中心和执行器)、两大组件(持久化储存和注册中心)。这三大模块和两大组件的作用如下:
SIA-TASK使用SpringBoot体系作为构架选型,基于Quartz及Zookeeper进行二次开发,支持相应的特×××,SIA-TASK的逻辑构架图如右图所示:
3.5SIA-TASK模块说明3.5.1任务调度中心
任务调度中心负责任务调度,管理调度信息,根据调度配置发出调度恳求,自身不承当业务代码。调度系统与任务前馈,增强了系统可用性和稳定性,同时调度系统性能不再受限于任务模块;支持可视化、简单且动态地管理调度信息,包括任务新建,更新开源调度系统,删掉和任务报案等,所有上述操作就会实时生效,同时支持监控调度结果以及执行日志,支持执行器故障恢复。
3.5.2任务编排中心
任务编排中心是分布式调度中心支持在线任务模型编排的组件;依托于UI可进行web端任务编排。
我们可以通过上述基础模型来编排一些复杂的调度模型,比如:
SIA-TASK的UI编排界面:
编排结束后查看task的编排信息如右图所示:
同时,编排中心还提供首页统计数据查看、调度监控、Job管理、Task管理以及日志管理功能。
3.5.3任务执行器
负责接收调度恳求并执行任务逻辑。任务模块专注于任务的执行等操作,开发和维护愈发简单和高效;
执行器支持两种类型:
(1)假如使用sia-task-hunter,支持SpringBoot项目和Spring项目,引入sia-task-hunter,任务(Task)抓取顾客端。合规的HTTP插口(称之为Task)任务会手动被抓取并上传注册中心;
(2)若果不使用sia-task-hunter,只需提供任务可调用的HTTP插口,此时须要业务自动录入,且自行控制该任务的并发调用控制。
3.5.4任务注册中心(Zookeeper)
分布式框架采用Zookeeper作为注册中心。
(1)任务注册
调度中心和执行集群都以Zookeeper作为注册中心,所有数据以节点及节点内容的方式注册,通过定时汇报主机状态保持存活在Zookeeper上。
(2)元数据储存
注册中心不仅仅提供注册服务,而且储存每位执行器的信息(包括执行器实例信息,执行器上传的Task元数据,以及任务运行时的一些临时状态数据)。
(3)风波发布
基于Zookeeper风波推送机制,进行任务的发布,通过平衡算法保证调度器任务占据的分布均衡。
(4)负载均衡
保证调度器获取执行Job的个数均衡开源调度系统,防止单一节点压力。
3.5.5持久化储存(DB)
这儿采用MySQL作为数据持久化解决方案。
不仅Task动态元数据保存在注册中心之外,其他相关的元数据都存入MySQL,包括但不限于:自动录入的Task、配置的Job信息、编排的Task依赖信息、调度日志、业务人员操作日志、Task执行日志等。
3.6SIA-TASK关键运行流程3.6.1任务发布流程
(1)用户可以通过UI进行Job创建。可以选择Job类型,设置预警邮箱,设置Job描述。之后为创建的Job进行任务Task编排。
(2)Job创建完毕而且设置Task编排关系后可进行任务发布,通过UI对相应的Job进行操作(激活,执行一次,停止以及删掉操作)。
(3)用户的Task任务可以是通过抓取器抓取的,亦可以使用UI自动创建。
3.6.2执行流程
(1)Job创建完成以后,可以选择激活触发定时任务;
(2)Job抵达预订时间后,调度中心触发Job,之后根据预定的Task编排逻辑通过http通知Task执行器进行执行,并异步窃听任务执行结果;
(3)若执行结果成功,则判定是否存在前置Task,若存在,则继续下一次调度,若不存在,则说明该Job执行完毕,结束本次调用;若执行结果失败,则触发故障恢复策略:立刻停止、忽略本次失败、多次尝试、转到其它执行器执行。
3.6.3状态流转
Job在整个生命周期显存在四种状态,分别是:已停止(NULL)、准备中(READY)、开始运行(RUNNING)、异常停止(STOP),状态流转及流转条件如右图所示。
3.7SIA-TASK模块设计
SIA-TASK的化学网路拓扑图如下所示:
SIA-TASK的模块间交互设计思路:
(1)通过编排中心创建Task任务或通过Hunter手动抓取linux命令tar,并将Task信息异步保存到DB;创建Job并激活,在zookeeper中创建JobKey。
(2)调度中心会窃听zookeeper中JobKey创建风波,之后占领创建的Job,占领成功后加入quartz定时任务,当时间抵达即触发Job运行。调度中心异步调用执行器服务执行Job中的Task(可能存在多个Task,遵守Task失败策略),并将结果返回到调度中心。
(3)将Job执行状态随时在zookeeper上修改,通过编排中心的查询插口可以进行查询。
(4)Job执行结束后,等待下一次执行。
3.7.1任务编排中心设计
编排中心可以与DB和zookeeper进行数据交互,其主要功能可分为三方面: