基于Mesos的當(dāng)當(dāng)作業(yè)云Elastic Job Cloud

責(zé)任編輯:editor006

作者:張亮

2016-09-19 17:09:11

摘自:INFOQ

常駐作業(yè)是作業(yè)一旦啟動,無論運(yùn)行與否均占用系統(tǒng)資源;瞬時作業(yè)是在作業(yè)啟動時占用資源,運(yùn)行完成后釋放資源。瞬時作業(yè)適合初始化時間短、觸發(fā)間隔長、允許延遲的作業(yè),一般用于資源不太充分,或作業(yè)要求的資源多,適合資源錯峰使用的場景。

作業(yè)在互聯(lián)網(wǎng)電商行業(yè)中是很常見的技術(shù)手段。當(dāng)當(dāng)具有成千上萬的作業(yè)規(guī)模,大致分為業(yè)務(wù)類,歸檔類,監(jiān)控類和大數(shù)據(jù)類。

當(dāng)當(dāng)原有的作業(yè)解決方案是Elastic Job,以下稱為Elastic Job 1.X。主要關(guān)注以下4個方面:

高可用。這里高可用指主從熱備。主節(jié)點(diǎn)提供服務(wù)的同時從節(jié)點(diǎn)處于等待狀態(tài)。一旦主節(jié)點(diǎn)失效,其中一個從節(jié)點(diǎn)通過選舉成為主節(jié)點(diǎn)繼續(xù)提供服務(wù),原來的主節(jié)點(diǎn)再次生效后,作為從節(jié)點(diǎn)繼續(xù)等待選舉機(jī)會。線性擴(kuò)展。可理解為高可用的高階功能。既然多節(jié)點(diǎn)參與服務(wù)提供,若從節(jié)點(diǎn)只負(fù)責(zé)熱備,難免造成資源浪費(fèi),將主備調(diào)整為分片,則可大幅提升處理能力。中心化分布 式服務(wù)基本都是提供獨(dú)立的調(diào)度中心和執(zhí)行節(jié)點(diǎn),調(diào)度中心提供主備,執(zhí)行節(jié)點(diǎn)可以彈性的線性擴(kuò)展。Elastic Job1.X采用無中心化架構(gòu),并無調(diào)度中心,而是各個執(zhí)行節(jié)點(diǎn)通過Zookeeper選舉主節(jié)點(diǎn)進(jìn)行分片、清理等動作,作業(yè)調(diào)度由執(zhí)行節(jié)點(diǎn)自行觸發(fā)。Elastic Job 1.X通過分片進(jìn)行線性擴(kuò)展,每個執(zhí)行節(jié)點(diǎn)負(fù)責(zé)處理被分配到的分片項(xiàng),應(yīng)用開發(fā)者負(fù)責(zé)分片項(xiàng)和業(yè)務(wù)邏輯的對應(yīng)關(guān)系。代碼示例: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: ... } }}容錯性。主要包括節(jié)點(diǎn)失效重分片、失效轉(zhuǎn)移、錯過任務(wù)重執(zhí)行以及分布式場景下的腦裂,網(wǎng)絡(luò)抖動容錯等。異構(gòu)語言。Elastic Job支持Java和Shell,基本能做到異構(gòu)語言支持。

Elastic Job 的核心組件圖如下:

綠色部分是Elastic Job 1.X對開發(fā)者提供的API。藍(lán)色部分為內(nèi)部實(shí)現(xiàn),主要有選舉模塊、分片模塊、調(diào)度模塊、持久化模塊以及分布式協(xié)調(diào)模塊。持久化和協(xié)調(diào)均基于Zookeeper。

部署架構(gòu)圖如下:

Elastic Job 1.X與應(yīng)用代碼部署在一起,作為lib提供服務(wù)。Elastic Job 1.X和運(yùn)維平臺通過注冊中心進(jìn)行交互。

花了這些篇幅介紹背景,目的是讓大家了解當(dāng)當(dāng)原有的分布式作業(yè)解決方案,接下來將闡述新一代的平臺化作業(yè)解決方案。

隨著時代發(fā)展進(jìn)步,分布式操作系統(tǒng)、容器以及各式各樣的容器編排治理方案層出不窮,站在巨人的肩膀上,可以更快速穩(wěn)定的搭建云平臺,基于這樣的考慮,我們決定擁抱革新。我們首先將目光投在了Docker上,希望將Elastic Job容器化,然后再選擇一個容器治理方案。經(jīng)過調(diào)研,我們轉(zhuǎn)而傾心Mesos,因?yàn)槲覀兊哪繕?biāo)不是容器化,而是云化,容器是實(shí)現(xiàn)云的一種手段,但合理的分布式編排系統(tǒng)更加關(guān)鍵。Docker本身有網(wǎng)絡(luò)、日志采集等問題需要解決。而Mesos將Docker作為可選容器支持,為了最小化采用新技術(shù)帶來的風(fēng)險,我們決定將Docker容器化推遲,先將Elastic Job遷移至Mesos。這也得益于Mesos對Docker的無縫支持,以后加入對Docker的支持非常容易。

下圖是Mesos的核心概念:

藍(lán)色是Mesos的基礎(chǔ)組件,由Mesos Master、Mesos Agent和運(yùn)維界面/API組成。Master/Agent的形式在分布式系統(tǒng)中很常見,如Hadoop map-reduce的JobTracker/TaskTacker。Mesos Master節(jié)點(diǎn)通過Zookeeper實(shí)現(xiàn)高可用,用于分配資源至注冊在Mesos的 Framework,Mesos Agent用于收集宿主機(jī)資源,如可用CPU、內(nèi)存、甚至GPU等,并負(fù)責(zé)執(zhí)行Mesos Framework分發(fā)的任務(wù)。Mesos Master與Slave間使用內(nèi)部API交互,通過遠(yuǎn)程執(zhí)行部署在Mesos Agent的程序無需Mesos Agent所在服務(wù)器提供免登錄賬號。

紫色是Mesos Framework的組成部分。Mesos只有基礎(chǔ)組件并不能獨(dú)立使用,需要注冊Framework接收Mesos Master分配的資源并決定如何執(zhí)行,目前常見的Marathon和Chronos都是Mesos Framework。Framework的兩個重要組成是Scheduler和Executor。Scheduler和Mesos Master通過Scheduler API交互,負(fù)責(zé)將分配的資源生成任務(wù)并分發(fā)。Executor通過Executor API與Mesos Agent交互,負(fù)責(zé)執(zhí)行分配的任務(wù)并回告狀態(tài)。

紅色是Scheduler中兩個最重要的回調(diào)方法,resourceOffers和statusUpdate。

resourceOffers用于將資源轉(zhuǎn)化為任務(wù)并調(diào)用Executor執(zhí)行。資源分配算法,任務(wù)業(yè)務(wù)邏輯都應(yīng)在此方法中實(shí)現(xiàn)。

statusUpdate用于處理Executor回傳的狀態(tài)??赏ㄟ^Executor的狀態(tài)傳遞和Scheduler的statusUpdate實(shí)現(xiàn)失效轉(zhuǎn)等的分布式協(xié)調(diào)功能。

Executor分為兩種。

Marathon和Chronos都使用Command Executor,這也是Mesos提供的內(nèi)置的Executor,可以直接執(zhí)行命令行腳本,也提供了基本的狀態(tài)回傳功能,對于普通應(yīng)用使用Command Executor是不錯的選擇。

自定義Executor可提供更多靈活性。下面舉幾個例子,但不限于僅實(shí)現(xiàn)這些功能。

日志重定向。Command Executor的日志會輸出到Mesos提供的沙箱中,通過自定義Executor可將日志重定向到其他文件,或?qū)悠渌罩臼占ぞ摺?strong>多任務(wù)復(fù)用。Command Executor與任務(wù)是一對一的關(guān)系。有些初始化資源非常耗時的場景,可以復(fù)用Executor,多線程并發(fā)處理多任務(wù)。執(zhí)行進(jìn)度報告。Command Executor僅回告狀態(tài)變化,如需更加細(xì)化進(jìn)度回告功能,需定制化處理。心跳檢測??梢酝ㄟ^Executor定時傳遞消息做心跳檢測。

簡單的介紹了Mesos,是該討論下Mesos能帶來什么好處的時候了。Mesos可作為部署平臺和運(yùn)行平臺使用。

作為部署平臺,Mesos可以做到應(yīng)用分發(fā)自動化。將應(yīng)用上傳到網(wǎng)絡(luò)地址(或Docker倉庫),Mesos能夠自動將應(yīng)用分發(fā)至需要執(zhí)行相關(guān)任務(wù)的Mesos Agent,省去人工部署成本。由于應(yīng)用自動分發(fā),那么CMDB將大大簡化,只需要管理Zookeeper服務(wù)器即可,Mesos Master、Mesos Agent以及其他部署在Mesos內(nèi)部的應(yīng)用均可用Mesos界面統(tǒng)一管理。美中不足是Mesos目前缺乏管理數(shù)據(jù)類服務(wù)器的成功案例,數(shù)據(jù)庫等部署在Mesos之外的應(yīng)用仍需獨(dú)立的CMDB管理。

作為運(yùn)行平臺,Mesos可以將資源收集至統(tǒng)一資源池,做到硬件資源與應(yīng)用一體化,按需分配資源,自動資源回收,減少資源閑置和浪費(fèi)。

應(yīng)用分發(fā)、資源分配和安全管理,即可形成云平臺的雛形,由于當(dāng)當(dāng)僅搭建私有云,安全管理暫時不是重點(diǎn)。

現(xiàn)在再分析Elastic Job 1.X的解決方案,應(yīng)用分發(fā)和資源分配部分是缺失的。

決定基于Mesos搭建作業(yè)云,我們開始調(diào)研實(shí)現(xiàn)方案。首先想到自然是擁抱開源,不重復(fù)發(fā)明輪子。方案A是使用Marathon作為調(diào)度框架。

  方案A的優(yōu)點(diǎn)是可以實(shí)現(xiàn)應(yīng)用分發(fā)和資源分配,并且是高可用的解決方案。

但缺點(diǎn)同樣明顯:

資源分配靜態(tài)化,作業(yè)無論執(zhí)行與否均需預(yù)分配資源;Executor無法復(fù)用,對于Elastic Job這種對內(nèi)部狀態(tài)報告有要求的框架,需要在框架中通過第三方存儲匯報狀態(tài);跨機(jī)房等定制化功能較困難;使用繁瑣,需要使用Mesos、Marathon和Elastic Job 3個管理界面。

另一種類似的方案是使用Chronos,可以做到動態(tài)資源分配,但缺點(diǎn)是:

不支持CRON表達(dá)式,對于原crontab或Quartz的應(yīng)用遷移不友好;不適合低延遲作業(yè),每次啟動初始化資源會消耗時間,導(dǎo)致作業(yè)延遲,反復(fù)初始化也容易造成資源浪費(fèi);定制功能仍然困難。

說到這里需要拋出常駐作業(yè)和瞬時作業(yè)概念了。

常駐作業(yè)是作業(yè)一旦啟動,無論運(yùn)行與否均占用系統(tǒng)資源;瞬時作業(yè)是在作業(yè)啟動時占用資源,運(yùn)行完成后釋放資源。

常駐作業(yè)適合初始化時間長、觸發(fā)間隔短、實(shí)時性要求高的作業(yè),要求資源配備充足。

瞬時作業(yè)適合初始化時間短、觸發(fā)間隔長、允許延遲的作業(yè),一般用于資源不太充分,或作業(yè)要求的資源多,適合資源錯峰使用的場景。

由于上述缺點(diǎn),我們最終選擇方案B。

  我們決定自行開發(fā)Mesos Framework,項(xiàng)目的名稱叫做Elastic Job Cloud。優(yōu)點(diǎn):

包含方案A的全部優(yōu)點(diǎn);資源分配靜態(tài)與動態(tài)相結(jié)合,常駐與瞬時作業(yè)分離處理;Elastic Job 1.X的核心理念仍可沿用,包括分片,以及之前未提及的功能,如多種作業(yè)類型,事件統(tǒng)計等;易于定制化需求開發(fā)。

Elastic Job Cloud核心組件圖如下:

綠色的API部分變化不大;紅色的內(nèi)部實(shí)現(xiàn)部分,無論是模塊本身,還是模塊的內(nèi)部實(shí)現(xiàn)均有大幅度調(diào)整。

選舉模塊由執(zhí)行節(jié)點(diǎn)主節(jié)點(diǎn)選舉變更為主Mesos Framework選舉,仍然依賴Zookeeper。

Sharding模塊功能未變,但從執(zhí)行節(jié)點(diǎn)主節(jié)點(diǎn)分片調(diào)整為Mesos Framework集中分片。Elastic Job 1.X的分片以IP為依據(jù),Elastic Job Cloud更改為以運(yùn)行任務(wù)實(shí)例為依據(jù)。

調(diào)度引擎從去中心化執(zhí)行節(jié)點(diǎn)調(diào)度轉(zhuǎn)變?yōu)镸esos Framework的中心節(jié)點(diǎn)調(diào)度。

通過調(diào)度作業(yè)向任務(wù)隊(duì)列中寫入待執(zhí)行作業(yè)。

日志輸出方式變更為事件發(fā)布,可自行監(jiān)聽發(fā)布的事件,收集Elastic Job Cloud的運(yùn)行狀態(tài),默認(rèn)提供日志和數(shù)據(jù)庫(推薦)兩種事件收集方式。

通過Executor和Scheduler API配合進(jìn)行分布式協(xié)調(diào),替換通過Zookeeper協(xié)調(diào)的方案,有效的減少了與Zookeeper的連接數(shù)。

Elastic Job Cloud作為Mesos Framework獨(dú)立部署,將作業(yè)信息存入Zookeeper。

雖然Elastic Job Cloud可以提供中心化云解決方案,但Elastic Job 1.X作為無中心化解決方案,仍適用于中小規(guī)模的分布式作業(yè)調(diào)度場景。我們并未放棄Elastic Job 1.X,將其更名為Elastic Job Lite。Elastic Job Lite和Elastic Job Cloud共同組成Elastic Job,核心組件全景圖如下:

Elastic Job Lite和Elastic Job Cloud使用統(tǒng)一的Elastic Job API,開發(fā)者在開發(fā)時無需關(guān)心最終的部署方式。部署在Lite或Cloud環(huán)境無需修改業(yè)務(wù)作業(yè)代碼,秩序調(diào)整配置和啟動方式即可。Lite和Cloud的差別僅在于云平臺需要的應(yīng)用分發(fā)和資源調(diào)度一體化。

目前Elastic Job Cloud已開發(fā)完成并在公司內(nèi)部試用。日前對接監(jiān)控系統(tǒng)的萬余作業(yè),全天運(yùn)行峰值百萬左右。

Elastic Job Cloud的roadmap是:

公司內(nèi)部大規(guī)模推廣使用;Docker支持;任務(wù)優(yōu)先級、依賴以及編排的支持;跨機(jī)房部署、物理機(jī)隔離等功能開發(fā)。

目前Elastic Job已全部開源。項(xiàng)目地址,歡迎感興趣的人踴躍嘗試。

最后我分享下我們這4個月以來的里程碑。

本文由當(dāng)當(dāng)網(wǎng)架構(gòu)專家張亮在CNUTCon北京2016 全球容器技術(shù)大會上的演講整理而成。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號