Flink运行架构主要涉及一下三个方面：
1.Flink运行时的组件
2.任务提交流程
3.任务调度流程
1. Flink运行时的组件
整体上分为四大组件：作业管理器、任务管理器、资源管理器、分发器，最重要的是前两个。而ResourceManger主要是负责整个系统的资源调度管理和分配的。另一个Dispacher，意思就是分发器。下面具体介绍这四大组件在运行时的功能
作业管理器（JobManager）
- 控制一个应用程序执行的主进程，也就是说，每个应用程序都会被一个不同的JobManager所控制执行。
- JobManager会先接收到要执行的应用程序，这个应用程序会包括：作业图（JobGraph）、逻辑数据流图（JobGraph）和打包了所有的类、库和其他资源的JAR包。
- JobManager会把JobGraph转换成一个物理层面的数据流图，这个图被叫做“执行图”（ExecutionGraph），包含了所有可以并发执行的任务。
- JobManager会向资源管理器（ResourceManager）请求执行任务必要的资源，也就是任务管理器（TaskManager）上的插槽（slot）。一旦它获取到了足够的资源，就会将执行图分发到真正运行它们的TaskManager上。而运行过程中，JobManager会负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调
资源管理器（ResourceManager）
- 主要负责管理任务管理器（TaskManager）的插槽（slot），TaskManager插槽是Flink中定义的处理资源单元。
- Flink为不同的环境和资源管理工具提供了不同资源管理器，比如YARN、Mesos、K8s，以及standalone部署。
- 当JobManager申请插槽资源时，ResourceManager会将有空闲插槽的TaskManager分配给JobManager。如果ResourceManager没有足够的资源满足JobManager的请求，它还可以向资源提供平台发起会话，以提供启动TaskManager进程的容器。
分发器（Dispacher）
- 可以跨作业运行，它为应用提交提供了REST接口。
- 当一个应用被提交执行时，分发器就会启动并且将应用移交给一个JobManager。
- Dispacher也会启动一个Web UI，用来方便地展示和监控作业执行的信息。
- Dispacher在架构中可能并不是必需的，这取决于应用提交运行的方式。
2.任务提交流程和调度原理
standalone模式下的提交流程
具体来说，就是下面这张图：
- 首先 我们从客户端将整个应用的job通过rest接口提交给了Dispacher
- 然后Dispacher就会把这个应用交给了JobManager管理，并将JobManager进程启动起来。接下来的事情就和Dispacher没有关系了。Dispacher只是接受客户端用户请求，起到一个中间媒介的作用，通过这样一个借口实现跨平台提交任务。
- 接下来，JobManager拿到了这个应用之后，接下来做什么呢，它的操作是向ResourceManager申请资源
- ResourceManager拿到请求后，就会把TaskManager进程启动起来，然后TaskManager就会把空闲的slot在ResourceManager这里进行注册。知道有了这些空闲的slot之后，它就根据JobManager请求的数量，向TaskManager发出哪些slot需要提供的信息，让它提供出来，提供出来时，TaskManager这时就直接和JobManager进行通信了。
- TaskManager向TaskManager提供slots，JobManager就会给TaskManager分配要在slots里面执行的任务了。
- 最后，在执行任务的过程当中，不同的TaskManager之间还会有数据交换，所有的任务都在TaskManager中执行了。
Yarn模式下的提交流程
以上就是我们整个任务提交的一个流程。这是从比较高层次的角度来看的Flink提交流程，具体到我们一些应用的场合，例如Standalone模式，就基本和这个是差不多的。如果要是部署的集群环境不一样，例如yarn或kys，那么提交流程还会有所不同。下面是Yarn提交流程图：
- Yarn模式下，要提交一个任务，首先是客户端会将Flink的jar包和配置上传到HDFS上，上传完后，JobManager和TaskManager就可以共享了。
- 接下来做的事，还是客户端，会向ResourceManager提交Job，然后ResourceManager，就会去分配container资源和通知NodeManager启动一个ApplicationMaster
- ApplicationMaster被启动后，它就要启动JobManager了，启动过程：从HDFS上加载我们之前上传的jar包和配置，对应地把JobManager启动起来。
- JobManager被启动之后，它就会执行我们的作业图，它就知道我们当前所需要的资源，这时再返回来向ResourceManager申请资源。
- Yarn的ResourceManager得到请求之后，继续分配container资源，资源分配好了之后，就通知ApplicationMaster，由它去启动更多的TaskManager。
- TaskManager启起来之后，就会向JobManager发起心跳，接下来就等待JobManager给它分配任务了。
这就是Yarn模式下的任务提交流程。
任务提交后的Flink任务调度原理
下面是Flink任务调度原理
首先，我们可以从上图看到，有一个JobManager和两个TaskManager，我们知道，一般情况下JobManager做管理调度只有一个，而TaskManager干活的人有很多个。所以在任务调度过程中，主要是TaskManager，像Dispacher，ResourceManager这些在任务执行过程当中，就没有什么用了。在上图中，左边还有一处，就是我们写好的代码，红色部分就是要做的编译打包，首先就生成一个初始的流DataFlow Graph，有了这个以后，就通过我们的客户端client，提交给客户端也好、ResourceManager也好，最终都要给JobManager，给JobManager之后，左边部分就没有工作了。除了要取消任务、收到JobManager返回的统计信息等这些还是可以做交互的，任务执行部分就不作参与了。JobManager拿到传来的DataFlow Graph之后，就会把逻辑的数据流图，转换成最后能够执行的Execution Graph执行图。转换之后，就把转换后的它发送给所有的TaskManager，每一个TaskManager里的slot里Task并发执行。这就是执行的过程。执行过程中，JobManager也可以和TaskManager通信，比如JobManager向TaskManager发送执行、停止、取消一个任务、保存当前执行的快照等指令。
以上就是整个任务调度的一个过程，在这里面，还涉及到很多具体的过程，比如TaskManager里的slot到底是怎么处理的、不同的Task是怎么拆分、合并的、前面的逻辑的数据流图转换成最后能够执行的Execution Graph执行图的这个执行图又是怎么样的呢，这里也有一些具体的细节有待我们探讨。
