Mesos Architecture
上图显示了 Mesos 的主要组成部分。 Mesos 由一个 master daemon 来管理 slave daemon 在每个集群节点上的运行, mesos applications （ 也称为 frameworks ）在这些 slaves 上运行 tasks。
Mesos master&slave首先，Mesos是一个分布式的架构，它分Mesos master和Mesos slave，slave和master分别有不同的职责。从Mesos的源代码可以看出Mesos实现得比较优雅——它是一个C++代码。代码中有大量的关键词叫process，它不是传统意义上的进程，而是一种抽象的libprocess，libprocess是它最核心的库。如果大家以前使用过Erlang的语言就知道libprocess实际是对Erlang的IO和通讯模型的一个抽象。
libprocess，在Erlang里面也叫进程，实际上是一个虚拟进程，在运行Erlang的VM上。它最优的特点是消息在不同的process之间传递，它抽象了process，消息传递其实是一个事件的库。向process里发一个消息，这个消息不是直接打到process，而是中间有一个buffer的过程。
这样做的优点是特别适合分布式的系统，以前最常用的做法是监听网络端口，有包来了，有一个模块专门负责解这个包，解开一个协议后把这个协议发到后面一个处理进程，这个处理的进程可能是IO操作，可能去做其它事情，然后里面有很多IO上的Block，最后构造出一个response，通过一个socket传给客户端。这是最常用的一个写网络程序的办法，但是这里有一个大的IO上Block的地方——后面处理的逻辑依赖于解包的逻辑。如果处理逻辑很快，但解包逻辑很慢，后面会拖慢，都在等解包。
后来人们想到一种IO处理的方式，让任何一个东西都是分离的，比如从某一个端口收到一个消息，有一个单独的进程，一个线程或者其它的东西去处理这个唯一的请求。这个线程很重，后来大家又发明了一些其它的东西，比如golang里面去搞一个channel，Erlang里面去搞一个process。libprocess实际上做了IO方面的事情， Mesos大量使用这个模型。
ZookeeperMesos底层实际上依赖于Zookeeper，为了保证分布式存储最终一致性。在Mesos运行过程中产生了一些数据，最终都会落在Zookeeper。因为Mesos是多个master，为了达到HA的需求，只要一个master活的，那么整个服务就能得到保证。
protobufMesos内部在通信里面选择了protobuf协议。好处是比较流行，各个语言的库都比较多，结构化的语义也比较强，所以Mesos内部选择了protobuf。
Master 使用 Resource Offers 实现跨应用细粒度资源共享，如 cpu、内存、磁盘、网络等。 master 根据指定的策略来决定分配多少资源给 framework ，如公平共享策略，或优先级策略。 为了支持更多样性的策略，master 采用模块化结构，这样就可以方便的通过插件形式来添加新的分配模块。
在 Mesos 上运行的 framework 由两部分组成：
一个是 scheduler ，通过注册到 master 来获取集群资源。
另一个是在 slave 节点上运行的 executor 进程，它可以执行 framework 的 task 。 Master 决定为每个 framework 提供多少资源， framework 的 scheduler 来选择其中提供的资源。当 framework 同意了提供的资源，它通过 master 将 task发送到提供资源的slaves 上运行。
资源供给的一个例子下图描述了一个 Framework 如何通过调度来运行一个 Task
事件流程:
Slave1 向 Master 报告，有4个CPU和4 GB内存可用
Master 发送一个 Resource Offer 给 Framework1 来描述 Slave1 有多少可用资源
FrameWork1 中的 FW Scheduler会答复 Master，我有两个 Task 需要运行在 Slave1，一个 Task 需要<2个CPU，1 GB内存="">，另外一个Task需要<1个CPU，2 GB内存="">
最后，Master 发送这些 Tasks 给 Slave1。然后，Slave1还有1个CPU和1 GB内存没有使用，所以分配模块可以把这些资源提供给 Framework2
当 Tasks 完成和有新的空闲资源时，Resource Offer 会不断重复这一个过程。、
当 Mesos 提供的瘦接口允许其来扩展和允许 frameworks 相对独立的参与进来，一个问题将会出现： 一个 framwork 的限制如何被满足在不被 Mesos 对这些限制所知晓的情况下？
例如， 一个 framework 如何得到数据本地化在不被 Mesos所知晓哪个节点存储着被该 framwork 所需要的数据？Mesos 通过简单的寄予 frameworks 能够拒绝 offers 的能力来回答了这个问题。 一个 framework 将拒绝 不满足其限制要求的 offers 并接受满足其限制要求的 offers.
特殊情况下，我们找到一个简单的策略 delay scheduling， 在该 frameworks 等待 一个限制时间来获取存储输入数据的节点， 并生成接近的优化过得数据点。
本篇主要分享了mesos的组成部分和事件流程。下周会详细介绍Mesos的概念解析和工作原理。敬请期待。