你有没有遇到过这种情况：本地开发环境里跑得好好的Flink任务，一拿到测试环境就各种幺蛾子，要么类冲突，要么提交后TaskManager一直连不上，要么作业运行几分钟就内存溢出。折腾一圈下来，发现大多数问题都不是业务逻辑造成的，而是提交作业的方式和集群环境配置没吃透。
这篇内容我来完整梳理一遍Flink StandAlone模式下提交作业的全流程，从集群启动、作业打包，到三种主流提交方式（Web UI、命令行、SQL Gateway）的实操细节，再到资源规划和问题排查。无论你是刚接触Flink的菜鸟，还是被StandAlone模式折腾过几次的开发者，这篇文章都值得收藏起来当操作手册用。
1. StandAlone模式是什么，为什么还在用它
1.1 StandAlone模式的核心架构和适用场景
Flink集群最基础的部署形态就是StandAlone，也就是独立集群模式。它不依赖YARN、Kubernetes这些外部资源调度系统，自己启动一套独立的进程组来运行作业。架构上分为两个核心角色：JobManager负责调度、检查点协调、作业管理；TaskManager负责任务的实际执行，内部通过Slot来隔离资源。
这套架构说白了就是主从模式，JobManager是大脑，TaskManager是干活的工人。从运维角度看，它比云原生环境更直观，所有组件都是进程可见的，日志也都在本地文件系统上，排查问题的时候不用绕弯子。
适用场景也比较明确：中小型团队做开发测试、数据量不大的生产环境、以及你需要完全掌控Flink运行参数而不想被底层调度器干扰的场景。虽然现在很多公司把Flink跑在K8s上，但StandAlone模式依然是学习Flink原理、调试复杂作业时的最佳环境。
1.2 StandAlone和Per-Job、Application模式的区别
这里很多人容易混淆。StandAlone描述的是集群部署形态，而Per-Job、Application描述的是作业提交方式。你可以在StandAlone集群上以Per-Job方式提交作业，也可以直接以Application模式把作业入口类丢给JobManager运行。
具体来说，Per-Job模式会为每个作业单独申请资源，作业结束资源即释放；Application模式则把main方法放在集群端执行，适合需要动态加载的作业。而StandAlone Plus的是，你可以自由选择用哪种方式提交，灵活性比在YARN上受限于队列配置要高很多。
从使用体验来讲，StandAlone最爽的一点是调试方便。代码改动后直接打包、上传、提交，几十秒内就能看到结果，不用等资源调度器分配容器的流程。对于频繁迭代的实时任务来说，这种响应速度非常关键。
2. 启动StandAlone集群，这些环境准备必须做对
2.1 环境依赖与安装细节
在启动集群之前，先把基础环境搞定。JDK版本建议1.8或11，Flink 1.13以后对JDK 11支持已经比较成熟，但如果你用的是老版本Flink，老老实实装JDK 8最稳妥。需要注意的是，这种部署方式不需要额外安装Hadoop，除非你要读写HDFS，那就得把HADOOP_CLASSPATH配好。
Flink安装包直接去官网下载对应版本的tgz文件，解压到一个没有中文、没有空格的路径下。我第一次部署的时候把它放在/opt/flink目录，权限记得给当前用户，不然启动脚本会因为写不了日志目录而报错。解压后重点确认两个目录：bin目录下是启动脚本，conf目录下是配置文件。
有一点容易被忽略：Flink默认配置只分配了1G的JobManager堆内存和1G的TaskManager堆内存，这个配置在本地环境跑小作业没问题，但放到稍大一点的数据集上就会频繁Full GC。建议在启动集群前就根据机器内存调整好，别等出了问题再重启。
2.2 JobManager和TaskManager的启动与配置
集群配置的核心文件是conf/flink-conf.yaml。我挑几个关键参数说明一下：
jobmanager.memory.process.size: 4096m taskmanager.memory.process.size: 8192m taskmanager.numberOfTaskSlots: 4 parallelism.default: 1 rest.address: 0.0.0.0 rest.port: 8081jobmanager.memory.process.size指的是整个进程的物理内存，包含堆外和元空间，别只把它当成堆内存看。taskmanager.memory.process.size同理。numberOfTaskSlots决定了每个TaskManager能并发跑多少个任务，一般设置为机器CPU核数或者核数减一。
启动命令很简单，在bin目录下执行：
./start-cluster.sh这条命令会同时拉起JobManager和TaskManager。如果只启动了JobManager而TaskManager没起来，多半是内存配置超出了机器可用内存，或者端口被占用了。你可以分别执行jps命令验证进程是否存在。
2.3 验证集群是否正常
启动完成后，打开浏览器访问http://localhost:8081，看到Flink Web UI页面就说明JobManager已经正常工作了。页面右上角会显示Available Task Slots的数量，如果和你在配置里设置的一致，说明TaskManager注册成功。
还有一种更直接的验证方式，就是向集群提交一个最简单的作业。Flink安装包自带了一些示例作业，在examples目录下，比如batch的WordCount。执行下面的命令：
./bin/flink run ./examples/batch/WordCount.jar --input /tmp/input.txt --output /tmp/output.txt如果作业能正常跑完并在输出目录生成结果，你的StandAlone集群就完全可用了。这个步骤虽然简单，但能排除一大半配置问题。
我在实际操作中发现一个小细节：启动集群前最好检查一下conf目录下的masters和workers文件。这两个文件在Flink 1.11版本以后被移除了，集群节点发现逻辑改成了通过ZooKeeper或Kubernetes，但配置文件中如果残留了过时配置，启动时会报一堆奇怪的警告。
3. 作业打包：提交前最容易翻车的环节
3.1 Maven工程配置与依赖作用域
代码写完，JobGraph的构建过程正确，接下来就是打包。这里面的坑比想象中多。Flink作业最后打成的JAR包不是随便打个fat-jar就行，依赖处理方式直接决定作业能不能在集群上正常跑起来。
标准的做法是用Maven的shade插件来打包。核心思路是：Flink框架本身的依赖（比如flink-core、flink-streaming-java）不需要打进JAR包里，因为StandAlone集群的Flink安装目录下已经有这些类了。而你业务里用到的第三方依赖，比如连接器、JSON解析库，就需要打包进去。
在pom.xml里，Flink依赖的scope设置成provided，表示编译时需要但不参与打包。其他第三方依赖不设置scope，会默认被打进JAR包。这是我们工程化Flink代码时的一个基础约束，如果全部打成fat-jar，提交作业时可能和集群自带的类冲突。
3.2 打包策略选择：shade插件、assembly插件、分开打
我试过三种打包方案，逐一说明优劣：
第一种是用Maven Shade插件，这是Flink官方推荐的方案。它支持重写类的路径，可以很大程度上避免和集群环境的类冲突。我这里给出一个可用的配置：
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.2.4</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <artifactSet> <excludes> <exclude>org.apache.flink:flink-core</exclude> <exclude>org.apache.flink:flink-streaming-java</exclude> </excludes> </artifactSet> <filters> <filter> <artifact>*:*</artifact> <excludes> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> </configuration> </execution> </executions> </plugin>第二种是Maven Assembly插件，它能打出一个包含所有依赖的大JAR包，但无法重写类路径，遇到冲突时很难处理。我只建议在没有依赖包冲突风险的小项目里用。
第三种是先把公共依赖放到Flink的lib目录下，业务代码单独打包。这种方式的维护成本很高，而且Flink lib目录下的依赖会被所有作业共享，一旦有版本不一致的情况，会把整个集群搞挂。我自己踩过这个坑，后来再也不用了。
3.3 打包后自检，避免交作业前才发现问题
打好包之后，先别急着上传。我一般会做三个自检动作：
先查看JAR包大小。如果只有几十KB，大概率依赖没打进去；如果几百MB，可能把Flink框架打进去了，需要检查exclude配置。
内容验证命令：
jar tf your-job.jar | grep -i "flink-streaming"如果这个命令还能搜出一堆flink相关类，说明provided配置失效了，重新检查pom文件。还要检查META-INF目录下有没有.SF签名文件，这些文件会在运行时导致SecurityException。
再确认一下主类路径是否正确。打开META-INF/MANIFEST.MF文件，里面Main-Class指向的类路径存在且里面有main方法。当然，用命令行提交时不强制要求设置主类，因为可以通过参数指定，但Web UI上传时就会用到这个信息。
4. 三种提交作业的方式，从底层到上层一次讲透
4.1 方式一：Web UI上传JAR提交
Web UI提交是最适合入门的方式。浏览器打开8081端口，点击左侧Submit New Job，上传JAR包后，界面会解析出可执行的主类列表。
这个方式有个比较烦人的坑：上传的JAR包会被缓存到JobManager的目录下，如果网络不好或者JAR包很大，上传过程会超时。另外由于Web UI提交时，入口类会被JobManager的类加载器加载，如果JAR包里有和集群lib目录下重复的类，有可能出现ClassCastException。
我个人的经验是，Web UI适合做快速验证，比如测试一个新写的SQL作业或者Demo程序。但是如果是生产作业，我更推荐用命令行提交，它更可控，也更容易集成到发布系统里。
4.2 方式二：命令行flink run提交，最常用的生产级方式
命令行提交是Flink最经典、也是生产环境最常用的提交方式。基础命令是：
./bin/flink run -m jobmanager-host:8081 -c com.example.YourMainClass your-job.jar \ --input /data/input.txt --output /data/output.txt这里面的参数一个个说清楚：
-m参数指定JobManager的地址和端口，默认是localhost:8081，如果集群在远程服务器上，这个参数必须显式指定。注意这个端口不是RPC端口，而是REST端口。
-c参数指定入口类全类名。如果你的JAR包设置了Main-Class，这个参数可以省略，但建议还是写上，避免以后重构时改包名导致作业提交失败。
后面的--input、--output是作业自定义的参数，会被传到main方法的args里。注意Flink的命令行解析机制有个小陷阱：如果作业参数里还有嵌套的--key=value格式，需要放在一个单独的--后面，否则会被Flink自身的参数解析器截胡。
还可以用-d参数让作业脱离终端后台运行。不加这个参数，终端关闭时作业可能会被一起带走。我在第一次部署时就没加-d，结果SSH断开后作业直接消失了。这个参数在1.11版本之后变成了默认行为，但老版本必须要加。
提交后系统会打印类似“Job has been submitted with JobID xxx”的信息，这个JobID就是后续排查日志、取消作业的凭证，一定要记下来。
4.3 方式三：SQL Client与SQL Gateway
如果你用的是Flink SQL开发作业，提交方式又不一样。较新版本（1.16以上）里，SQL Client逐渐被SQL Gateway取代，但底层逻辑是相同的：你把SQL文件交给客户端工具，它帮你解析、生成作业图并提交到集群。
先启动SQL客户端：
./bin/sql-client.sh embedded -Dexecution.target=remote \ -Dexecution.remote.host=jobmanager-host \ -Dexecution.remote.port=8081连上之后，执行SQL文件：
SET execution.checkpointing.interval = 60s; CREATE TABLE source_table (...) WITH ('connector' = 'kafka', ...); CREATE TABLE sink_table (...) WITH ('connector' = 'print'); INSERT INTO sink_table SELECT * FROM source_table;执行完INSERT语句后，作业就自动提交到StandAlone集群了。SQL Gateway的好处是可以把SQL脚本编排成文件，实现更规范的SQL上线流程。但SQL方式对依赖管理的要求更高，比如你用了JDBC连接器，就得保证连接器的JAR包在Flink lib目录下，因为SQL客户端的类加载机制不会从你自定义的JAR包里加载连接器。
这里还牵扯到一个高频问题：flink的jdbc连接器异常。大多数情况下都是因为Flink版本和连接器版本不匹配。Flink 1.14以前连接器版本是跟着主版本走的，之后变成了独立版本。遇到ClassNotFoundException时，第一反应就应该是去Flink官网查对应版本的连接器JAR包，别急着怀疑代码逻辑。
4.4 提交参数的内存调整细节
作业提交时的内存参数可以覆盖集群默认配置，但我不建议在提交参数里把内存调得和集群配置差距太大。主要的内存参数有：
./bin/flink run -m jobmanager-host:8081 \ -m 2048m \ -tm 4096m \ -t 4 \ -c com.example.YourMainClass your-job.jar-m和-tm参数分别控制JobManager和TaskManager的分配内存。注意这里-m参数可能产生歧义，如果前面用了-m指定JobManager地址，再写一个-m就会冲突。所以如果要用内存参数，地址参数推荐用环境变量或配置文件指定，或者用--jobmanager替代。
-t参数是设置作业的并行度。这个并行度的优先级最高，会覆盖配置文件里的parallelism.default和代码里的setParallelism值。所以如果你在提交时明确指定了-t，代码里的并行度设置就不会生效了，这一点一定要团队达成共识，不然并行度调优时很容易踩坑。
5. 规划资源与并行度，让作业稳定跑起来
5.1 并行度、Slot和TaskManager的关系
很多初学者对这三个概念一头雾水。用大白话解释：TaskManager是机器上运行的一个JVM进程，Slot是JVM进程里的一个执行槽位，并行度是一个算子实际开启的并发线程数。TaskManager的Slot数量在flink-conf.yaml里通过taskmanager.numberOfTaskSlots配置。
举个实际例子：假设集群有两台机器，每台机器配置4个Slot，那么集群总共有8个Slot。如果你的作业并行度设置为8，而且是从Source开始的全局并行，那么8个任务会被分配到8个不同的Slot上。如果并行度设置为10，超过总Slot数，作业会一直处于等待状态，如果Slot数超过并行度，多余的Slot就闲着。
这里有个性能陷阱：同一个Slot里的任务会共享JVM资源，包括内存和CPU。如果一个TaskManager被分配了8个任务，而这些任务所在算子的负载很高，会互相挤占资源，容易出性能瓶颈。
5.2 内存配置的参考算法
任务内存计算有个最简单的公式：
taskmanager.memory.process.size = taskmanager.memory.framework.off-heap.size + taskmanager.memory.task.off-heap.size + taskmanager.memory.managed.size + taskmanager.memory.jvm-overhead.size + 堆内存堆内存主要被用户代码、状态后端用掉；managed内存被RocksDB、排序、窗口等操作使用，默认是进程总内存的40%左右。如果没有开启RocksDB，managed内存可以适当调小，把空间留给堆内存。
我在实践中推荐的基线是：数据量在百万级别、窗口大小为1分钟的作业，TaskManager进程内存给4-8G，Slot数设置4个，每个Slot的堆内存大约在700M到1G之间。如果作业状态很大，优先加大堆内存，同时增加检查点的间隔时间。
5.3 通过Web UI观察执行计划与资源使用
作业提交后，在Web UI上点进对应Job页面，可以看到Execution Graph，里面是每个算子的并行度和数据流方向。这个图直观展示了每个算子分配了几个任务、数据shuffle的方式是forward还是hash。如果发现某个算子的并行度明显异常，可以在这里一眼定位。
再看Backpressure（背压）指标，如果某个算子一直处于HIGH状态，说明它的下游处理速度跟不上。结合资源配置的视角来看，这往往不是代码问题，而是并行度或者内存分配不合理。
还有一种常见情况是数据倾斜：Execution Graph里某个子任务处理的数据量是其他子任务的几十倍。这时候要调整的是key的分布策略，或者加一层随机前缀，而不是盲目增加并行度。这个判断在Web UI上可以很直观地看出来。
6. 常见问题排查与避坑实录
6.1 ClassNotFoundException和NoClassDefFoundError
这是StandAlone模式下最经典的错误。两者表现有细微差别：ClassNotFoundException通常发生在类加载阶段，往往是因为依赖根本没有打包进去；NoClassDefFoundError发生在类已加载但某个引用类缺失时，可能是版本冲突。
排查思路就一句话：先看报错涉及的类来自哪个JAR，然后确认这个JAR在不在TaskManager的classpath里。如果不在，把它打进作业JAR包，或者放到Flink lib目录。如果两个地方都有了，再检查版本是否冲突。
我积累的一个独家技巧：在pom里引入Flink依赖时，尽量使用和集群Flink版本完全一致的版本号。版本较大的不一致会导致隐性的兼容性问题，例如Flink 1.14的作业提交到1.17的集群，虽然很多时候能跑起来，但某些API行为已经变了，运行时的错误又特别难以复现。
6.2 内存溢出与调整思路
OOM大类分为堆内存溢出和堆外内存溢出。堆内存溢出时会看到OutOfMemoryError: Java heap space，这时调整堆内存是最直接的解法，但也得看看是不是代码里缓存了过多数据。堆外内存溢出则会报Direct buffer memory或者其他native内存异常，多半是框架本身的堆外开销超过了预算。
大多数情况下，我是按这个顺序来排查的：先看是不是数据量超过了预期，增加并行度；再看代码里map、flatMap算子内是否存储了不会释放的集合；最后才调整内存配置。因为调内存只是把问题往后推迟，代码层面的优化才是根治方案。
另外要注意，StandAlone模式下TaskManager的JVM启动参数是封装的，你不太容易直接加JVM参数。所以更灵活的方式是用环境变量或者flink-conf.yaml里的控制参数来调整。
6.3 作业提交超时或TaskManager连接不上
提交作业时报Connection refused或者TaskManager not connect，大概率是网络和端口问题。StandAlone集群里，TaskManager需要向JobManager注册，默认走的是blob服务端口和RPC端口，这两个端口可能和Web UI端口不同，默认配置下都是随机分配的。
解决方法是固定这些端口，在flink-conf.yaml里设置：
taskmanager.rpc.port: 6122 blob.server.port: 6124然后确保防火墙放行这些端口。另外一个很隐蔽的问题是，如果机器的hostname解析异常，TaskManager启动时会不断重试注册，日志里看到的就是一堆超时重试。这种情况可以在/etc/hosts里配置好IP和主机名的映射。
6.4 日志查询三板斧
排查问题最有效的方式永远是日志。先用作业提交时返回的JobID找到对应TaskManager日志文件。Flink的日志默认放在安装目录下的log文件夹，命名格式是flink-{用户}-taskexecutor-{序号}-{主机名}.log。
第一条原始日志里如果出现Exception或ERROR，定位起来很快。怕的是任务一直处于RUNNING状态但数据没有产出，这时候就要看业务代码里有没有自定义的日志输出，可以临时加一些关键节点的日志，重新打包提交。
第三板斧是要习惯使用Web UI的TaskManager和JobManager页面。上面的Metrics信息非常全，包括堆内存使用率、GC时间、网络缓冲区等。很多问题在日志里看不到，但在度量指标里会有明显异常，比如网络流量为0但CPU使用率很高，大概率是算子卡在某个死循环了。
写在最后的一个经验
回头再看整个StandAlone模式提交Flink作业的流程，其实每一步都环环相扣：环境配置影响集群稳定性，打包方式影响作业能否正常启动，提交方式影响运维方式的便利性，而资源规划直接决定性能上限。如果你是刚入门，我建议老老实实先把命令行提交方式摸透，再用Web UI辅助验证，最后再碰SQL提交。
最后再分享一个小建议：Flink作业一旦上了生产，尽量保持版本统一，不要随手上线新版本Flink的作业到旧集群里。这个习惯能帮你避开我早期反复踩过的无数坑。
