最近在做一個(gè)類似的東西，看了一篇講FuxiSort的paper，就去詳細(xì)學(xué)習(xí)了下。

paper鏈接:

鏈接: https://pan.baidu.com/s/1H9GdDd7lgcgWkw0tkC95Jw 提取碼: gix8

---

下文作者：陶陽宇，花名舉水，阿里云高級(jí)技術(shù)專家，飛天分布式系統(tǒng)早期核心開發(fā)人員，開發(fā)和優(yōu)化過伏羲系統(tǒng)中多個(gè)功能模塊，參加了飛天5K、世界排序大賽等多個(gè)技術(shù)攻堅(jiān)項(xiàng)目。在分布式計(jì)算、高并發(fā)系統(tǒng)的設(shè)計(jì)和開發(fā)方面有較豐富的經(jīng)驗(yàn)。

本文涉及阿里云分布式調(diào)度團(tuán)隊(duì)在分布式調(diào)度系統(tǒng)的設(shè)計(jì)、實(shí)現(xiàn)、優(yōu)化等方面的實(shí)踐以及由此總結(jié)的分布式系統(tǒng)設(shè)計(jì)的一般性原則，具體包括分布式調(diào)度的任務(wù)調(diào)度、資源調(diào)度、容錯(cuò)機(jī)制、規(guī)模挑戰(zhàn)、安全與性能隔離以及未來發(fā)展方向六部分。

云計(jì)算并不是無中生有的概念，它將普通的單臺(tái)PC計(jì)算能力通過分布式調(diào)度軟件連接起來。其最核心的問題是如何把一百臺(tái)、一千臺(tái)、一萬臺(tái)機(jī)器高效地組織起來，靈活進(jìn)行任務(wù)調(diào)度和管理，從而可以像使用臺(tái)式機(jī)一樣使用云計(jì)算。在云計(jì)算中，最核心的模塊是分布式調(diào)度，它好比云計(jì)算的中央處理器。目前，業(yè)界已存在多種分布式調(diào)度實(shí)現(xiàn)方案，如伏羲、Hadoop MapReduce、YARN、Mesos等系統(tǒng)。

阿里云伏羲

伏羲系統(tǒng)在前人的基礎(chǔ)上進(jìn)行了一系列改造，首先與YARN和Mesos系統(tǒng)類似，將資源的調(diào)度和任務(wù)調(diào)度分離，形成兩層架構(gòu)，使其具備以下優(yōu)勢(shì)：

規(guī)模：兩層架構(gòu)易于橫向擴(kuò)展，資源管理和調(diào)度模塊僅負(fù)責(zé)資源的整體分配，不負(fù)責(zé)具體任務(wù)調(diào)度，可以輕松擴(kuò)展集群節(jié)點(diǎn)規(guī)模；
容錯(cuò)：當(dāng)某個(gè)任務(wù)運(yùn)行失敗不會(huì)影響其他任務(wù)的執(zhí)行；同時(shí)資源調(diào)度失敗也不影響任務(wù)調(diào)度；
擴(kuò)展性：不同的計(jì)算任務(wù)可以采用不同的參數(shù)配置和調(diào)度策略，同時(shí)支持資源搶占；
調(diào)度效率：計(jì)算framework決定資源的生命周期，可以復(fù)用資源，提高資源交互效率。
這套系統(tǒng)目前已經(jīng)在阿里集團(tuán)進(jìn)行了大范圍的應(yīng)用，能支持單集群5000節(jié)點(diǎn)、并發(fā)運(yùn)行10000作業(yè)、30分鐘完成100T數(shù)據(jù)terasort，性能是Yahoo在Sort Benchmark的世界紀(jì)錄的兩倍。

伏羲的系統(tǒng)架構(gòu)

伏羲的系統(tǒng)架構(gòu)如圖1所示，整個(gè)集群包括一臺(tái)Fuxi Master以及多臺(tái)Tubo。其中Fuxi Master是集群的中控角色，負(fù)責(zé)資源的管理和調(diào)度；Tubo是每臺(tái)機(jī)器上都有的一個(gè)Agent，負(fù)責(zé)管理本臺(tái)機(jī)器上的用戶進(jìn)程；同時(shí)集群中還有一個(gè)叫Package Manager的角色，因?yàn)橛脩舻目蓤?zhí)行程序以及一些配置需要事先打成一個(gè)壓縮包并上傳到Package Manager上，Package Manager專門負(fù)責(zé)集群中包的分發(fā)。

集群部署完后，用戶通過Client端的工具向Fuxi Master提交計(jì)算任務(wù)；Fuxi Master接收到任務(wù)后首先通知某一個(gè)Tubo啟動(dòng)這個(gè)計(jì)算任務(wù)所對(duì)應(yīng)的APP Master；APP Master啟動(dòng)之后，它獲知了自己的計(jì)算任務(wù)，包括數(shù)據(jù)分布在哪里、有多少的任務(wù)需要計(jì)算等等信息；接著APP Master會(huì)向Fuxi Master提交資源申請(qǐng)，表明它需要多少計(jì)算資源；Fuxi Master經(jīng)過資源調(diào)度以后，將資源的分配結(jié)果下發(fā)給APP Master；APP Master在這個(gè)資源的基礎(chǔ)之上進(jìn)行它的任務(wù)調(diào)度，來決定哪些機(jī)器上運(yùn)行哪些計(jì)算任務(wù)，并且將這個(gè)計(jì)算任務(wù)發(fā)送給對(duì)應(yīng)機(jī)器上的Tubo進(jìn)程；Tubo接受到命令之后就會(huì)從Package Manager中下載對(duì)應(yīng)的可執(zhí)行程序并解壓；然后啟動(dòng)用戶的可執(zhí)行程序，加載用戶的配置（圖1中的APP Worker）；APP Worker根據(jù)配置中的信息讀取文件存儲(chǔ)系統(tǒng)中的數(shù)據(jù)，然后進(jìn)行計(jì)算并且將計(jì)算結(jié)果發(fā)往下一個(gè)APP Worker。其中，數(shù)據(jù)的切片稱之為Instance或者叫計(jì)算實(shí)例。

Fuxi Master與Tubo這套結(jié)構(gòu)解決了分布式調(diào)度中的資源調(diào)度，每個(gè)計(jì)算任務(wù)的APP Master以及一組APP Worker組合起來解決任務(wù)調(diào)度的問題。

任務(wù)調(diào)度

伏羲在進(jìn)行任務(wù)調(diào)度時(shí)，主要涉及兩個(gè)角色：計(jì)算框架所需的APP Master以及若干個(gè)APP Worker。

APP Master首先向Fuxi Master申請(qǐng)/釋放資源；拿到Fuxi Master分配的資源以后會(huì)調(diào)度相應(yīng)的APP Worker到集群中的節(jié)點(diǎn)上，并分配Instance（數(shù)據(jù)切片）到APP Worker；APP Master同時(shí)還要負(fù)責(zé)APP Worker之間的數(shù)據(jù)傳遞以及最終匯總生成Job Status；同時(shí)為了達(dá)到容錯(cuò)效果，APP Master還要負(fù)責(zé)管理APP Worker的生命周期，例如當(dāng)發(fā)生故障之后它要負(fù)責(zé)重啟APP Worker。

而APP Worker的職責(zé)相對(duì)比較簡(jiǎn)單，首先它需要接收App Master發(fā)來的Instance，并執(zhí)行用戶計(jì)算邏輯；其次它需要不斷地向APP Master報(bào)告它的執(zhí)行進(jìn)度等運(yùn)行狀態(tài)；其最為主要的任務(wù)是負(fù)責(zé)讀取輸入數(shù)據(jù)，將計(jì)算結(jié)果寫到輸出文件；此處的Instance是指輸入數(shù)據(jù)的切片。伏羲任務(wù)調(diào)度系統(tǒng)的技術(shù)要點(diǎn)主要包括數(shù)據(jù)的Locality、數(shù)據(jù)的Shuffle以及Instance重試和Backup Instance三點(diǎn)。

數(shù)據(jù)Locality

數(shù)據(jù)Locality是指調(diào)度時(shí)要考慮數(shù)據(jù)的親近性，也就是說APP Worker在處理數(shù)據(jù)時(shí)，盡量從本地的磁盤讀取數(shù)據(jù)，輸出也盡量寫到本地磁盤，避免遠(yuǎn)程的讀寫。要實(shí)現(xiàn)這一目標(biāo)，在任務(wù)調(diào)度時(shí)，盡量讓Instance（數(shù)據(jù)分片）數(shù)據(jù)最多的節(jié)點(diǎn)上的AppWorker來處理該Instance。

數(shù)據(jù)Shuffle

數(shù)據(jù)Shuffle指的是APP Worker之間的數(shù)據(jù)傳遞。在實(shí)際運(yùn)行中，APP Worker之間是有多種傳遞形態(tài)的，如一對(duì)一、一對(duì)N、M對(duì)N等模式。如果用戶去處理不同形態(tài)的傳輸模式，勢(shì)必會(huì)帶來較大的代價(jià)。伏羲分布式調(diào)度系統(tǒng)將數(shù)據(jù)傳遞的過程封裝成streamline lib，用戶無需關(guān)心數(shù)據(jù)傳遞的細(xì)節(jié)。首先Map進(jìn)行運(yùn)算，將結(jié)果直接交給streamline，streamline底層會(huì)根據(jù)不同的配置將數(shù)據(jù)傳給下游計(jì)算任務(wù)的streamline；然后streamline將接到的數(shù)據(jù)交給上層的計(jì)算任務(wù)。

Instance重試和backup instance

在Instance的運(yùn)行過程中可能有多種原因?qū)е翴nstance失敗，比如APP Worker進(jìn)程重啟或運(yùn)行時(shí)機(jī)器、磁盤發(fā)生故障，種種原因都可能導(dǎo)致一個(gè)Instance在運(yùn)行時(shí)最終失敗；另外APP Master還會(huì)監(jiān)控Instance的運(yùn)行速度，如果發(fā)現(xiàn)Instance運(yùn)行非常慢（容易造成長(zhǎng)尾），會(huì)在另外的APP Worker上同時(shí)運(yùn)行該Instance，也就是同時(shí)有兩個(gè)APP Worker處理同一份數(shù)據(jù)，APP Master會(huì)選取最先結(jié)束的結(jié)果為最終結(jié)果。判斷一個(gè)Instance運(yùn)行緩慢的依據(jù)有：

該Instance運(yùn)行時(shí)間超過其他Instance的平均運(yùn)行時(shí)間；
該Instance數(shù)據(jù)處理速度低于其他Instance平均值；
目前已完成的Instance比例，防止在整體任務(wù)運(yùn)行初期發(fā)生誤判。

資源調(diào)度

資源調(diào)度要考慮幾個(gè)目標(biāo)：一是集群資源利用率最大化；二是每個(gè)任務(wù)的資源等待時(shí)間最小化；三是能分組控制資源配額；四是能支持臨時(shí)緊急任務(wù)。在飛天分布式系統(tǒng)中，Fuxi Master與Tubo兩者配合完成資源調(diào)度。

在飛天分布式系統(tǒng)中，Fuxi Master與Tubo兩者配合完成資源調(diào)度。Tubo是每個(gè)節(jié)點(diǎn)都有的，用于收集每個(gè)機(jī)器的硬件資源（CPU、Memory、Disk、Net），并發(fā)送給FuxiMaster；FuxiMaster是中控節(jié)點(diǎn)，負(fù)責(zé)整個(gè)集群的資源調(diào)度。當(dāng)啟動(dòng)計(jì)算任務(wù)時(shí)，會(huì)生成APP Master，它根據(jù)自己的需要向Fuxi Master申請(qǐng)資源，當(dāng)計(jì)算完成不再需要時(shí)，歸還該資源。

飛天分布式調(diào)度常用的分配資源策略包括優(yōu)先級(jí)和搶占、公平調(diào)度、配額。在實(shí)際應(yīng)用場(chǎng)景中，不同策略可配合起來使用。

策略之優(yōu)先級(jí)和搶占

每個(gè)Job在提交時(shí)會(huì)帶一個(gè)priority值（整數(shù)值），該值越小優(yōu)先級(jí)越高；相同優(yōu)先級(jí)按提交時(shí)間，先提交的優(yōu)先級(jí)高；FuxiMaster在調(diào)度時(shí)，資源優(yōu)先分配給高優(yōu)先級(jí)的Job，剩余的資源繼續(xù)分配給次高優(yōu)先級(jí)Job。

如果臨時(shí)有高優(yōu)先級(jí)的緊急任務(wù)加入，FuxiMaster會(huì)從當(dāng)前正在運(yùn)行的任務(wù)中，從最低優(yōu)先級(jí)任務(wù)開始強(qiáng)制收回資源，以分配給緊急任務(wù)，此過程稱為“搶占”。搶占遞歸進(jìn)行，直到被搶任務(wù)優(yōu)先級(jí)不高于緊急任務(wù)，也就是不能搶占比自己優(yōu)先級(jí)高的任務(wù)。

策略之公平調(diào)度

公平調(diào)度策略是指當(dāng)有資源時(shí)Fuxi Master依次輪詢地將部分資源分配給各個(gè)Job，它避免了較大Job搶占全部資源導(dǎo)致其他Job餓死現(xiàn)象發(fā)生。公平調(diào)度首先按優(yōu)先級(jí)分組，同一優(yōu)先級(jí)組內(nèi)的平均分配，如果有剩余資源再去下一個(gè)優(yōu)先級(jí)組進(jìn)行分配，依此類推。

配額

配額是資源分配時(shí)的第三個(gè)策略，通常是按照不同的業(yè)務(wù)進(jìn)行區(qū)分，多個(gè)任務(wù)組成一個(gè)組，例如淘寶、支付寶等；集群管理員會(huì)設(shè)立每一個(gè)組的資源上限，意味著這個(gè)組最多能使用這么多CPU、Memory、磁盤等，該上限值稱為Quota；每個(gè)組的Job所分配的資源總和不會(huì)超過該組內(nèi)的Quota，當(dāng)然如果每一個(gè)組內(nèi)沒有用完的Quota是可以分享給其他組的，會(huì)按照Quota的比例進(jìn)行均分。

容錯(cuò)機(jī)制

在大規(guī)模進(jìn)程集群中故障是常態(tài)，這些常態(tài)會(huì)來自硬件，比如主板、電源、內(nèi)存條；也可能來自軟件，比如進(jìn)程有Bug導(dǎo)致進(jìn)程Crash，機(jī)器故障導(dǎo)致性能慢。因此，分布式調(diào)度必須具有容錯(cuò)機(jī)制，以保證正在運(yùn)行的任務(wù)不受影響，并對(duì)用戶透明，能夠從故障中恢復(fù)過來，保障系統(tǒng)的高可用。下面將從任務(wù)調(diào)度的Failover和資源調(diào)度的Failover兩個(gè)方面介紹。

AppMaster進(jìn)程重啟后的任務(wù)調(diào)度Failover

每個(gè)計(jì)算任務(wù)有自己的APP Master，如果APP Master進(jìn)程發(fā)生了重啟，那其重啟之后的任務(wù)調(diào)度如何進(jìn)行Failover呢？這里采用了Snapshot機(jī)制，它將Instance的運(yùn)行進(jìn)度保存下來，當(dāng)APP Master重啟之后會(huì)自動(dòng)加載Snapshot以獲取之前每個(gè)Instance的執(zhí)行進(jìn)度，然后繼續(xù)運(yùn)行Instance；當(dāng)APP Master進(jìn)程重啟之后，從APP Worker匯報(bào)的狀態(tài)中重建出之前的調(diào)度結(jié)果，繼續(xù)運(yùn)行Instance。

FuxiMaster進(jìn)程重啟后的資源調(diào)度Failover

另一種情況是Fuxi Master發(fā)生了Failover。Fuxi Master Failover起來之后需要重建內(nèi)部狀態(tài)，該狀態(tài)通常分為兩種：一是Hard State，主要是之前提交的Application配置信息，如不同的Job配置參數(shù)等，它們來自于Fuxi Master寫的Snapshot；另一類是Soft State，Fuxi Master會(huì)收集來自各個(gè)Tubo以及APP Master的信息重建出自己的狀態(tài)，這些信息包括機(jī)器列表、每個(gè)APP Master的資源請(qǐng)求以及之前的資源分配結(jié)果。

Fuxi Master進(jìn)程重啟之后的資源調(diào)度過程如圖4所示，首先會(huì)從Checkpoint中讀取出所有Job的配置信息；同時(shí)會(huì)收集所有的Tubo以及APP Master上報(bào)上來的關(guān)于資源分配的結(jié)果，如CPU多少、Memory多少等等。

規(guī)模挑戰(zhàn)

分布式系統(tǒng)設(shè)計(jì)主要目標(biāo)之一就是橫向擴(kuò)展（scale-out），目前阿里云飛天在2013年時(shí)已支撐單個(gè)集群5000個(gè)節(jié)點(diǎn)、并發(fā)1萬個(gè)任務(wù)。在做橫向擴(kuò)展設(shè)計(jì)時(shí)，需要注意兩個(gè)要點(diǎn)：一是多線程異步；二是增量的資源調(diào)度。

多線程異步

多線程異步是編寫分布式程序一個(gè)非常重要而且常用的技術(shù)手段。在網(wǎng)絡(luò)通信模塊中，每個(gè)APP Master都需要跟Fuxi Master進(jìn)行資源通信，同時(shí)也需要跟多個(gè)Tubo進(jìn)行通信以啟動(dòng)它們的APP Worker。APP Master處理網(wǎng)絡(luò)通信的過程稱之為RPC，RPC通信時(shí)必須采用線程池來處理。如圖5中采用四個(gè)線程池來處理這些消息。由于Fuxi Master是一個(gè)中控節(jié)點(diǎn)，而Tubo的數(shù)量非常眾多，如果將這些消息都在同一個(gè)線程池中處理，則Fuxi Master的消息有可能會(huì)被大量的Tubo消息阻塞（對(duì)頭阻塞問題）。為了解決該問題，在伏羲系統(tǒng)當(dāng)中設(shè)立了一個(gè)獨(dú)立的線程池來處理Fuxi Master的消息；另外一個(gè)線程池來處理Tubo的消息，將線程池進(jìn)行分開，也稱之為泳道；獨(dú)立的泳道能有效解決Fuxi Master的消息被對(duì)頭阻塞的問題。

增量的資源調(diào)度

伏羲解決規(guī)模問題的另一個(gè)技術(shù)點(diǎn)是增量。目前，伏羲采用增量的消息通信和資源調(diào)度，下面通過具體例子，來介紹伏羲所采用的增量資源調(diào)度的協(xié)議。

圖6左側(cè)是中控節(jié)點(diǎn)Fuxi Master；右邊為某一個(gè)APP Master，如果說APP Master需要1000份資源，最直接的一種實(shí)現(xiàn)方式是將“我要1000個(gè)資源”這樣的消息直接發(fā)送給Fuxi Master；Fuxi Master在接到消息之后可能當(dāng)前的剩余資源只有200份，它將會(huì)“我分配給你200”這樣的消息發(fā)送給APP Master；那APP Master還會(huì)繼續(xù)發(fā)送消息“我還要剩余的800”，Fuxi Master回復(fù)“此時(shí)沒有資源，我分配0個(gè)給你”；則APP Master在下一次通信的時(shí)候需要繼續(xù)發(fā)送“我還要剩余的800”……依此類推，可能某一個(gè)時(shí)刻Fuxi Master還能分一點(diǎn)資源下來。這就是最直觀的全量消息通信，每一次APP Master提出請(qǐng)求時(shí)都要指明它總共需要多少。

而在伏羲的實(shí)現(xiàn)當(dāng)中為了減小通信量和不必要的開銷，采用了增量的語義。首先APP Master發(fā)送一個(gè)請(qǐng)求“我要1000個(gè)資源”，Fuxi Master收到之后將當(dāng)時(shí)空閑的200個(gè)資源返回給APP Master；之后APP Master無需再提交請(qǐng)求說我還需要800，因?yàn)镕uxi Master會(huì)將這1000個(gè)請(qǐng)求記錄下來等到某一時(shí)刻又有更多的資源，比如150個(gè)資源釋放，它直接將150個(gè)分配結(jié)果發(fā)送給APP Master即可。這期間APP Master無需再發(fā)多余的網(wǎng)絡(luò)通信。

安全與性能隔離

在分布式系統(tǒng)當(dāng)中通常有多個(gè)用戶在執(zhí)行自己的計(jì)算任務(wù)，多個(gè)任務(wù)之間需要互相隔離、互相不影響。飛天伏羲實(shí)現(xiàn)了全鏈路的訪問控制，采用了兩種訪問控制進(jìn)行安全的驗(yàn)證，一種是Capability，指通信雙方基于私鑰進(jìn)行解密并驗(yàn)證的一種方式；還有一種稱為Token的方式，這種方式需要通信的雙方臨時(shí)生成基于私鑰加密的口令，在通信時(shí)進(jìn)行驗(yàn)證。

兩種方式最大區(qū)別在于口令生成的時(shí)機(jī)，Capability方式是在通信之前就已經(jīng)加密好；而Token是需要在通信時(shí)臨時(shí)生成。

兩種方式使用于不同的場(chǎng)景，如圖7所示FuxiMaster與Tubo通信采用的是Capability方式，因?yàn)檫@兩個(gè)角色在集群部署時(shí)就已啟動(dòng)，可以事先進(jìn)行加密生成好Capability；FuxiMaster與APP之間是采用Token的方式，這是因?yàn)锳PP與FuxiMaster進(jìn)行通信時(shí)，當(dāng)每個(gè)任務(wù)執(zhí)行完計(jì)算之后會(huì)退出；在進(jìn)程與進(jìn)程之間，伏羲采用了沙箱的方式將不同的進(jìn)程進(jìn)行隔離開、互不干擾。

除了安全的隔離之外，還需要考慮性能的隔離。目前伏羲采用的幾種技術(shù)手段：Cgroup（Linux LXC）、Docker container、VM等。這幾種技術(shù)的隔離性、資源配額/度量、移動(dòng)性、安全性的比較如圖8所示，不再一一敘述。

伏羲目前采用的隔離技術(shù)是基于Docker和LXC混合部署的方式，之所以拋棄虛擬機(jī)的方式，是因?yàn)槠湫阅軗p耗太多。當(dāng)運(yùn)行計(jì)算任務(wù)時(shí)，如果完全放在虛擬機(jī)當(dāng)中，它的IO以及CPU時(shí)間片會(huì)受到很大的影響，會(huì)降低任務(wù)的執(zhí)行效率。在目前阿里的生產(chǎn)環(huán)境中，實(shí)踐發(fā)現(xiàn)基于Docker和LXC的隔離技術(shù)已經(jīng)可以很好地滿足需求。

分布式調(diào)度的發(fā)展方向

隨著計(jì)算能力和數(shù)據(jù)量的持續(xù)增長(zhǎng)，分布式調(diào)度未來可能朝向以下幾個(gè)方向發(fā)展：

在線服務(wù)與離線任務(wù)混跑。云計(jì)算最終的目的是降低IT成本，最大限度地利用單臺(tái)PC的CPU處理能力，所以未來的趨勢(shì)一定是在線服務(wù)與離線任務(wù)能夠在同一物理集群上運(yùn)行從而實(shí)現(xiàn)削峰填谷效果、最大化提高集群利用率。但是由于兩種任務(wù)的特點(diǎn)不同，在線運(yùn)用對(duì)于響應(yīng)時(shí)間要求很高，而離線運(yùn)用則對(duì)調(diào)度的吞吐率要求比較高，因此混跑會(huì)帶來性能隔離與資源利用率之間的矛盾。

實(shí)時(shí)計(jì)算的發(fā)展，Map Reduce是一個(gè)很偉大的框架，但其是為數(shù)據(jù)量一定的批處理而設(shè)計(jì)的。隨著云計(jì)算越來越普及，很多計(jì)算形態(tài)需要實(shí)時(shí)拿到計(jì)算結(jié)果，并且其輸入數(shù)據(jù)可能是不間斷的。目前，伏羲也已經(jīng)開發(fā)出了實(shí)時(shí)的計(jì)算框架——OnlineJob，它可以提供更快的執(zhí)行速度。

更大的規(guī)模，目前已能夠支撐5000臺(tái)的節(jié)點(diǎn)，隨著計(jì)算量越來越大，客戶的需求越來越多，需要進(jìn)一步優(yōu)化伏羲系統(tǒng)，能夠支撐起1萬、5萬、10萬等更大規(guī)模單集群，同時(shí)能夠支撐更多的并發(fā)任務(wù)。

總結(jié)

以上是生活随笔為你收集整理的阿里云分布式调度系统-伏羲的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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