YARN源码分析之ApplicationMaster架构

前面几篇关于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发送清理应用程序的请求,以回收资源和清理各种数据结构。

您的肯定,是我装逼的最大的动力!