众所周知，集群调度系统是现代数据中心举足轻重的组件，一个好的调度器，能提高集群资源利用率，实现自动化部署和高可用，节约用户投资，“让开发者最大可能地把精力集中到上层业务逻辑上”。考虑到时下各路调度系统眼花缭乱，小编打算从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）。（见下图）
http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41684.pdf
（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架构。（见下图）
http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/43438.pdf
关于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请求的资源远超过它的需要）。（见下图）
http://www.cl.cam.ac.uk/research/srg/netos/camsas/blog/2016-03-09-scheduler-architectures.html
但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的“共享状态”调度以及“乐观并发”策略。
http://queue.acm.org/detail.cfm?id=2898444
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）。
http://research.microsoft.com/pubs/232978/osdi14-paper-boutin.pdf
3. Hashicorp Nomad
Nomad是著名开源公司Hashicorp在2015年9月推出的一款分布式、高可用的开源集群管理工具，专为微服务和批量处理工作流设计，支持所有主流操作系统以及虚拟化、容器化或独立应用。现已在生产环境使用。Nomad支持跨数据中心跨区域数千节点的高扩展和任务调度，下图为Nomad跨区域调度示意图，转自Hashicorp官网。
https://www.nomadproject.io/docs/internals/architecture.html
Nomad也是基于共享状态的调度器，它是通过“Plan Queue”来维持一个全局共享的集群状态。下图为Nomad的一个完整Evaluation工作流，转自Hashicorp官网。
