基于Mesos的当当作业云Elastic Job Cloud

本文是当当网架构专家张亮在CNUTCon北京2016 全球容器技术大会上的演讲整理而成。

作业在互联网电商行业中是很常见的技术手段。当当具有成千上万的作业规模，大致分为业务类、归档类、监控类和大数据类。

当地分布式调度原方案

当当原有的作业解决方案是Elastic Job，以下称为Elastic Job 1.X。主要关注以下4个方面：

1、高可用。这里高可用指主从热备。主节点提供服务的同时从节点处于等待状态。一旦主节点失效，其中一个从节点通过选举成为主节点继续提供服务，原来的主节点再次生效后，作为从节点继续等待选举机会。

2、线性扩展。可理解为高可用的高阶功能。既然多节点参与服务提供，若从节点只负责热备，难免造成资源浪费，将主备调整为分片，则可大幅提升处理能力。中心化分布式服务基本都是提供独立的调度中心和执行节点，调度中心提供主备，执行节点可以弹性的线性扩展。Elastic Job1.X采用无中心化架构，并无调度中心，而是各个执行节点通过Zookeeper选举主节点进行分片、清理等动作，作业调度由执行节点自行触发。Elastic Job 1.X通过分片进行线性扩展，每个执行节点负责处理被分配到的分片项，应用开发者负责分片项和业务逻辑的对应关系。代码示例：

public class MyElasticJob implements SimpleJob {

@Override public void process(ShardingContext context) {
 switch (context.getShardingItem()) {
 case 0:
 // do something by sharding item 0
 break;
 case 1:
 // do something by sharding item 1
 break;
 case 2:
 // do something by sharding item 2
 break;
 // case n: ...
 }
 }}

1、容错性。主要包括节点失效重分片、失效转移、错过任务重执行以及分布式场景下的脑裂，网络抖动容错等。

2、异构语言。Elastic Job支持Java和Shell，基本能做到异构语言支持。

Elastic Job 的核心组件图如下：

绿色部分是Elastic Job 1.X对开发者提供的API。蓝色部分为内部实现，主要有选举模块、分片模块、调度模块、持久化模块以及分布式协调模块。持久化和协调均基于Zookeeper。

部署架构图如下：

Elastic Job 1.X与应用代码部署在一起，作为lib提供服务。Elastic Job 1.X和运维平台通过注册中心进行交互。

Mesos对云平台解决方案的革新

花了这些篇幅介绍背景，目的是让大家了解当当原有的分布式作业解决方案，接下来将阐述新一代的平台化作业解决方案。

随着时代发展进步，分布式操作系统、容器以及各式各样的容器编排治理方案层出不穷，站在巨人的肩膀上，可以更快速稳定的搭建云平台，基于这样的考虑，我们决定拥抱革新。我们首先将目光投在了Docker上，希望将Elastic Job容器化，然后再选择一个容器治理方案。经过调研，我们转而倾心Mesos，因为我们的目标不是容器化，而是云化，容器是实现云的一种手段，但合理的分布式编排系统更加关键。Docker本身有网络、日志采集等问题需要解决。而Mesos将Docker作为可选容器支持，为了最小化采用新技术带来的风险，我们决定将Docker容器化推迟，先将Elastic Job迁移至Mesos。这也得益于Mesos对Docker的无缝支持，以后加入对Docker的支持非常容易。

下图是Mesos的核心概念：

蓝色是Mesos的基础组件，由Mesos Master、Mesos Agent和运维界面/API组成。Master/Agent的形式在分布式系统中很常见，如Hadoop map-reduce的JobTracker/TaskTacker。Mesos Master节点通过Zookeeper实现高可用，用于分配资源至注册在Mesos的 Framework，Mesos Agent用于收集宿主机资源，如可用CPU、内存、甚至GPU等，并负责执行Mesos Framework分发的任务。Mesos Master与Slave间使用内部API交互，通过远程执行部署在Mesos Agent的程序无需Mesos Agent所在服务器提供免登录账号。

紫色是Mesos Framework的组成部分。Mesos只有基础组件并不能独立使用，需要注册Framework接收Mesos Master分配的资源并决定如何执行，目前常见的Marathon和Chronos都是Mesos Framework。Framework的两个重要组成是Scheduler和Executor。Scheduler和Mesos Master通过Scheduler API交互，负责将分配的资源生成任务并分发。Executor通过Executor API与Mesos Agent交互，负责执行分配的任务并回告状态。

红色是Scheduler中两个最重要的回调方法，resourceOffers和statusUpdate。

resourceOffers用于将资源转化为任务并调用Executor执行。资源分配算法，任务业务逻辑都应在此方法中实现。

statusUpdate用于处理Executor回传的状态。可通过Executor的状态传递和Scheduler的statusUpdate实现失效转等的分布式协调功能。

Executor分为两种。

Marathon和Chronos都使用Command Executor，这也是Mesos提供的内置的Executor，可以直接执行命令行脚本，也提供了基本的状态回传功能，对于普通应用使用Command Executor是不错的选择。

自定义Executor可提供更多灵活性。下面举几个例子，但不限于仅实现这些功能。

1、日志重定向。Command Executor的日志会输出到Mesos提供的沙箱中，通过自定义Executor可将日志重定向到其他文件，或对接其他日志收集工具。

2、多任务复用。Command Executor与任务是一对一的关系。有些初始化资源非常耗时的场景，可以复用Executor，多线程并发处理多任务。

3、执行进度报告。Command Executor仅回告状态变化，如需更加细化进度回告功能，需定制化处理。
心跳检测。可以通过Executor定时传递消息做心跳检测。
简单的介绍了Mesos，是该讨论下Mesos能带来什么好处的时候了。Mesos可作为部署平台和运行平台使用。

作为部署平台，Mesos可以做到应用分发自动化。将应用上传到网络地址（或Docker仓库），Mesos能够自动将应用分发至需要执行相关任务的Mesos Agent，省去人工部署成本。由于应用自动分发，那么CMDB将大大简化，只需要管理Zookeeper服务器即可，Mesos Master、Mesos Agent以及其他部署在Mesos内部的应用均可用Mesos界面统一管理。美中不足是Mesos目前缺乏管理数据类服务器的成功案例，数据库等部署在Mesos之外的应用仍需独立的CMDB管理。

作为运行平台，Mesos可以将资源收集至统一资源池，做到硬件资源与应用一体化，按需分配资源，自动资源回收，减少资源闲置和浪费。

应用分发、资源分配和安全管理，即可形成云平台的雏形，由于当当仅搭建私有云，安全管理暂时不是重点。

现在再分析Elastic Job 1.X的解决方案，应用分发和资源分配部分是缺失的。

基于Mesos开发作业云Elastic Job Cloud

决定基于Mesos搭建作业云，我们开始调研实现方案。首先想到自然是拥抱开源，不重复发明轮子。方案A是使用Marathon作为调度框架。

方案A的优点是可以实现应用分发和资源分配，并且是高可用的解决方案。

但缺点同样明显：

1. 资源分配静态化，作业无论执行与否均需预分配资源；
2. Executor无法复用，对于Elastic Job这种对内部状态报告有要求的框架，需要在框架中通过第三方存储汇报状态；
3. 跨机房等定制化功能较困难；
4. 使用繁琐，需要使用Mesos、Marathon和Elastic Job 3个管理界面。

另一种类似的方案是使用Chronos，可以做到动态资源分配，但缺点是：

1. 不支持CRON表达式，对于原crontab或Quartz的应用迁移不友好；
2. 不适合低延迟作业，每次启动初始化资源会消耗时间，导致作业延迟，反复初始化也容易造成资源浪费；
3. 定制功能仍然困难。

说到这里需要抛出常驻作业和瞬时作业概念了。

常驻作业是作业一旦启动，无论运行与否均占用系统资源；瞬时作业是在作业启动时占用资源，运行完成后释放资源。

常驻作业适合初始化时间长、触发间隔短、实时性要求高的作业，要求资源配备充足。

瞬时作业适合初始化时间短、触发间隔长、允许延迟的作业，一般用于资源不太充分，或作业要求的资源多，适合资源错峰使用的场景。

由于上述缺点，我们最终选择方案B。

我们决定自行开发Mesos Framework，项目的名称叫做Elastic Job Cloud。优点：

1. 包含方案A的全部优点；
2. 资源分配静态与动态相结合，常驻与瞬时作业分离处理；
3. Elastic Job 1.X的核心理念仍可沿用，包括分片，以及之前未提及的功能，如多种作业类型，事件统计等；
4. 易于定制化需求开发。

Elastic Job Cloud核心组件图如下：

绿色的API部分变化不大；红色的内部实现部分，无论是模块本身，还是模块的内部实现均有大幅度调整。

选举模块由执行节点主节点选举变更为主Mesos Framework选举，仍然依赖Zookeeper。

Sharding模块功能未变，但从执行节点主节点分片调整为Mesos Framework集中分片。Elastic Job 1.X的分片以IP为依据，Elastic Job Cloud更改为以运行任务实例为依据。

调度引擎从去中心化执行节点调度转变为Mesos Framework的中心节点调度。

通过调度作业向任务队列中写入待执行作业。

日志输出方式变更为事件发布，可自行监听发布的事件，收集Elastic Job Cloud的运行状态，默认提供日志和数据库（推荐）两种事件收集方式。

通过Executor和Scheduler API配合进行分布式协调，替换通过Zookeeper协调的方案，有效的减少了与Zookeeper的连接数。

Elastic Job Cloud作为Mesos Framework独立部署，将作业信息存入Zookeeper。

虽然Elastic Job Cloud可以提供中心化云解决方案，但Elastic Job 1.X作为无中心化解决方案，仍适用于中小规模的分布式作业调度场景。我们并未放弃Elastic Job 1.X，将其更名为Elastic Job Lite。Elastic Job Lite和Elastic Job Cloud共同组成Elastic Job，核心组件全景图如下：

Elastic Job Lite和Elastic Job Cloud使用统一的Elastic Job API，开发者在开发时无需关心最终的部署方式。部署在Lite或Cloud环境无需修改业务作业代码，秩序调整配置和启动方式即可。Lite和Cloud的差别仅在于云平台需要的应用分发和资源调度一体化。

目前Elastic Job Cloud已开发完成并在公司内部试用。日前对接监控系统的万余作业，全天运行峰值百万左右。

Elastic Job Cloud的roadmap是：

1. 公司内部大规模推广使用；
2. Docker支持；
3. 任务优先级、依赖以及编排的支持；
4. 跨机房部署、物理机隔离等功能开发。

回馈开源社区

目前Elastic Job已全部开源。欢迎感兴趣的人踊跃尝试。

最后我分享下我们这4个月以来的里程碑。