云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

作为现代企业的重要工具，流处理和实时分析这类工具逐渐兴起，越来越多的企业以 Apache Flink 为核心构建平台，并将其作为服务在内部提供。在最新举办的 Flink Forward 会议中， Uber 、 Netflix 和 阿里巴巴等公司的许多相关主题演讲进一步说明了这一趋势。

这些平台旨在通过减轻最终用户的所有运营负担来简化内部的 Application （应用）提交。为了提交 Flink 应用程序，这些平台通常只公开一个集中式或低并行度端点（例如 Web 前端）用于应用提交，我们将调用 Deployer（部署器）。

平台开发人员和维护人员经常提到的障碍之一是，Deployer 可能是一个很难配置的大量资源消耗者。如果按照平均负载进行配置，可能会导致 Deployer 服务被部署请求淹没（在最坏的情况下，短时间内对所有生产应用程序都是如此），而按照最高负载进行规划的话，又会带来不必要的成本。根据这一观察结果，Flink 1.11 引入了 Application 模式（应用模式）作为部署选项，它允许一个轻量级、更可伸缩性的应用提交过程，从而使应用程序部署负载更均匀地分布在集群的各个节点上。

为了理解这个问题以及了解 Application 模式如何解决该问题，我们首先简要概述 Flink 中应用程序执行的当前状态，然后再阐述部署模式引入的架构变化以及如何利用它们。

Flink 中的应用程序执行

在 Flink 中执行应用程序主要涉及三个实体：Client（客户端）、JobManager（作业管理器）和 TaskManager（任务管理器）。Client 负责将应用提交给集群，JobManager 负责执行期间必要的 bookkeeping，而 TaskManager 则负责实际的计算。更多细节请参考 Flink 的架构文档。

当前部署模式
在 1.11 版本中引入 Application 模式之前，Flink 允许用户在 Session（会话）或 Per-Job 集群上执行应用程序。两者之间的差异与集群生命周期和它们提供的资源隔离保证有关。