眾所周知，叢集排程系統是現代資料中心舉足輕重的元件，一個好的排程器，能提高叢集資源利用率，實現自動化部署和高可用，節約使用者投資，“讓開發者最大可能地把精力集中到上層業務邏輯上”。考慮到時下各路排程系統眼花繚亂，小編打算從Google的三代叢集排程架構演進切入，對十個主流叢集排程系統進行分門別類大盤點。

開始盤點前，讓我們先快速回顧一下Google的三代叢集排程架構——中央式（Monolithic）、雙層式（Two-level）、共享狀態式（Shared-state）都有哪些特徵？

快速回顧：Google三代叢集資源排程架構

早在十多年前，Google就開始使用第一代叢集管理Borg技術管理資料中心。2013年，Google發表的Omega論文（Omega，a scalable scheduler for large compute clusters）詳細介紹了Google的三代叢集資源排程架構：中央式（Monolithic）、雙層式（Two-level）、共享狀態式（Shared-state）。（見下圖）

（1） 中央式排程器（Monolithic scheduler）

中央式排程器實質上就是一個單一的排程agent來負責所有請求，通常用在HPC（高效能運算）中。由於將資源的排程和作業的管理功能全部放到一個程序中完成，擴充套件性較差：首先，叢集規模受限。其次，很難引入新的排程策略，比如之前僅支援MapReduce作業，現在要支援流式作業，而將流式作業的排程策略嵌入到中央式排程器中是一項很難的工作。

（2） 雙層排程器（Two-level scheduler）

雙層排程器採用“分層”思想，上層是一個非常輕量級的的中央式排程器，下層是具體某個應用程式的排程器，如Hadoop、Storm、Spark、MPI等。這樣就可以減小“中心節點”的壓力，由原來的一個“中心”，變成二層“中心”；而且同一個叢集中多種應用接入，多種框架混部，有效提高分散式叢集的利用率。但是，這種“二級排程”也有缺陷：各應用無法感知叢集整體的使用狀況，只能等待上層排程推送資訊；再加上資源分配採用輪詢，在分配過程使用“悲觀鎖”（即PCC，Pessimistic Concurrency Control，悲觀併發訪問控制方式），併發粒度小，響應稍慢，缺乏一種有效的競爭機制。

（3）共享狀態排程器（Shared-state scheduler）

為克服雙層排程器的不足，Google提出了共享狀態排程。這種排程器將雙層排程器中的集中式資源排程模組簡化為持久化的“共享資料”（狀態）和針對這些資料的驗證程式碼——這裡的“共享資料”實際上就是整個叢集的實時資源使用資訊。共享狀態排程器最典型的代表就是Google的Omega系統，它也可理解為改進版的“雙層排程器”。通過將雙層排程器中的“共享資料”進行全域性持久化，任何應用都可以看到叢集資源資訊。而且資源申請採用“樂觀鎖”（即MVCC，Multi-Version Concurrency Control，多版本併發訪問控制方式），優先順序控制，大大提升併發性。

現在讓我們基於這三類排程策略，對時下十個主流叢集排程系統進行分門別類大盤點吧！

Monolithic篇

1. Google Borg

Borg作為Google的內部叢集管理系統已有十多年曆史了，但其細節資訊一直鮮少公開，直到去年Google發表的論文（Large-scale cluster management at Google with Borg）才第一次揭開它的神祕面紗。一個Borg叢集（即Cell）由一個邏輯中央控制器BorgMaster和若干代理節點Borglet組成，屬於Monolithic架構。（見下圖）

關於Borg架構的解讀，網上有一個有趣的段子，它將Borg架構比作黑社會，BorgMaster是黑老大，Borglet是底下的一幫小弟，而Borg的一套排程流程就像黑社會運作一趟毒品交易。（見下圖，轉自網路）

2. Kubernetes

Kubernetes是一個容器叢集的編排管理系統，主要面向跨Docker主機場景之下容器叢集的統一管理，據Wikipedia介紹，最初是由Google在2014年提出的開源專案，其開發設計思想深受Google的Borg系統影響。

Kubernetes屬於Monolithic架構，Kubernetes Master提供了叢集統一檢視的中心控制點，Node節點又稱作Minion，負責執行Master交付的任務。

3. Docker Swarm

Docker Swarm是Docker公司在2014年12月初發布的一套管理Docker叢集的工具。一套Docker Swarm架構由一個Swarm manager和一組Swarm節點組成，Swarm manager上執行Swarm daemon，使用者只需跟Swarm manager通訊，然後Swarm manager根據discovery service的資訊選擇一個Swarm節點來執行容器。典型的Monolithic架構。

4. 騰訊 Torca

Torca作為騰訊Typhoon雲平臺的資源排程子系統，已經在網頁搜尋、廣告方面廣泛應用。Torca屬於Monolithic架構，一個Torca叢集由一個Central Manager和若干Execute Server組成。Central Manager是叢集任務排程中心，Execute Server接收任務並負責相應執行。

5. 阿里飛天伏羲

“飛天”是阿里巴巴的雲端計算平臺，其中分散式排程系統被命名為“伏羲”（代號Fuxi）。伏羲主要負責叢集資源管理和任務排程，屬於Monolithic架構。系統有一個“Fuxi Master”的叢集控制中心，其餘每個Slave節點上會執行一個“Fuxi Agent”的守護程序，Fuxi Agent除了管理節點上執行的任務外，還負責收集該節點上的資源使用情況，並彙報給Fuxi Master。Fuxi Master與Fuxi Agent之間使用Heartbeat機制，以監測節點健康狀態。

Two-level篇

1. Apache Mesos

Apache Mesos是2009年加州大學伯克利分校AMPLab首先開發出的一款開源叢集管理軟體，主要用於搭建高效擴充套件的分散式系統來支援各式各樣不斷增長的Framework。Mesos以Framework的形式，提供兩級排程機制，即Two-level scheduler的典型代表。

Mesos Master協調全部的Mesos Slave，並確定每個節點的可用資源，聚合計算跨節點的所有可用資源的報告，然後向註冊到Master的Framework（作為Master的客戶端）發出資源邀約。Framework根據應用程式的需求，選擇接受或拒絕來自Master的資源邀約。一旦接受邀約，Master即協調Framework和Slave，排程參與節點上的任務，並在容器中執行，使得多種型別的任務可在同一個節點上同時執行。

下圖為Mesos“兩級排程機制”示意圖，圖中只展示了Hadoop和MPI兩種框架型別。

2. Apache Hadoop YARN

Apache Hadoop 是一個開源軟體框架，最初包含HDFS（Hadoop分散式檔案系統）和Hadoop MapReduce分散式計算引擎。自2012年8月開始，Apache Hadoop YARN成為Apache Hadoop的一個新子專案，其目的是讓Hadoop資料處理能力超越MapReduce。Hadoop YARN提供了一個更加通用的資源管理和分散式應用框架，不僅支援Hadoop MapReduce，而且MPI，圖處理，線上服務（比如Spark、Storm、HBase）等應用都可放到YARN上。

注：在 YARN 中，MapReduce 降級為一個分散式應用程式的角色（但仍是一個非常流行且有用的角色），現在稱為 MRv2。MRv2 是經典 MapReduce 引擎（現在稱為 MRv1）的重現，執行在 YARN 之上。

MRv1屬於Monolithic架構，由一個JobTracker和若干TaskTracker組成。JobTracker負責資源管理以及Job的生命週期管理，TaskTracker負責執行JobTracker分配的Task，並週期性向JobTracker彙報Task進度及狀態。（見下圖）

YARN將MRv1中JobTracker的兩大職責——資源管理和Job管理，分別交給兩個角色負責。一個是全域性的ResourceManager，一個是每個應用一個的ApplicationMaster。ResourceManager是整個系統仲裁應用之間資源分配的最高權威，而每個應用一個的ApplicationMaster負責向ResourceManager協商資源，並與NodeManager協同工作來執行和管理task。（見下圖）

最近CamSaS專案組（Cambridge System at Scale）在Cambridge官網發表了一篇部落格——The evolution of cluster scheduler architectures，文中認為YARN屬於“有限的兩級排程”。因為YARN的ApplicationMaster只能將應用層的Tasks放置在已有容器裡，無法挑選資源（除非它向ResourceManager請求的資源遠超過它的需要）。（見下圖）

但Google在2013年的Omega論文中（Omega，a scalable scheduler for large compute clusters），直接將 YARN歸到了Monolithic架構。

Shared-state篇

1. Google Omega

如前所述，Omega使用基於共享狀態的策略，每個排程器擁有全域性資源檢視，具有整個叢集全部負載資訊的完全訪問許可權。Omega中的“元排程器”（Cell State）維護著一個全域性共享的叢集狀態，而每個排程器具有一個私有叢集狀態副本。

ACM Queue（美國計算機學會ACM發行的商業雜誌）最近也發表了一篇文章（Borg, Omega, and Kubernetes：Lessons learned from three container-management systems over a decade），詳細介紹了Omega的“共享狀態”排程以及“樂觀併發”策略。

2. 微軟Apollo

Apollo是已經部署在微軟實際生產環境中的叢集排程系統，每天負責上萬臺機器上數以百萬計的高併發計算任務的排程和管理。Apollo使用基於共享狀態的策略。每個排程器（即Job Manager，負責Job的生命週期管理）擁有全域性資源檢視，具有整個叢集的完全訪問許可權。Process Node負責管理所在server上的本地資源和排程。Resource Monitor負責維護一個全域性共享的叢集狀態，即持續收集叢集所有Process Node的負載資訊，向每個Job Manager提供叢集狀態的全域性檢視。見下圖，轉自Microsoft Research（微軟研究院）關於Apollo的論文（Apollo: Scalable and Coordinated Scheduling for Cloud-Scale Computing）。

3. Hashicorp Nomad

Nomad是著名開源公司Hashicorp在2015年9月推出的一款分散式、高可用的開源叢集管理工具，專為微服務和批量處理工作流設計，支援所有主流作業系統以及虛擬化、容器化或獨立應用。現已在生產環境使用。Nomad支援跨資料中心跨區域數千節點的高擴充套件和任務排程，下圖為Nomad跨區域排程示意圖，轉自Hashicorp官網。

Nomad也是基於共享狀態的排程器，它是通過“Plan Queue”來維持一個全域性共享的叢集狀態。下圖為Nomad的一個完整Evaluation工作流，轉自Hashicorp官網。