摘要：從的源代碼可以看出實現(xiàn)得比較優(yōu)雅它是一個代碼。它最優(yōu)的特點是消息在不同的之間傳遞，它抽象了，消息傳遞其實是一個事件的庫。底層實際上依賴于，為了保證分布式存儲最終一致性。如果想寫一個，其實大部分時間在如何寫好一個實現(xiàn)這一部分。

上周小數(shù)羞澀出鏡，和數(shù)人云架構(gòu)師春明一起為大家進行了在線直播的干貨分享，今天小數(shù)抱來了實錄，大家可以一睹為快啦！
本文從Mesos的基礎(chǔ)概念講起，不懂Mesos的小伙伴也完全沒有問題，一步一步教你寫出優(yōu)雅的Framework，讓Mesos更加強大好用：）

今天主要和大家聊一聊Mesos、Marathon，以及數(shù)人云剛剛開源不久的一個Mesos Framework——Swan。

微服務(wù)概念起來之后，很多大型互聯(lián)網(wǎng)公司需要把資源（比如說幾千臺機器、幾萬臺機器）抽象工作，讓更多人來使用。之前大家的做法比較粗暴，一個部門分幾百臺機器，一個項目分幾百臺機器，然后把程序裸跑在一些硬件或者虛擬機上，但這個過程中資源的利用率不是很高。

另一方面，有些增加資源的場景中，增加一些機器非常緩慢，安裝、做機器的provision等等都很困難。因此一些聰明的工程師就萌生了一個想法：能不能把這些資源都抽象，需要的時候分配給不同的人來使用？這個背景誕生了Mesos，即資源調(diào)度的工具。資源調(diào)度器Mesos不是創(chuàng)新，它源自于Google Omega的論文，由Twitter的公司最早推出來。

最近一段時間使用Mesos的API以及看代碼時間比較多，接下和大家分享一下我對Mesos內(nèi)部的理解。

首先，Mesos是一個分布式的架構(gòu)，它分Mesos master和Mesos slave，slave和master分別有不同的職責(zé)。從Mesos的源代碼可以看出Mesos實現(xiàn)得比較優(yōu)雅——它是一個C++代碼。代碼中有大量的關(guān)鍵詞叫process，它不是傳統(tǒng)意義上的進程，而是一種抽象的libprocess，libprocess是它最核心的庫。如果大家以前使用過Erlang的語言就知道libprocess實際是對Erlang的IO和通訊模型的一個抽象。

libprocess，在Erlang里面也叫進程，實際上是一個虛擬進程，在運行Erlang的VM上。它最優(yōu)的特點是消息在不同的process之間傳遞，它抽象了process，消息傳遞其實是一個事件的庫。向process里發(fā)一個消息，這個消息不是直接打到process，而是中間有一個buffer的過程。

這樣做的優(yōu)點是特別適合分布式的系統(tǒng)，以前最常用的做法是監(jiān)聽網(wǎng)絡(luò)端口，有包來了，有一個模塊專門負(fù)責(zé)解這個包，解開一個協(xié)議后把這個協(xié)議發(fā)到后面一個處理進程，這個處理的進程可能是IO操作，可能去做其它事情，然后里面有很多IO上的Block，最后構(gòu)造出一個response，通過一個socket傳給客戶端。這是最常用的一個寫網(wǎng)絡(luò)程序的辦法，但是這里有一個大的IO上Block的地方——后面處理的邏輯依賴于解包的邏輯。如果處理邏輯很快，但解包邏輯很慢，后面會拖慢，都在等解包。

后來人們想到一種IO處理的方式，讓任何一個東西都是分離的，比如從某一個端口收到一個消息，有一個多帶帶的進程，一個線程或者其它的東西去處理這個唯一的請求。這個線程很重，后來大家又發(fā)明了一些其它的東西，比如golang里面去搞一個channel，Erlang里面去搞一個process。libprocess實際上做了IO方面的事情， Mesos大量使用這個模型。

Mesos底層實際上依賴于Zookeeper，為了保證分布式存儲最終一致性。在Mesos運行過程中產(chǎn)生了一些數(shù)據(jù)，最終都會落在Zookeeper。因為Mesos是多個master，為了達到HA的需求，只要一個master活的，那么整個服務(wù)就能得到保證。

Mesos內(nèi)部在通信里面選擇了protobuf協(xié)議。好處是比較流行，各個語言的庫都比較多，結(jié)構(gòu)化的語義也比較強，所以Mesos內(nèi)部選擇了protobuf。

至此，簡單介紹了Mesos內(nèi)部的一些動作。接下來介紹Mesos提出的一些概念。

Mesos是一個分布式的系統(tǒng)，分master和slave， master的部分主要協(xié)調(diào)任務(wù)的分發(fā)、一些資源的調(diào)度。slave是負(fù)責(zé)執(zhí)行的部分，比如一個任務(wù)最終是slave去執(zhí)行的。當(dāng)然，可以配在master執(zhí)行。Mesos是一個雙層調(diào)度，slave處于下層，也就是說可以動態(tài)的增加或者減少一些slave而不影響整個的任務(wù)池資源的變化，不影響上一層的任務(wù)。

Executor是真正的執(zhí)行任務(wù)的邏輯。Mesos平臺不太區(qū)分需要執(zhí)行什么任務(wù)，所以它給用戶一些靈活性，可以寫不同的Executor。比如最常用的Mesos運行容器的部分，就是一個Executor。還有Map Reduce的大型任務(wù)，一個Map、一個Reduce， Executor都可以執(zhí)行。它的表現(xiàn)形式可以是一個二進制，Mesos在運行時，slave會把Executor從遠(yuǎn)程一個URL上拉下來，然后開始執(zhí)行Executor。

Scheduler的意思是調(diào)度， Mesos master和slave把資源收上來之后，再把這些任務(wù)交給Scheduler，由Scheduler決定應(yīng)該運行什么Task。

Framework是雙層調(diào)度的上一層，也就是由Framework來決定到底該執(zhí)行什么任務(wù)，然后執(zhí)行多少這樣的任務(wù)。

Offer是Mesos資源的抽象，比如說有多少CPU、多少memory，disc是多少，都放在Offer里，打包給一個Framework，然后Framework來決定到底怎么用這個Offer。

Task實際上是運行的小任務(wù)。有兩大類Task，一大類我們叫Long Running Task，比如Docker的一個進程或者其它的進程。另外一類是Batch類型任務(wù)，這類應(yīng)用非常廣泛，比如說Map Reduce這么一個小任務(wù)或者是定時任務(wù)。

這里分別介紹一下剛才提到的這些名詞，說一說它們都是如何工作的。

Mesos master是整個集群的核心，master為了保證高可用其實是可以跑多個master，分布式系統(tǒng)為了保證盡量的高可用，其實是可以有多個master在那兒運行的。比如倒了幾個master，不會影響整個服務(wù)。Mesos master主要內(nèi)部的工作有：Framework注冊或者Framework出了什么問題，它來保證Framework的生命周期；slave的添加、slave的異常、slave的任務(wù)分配，我把它叫做slave的Lifecycle；Task Management，比如說Mesos master可能記錄了哪些Task運行在哪些slave上；Resource Allocation&Offer，就是說slave有什么資源匯報給master，然后由master把這些任務(wù)交給注冊在這個master上的一些Framework。

slave可以動態(tài)添加和減少，它lost不會影響整個服務(wù)，只是把這個事件（比如說一個slave掉了）由master去通知Framework。在Mesos slave代碼里有大量執(zhí)行器，即Executor的邏輯，因為所有Executor都是在slave上執(zhí)行的，包括把Executor從遠(yuǎn)程拉下來、開始執(zhí)行Executor、開始執(zhí)行l(wèi)aunch task，維護task的生命周期，task fail了如何去做等等。

Mesos的定位是一些資源的調(diào)度，它把任務(wù)的調(diào)度交給了Framework來做，Mesos只關(guān)心資源以及把資源給了誰， Framework來決定哪些資源怎么去使用。Mesos鼓勵Framework在上面共生。想象一下，作為一個大型公司，有很多的資源，有核心的一組人來維護Mesos的集群，不斷的往Mesos上添加資源和減少資源，而把Framework執(zhí)行的能力交給其它的組、需要資源的那些組，各個組就可以寫自己的Framework，丟到整個大的Mesos集群上來執(zhí)行了。Mesos框架上和執(zhí)行上各種各樣的Framework，而Mesos本身也不了解為什么Framework工作，它只是知道把Offer給Framework，然后Framework告訴它來執(zhí)行什么樣的Executor。

Marathon Framework，它的任務(wù)偏Long Running，核心是application。因為Mesos只關(guān)注task本身，task偏向于小任務(wù)，不會產(chǎn)生什么巨大的效應(yīng)，而在企業(yè)里面尤其是彈性應(yīng)用，更多是一個應(yīng)用，它有很多的實例來執(zhí)行，這就是Marathon來做的。

Chornous是一個偏Job、定時任務(wù)類型，如果把定時任務(wù)以Docker形式發(fā)出來，這個Chornous是非常適合的。傳統(tǒng)的的Cron Job也是解決這類問題， Cron Job其實有很大的痛點，因為Cron Job是跑在主機上的，主機有l(wèi)imit的限制，如何把Cron Job放在多機上，需要有一個很好的哈希算法。到底如何把一堆單臺機器很難執(zhí)行的多個job水平分布在很多機器上，很麻煩。但是有了這個Chornous的Framework，事情就變得簡單多了。

它們倆區(qū)分度不是太大，有一些區(qū)分。Scheduler是做任務(wù)分配的，它從master上得到一個Offer的事件，拿到Offer后，決定到底接受這個Offer還是拒絕，接受這個Offer之后，把什么樣的Task放在這個Offer上， Framework也開始占用這個Offer，這是Scheduler做的事情。Scheduler Driver其實是偏消息通信的那一部分，而Scheduler可定制化特別強，在代碼里看到Scheduler其實是一個java的abstract glass，相當(dāng)于一個interface，F(xiàn)ramework自己去實現(xiàn)這么一個東西。如果想寫一個Framework，其實大部分時間在如何寫好一個Scheduler實現(xiàn)這一部分。

如果Executor和Scheduler是對應(yīng)的， Executor就是執(zhí)行的這一部分。Mesos container這個Executor是Mesos自己提供的，不用寫Executor就可以launch一個Docker的任務(wù)。但如果有一些自己的需求，就需要去實現(xiàn)一個Executor，比如七牛和樂視實現(xiàn)了一些Executor。

舉例來說，處理圖片、處理文件的Executor，偏向于這種小任務(wù)，寫一個Executor來實現(xiàn)這個interface，最終打成一個二進制，放在一個URL里面。在Framework，slave就可以把這個Executor拉下來，然后執(zhí)行這個Tasks。Executor是一個獨立的二進制，它和master、和slave之間的通信是要支持RBC的。

剛才已經(jīng)提到了Marathon基本的功能，Marathon作為一個Long Running上一層的調(diào)度機制，為用戶做了很多有意義的事情。單純一個Mesos的話做不了什么，因為Task的力度特別小，Mesos的功能更偏重于資源的管理、資源的調(diào)度，Marathon更偏向于一些任務(wù)。

Marathon提出了幾個概念，最核心的概念叫application，還有Group的application，是一組的application。一個application是什么呢？比如一個Rails的任務(wù)、NodeJS任務(wù)或者其它的一些任務(wù)，在部署的時候并不是部署一個Task，而是部署非常多的Task，application就是一組Task。這個Task在Marathon里面叫instance，可以選擇scale down或者scale up這些instance，這些任務(wù)最終交給Mesos，Mesos調(diào)度到不同的slave上。

圍繞著這個application，Marathon就提供了一些概念叫Group，Group是一組application。舉例來說，在內(nèi)部可能有很多的微服務(wù)，這些微服務(wù)達到同一個目標(biāo)，比如說服務(wù)之間還有調(diào)用、還有依賴，這時去發(fā)一個Group application就比較好用。但實際工作中，因為生產(chǎn)級別的服務(wù)對穩(wěn)定性的要求很高， Group之間其實假設(shè)服務(wù)和服務(wù)之間是有一定的依賴。

Marathon提供了一個有意思的feature—— rolling update。假如有APP的新版本上來，它可以通過一定的機制去發(fā)多個版本，而且可以多個版本共存。如果那個新版本沒有問題的話，可以繼續(xù)preceeding deployment。如果有問題的話，可以Rollback。這時有兩個概念Deployment和Version，可以選定哪一個Version，想Rollback哪個Version。Deployment是每次update，每次更新、每次重新的Deployment、每次scale，都會在內(nèi)部生成一個Deployment，和應(yīng)用一對多有關(guān)。有趣的是Deployment之間是不可以重疊的，Deployment是一種部署排隊的機制，Deployment不可以多個同時進行，既想update又想scale，會讓Marathon崩潰。

Marathon scale和rolling update的功能都非常有用，比如新浪微博現(xiàn)在有一個大的事件，需要更多的Task頂上來，立刻 scale up，只要資源足夠就可以無限多的Task生成。Rollback，如果有一個版本有問題，可以瞬間Rollback到以前一個健康的版本。

雖然Mesos對下面的資源做了一些抽象，但是有時候有一些傾向性，比如希望CPU使用率比較高的一些任務(wù)調(diào)度到CPU比較好的機器上，需要一種在調(diào)度上的傾向性來滿足剛才的場景。很多調(diào)度器都有類似的功能，叫Constraints，比如一臺主機的label，要把Task打到一組主機這樣的Label上或者是Host name like，這是Marathon做的，Mesos不用做這類的事情。

Marathon的接口非常友好，都是HTTP的接口。Mesos的接口by design不是面向最終用戶，所以它的接口并不是那么友好。馬拉松的UI也非常漂亮，尤其是新版。

最后介紹一下Swan（https://github.com/Dataman-Cl... ）這個項目，Swan是最近數(shù)人云做的一個Mesos的Framework，定位是做一個General Purpose Long Running Task的Framework。數(shù)人云使用馬拉松較長時間，發(fā)現(xiàn)不太滿足需求，比如很難做一些定制化，控制不住它的發(fā)展趨勢。我們希望研發(fā)一款工具既有馬拉松的功能又自主可控、添加一些想要的featur，具體的feature會在下文中逐一介紹。

我們希望這個通用性的Framework在任何情況下，服務(wù)不會受到影響。因為Mesos HA這方面已經(jīng)做得很好，所以Framework不會是單點，首先Swan要支持HA，因為受到Swarmkit啟發(fā)比較大， Swarmkit天生就是Raft協(xié)議，在一堆manager中只要有一個活的，就能健康的對外服務(wù)。

Marathon沒怎么做服務(wù)發(fā)現(xiàn)，無非是把端口暴露出來，哪個任務(wù)在哪些IP和端口上，通過API的形式告訴給外面。Swan里內(nèi)置服務(wù)發(fā)現(xiàn)，會有一個列表告訴外面哪些服務(wù)跑在哪些端口、哪些APP上。

DNS是服務(wù)發(fā)現(xiàn)的另一種。主流的一些Framework都把DNS這個功能放在了比較核心的位置，比如K8s里面的SkyNet，Mesos曾經(jīng)以前有Mesos DNS，以及Swarmkit，Swarm的服務(wù)發(fā)現(xiàn)分為DNS Round Robin和IPVS兩種，把DNS放在Swan這個模塊里更加的可控。它不單是一個DNS，同時是一個DNS的代理。這樣最終能實現(xiàn)的效果，在企業(yè)內(nèi)部通過我們的DNS和用戶的DNS來混搭，來達到一種Mesos內(nèi)部和外部互相調(diào)用，在瀏覽器上既可以訪問Mesos內(nèi)部的東西又可以訪問外面的東西，達到比較完美的效果。

Proxy，并不單是Proxy，還有負(fù)載均衡。最常見的Proxy的工具有HAProxy或者nginx。 HAProxy和nginx雖然很優(yōu)秀、性能很好，缺點是可控性太差，很難控制它。HA可編程的能力很差，Nginx可編程的能力不錯，新浪微博有一個項目叫upsync-module，非常優(yōu)秀。之前評估過這個項目，發(fā)現(xiàn)集成這兩個的難度很大。

我的分享就到這里，謝謝大家。