前面几篇关于ApplicationMaster的文章，把ApplicationMaster与RM之前的相关的流程已梳理完毕了(ApplicationMaster与NM之前的流程随后梳理)，其中有几个关键类ApplicationMaster(以MRAppMaster为例)、AMLivelinessMonitor、ApplicationMasterLauncher和ApplicationMasterService，本篇重点介绍下这4个类之间的关系。

先看下这4个类之间的整体架构图：
ApplicationMaster架构图

简单描述下整个流程：

  • 首先client向RM提交一个application请求，RM创建一个application，然后再创建一个appattempt，后期的调度和任务的拆解都是对这个appattempt进行的。随着appattempt的状态变化，会触发AMLauncherEventType.LAUNCH事件类型的事件，由ApplicationMasterLauncher.handle进行处理，通过RPC调用containerMgrProxy.startContainers来启动一个ApplicationMaster。

  • ApplicationMaster启动成功之后，返回到AMLauncher.run中会触发RMAppAttemptEventType.LAUNCHED事件类型的事件，向AMLivelinessMonitor中注册am。

  • 以MRAppMaster为例，当ApplicationMaster启动时会启动MRAppMaster这个服务，MRAppMaster启动的时候会向ApplicationMasterService注册。

  • 然后开启一个心跳线程，由此线程周期性的发送心跳，心跳中包含所需container的请求列表和所要释放的container的列表，通过RPC调用ApplicationMasterService.allocate来获取资源，在此过程中会向AMLivelinessMonitor发送ping，更新在AMLivelinessMonitor中记录的生命时钟。

  • 当job结束之后，调用ApplicationMaster.finish，通过RPC最终调用ApplicationMasterService.finishApplicationMaster，在此过程中依然会向AMLivelinessMonitor发送ping，更新在AMLivelinessMonitor中记录的生命时钟。

下面概括下各个类的主要作用：

ApplicationMasterLauncher

ApplicationMasterLauncher继承了AbstractService实现了EventHandler接口，使其即是一个服务也是一个事件处理器。
ApplicationMasterLauncher只处理两类事件，一个是启动AM的LAUNCH和清理AM的CLEANUP请求，这两类事件被放入一个事件队列中，由ApplicationMasterLauncher作为服务时，启动一个launcherHandlingThread线程将事件取出放入线程池中处理。
如果ApplicationMasterLauncher收到了LAUNCH类型的事件，它会与对应的NodeManager通信，要求它启动ApplicationMaster。整个过程在这篇文章中详细介绍了下，这里简单回顾下，首先创建一个ContainerManager协议的Client，然后向对应的NodeManager发起连接请求，接着将启动AM所需的各种信息，包括命令，Jar包、环境变量等信息，封装成一个StartContainerRequest对象，然后通过RPC函数ContainerManager.startContainer()发送给对应的NM。
如果ApplicationMasterLauncher收到了CLEANUP类型的事件，它会与对应的NodeManager通信，要求它杀死ApplicationMaster。整个过程与启动AM的过程类似。

AMLivelinessMonitor

AMLivelinessMonitor主要用来监控am的生命状态，如果AM长时间没有心跳信息更新，RM就会通知NodeManager把AM移除。appattempt在启动的时候会向其注册am信息，然后AMLivelinessMonitor会周期性遍历所有ApplicationMaster，如果一个ApplicationMaster在一定时间（可通过参数yarn.am.liveness-monitor.expiry-interval-ms配置，默认为10min）内未汇报心跳信息，则认为它死掉了，它上面所有正在运行的Container将被置为运行失败（RM不会重新执行这些Container，它只会通过心跳机制告诉对应的AM，由AM决定是否重新执行，如果需要，则AM重新向RM申请资源），AM本身会被重新分配到另外一个节点上（管理员可通过参数yarn.resourcemanager.am.max-retries指定每个ApplicationMaster的尝试次数，默认是1次）执行。

ApplicationMasterService

ApplicationMasterService负责处理来自ApplicationMaster的请求，主要包括三种请求：注册、心跳和清理，这部分内容在这篇文章中详细介绍了下，这里简单回顾下，其中，注册是ApplicationMaster启动时发生的行为，请求包中包含AM所在节点，RPC端口号和tracking URL等信息；心跳是周期性行为，包含请求资源的类型描述、待释放的Container列表等，而AMS则为之返回新分配的Container、已完成的Container等信息；清理是应用程序运行结束时发生的行为，ApplicationMaster向RM发送清理应用程序的请求，以回收资源和清理各种数据结构。