ResourceManager架构解析
RM作为master管理着所有的集群资源，它会和NM和特定application的AM共同工作
1. NodeManagers
NM从RM中获得指令，并管理着单节点上可用资源
2. ApplicationMasters
负责和RM协调，然后通知NM来启动资源容器
RM有如下部件：
1. RM和客户端交互的部件
ClientRMService
RM的client接口，处理client端的RPC请求，比如提交application，强制杀死application，获得Queue信息，集群metrics
AdminService
单独的管理员客户端接口，比如refreshNodes，refreshUserToGroupsMappings等.
2. RM和NM交互的部件
ResourceTrackerService
负责响应NM过来的RPC请求，比如注册NM，拒绝不合法或者decommissioned节点请求，获得NM心跳信息并传递给事件处理器YarnScheduler。每次heartbeat会调用nodesListManager和 nmLivelinessMonitor组件
NMLivelinessMonitor
跟踪活跃的节点，并且记录挂掉的节点。该部件会记录每个节点最后一次心跳时间，任何节点如果在一定时间内没有心跳信息（默认是10分钟）会被认为已经挂了并被标记为expired node，新的container不会被分配到expired node.
NodesListManager
维护了include和exclude的NM列表信息，初始化时会读入yarn.resourcemanager.nodes.include-path和yarn.resourcemanager. nodes.exclude-path指定的两个文件。集群启动后也可以通过AdminService来动态refresh nodes
3. RM和AM交互的部件
ApplicationMasterService
AM向RM请求RPC的服务 ，AM可以注册或者注销，从RM中获得资源容器
AMLivelinessMonitor
这个部件在ApplicationMasterService中，AM在注册/注销和申请资源的时候都会调用(receivedPing方法 )，它负责记录每个AM最后一次心跳时间 ，若在规定间隔内NM未反馈心跳（默认10分钟），则NM被认为已经挂了，并被AM移除。所有这个AM上已经分配和正在执行的资源容器都会被标记为dead，RM Scheduler会重新调度AM到一个新的容器中，默认最多会尝试4次
RM的核心部件 - 调度器和相关部件
RMAppManager
负责维护提交的applications，信息存放到RMContext中， 同时会cache已经完成的application，用户可以通过WebUI或者命令行来查看
ApplicationACLsManager
维护每个应用的ACL列表，在杀死应用，查看应用信息的时候会检查ACL authorization
ApplicationMasterLauncher
内部有一个线程池来启动AM （新提交的或者之前由于某种原因失败了的），
如果application正常停止或者强制kill掉后会负责清理AM
YarnScheduler
Scheduler负责分配资源，它是基于application资源需求的分配策略，比如CPU，内存，网络，磁盘等
ContainerAllocationExpirer
负责保证所有分配给AM的容器都会被相应的NM启动起来了。由于AM有可能在得到资源后不启动，这会造成集群利用率的降低，所以ContainerAllocationExpirer会保持已经分配但是还未被NM启动的container列表。对于任何一个container，如果在一定的时间内（默认10分钟） NM未汇报给RM它已经被启动了，则该container会被认为已经过期了
参考：
