Mesos中包含四類主要的服務（實際上是一個socket server），它們分別是Mesos Master，Mesos Slave，SchedulerProcess和ExecutorProcess，它們之間通過Protocal Buffer消息進行通信，每種服務內部注冊了若干種Protocal Buffer消息處理器，一旦收到某種消息，則會調用相應的消息處理器進行處理。除了以上四種服務之外，Mesos還對外提供了三種可編程組件，分別是 Alloctor、Framework Scheduler和Framework Executor，編寫這幾個組件必須按照要求實現了幾個接口，而這些接口將分別被下圖中相鄰的服務調用。

大部分人看到以上Mesos架構后，均會認為Framework必須是一個通用的框架，比如MapReduce、Storm、Spark等，而 Mesos Master負責將資源分配給各個框架，而各個框架的Scheduler進一步將資源分配給其內部的各個應用程序。這種觀念是錯誤的，是對Mesos架構 的一種錯誤解讀。

事實上，Framework不僅可以是通用的框架，也可以是像Hadoop的Job或者YARN的Application那樣的簡單計算任務，也就 是說，Framework并需要一定是一個“Framework”，或者一個長時間運行的服務（比如JobTracker等），也可以是一個短生命周期的 Job或者Application。如果讓Framework對應一個Hadoop Job，則可以這樣設計Framework Scheduler和Framework Executor：

（1）Framework Scheduler功能

Framework Scheduler負責按照作業的輸入數據量，將之分解成若干任務，并為這些任務申請資源、監控這些任務的運行狀態，一旦發現某個任務運行失敗則重新為之申請資源。

（2）Framework Executor功能

為一個節點上的Map Task或者Reduce Task準備運行環境，包括準備各種jar包、二進制文件，設置必要的環境變量，進行必要的資源隔離，啟動Jetty Shuffle以為Reduce Task提供遠程數據拷貝服務等，接收來自Framework Scheduler的命令（啟動任務、殺死任務等），并執行。

通過上面的介紹可以知道，Framework Scheduler只負責運行一個Hadoop Job，而如果你對YARN比較熟悉，便會發現者正是YARN中的MapReduce ApplicationMaster做的事情，沒錯，Mesos與YARN的設計架構如此的相近，以至于我們很容易通過修改YARN 的任何一個ApplicationMaster，讓它作為一個Framework Scheduler運行在Mesos中。

最近Mesos提供了一個mesos-submit工具（https://github.com/apache/mesos/blob/trunk/docs/Using-the-mesos-submit-tool.md，注意，該工具尚不完善），該工具可以讓用戶的Framework Scheduler運行在任何一個Mesos Slave上，以防止客戶端運行過多的Framework Scheduler，這樣，Mesos的整個架構和工作流程已經變得與YARN相差無幾了。

為了讓大家更容易理解Mesos和YARN在架構上的相似性，下面給出了Mesos和YARN的組件對應表：

既然Mesos和YARN如此的相近，那么我們到底應該使用哪一個呢？或者說，哪一個系統更有前景？

就目前看來，YARN在以下幾個方面存在明顯優勢：（1）人力投入大。目前YARN有專門的公司（hortonwork）維護和開發 （2）知名度高。YARN之前從Hadoop 1.0中演化而來，繼承了Hadoop的知名度，且有大量公司和開發人員共享patch。然而，Mesos***優點的設計簡單、容易上手使用，它不像 YARN那樣，一個資源的分配過程要涉及到若干個狀態機，且每種狀態機十幾種狀態，十幾種事件。但穩定性看，兩個系統都處于研發和測試階段，離穩定可用還 有一段距離。

 原文鏈接：http://dongxicheng.org/category/apache-mesos/