Flink 是一个多功能框架，以混搭方式支持许多不同的部署场景。
下面我们简要解释 Flink 集群的构建块、它们的用途和可用的实现。如果你只是想在本地启动 Flink，我们建议设置一个Standalone Cluster。
概述和参考架构
下图展示了每个 Flink 集群的构建块。客户端获取 Flink 应用程序的任务，将其转换为 JobGraph 并提交给 JobManager。JobManager 将工作分配到 TaskManagers 上，在那里运行实际的操作处理（例如源、转换和接收）。在部署 Flink 时，每个构建块通常有多个组件选项可用。我们在图下方的表格中列出了它们。
| 组件 | 作用 | 实现 |
|---|---|---|
| Flink 客户端 | 将批处理或流应用程序编译成数据流图，然后将其提交给 JobManager。 |
|
| 作业管理器 | JobManager 是 Flink 的中心工作协调组件的名称。它具有针对不同资源提供者的实现，这些实现在高可用性、资源分配行为和支持的作业提交模式方面有所不同。 作业提交的JobManager模式：
|
|
| 任务管理器 | TaskManager 是实际执行 Flink 作业工作的服务。 | |
| 外部组件（全部可选） | ||
| 高可用性服务提供商 | Flink 的 JobManager 可以运行在高可用模式下，这使得 Flink 从 JobManager 故障中恢复。为了更快地进行故障转移，可以启动多个备用 JobManager 作为备份。 |
|
| 文件存储和持久性 | 对于检查点（流作业的恢复机制），Flink 依赖于外部文件存储系统 | 请参阅文件系统页面。 |
| 资源提供者 | Flink 可以通过不同的资源提供者框架进行部署，例如 Kubernetes、YARN 或 Mesos。 | 请参阅上面的JobManager实现。 |
| 指标存储 | Flink 组件报告内部指标，Flink 作业也可以报告额外的、特定于作业的指标。 | 请参阅指标报告器页面。 |
| 应用程序级数据源和接收器 | 虽然应用级数据源和接收器在技术上不是 Flink 集群组件部署的一部分，但在规划新的 Flink 生产部署时应该考虑它们。使用 Flink 托管常用数据可以带来显着的性能优势 | 例如：
|
部署模式
Flink 可以通过以下三种方式之一执行应用程序：
- 应用模式，
- Per-Job 模式，
- 会话模式。
上述模式的区别在于：
- 集群生命周期和资源隔离保证
- 应用程序的
main()方法是在客户端还是在集群上执行。
应用程序模式
在所有其他模式中，应用程序的main()方法在客户端执行。此过程包括在本地下载应用程序的依赖项，执行main()以提取 Flink 的运行时可以理解的应用程序表示（即JobGraph），并将依赖项和JobGraph(s)传送到集群。这使得客户端成为大量资源消耗者，因为它可能需要大量网络带宽来下载依赖项并将二进制文件发送到集群，并且需要 CPU 周期来执行 main(). 当客户端在用户之间共享时，这个问题会更加明显。
基于这个观察，Application Mode为每个提交的应用程序创建一个集群，但这一次，main()应用程序的方法是在 JobManager 上执行的。为每个应用程序创建一个集群可以看作是创建一个仅在特定应用程序的作业之间共享的会话集群，并在应用程序完成时拆除。使用这种架构，应用程序模式提供与Per-Job模式相同的资源隔离和负载平衡保证，但以整个应用程序的粒度。执行main()在 JobManager 上允许节省所需的 CPU 周期，但也节省了本地下载依赖项所需的带宽。此外，它允许更均匀地分布网络负载以下载集群中应用程序的依赖项，因为每个应用程序有一个 JobManager。
在应用程序模式下，在main()集群上执行，而不是在客户端上执行，就像在其他模式下一样。这可能会对您的代码产生影响，例如，您在环境中使用 注册的任何路径都registerCachedFile()必须可由应用程序的 JobManager 访问。
与Per-Job模式相比，Application Mode允许提交由多个作业组成的应用程序。作业执行的顺序不受部署模式的影响，而是受用于启动作业的调用的影响。使用execute()阻塞，建立一个顺序，它将导致“下一个”作业的执行被推迟，直到“这个”作业完成。使用executeAsync()非阻塞，将导致“下一个”作业在“此”作业完成之前开始。
应用程序模式允许多个
execute()应用程序，但在这些情况下不支持高可用性。应用程序模式下的高可用性仅支持单一execute()应用程序。此外，当应用程序模式下多个正在运行的作业（例如使用 提交
executeAsync()）中的任何一个被取消时，所有作业都将停止并且 JobManager 将关闭。支持定期作业完成（通过源关闭）。
Per-Job模式
Per-Job模式旨在提供更好的资源隔离保证，使用可用的资源提供者框架（例如 YARN、Kubernetes）为每个提交的作业启动一个集群。此集群仅可用于该作业。作业完成后，集群将被拆除并清除所有遗留资源（文件等）。这提供了更好的资源隔离，因为行为不当的作业只能降低其自己的 TaskManager。此外，它将簿记负载分散到多个 JobManager 中，因为每个作业有一个。由于这些原因，Per-Job资源分配模型是许多生产原因的首选模式。
会话模式
会话模式假设一个已经在运行的集群并使用该集群的资源来执行任何提交的应用程序。在同一（会话）集群中执行的应用程序使用并因此竞争相同的资源。这样做的好处是您无需为每个提交的作业支付启动完整集群的资源开销。但是，如果其中一个作业行为不当或关闭了 TaskManager，那么在该 TaskManager 上运行的所有作业都将受到故障的影响。除了对导致失败的作业的负面影响之外，这意味着潜在的大规模恢复过程，所有重新启动的作业同时访问文件系统并使其对其他服务不可用。此外，让单个集群运行多个作业意味着 JobManager 的负载更大，
总结
在会话模式下，集群生命周期独立于集群上运行的任何作业的生命周期，并且资源在所有作业之间共享。在每个作业方式支付旋转起来为每个提交的作业集群的价格，但这种带有更好的隔离保证的资源不能跨岗位共享。在这种情况下，集群的生命周期与作业的生命周期绑定。最后， Application Mode为每个应用程序创建一个会话集群，并main() 在集群上执行应用程序的方法。
部署
Flink 是一个多功能框架，以混搭方式支持许多不同的部署场景。
下面，我们简要解释 Flink 集群的构建块、它们的用途和可用的实现。如果你只是想在本地启动 Flink，我们建议设置一个Standalone Cluster。
概述和参考架构
下图展示了每个 Flink 集群的构建块。总是有客户端在运行。它获取 Flink 应用程序的代码，将其转换为 JobGraph 并提交给 JobManager。
JobManager 将工作分配到 TaskManagers 上，在那里运行实际的操作符（例如源、转换和接收器）。
在部署 Flink 时，每个构建块通常有多个选项可用。我们在图下方的表格中列出了它们。
| 成分 | 目的 | 实现 |
|---|---|---|
| Flink 客户端 | 将批处理或流应用程序编译成数据流图，然后将其提交给 JobManager。 |
|
| 作业管理器 | JobManager 是 Flink 的中心工作协调组件的名称。它具有针对不同资源提供者的实现，这些实现在高可用性、资源分配行为和支持的作业提交模式方面有所不同。 作业提交的JobManager模式：
|
|
| 任务管理器 | TaskManager 是实际执行 Flink 作业工作的服务。 | |
| 外部组件（全部可选） | ||
| 高可用性服务提供商 | Flink 的 JobManager 可以运行在高可用模式下，这使得 Flink 从 JobManager 故障中恢复。为了更快地进行故障转移，可以启动多个备用 JobManager 作为备份。 |
|
| 文件存储和持久性 | 对于检查点（流作业的恢复机制），Flink 依赖于外部文件存储系统 | 请参阅文件系统页面。 |
| 资源提供者 | Flink 可以通过不同的资源提供者框架进行部署，例如 Kubernetes、YARN 或 Mesos。 | 请参阅上面的JobManager实现。 |
| 指标存储 | Flink 组件报告内部指标，Flink 作业也可以报告额外的、特定于作业的指标。 | 请参阅指标报告器页面。 |
| 应用程序级数据源和接收器 | 虽然应用级数据源和接收器在技术上不是 Flink 集群组件部署的一部分，但在规划新的 Flink 生产部署时应该考虑它们。使用 Flink 托管常用数据可以带来显着的性能优势 | 例如：
|
部署模式
Flink 可以通过以下三种方式之一执行应用程序：
- 在应用模式下，
- 在 Per-Job 模式下，
- 在会话模式中。
上述模式的区别在于：
- 集群生命周期和资源隔离保证
- 应用程序的
main()方法是在客户端还是在集群上执行。
申请模式
在所有其他模式中，应用程序的main()方法在客户端执行。此过程包括在本地下载应用程序的依赖项，执行main()以提取 Flink 的运行时可以理解的应用程序表示（即JobGraph），并将依赖项和JobGraph(s)传送到集群。这使得客户端成为大量资源消耗者，因为它可能需要大量网络带宽来下载依赖项并将二进制文件发送到集群，并且需要 CPU 周期来执行 main(). 当客户端在用户之间共享时，这个问题会更加明显。
基于这个观察，Application Mode为每个提交的应用程序创建一个集群，但这一次，main()应用程序的方法是在 JobManager 上执行的。为每个应用程序创建一个集群可以看作是创建一个仅在特定应用程序的作业之间共享的会话集群，并在应用程序完成时拆除。使用这种架构，应用程序模式提供与Per-Job模式相同的资源隔离和负载平衡保证，但以整个应用程序的粒度。执行main()在 JobManager 上允许节省所需的 CPU 周期，但也节省了本地下载依赖项所需的带宽。此外，它允许更均匀地分布网络负载以下载集群中应用程序的依赖项，因为每个应用程序有一个 JobManager。
在应用程序模式下，在main()集群上执行，而不是在客户端上执行，就像在其他模式下一样。这可能会对您的代码产生影响，例如，您在环境中使用 注册的任何路径都registerCachedFile()必须可由应用程序的 JobManager 访问。
与Per-Job模式相比，Application Mode允许提交由多个作业组成的应用程序。作业执行的顺序不受部署模式的影响，而是受用于启动作业的调用的影响。使用execute()阻塞，建立一个顺序，它将导致“下一个”作业的执行被推迟，直到“这个”作业完成。使用executeAsync()非阻塞，将导致“下一个”作业在“此”作业完成之前开始。
应用程序模式允许多个
execute()应用程序，但在这些情况下不支持高可用性。应用程序模式下的高可用性仅支持单一execute()应用程序。此外，当应用程序模式下多个正在运行的作业（例如使用 提交
executeAsync()）中的任何一个被取消时，所有作业都将停止并且 JobManager 将关闭。支持定期作业完成（通过源关闭）。
每作业模式
Per-Job模式旨在提供更好的资源隔离保证，使用可用的资源提供者框架（例如 YARN、Kubernetes）为每个提交的作业启动一个集群。此集群仅可用于该作业。作业完成后，集群将被拆除并清除所有遗留资源（文件等）。这提供了更好的资源隔离，因为行为不当的作业只能降低其自己的 TaskManager。此外，它将簿记负载分散到多个 JobManager 中，因为每个作业有一个。由于这些原因，Per-Job资源分配模型是许多生产原因的首选模式。
会话模式
会话模式假设一个已经在运行的集群并使用该集群的资源来执行任何提交的应用程序。在同一（会话）集群中执行的应用程序使用并因此竞争相同的资源。这样做的好处是您无需为每个提交的作业支付启动完整集群的资源开销。但是，如果其中一个作业行为不当或关闭了 TaskManager，那么在该 TaskManager 上运行的所有作业都将受到故障的影响。除了对导致失败的作业的负面影响之外，这意味着潜在的大规模恢复过程，所有重新启动的作业同时访问文件系统并使其对其他服务不可用。此外，让单个集群运行多个作业意味着 JobManager 的负载更大，
总结
在会话模式下，集群生命周期独立于集群上运行的任何作业的生命周期，并且资源在所有作业之间共享。在每个作业方式支付旋转起来为每个提交的作业集群的价格，但这种带有更好的隔离保证的资源不能跨岗位共享。在这种情况下，集群的生命周期与作业的生命周期绑定。最后， Application Mode为每个应用程序创建一个会话集群，并main() 在集群上执行应用程序的方法。