Mesos Architecture
上圖顯示了 Mesos 的主要組成部分。 Mesos 由一個 master daemon 來管理 slave daemon 在每個集羣節點上的運行, mesos applications （ 也稱爲 frameworks ）在這些 slaves 上運行 tasks。
Mesos master&slave
首先，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大量使用這個模型。
Zookeeper
Mesos底層實際上依賴於Zookeeper，爲了保證分佈式存儲最終一致性。在Mesos運行過程中產生了一些數據，最終都會落在Zookeeper。因爲Mesos是多個master，爲了達到HA的需求，只要一個master活的，那麼整個服務就能得到保證。
protobuf
Mesos內部在通信裏面選擇了protobuf協議。好處是比較流行，各個語言的庫都比較多，結構化的語義也比較強，所以Mesos內部選擇了protobuf。
Master 使用 Resource Offers 實現跨應用細粒度資源共享，如 cpu、內存、磁盤、網絡等。 master 根據指定的策略來決定分配多少資源給 framework ，如公平共享策略，或優先級策略。 爲了支持更多樣性的策略，master 採用模塊化結構，這樣就可以方便的通過插件形式來添加新的分配模塊。
在 Mesos 上運行的 framework 由兩部分組成：
一個是 scheduler ，通過註冊到 master 來獲取集羣資源。
另一個是在 slave 節點上運行的 executor 進程，它可以執行 framework 的 task 。 Master 決定爲每個 framework 提供多少資源， framework 的 scheduler 來選擇其中提供的資源。當 framework 同意了提供的資源，它通過 master 將 task發送到提供資源的slaves 上運行。
資源供給的一個例子下圖描述了一個 Framework 如何通過調度來運行一個 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
當 Tasks 完成和有新的空閒資源時，Resource Offer 會不斷重複這一個過程。、
當 Mesos 提供的瘦接口允許其來擴展和允許 frameworks 相對獨立的參與進來，一個問題將會出現： 一個 framwork 的限制如何被滿足在不被 Mesos 對這些限制所知曉的情況下？
例如， 一個 framework 如何得到數據本地化在不被 Mesos所知曉哪個節點存儲着被該 framwork 所需要的數據？Mesos 通過簡單的寄予 frameworks 能夠拒絕 offers 的能力來回答了這個問題。 一個 framework 將拒絕 不滿足其限制要求的 offers 並接受滿足其限制要求的 offers.
特殊情況下，我們找到一個簡單的策略 delay scheduling， 在該 frameworks 等待 一個限制時間來獲取存儲輸入數據的節點， 並生成接近的優化過得數據點。
本篇主要分享了mesos的組成部分和事件流程。下週會詳細介紹Mesos的概念解析和工作原理。
敬請期待。