session cluster和per job 因为是源码分析，所以会分为服务端和客户端两个部分的代码分析，下面我先看服务端<br/>
session cluster模式是类似standalone，先去向yarn申请好资源，然后供业务方提交，主要的入口类是YarnSessionClusterEntrypoint(这里指的是服务端的入口)
从上图可以看出来，startCluster()方法前后是两个分界线,startCluster之前是获取配置，之后是进行集群相关的创建，包括haService/blobServer/heartBeatService/resourceManger/webMonitorEndpoint。<br/>
这里有一点是需要说明的是有关executionGraphStore， 这里实际有两种，
1.将可执行图放在内存中，
2.将可执行图持久化到文件。<br/>
yarn session：将executionGraph持久化到文件<br/>
per job：将executionGraph持久化到文件<br/>
对于per job模式是每个任务对应一个集群，其实就是将上图中的YarnSessionClusterEntrypoint改成YarnJobClusterEntrypoint，其它流程基本一致（除去executionGrap的存储）。<br/>
下面来看一下两个主类的继承关系图<br/>
<br/>
从图上可以看到主要的区别就是createSerializeableExecutionGraphStore方法，也就是executionGraph的存储位置不同。<br/>
session client和per job 由于flink不同的版本代码变动较大，所以在这里需要区分flink的版本进行一下说明 flink1.9之前的基本一致，提交至yarn的主要流程都在CliFrontend和FlinkYarnSessionCli中， 我们来看一下主要流程<br/>
<br/>
这里session和per job的在流程上的最大区别就是clusterId是否为空 flink1.9之后进行了流程统一,抽象出了一个PipelineExecutor接口，统筹所有的提交，不过在看继承关系之前还是先看一下yarn-client的提交流程其实主要入口还是CLiFrontened，不过在加载完配置文件之后就直接反射调用invokeInteractiveModeForExecution，这个类会调用用户的main函数，加载完用户业务代码之后，会去走正常的提交流程。 到这里已经将所有的提交流程都说完了，大家对于flink争个提交流程应该有了更加清晰的认识。<br/>
最后在来说一下flink submit的接口,这是在flink-1.10才出现的一个新的统一，流程图如下<br/>
<br/>
从上图可以看出来，AbstractSessionClusterExecutor中的主要调用逻辑其实和上面我们已经看到的session cluster的提交流程是一致的，只不过代码更加的抽象，这样其实扩展性也更加好，AbstractJobClusterExecutor主要主要就是为了向已有集群提交任务的，LocalExecutor其实是为了用户本地调试所用
