深入淺出Mesos（二）：Mesos的體系結構和工作流

我們來研究下上圖的事件流程。上一篇談到，Slave是運作在實體或虛拟伺服器上的Mesos守護程序，是Mesos叢集的一部分。Framework由排程器（Scheduler）應用程式和任務執行器（Executor）組成，被注冊到Mesos以使用Mesos叢集中的資源。

Slave 1向Master彙報其空閑資源：4個CPU、4GB記憶體。然後，Master觸發配置設定政策子產品，得到的回報是Framework 1要請求全部可用資源。

Master向Framework 1發送資源邀約，描述了Slave 1上的可用資源。

Framework的排程器（Scheduler）響應Master，需要在Slave上運作兩個任務，第一個任務配置設定<2 CPUs, 1 GB RAM>資源，第二個任務配置設定<1 CPUs, 2 GB RAM>資源。

最後，Master向Slave下發任務，配置設定适當的資源給Framework的任務執行器（Executor）,接下來由執行器啟動這兩個任務（如圖中虛線框所示）。 此時，還有1個CPU和1GB的RAM尚未配置設定，是以配置設定子產品可以将這些資源供給Framework 2。

為了實作在同一組Slave節點集合上運作多任務這一目标，Mesos使用了隔離子產品， 該子產品使用了一些應用和程序隔離機制來運作這些任務。 不足為奇的是，雖然可以使用虛拟機隔離實作隔離子產品，但是Mesos目前子產品支援的是容器隔離。 Mesos早在2009年就用上了Linux的容器技術，如cgroups和Solaris Zone，時至今日這些仍然是預設的。 然而，Mesos社群增加了Docker作為運作任務的隔離機制。 不管使用哪種隔離子產品，為運作特定應用程式的任務，都需要将執行器全部打包，并在已經為該任務配置設定資源的Slave伺服器上啟動。 當任務執行完畢後，容器會被“銷毀”，資源會被釋放，以便可以執行其他任務。

我們來更深入地研究一下資源邀約和配置設定政策，因為這對Mesos管理跨多個Framework和應用的資源，是不可或缺的。 我們前面提到資源邀約的概念，即由Master向注冊其上的Framework發送資源邀約。 每次資源邀約包含一份Slave節點上可用的CPU、RAM等資源的清單。 Master提供這些資源給它的Framework，是基于配置設定政策的。配置設定政策對所有的Framework普遍适用，同時适用于特定的Framework。 Framework可以拒絕資源邀約，如果它不滿足要求，若此，資源邀約随即可以發給其他Framework。 由Mesos管理的應用程式通常運作短周期的任務，是以這樣可以快速釋放資源，緩解Framework的資源饑餓； Slave定期向Master報告其可用資源，以便Master能夠不斷産生新的資源邀約。 另外，還可以使用諸如此類的技術， 每個Fraamework過濾不滿足要求的資源邀約、Master主動廢除給定周期内一直沒有被接受的邀約。

配置設定政策有助于Mesos Master判斷是否應該把目前可用資源提供給特定的Framework，以及應該提供多少資源。 關于Mesos中使用資源配置設定以及可插拔的配置設定子產品，實作非常細粒度的資源共享，會單獨寫一篇文章。 言歸正傳，Mesos實作了公平共享和嚴格優先級（這兩個概念我會在資源配置設定那篇講）配置設定子產品， 確定大部分用例的最佳資源共享。已經實作的新配置設定子產品可以處理大部分之外的用例。

現在來回答談及Mesos時，“那又怎樣”的問題。 對于我來說，令人興奮的是Mesos集四大好處于一身（概述如下），正如我在前一篇文章中所述，我目測Mesos将為下一代資料中心的作業系統核心。

效率 - 這是最顯而易見的好處，也是Mesos社群和Mesosphere經常津津樂道的。

可擴充性 - 為可擴充而設計，這是我真心欣賞Mesos架構的地方。 這一重要屬性使資料可以指數級增長、分布式應用可以水準擴充。 我們的發展已經遠遠超出了使用巨大的整體排程器或者限定群集節點數量為64的時代，足矣承載新形式的應用擴張。

Mesos可擴充設計的關鍵之處是采用兩級排程架構。 使用Framework代理任務的實際排程，Master可以用非常輕量級的代碼實作，更易于擴充叢集發展的規模。 因為Master不必知道所支援的每種類型的應用程式背後複雜的排程邏輯。 此外，由于Master不必為每個任務做排程，是以不會成為容量的性能瓶頸，而這在為每個任務或者虛拟機做排程的整體排程器中經常發生。