分布式任务调度平台是目前不少公司研究的方向,今天小数就给你们分享一下数人云分布式任务调度平台(Octopus)的一些思考与实践。git
今天主要分享下批量处理平台的技术心得,批量处理从片面的角度讲相似于Linux系统中的Cron Table,从大方向去看属于批量业务的调度平台,这次依托数人云3年来对容器技术的积累和对批量处理开源项目的整合过程,在这里和你们探讨一下实践分布式任务调度的心路历程。github
从理论上来讲,作分布式系统并不是企图加快单一任务处理速度,而是经过并行的方式合理利用资源,经过加大对任务的同时批量处理业务容量来加快业务的运营速度,举个典型的例子:当前视频直播中须要的视频文件解码,就是一种典型的批量处理业务。数据库
原本,批量处理业务和容器技术的关系并不紧密,咱们经过跨领域的交叉设计,但愿经过容器技术的封装能力帮助批处理系统快速创建更多的高密度批量处理运行时环境,更高效地利用资源。编程
定时任务无处不在,在多任务处理时如何进行秒级调度?与容器如何碰撞?这是我比较关注的主题,我的的角度来看,批量处理系统的痛点有四个维度是用户比较关注的:多线程
以金融行业为例,在金融行业高速发展的今天,业务规模快速扩展,随着业务的发展,需处理的数据量愈来愈大,后台批量处理业务占60%以上,如数据接口导入、数据预处理、估值表生成、凭证生成、对帐、日终批处理、报表生成等。架构
从用户关注的4个维度切入问题主要表如今:并发
弹性扩缩:批量处理做业只能运行在一个服务节点上,没法适应业务发展,这是目前业务系统的最大性能瓶颈点。负载均衡
故障处理:看成业发生故障时,未实现故障自动转移,严重时影响业务进展。框架
性能指标:运维
运维体系:不便于定位做业运行时问题,不便于了解做业运行进展、负载状况、也缺乏做业运行时的性能指标,不便于对做业进行调优等。
有了这些分析,在设计竖线数人云分布式任务调度平台过程当中,采用做业调度与做业执行分离的架构来简化业务系统批量处理的开发和运维工做;采用中间件和平台化的思路提高其应用的范围及价值;采用Java系统做业的调度,执行与管控;最后产生的效果是实现了以分布式调度为理念而设计的——多服务节点协同并行处理能力及运行环境的适用能力。
在弹性伸缩方面,数人云采用了基于容器平台目的是快速构建多节点的任务执行节点,容器的好处是封装了一整套完整的任务执行环境,而且能够快速扩容服务节点数量,这个批处理设计模型如何本身实现会须要大量的测试和业务打磨,因此在技术选型上,选用了Mesos做为企业级环境的底座,毕竟Apple、MS、Netflix、Uber等大厂都在基于此技术上构建了本身的业务平台。
尤为国内开源项目当当的Elastic-Job批量处理平台(https://github.com/dangdangdo...)受到不少厂家的采用,为数人云提供了一手的学习实践经验。
数人云在此之上又进行了一些优化,从设计理念中,更多考虑了业务实际场景中的一种情况:即每次任务处理完毕后,是重置当前进程环境仍是退出,虽然容器的额快速启停确实能够解决这个小问题,但仍然不够快。毕竟一个任务的环境初始化是须要消耗时间的,即便容器启动也有那么几十毫秒的损耗。另外,咱们对Mesos集群的使用,在于提供能够FailOver的高容错环境,并无直接让Mesos来调度批量处理任务,实际上,做业节点注册到ZK后,任务的分发和结果收集都是在JVM里面解决,和Mesos集群自己没有关系,减小了对集群系统的直接依赖,后面,咱们还会对Kuberentes集群作支持。
在故障处理方面,重要的并非让任务永远不出错,在建立任务时,能提供当即执行一次的操做,让执行结果能即刻体现出来,这样给任务指定的时间去跑才不会出错,在建立任务的细节上,好比把跑批时间参入如:0/5 ? 预测出固定的时间,让用户看到直接的时间会更好。
对于过后的历史结果留存也须要作到详细完整,保证故障拍错,这块使用统计面板来监控便可。
以及做业预警面板也是须要的。
在性能指标方面,大量的工做主要是定义好性能指标并大量压测并调优系统,好比数人云的产品定义:
调度频率:定时做业最快支持5S的时间间隔,对比:公有云如阿里ScheduleX,都是分钟级间隔。
支持做业容量:最多支持管理100个Zookeeper集群,做业总量支持到500K+。
消息做业并发量:支持单节点100K TPS的并发。
经过这个目标,根据本地搭建的做业系统环境就能够压测了,压测数据经过Grafana展示出来,测试样例以下:
在运维体系中,能不能经过一个管理平台就囊括全部运维须要管理的事情,将其都考虑进去,好比组织关系的体现,暂停时间的管理,配置数据的备份和查询,ZK元数据的处处备份工做,调用链的跟踪设计实现,各类监控面板的实现,这个难度不大,但须要考虑的细节很是多,咱们也是在参考和落地实践中摸索这些问题如何解决。
最后,分布式任务调度平台在企业架架构体系里面必不可少少的组件,国内企业在通过这几年云计算的高速发展,开始意识到数字化转型过程当中必需要经历架构方面的变革,传统的批处理系统已经不能适应业务发现的须要,不妨参考业内开源领域的最佳实践构建本身的分布式调度平台。
Q:是否开源?
A: 数人云任务调度基于开源基础构建扩展了企业级功能。目前暂不开源,后续是否开源视社区反馈决定。
Q:无中心化设计(由任务执行者获取执行计划,并本身触发执行)和集中式调度设计(由一个调度中心统一经过远程调用的方式触发执行者)有什么考虑,更偏向于哪个?
A:数人云任务调度包括控制台都在内都基于无中心化设计,中心控制是ZooKeeper集群。此种设计从分布式角度考虑,避免单点故障。
Q:可否详细介绍下并行执行、分片、日志,终端处理的设计实现思路?
A:
l 并行基于分片粒度执行,目前支持几种粒度:多机器节点执行、同个节点多个进程执行、同个进程多个线程执行。进程粒度的并行执行基于ZooKeeper进行分布式协调处理。多线程基于Java Executors作线程池调度处理。
l 日志支持写入ZK,同时支持对接LogStash将日志放入ELK。因为任务执行控制都在平台侧,因此平台能够获取拦截日志流,并将日志进行查处记录。Java和消息做业是拦截LogBack,Shell做业基于Apache Commons Exec的LogOutputStream进行进程输出流的拦截。
Q:任务积压如何考虑?如何标记任务执行中或执行完成,具体如何实现?
A:
l 任务支持超时告警和Kill的配置控制。任务积压时能够对接告警系统,Dashboard也支持显示。
l 当任务开始执行和结束时,会由平台侧将状态写入ZK。
Q:选择平台独立调度系统主要基于哪些考虑?支持K8S后会考虑自带的Scheduler吗?另“任务结果收集”是如何实现的?
A:任务调度能够当即为容器Scheduler上的另一层独立调度,然后经过Kubernetes/Marathon等API启动容器,任务结果收集能够考虑ELK方式或对接APM系统。
Q:分布式任务系统中,如何根据机器系统负载及当前执行任务列表进行任务动态负载?
A:目前作法是给任务设定一个逻辑的负载,在调度的时尽量作到各个机器的总体负载均衡。
Q:若机器挂掉,如何进行有状态任务的故障转移?
A: 利用Zookeeper特性,当一台机器掉线后,它上面的做业会被调度到其它机器来完成。
Q:任务间可能存在一些依赖,如何解决这些任务间的传递问题?
A: 目前经过配置的方式设置任务依赖,当中止、启动做业时会给予提醒。任务间的消息传递可利用消息做业的方式进行。
Q:当用户上传的是危险操做,平台如何进行自我保护?
A:目前利用容器作隔离,固然也能够经过Chroot的方式将做业运行目录隔离。
Q:若任务堵住了Hang 任务进程会表现正常,但实际业务没有处理,如何解决?
A:须要平台级别超时控制,超过必定阈值时发送告警,再过必定阀值杀掉任务。
Q:消息做业支持哪些平台,消息做业的性能表现如何?
A:目前支持Kafka,后续也会支持RabbitMQ。至于性能,内部测试能够达到20W的TPS。机器的配置为Mem:48G,CPU:16C*2.2G。
Q:是否支持在容器化的平台运行?
A:支持,目前支持发布到Marathon、数人云SWAN、以及Kubernetes平台。
Q:开源版本如EJ和Saturn,不支持认证或提供BASIC认证。企业难以使用,如何处理?
A:数人云调度平台提供基于角色的标准认证,也支持对接LDAP的方式。
Q:针对开源版本,数人云调度平台提供哪些企业级功能?
A:提供认证受权、审计、对接Prometheus的Metrics、历史配置与版本恢复。
数人云Octopus基于当当Elastic Job和惟品会的Saturn以及数人云DM/OS和容器云平台,打造的高效易用定时任务调度系统。支持多种任务类型和模式,具备资源动态平衡以及框架、业务隔离的功能,并且无缝融合物理机、虚拟机以及容器,从而实现调度任务统一监控管理,全面高可用。
无缝代替 Linux Cron Job:完美代替 Linux Cron Job,作到全局统一配置、统一管理、统一监控。
分布式任务调度:分布式并行任务处理,如分库分表的批处理等。
本地任务调度:能够根据任务量,任意调整处理资源。如电商商品图片扫描处理等。
消息任务调度:经过消息调度做业处理。如日志处理、消息驱动数据库同步等。
2)JAVA 任务:提供灵活编程模式,知足不一样的业务需求;3)消息任务:提供消息驱动,支持任务间串接;4)分布式运行与本地任务模式:提供分片、分区处理模式,以及 Daemon 模式,知足业务灵活并行处理。