重新認(rèn)識(shí)Mesos的設(shè)計(jì)架構(gòu)
Mesos中包含四類主要的服務(wù)（實(shí)際上是一個(gè)socket server），它們分別是Mesos Master，Mesos Slave，SchedulerProcess和ExecutorProcess，它們之間通過Protocal Buffer消息進(jìn)行通信，每種服務(wù)內(nèi)部注冊(cè)了若干種Protocal Buffer消息處理器，一旦收到某種消息，則會(huì)調(diào)用相應(yīng)的消息處理器進(jìn)行處理。除了以上四種服務(wù)之外，Mesos還對(duì)外提供了三種可編程組件，分別是 Alloctor、Framework Scheduler和Framework Executor，編寫這幾個(gè)組件必須按照要求實(shí)現(xiàn)了幾個(gè)接口，而這些接口將分別被下圖中相鄰的服務(wù)調(diào)用。
大部分人看到以上Mesos架構(gòu)后，均會(huì)認(rèn)為Framework必須是一個(gè)通用的框架，比如MapReduce、Storm、Spark等，而 Mesos Master負(fù)責(zé)將資源分配給各個(gè)框架，而各個(gè)框架的Scheduler進(jìn)一步將資源分配給其內(nèi)部的各個(gè)應(yīng)用程序。這種觀念是錯(cuò)誤的，是對(duì)Mesos架構(gòu) 的一種錯(cuò)誤解讀。
事實(shí)上，F(xiàn)ramework不僅可以是通用的框架，也可以是像Hadoop的Job或者YARN的Application那樣的簡單計(jì)算任務(wù)，也就 是說，F(xiàn)ramework并需要一定是一個(gè)“Framework”，或者一個(gè)長時(shí)間運(yùn)行的服務(wù)（比如JobTracker等），也可以是一個(gè)短生命周期的 Job或者Application。如果讓Framework對(duì)應(yīng)一個(gè)Hadoop Job，則可以這樣設(shè)計(jì)Framework Scheduler和Framework Executor：
（1）Framework Scheduler功能
Framework Scheduler負(fù)責(zé)按照作業(yè)的輸入數(shù)據(jù)量，將之分解成若干任務(wù)，并為這些任務(wù)申請(qǐng)資源、監(jiān)控這些任務(wù)的運(yùn)行狀態(tài)，一旦發(fā)現(xiàn)某個(gè)任務(wù)運(yùn)行失敗則重新為之申請(qǐng)資源。
（2）Framework Executor功能
為一個(gè)節(jié)點(diǎn)上的Map Task或者Reduce Task準(zhǔn)備運(yùn)行環(huán)境，包括準(zhǔn)備各種jar包、二進(jìn)制文件，設(shè)置必要的環(huán)境變量，進(jìn)行必要的資源隔離，啟動(dòng)Jetty Shuffle以為Reduce Task提供遠(yuǎn)程數(shù)據(jù)拷貝服務(wù)等，接收來自Framework Scheduler的命令（啟動(dòng)任務(wù)、殺死任務(wù)等），并執(zhí)行。
通過上面的介紹可以知道，F(xiàn)ramework Scheduler只負(fù)責(zé)運(yùn)行一個(gè)Hadoop Job，而如果你對(duì)YARN比較熟悉，便會(huì)發(fā)現(xiàn)者正是YARN中的MapReduce ApplicationMaster做的事情，沒錯(cuò)，Mesos與YARN的設(shè)計(jì)架構(gòu)如此的相近，以至于我們很容易通過修改YARN 的任何一個(gè)ApplicationMaster，讓它作為一個(gè)Framework Scheduler運(yùn)行在Mesos中。
最近Mesos提供了一個(gè)mesos-submit工具（https://github.com/apache/mesos/blob/trunk/docs/Using-the-mesos-submit-tool.md，注意，該工具尚不完善），該工具可以讓用戶的Framework Scheduler運(yùn)行在任何一個(gè)Mesos Slave上，以防止客戶端運(yùn)行過多的Framework Scheduler，這樣，Mesos的整個(gè)架構(gòu)和工作流程已經(jīng)變得與YARN相差無幾了。
為了讓大家更容易理解Mesos和YARN在架構(gòu)上的相似性，下面給出了Mesos和YARN的組件對(duì)應(yīng)表：
| Mesos中的組件 | YARN中的組件 | 功能 |
| Mesos Master | Resource Manager | 整個(gè)集群的資源管理和調(diào)度 |
| Mesos Slave | Node Manager | 單個(gè)節(jié)點(diǎn)的資源管理（資源隔離、匯報(bào)等）、任務(wù)啟動(dòng)等 |
| Framework Executor | ||
| Framework Scheduler | ApplicationMaster | 單個(gè)應(yīng)用程序的管理和資源二次調(diào)度，基本操作均包括注冊(cè)、資源申請(qǐng)/獲取、資源分配（給內(nèi)部的任務(wù)）等。 |
既然Mesos和YARN如此的相近，那么我們到底應(yīng)該使用哪一個(gè)呢？或者說，哪一個(gè)系統(tǒng)更有前景？
就目前看來，YARN在以下幾個(gè)方面存在明顯優(yōu)勢：（1）人力投入大。目前YARN有專門的公司（hortonwork）維護(hù)和開發(fā) （2）知名度高。YARN之前從Hadoop 1.0中演化而來，繼承了Hadoop的知名度，且有大量公司和開發(fā)人員共享patch。然而，Mesos***優(yōu)點(diǎn)的設(shè)計(jì)簡單、容易上手使用，它不像 YARN那樣，一個(gè)資源的分配過程要涉及到若干個(gè)狀態(tài)機(jī)，且每種狀態(tài)機(jī)十幾種狀態(tài)，十幾種事件。但穩(wěn)定性看，兩個(gè)系統(tǒng)都處于研發(fā)和測試階段，離穩(wěn)定可用還 有一段距離。
