Mesos 按照官方的介紹，是分布式操作系統(tǒng)的內(nèi)核。目標(biāo)是 ”Program against your datacenter like it’s a single pool of resources”，即可以將整個(gè)數(shù)據(jù)中心當(dāng)做一臺(tái)電腦一樣使用。可以說(shuō)這個(gè)目標(biāo)是所有宣稱自己是DCOS的系統(tǒng)的共同目標(biāo)，本文從架構(gòu)和源碼層面分析Mesos以及周邊框架，看看Mesos是如何實(shí)現(xiàn)這個(gè)目標(biāo)的，當(dāng)前距這個(gè)目標(biāo)還有多大差距。最后比較了一下Mesos和Kubernetes這兩個(gè)都受Google的Borg影響的系統(tǒng)的異同。

閱讀對(duì)象：對(duì)Mesos或者分布式系統(tǒng)感興趣的技術(shù)人

設(shè)計(jì)理念以及架構(gòu)

引用Mesos paper里的一句話，來(lái)說(shuō)明Mesos的設(shè)計(jì)理念：

define a minimal interface that enables efficient resource sharing across frameworks, and otherwise push control of task scheduling and execution to the frameworks

定義一個(gè)最小化的接口來(lái)支持跨框架的資源共享，其他的調(diào)度以及執(zhí)行工作都委托給框架自己來(lái)控制。

這句話標(biāo)志Mesos不試圖作為一個(gè)一棧式解決問(wèn)題的系統(tǒng)，而是以最小的成本來(lái)實(shí)現(xiàn)資源共享。先來(lái)看看官方提供的架構(gòu)圖：

主要組件以及概念：

• Zookeeper 主要用來(lái)實(shí)現(xiàn)Master的選舉，支持Master的高可用。
• Master Mesos的主節(jié)點(diǎn)，接受Slave和Framework scheduler的注冊(cè)，分配資源。
• Slave 從節(jié)點(diǎn)，接受master發(fā)來(lái)的task，調(diào)度executor去執(zhí)行。
• Framework 比如上圖中的Hadoop，MPI就是Framework，包括scheduler，executor兩部分。scheduler獨(dú)立運(yùn)行，啟動(dòng)后注冊(cè)到master，接受master發(fā)送的Resource Offer消息，來(lái)決定是否接受。Executor是給slave調(diào)用的，執(zhí)行framework的task。Mesos內(nèi)置了CommandExecutor(直接調(diào)用shell)和DockerExecutor兩種executor，其他的自定義Executor需要提供uri，供slave下載。
• Task Mesos最主要的工作其實(shí)就是分配資源，然后詢問(wèn)scheduler是否可以利用該資源執(zhí)行Task，scheduler將資源和Task綁定后交由Master發(fā)送給指定的Slave執(zhí)行。Task可以是長(zhǎng)生命周期的，也可以使用批量的短生命周期的。

官方提供的另外一個(gè)資源分配的例子：

1. Slave1 向 Master 報(bào)告，有4個(gè)CPU和4 GB內(nèi)存可用
2. Master 發(fā)送一個(gè) Resource Offer 給 Framework1 來(lái)描述 Slave1 有多少可用資源
3. FrameWork1 中的 FW Scheduler會(huì)答復(fù) Master，我有兩個(gè) Task 需要運(yùn)行在 Slave1，一個(gè) Task 需要<2個(gè)CPU，1 GB內(nèi)存=””>，另外一個(gè)Task需要<1個(gè)CPU，2 GB內(nèi)存=””>
4. 最后，Master 發(fā)送這些 Tasks 給 Slave1。然后，Slave1還有1個(gè)CPU和1 GB內(nèi)存沒有使用，所以分配模塊可以把這些資源提供給 Framework2

這個(gè)例子可以看出來(lái)，Mesos的核心工作其實(shí)很少，資源管理和分配以及task轉(zhuǎn)發(fā)。調(diào)度由Framework實(shí)現(xiàn)，task的定義以及具體執(zhí)行也由Framework實(shí)現(xiàn)，Mesos的資源分配粒度是按task的，但由于executor執(zhí)行task可能在同一個(gè)進(jìn)程中實(shí)現(xiàn)，所以資源限制只是一種流控的機(jī)制，并不能實(shí)際的控制到task這個(gè)粒度。

看了上面官方的架構(gòu)說(shuō)明，大約應(yīng)該明白了Mesos的大致架構(gòu)，但具體Mesos為什么要做成這樣，下面我們具體分析下。

歷史演進(jìn)

我們把時(shí)間回退到Mesos發(fā)明的2009年，那時(shí)候Hadoop逐漸成熟，并廣泛應(yīng)用，正在吞噬著大家的服務(wù)器。Spark當(dāng)時(shí)也在醞釀中。而服務(wù)器配置管理領(lǐng)域Puppet還沒發(fā)布1.0，Chef才剛出現(xiàn)，"Configuration management Infrastructure as Code" 的思想才慢慢被接受，Ansible/Salt還沒出現(xiàn)。大家管理服務(wù)器還是靜態(tài)劃分的方式，購(gòu)買服務(wù)器的時(shí)候就安排好了，這幾臺(tái)服務(wù)器上運(yùn)行什么服務(wù)，應(yīng)該配置多少CPU/內(nèi)存/磁盤，安裝維護(hù)還多用的是shell腳本。

靜態(tài)管理服務(wù)器，無(wú)論是用shell還是Puppet這種工具，一方面是比較浪費(fèi)資源，另外一方面服務(wù)故障恢復(fù)，服務(wù)遷移都需要人工介入，因?yàn)檫@種工具都只在部署時(shí)進(jìn)行管理，服務(wù)進(jìn)程運(yùn)行后就不歸部署工具管理了。而Mesos則看到了這種方式的弊端，試圖實(shí)現(xiàn)一個(gè)資源共享的平臺(tái)，提高資源利用率，實(shí)現(xiàn)動(dòng)態(tài)運(yùn)維。

按照這種方式就比較容易理解Mesos的做法，Mesos的master相當(dāng)于Puppet/Salt的master，Mesos的slave相當(dāng)于Puppet/Salt的agent，二者干的事情都是把指令通過(guò)master發(fā)送給slave/agent執(zhí)行，區(qū)別是Puppet/Salt成功執(zhí)行后就不關(guān)心了，而Mesos執(zhí)行后會(huì)在Master維護(hù)task的狀態(tài)，task掛掉后可以重啟或者遷移。

同時(shí)Mesos看到Hadoop等分布式系統(tǒng)都自己實(shí)現(xiàn)了scheduler以及executor，所以將scheduler以及executor的具體實(shí)現(xiàn)讓出來(lái)，通過(guò)制定Framework標(biāo)準(zhǔn)，由第三方分布式框架自己實(shí)現(xiàn)，自己只負(fù)責(zé)轉(zhuǎn)發(fā)task到slave，由slave調(diào)用Framework的executor去執(zhí)行task。

也就是說(shuō)由于歷史時(shí)機(jī)的問(wèn)題，Mesos采用了一種保守的策略來(lái)進(jìn)行演進(jìn)。

資源沖突以及隔離機(jī)制

資源共享導(dǎo)致的首要問(wèn)題就是如何解決資源沖突問(wèn)題：

1. cpu/mem 這個(gè)Mesos默認(rèn)內(nèi)置了一個(gè)Mesos Containerizer，可以通過(guò)cgroups和namespaces進(jìn)行限制。
2. 網(wǎng)絡(luò)端口 Mesos默認(rèn)會(huì)給每個(gè)task分配一個(gè)(可以分配多個(gè)端口)隨機(jī)的未使用的端口，需要應(yīng)用從環(huán)境變量中獲取到這個(gè)端口進(jìn)行使用，是一種約定的規(guī)則，并不強(qiáng)制限制。
3. 文件系統(tǒng) 默認(rèn)情況下Mesos的文件系統(tǒng)是多應(yīng)用共享的，默認(rèn)給每個(gè)task分配一個(gè)sandbox目錄作為工作目錄，sandbox在主機(jī)上的目錄是和taskid相關(guān)的，不會(huì)沖突，生命周期和task綁定。另外也支持Persistent Volume，用于應(yīng)用保存持久數(shù)據(jù)，也是通過(guò)目錄映射的方式實(shí)現(xiàn)的。Persistent Volume的生命周期獨(dú)立于task，由scheduler決定是否復(fù)用，也就是說(shuō)Mesos將持久化數(shù)據(jù)和動(dòng)態(tài)遷移之間的沖突問(wèn)題交給了scheduler自己處理。另外可以選擇使用Docker Containerizer，通過(guò)Docker的方式隔離文件系統(tǒng)。
4. 服務(wù)發(fā)現(xiàn)以及負(fù)載均衡 Mesos默認(rèn)不支持服務(wù)發(fā)現(xiàn)和負(fù)載均衡，需要用戶自己實(shí)現(xiàn)。Mesos之上的Marathon Framework提供了一個(gè)marathon-lb，通過(guò)監(jiān)聽Marathon的event修改HAProxy，實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡，不過(guò)只支持通過(guò)Marathon部署的應(yīng)用。
5. 容器的改進(jìn) Mesos內(nèi)置的容器不是基于Image的，但Docker是基于Image的，帶來(lái)的問(wèn)題就是有些功能要通過(guò)兩種方式實(shí)現(xiàn)(比如磁盤隔離等)。另外Docker本身的daemon機(jī)制讓Mesos不好直接管理容器進(jìn)程，所以Mesos也在計(jì)劃改進(jìn)內(nèi)置的容器支持Image，兼容Docker/Appc的Image，不會(huì)把Docker作為默認(rèn)的容器。具體參看：https://github.com/apache/mesos/blob/master/docs/container-image.md，MESOS-2840。

源碼架構(gòu)分析

Mesos的核心是用c++寫的，主要使用了一個(gè)libprocess的庫(kù)，這是一個(gè)c++的actor模型的庫(kù)(不太了解actor模型的可以參看我的前一篇文章：并發(fā)之痛 Thread，Goroutine，Actor，這個(gè)庫(kù)順帶把Option,Nothing,Try, Future,Lambda,Defer這些都實(shí)現(xiàn)了，讓我充分體會(huì)了c++的魔法)。libprocess基本是參考erlang的模式實(shí)現(xiàn)的，其中的actor都叫做process，每個(gè)process有一個(gè)獨(dú)立的ID，我們這里為了方便理解，把其中的抽象都叫做actor，具體actor協(xié)作模式見下圖：

在Mesos的master節(jié)點(diǎn)中，每個(gè)Framework以及Slave都是一個(gè)遠(yuǎn)程的actor。而slave節(jié)點(diǎn)上，每個(gè)executor是一個(gè)actor，只不過(guò)內(nèi)置的executor是在同一個(gè)進(jìn)程中的，而其他自定義的executor是獨(dú)立的進(jìn)程，executor和slave之間通過(guò)進(jìn)程間通信方式(網(wǎng)絡(luò)端口)交互。

Mesos通過(guò)actor模型，簡(jiǎn)化了分布式系統(tǒng)的調(diào)用以及并發(fā)編程的復(fù)雜度，actor之間都通過(guò)消息異步通信，只需要知道對(duì)方的ID即可，無(wú)需了解對(duì)方和自己是否在同一個(gè)節(jié)點(diǎn)上。libprocess封裝的actor manager知道接收方是本地的actor還是遠(yuǎn)程的actor，如果是遠(yuǎn)程的則通過(guò)請(qǐng)求接口轉(zhuǎn)發(fā)消息。libprocess也封裝了網(wǎng)絡(luò)層，傳輸層使用的是http協(xié)議，使用方對(duì)不同的消息注冊(cè)不同的handler即可，也支持http的長(zhǎng)輪詢模式訂閱事件。mesos為了提高消息傳遞解析效率，消息傳遞支持json和protobuf兩種格式。

這種架構(gòu)的好處是Mesos省去了對(duì)消息隊(duì)列的依賴。一般情況下這種分布式消息分發(fā)系統(tǒng)都需要消息隊(duì)列或者中心存儲(chǔ)的支持，比如Salt使用的是ZeroMQ，Kubenetes使用的是Etcd，而Mesos則不依賴外部的資源支持，只通過(guò)actor模型的容錯(cuò)機(jī)制來(lái)實(shí)現(xiàn)。而缺點(diǎn)也是actor本身的缺點(diǎn)，因?yàn)橄⒍际钱惒降?，需要actor處理消息的丟失以及超時(shí)邏輯，Mesos不保證消息的可靠投遞，提供的投遞策略是 “at-most-once”，actor需要通過(guò)超時(shí)重試機(jī)制解決消息丟失的問(wèn)題。不過(guò)任何需要遠(yuǎn)程調(diào)用的分布式系統(tǒng)需要處理的類似的問(wèn)題吧。

Framework的實(shí)現(xiàn)解析

從上面的分析可以了解到，F(xiàn)ramework在Mesos中扮演著重要的角色。如果你自己要開發(fā)一個(gè)分布式系統(tǒng)，打算運(yùn)行在Mesos中，就需要考慮自己實(shí)現(xiàn)一個(gè)Framework。

Mesos提供了一個(gè)Framework的基礎(chǔ)庫(kù)，第三方只需要實(shí)現(xiàn)scheduler，和executor兩個(gè)接口即可?；A(chǔ)庫(kù)是用c++實(shí)現(xiàn)了，通過(guò)jni提供了java版本，通過(guò)python的native方式提供了python版本。而golang的版本是獨(dú)立開發(fā)的，沒有依賴c++庫(kù)，代碼架構(gòu)比較優(yōu)雅，想用go實(shí)現(xiàn)actor的可以參考。這個(gè)Framework基礎(chǔ)庫(kù)(SchedulerDriver以及ExecutorDriver的實(shí)現(xiàn))主要做的事情就是實(shí)現(xiàn)前面我們提到的actor模型，和master以及slave交互，收到消息后回調(diào)用戶自定義的scheduler和executor。

下面是java的Scheduler接口：

public interface Scheduler { 
 
  void registered(SchedulerDriver driver, 
  FrameworkID frameworkId, 
  MasterInfo masterInfo); 
 
  void reregistered(SchedulerDriver driver, MasterInfo masterInfo); 
 
  //這個(gè)是最主要的一個(gè)方法，當(dāng)系統(tǒng)有空閑資源的時(shí)候，會(huì)詢問(wèn)Scheduler， 
  //是否接受或者拒絕該Offer。如果接受，則同時(shí)需要封裝使用該Offer的task信息，調(diào)用driver去執(zhí)行。 
  void resourceOffers(SchedulerDriver driver, List<Offer> offers); 
  //如果Offer被取消或者被別的Framework使用，則回調(diào)本方法 
  void offerRescinded(SchedulerDriver driver, OfferID offerId); 
  //該Framework啟動(dòng)的task狀態(tài)變化時(shí)回調(diào)。 
  void statusUpdate(SchedulerDriver driver, TaskStatus status); 
  //自定義的框架消息 
  void frameworkMessage(SchedulerDriver driver,ExecutorID executorId,SlaveID slaveId,byte[]() data); 
 
  void disconnected(SchedulerDriver driver); 
 
  void slaveLost(SchedulerDriver driver, SlaveID slaveId); 
 
  void executorLost(SchedulerDriver driver,ExecutorID executorId,SlaveID slaveId,int status); 
 
  void error(SchedulerDriver driver, String message); 
} 

Mesos的Framework是獨(dú)立于Mesos系統(tǒng)的，具體的部署方式，以及高可用都需要Framework自己解決，所以要實(shí)現(xiàn)一個(gè)完備的，高可用的Framework，復(fù)雜度還是挺高的。另外Framwork的機(jī)制比較適合需要任務(wù)分發(fā)以及調(diào)度的分布式系統(tǒng)，比如Hadoop，Jenkins等。其他的分布式數(shù)據(jù)庫(kù)比如Cassandra，Mesos做的事情是通過(guò)Scheduler調(diào)度CassandraExecutor部署和管理(包括節(jié)點(diǎn)上的維護(hù)操作，比如備份)Cassandra節(jié)點(diǎn)，詳細(xì)可參看 https://github.com/mesosphere/cassandra-mesos 。

另外Mesos Master本身沒有持久化存儲(chǔ)，所有數(shù)據(jù)都在內(nèi)存，重啟后數(shù)據(jù)會(huì)丟失。但活躍的Framework和Slave注冊(cè)時(shí)會(huì)把自己當(dāng)前的狀態(tài)發(fā)送給Master，Master通過(guò)這種方式恢復(fù)數(shù)據(jù)。所以如果Framework需要持久化Task的執(zhí)行記錄，需要自己實(shí)現(xiàn)持久化存儲(chǔ)。

Mesos Slave提供了recovery的機(jī)制，用于實(shí)現(xiàn)Slave進(jìn)程重啟后的恢復(fù)。默認(rèn)情況下，Slave進(jìn)程重啟后，和該進(jìn)程相關(guān)的executor/task都會(huì)被殺掉，但如果Framework配置開啟了checkpoint設(shè)置，則該Framework相關(guān)的executor/task信息會(huì)被持久化到磁盤上，用于重啟后的recovery。

Marathon

Marathon按照官方的說(shuō)法是個(gè)基于Mesos的私有PaaS。它實(shí)現(xiàn)了Mesos的Framework，支持通過(guò)shell命令和Docker部署應(yīng)用，提供Web界面，支持cpu/mem，實(shí)例數(shù)等參數(shù)設(shè)置，支持單應(yīng)用的scale，但不支持復(fù)雜的集群定義。

Marathon本身是通過(guò)Scala實(shí)現(xiàn)的，也使用了actor模型。它提供了event bus接口，允許其他應(yīng)用通過(guò)監(jiān)聽event bus來(lái)實(shí)現(xiàn)動(dòng)態(tài)配置，比如前面提到的marathon-lb。

Aurora

Aurora試圖用一種自定義的配置語(yǔ)言去定義Mesos之上的task以及順序關(guān)系，解決各種環(huán)境的異構(gòu)問(wèn)題，降低用shell腳本的復(fù)雜度?？梢岳斫鉃镸esos之上的一種粘合劑語(yǔ)言，地位類似于Salt/Ansible的yaml，只不過(guò)Mesos本身沒支持類似的配置語(yǔ)言，于是Aurora通過(guò)Framework的方式來(lái)支持。

Mesos和Kubernetes比較

Mesos和Kubernetes雖然都借鑒了Borg的思想，終極目標(biāo)類似，但解決方案是不同的。Mesos有點(diǎn)像聯(lián)邦制，承認(rèn)各邦(Framework)的主權(quán)，但各邦讓渡一部分公用的機(jī)制出來(lái)由Mesos來(lái)實(shí)現(xiàn)，最大化的共享資源，提高資源利用率，F(xiàn)ramework和Mesos是相對(duì)獨(dú)立的關(guān)系。而Kubernetes有點(diǎn)像單一制，搭建一個(gè)通用的平臺(tái)，盡量提供全面的能力(網(wǎng)絡(luò)，磁盤，內(nèi)存，cpu)，制定一個(gè)集群應(yīng)用的定義標(biāo)準(zhǔn)，任何復(fù)雜的應(yīng)用都可以按照該標(biāo)準(zhǔn)定義并以最小的變更成本在上面部署運(yùn)行，主要的變更需求也是因?yàn)橄胂硎躃ubernetes的動(dòng)態(tài)伸縮能力帶來(lái)的。所以Mesos盡量做的比較少，而Kubernetes盡量做的比較多。Mesos定義是DCOS的kernel，但OS的kernel具體應(yīng)該承擔(dān)哪些職責(zé)，相關(guān)爭(zhēng)論也從來(lái)沒停止過(guò)。

相對(duì)來(lái)說(shuō)Kubernetes使用要比較容易些，而Mesos更靈活些，需要做的定制開發(fā)工作也比較多。拿前面提到的cassandra來(lái)比較，cassandra-mesos的實(shí)現(xiàn)很復(fù)雜，而Kubernetes的cassandra例子則只有一個(gè)類，就是實(shí)現(xiàn)了KubernetesSeedProvider，通過(guò)Kubernetes的服務(wù)發(fā)現(xiàn)機(jī)制尋找cassandra的seed節(jié)點(diǎn)。當(dāng)然Mesos上的cassandra可以通過(guò)Mesos發(fā)送備份等管理任務(wù)，而Kubernetes不提供任務(wù)轉(zhuǎn)發(fā)的功能，這類需求用戶可以通過(guò)kubectl的exec方法實(shí)現(xiàn)。從這個(gè)例子也大致能明白二者的差異點(diǎn)。

Kubernetes下的Kubernetes on Mesos項(xiàng)目的目的就是利用Mesos的這個(gè)特性，實(shí)現(xiàn)Kubernetes和Mesos上的其他Framework共享資源。如果想了解Kubernetes的更多資料可以看這次一并推送的文章："Kubernetes 架構(gòu)淺析"。

【本文為51CTO專欄作者“王淵命”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)jolestar-blog獲取授權(quán)】

戳這里，看該作者更多好文