YARN是开源项目Hadoop的一个资源管理系统，最初设计是为了解决Hadoop中MapReduce计算框架中的资源管理问题，但是现在它已经是一个更加通用的资源管理系统，可以把MapReduce计算框架作为一个应用程序运行在YARN系统之上，通过YARN来管理资源。如果你的应用程序也需要借助YARN的资源管理功能，你也可以实现YARN提供的编程API，将你的应用程序运行于YARN之上，将资源的分配与回收统一交给YARN去管理，可以大大简化资源管理功能的开发。当前，也有很多应用程序已经可以构建于YARN之上，如Storm、Spark等计算框架。
YARN整体架构
YARN是基于Master/Slave模式的分布式架构，我们先看一下，YARN的架构设计，如图所示（来自官网文档）：
上图，从逻辑上定义了YARN系统的核心组件和主要交互流程，各个组件说明如下：
- YARN Client
YARN Client提交Application到RM，它会首先创建一个Application上下文件对象，并设置AM必需的资源请求信息，然后提交到RM。YARN Client也可以与RM通信，获取到一个已经提交并运行的Application的状态信息等，具体详见后面ApplicationClientProtocol协议的分析说明。
- ResourceManager（RM）
RM是YARN集群的Master，负责管理整个集群的资源和资源分配。RM作为集群资源的管理和调度的角色，如果存在单点故障，则整个集群的资源都无法使用。在2.4.0版本才新增了RM HA的特性，这样就增加了RM的可用性。
- NodeManager（NM）
NM是YARN集群的Slave，是集群中实际拥有实际资源的工作节点。我们提交Job以后，会将组成Job的多个Task调度到对应的NM上进行执行。Hadoop集群中，为了获得分布式计算中的Locality特性，会将DN和NM在同一个节点上运行，这样对应的HDFS上的Block可能就在本地，而无需在网络间进行数据的传输。
- Container
Container是YARN集群中资源的抽象，将NM上的资源进行量化，根据需要组装成一个个Container，然后服务于已授权资源的计算任务。计算任务在完成计算后，系统会回收资源，以供后续计算任务申请使用。Container包含两种资源：内存和CPU，后续Hadoop版本可能会增加硬盘、网络等资源。
- ApplicationMaster（AM）
AM主要管理和监控部署在YARN集群上的Application，以MapReduce为例，MapReduce Application是一个用来处理MapReduce计算的服务框架程序，为用户编写的MapReduce程序提供运行时支持。通常我们在编写的一个MapReduce程序可能包含多个Map Task或Reduce Task，而各个Task的运行管理与监控都是由这个MapReduce Application来负责，比如运行Task的资源申请，由AM向RM申请；启动/停止NM上某Task的对应的Container，由AM向NM请求来完成。
下面，我们基于Hadoop 2.6.0的YARN源码，来探讨YARN内部实现原理。
YARN协议
YARN是一个分布式资源管理系统，它包含了分布的多个组件，我们可以通过这些组件之间设计的交互协议来说明，如图所示：
下面我们来详细看看各个协议实现的功能：
- ApplicationClientProtocol（Client -> RM）
| 协议方法 | 功能描述 |
| getNewApplication | 获取一个新的ApplicationId，例如返回的ApplicationId为application_1418024756741 |
| submitApplication | 提交一个Application到RM |
| forceKillApplication | 终止一个已经提交的Application |
| getApplicationReport | 获取一个Application的状态报告信息ApplicationReport，包括用户、队列、名称、AM所在节点、AM的RPC端口、跟踪URL、AM状态、诊断信息（如果出错的话）、启动时间、提交Application的Client（如果启用安全策略） |
| getClusterMetrics | 获取YARN集群信息，如节点数量 |
| getApplications | 获取Application状态报告信息，和getApplicationReport类似，只不过增加了过滤器功能 |
| getClusterNodes | 获取集群内所有节点的状态报告信息 |
| getQueueInfo | 获取队列信息 |
| getQueueUserAcls | 获取当前用户的队列ACL信息 |
| getDelegationToken | 获取访问令牌信息，用于Container与RM端服务交互 |
| renewDelegationToken | 更新已存在的访问令牌信息 |
| cancelDelegationToken | 取消访问令牌 |
| moveApplicationAcrossQueues | 将Application移动到另一个队列中 |
| getApplicationAttemptReport | 获取Application Attempt状态报告信息ApplicationAttemptReport |
| getApplicationAttemptReport | 获取Application Attempt状态报告信息，和getApplicationAttemptReport类似，只不过增加了过滤器功能 |
| getContainerReport | 根据ContainerId获取Container状态报告信息ContainerReport，例如Container名称为container_e17_1410901177871_0001_01_000005，各个段的含义：container_e<epoch>_<clusterTimestamp>_<appId>_<attemptId>_<containerId> |
| getContainers | 根据ApplicationAttemptId获取一个Application Attempt所使用的Container的状态报告信息，例如Container名称为container_1410901177871_0001_01_000005 |
| submitReservation | 预定资源，以备在特殊情况下能够从集群获取到资源来运行程序，例如预留出资源供AM启动 |
| updateReservation | 更新预定资源 |
| deleteReservation | 删除预定 |
| getNodeToLabels | 获取节点对应的Label集合 |
| getClusterNodeLabels | 获取集群中所有节点的Label |
- ResourceTracker（NM -> RM）
| 协议方法 | 功能描述 |
| registerNodeManager | NM向RM注册 |
| nodeHeartbeat | NM向RM发送心跳状态报告 |
- ApplicationMasterProtocol（AM -> RM）
| 协议方法 | 功能描述 |
| registerApplicationMaster | AM向RM注册 |
| finishApplicationMaster | AM通知RM已经完成（成功/失败） |
| allocate | AM向RM申请资源 |
- ContainerManagementProtocol（AM -> NM）
| 协议方法 | 功能描述 |
| startContainers | AM向NM请求启动Container |
| stopContainers | AM向NM请求停止Container |
| getContainerStatuses | AM向NM请求查询当前Container的状态 |
- ResourceManagerAdministrationProtocol（RM Admin -> RM）
| 协议方法 | 功能描述 |
| getGroupsForUser | 获取用户所在用户组，该协议继承自GetUserMappingsProtocol |
| refreshQueues | 刷新队列配置 |
| refreshNodes | 刷新节点配置 |
| refreshSuperUserGroupsConfiguration | 刷新超级用户组配置 |
| refreshUserToGroupsMappings | 刷新用户->用户组映射信息 |
| refreshAdminAcls | 刷新Admin的ACL信息 |
| refreshServiceAcls | 刷新服务级别信息（SLA） |
| updateNodeResource | 更新在RM端维护的RMNode资源信息 |
| addToClusterNodeLabels | 向集群中节点添加Label |
| removeFromClusterNodeLabels | 移除集群中节点Label |
| replaceLabelsOnNode | 替换集群中节点Label |
- HAServiceProtocol（Active RM HA Framework Standby RM）
| 协议方法 | 功能描述 |
| monitorHealth | HA Framework监控服务的健康状态 |
| transitionToActive | 使RM转移到Active状态 |
| transitionToStandby | 使RM转移到Standby状态 |
| getServiceStatus | 获取服务状态信息 |
YARN RPC实现
1.X版本的Hadoop使用默认实现的Writable协议作为RPC协议，而在2.X版本，重写了RPC框架，改成默认使用Protobuf协议作为Hadoop的默认RPC通信协议。 YARN RPC的实现，如下面类图所示：
通过上图可以看出，RpcEngine有两个实现：WritableRpcEngine和ProtobufRpcEngine，默认使用ProtobufRpcEngine，我们可以选择使用1.X默认的RPC通信协议，甚至可以自定义实现。
ResourceManager内部原理
RM是YARN分布式系统的主节点，ResourceManager服务进程内部有很多组件提供其他服务，包括对外RPC服务，已经维护内部一些对象状态的服务等，RM的内部结构如图所示：
上图中RM内部各个组件（Dispatcher/EventHandler/Service）的功能，可以查看源码。
这里，说一下ResourceScheduler组件，它是RM内部最重要的一个组件，用它来实现资源的分配与回收，它提供了一定算法，在运行时可以根据算法提供的策略来对资源进行调度。YARN内部有3种资源调度策略的实现：FifoScheduler、FairScheduler、CapacityScheduler，其中默认实现为CapacityScheduler。CapacityScheduler实现了资源更加细粒度的分配，可以设置多级队列，每个队列都有一定的容量，即对队列设置资源上限和下限，然后对每一级别队列分别再采用合适的调度策略（如FIFO）进行调度。
如果我们想实现自己的资源调度策略，可以直接实现YARN的资源调度接口ResourceScheduler，然后修改yarn-site.xml中的配置项yarn.resourcemanager.scheduler.class即可。
NodeManager内部原理
NM是YARN系统中实际持有资源的从节点，也是实际用户程序运行的宿主节点，内部结构如图所示：
上图中NM内部各个组件（Dispatcher/EventHandler/Service）的功能，可以查看源码，不再累述。
事件处理机制
事件处理可以分成2大类，一类是同步处理事件，事件处理过程会阻塞调用进程，通常这样的事件处理逻辑非常简单，不会长时间阻塞；另一类就是异步处理处理事件，通常在接收到事件以后，会有一个用来派发事件的Dispatcher，将事件发到对应的事件队列中，这采用生产者-消费者模式，消费者这会监视着队列，并从取出事件进行异步处理。
YARN中到处可以见到事件处理，其中比较特殊一点的就是将状态机（StateMachine）作为一个事件处理器，从而通过事件来触发特定对象状态的变迁，通过这种方式来管理对象状态。我们先看一下YARN中事件处理的机制，以ResourceManager端为例，如下图所示：
产生的事件通过Dispatcher进行派发并进行处理，如果EventHandler处理逻辑比较简单，直接同步处理，否则可能会采用异步处理的方式。在EventHandler处理的过程中，还可能产生新的事件Event，然后再次通过RM的Dispatcher进行派发，而后处理。
状态机
我们以RM端管理的RMAppImpl对象为例，它表示一个Application运行过程中，在RM端的所维护的Application的状态，该对象对应的所有状态及其状态转移路径，如下图所示：
在上图中如果加上触发状态转移的事件及其类型，可能整个图会显得很乱，所以这里，我详细画了一个分图，用来说明，每一个状态的变化都是有哪种类型的事件触发的，根据这个图，可以方便地阅读源码，如下图所示：
NMLivelinessMonitor源码分析实例
YARN主要采用了Dispatcher+EventHandler+Service这样的抽象，将所有的内部/外部组件采用这种机制来实现，由于存在很多的Service和EventHandler，而且有的组件可能既是一个Service，同时还是一个EventHandler，所以在阅读代码的时候可能会感觉迷茫，这里我给出了一个阅读NMLivelinessMonitor服务的实例，仅供想研究源码的人参考。
NMLivelinessMonitor是ResourceManager端的一个监控服务实现，它主要是用来监控注册的节点的Liveliness状态，这里是监控NodeManager的状态。该服务会周期性地检查NodeManager的心跳信息来确保注册到ResourceManager的NodeManager当前处于活跃状态，可以执行资源分配以及处理计算任务，在NMLivelinessMonitor类继承的抽象泛型类AbstractLivelinessMonitor中有一个Map，如下所示：
private Map<O, Long> running = new HashMap<O, Long>();
这里面O被替换成了NodeId，而值类型Long表示时间戳，也就是表达了一个NodeManager向ResourceManager最后发送心跳信息时间戳，通过检测running中的时间戳；来判断NodeManager是否可以正常使用。
在ResourceManager中可以看到，NMLivelinessMonitor的实例是其一个成员：
protected NMLivelinessMonitor nmLivelinessMonitor;
看一下NMLivelinessMonitor类的实现，它继承自抽象泛型类AbstractLivelinessMonitor，看NMLivelinessMonitor类的声明：
public class NMLivelinessMonitor extends AbstractLivelinessMonitor<NodeId>