Flink部署怎么选，自建还是托管？

让我最头痛的框架

先看看我们团队内部遇到的一大堆问题：

上个月某天凌晨三点，我被手机震醒。迷迷糊糊看了一眼，是生产环境的 Flink 任务挂了。哈哈，这已经是第6次了。

主要是问题出现前，你都没法优化他，只能等他哪天在生产环境冒出来，气笑了。

爬起来打开电脑，看着 Kafka 的消费延迟已经堆到了 5 万条，整个人都不好了。那天晚上我花了两个小时排查，发现是 TaskManager 内存不够，频繁 Full GC。问题是，这个集群我三个月前刚上线的，当时还觉得配置挺合理的。

第二天早上开会，老板问：“能不能用托管服务？AWS 不是有 Managed Flink 吗？“我算了一下账单，一个月要多花 3 万。emmm，这钱还不如拿来招个 SRE。

Flink 部署，到底该怎么选？

前几天我在星巴克跟以前的同事聊这个。他们公司用的是 Confluent Cloud，我问体验怎么样。他说：“钱到位了，啥问题都没有。就是每次看账单心里发虚。”

我们公司用的是自建的 Kubernetes 集群。说实话，刚开始搭的时候特别痛苦，各种配置、各种踩坑。但现在稳定下来了，成本比托管服务低多了。

我的建议是，先算账，再选型。

你得考虑这几个问题：

• 你的团队有没有人懂 Flink 运维？如果没有，托管服务可能更靠谱。
• 你的数据量有多大？如果每天就几百 GB，Standalone 就够了。要是上 TB，那得考虑 Kubernetes 或 YARN。
• 你对成本敏感吗？托管服务确实省心，但账单也真的贵。

我之前见过最极端的案例：有个创业公司，三个人的技术团队，上来就自建了一套 Kubernetes + Flink 集群。结果花了两个月时间调试，产品功能都没做。后来他们换成托管服务，一周就上线了。

别用老教程了，版本更新太快

这是我踩过的另一个大坑。我刚开始学 Flink 的时候，找了一堆教程，结果全是 Flink 1.14、1.15 的。照着配置文件抄，跑起来各种报错。

Flink 1.18/1.19 变化太大了。以前手动调 taskmanager.numberOfTaskSlots，现在有自动资源感知了。以前 Checkpoint 配置一堆参数，现在有默认的网络堆积阈值了。

我的建议是：别省那几行 YAML，该写的配置都写清楚。

之前有一次，我把 RocksDB 的内存配置从默认改成了自定义的 state.backend.rocksdb.memory.write-buffer-ratio，延迟直接降了 30%。这种小优化，老教程里根本不会提。

Kubernetes Operator 真香

去年我们刚开始用 Flink 的时候，部署全靠手撸 shell 脚本。每次发版都要 SSH 到服务器上，手动重启任务，做 Savepoint。emmm，那段时间真的是噩梦。

后来我试了 Flink Kubernetes Operator，整个世界都变了。Savepoint 自动化、Job 重启策略、高可用配置，全都可以在 YAML 里搞定。CI/CD 只要跑一遍 kubectl apply，剩下的 Operator 帮你搞定。

有没有遇到过这种情况？生产环境出问题了，你想回滚到上一个版本，结果发现 Savepoint 没做或者找不到了。用了 Operator 之后，这种事再也没发生过。

YARN？其实也还行

很多人觉得 YARN 过时了，应该全面拥抱 Kubernetes。但说实话，如果你的公司已经有一套成熟的 Hadoop 集群，YARN 还是挺香的。

我之前在一家传统企业待过，他们有几百台机器的 YARN 集群。刚开始我也想推 Kubernetes，但后来算了一下迁移成本，老板直接摇头。

关键是要把 YARN 用好。比如：

• 给 Flink 任务单独划一个队列，别跟 Spark 抢资源
• 配置好 Node Label，让流处理任务跑在固定的机器上
• Checkpoint 频率要和 YARN 的资源调度配合好

我见过最惨的案例：有个团队把 Flink 和 Spark 混在一起跑，结果 Spark 一扫全表，Flink 的 JobManager 就开始抖动。后来他们给 Flink 单独划了队列，问题就没了。

托管服务不是万能的

去年我们评估过 AWS Managed Flink。确实省心，不用管机器、不用管升级。但你以为用了托管服务就能高枕无忧了？

该盯的指标还是得盯。Kafka 的消费延迟、Kinesis 的背压、任务的 Checkpoint 时长，这些都要监控。我见过有人用了托管服务之后就不管了，结果延迟越来越高，直到业务方投诉才发现。

还有成本问题。托管服务是按小时计费的，如果你不小心把 parallelism 设得太高，或者开了一堆测试任务忘记关，月底账单能把你吓一跳。我之前就因为这个被老板叫去谈话，哈哈。

我现在怎么做？

那次凌晨告警之后，我花了一个月时间重新梳理了整个部署方案。

现在我们的架构是这样的：

• 用 Kubernetes + Flink Operator 做主集群，处理核心业务的流处理任务
• 测试环境用 Standalone 模式，轻量快速
• 监控用 Prometheus + Grafana，每个任务都有详细的指标
• 成本控制方面，每个月都会出一份报表，看看哪些任务资源用得多，能不能优化

最重要的是，我把所有配置都文档化了。新人来了，看看文档就能上手。不像以前，全靠老员工口口相传。

说实话，Flink 部署没那么可怕。关键是要根据自己的情况选方案，别盲目跟风。有的公司适合 Kubernetes，有的适合 YARN，有的干脆用托管服务就行。重要的是，选完之后要持续优化，盯好监控，控制成本。