## Mesos 架构  上面的这张图像我们展示了mesos架构的主要组件.mesos架构包含一个master守护进程，它管理了多个运行在集群各节点上的agent守护进程,Mesos frameworks(应用框架)负责在这些agent上运行task(任务) master进程通过资源分派(resources offers)的方式，在应用框架间实现细粒度的资源(CPU,RAM等)共享.每次资源分派包含这样的一个列表，<agent ID, resource1: amount1, resource2: amount2, …> >(注意: 关键字slave已经被废弃，由agent来替换, driver-based frameworks will still receive offers with slave ID, whereas frameworks using the v1 HTTP API receive offers with agent ID). master进程根据既定的组织策略来决定为每个框架提供多少资源，组织策略比如：平均分配策略 或者 按严格的优先级的策略.为了支持多样化的策略，master采用了一种模块化的架构，这使得通过插件方式来添加新的资源分配模块变得很容易. 运行于Mesos之上的framework包含两个组件： * 调度器：向master注册,向master说明需要使用哪些，多少被分派的资源 * 执行器：在agent节点上运行该应用框架的任务（查看[App/Framework development guide](http://mesos.apache.org/documentation/latest/app-framework-development-guide/)获取更多关于调度器与执行器的内容） master进程可以决定为每个framework提供多少资源，framework的调度器选择去使用哪些被master分派出来的资源.当一个框架接收一个资源分派的时候，它提交给mesos一个关于它所运行的任务的描述。然后，mesos将在对应的agent节点上运行任务. ### 资源分派的例子 下面的图片中的例子显示了，一个framework(框架)如何去调度任务的执行  我们来看看上图中所发生的事件： 1. agent 1 节点向master汇报它还有4颗CPU 和4G的内存空闲.master随后调用资源分配策略模块，告诉framework 1 可以使用这些资源了 2. master发送了一个资源分派列表，告诉framework1具体有哪些资源在agent1上是可用的 3. framework的调度器回复master,它需要在agent1上运行2个任务，第一个任务使用<2 CPUs, 1 GB RAM>，第二个任务使用<1 CPUs, 2 GB RAM>。 4. 最后，master将任务发送给agent，分配相应的资源给framework执行器，依次启动2个任务(图中虚线描绘的部分).由于还有1颗 CPU和1GB的内存没有被分配，资源分配模块可能会将他们分配给framework2 在任务完成之后,资源被释放。资源分派模块将重复上面的步骤，重新进行资源分配。 通过这种低依赖性的接口设计，mesos可以实现应用框架的缩放，并且允许各种框架独立的发展演进。但是还遗留了一个问题：在mesos不知道应用框架的特殊限制条件的时候，如何去满足这些限制条件？比如：Mesos不知道哪个agent节点存储着应用所需要的数据的时候，如何知道把任务放到哪个节点实现数据获取的本地化？Mesos的做法非常简单，就是赋予framework拒绝资源分派的能力.框架拒绝不满足限制条件的资源分派，去接收满足限制条件的资源分派.特别说明的是，我们已经找到一种非常简单的策略叫做延迟调度.(In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality.)(这段话译者暂时没能理解，保留原文) 了解关于 Mesos架构的更多内容，请参考 [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf).