Flink源码解析(十一)——Flink On Yarn JobManager启动过程WebmonitorEndpoint启动解析
一、JobManager三大组件功能简介
JobManager是Flink系统master节点的逻辑称呼，不同的部署模式有不同的实现类，对于Flink On Yarn下Application模式，其实现类是YarnApplicationClusterEntryPoint。JobManager由三个核心组件构成，分别是ResourceManager、Dispatcher和WebmonitorEndpoint，以下是核心组件的功能简介。
1、WebmonitorEndpoint：Rest服务，内部由Netty实现。客户端发起的所有请求都会被该组件接收处理。
2、Dispatcher：负责接收客户端提交的JobGraph请求，启动一个JobMaster。内部持有一个JobGraphStore，当物理执行图构成过程中主节点发生故障时，可以从JobGraphStore中从新拉起一个新的JobGraph。
3、ResourceManager：Flink集群的资源管理器，作用于Flink和资源管理集群(Yarn、K8s等)之间。主要功能包括启动新的TaskManager、为作业申请slot、维持和TaskManager、JobMaster的心跳等功能。
二、Zookeeper Curator框架Leader选举过程简述
本系列随笔主要解析基于zookeeper组件的高可用实现。三个核心组件在高可用过程中涉及到Leader选举时采用Zookeeper Curator框架LeaderLatch方式。其Leader选举基本原理是同一类的LeaderContender，每个LeaderContender在启动时都会创建一个LeaderLatch，使用相同的leader path和其他LeaderLatch交互，其中一个最终会被选举为leader。LeaderLatch在启动执行start()方法之前会先调用addListener(...)方法添加一个LeaderLatchListener，在被选举为leader时回调LeaderLatchListener的isLeader()方法，isLeader()方法即包含选举leader成功后LeaderContender的后续操作。在未被选举为leader时，会回调LeaderLatchListener的notLeader()方法，保持备用状态。
三、JobManager启动过程WebmonitorEndpoint启动解析
上一篇随笔最后小节介绍到YarnApplicationClusterEntryPoint启动过程最后会调用到ClusterEntrypoint.runCluster(...)方法，但只分析到Flink应用main(...)方法启动过程。现在继续分析ClusterEntrypoint.runCluster()方法涉及的三大组件创建过程。
1、ClusterEntrypoint.initializeServices()方法，为了支持上面3个核心组件的运行，该方法会生成8个基础服务，分别如下：
(1)、commonRpcService = RpcUtils.createRemoteRpcService(...);初始化和启动PekkoRpcService
(2)、JMXService.startInstance(configuration.getString(JMXServerOptions.JMX_SERVER_PORT));启动一个 JMXService，客户端用于连接JobManager JVM 进行监控
(3)、ioExecutor = Executors.newFixedThreadPool(...);初始化一个负责集群io的线程池
(4)、haServices = createHaServices(configuration, ioExecutor, rpcSystem);创建一个ZooKeeperLeaderElectionHaServices类型的高可用服务
(5)、blobServer = BlobUtils.createBlobServer(...);初始化BlobServer服务端
(6)、heartbeatServices = createHeartbeatServices(configuration);创建一个心跳服务，管理组件心跳
(7)、metricQueryServiceRpcService = MetricUtils.startRemoteMetricsRpcService(...);性能监控服务
(8)、executionGraphInfoStore = createSerializableExecutionGraphStore(...);初始化一个FileExecutionGraphInfoStore类型的ExecutionGraph store服务
2、WebmonitorEndpoint创建过程解析：在生成以上8个基础服务后紧接着会生成DispatcherResourceManagerComponent clusterComponent实例对象，该实例对象由DispatcherResourceManagerComponentFactory实例的create(...)方法生成。DispatcherResourceManagerComponentFactory实例创建过程如下，可知主要包含WebmonitorEndpoint、Dispatcher、ResourceManager3大核心组件的工厂类。
ApplicationClusterEntryPoint.createDispatcherResourceManagerComponentFactory(){
new DefaultDispatcherResourceManagerComponentFactory{
dispatcherRunnerFactory:new DefaultDispatcherRunnerFactory{
dispatcherLeaderProcessFactoryFactory(configuration,dispatcherFactory,program):ApplicationDispatcherLeaderProcessFactoryFactory.create(configuration, SessionDispatcherFactory.INSTANCE, program)
};
resourceManagerFactory:YarnResourceManagerFactory.getInstance();
restEndpointFactory:JobRestEndpointFactory.INSTANCE;
}
}
在DispatcherResourceManagerComponentFactory.create(...)方法中先创建dispatcher、resourcemanager的leader检索服务和其他辅助组件后进入WebmonitorEndpoint的创建过程，创建完成后执行start()方法启动。
WebmonitorEndpoint的创建过程在JobRestEndpointFactory.INSTANCE.createRestEndpoint(...)方法中实现，主要继承关系如：MiniDispatcherRestEndpoint(C) <- WebMonitorEndpoint(C) <- {LeaderContender(I)、RestServerEndpoint}，表明WebMonitorEndpoint也是一个LeaderContender候选者。在上图createRestEndpoint(...)调用用，高可用服务highAvailabilityServices.getClusterRestEndpointLeaderElection()会先获取一个"rest_server"的componentId标识，然后创建一个WebMonitorEndpoint的Leader选举服务new DefaultLeaderElection(this, componentId)。可知一个LeaderContender候选者实例包含一个用componentId标识的Leader选举服务DefaultLeaderElection。一类LeaderContender的多个候选者实例在通过start()方法启动时会通过DefaultLeaderElection服务确认一个Leader状态的候选者。webMonitorEndpoint.start()内容很多，一一进行解析：
(1)、客户端请求Handler生成。
1)、创建Router、将客户端的请求路由到具体的Handler。
2)、initializeHandlers(...)方法注册一系列的Handler，对应具体的请求处理逻辑。
3)、将Handlers按请求地址信息排序，目的是确认请求URL和Handler的一一对应关系
4)、确认Handler的唯一性，然后将所有的Handler注册到Router当中。
(2)、Netty服务端启动操作，Handlers注册完以后开发Netty服务端的启动操作，通道初始化器生成、Netty服务端启动、遍历端口范围，防止端口冲突后绑定端口。
(3)、Netty服务端启动后，修改WebMonitorEndpoint状态为RUNNING状态，并进行Leader选举和启动其他基础服务。
1)、开始Leader选举过程。
2)、在选举过程中创建LeaderElectionDriver组件，并赋值issuedLeaderSessionId。
3)、创建LeaderElectionDriver。
4)、由第二节介绍的Zookeeper Curator框架Leader选举过程可知，LeaderLatch在启动执行start()方法之前会先调用addListener(...)方法添加一个LeaderLatchListener，在被选举为leader时回调LeaderLatchListener的isLeader()方法，isLeader()方法即包含选举leader成功后LeaderContender的后续操作。在未被选举为leader时，会回调LeaderLatchListener的notLeader()方法，保持备用状态。
5)、选举Leader成功后回调isLeader()方法，并赋值issuedLeaderSessionID。此时leaderContenderRegistry还未添加componentId -> WebMonitorEndpoint的映射，onGrantLeadershipInternal(...)直接退出，因此leaderElectionDriver创建完成并退回到上面的register(...)方法中。
6)、register(...)方法在创建完LeaderElectionDriver后添加componentId -> WebMonitorEndpoint的映射，遍历leaderContenderRegistry并执行上面的notifyLeaderContenderOfLeadership(...)方法，后面会调用到WebMonitorEndpoint的grantLeadership(...)方法。
7)、最后可知WebMonitorEndpoint选举Leader成功后没有走什么复杂的操作，只是将自己的信息写入Zookeeper路径中。
四、WebMonitorEndpoint启动总结
以上可知WebMonitorEndpoint的启动过程不太复杂，只要是初始化了一系列的Handler、启动Netty服务并注册Handlers、WebMonitorEndpoint候选者竞选Leader过程并将自己的信息写入Zookeeper中。下一篇随笔解析ResourceManager的启动过程。
