作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
Mesos是诞生于UC Berkeley的一个研究项目，它的设计动机是解决编程模型和计算框架在多样化环境下，不同框架间的资源隔离和共享问题。
尽管他的直接设计动机与YARN稍有不同，但它的架构和实现策略与YARN类似。当前部分公司在使用Mesos管理集群资源，比如外国的Twitrer，国内的豆瓣等。
Mesos官方链接 ：http://mesos.apache.org/
豆瓣的dpark项目 ：https://github.com/douban/dpark
一.Mesos基本架构
如下图所示，Apache Mesos由以下四个组件组成，接下来我们将详细对这些组件进行介绍。
1>.Mesos Master
Mesos Master是整个系统的核心，负载管理整个系统中的资源和接入的各个框架（Framework），并将Mesos Slave上的资源按照某种策略分配给框架。
为了防止Mesos Master出现故障后导致集群不可用，Mesos允许用户配置多个Mesos Master，并通过Zookeeper进行管理，当主Mesos Master出现故障后，Zookeeper可马上从备用Master中选择一个提升为新的主Mesos Master。
2>.Mesos Slave
Mesos Slave负责接受并执行来自Mesos Master的命令，并定时将任务执行状态汇报给Mesos Master。Mesos Slave将节点上的资源使用情况发送给Mesos Master，由Mesos Master中的Allocaltor模块决定将资源分配给哪个Feamework，需要注意的是，当Mesos仅考虑了CPU和内存两种资源。
为了避免任务之间互相干扰，同YARN一样，Mesos Slave采用了轻量级资源隔离机制Cgroups。
3>.Framework Scheduler
Framework是指外部的框架，如MPI，MapReduce，Spark等，这些框架可通过注册的方式接入Mesos，以便Mesos进行统一资管理和资源分配。Mesos要求接入的框架必须有一个调度器模块Framework Scheduler，该调度器负责框架内部的任务调度。
一个Framework在Mesos上工作流程为：首先通过自己的调度器向Mesos注册，并获取Mesos分配给自己的资源，然后再由自己的调度器将这些资源分配给框架中的任务。也就是说，同YARN一样，Mesos采用了双层调度框架：
（1）第一层，由Mesos将资源分配给框架；
（2）第二层 ，框架自己的调度器将资源非配给内部的各个任务。
当前Mesos支持三种语言编写的调度器，分别是C++，Java和Python，为了向各种调度器提供统一的接入方式，Mesos内部采用C++实现一个MesosSchedulerDriver（调度器驱动器），Framework的调度器可调用该Driver中的接口与Mesos Master交互，完成一系列功能（如注册，资源分配等）。
4>.Framework Executor
Framework Executor主要用于启动框架内部的任务。由于不同的框架，启动任务的接口或者方式不对，当一个新的框架要接入Mesos时，通常需要指定专有的Executor，宜高速Mesoss如何启动该框架中的任务。为了给各种框架提供统一的编写方式，Mesos内部采用C++实现了一个MesosExecutorDiver（执行器驱动器），Framework可通过该驱动器的相关接口高速Mesos启动任务的方法。
二.Mesos资源分配策略
Mesos中最核心的问题是如何构建一个兼具良好扩展性和性能调度模型以支持各种计算框架。由于不同框架可能有不同的调度需求（这往往跟它的编程模型，通信模型，任务依赖关系和数据放置策略等因素相关），因此，为Mesos设计一个好的调度器模型是一个极具挑战性的工作。
一种可能性的解决方案是构建一个具有丰富表达能力的中央调度器，该调度器接受来自不同框架的详细需求描述，比如资源需求，任务调度顺序和组织关系等，然后为这些任务构建一个全局的调度序列。但是，在真是系统中，由于每种计算框架具有不同的调度需求，且有写框架的调度需求非常复杂，因此，提供一个具有丰富表达能力的API以捕获所有框架的需求是不太可能，也就是说，该方案过于理想化，在真是系统中很难实现。
Mesos提供了一种简化方案：将资源调度的控制授权给各个框架。Mesos负责按照一些简单的策略（比如FIFO，Fari等）将资源分配给各个框架，而框架内部调度器则根据一些个性化的需求将得到的资源进一步分配个各个作业。
考虑到Mesos缺少对各个框架的实际资源需求的了解，为保证框架能高效地获取到自己的需要的资源，它提供了以下三个机制。
1>.资源拒绝
如果Mesos为了某个服务分配的资源不符合它的要求，则框架可拒绝该资源直到出现满足自己需求的资源。该机制使得框架在复杂的资源约束条件下，还能够保证Mesos设计简单和具有良好的扩展性；
2>.资源过滤
每次发生资源协调时，Mesos Master均要与Framework Scheduler进行通信，如果有些框架总是拒绝某些节点上的资源，那么由于额外的通信开销会使得调度性变得低效。为了避免不必要的通信，Mesos提供了资源过滤机制，允许框架只接受来自“剩余资源量大于L的Mesos Slave”或者“位于特定列表中的Mesos Slave”上的资源。
3>.资源回收
如果某个框架在一定的时间内没有为分配的资源返回对应的任务，则Mesos将回收为其分配的资源，并将这些资源重新分配给其他框架。
为了支持多种资源调度，Mesos采用了主资源公平调度算法（Dominant ResourceFairness，DRF），该算法扩展了最大最小公平（max-min fairness）算法，使其能够支持多维度资源的调度。
三.Mesos与YARN对比
尽管YARN和Mesos诞生于不同的公司和研究机构，但它们的架构却大同小异，如下图所示，给出了它们内部的组织对应关系。
如下表所示，从设计目标，容错性，在线升级，调度模型，调度算法，资源隔离等方面对比了Mesos和YARN。
总结起来，YARN起源于大数据领域，目前已经形成了良好的生态系统，与其他大数据系统结合紧密，而Mesos源自于集群化服务部署，因而更加适合服务部署与管理。
四.资源管理系统架构演化
Google在论文“Omega:Flexible,scalable schedulers for large compute clusters”中介绍了Google经历的三代资源调度器的架构，如下图所示。
分别是中央调度器（类似于Hadoop JobTracker，但是支持多种类型作业调度），双层调度架构（类似于Mesos和YARN）和共享状态架构（Omega），并分别讨论了这几个架构的优缺点，重点剖析了最新资源管理系统Omega的相关实现。
1>.集中式架构
集中式调度器（Monolithic scheduler）的特点是，资源的调度和应用程序的管理功能全部放到一个进程中完成，开源典型的代表是MRv1 JobTracker的实现。这种设计方式的缺点很明显，扩展性差：首先，集群规模受限，其次，新的调度策略难以融入现有代码中，比如之前仅支持MapReduce作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央式调度器中是一项很难得工作。
Omega论文中提到了一种对集中式调度器的优化方案：将每种调度策略放到单独一个路径（模块）中，不同的作业由不同的调度策略进行调度。这种方案在作业量和集群规模比较小时，能大大缩短作业响应时间，但由于所有调度策略仍在一个集中式的组件中，整个系统扩展性并没有变得更好。
2>.双层调度架构
为了解决集中式调度器的不足，双层调度器（Two-level scheduler）是一种很容易想到的解决之道。可将它看作一种分而治之的机制或则策略下放机制：双层调度器仍保存一个经简化的集中式资源调度器，但具体任务相关的调度策略则下放到各个应用程序调度器中完成。这种调度器典型代表是Mesos和YARN。Omega论文重点介绍了Mesos，Mesos是Twitter开源的资源管理系统，正如上面我们提到的，Mesos调度器由两部分组成，分别是资源调度器和框架（应用程序）调度器，其中，资源调度器负责将集群中的资源分配给各个框架（应用程序），而框架（应用程序）调度器则负责将资源进一步分配给内部的各个任务，用户很容易将一种框架或者系统接入Mesos，当然，很多框架已经成功接入了Mesos中，包括Hadoop，MPI，Spark等。
双层调度器的特点是，各个框架调度器并不知道整个集群资源的使用情况，只是被动的接受资源；资源调度器仅将可用的资源推送给各个框架，而框架自己选择使用还是拒绝这些资源；一旦框架接受到新资源后，再进一步将资源分配给其内部的任务，进而实现双层调度。
然而，双层调度的缺点也是非常明显的：
（1）各个框架无法知道整个集群的实时资源使用情况
很多框架不需要知道整个集群的实时资源使用情况就可以运行的很顺畅，但是对于其他的一些应用，为了提供实时资源使用情况可以挖掘潜在的优化空间，比如，当集群非常繁忙时，一个服务在一个节点上运行失败了，此时应该选择换一个节点重新运行它呢，还是在这个节点上在此尝试运行？通常而言，换一个节点可能会更有利（排除硬件故障和即诶案环境问题导致失败），但是，如果此时集群非常繁忙，所以节点只剩下小于5GB的内存，而这个服务需要10GB内存，那么换一个节点可能意味着长时间等待资源释放，而这个等待时间是无法确定的。
（2）采用被关锁，并发粒度小
在数据库领域，悲观锁和乐观锁的争论一直不休，悲观锁通常采用锁机制控制并发，这会大大降低性能，而乐观锁则采用多版本并发控制，典型代表是MySQL InnoDB，这种机制通过多版本方式控制并发，可大大提升性能。
在YARN/Mesos中，在任意一个时刻，Mesos资源调度器只会将某些资源推送给一个框架，等到该框架返回资源使用情况后，才能够将资源再次推动给其他框架，因此，YARN/Mesos资源调度器中实际上有一个全局锁，这大大限制了系统的并发性。
3>.共享状态架构
为了克服双层调度器的以上两个缺点，Google开发了下一代资源管理系统Omega，Omega是一种基于共享状态的调度器（Shared State Scheduler），该调度器将双层调度器中的集中式资源调度模块简化成了一些持久化的共享数据（状态）和针对这些数据的验证代码，而这里的“共享数据”实际上就是整个集群的实时资源使用信息。一旦引入了共享数据后，共享数据的并发访问方式就成为该系统设计的核心，而Omega则采用了传统数据库中基于多版本的并发访问控制方式（也称为“乐观锁”），这大大提升了Omega的并发性。
由于Omega不再有集中式的调度模块，因此，不能像Mesos或者YARN集群那样，在一个统一模块完成以下功能：对整个集群中的所有资源分组，限制没类应用程序的资源使用量，限制每个用户的资源使用量，限制每个用户的资源使用量等。这些全部由各个应用程序调度器自我管理和控制，根据论文所属，Omega只是将优先级这一限制放到了共享数据的验证代码中，即当同时有多个应用程序申请同一份资源时，优先级最高的哪个应用程序将获得该资源，其他资源限制全部放到各个子调度器。 引入多版本并发控制后，限制该机制性能的一个因素是资源访问冲突的次数，冲突次数越多，系统性能下降得越快，而Google通过实际负载测试证明，这种方式的冲突次数是完全可以接受的。 Omega论文中谈到，Omega是从Google现有系统上演化而来的。也就是从类似于YARN或者Mesos的系统改造而来的，经过前面的介绍后，有心的读者会发现，可以很容易将YARN或者Mesos改造成一个类Omega的系统，有兴趣的读者可以尝试一下完成这项工作。
