数人云|关于分布式任务调度平台，数人云的经验都在这里了

分布式任务调度平台是目前很多公司研究的方向，今天小数就给大家分享一下数人云分布式任务调度平台（Octopus）的一些思考与实践。

今天主要分享下批量处理平台的技术心得，批量处理从片面的角度讲类似于Linux系统中的Cron Table，从大方向去看属于批量业务的调度平台，此次依托数人云3年来对容器技术的积累和对批量处理开源项目的整合过程，在这里和大家探讨一下实践分布式任务调度的心路历程。

从理论上来说，做分布式系统并非企图加快单一任务处理速度，而是通过并行的方式合理利用资源，通过加大对任务的同时批量处理业务容量来加快业务的运营速度，举个典型的例子：当前视频直播中需要的视频文件解码，就是一种典型的批量处理业务。

本来，批量处理业务和容器技术的关系并不紧密，我们通过跨领域的交叉设计，希望通过容器技术的封装能力帮助批处理系统快速建立更多的高密度批量处理运行时环境，更高效地利用资源。

定时任务无处不在，在多任务处理时如何进行秒级调度？与容器如何碰撞？这是我比较关注的主题，个人的角度来看，批量处理系统的痛点有四个维度是用户比较关注的：

• 弹性伸缩
• 故障处理
• 运维体系
• 性能指标

以金融行业为例，在金融行业高速发展的今天，业务规模快速扩展，随着业务的发展，需处理的数据量越来越大，后台批量处理业务占60%以上，如数据接口导入、数据预处理、估值表生成、凭证生成、对账、日终批处理、报表生成等。

从用户关注的4个维度切入问题主要表现在：

弹性扩缩：批量处理作业只能运行在一个服务节点上，无法适应业务发展，这是目前业务系统的最大性能瓶颈点。

故障处理：当作业发生故障时，未实现故障自动转移，严重时影响业务进展。

性能指标：
1. 作业调度与作业执行线程耦合在一起，随着作业规模的增长，严重影响系统性能，也给开发和运维带来了一定的难度。
1. 联机业务和批量处理业务耦合，当在进行比较消耗资源的批处理或批量处理服务发生严重故障时直接影响到了在线业务。

运维体系：不便于定位作业运行时问题，不便于了解作业运行进展、负载情况、也缺少作业运行时的性能指标，不便于对作业进行调优等。

有了这些分析，在设计竖线数人云分布式任务调度平台过程中，采用作业调度与作业执行分离的架构来简化业务系统批量处理的开发和运维工作；采用中间件和平台化的思路提升其应用的范围及价值；采用Java系统作业的调度，执行与管控；最后产生的效果是实现了以分布式调度为理念而设计的——多服务节点协同并行处理能力及运行环境的适用能力。

在弹性伸缩方面，数人云采用了基于容器平台目的是快速构建多节点的任务执行节点，容器的好处是封装了一整套完整的任务执行环境，并且可以快速扩容服务节点数量，这个批处理设计模型如何自己实现会需要大量的测试和业务打磨，所以在技术选型上，选用了Mesos作为企业级环境的底座，毕竟Apple、MS、Netflix、Uber等大厂都在基于此技术上构建了自己的业务平台。

尤其国内开源项目当当的Elastic-Job批量处理平台（https://github.com/dangdangdotcom/elastic-job）受到很多厂家的采用，为数人云提供了一手的学习实践经验。

数人云在此之上又进行了一些优化，从设计理念中，更多考虑了业务实际场景中的一种状况：即每次任务处理完毕后，是重置当前进程环境还是退出，虽然容器的额快速启停确实可以解决这个小问题，但仍然不够快。毕竟一个任务的环境初始化是需要消耗时间的，即使容器启动也有那么几十毫秒的损耗。另外，我们对Mesos集群的使用，在于提供可以FailOver的高容错环境，并没有直接让Mesos来调度批量处理任务，实际上，作业节点注册到ZK后，任务的分发和结果收集都是在JVM里面解决，和Mesos集群本身没有关系，减少了对集群系统的直接依赖，后面，我们还会对Kuberentes集群做支持。

在故障处理方面，重要的并不是让任务永远不出错，在创建任务时，能提供立即执行一次的操作，让执行结果能即刻体现出来，这样给任务指定的时间去跑才不会出错，在创建任务的细节上，比如把跑批时间参入如：0/5 * * * * ? 预测出固定的时间，让用户看到直接的时间会更好。

对于事后的历史结果留存也需要做到详细完整，保证故障拍错，这块使用统计面板来监控即可。

以及作业预警面板也是需要的。

在性能指标方面，大量的工作主要是定义好性能指标并大量压测并调优系统，比如数人云的产品定义：

调度频率：定时作业最快支持5S的时间间隔，对比：公有云如阿里ScheduleX，都是分钟级间隔。

支持作业容量：最多支持管理100个Zookeeper集群，作业总量支持到500K+。

消息作业并发量：支持单节点100K TPS的并发。

通过这个目标，根据本地搭建的作业系统环境就可以压测了，压测数据通过Grafana展现出来，测试样例如下：

在运维体系中，能不能通过一个管理平台就囊括所有运维需要管理的事情，将其都考虑进去，比如组织关系的体现，暂停时间的管理，配置数据的备份和查询，ZK元数据的到处备份工作，调用链的跟踪设计实现，各种监控面板的实现，这个难度不大，但需要考虑的细节非常多，我们也是在参考和落地实践中摸索这些问题如何解决。

最后，分布式任务调度平台在企业架架构体系里面必不可少少的组件，国内企业在经过这几年云计算的高速发展，开始意识到数字化转型过程中必须要经历架构方面的变革，传统的批处理系统已经不能适应业务发现的需要，不妨参考业内开源领域的最佳实践构建自己的分布式调度平台。

QA

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

数人云Octopus基于当当Elastic Job和唯品会的Saturn以及数人云DM/OS和容器云平台，打造的高效易用定时任务调度系统。支持多种任务类型和模式，具有资源动态平衡以及框架、业务隔离的功能，而且无缝融合物理机、虚拟机以及容器，从而实现调度任务统一监控管理，全面高可用。

〓 应用场景

无缝代替 Linux Cron Job：完美代替 Linux Cron Job，做到全局统一配置、统一管理、统一监控。

分布式任务调度：分布式并行任务处理，如分库分表的批处理等。

本地任务调度：可以根据任务量，任意调整处理资源。如电商商品图片扫描处理等。

消息任务调度：通过消息调度作业处理。如日志处理、消息驱动数据库同步等。

〓 功能特性

• 资源动态平衡：人工指定运行节点，系统自动平衡负载，灵活的运维配置与部署，高效资源利用，简便的管理。

• 认证与授权：提供 LDAP 集成，以及多角色权限管理。

• 框架与业务隔离：框架代码与业务代码隔离，集中化动态增加与删除任务，简化开发，避免冲突，业务无侵入，易于发布与维护，框架升级与业务脱离，框架版本统一升级。

• 分组以及依赖管理：严谨的管理模式以及灵活的设置。

• 秒级调度：提供任务秒级触发。

• 简单易用的 SDK：快速开发业务。

• 资源混搭：支持物理机、虚拟机以及容器。

• 优美的监控台：提供多维度 Dashboard 以及监控视图。

• 多种任务类型与任务模式：
  1）Shell 任务：提供任意脚本语言，无缝迁移 Linux Cron Job；
  2）JAVA 任务：提供灵活编程模式，满足不同的业务需求；
  3）消息任务：提供消息驱动，支持任务间串接；
  4）分布式运行与本地任务模式：提供分片、分区处理模式，以及 Daemon 模式，满足业务灵活并行处理。