mesos 架构
上面这张图展示了mesos的主要部件。mesos由master后台程序、agent后台程序、mesos framework 组成，其中agent运行在每个集群节点上，framework负责在agent上运行任务。
Master能够通过为framework产生资源邀约（resource offers）进行细粒度的资源（CPU、RAM……）调度。每个资源要求包含类似如下的列表：<agent ID, resource1: amount1, resource2: amount2, …> 。master根据已经给定的组织策略（如公平算分享或者严格优先级）决定给每一个framework多少资源邀约。为了能够支持多种策略，master采用了模块化的架构，通过插件机制可以方便的添加新的分配模块。
framework运行在mesos之上，由两部分组成：scheduler——注册到master，并负责提出资源需求；executor——运行在agent节点，运行所属framework的task。然而master决定分配给每个framework多少资源，framework选定使用资源邀约中哪些资源。当framework接受了分配的资源，它将想要在mesos上运行的任务返回给mesos。接下来，mesos在相应的agent上启动这些任务。
资源邀约示例
下图演示了一个framework如何调度任务运行。
让我们把图中的各个事件过一遍。
- agent1 上报给master，它有4 cpu 和 4gb内存空闲。接下来master调用分配策略模块，该模块告知应该给framework 1提供所有可用的资源。
- master发送一个描述agent 1上可用资源的资源邀约给framework 1.
- framework的scheduler回复master两个任务需要在agent上运行，第1个任务使用<2 CPUs, 1 GB RAM> 的资源，第2个任务使用 <1 CPUs, 2 GB RAM>资源。
- 最后，master把任务发送到agent，agent分配适当的资源给executor，executor启动这两个任务（图中的虚线部分）。因为还有1 CPU和1GB内存资源没有分配，分配模块会提供这些资源给framework 2.
另外，随着任务完成或者有新的空闲资源，资源分配过程重复进行。
虽然mesos提供轻量级的接口允许对其进行扩展以及framework可以独立演进，但是有个问题：在mesos不知道framework存在的一些约束条件的情况下，framework的约束条件如何得到满足？比如，framework需要从本次取得一份数据，但是mesos不知道哪一个节点有这份数据。 mesos通过给framework拒绝 邀约的能力的方式解决这类问题。 一个framework会拒绝那些不满足其约束条件的邀约，只接受满足约束的。特别指出的是，我们已经找一个叫做延迟调度的简单策略，即framework等待一个有限时间来等待存储输入数据的节点，得到近似优化的本地数据处理结果。