Mesos介绍

    Mesos项目可以很容易地实现分布式应用的自动化调度。同时，Mesos自身也很高的结合和主持了Docker等相关容器技术，基于Mesos已有的大量应用框架，可以实现用户应用的快速上线。

    Mesos可以将整个数据中心的资源（包括CPU、内存、存储、网络等）进行抽象和调度，是的多个应用同时运行在集群中分享资源，并无需关心资源的屋里分布情况。

如果把数据中心中的集群资源看做一台服务器，那么Mesos要做的事情，其实就是今天操作系统内核的职责：抽象资源+调度任务。Mesos项目代码已经相对成熟。拥有许多引人注目的特性，包括：

1. 支持数万个节点的大规模场景
2. 支持多种应用框架，包括Marathon、Singularity、Aurora等；
3. 支持HA（基于ZooKeeper实现）
4. 支持Docker、LXC等容器机制进行任务隔离；
5. 提供了多个流行语言的API，包括Python、Javaden
6. 自带了简洁易用的WebUI，方便用户直接进行操作；

Mesos才用了经典的“主-从”架构，其中主节点（管理节点）可以使用Zookeeper来做HA。Mesos master 服务奖运行在主节点上，Mesos slave 服务则需要运行在各个计算任务节点上。负责完成具体任务的应用框架，与Mesos master进行交互，来申请资源。

         Mesos有三个基本的组件：管理服务（master）、任务服务（slave）以及应用框架（framework）。

         管理服务（master）：跟大部分分布式系统中类似，主节点起到管理作用，将看到全局的信息，负责不同应用框架之间的资源调度和逻辑控制。应用框架需要注册到管理服务上才能被使用。用户和应用需要通用主节点提供的API来获取集群状态和操作集群资源。

         任务服务（slave）：负责汇报本从节点上的资源状态（空闲资源、运行状态等等）给主节点，并负责隔离本地资源来执行主节点分配的具体任务。隔离机制目前包括各种容器机制，包括LXC、Docker等。

         应用框架（framework）：应用框架是实际干活的，包括连个主要组件：

                   调度器：注册到主机诶单，等待分配资源；

                   执行器：在从节点上执行框架指定的任务（框架也可以使用Mesos自带的执行器，包括shell脚本执行器和Docker执行器）

         应用框架可以分两种：一种是对资源的需求会扩展（比如Hadoop、Spark等），申请后还可能调整；另一种是对资源的需求将会固定（MPI等），一次申请即可。

调度

    对于一个资源调度框架来说，最核心的就是调度机制，怎么能快速高效地完成对某个应用框架资源的分配，是核心竞争力所在。最理想情况下（大部分时候都无法实现），最好是能猜到应用们的实际需求，实现最大化的资源使用率。

    Mesos为了实现尽量优化的调度，采取了两层（two-layer）的调度算法

    调度的基本思路很简单，master先全局调度一大块资源给某个framework，framework自己在实现内部的细粒度调度，决定那个任务用多少资源。两层调度简化了Mesos master自身的调度过程，通过将复杂的细粒度调度交由framework实现，避免了Mesos master成为性能的瓶颈。

调度过程

    调度通过offer发送的方式进行交互。一个offer是一组资源例如<1 CPU ,2GB Mem>>。

基本调度过程如下：

1. Slave节点会周期性汇报自己可用的资源给master；
2. 某个时候，master收到应用框架发来的资源请求，根据调度策略，计算出来一个资源offer给framework；
3. framework收到offer后可以决定要不要，如果接受的话，返回一个描述，说明自己希望如何使用和分配这些资源来运行某些任务（可以说明只希望使用部分资源，则多出来的会被master收回）；
4. master则根据framework答复的具体分配情况发送给slave，以使用framework的executor来按照分配的资源策略执行任务。

    具体给出一个例子：某从节点想主节点汇报自己有<4 CPU , 8 GB Mem>的空闲资源，同时，主节点看到某个应用框架请求<3 CPU , 6 GB Mem>，就创建一个offer<slave #1, 4 CPU, 8GB> 把满足的资源发给应用框架。应用框架（的调度器）收到offer后觉得可以接受，就恢复主节点，并告诉主机节点希望运行两个任务：一个占用<1CPU ，2GB Mem>, 一个占用<2 CPU , 4GB Mem>。主节点收到任务信息后分配任务到从节点上运行（实际上是应用框架的执行器来负责执行任务）。任务执行结束后资源可以被释放出来。剩余则资源还尅继续分配给其他应用框架或任务。

    应用框架在收到offer后，如果offer不满足自己的偏好（例如希望继续使用上次的slave）则可以选择拒绝offer，等待master发送新的offer过来。另外可以通过过滤机制加快资源的分配过程。