在概况(一)中，主要简单的对Yarn的情况作了简单的介绍，今天花一定时间在某些具体的模块上呈现以下Yarn的整体情况，帮助大家更好的理解Yarn。
1）ResourceManager
在Yarn的整体架构中，他用的也是Master/Slave架构，他的Slave是NodeManager，RM在Yarn中扮演着一个非常重要的角色，他是负责集群中所有资源的统一管理和分配的。他根据各个NM的资源汇报信息，把这些信息按照一定策略分配各个应用程序。下面是ResourceManager的主要内部结构：
(1).用户交互模块
(2).NM管理模块
(3).AM管理模块
(4).Application应用管理模块
(5).安全管理模块
(6).资源分配模块
(7).状态机管理模块，ResourceManager使用有限状态机来维护状态的生命周期的，比如RMApp应用状态机，RMConta容器状态机。
1.ResourceManager事件处理
在Yarn广泛采用了事件驱动的机制，由1个中心事件分发器，对于传进来的事件做转发处理，大大的提高了效率。
2）资源调度模型
在MRV1中，资源调度默认采用的是简单的FIFO的方式，但是在需求日益多元化的条件下，这种方式一件渐渐的没有那么完美了，于是适用于多用户的资源调度器就出现了。主要2种设计思路。
(1).在同个集群中虚拟多个Hadoop集群，这些Hadoop集群拥有全套的Hadoop服务，典型的代表HOD(Hadoop On Demand)调度器。
(2).资源调度器以多用户多队列的形式实现，每个队列只要每个队列运行着类似的用户群，每个队列里有自己分配的资源和任务。但是他们是共享一整套Hadoop的资源的。
3）NodeManager
NM是Yarn上单个节点上的代理。他有如下的作用
1.与ResourceManager通信
2.管理Contain容器的的生命周期
3.监控Contain的资源使用情况
4.管理节点健康状况
5.管理日志服务
与RM一样，NM也采用了事件驱动的形式来控制整个过程，有许多的事件类型经过事件处理器处理后会改变对象的状态机，进而改变了对象的声明周期。
3）在Yarn上运行多种计算框架
Yarn是一一个通用的资源管理框架，在上面运行多种计算框架才是啊他的最大的不同MRV1的地方。作为一个资源框架，有2样东西你必须要重写一个提交应用的Client，还有一个是与待接入框架相适应的ApplicationMaster，后者的设计尤其是关键。因为提交程序的Client都差不多的。
1.MRV1主要是通过JobTracker和TaskTracker实现的，所以他在Yarn的部署可以是下面这幅图的样子。
2.Storm，实时处理框架在Yarn是怎么运行的呢，Storm与MRV1还是非常类似的，通过Nimbus,Supervisor,中间加个zookeeper做协调服务就能实现了。模拟图如下。
当然以上还都是设计思路，最终还是通过自己实现客户端和自定义的ApplicationMaster实现最终的设计。
4）Yarn的未来
在最近几年，也衍生出了一些类似于Yarn的通用计算框架，比如Apache Mesos，他同样可以支持MapReduce和Storm，在某些特性上和Yarn还是有些不同的。不过这个框架还不是特别稳定目前。作为通用的计算框架，在Yarn的身上，还是有些缺点的，比如因为运行在Yarn上的计算框架是资源隔离的， 所以各个框架是不知道集群的整体资源运行情况的，就不好进行整体资源的调度。各个计算是框架不知道当在节点非常繁忙的时候是应该等待自己的任务运行完了在继续下面的任务，还是向系统请求新的资源，如果系统此时也非常忙，显然不适合请求，反而要等更长时间，如果系统资源此时非常空，那这就是正确的策略。