YA RN个方面存在明显优势：人力投入大，目前YA RN有专门的公司（hortonwork维护和开发；知名度高，YA RN之前从Hadoop1.0中演化而来，就目前看来。继承了Hadoop知名度，且有大量公司和开发人员共享patch然而，Meso最大优点的设计简单、容易上手使用，不像 YA RN那样，一个资源的分配过程要涉及到若干个状态机，且每种状态机十几种状态，十几种事件。但稳定性看，两个系统都处于研发和测试阶段，离稳定可用还 有一段距离。

每种服务内部注册了若干种ProtocBuffer消息处置器，Meso中包括四类主要的服务（实际上是一个socketserver分别是MesoMasterMesoSlaveSchedulerProcess和ExecutorProcess之间通过ProtocBuffer消息进行通信。一旦收到某种消息，则会调用相应的消息处置器进行处理。除了以上四种服务之外，Meso还对外提供了三种可编程组件，分别是AlloctorFrameworkSchedul和FrameworkExecutor编写这几个组件必需依照要求实现了几个接口，而这些接口将分别被下图中相邻的服务调用。

均会认为Framework必需是一个通用的框架，大部分人看到以上Meso架构后。比方MapReducStormSpark等，而 MesoMaster负责将资源分配给各个框架，而各个框架的Schedul进一步将资源分配给其内部的各个应用顺序。这种观念是错误的对Meso架构 一种错误解读。

Framework不只可以是通用的框架，事实上也可以是像HadoopJob或者YA RNApplicat那样的简单计算任务，也就 说，Framework并需要一定是一个“Framework或者一个长时间运行的服务（比方JobTrack等）也可以是一个短生命周期的Job或者Applicat如果让Framework对应一个HadoopJob则可以这样设计FrameworkSchedul和FrameworkExecutor

FrameworkSchedul功能，将之分解成若干任务，FrameworkSchedul负责依照作业的输入数据量。并为这些任务申请资源、监控这些任务的运行状态，一旦发现某个任务运行失败则重新为之申请资源；FrameworkExecutor功能，包括准备各种jar包、二进制文件，为一个节点上的MapTask或者ReducTask准备运行环境。设置必要的环境变量，进行必要的资源隔离，启动JettiShuffl以为ReducTask提供远程数据拷贝服务等，接收来自FrameworkSchedul命令（启动任务、杀死任务等）并执行。

FrameworkSchedul只负责运行一个HadoopJob而如果你对YA RN比较熟悉，通过上面的介绍可以知道。便会发现者正是YA RN中的MapReducApplicationMast做的事情，没错，Meso与YA RN设计架构如此的相近，以至于我很容易通过修改YA RN任何一个ApplicationMast让它作为一个FrameworkSchedul运行在Meso中。该工具尚不完善）该工具可以让用户的FrameworkSchedul运行在任何一个MesoSlave上，最近Meso提供了一个mesos-submit工具注意。以防止客户端运行过多的FrameworkSchedul这样，Meso整个架构和工作流程已经变得与YA RN相差无几了

下面给出了Meso和YA RN组件对应表：为了让大家更容易理解Meso和YA RN架构上的相似性。

Meso中的组件 YA RN中的组件 功能

MesoMaster ResourcManager 整个集群的资源管理和调度

MesoSlave NodManager 单个节点的资源管理（资源隔离、汇报等）任务启动等

FrameworkExecutor

基本操作均包括注册、资源申请/获取、资源分配（给内部的任务）等。FrameworkScheduler A pplicationMaster 单个应用顺序的管理和资源二次调度。