为什么要做Maat？——基于ODPS的流程调度系统
阿里妹导读：搜索中台建设过程中，单个系统不再能满足复杂业务的需求，更多时侯还要多个子系统相互协作，异步地根据指定步骤完成一项特定的功能。比如一个应用的上线步骤依次须要读取配置同步模块、监控模块、资源更新模块、冒烟模块、引擎争创模块，步骤的运行中又有分支判断、上下文传递、失败重试等需求。基于这些需求，Maat将各种步骤化的任务集中管理，各个任务节点以分布式的形式运行在不同容器内，保证步骤高效稳定地运行。
背景
哪些是Maat？
Maat是一个基于开源项目的步骤调度系统，它支持用户自定义地装配步骤节点，步骤可以在用户指定的时间触发（支持格式），或由用户自动触发。
Maat的所有节点分布式地运行在Hippo上，由Drogo调度。用户可以争创自己的调度节点和执行节点，达到资源隔离的目的。
用户可以通过配置的形式安装自己执行节点的运行环境，也可以配置执行节点的副本数。
右图展示了一个任务的一次调度步骤：
为何要做Maat？
我们在项目的开发过程中，常常碰到一些步骤化/定时调度的需求，如上线公布步骤、定时剖析任务步骤等。对于某些步骤化的调度任务，我们尝试过自己开发了一套步骤调度系统，也尝试过接入企业集团的工作流，但难免会碰到一些问题：
技术选型
定时任务&步骤任务的调度是一个通用的需求，企业集团内的产品如D2、工作流，开源的产品如、等。
★D2
D2是基于ODPS生态的一套步骤调度系统，承载企业集团基于ODPS数据产出的调度任务。支持用户自定义撰写脚本，支持定时任务触发和自动触发（补运行的模式），适于基于数据状态的任务步骤调度（如按照数据的产出执行任务流），由D2团队专门维护，有较差的UI。
但它有一些不足：
★工作流
企业集团工作流是企业集团审批步骤的一个通用调度引擎，这些产品的审批步骤都是基于企业集团工作流的，同时它也可以作为一个简易的任务调度步骤使用，我们在Maat之前也使用企业集团工作流作为我们步骤任务的调度引擎。它支持自动触发，支持以HSF的方法读取外部系统，支持上下文传递。但它在配置上较为复杂，且支持外部系统的读取模式有限。
★
是Java开源的任务调度框架。它支持分布式调度、支持任务持久化、支持定时任务，但不支持步骤调度，且任务配置还要耦合在调度系统中，任务的热读取还要做一些扩建。
★
开源项目是一套分布式的步骤调度系统，它的优势如下：
经过一段时间的考察，我们采用作为我们的原型开发一套分布式任务调度系统，它功能全面，基本满足业务需求，在功能上扩充相对便捷，外部依赖较少，和搜索生态对接相对容易。
原生的问题
可以解决步骤调度中面临的许多问题，但直接将原生的适于生产，仍面临一些问题：
Maat构架
Maat构架：
业务层
任何流程式调度及定时触发的需求均可以通过Maat争创应用，Maat提供了可视化编辑页面及丰富的api，用户可以便捷地争创编辑步骤模版，设置复杂的分支逻辑，Maat会在调度时根据运行时的状态决定步骤的流转路径。
现在接入Maat的应用场景包括、、Kmon、容量平台、离线组件平台、
管控层
因为原生的管控比较简略，是基于描述任务步骤dag的脚本调度，用户要进行任务的争创、更新、运行还要深入学习原理能够上手，但是后来维护只好基于文件操作，十分不便。因而Maat在内层封装一层管控系统Maat，增加维保及用户学习的费用。
右图是Maat管控系统Aflow的操作界面：
★模板管理
在任务步骤调度的场景中，常见的状况是：不同任务执行的步骤基本一致任务平台，只有某些参数不同。因而Maat提出了基于模版管理的任务步骤，用户在模版管理中定义一个步骤的运行模版，对于其中未确定的部份用变量表示。当生成详细任务时，由详细变量和模版渲染出示体的任务。当模版更改时，可以将模版生效到所有依赖该模版的任务。
模版管理预设了几种任务节点任务平台，用户可以自由选择不同的任务节点装配模版步骤。
★应用管理
管理所有详细的步骤调度任务，包括任务使用的模版、变量的值、报警信息、任务触发等，用户在通过模版争创应用后，后续可以通过应用管理继续维护任务的运行。
★队列管理
因为Maat上运行的任务所属应用各不相似，不同应用运行环境也不相似，另外不同应用也希望达到集群隔离的目的。为了实现这个功能Maat提供了队列的管理，指定队列的任务节点会被调度到相应队列的机器上，相应队列的机器也只会运行指定队列的任务节点。
另外，队列上也可以指定并发数，表示当前队列上最多同时有多少个任务运行，确保机器上同时运行的任务不会很多造成负载过低，超过并发的任务会被挂起直至资源释放。
核心模块
Maat核心模块完成了任务调度的整个步骤。核心模块的每位节点都独立运行在机器上，启动上彼此不依赖，通过DB保存数据状态，通过MQ或FaaS完成消息的分发。
★WebApi
WebApi提供了丰富的与外部交互的Api，包括任务增删改、历史任务状态、任务状态更改、任务的触发、任务的重试等插口。
另外原生提供的web展示功能只是由该角色完成。
★
是Maat关键角色，它决定了任务何时被调度运行，也决定一次任务运行中，这些节点可以被执行。被判断执行的节点会被通过MQ或FaaS发送给执行。
随着任务的增多，单一的负载过低引致调度周期下降，为了减少的压力，Maat将根据业务分拆。不同业务的任务有独立的负责调度，发送任务到指定的上。
★性能优化
原生的调度逻辑吞吐量较低，当任务量增多时，调度周期会很长，一些任务多的推迟抵达1分钟左右。我们参考社区最新的实现，对原生调度逻辑进行优化，将原本阻塞的调度方法分拆为多个进程池，全异步地完成可执行任务的生产->递交->线程操作。经相序测原本调度周期为30s-40s的场景增加为5s左右。
★
为详细执行任务的角色，会接受发出的任务，在上执行节点中描述的详细任务。多副本布署，任务会在任意一个对等的上机器，当资源不足时，可以动态扩容。
因为不同队列任务所需的基础环境不同，如、Java、、zk等，不同队列的角色启动参数有配置上的差别，不同队列的启动时会根据配置中描述的资源完成布署安装。
上任务完成后会回写db，发觉到当前任务状态变化后会继续任务的调度。
★
任务分发层负责将须要调度的任务发送到指定的上。现在Maat同时使用原生+的形式和搜索生态FaaS的形式实现任务分发。
★+
原生使用+完成消息从到的分发。
将须要运行的任务发送到MQ中，发送到MQ中包含任务对应的队列信息。从MQ获取消息时，仅获取相应队列任务，拉取到对应上执行。MQ在Maat中以实现，MQ和其他角色一样，只是独立布署的。
+的模型对消息队列中的任务进行持久化，所有的任务状态也进行持久化，显存Queue的功耗满足大部份场景的需求。但因为Maat基于二层调度Drogo布署，任何布署节点都要求无状态的，而消息队列MQ由于保存消息状态虽然不满足这个要求，因此我们选择使用搜索生态的FaaS框架作为+的取代方案。
★FaaS
FaaS：FaaS（asa）是基于搜索生态实现的框架，Maat将其作为执行器。Maat的所有任务都具象成，任务执行时则读取相应的，完成后返回任务状态。现在已完成与FaaS的初步对接，期望未来能基于FaaS做更多优化。如：多元化的任务执行方法，可以将羽量级的任务函数化，将重量级的任务服务化；任务资源动态调整，并且这些任务可以执行时分配资源，完成后即释放。
对于Maat来讲，FaaS支持任务从生产者到消费者的分发，外置消息Queue，提供任务状态插口，同时FaaS自身保证消息不对遗失，后续还具有按照消费者负载手动扩缩容的功能。
★基础组件
Maat平台的优势
可视化编辑及通用的节点类别
Maat提供了一个管控平台Aflow，用户可以便捷地编辑步骤节点，管理所有的模版和任务，具体见上文的[管控层]。
除此此外，Maat还提供了丰富的通用节点类别。原生支持许多不同种类的节点类别，这种节点可以执行不同类别的任务。在与用户的接触中，Maat针对用户的使用习惯与需求，对一些节点进行封装，同时开发了几种新的节点类别，可以满足大部份用户的需求。
Drogo化布署
Maat服务有多种角色，每种角色都还要不同的运行环境，为了维护这种运行环境，对维保老师来说绝对是个恶梦，这些状况下上hippo成为Maat维保最好的选择。drogo作为基于二层调度服务的管控平台，为Maat各个节点布署在hippo上成为或许。详细来说，Drogo化的优势如下：
右图展示了现在Drogo上布署的Maat各个角色：
因为原生的一些节点是有状态的，还要依赖本地一些文件，机器迁移会造成某些节点的状态遗失，我们对Maat做了一些更改，保证机器迁移不会遗失运行状态：
分集群管理
因为不同任务隔离的需求，Maat基于原生的队列管理扩充不同任务的集群管理功能，不同类别的任务可以争创自己的和，争创应用时可以使用指定的调度或运行在指定上（假如不指定由默认和调度）。
集群的配置参数包括以下信息：
监控&报案
★平台监控报案
为了把握平台的运行情况，Maat在各个节点的关键方法向kmon汇报信息，异常状态下会发送报案给开发老乡。也可以按照这种信息辨别当前集群的负载情况，对任务负载较高的节点进行优化。
★任务报案
对于详细任务，Maat支持在每位任务节点运行异常的状况下发送报案，如节点运行异常、任务未按量运行、任务运行超时等。用户可以在管控平台设置报案条件及报案接收人。
平台状况
Maat是一个通用基于Dag的任务调度系统，服务于企业集团内部和云上的许多场景：
Maat线上集群任务执行状况（2018.8.13数据）：
随着更多应用场景的接入，平台能力将要接受逐步的考验。
未来展望
随着业务的接入和数据规模的减小，Maat平台也须要逐步提高用户感受，提高平台稳定性。
加入我们
搜索中台从0到1建设早已走过了3年，但它离我们心目中让天下没有难用的搜索的远大愿景还离的特别远，在这个前行的公路上一定会富有挑战，无论是业务角度的SaaS化能力、搜索算法产品化、云端&aiops，还是业务做网站等都将遇见世界级的瓶颈等着我们去挑战。因此，无论是web开发，引擎开发还是算法老师，欢迎点击文末“阅读原文”加入阿里搜索中台团队我们一起做最牛X的搜索中台，让天下没有难用的搜索。
一天一篇技术文章，
看不带劲？
评论列表 (0)