“Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter得到广泛使用”------百度百科。
一、出现背景随着互联网的发展，各种大数据计算框架不断出现，支持离线处理的MapReduce、在线处理的Storm，迭代计算框架Spark、及流式处理框架S4……各种分布式计算框架应运而生，各自解决某一类应用中的问题。而在互联网公司中，几种不同的框架都可能会被采用。考虑到资源的利用率、运维成本、数据共享等因素，我们往往会把不同的计算框架部署到一个公共的集群中，使其共享集群资源，而不同任务往往需要的资源（CPU、内存、网络I/O等）不同，它们运行在同一个集群中不免会相互干扰、资源竞争导致效率低下，因此就诞生了资源统一管理与调度平台，两个典型代表---Mesos和Yarn（关于Yarn笔者在之前文章中介绍过）。
二、Mesos框架1、Mesos的总体架构
同其他分布式系统一样，Apache Mesos也采用了Master/Slave结构，为解决Master单点故障，将Master做的尽可能轻量级，Master上所有元数据可以通过各个Slave重新注册进行重构，并通过Zookeeper进行维护管理实现Master的高可用性。其总体架构图如下所示：
2、Mesos的四大组成部分：
（1）Mesos Master：整个系统的核心。主要负责管理各个Framework（通过Framework_manager管理接入的各个Framework）和Slave（通过Slaves_manager管理所有的Slave），并将Slave上的资源按照某资源分配策略分配给各个Framework；
（2）Mesos Slave：接收来自Mesos Master的命令、管理本地节点上的各个Mesos Task，如为每个Executor分配资源。Mesos Slave将自己的资源量（包括CPU和内存）发送经Mesos Master，由Mesos Master的Allocator模块决定资源的具体分配；
（3）Framework：负责外部的计算框架的接入，如Hadoop、Spark等。这些外部计算框架通过注册的方式接入Mesos，由Mesos进行分布式集群资源的分配；而任务的调度和执行由计算机框架本身完成（即计算框架本身调度器负责将资源分配给具体的任务）；
（4）Executor：启动框架内部的Task。由于不同的框架接入Mesos的接口、方式不同，所以新框架接入Mesos需要编写自己的executor，通知Mesos如何启动框架中的Task。
三、Mesos的特点1、高效率
Mesos对分布式集群的资源可以做到细粒度的资源分配。细粒度的资源分配指按照任务实际需求进行分配资源，大大提高了资源的使用利用率，如下图所示：
左图中有三个集群，每个集群有三台服务器，分别由三个不同的框架进行管理；右图则是由Mesos集群统一管理九台服务器，然后对外统一提供资源，细粒度的管理提高了资源的利用率。
这时补充一下：Mesos的资源调度可以分为两类，即粗粒度调度和细粒度调度。
粗粒度调度方式是每个Executor获得资源后就长期持有，直到应用程序退出才会释放资源。优点是减少了资源调度的时间开销，缺点是由于其分配资源被长期占有，在应用程序大部分的计算任务都已完成的情况下造成了资源浪费。
细粒度调度方式是根据任务的实际需要动态申请资源，任务完成后就将资源释放、交还给系统。优点是避免了粗粒度调度的资源浪费问题，缺点是由于每次任务调度都要动态申请系统资源，所以调度的时间开销增大。
2、可扩展
Mesos的设计采用两级调度架构，使用Framework代理任务的实际调度，Mesos Master则以非常轻量级的代码实现，更易于扩展集群发展的规模。 因为Mesos Master不必知道所支持的每种类型的应用程序背后复杂的调度逻辑。 此外，由于Master不必为每个任务做调度，因此不会成为容量的性能瓶颈，而这在为每个任务或者虚拟机做调度的整体调度器中经常发生。
3、模块化
每接入一种新的Framework，Master无需为此编码，Slave模块可以复用，使得在Mesos所支持的宽泛领域中，业务迅速增长。相反，开发者可以专注于他们的应用和Framework的选择。 当前而且还在不断地增长着的Mesos Framework。目前已支持的框架如下图所示：
4、容错性
对Mesos Master，采用热备份设计实现Master节点集合，一个Master节点与多个备用（standby）节点运行在同一集群中，并由开源软件Zookeeper来监控。Zookeeper会监控Master集群中所有的节点，并在Master节点发生故障时管理新Master的选举。 Mesos决定将Master设计为持有软件状态，这意味着当Master节点发生故障时，其状态可以很快地在新选举的Master节点上重建。 Mesos的状态信息实际上驻留在Framework调度器和Slave节点集合之中。当一个新的Master当选后，Zookeeper会通知Framework和选举后的Slave节点集合，以便使其在新的Master上注册。彼时，新的 Master可以根据Framework和Slave节点集合发送过来的信息，重建内部状态。
对Mesos Slave，实现了Slave的恢复功能，当Slave节点上的进程失败时，可以让执行器/任务继续运行，并为那个Slave进程重新连接那台Slave节点上运行的执行器/任务。当任务执行时，Slave会将任务的监测点元数据存入本地磁盘。如果Slave进程失败，任务会继续运行，当Master重新启动Slave进程后，因为此时没有可以响应的消息，所以重新启动的Slave进程会使用检查点数据来恢复状态，并重新与执行器/任务连接。当计算节点/Slave节点无法响应多个连续的消息后，Master会从可用资源的列表中删除该节点，并会尝试关闭该节点。然后，Master会向分配任务的Framework调度器汇报执行器/任务失败，并允许调度器根据其配置策略做任务失败处理。通常情况下，Framework会重新启动任务到新的Slave节点，假设它接收并接受来自Master的相应的资源邀约。
对Framework，Framework调度器的容错是通过Framework将调度器注册2份或者更多份到Master来实现。当一个调度器发生故障时，Master会通知另一个调度来接管。需要注意的是Framework自身负责实现调度器之间共享状态的机制。
对Executor，与计算节点/Slave节点故障类似，Master会向分配任务的Framework调度器汇报执行器/任务失败，并允许调度器根据其配置策略在任务失败时做出相应的处理。通常情况下，Framework在接收并接受来自Master的相应的资源邀约后，会在新的Slave节点上重新启动任务。
四、与Yarn的区别1、Mesos和Yarn都采用双层调度机制，即资源管理系统层（将资源分配给应用程序）和资源调度层（将资源具体分配给计算框架中的任务），但资源分配程度不同。Mesos只负责为Framework计算框架提供资源，具体的资源分配由计算框架自己实现。而Yarn则从计算框架中分离出资源管理，自己全权负责资源分配及调度；
2、Mesos是分布式资源管理框架，更为通用。而Yarn则是Hadoop1.0到Hadoop2.0升级优化分离出来进行统一资源管理系统，具有一定局限性；
3、Mesos统一管理集群CPU、内存、硬盘等资源。而Yarn是基于HDFS分布式文件系统的基础上统一管理集群CPU和内存资源（因此说Yarn只是为上层屏蔽了底层集群的差异，而不是取代任何存储系统的系统）；
4、Mesos采用Linux Container容器（一种内核虚拟化技术）对多计算框架共享资源进行隔离。而Yarn则是通过进程隔离，这一点Yarn的性能比较好（Yarn的发展借鉴了Mesos思想）；
5、部署Mesos以后，再跑Spark或Hadoop MapReduce的时候，就不需要部署Spark和Hadoop了，直接在Mesos上运行Spark或Hadoop任务(在文件系统中指定运行所需要的框架二进制包位置)；
五、参考文献1、http://mesos.apache.org/index.html
2、http://dongxicheng.org/apache-mesos/meso-architecture/
3、http://www.csdn.net/article/2015-06-09/2824906
4、http://www.csdn.net/article/2015-07-10/2825180
5、http://blog.csdn.net/lsshlsw/article/details/47086869