一、概述

无论是 Session 模式还是 Per_Job 模式，其 main 方法都是在容户端执行来获取 Flink 运行时所需的依赖项，并生成
JobGraph，提交到集群的操作都会在实时平台所在的机器上执行，会给服务器造成很大的压力。尤其在大量用户共享客户端时，问题更加突出。其次，两种模式提交任务的时候会把本地 Flink 的所有 jar 包先上传到 hdfs 上相应的临时目录，这个会带来大量的网络的开销，如果任务特别多的情況下，平台的吞吐量将会直线下降。
Flink-1.11 中引入了一种新的部署模式，即 Application 模式。Application 模式下，用户程序的 main 方法将在集群中而不是客户端运行。
用户将程序選辑和依赖打包进一个可执行的 jar 包里，集群的入口程序 (ApplicationClusterEntryPoint) 负责调用其中的 main 方法生成 JobGraph

Applicaton 模式为每个提交的应用程序创建一个集群，该集群可以看作是在特定应用程序的作业之间共享的会话集群，并在应用程序完成时终止。

二、架构设计

目前，Flink-1.11 已经可以支持基于 Yarn 和 Kubernetes 的 Application 模式。

2.1. Yarn Application

2.1.1. 启动集群

2.1.2. 作业提交

2.1.3. 作业调度

引用本站文章

Flink-源码学习-架构设计-部署模式-Application-Flink On Yarn

Joker

2.2. Kubernetes Application

2.1.1. 启动集群

2.1.2.作业提交

2.1.3. 作业调度

2.1.4. Native 模式

为什么叫 Native 方式 🤔️～

Flink 的 Client 内置了一个 K8s Client, 可以借助 K8s Client 去创建 JobManager，当 Job 提交之后，如果对资源有需求，
JobManager 会向 Flink 自己的 ResourceManager 去申请资源。这个时候 Flink 的 ResourceManager 会直接跟 K8s 的 API
Server 通信，将这些请求资源直接下发给 K8s Cluster，告诉它需要多少个 TaskManger，每个 TaskManager 多大。当任务运行
完之后，它也会告诉 K8s Cluster 释放没有使用的资源。

Native 是相对于 Flink 而言的，借助 Flink 的命令就可以达到自治的一个状态，不需要引入外部工具就可以通过 Flink 完成任务在
K8s 上的运行。

2.1.5. refer

引用本站文章

Flink-源码学习-架构设计-部署模式-Application-Flink On Kubernetes

Joker

三、总结

针对 Flink Per-Job 模式的一些问题，Flink 引入了一个新的部署模式 Application 模式。目前 Application 模式支持 Yarn 和 K8s 的部署方式，Yarn Application 模式会在客户端将运行任务需要的依赖都上传到 Flink Master，然后在 Master 端进行任务的提交。
此外，还支持远程的用户 jar 包来提交任务，比如可以将 jar 放到 hdfs 上，进一步减少上传 jar 所需的时间，从而减少部署作业的时间。
采用 Application 模式部署，规避了 Session 模式的资源隔离问题、Per-Job 模式的集群生命周期问题，以及两者共同的客户端资源消耗问题，也因其显著优点被广泛用于生产环境。

3.1. 集群生命周期

ResourceManger 会为每一个提交的**Applcation(包含一个或多个作业)**启动一个 Flink 集群。集群的生命周期与Application 的生命周期相关。

3.2. 资源隔离

资源隔离的粒度是 Application。 Application 之间隔离，Application 内的所有作业共享集群。

3.3. main() 执行位置

集群侧，在之前的两种模式中，客户端需要获取依赖 jar 包(网络)，生成逻辑执行计划（CPU 和内存），上传 jar 包和提交 JobGraph 到集群(网络)，客户端可能需要大量的网络带宽来下载依赖项和将二进制文件发送到集群。
在生产环境中，为了简化用户操作的负担，简化应用程序的提交。一些平台通常只公开一个集中式或低并行度端点(Web前踹）用于应用提交，也就是客户端数量为一个或者很少的几个。因此客户端可能会成为瓶颈，所以 Application 模式的 main() 函数转移到了集群侧。

3.4. 适用场景

可以看出这种模式与前两种明显的区别就是 main()方法执行位置，这种模式适用于 client(）容易成为瓶颈的任务。Per-Job Mode 的优点是资源隔离程度高，而 Session Mode 的优点是可以在同一个集群中运行多个作业不用反复申请资源。Application 模式是一个在资源隔离的优点与资源共用的优点之间的平衡。
~~猜测该模式可能适用于发生时间间隔较短的凡个作业生成—个应用程序的场景。~~🤔️～