?

阿里妹導(dǎo)讀：搜索中臺(tái)建設(shè)過程中，單個(gè)系統(tǒng)不再能滿足復(fù)雜業(yè)務(wù)的需求，更多時(shí)候需要多個(gè)子系統(tǒng)互相協(xié)作，異步地按照指定流程完成一項(xiàng)特定的功能。例如一個(gè)應(yīng)用的上線流程依次需要調(diào)用配置同步模塊、監(jiān)控模塊、資源更新模塊、冒煙模塊、引擎創(chuàng)建模塊，流程的運(yùn)行中又有分支判斷、上下文傳遞、失敗重試等需求。基于這種需求，Maat將各類流程化的任務(wù)集中管理，各個(gè)任務(wù)節(jié)點(diǎn)以分布式的方式運(yùn)行在不同容器內(nèi)，保證流程高效穩(wěn)定地運(yùn)行。

背景

什么是Maat？

Maat是一個(gè)基于開源項(xiàng)目Airflow的流程調(diào)度系統(tǒng)，它支持用戶自定義地組裝流程節(jié)點(diǎn)，流程可以在用戶指定的時(shí)間觸發(fā)（支持crontab格式），或由用戶手動(dòng)觸發(fā)。

Maat的所有節(jié)點(diǎn)分布式地運(yùn)行在Hippo上，由Drogo調(diào)度。用戶可以創(chuàng)建自己的調(diào)度節(jié)點(diǎn)和執(zhí)行節(jié)點(diǎn)，達(dá)到資源隔離的目的。

用戶可以通過配置的方式安裝自己執(zhí)行節(jié)點(diǎn)的運(yùn)行環(huán)境，也可以配置執(zhí)行節(jié)點(diǎn)的副本數(shù)。

下圖展示了一個(gè)任務(wù)的一次調(diào)度流程：

為什么要做Maat？

我們?cè)陧?xiàng)目的開發(fā)過程中，經(jīng)常遇到一些流程化/定時(shí)調(diào)度的需求，如上線發(fā)布流程、定時(shí)分析任務(wù)流程等。對(duì)于這些流程化的調(diào)度任務(wù)，我們嘗試過自己開發(fā)了一套流程調(diào)度系統(tǒng)，也嘗試過接入集團(tuán)的工作流，但難免會(huì)遇到一些問題：

• 業(yè)務(wù)代碼和調(diào)度代碼耦合嚴(yán)重，修改流程基本需要入侵到代碼級(jí)別，業(yè)務(wù)代碼的發(fā)布影響調(diào)度。
• 對(duì)于這些調(diào)度任務(wù)，沒有一個(gè)統(tǒng)一管控的系統(tǒng)，難以管理和追溯。
• 多分支的復(fù)雜流程不能很好支持，上下文傳遞場(chǎng)景不能很好支持。
• 缺少可視化的UI，用戶使用不友好。

技術(shù)選型

定時(shí)任務(wù)&流程任務(wù)的調(diào)度是一個(gè)通用的需求，集團(tuán)內(nèi)的產(chǎn)品如D2、工作流，開源的產(chǎn)品如Airflow、Quartz等。

★ D2

D2是基于ODPS生態(tài)的一套流程調(diào)度系統(tǒng)，承載集團(tuán)基于ODPS數(shù)據(jù)產(chǎn)出的調(diào)度任務(wù)。支持用戶自定義編寫腳本，支持定時(shí)任務(wù)觸發(fā)和手動(dòng)觸發(fā)（補(bǔ)運(yùn)行的方式），適合基于數(shù)據(jù)狀態(tài)的任務(wù)流程調(diào)度（如根據(jù)數(shù)據(jù)的產(chǎn)出執(zhí)行任務(wù)流），由D2團(tuán)隊(duì)專門維護(hù)，有較好的UI。

但它有一些不足：

• D2的DAG調(diào)度是一張大圖，每天需要運(yùn)行的每個(gè)節(jié)點(diǎn)及拓?fù)潢P(guān)系是根據(jù)前一天的全局的拓?fù)潢P(guān)系計(jì)算得出的，所以新創(chuàng)建/修改的任務(wù)理論上只能第二天生效，如果想立即生效需要采用補(bǔ)運(yùn)行的方式。業(yè)務(wù)上經(jīng)常會(huì)有任務(wù)的變動(dòng)（如任務(wù)配置或調(diào)度時(shí)間），或手動(dòng)觸發(fā)一個(gè)調(diào)度的場(chǎng)景（如隨時(shí)發(fā)生的上線流程、全量流程），使用D2對(duì)業(yè)務(wù)不是很靈活，也不符合D2的使用場(chǎng)景。
• 不支持流程上下文的傳遞，業(yè)務(wù)上對(duì)上下文的傳遞比較強(qiáng)烈，經(jīng)常有上個(gè)節(jié)點(diǎn)產(chǎn)出某個(gè)值，下個(gè)節(jié)點(diǎn)需要使用。
• 缺乏對(duì)搜索生態(tài)的支持。搜索技術(shù)部整個(gè)底層架構(gòu)有自己的一套生態(tài)，如調(diào)度（Hippo，Drago）、報(bào)警（Kmon）。使用D2，不能充分享受搜索技術(shù)生態(tài)帶來的好處，對(duì)于之后的單元化部署也會(huì)帶來問題。

★ 工作流

集團(tuán)工作流是集團(tuán)審批流程的一個(gè)通用調(diào)度引擎，很多產(chǎn)品的審批流程都是基于集團(tuán)工作流的，同時(shí)它也可以作為一個(gè)簡(jiǎn)易的任務(wù)調(diào)度流程使用，我們?cè)贛aat之前也使用集團(tuán)工作流作為我們流程任務(wù)的調(diào)度引擎。它支持手動(dòng)觸發(fā)，支持以HSF的方式調(diào)用外部系統(tǒng)，支持上下文傳遞。但它在配置上較為復(fù)雜，且支持外部系統(tǒng)的調(diào)用方式有限。

★ Quartz

Quartz是Java開源的任務(wù)調(diào)度框架。它支持分布式調(diào)度、支持任務(wù)持久化、支持定時(shí)任務(wù)，但不支持流程調(diào)度，且任務(wù)配置需要耦合在調(diào)度系統(tǒng)中，任務(wù)的熱加載需要做一些改造。

★ Airflow

開源項(xiàng)目Airflow是一套分布式的流程調(diào)度系統(tǒng)，它的優(yōu)勢(shì)如下：

• 業(yè)務(wù)代碼和調(diào)度系統(tǒng)解耦，每個(gè)業(yè)務(wù)的流程代碼以獨(dú)立的Python腳本描述，里面定義了流程化的節(jié)點(diǎn)來執(zhí)行業(yè)務(wù)邏輯，支持任務(wù)的熱加載。
• 完全支持crontab定時(shí)任務(wù)格式，可以通過crontab格式指定任務(wù)何時(shí)進(jìn)行。
• 支持復(fù)雜的分支條件，每個(gè)節(jié)點(diǎn)單獨(dú)設(shè)定觸發(fā)時(shí)機(jī)，如父節(jié)點(diǎn)全部成功時(shí)執(zhí)行、任意父節(jié)點(diǎn)成功時(shí)執(zhí)行。
• 有一套完整的UI，可視化展現(xiàn)所有任務(wù)的狀態(tài)及歷史信息。
• 外部依賴較少，搭建容易，僅依賴DB和rabbitmq。
• 有同學(xué)問到Luigi與Airflow的對(duì)比，個(gè)人感覺都是基于pipline的一個(gè)任務(wù)調(diào)度系統(tǒng)，功能也大同小異，Airflow屬于后來居上，功能更強(qiáng)，找到一篇同類產(chǎn)品的對(duì)比。

經(jīng)過一段時(shí)間的調(diào)研，我們選用Airflow作為我們的原型開發(fā)一套分布式任務(wù)調(diào)度系統(tǒng)，它功能全面，基本滿足業(yè)務(wù)需求，在功能上擴(kuò)展相對(duì)方便，外部依賴較少，和搜索生態(tài)對(duì)接相對(duì)容易。

原生Airflow的問題

Airflow可以解決流程調(diào)度中面臨的許多問題，但直接將原生的Airflow用于生產(chǎn)，仍面臨一些問題：

• 原生Airflow雖然支持分布式，但由于依賴本地狀態(tài)，不能直接部署在drogo上。
• 缺乏合適的監(jiān)控手段，需要結(jié)合kmon完善監(jiān)控和報(bào)警設(shè)施。
• 缺乏用戶友好的編輯手段，用戶需要了解Airflow的原理和細(xì)節(jié)。
• 大量任務(wù)運(yùn)行時(shí)，調(diào)度的性能急劇下降。
• 分布式模式下，原生Airflow存在一些bug。

Maat架構(gòu)

Maat架構(gòu)：

業(yè)務(wù)層

任何流程式調(diào)度及定時(shí)觸發(fā)的需求均可以通過Maat創(chuàng)建應(yīng)用，Maat提供了可視化編輯頁面及豐富的api，用戶可以方便地創(chuàng)建編輯流程模板，設(shè)置復(fù)雜的分支邏輯，Maat會(huì)在調(diào)度時(shí)按照運(yùn)行時(shí)的狀態(tài)決定流程的流轉(zhuǎn)路徑。

目前接入Maat的應(yīng)用場(chǎng)景包括Tisplus、Hawkeye、Kmon、容量平臺(tái)、離線組件平臺(tái)、Opensearch

管控層

由于原生Airflow的管控比較簡(jiǎn)單，是基于描述任務(wù)流程dag的Python腳本調(diào)度，用戶要進(jìn)行任務(wù)的創(chuàng)建、更新、運(yùn)行需要深入學(xué)習(xí)Airflow原理才能上手，并且之后維護(hù)只能基于文件操作，非常不便。因此Maat在外層封裝一層管控系統(tǒng)Maat Console，降低運(yùn)維及用戶學(xué)習(xí)的成本。

下圖是Maat管控系統(tǒng)Aflow的操作界面：

★ 模板管理

在任務(wù)流程調(diào)度的場(chǎng)景中，常見的情況是：不同任務(wù)執(zhí)行的流程基本一致，只有個(gè)別參數(shù)不同。因此Maat提出了基于模板管理的任務(wù)流程，用戶在模板管理中定義一個(gè)流程的運(yùn)行模板，對(duì)于其中未確定的部分用變量表示。當(dāng)生成具體任務(wù)時(shí)，由具體變量和模板渲染出具體的任務(wù)。當(dāng)模板修改時(shí)，可以將模板生效到所有依賴該模板的任務(wù)。

模板管理預(yù)設(shè)了幾種任務(wù)節(jié)點(diǎn)，用戶可以自由選擇不同的任務(wù)節(jié)點(diǎn)組裝模板流程。

★ 應(yīng)用管理

管理所有具體的流程調(diào)度任務(wù)，包括任務(wù)使用的模板、變量的值、報(bào)警信息、任務(wù)觸發(fā)crontab等，用戶在通過模板創(chuàng)建應(yīng)用后，后續(xù)可以通過應(yīng)用管理繼續(xù)維護(hù)任務(wù)的運(yùn)行。

★ 隊(duì)列管理

由于Maat上運(yùn)行的任務(wù)所屬應(yīng)用各不相同，不同應(yīng)用運(yùn)行環(huán)境也不相同，另外不同應(yīng)用也希望達(dá)到集群隔離的目的。為了實(shí)現(xiàn)這個(gè)功能Maat提供了隊(duì)列的管理，指定隊(duì)列的任務(wù)節(jié)點(diǎn)會(huì)被調(diào)度到相應(yīng)隊(duì)列的機(jī)器上，相應(yīng)隊(duì)列的機(jī)器也只會(huì)運(yùn)行指定隊(duì)列的任務(wù)節(jié)點(diǎn)。

另外，隊(duì)列上也可以指定并發(fā)數(shù)，表示當(dāng)前隊(duì)列上最多同時(shí)有多少個(gè)任務(wù)運(yùn)行，確保機(jī)器上同時(shí)運(yùn)行的任務(wù)不會(huì)太多導(dǎo)致負(fù)載過高，超出并發(fā)的任務(wù)會(huì)被掛起直到資源釋放。

核心模塊

Maat核心模塊完成了任務(wù)調(diào)度的整個(gè)流程。核心模塊的每個(gè)節(jié)點(diǎn)都獨(dú)立運(yùn)行在機(jī)器上，啟動(dòng)上互相不依賴，通過DB保存數(shù)據(jù)狀態(tài)，通過MQ或FaaS完成消息的分發(fā)。

★ Web Api Service

Web Api Service提供了豐富的與外部交互的Api，包括任務(wù)增刪改、歷史任務(wù)狀態(tài)、任務(wù)狀態(tài)修改、任務(wù)的觸發(fā)、任務(wù)的重試等接口。

另外原生Airflow提供的web展示功能也是由該角色完成。

★ Scheduler

scheduler是Maat關(guān)鍵角色，它決定了任務(wù)何時(shí)被調(diào)度運(yùn)行，也決定一次任務(wù)運(yùn)行中，哪些節(jié)點(diǎn)可以被執(zhí)行。被判定執(zhí)行的節(jié)點(diǎn)會(huì)被scheduler通過MQ或FaaS發(fā)送給worker執(zhí)行。

隨著任務(wù)的增多，單一的scheduler負(fù)載過高導(dǎo)致調(diào)度周期增長(zhǎng)，為了減輕scheduler的壓力，Maat將scheduler按照業(yè)務(wù)拆分。不同業(yè)務(wù)的任務(wù)有獨(dú)立的scheduler負(fù)責(zé)調(diào)度，發(fā)送任務(wù)到指定的Worker上。

★ Scheduler性能優(yōu)化

原生Airflow的調(diào)度邏輯吞吐量較低，當(dāng)任務(wù)量增多時(shí)，調(diào)度周期會(huì)很長(zhǎng)，一些任務(wù)多的Scheduler延遲到達(dá)1分鐘左右。我們參考社區(qū)最新的實(shí)現(xiàn)，對(duì)原生調(diào)度邏輯進(jìn)行優(yōu)化，將原先阻塞的調(diào)度方式拆分為多個(gè)進(jìn)程池，全異步地完成可執(zhí)行任務(wù)的生產(chǎn)->提交->輪詢操作。經(jīng)過壓測(cè)原先調(diào)度周期為30s-40s的場(chǎng)景降低為5s左右。

★ Worker

worker為具體執(zhí)行任務(wù)的角色，worker會(huì)接受scheduler發(fā)出的任務(wù)，在worker上執(zhí)行節(jié)點(diǎn)中描述的具體任務(wù)。worker多副本部署，任務(wù)會(huì)在任意一個(gè)對(duì)等的worker上機(jī)器，當(dāng)worker資源不足時(shí)，可以動(dòng)態(tài)擴(kuò)容。

由于不同隊(duì)列任務(wù)所需的基礎(chǔ)環(huán)境不同，如Python、Java、Hadoop、zk等，不同隊(duì)列的worker角色啟動(dòng)參數(shù)有配置上的差異，不同隊(duì)列的worker啟動(dòng)時(shí)會(huì)按照配置中描述的資源完成部署安裝。

worker上任務(wù)完成后會(huì)回寫db，scheduler察覺到當(dāng)前任務(wù)狀態(tài)變化后會(huì)繼續(xù)任務(wù)的調(diào)度。

★ Distributers

任務(wù)分發(fā)層負(fù)責(zé)將scheduler需要調(diào)度的任務(wù)發(fā)送到指定的Worker上。目前Maat同時(shí)使用原生Celery+Rabbitmq的方式和搜索生態(tài)FaaS的方式實(shí)現(xiàn)任務(wù)分發(fā)。

★ Celery + RabbitMQ

原生Airflow使用Celery + RabbitMQ完成消息從Scheduler到Worker的分發(fā)。

Scheduler將需要運(yùn)行的任務(wù)發(fā)送到MQ中，發(fā)送到MQ中包含任務(wù)對(duì)應(yīng)的隊(duì)列信息。Worker從MQ獲取消息時(shí)，僅獲取相應(yīng)隊(duì)列任務(wù)，拉取到對(duì)應(yīng)Worker上執(zhí)行。MQ在Maat中以rabbitmq實(shí)現(xiàn)，MQ和其他角色一樣，也是獨(dú)立部署的。

Celery + Rabbitmq的模型對(duì)消息隊(duì)列中的任務(wù)進(jìn)行持久化，所有的任務(wù)狀態(tài)也進(jìn)行持久化，內(nèi)存Queue的性能滿足大部分場(chǎng)景的需求。但由于Maat基于二層調(diào)度Drogo部署，任何部署節(jié)點(diǎn)都要求無狀態(tài)的，而消息隊(duì)列MQ因?yàn)楸４嫦顟B(tài)顯然不滿足這個(gè)要求，所以我們選擇使用搜索生態(tài)的FaaS框架作為Celery + RabbitMQ的替代方案。

★ FaaS

FaaS：FaaS（Function as a Service）是基于搜索生態(tài)實(shí)現(xiàn)的ServerLess框架，Maat將其作為執(zhí)行器。Maat的所有任務(wù)都抽象成function，任務(wù)執(zhí)行時(shí)則調(diào)用相應(yīng)的function，完成后返回任務(wù)狀態(tài)。目前已完成與FaaS的初步對(duì)接，期望未來能基于FaaS做更多優(yōu)化。如：多樣化的任務(wù)執(zhí)行方式，可以將輕量級(jí)的任務(wù)函數(shù)化，將重量級(jí)的任務(wù)服務(wù)化；任務(wù)資源動(dòng)態(tài)調(diào)整，甚至某些任務(wù)可以執(zhí)行時(shí)分配資源，完成后即釋放。

對(duì)于Maat來講，FaaS支持任務(wù)從生產(chǎn)者到消費(fèi)者的分發(fā)，內(nèi)置消息Queue，提供任務(wù)狀態(tài)接口，同時(shí)FaaS自身保證消息不對(duì)丟失，后續(xù)還具備根據(jù)消費(fèi)者負(fù)載自動(dòng)擴(kuò)縮容的功能。

★ 基礎(chǔ)組件

• DB：使用集團(tuán)IDB，負(fù)責(zé)Maat信息的持久化，包括任務(wù)信息、任務(wù)運(yùn)行歷史、任務(wù)運(yùn)行狀態(tài)、節(jié)點(diǎn)運(yùn)行歷史、節(jié)點(diǎn)運(yùn)行狀態(tài)等。
• OSS：由于上drogo導(dǎo)致機(jī)器遷移的風(fēng)險(xiǎn)，所有日志不能存放在本地，因此所有節(jié)點(diǎn)運(yùn)行日志存放在oss上，需要查看日志上從oss上獲取。
• Kmon：完成監(jiān)控集群運(yùn)行狀態(tài)及任務(wù)失敗的報(bào)警功能。
• Drogo：完成Maat所有節(jié)點(diǎn)的docker容器化部署。

Maat平臺(tái)的優(yōu)勢(shì)

可視化編輯及通用的節(jié)點(diǎn)類型

Maat提供了一個(gè)管控平臺(tái)Aflow，用戶可以方便地編輯流程節(jié)點(diǎn)，管理所有的模板和任務(wù)，詳細(xì)見上文的[管控層]。

除此之外，Maat還提供了豐富的通用節(jié)點(diǎn)類型。原生Airflow支持許多不同種類的節(jié)點(diǎn)類型，這些節(jié)點(diǎn)可以執(zhí)行不同類型的任務(wù)。在與用戶的接觸中，Maat針對(duì)用戶的使用習(xí)慣與需求，對(duì)一些節(jié)點(diǎn)進(jìn)行封裝，同時(shí)開發(fā)了幾種新的節(jié)點(diǎn)類型，可以滿足大部分用戶的需求。

• Bash節(jié)點(diǎn)：直接在worker上執(zhí)行簡(jiǎn)單的bash操作，由于bash通常需要依賴其他資源，實(shí)際使用較少，參照“帶資源的Bash節(jié)點(diǎn)”；
• Http節(jié)點(diǎn)：該節(jié)點(diǎn)支持http調(diào)用，調(diào)度時(shí)發(fā)送http請(qǐng)求觸發(fā)其他系統(tǒng)，同時(shí)該節(jié)點(diǎn)提供一個(gè)輪詢的http接口，觸發(fā)成功后輪詢其他系統(tǒng)是否成功，成功時(shí)才繼續(xù)運(yùn)行；
• 帶資源的Bash節(jié)點(diǎn)：與普通Bash節(jié)點(diǎn)不同的是，該節(jié)點(diǎn)附帶一些資源（如jar包、bash腳本、Python腳本等），節(jié)點(diǎn)運(yùn)行時(shí)會(huì)先將資源下載到本地，然后執(zhí)行bash腳本；
• 分支節(jié)點(diǎn)：該節(jié)點(diǎn)根據(jù)之前節(jié)點(diǎn)的運(yùn)行結(jié)果或初始傳入的參數(shù)決定分之后的節(jié)點(diǎn)走哪個(gè)分支。

Drogo化部署

Maat服務(wù)有多種角色，每種角色都需要不同的運(yùn)行環(huán)境，為了維護(hù)這些運(yùn)行環(huán)境，對(duì)運(yùn)維同學(xué)來說絕對(duì)是個(gè)噩夢(mèng)，這種情況下上hippo成為Maat運(yùn)維最好的選擇。drogo作為基于二層調(diào)度服務(wù)的管控平臺(tái)，為Maat各個(gè)節(jié)點(diǎn)部署在hippo上成為可能。具體來說，Drogo化的優(yōu)勢(shì)如下：

• 低成本增加新節(jié)點(diǎn)。上Drogo前，有新增節(jié)點(diǎn)的需求時(shí)，每次都需要準(zhǔn)備運(yùn)行資源，重新寫部署腳本，而每個(gè)節(jié)點(diǎn)的腳本都要運(yùn)維同學(xué)自己維護(hù)。上Drogo后，所有這些部署信息保存在Drogo平臺(tái)上，有新的的節(jié)點(diǎn)也只需要將之前類似的部署信息復(fù)制，稍加修改即可。
• 擴(kuò)容簡(jiǎn)單。上Drogo前，某類任務(wù)水位太高，為這類任務(wù)擴(kuò)容，每次都需要準(zhǔn)備機(jī)器、準(zhǔn)備環(huán)境、調(diào)試運(yùn)行參數(shù)，可能需要半天到一天的時(shí)間。上Drogo后，調(diào)整副本數(shù)，Drogo會(huì)自動(dòng)擴(kuò)容。
• 有效防止機(jī)器遷移帶來的服務(wù)中斷。上Drogo前，機(jī)器出現(xiàn)問題后，只能另找機(jī)器擴(kuò)容，對(duì)于某些只能單點(diǎn)運(yùn)行的節(jié)點(diǎn)，只能燒香祈禱機(jī)器不掛了。上Drogo后，機(jī)器遷移后，會(huì)Drogo會(huì)自動(dòng)分配一臺(tái)機(jī)器將服務(wù)拉起，對(duì)于可中斷的服務(wù)，單節(jié)點(diǎn)部署也不用擔(dān)心機(jī)器掛了導(dǎo)致服務(wù)消失了。

下圖展示了目前Drogo上部署的Maat各個(gè)角色：

由于原生Airflow的一些節(jié)點(diǎn)是有狀態(tài)的，需要依賴本地一些文件，機(jī)器遷移會(huì)導(dǎo)致這些節(jié)點(diǎn)的狀態(tài)丟失，我們對(duì)Maat做了一些修改，保證機(jī)器遷移不會(huì)丟失運(yùn)行狀態(tài)：

• 之前的調(diào)度依賴本地Python dag文件，機(jī)器遷移導(dǎo)致本地文件丟失。我們做了修改，所有dag保存在db，依賴db中保存的信息調(diào)度，保證機(jī)器遷移后，dag信息也不會(huì)丟失。
• 由于基于本地文件，web service和scheduler讀寫的都是同一份dag文件，導(dǎo)致原生Airflow的scheduler和web service角色必須綁定運(yùn)行。以db中信息調(diào)度后，web service和scheduler可以單獨(dú)部署。
• 由于原來日志文件保存在本地，機(jī)器遷移會(huì)導(dǎo)致日志文件丟失。我們改造后，將日志文件保存在oss遠(yuǎn)端，每次讀取日志從遠(yuǎn)端讀取。

分集群管理

由于不同任務(wù)隔離的需求，Maat基于Airflow原生的隊(duì)列管理擴(kuò)展不同任務(wù)的集群管理功能，不同類型的任務(wù)可以創(chuàng)建自己的scheduler和worker，創(chuàng)建應(yīng)用時(shí)可以使用指定的scheduler調(diào)度或運(yùn)行在指定worker上（如果不指定由默認(rèn)scheduler和worker調(diào)度）。

集群的配置參數(shù)包括以下信息：

• worker部署配置：該worker依賴的資源，drogo啟動(dòng)時(shí)會(huì)將任務(wù)運(yùn)行需要的資源部署到worker機(jī)器上，機(jī)器遷移時(shí)也會(huì)使用這份部署配置重新分配資源。
• worker個(gè)數(shù)：控制worker角色的個(gè)數(shù)。
• 集群并發(fā)數(shù)：控制集群中正在運(yùn)行的并發(fā)數(shù)，防止任務(wù)運(yùn)行過多導(dǎo)致下游系統(tǒng)壓力過大。
• scheduler：目前每個(gè)集群只有一個(gè)scheduler，后續(xù)會(huì)改造成支持多個(gè)scheduler調(diào)度節(jié)點(diǎn)。

監(jiān)控&報(bào)警

★ 平臺(tái)監(jiān)控報(bào)警

為了掌握平臺(tái)的運(yùn)行狀況，Maat在各個(gè)節(jié)點(diǎn)的關(guān)鍵步驟向kmon匯報(bào)metric信息，metric異常狀態(tài)下會(huì)發(fā)送報(bào)警給開發(fā)同學(xué)。也可以根據(jù)這些metric信息判斷當(dāng)前集群的負(fù)載狀況，對(duì)任務(wù)負(fù)載較高的節(jié)點(diǎn)進(jìn)行優(yōu)化。

★ 任務(wù)報(bào)警

對(duì)于具體任務(wù)，Maat支持在每個(gè)任務(wù)節(jié)點(diǎn)運(yùn)行異常的情況下發(fā)送報(bào)警，如節(jié)點(diǎn)運(yùn)行異常、任務(wù)未按時(shí)運(yùn)行、任務(wù)運(yùn)行超時(shí)等。用戶可以在管控平臺(tái)設(shè)置報(bào)警條件及報(bào)警接收人。

平臺(tái)現(xiàn)狀

Maat是一個(gè)通用基于Dag的任務(wù)調(diào)度系統(tǒng)，服務(wù)于集團(tuán)內(nèi)部和云上的許多場(chǎng)景：

• 搜索中臺(tái)Tisplus：調(diào)度Tisplus的上線流程及其他需要定時(shí)觸發(fā)的任務(wù)；
• Hawkeye：定時(shí)調(diào)度Hawkeye的分析任務(wù)；
• 搜索監(jiān)控平臺(tái)Kmon：支持kmon的監(jiān)控托管服務(wù)及報(bào)警處理流程；
• 搜索容量預(yù)估平臺(tái)Torch：支持容量預(yù)估流程的管控；
• 搜索離線平臺(tái)Bahamut：支持離線組件平臺(tái)發(fā)布流程、全量流程；
• Opensearch：一些算法場(chǎng)景的離線任務(wù)；
• Tpp：推薦場(chǎng)景的流程調(diào)度任務(wù)。

Maat線上集群任務(wù)執(zhí)行現(xiàn)狀（2018.8.13數(shù)據(jù)）：

• 日均調(diào)度任務(wù)：3000+個(gè)
• 日均運(yùn)行任務(wù)：24K+次

隨著更多應(yīng)用場(chǎng)景的接入，平臺(tái)能力將會(huì)接受進(jìn)一步的考驗(yàn)。

未來展望

隨著業(yè)務(wù)的接入和數(shù)據(jù)規(guī)模的增大，Maat平臺(tái)也需要進(jìn)一步提升用戶體驗(yàn)，提升平臺(tái)穩(wěn)定性。

• 與Aflow進(jìn)一步結(jié)合，在管控平臺(tái)上一站式完成集群的創(chuàng)建、配置、部署。
• 提供更加豐富的報(bào)警選項(xiàng)，進(jìn)一步加強(qiáng)錯(cuò)誤的反饋機(jī)制。
• 隨著任務(wù)數(shù)量的增多，一些調(diào)度上的缺陷逐漸體現(xiàn)出來，對(duì)于這些缺陷做進(jìn)一步優(yōu)化。
• 和FaaS深度合作，為各類任務(wù)創(chuàng)建單獨(dú)的FaaS服務(wù)，降低資源利用率。

加入我們

搜索中臺(tái)從0到1建設(shè)已經(jīng)走過了3年，但它離我們心目中讓天下沒有難用的搜索的遠(yuǎn)大愿景還離的非常遠(yuǎn)，在這個(gè)前行的道路上一定會(huì)充滿挑戰(zhàn)，無論是業(yè)務(wù)視角的SaaS化能力、搜索算法產(chǎn)品化、云端devops&aiops，還是業(yè)務(wù)建站等都將遇到世界級(jí)的難題等著我們?nèi)ヌ魬?zhàn)。

所以，無論是web開發(fā)，引擎開發(fā)還是算法同學(xué)，

歡迎訪問：https://job.alibaba.com/zhaopin/position_detail.htm?trace=qrcode_share&positionCode=GP037395

加入阿里搜索中臺(tái)團(tuán)隊(duì)我們一起做最牛X的搜索中臺(tái)，讓天下沒有難用的搜索。

?

每天一篇技術(shù)文章，

看不過癮？

關(guān)注“阿里巴巴機(jī)器智能”，

發(fā)現(xiàn)更多AI干貨。

總結(jié)

以上是生活随笔為你收集整理的深度解析 | 基于DAG的分布式任务调度平台：Maat的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。