1.回顾YARN的三大组件
1.1ResourceManager全局资源管理器
每个集群有一个RM守护进程（可HA），RM负责整个系统的资源分配与管理；它主要有调度器ResourceScheduler和应用程序管理器（APPlications Manager）构成；
1.2 NodeManger，节点资源管理器
每个节点有一个NM守护进程，负责本节点的资源管理。其资源分配主要体现在Container模式上，根据RM分配资源。其次NM负责本地可用资源的监控，故障报告，以及Container的生命周期管理等。
1.3Application Master应用程序主管理器
每个提交的应用程序都有一个AM的守护进程，客户端每使用YARN客户端启动提交执行一个应用程序之前，先启动一个AM（其实本质就是一个运行的Container，一个程序最早启动的container实例），AM负责与RM进行资源协商，并协同NM工作以完成应用的功能。
AM的作用就是负责向RM协商资源，并且同时和NM协同配合来运行Container，以及监控他们的资源消耗。
2.从RM的通信架构剖析RM
2.1ResourceManager的主要职责
- 先与YARN客户端交互，处理来自客户端的请求（身份认证）。
- 启动监控管理ApplicationMaster，包括重试等 。
- 管理NodeManager，接受其资源汇报，对其资源进行统一分配；对其状态进行监控和下达指令。
- 资源管理与调度，处理AM的请求。
2.2ResourceManager与YARN客户端交互
注意：第5步，RM在响应AM的注册请求时，会将自身的资源使用情况(集群的最小容量最大容量等)发送给AM,让AM判断启动Container的策略。
YARN的作业，可以使用yarn application 命令来管理，包括-kill,-list,-status等等。
2.3ResourceManager与AM的通信交互
RM内部两大员工：ResourceScheduler和APPlications Manager。
前者ResourceScheduler是一个可插拔的调度器组件（可更换不同的调度策略），负责为运行中的各种应用分配资源，资源受队列，容量，优先级等配置制约，它只是一个纯粹的资源调度器，不关心也不负责应用程序的监控和状态跟踪。一句话，只负责分配资源，不管应用死活。ResourceScheduler给应用程序分配的资源叫Container，在NM上启动。注意此外ResourceScheduler还可以进行资源回收，主要发生在集群资源很稀缺的时候，调度器会主动杀死那些超出使用阈值队列分配的Container,以保证其他队列的最小使用资源，一般只会杀死部分。
后者APPlications Manager负责处理客户端提交的应用请求，并且它还根据应用请求分配启动对应AM,如MR任务则启动MapReduce AM等。如果监控到某个AM失败，则其会重启AM。基于如下架构，说明当一个应用提交时，RM内部的的协调机制。
- 如上，当两个不同类型的应用程序通过YARN客户端提交时给YARN时，一系列权限校验后，首先提交给YARN的RM，RM其中APPlications Manager应用管理器，它会根据这个应用程序类型，启动的对应的AM,如这里提交了MapRedcue任务，则应用管理器会跟RM中的调度器Scheduler通信，申请一个Container，如果调度有资源的话就可以满足要求。应用管理器在这个分配的Container上启动MRAPPMaster（即：MapReduce ApplicationMaster）。所以说AM是一个应用程序启动的第一个Container，为Container0。
- MRAPPmaster启动后，会定期向RM发送心跳信息，一是为了跟RM中的应用管理器APPlications Manager通信，报告自己的状态是否存活等，二是与RM保持通信，提交自己的资源需求，等待其ResourceScheduler给起分配资源。
- AM启动后，表示应用程序起来了，但是实际的计算并没有开始。AM会将自己需要的资源需求发给RM。这个时候如果Scheduler有资源分配给AM，返回《主机名，container数，资源大小.....》。则AM会跟对应的NM进行RPC通信，在对应的NM上启动Container进行任务计算。这些Container受AM的监管。
- 默认是AM在十分钟内没有向RM的应用管理器汇报心跳，则被认为其死亡了。受这些AM管理的所有Contaier都会被置为失败，Killed。 应用管理器会重新申请分配一个Container，启动新的AM，类似于任务重新提交跑（默认配置AM尝试次数2次，可修改）。
2.4 ResourceManager与NodeManager通信交互
RM通过的实现的ResourceTrack接口来和NM进行通信，RM与NM的通信主要实现如下几个功能：
- 新节点NM向RM的注册
- 接受管理已经注册的NM节点的心跳，并通过心跳下达指令
- 安全身份认证只有合法的NM才可以与RM通信
RM中的ResouceTrack Service会将AM心跳的的资源请求发送给ResouceScheduler调度器，调度器会根据NM节点的实际资源使用情况以及应用程序实际资源请求调度分配资源。
NM在默认10分钟内没有像RM发送心跳，就会被标记死亡。RM将不会在往这个节点分配Container，直到这个节点重启，重新加入RM.
2.5 RM,AM,NM的协同合作架构
如上图所示：
第1步.用户通过YARN客户端向提交YARN支持的应用程序，其中包括了Application Master程序，启动AM的名命令，用户程序，对应的资源等。具体内部的流程参考上面。
第2步：通过AM的安全校验后，Resource Manager为该AM分配一个Container,然后与对应的NM通信，要求在上面启动这个Container，启动运行AM程序
第3步：AM首先向RM进行注册，其实就是RM中ResourceManager应用管理器注册（这个时候用户就可以通过RM的YARN日志界面查看这个AM了）。然后AM开始为应用程序的各个任务（比如一个MR任务有2000maps,1099reduces）申请运行资源，监控管理运行任务的状态,直到任务运行结束。后面就是重复4-7步了。
第4步：AM在监控管理已经运行的任务实例时（如map task），同时保持RM周期性心跳，通过RPC通信向RM提交自己的资源需求，顺便通过心跳领取资源（RM返回对应的主机，启动对应的Containers，大小等）
第5步：AM领取到资源时，便与对应的NM通信，要求NM启动该应用程序对应Container，执行相关任务实例。
第6步：NM会为第5步AM要求即将启动的任务，设置好运行环境，下载好需要的资源（环境变量，JAR包，配置文件，依赖的文件等），最后通过任务的启动脚本启动任务。（具体参考 剖析NodeManager篇）
第7步:拉起后的任务，通过心跳机制向AM汇报自己的运行的状态进度，AM对其监控，包括失败重启，推测执行等等。同时NM监控各个Container的运行状态，像RM进行汇报。
第8步：应用程序执行完成后，AM通知RM作业完成，然后RM通知NM聚集日志（一般上传HDFS）,并且清理Container专用文件。如果还有推测执行的Container，则会被直接杀死。
尖叫提醒：AM管理的是应用程序相关的任务实例，以MapReduce为例，其MRAM管理的是运行在Container上里的maptask/reducetask，运行状态，会否成功等；而NM管理的是Container，监控Container的状态；RM则管理的是更上层的NM节点的的状态。
3.ResourceManager内部其他组件
RM内部两大员工：ResourceScheduler和APPlications Manager。除此之外，还有大量的组件，配合保证RM与客户端，NM,AM进行通信，协调资源分配，任务执行等。
3.1身份验证SecretManager
因为yarn的客户端部署安装很简单，是不是大家只要在内网随便参考生产集群的配置文件，模拟一个客户端就可以与之通信了呢？那么如何防止外部伪装呢？
RM内部的SecretManager提供了一系列AM,NM与之通信的令牌与私钥管理机制，进而三者通过RPC通信时进行安全认证与授权。
比如ContainerToken SecretManager保证RM通过AM下发申请，向NM申请Container时的安全性，具体内部使用还是比较复杂的，后期再详细讲解。
比如AMRMToken SecretManager 保证了AM与RM申请资源时的验证与授权，RM会在起始阶段给每个AM分配一个令牌，这些令牌会保存起来直到AM管理的程序执行完毕，在此期间，RM都会通过保存的令牌进行验证。
3.2 Administration Service
这个主要是用来给管理员使用，通过ResourceManagerAdministrationProtocol通信协议实现管理员动态操作或者刷新YARN配置使用的。比如：
- 刷新队列：新增队列，重新配置队列的资源分配，权重，用户ACl限制，队列删除等等。默认YARN10s重新加载一次配置文件，实现冬天刷新，不需要重启集群。
- 用户管理：添加管理员，修改管理员权限等
- 动态刷新YARN管理的节点列表。比如节点退役，有个exclude文件，将需要剔除计算节点的节点剔除集群，停止提交YARN任务。同样维护哪些节点可以进行资源分配的等等，做存储计算分离等。
3.3 ApplicationMaster launcher
AM本质是一个运行的Container，且是提交应用程序的第一个Container，Container0 。 应用程序启动时，会向RM申请Container,RM分配对应的Container和节点ip后，APPlications Manager应用管理器会在该节点启动AM。而与NM通信拉起AM的这个角色就是ApplicationMaster launcher。
该组件维护了一个线程池，通过与NM通信，来处理所有新提交应用程序启动的AM。当然同时如果有AM失败，也靠它重新拉起。此外，如果一个应用程序跑完以后，或者应用程序主动被停止，需要杀死AM,也是通过它和NM通信发送命令干的。
?