mesos架构
mesos由4各部分组成：
- mesos-master：负责管理接入mesos的各个framework（由frameworks_manager管理）和slave（由slaves_manager管理），并将slave上的资源按照某种策略分配给framework（由独立插拔模块Allocator管理）。
- mesos-slave： 负责接收mesos-master的命令，管理节点上的task。
- Framework：指的是外部框架。他们通过注册的方式接入mesos。Framework接入mesos需要实现自己的scheduler。
- executor：executor用于启动框架内的task，因为各种Framework的任务启动方式不同，需要Framework自己实现。
mesos 和yarn的对比
mesos的工作过程具体可以看董老师的blog，这里主要说一下mesos和yarn的对比：
| yarn | mesos | 功能 |
|---|---|---|
| Resource Manage | mesos master | 负责整个集群的资源管理和调度 |
| Node Manage | mesos slave / framework executor | 负责单个节点的资源管理并且负责任务管理和任务运行进度汇报 |
| Application Master | Framework scheduler | 负责单个应用程序的管理和资源在任务内部的二次调度 |
可以看出其实mesos和yarn的各个部分还是对应的很像的。这里唯一的区别就是framework scheduler. yarn的am是运行在node manager上的，耦合比较紧密，而 mesos的Framework scheduler默认是运行在submit的机器上。（当然也可以运行在mesos slave上，通过工具mesos submit tool）。同时我们注意到scheduler是用户自己写的，所以相比之下和mesos的耦合比较小。yarn里面am失败了整个任务就要进行一次全新的尝试，而mesos中建议scheduler编写时就有容错机制，具体可以见Designing Highly Available Mesos Frameworks。这也就是mesos更适合长时任务的原因，他可以更容易的实现scheduler的重启，而相比之下yarn的am失败则整个任务需要重启，这在长时任务中是不可忍受的（当然现在yarn有一个叫slide的项目正在研究这个问题，参考文献，项目主页）。另外mesos有很多成熟的部署长时任务的项目，比如marathon，他自己是一个Framework，自己实现了HA，据说能在shell里跑得项目都可以直接在它上面跑。
总结起来就是mesos更是一个纯粹的资源管理系统，比较灵活，但是Framework方面需要用户写的也更多；yarn是一个hadoop的资源管理系统，对于长时任务和超短任务支持不是特别好，（超短任务的原因貌似是因为状态复杂吧，下面参考文献说的），但是在hadoop体系下使用方便，至少我现在用hadoop和spark没有遇到什么问题。
参考文献
除了上面给出的链接，其余的参考文献有:
- Deploying a Service on Mesos Cluster using Marathon Framework
- running batch and long-running, highly available service jobs on the same cluster
- A tale of two clusters: Mesos and YARN
本文采用创作共用保留署名-非商业-禁止演绎4.0国际许可证，欢迎转载，但转载请注明来自http://thousandhu.github.io，并保持转载后文章内容的完整。本人保留所有版权相关权利。