Mesos 架構以及源碼淺析
Mesos 按照官方的介紹，是分布式操作系統的內核。目標是 ”Program against your datacenter like it’s a single pool of resources”，即可以將整個數據中心當做一臺電腦一樣使用。可以說這個目標是所有宣稱自己是DCOS的系統的共同目標，本文從架構和源碼層面分析Mesos以及周邊框架，看看Mesos是如何實現這個目標的，當前距這個目標還有多大差距。最后比較了一下Mesos和Kubernetes這兩個都受Google的Borg影響的系統的異同。
閱讀對象：對Mesos或者分布式系統感興趣的技術人
設計理念以及架構
引用Mesos paper里的一句話，來說明Mesos的設計理念：
define a minimal interface that enables efficient resource sharing across frameworks, and otherwise push control of task scheduling and execution to the frameworks
定義一個最小化的接口來支持跨框架的資源共享，其他的調度以及執行工作都委托給框架自己來控制。
這句話標志Mesos不試圖作為一個一棧式解決問題的系統，而是以最小的成本來實現資源共享。先來看看官方提供的架構圖：
主要組件以及概念：
- Zookeeper 主要用來實現Master的選舉，支持Master的高可用。
- Master Mesos的主節點，接受Slave和Framework scheduler的注冊，分配資源。
- Slave 從節點，接受master發來的task，調度executor去執行。
- Framework 比如上圖中的Hadoop，MPI就是Framework，包括scheduler，executor兩部分。scheduler獨立運行，啟動后注冊到master，接受master發送的Resource Offer消息，來決定是否接受。Executor是給slave調用的，執行framework的task。Mesos內置了CommandExecutor(直接調用shell)和DockerExecutor兩種executor，其他的自定義Executor需要提供uri，供slave下載。
- Task Mesos最主要的工作其實就是分配資源，然后詢問scheduler是否可以利用該資源執行Task，scheduler將資源和Task綁定后交由Master發送給指定的Slave執行。Task可以是長生命周期的，也可以使用批量的短生命周期的。
官方提供的另外一個資源分配的例子：
- Slave1 向 Master 報告，有4個CPU和4 GB內存可用
- Master 發送一個 Resource Offer 給 Framework1 來描述 Slave1 有多少可用資源
- FrameWork1 中的 FW Scheduler會答復 Master，我有兩個 Task 需要運行在 Slave1，一個 Task 需要<2個CPU，1 GB內存=””>，另外一個Task需要<1個CPU，2 GB內存=””>
- 最后，Master 發送這些 Tasks 給 Slave1。然后，Slave1還有1個CPU和1 GB內存沒有使用，所以分配模塊可以把這些資源提供給 Framework2
這個例子可以看出來，Mesos的核心工作其實很少，資源管理和分配以及task轉發。調度由Framework實現，task的定義以及具體執行也由Framework實現，Mesos的資源分配粒度是按task的，但由于executor執行task可能在同一個進程中實現，所以資源限制只是一種流控的機制，并不能實際的控制到task這個粒度。
看了上面官方的架構說明，大約應該明白了Mesos的大致架構，但具體Mesos為什么要做成這樣，下面我們具體分析下。
歷史演進
我們把時間回退到Mesos發明的2009年，那時候Hadoop逐漸成熟，并廣泛應用，正在吞噬著大家的服務器。Spark當時也在醞釀中。而服務器配置管理領域Puppet還沒發布1.0，Chef才剛出現，"Configuration management Infrastructure as Code" 的思想才慢慢被接受，Ansible/Salt還沒出現。大家管理服務器還是靜態劃分的方式，購買服務器的時候就安排好了，這幾臺服務器上運行什么服務，應該配置多少CPU/內存/磁盤，安裝維護還多用的是shell腳本。
靜態管理服務器，無論是用shell還是Puppet這種工具，一方面是比較浪費資源，另外一方面服務故障恢復，服務遷移都需要人工介入，因為這種工具都只在部署時進行管理，服務進程運行后就不歸部署工具管理了。而Mesos則看到了這種方式的弊端，試圖實現一個資源共享的平臺，提高資源利用率，實現動態運維。
按照這種方式就比較容易理解Mesos的做法，Mesos的master相當于Puppet/Salt的master，Mesos的slave相當于Puppet/Salt的agent，二者干的事情都是把指令通過master發送給slave/agent執行，區別是Puppet/Salt成功執行后就不關心了，而Mesos執行后會在Master維護task的狀態，task掛掉后可以重啟或者遷移。
同時Mesos看到Hadoop等分布式系統都自己實現了scheduler以及executor，所以將scheduler以及executor的具體實現讓出來，通過制定Framework標準，由第三方分布式框架自己實現，自己只負責轉發task到slave，由slave調用Framework的executor去執行task。
也就是說由于歷史時機的問題，Mesos采用了一種保守的策略來進行演進。
資源沖突以及隔離機制
資源共享導致的首要問題就是如何解決資源沖突問題：
- cpu/mem 這個Mesos默認內置了一個Mesos Containerizer，可以通過cgroups和namespaces進行限制。
- 網絡端口 Mesos默認會給每個task分配一個(可以分配多個端口)隨機的未使用的端口，需要應用從環境變量中獲取到這個端口進行使用，是一種約定的規則，并不強制限制。
- 文件系統 默認情況下Mesos的文件系統是多應用共享的，默認給每個task分配一個sandbox目錄作為工作目錄，sandbox在主機上的目錄是和taskid相關的，不會沖突，生命周期和task綁定。另外也支持Persistent Volume，用于應用保存持久數據，也是通過目錄映射的方式實現的。Persistent Volume的生命周期獨立于task，由scheduler決定是否復用，也就是說Mesos將持久化數據和動態遷移之間的沖突問題交給了scheduler自己處理。另外可以選擇使用Docker Containerizer，通過Docker的方式隔離文件系統。
- 服務發現以及負載均衡 Mesos默認不支持服務發現和負載均衡，需要用戶自己實現。Mesos之上的Marathon Framework提供了一個marathon-lb，通過監聽Marathon的event修改HAProxy，實現動態的負載均衡，不過只支持通過Marathon部署的應用。
- 容器的改進 Mesos內置的容器不是基于Image的，但Docker是基于Image的，帶來的問題就是有些功能要通過兩種方式實現(比如磁盤隔離等)。另外Docker本身的daemon機制讓Mesos不好直接管理容器進程，所以Mesos也在計劃改進內置的容器支持Image，兼容Docker/Appc的Image，不會把Docker作為默認的容器。具體參看：https://github.com/apache/mesos/blob/master/docs/container-image.md，MESOS-2840。
源碼架構分析
Mesos的核心是用c++寫的，主要使用了一個libprocess的庫，這是一個c++的actor模型的庫(不太了解actor模型的可以參看我的前一篇文章：并發之痛 Thread，Goroutine，Actor，這個庫順帶把Option,Nothing,Try, Future,Lambda,Defer這些都實現了，讓我充分體會了c++的魔法)。libprocess基本是參考erlang的模式實現的，其中的actor都叫做process，每個process有一個獨立的ID，我們這里為了方便理解，把其中的抽象都叫做actor，具體actor協作模式見下圖：
在Mesos的master節點中，每個Framework以及Slave都是一個遠程的actor。而slave節點上，每個executor是一個actor，只不過內置的executor是在同一個進程中的，而其他自定義的executor是獨立的進程，executor和slave之間通過進程間通信方式(網絡端口)交互。
Mesos通過actor模型，簡化了分布式系統的調用以及并發編程的復雜度，actor之間都通過消息異步通信，只需要知道對方的ID即可，無需了解對方和自己是否在同一個節點上。libprocess封裝的actor manager知道接收方是本地的actor還是遠程的actor，如果是遠程的則通過請求接口轉發消息。libprocess也封裝了網絡層，傳輸層使用的是http協議，使用方對不同的消息注冊不同的handler即可，也支持http的長輪詢模式訂閱事件。mesos為了提高消息傳遞解析效率，消息傳遞支持json和protobuf兩種格式。
這種架構的好處是Mesos省去了對消息隊列的依賴。一般情況下這種分布式消息分發系統都需要消息隊列或者中心存儲的支持，比如Salt使用的是ZeroMQ，Kubenetes使用的是Etcd，而Mesos則不依賴外部的資源支持，只通過actor模型的容錯機制來實現。而缺點也是actor本身的缺點，因為消息都是異步的，需要actor處理消息的丟失以及超時邏輯，Mesos不保證消息的可靠投遞，提供的投遞策略是 “at-most-once”，actor需要通過超時重試機制解決消息丟失的問題。不過任何需要遠程調用的分布式系統需要處理的類似的問題吧。
Framework的實現解析
從上面的分析可以了解到，Framework在Mesos中扮演著重要的角色。如果你自己要開發一個分布式系統，打算運行在Mesos中，就需要考慮自己實現一個Framework。
Mesos提供了一個Framework的基礎庫，第三方只需要實現scheduler，和executor兩個接口即可。基礎庫是用c++實現了，通過jni提供了java版本，通過python的native方式提供了python版本。而golang的版本是獨立開發的，沒有依賴c++庫，代碼架構比較優雅，想用go實現actor的可以參考。這個Framework基礎庫(SchedulerDriver以及ExecutorDriver的實現)主要做的事情就是實現前面我們提到的actor模型，和master以及slave交互，收到消息后回調用戶自定義的scheduler和executor。
下面是java的Scheduler接口：
- public interface Scheduler {
- void registered(SchedulerDriver driver,
- FrameworkID frameworkId,
- MasterInfo masterInfo);
- void reregistered(SchedulerDriver driver, MasterInfo masterInfo);
- //這個是最主要的一個方法，當系統有空閑資源的時候，會詢問Scheduler，
- //是否接受或者拒絕該Offer。如果接受，則同時需要封裝使用該Offer的task信息，調用driver去執行。
- void resourceOffers(SchedulerDriver driver, List<Offer> offers);
- //如果Offer被取消或者被別的Framework使用，則回調本方法
- void offerRescinded(SchedulerDriver driver, OfferID offerId);
- //該Framework啟動的task狀態變化時回調。
- 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是獨立于Mesos系統的，具體的部署方式，以及高可用都需要Framework自己解決，所以要實現一個完備的，高可用的Framework，復雜度還是挺高的。另外Framwork的機制比較適合需要任務分發以及調度的分布式系統，比如Hadoop，Jenkins等。其他的分布式數據庫比如Cassandra，Mesos做的事情是通過Scheduler調度CassandraExecutor部署和管理(包括節點上的維護操作，比如備份)Cassandra節點，詳細可參看 https://github.com/mesosphere/cassandra-mesos 。
另外Mesos Master本身沒有持久化存儲，所有數據都在內存，重啟后數據會丟失。但活躍的Framework和Slave注冊時會把自己當前的狀態發送給Master，Master通過這種方式恢復數據。所以如果Framework需要持久化Task的執行記錄，需要自己實現持久化存儲。
Mesos Slave提供了recovery的機制，用于實現Slave進程重啟后的恢復。默認情況下，Slave進程重啟后，和該進程相關的executor/task都會被殺掉，但如果Framework配置開啟了checkpoint設置，則該Framework相關的executor/task信息會被持久化到磁盤上，用于重啟后的recovery。
Marathon
Marathon按照官方的說法是個基于Mesos的私有PaaS。它實現了Mesos的Framework，支持通過shell命令和Docker部署應用，提供Web界面，支持cpu/mem，實例數等參數設置，支持單應用的scale，但不支持復雜的集群定義。
Marathon本身是通過Scala實現的，也使用了actor模型。它提供了event bus接口，允許其他應用通過監聽event bus來實現動態配置，比如前面提到的marathon-lb。
Aurora
Aurora試圖用一種自定義的配置語言去定義Mesos之上的task以及順序關系，解決各種環境的異構問題，降低用shell腳本的復雜度。可以理解為Mesos之上的一種粘合劑語言，地位類似于Salt/Ansible的yaml，只不過Mesos本身沒支持類似的配置語言，于是Aurora通過Framework的方式來支持。
Mesos和Kubernetes比較
Mesos和Kubernetes雖然都借鑒了Borg的思想，終極目標類似，但解決方案是不同的。Mesos有點像聯邦制，承認各邦(Framework)的主權，但各邦讓渡一部分公用的機制出來由Mesos來實現，最大化的共享資源，提高資源利用率，Framework和Mesos是相對獨立的關系。而Kubernetes有點像單一制，搭建一個通用的平臺，盡量提供全面的能力(網絡，磁盤，內存，cpu)，制定一個集群應用的定義標準，任何復雜的應用都可以按照該標準定義并以最小的變更成本在上面部署運行，主要的變更需求也是因為想享受Kubernetes的動態伸縮能力帶來的。所以Mesos盡量做的比較少，而Kubernetes盡量做的比較多。Mesos定義是DCOS的kernel，但OS的kernel具體應該承擔哪些職責，相關爭論也從來沒停止過。
相對來說Kubernetes使用要比較容易些，而Mesos更靈活些，需要做的定制開發工作也比較多。拿前面提到的cassandra來比較，cassandra-mesos的實現很復雜，而Kubernetes的cassandra例子則只有一個類，就是實現了KubernetesSeedProvider，通過Kubernetes的服務發現機制尋找cassandra的seed節點。當然Mesos上的cassandra可以通過Mesos發送備份等管理任務，而Kubernetes不提供任務轉發的功能，這類需求用戶可以通過kubectl的exec方法實現。從這個例子也大致能明白二者的差異點。
Kubernetes下的Kubernetes on Mesos項目的目的就是利用Mesos的這個特性，實現Kubernetes和Mesos上的其他Framework共享資源。如果想了解Kubernetes的更多資料可以看這次一并推送的文章："Kubernetes 架構淺析"。
【本文為51CTO專欄作者“王淵命”的原創稿件，轉載請通過作者微信公眾號jolestar-blog獲取授權】
