## 原理與架構 首先，再次需要強調 Mesos 自身只是一個資源調度框架，并非一整套完整的應用管理平臺，所以只有 Mesos 自己是不能干活的。但是基于 Mesos，可以比較容易地為各種應用管理框架或者中間件平臺（作為 Mesos 的應用）提供分布式運行能力；同時多個框架也可以同時運行在一個 Mesos 集群中，提高整體的資源使用效率。 Mesos 對自己定位范圍的劃分，使得它要完成的任務很明確，其它任務框架也可以很容易的與它進行整合。 ### 架構 下面這張基本架構圖來自 Mesos 官方。  可以看出，Mesos 采用了經典的主-從（master-slave）架構，其中主節點（管理節點）可以使用 zookeeper 來做 HA。 Mesos master 服務將運行在主節點上，Mesos slave 服務則需要運行在各個計算任務節點上。 負責完成具體任務的應用框架們，跟 Mesos master 進行交互，來申請資源。 ### 基本單元 Mesos 中有三個基本的組件：管理服務（master）、任務服務（slave）以及應用框架（framework）。 #### 管理服務 - master 跟大部分分布式系統中類似，主節點起到管理作用，將看到全局的信息，負責不同應用框架之間的資源調度和邏輯控制。應用框架需要注冊到管理服務上才能被使用。 用戶和應用需要通過主節點提供的 API 來獲取集群狀態和操作集群資源。 #### 任務服務 - slave 負責匯報本從節點上的資源狀態（空閑資源、運行狀態等等）給主節點，并負責隔離本地資源來執行主節點分配的具體任務。 隔離機制目前包括各種容器機制，包括 LXC、Docker 等。 #### 應用框架 - framework 應用框架是實際干活的，包括兩個主要組件： * 調度器（scheduler）：注冊到主節點，等待分配資源； * 執行器（executor）：在從節點上執行框架指定的任務（框架也可以使用 Mesos 自帶的執行器，包括 shell 腳本執行器和 Docker 執行器）。 應用框架可以分兩種：一種是對資源的需求是會擴展的（比如 Hadoop、Spark 等），申請后還可能調整；一種是對資源需求大小是固定的（MPI 等），一次申請即可。 ### 調度 對于一個資源調度框架來說，最核心的就是調度機制，怎么能快速高效地完成對某個應用框架資源的分配，是核心競爭力所在。最理想情況下（大部分時候都無法實現），最好是能猜到應用們的實際需求，實現最大化的資源使用率。 Mesos 為了實現盡量優化的調度，采取了兩層（two-layer）的調度算法。 #### 算法基本過程 調度的基本思路很簡單，master 先全局調度一大塊資源給某個 framework，framework 自己再實現內部的細粒度調度，決定哪個任務用多少資源。兩層調度簡化了 Mesos master 自身的調度過程，通過將復雜的細粒度調度交由 framework 實現，避免了 Mesos master 成為性能瓶頸。 調度機制支持插件機制來實現不同的策略。默認是 Dominant Resource Fairness（DRF）。 *注：DRF 算法細節可以參考論文《Dominant Resource Fairness: Fair Allocation of Multiple Resource Types》。其核心思想是對不同類型資源的多個請求，計算請求的主資源類型，然后根據主資源進行公平分配。* #### 調度過程 調度通過 offer 發送的方式進行交互。一個 offer 是一組資源，例如 `<1 CPU, 2 GB Mem>`。 基本調度過程如下： * 首先，slave 節點會周期性匯報自己可用的資源給 master； * 某個時候，master 收到應用框架發來的資源請求，根據調度策略，計算出來一個資源 offer 給 framework； * framework 收到 offer 后可以決定要不要，如果接受的話，返回一個描述，說明自己希望如何使用和分配這些資源來運行某些任務（可以說明只希望使用部分資源，則多出來的會被 master 收回）； * 最后，master 則根據 framework 答復的具體分配情況發送給 slave，以使用 framework 的 executor 來按照分配的資源策略執行任務。 具體給出一個例子，某從節點向主節點匯報自己有 `<4 CPU, 8 GB Mem>` 的空閑資源，同時，主節點看到某個應用框架請求 `<3 CPU, 6 GB Mem>`，就創建一個 offer `<slave#1, 4 CPU, 8 GB Mem>` 把滿足的資源發給應用框架。應用框架（的調度器）收到 offer 后覺得可以接受，就回復主節點，并告訴主節點希望運行兩個任務：一個占用 `<1 CPU, 2 GB Mem>`，一個占用 一個占用 `<2 CPU, 4 GB Mem>`。主節點收到任務信息后分配任務到從節點上進行運行（實際上是應用框架的執行器來負責執行任務）。任務運行結束后資源可以被釋放出來。 剩余的資源還可以繼續分配給其他應用框架或任務。 應用框架在收到 offer 后，如果 offer 不滿足自己的偏好（例如希望繼續使用上次的 slave 節點），則可以選擇拒絕 offer，等待 master 發送新的 offer 過來。另外，可以通過過濾器機制來加快資源的分配過程。 #### 過濾器 framework 可以通過過濾器機制告訴 master 它的資源偏好，比如希望分配過來的 offer 有哪個資源，或者至少有多少資源等。 過濾器可以避免某些應用資源長期分配不到所需要的資源的情況，加速整個資源分配的交互過程。 #### 回收機制 為了避免某些任務長期占用集群中資源，Mesos 也支持回收機制。 主節點可以定期回收計算節點上的任務所占用的資源，可以動態調整長期任務和短期任務的分布。 ### HA 從架構上看，最為核心的節點是 master 節點。除了使用 ZooKeeper 來解決單點失效問題之外，Mesos 的 master 節點自身還提供了很高的魯棒性。 Mesos master 節點在重啟后，可以動態通過 slave 和 framework 發來的消息重建內部狀態，雖然可能導致一定的時延，但這避免了傳統控制節點對數據庫的依賴。 當然，為了減少 master 節點的負載過大，在集群中 slave 節點數目較多的時候，要避免把各種通知的周期配置的過短。實踐中，可以通過部署多個 Mesos 集群來保持單個集群的規模不要過大。