夜天之书 #13 Flink Runtime

今天对着下面的流程图简单介绍一下 Flink Runtime 的各个组件及其交互流程。

由于每个流程细讲内容太多，Flink 经过多年的发展在每个环节上有复杂的策略，这里只会对着图例简单讲讲，更多的信息留给其他文档材料。

第一个流程，提交 Flink 应用。

其实这个流程里面就有很多策略。如果是 JobCluster 或者 AppCluster 的部署模式，其实这个流程里会把从用户应用编译得到的 JobGraph 一并打包进 Entrypoint 交给 YARN 或 Kubernetes 启动应用，并省略掉第三个流程 Submit Job 的步骤。

这个图上的流程可以认为是 SessionCluster 的部署起点。实际上，对于 Streaming 作业来说，资源独占才是 long running 作业的最佳策略，因此抽象出 Dispatcher 和 ResourceManager 并期待服务多个 JobManager 的情况并不务实。

•Deployment^[1]•3.22 【1.10特别篇】Running Flink on Kubernetes natively^[2]

第二个流程，启动 Flink 应用。

与上一个流程一脉相承。

这里需要说明的是 Flink AM 包括 Dispatcher / ResourceManager / JobManager 三个组件，其中前两个组件在每个 Flink 集群当中是唯一的，而 JobManager 理论上可以有多个，每个对应到一个 JobGraph 表示的任务。

Dispatcher 类似于 API Gateway 的角色，主要处理 Client 的请求，把相关的命令或数据采集请求转发给其他两个组件处理并返回结果。此外，可以接受 Client 提交的 JobGraph 并创建对应的 JobManager 实例。

吐槽一个技术细节，这三个组件各自有自己的选主机制，但是实际上一直以来都在同一个 JVM 里，完全可以共享选主的概念，不会出现 AM 和 Standby AM 一边有一半 Leader 的坑爹情况。

如果不为了这种奇怪的拆分要求，完全可以参考 FLIP-6 之前的架构，一个 JobManager 带着 Resource Client 做资源管理，顺便解决网络请求完事。

不过话说回来，这种过度的拆分倒也是一种技术壁垒，其他 Streaming System 初创团队也完全抄不动。

•FLIP-6 Flink Deployment and Process Model^[3]

第三个流程，提交 Flink 作业。

只在 Session 模式下有用，Job 和 Application 模式下 Dispatcher 会拒绝这种请求。

•Submitting a Job^[4]

第四个流程，创建 JobManager 实例。

前面提到了，Dispatcher 几兄弟都在一个 JVM 里，每个 JobManager 就是一个线程。具体地说是 Akka 实现的 Actor System 里的一个 Actor 实例。

JobManager 会接收 JobGraph 并编译到 ExecutionGraph 再进行后续的流程。这个过程