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

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

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

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

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

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

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

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

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

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

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

Mesos內部在通信里面選擇了protobuf協議。好處是比較流行，各個語言的庫都比較多，結構化的語義也比較強，所以Mesos內部選擇了protobuf。

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

Mesos是一個分布式的系統，分master和slave， master的部分主要協調任務的分發、一些資源的調度。slave是負責執行的部分，比如一個任務最終是slave去執行的。當然，可以配在master執行。Mesos是一個雙層調度，slave處于下層，也就是說可以動態的增加或者減少一些slave而不影響整個的任務池資源的變化，不影響上一層的任務。

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

Scheduler的意思是調度， Mesos master和slave把資源收上來之后，再把這些任務交給Scheduler，由Scheduler決定應該運行什么Task。

Framework是雙層調度的上一層，也就是由Framework來決定到底該執行什么任務，然后執行多少這樣的任務。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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