## Mesos 架構  上面的這張圖像我們展示了mesos架構的主要組件.mesos架構包含一個master守護進程，它管理了多個運行在集群各節點上的agent守護進程,Mesos frameworks(應用框架)負責在這些agent上運行task(任務) master進程通過資源分派(resources offers)的方式，在應用框架間實現細粒度的資源(CPU,RAM等)共享.每次資源分派包含這樣的一個列表，<agent ID, resource1: amount1, resource2: amount2, …> >(注意: 關鍵字slave已經被廢棄，由agent來替換, driver-based frameworks will still receive offers with slave ID, whereas frameworks using the v1 HTTP API receive offers with agent ID). master進程根據既定的組織策略來決定為每個框架提供多少資源，組織策略比如：平均分配策略 或者 按嚴格的優先級的策略.為了支持多樣化的策略，master采用了一種模塊化的架構，這使得通過插件方式來添加新的資源分配模塊變得很容易. 運行于Mesos之上的framework包含兩個組件： * 調度器：向master注冊,向master說明需要使用哪些，多少被分派的資源 * 執行器：在agent節點上運行該應用框架的任務（查看[App/Framework development guide](http://mesos.apache.org/documentation/latest/app-framework-development-guide/)獲取更多關于調度器與執行器的內容） master進程可以決定為每個framework提供多少資源，framework的調度器選擇去使用哪些被master分派出來的資源.當一個框架接收一個資源分派的時候，它提交給mesos一個關于它所運行的任務的描述。然后，mesos將在對應的agent節點上運行任務. ### 資源分派的例子 下面的圖片中的例子顯示了，一個framework(框架)如何去調度任務的執行  我們來看看上圖中所發生的事件： 1. agent 1 節點向master匯報它還有4顆CPU 和4G的內存空閑.master隨后調用資源分配策略模塊，告訴framework 1 可以使用這些資源了 2. master發送了一個資源分派列表，告訴framework1具體有哪些資源在agent1上是可用的 3. framework的調度器回復master,它需要在agent1上運行2個任務，第一個任務使用<2 CPUs, 1 GB RAM>，第二個任務使用<1 CPUs, 2 GB RAM>。 4. 最后，master將任務發送給agent，分配相應的資源給framework執行器，依次啟動2個任務(圖中虛線描繪的部分).由于還有1顆 CPU和1GB的內存沒有被分配，資源分配模塊可能會將他們分配給framework2 在任務完成之后,資源被釋放。資源分派模塊將重復上面的步驟，重新進行資源分配。 通過這種低依賴性的接口設計，mesos可以實現應用框架的縮放，并且允許各種框架獨立的發展演進。但是還遺留了一個問題：在mesos不知道應用框架的特殊限制條件的時候，如何去滿足這些限制條件？比如：Mesos不知道哪個agent節點存儲著應用所需要的數據的時候，如何知道把任務放到哪個節點實現數據獲取的本地化？Mesos的做法非常簡單，就是賦予framework拒絕資源分派的能力.框架拒絕不滿足限制條件的資源分派，去接收滿足限制條件的資源分派.特別說明的是，我們已經找到一種非常簡單的策略叫做延遲調度.(In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality.)(這段話譯者暫時沒能理解，保留原文) 了解關于 Mesos架構的更多內容，請參考 [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf).