11.JobManager 启动流程总结

JobManager 启动流程总结（对 1~10 的再收敛）

本文基于本目录 1~10 的内容，把 JobManager（Standalone Session 为主）的启动链路再收敛成一条可复述的主线：先初始化地基服务（RPC/HA/Blob/Heartbeat/Metrics...），再创建并启动三大核心组件（Dispatcher / ResourceManager / WebMonitorEndpoint），最后把"选举/发现/RPC 网关/对外 REST"串成闭环并进入生命周期等待。

对应阅读入口：

• 1.JobManager启动流程解析.md
• 2.Flink RPC通信流程解析.md
• 3.HAService启动流程解析.md
• 4.blobServer解析.md
• 5.HeartbeatServices启动解析.md
• 6.metricService解析.md
• 7.DispatcherResourceManagerComponentFactory解析.md
• 8.WebMonitorEndpoint解析.md
• 9.resourceManager启动源码解析.md
• 10.dispatch源码解析.md

1. 一句话主线（总览）

Entrypoint.main
startCluster（安全/FS/插件）
runCluster
initializeServices（地基：RPC/HA/Blob/Heartbeat/Metrics...）
Factory.create（核心：Web → RM → Dispatcher）
选举/发现 → RpcGatewayRetriever.connect → 网关可用
REST 对外服务 + 生命周期阻塞等待 shutdown

把它拆成两句就是：

• initializeServices(...) 解决"把集群进程跑起来需要哪些底座能力"的问题；
• DispatcherResourceManagerComponentFactory#create(...) 解决"三大核心组件按什么顺序创建/启动，并如何互相找到对方"的问题。

2. 核心组件职责（先对齐边界）

• Dispatcher：作业提交入口与调度编排中枢，对外提供 DispatcherGateway；其启动与存活被绑定到 Dispatcher 的 leader 任期（见 10.dispatch源码解析.md）。
• ResourceManager：TaskManager 注册/心跳/slot 管理与资源分配，对外提供 ResourceManagerGateway；其启动也被绑定到 leader 任期（见 9.resourceManager启动源码解析.md 与 5.HeartbeatServices启动解析.md）。
• WebMonitorEndpoint：Web UI + REST API；对外是 HTTP 服务，对内通过 gateway retriever 把请求转发到 Dispatcher/RM（见 8.WebMonitorEndpoint解析.md）。

配套"地基"能力：

• RPC：RpcService + RpcEndpoint + RpcGateway(动态代理) + PekkoInvocationHandler，让"像本地方法一样调用远端组件"成立（见 2.Flink RPC通信流程解析.md）。
• HA：HighAvailabilityServices + LeaderElection + LeaderRetrievalService，把"谁是 leader、leader 在哪里"外置/统一抽象（见 3.HAService启动流程解析.md）。
• BlobServer：作业 jar/依赖的上传、缓存、分发与（可选）BlobStore 恢复（见 4.blobServer解析.md）。
• Heartbeat：RM ↔ TM（以及 JM ↔ RM）存活探测与 payload 通道（见 5.HeartbeatServices启动解析.md）。
• Metrics：MetricRegistry + MetricQueryService 将"注册 → 采集/上报 → 查询"闭环打通（见 6.metricService解析.md）。

3. 启动流程分阶段（从 Entrypoint 到三大组件）

3.1 启动入口（main/startCluster/runCluster）

这部分的关键结论来自 1.JobManager启动流程解析.md：

• main：解析参数与配置、初始化 Entrypoint 并进入 ClusterEntrypoint.runClusterEntrypoint(...)。
• startCluster：安装安全上下文、插件/文件系统初始化，然后在受控环境中进入 runCluster(...)。
• runCluster：先 initializeServices(...)，再走 Factory.create(...) 启动核心组件，并把 getShutDownFuture() 挂到进程生命周期上阻塞等待。

3.2 地基服务初始化（initializeServices）

可以把 initializeServices(...) 当作"主进程运行时依赖注入容器"的手写装配点：它把后续组件创建需要的对象一次性准备好，并将关键地址/端口写回 Configuration（例如 JM RPC 地址、BlobServer 端口）。

地基清单与"谁消费它"：

• 工作目录（workingDirectory）：Blob 存储、临时文件与本地缓存目录的基础。
  • 主要消费者：BlobServer、REST 上传目录、（部分恢复/缓存组件）。
  • 关联：见 1.JobManager启动流程解析.md 与 4.blobServer解析.md。
• RPC 系统与 commonRpcService：为 Dispatcher/RM/Web/TaskExecutor 等端点注册与互联提供底座。
  • 主要消费者：RpcGatewayRetriever.connect(...)、各类 RpcEndpoint.start()。
  • 关联：见 2.Flink RPC通信流程解析.md。
• ioExecutor：给 HA driver、恢复流程、异步回调等后台任务提供线程池。
  • 主要消费者：HA、Dispatcher leader process、RM leader 切换、Blob 清理等。
• DelegationTokenManager：安全体系/外部文件系统凭证的获取与刷新。
  • 主要消费者：RM、Blob 访问外部 FS。
• HighAvailabilityServices：为 Dispatcher/RM/REST 提供选举/发现与元数据能力门面。
  • 主要消费者：DefaultDispatcherResourceManagerComponentFactory#create(...)（拿 election 与 retrieval）。
  • 关联：见 3.HAService启动流程解析.md。
• BlobServer：作业 jar/依赖的上传/下载/缓存/（可选）BlobStore 恢复。
  • 主要消费者：REST 上传/作业提交、（作业依赖分发相关链路）。
  • 关联：见 4.blobServer解析.md。
• HeartbeatServices：固化 interval/timeout/失败阈值的心跳工厂。
  • 主要消费者：RM 与 TM 在 onStart/连接阶段创建 HeartbeatManager(Sender/Receiver)。
  • 关联：见 5.HeartbeatServices启动解析.md。
• MetricRegistry + MetricQueryService：指标注册/查询闭环；QueryService 跑在 metrics 专用 RpcService 上。
  • 主要消费者：Web UI/REST 的 metrics 拉取、各组件 metric group 注册。
  • 关联：见 6.metricService解析.md。
• ExecutionGraphInfoStore：为 REST 查询 ExecutionGraph 等信息提供存储（JM 侧常见内存实现）。

4. 三大核心组件如何被创建并启动（Factory.create 的顺序）

核心顺序由 7.DispatcherResourceManagerComponentFactory解析.md 收敛：

1. 基于 HA 拿到 Dispatcher/RM 的 LeaderRetrievalService，并创建 RpcGatewayRetriever（leader 地址 → gateway 代理）。
2. 创建并 start() WebMonitorEndpoint：先把 HTTP 端口绑定起来，生成 restBaseUrl，并启动 REST endpoint 自己的 leader 选举（HA 场景用于对外发布 REST leader 地址）。
3. 创建 ResourceManagerServiceImpl（不是 RM 本体）：它是 LeaderContender，当选 leader 后才创建并启动真正的 ResourceManager（RpcEndpoint）。
4. 创建 DispatcherRunner：也是 LeaderContender，当选 leader 后创建 leader process 并启动真正的 Dispatcher。
5. resourceManagerService.start()：触发 RM 侧选举（Standalone 下通常"退化为立刻授予 leadership"）。
6. resourceManagerRetrievalService.start(retriever) 与 dispatcherLeaderRetrievalService.start(retriever)：开启"发现 leader → connect → 得到 gateway"的链路。

initializeServices 完成
DefaultDispatcherResourceManagerComponentFactory.create
创建 Dispatcher/RM GatewayRetriever（LeaderRetrieval → RpcGatewayRetriever）
create & start WebMonitorEndpoint（bind → restBaseUrl → REST leader election）
create ResourceManagerServiceImpl（LeaderContender）
create DispatcherRunner（LeaderContender）
resourceManagerService.start → startLeaderElection
start LeaderRetrievalService（Dispatcher/RM）
封装为 DispatcherResourceManagerComponent（统一 shutdown/close）

5. HA + RPC：把"选举/发现/网关调用"串成闭环

这部分是 3.HAService启动流程解析.md 与 2.Flink RPC通信流程解析.md 的交汇点：选举决定"谁是 leader"，发现给出"leader 在哪里"，RPC 把"地址"变成"可调用的网关对象"。

5.1 Standalone(NONE) vs HA（差异落点）

• Standalone(NONE)：StandaloneHaServices 在创建时就把 Dispatcher/RM 的 RPC URL 拼好；StandaloneLeaderRetrievalService.start(listener) 会立刻通知地址；StandaloneLeaderElection 会在注册 contender 时立刻 grant leadership。
• HA（ZK/K8s）：leader 信息由后端 driver 存取；confirmLeadershipAsync(sessionId, address) 把地址写回后端；retrieval 监听后端变化并 notify listener。

5.2 "Leader 地址 → Gateway → 调用执行"的收敛链路

LeaderElection.grantLeadership(sessionId)
组件启动（DispatcherRunner / RM Service）
confirmLeadershipAsync(sessionId, address) 写回 leader 地址
LeaderRetrievalService.notifyLeaderAddress(address, sessionId)
RpcGatewayRetriever.createGateway → rpcService.connect(...)
得到 RpcGateway 动态代理
调用代理方法 → PekkoInvocationHandler.invoke
封装 RpcInvocation → tell/ask 发给 PekkoRpcActor
Actor 线程执行 RpcEndpoint 方法 → CompletableFuture 返回

这张图对应两个关键"抽象层面"的分工：

• HA：负责把 "leaderSessionId + leaderAddress" 这对信息稳定地产生与传播；
• RPC：负责把 "leaderAddress" 变成一个 Gateway 代理对象，并把方法调用转成 actor 消息投递执行。

6. Web/REST：对外入口如何进到 Dispatcher/RM

来自 8.WebMonitorEndpoint解析.md 与 10.dispatch源码解析.md 的合并视角：

• WebMonitorEndpoint 的 start() 先完成 Netty 端口绑定与 handler 注册，随后 startInternal() 启动 REST endpoint 自己的 leader 选举，并在 grant leadership 时 confirmLeadershipAsync(restBaseUrl) 对外发布 REST leader 地址。
• REST handlers 内部通过 dispatcherGatewayRetriever/resourceManagerGatewayRetriever 获取当前 leader 的网关代理，从而把 HTTP 请求转为对 Dispatcher/RM 的 RPC 调用。
• 作业 jar 上传与依赖分发依赖 BlobServer：REST 上传完成后，提交逻辑会把 jar/依赖作为 blob 引用交给后续组件处理（BlobServer 的 PUT/GET/缓存/（可选）BlobStore 回源见 4.blobServer解析.md）。

7. ResourceManager 与 Heartbeat：RM 启动后如何进入"可维持集群运行"

来自 9.resourceManager启动源码解析.md 与 5.HeartbeatServices启动解析.md 的合并视角：

• ResourceManagerServiceImpl 负责 leader 任期：startLeaderElection(this) → grantLeadership(sessionId) → 创建 ResourceManager（RpcEndpoint）→ resourceManager.start()。
• ResourceManager.onStart() 里启动 RM 核心子系统，其中 startHeartbeatServices() 会创建心跳 Sender（RM 主动向 TM/JM 发 request），并依赖 HeartbeatServices 固化的 interval/timeout/失败阈值。
• TM 侧通常用 HeartbeatServices.createHeartbeatManager(...)（receiver）来响应 RM 的 request，并通过 monitor/timeout 维护对端存活状态。

8. Dispatcher：从 Runner 到 LeaderProcess 再到 DispatcherGateway 可用

来自 10.dispatch源码解析.md 的主线结论：

• DefaultDispatcherRunner 是 LeaderContender，grant/revoke leadership 驱动 leader process 的启动/停止，并通过 confirmLeadershipAsync(leaderSessionId, leaderAddress) 对外发布当前 dispatcher 的可连接地址。
• Session 模式下 SessionDispatcherLeaderProcess 会在任期开始时启动恢复逻辑（JobGraphStore/JobResultStore），然后创建 DispatcherGatewayService 并最终完成 DispatcherGateway。
• leaderAddressFuture 依赖 DispatcherGateway ready 之后的 RestfulGateway.getAddress()，因此 "confirm leadership" 被自然延迟到 Dispatcher 真正可服务之后。

9. 回到主题（收束：把 1~10 合成一句话）

• 1 给出全局启动骨架：main → startCluster → runCluster → initializeServices → Factory.create → 等待 shutdown。
• 2 解释"RPC 为什么能像本地方法一样调用远端"：Gateway 代理 → InvocationHandler → tell/ask → RpcActor → Endpoint。
• 3 解释"HA 为什么能把组件串起来"：LeaderElection/confirm → LeaderRetrieval/notify → GatewayRetriever/connect。
• 4/5/6 分别补齐三块地基能力：Blob/Heartbeat/Metrics，解释它们在启动链路中何时被创建、被谁消费、输出给下一阶段什么能力。
• 7/8/9/10 解释"后半段三大组件如何启动并形成闭环"：Factory 控制顺序，REST 对外入口连到 Dispatcher/RM，Dispatcher/RM 都被绑定到 leader 任期并通过 HA+RPC 对外/对内可发现可调用。