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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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