FunPlus（趣加）成立于 2010 年，是一家全球性的互动娱乐公司，以精品游戏和艺术风格而闻名，深受欧美等地区用户欢迎。公司在瑞士、中国、西班牙、葡萄牙等多地设有办公室，汇聚来自约 20 个国家和地区的 2,000 名员工，产品的本地化运营支持 20 余种语言，全球累计玩家数量超过 1 亿。FunPlus 以“用优质产品为全球玩家传递极致娱乐体验”为目标，聚焦互动娱乐领域核心赛道，以游戏及泛娱乐产品为核心载体，持续构建全球用户、合作伙伴与多元文化间的深度连接。公司业务涵盖游戏研发、全球发行及电竞生态构建等。在游戏产品矩阵方面，旗下拥有多款覆盖不同细分赛道的标杆级作品，包括《Foundation: Galactic Frontier》《Tiles Survive》《DC：Dark Legion》《State of Survival》《King of Avalon》《Guns of Glory》等热门游戏产品。
玩家登录、游戏内事件和实时运营决策，都依赖后台的数据管道稳定运行。FunPlus 使用 Apache Kafka® 作为两类核心系统的数据底座：
- 游戏可观测性平台：实时处理服务端日志、性能指标和告警，保障全球多区域游戏服务的稳定性
- 实时数据分析平台：支撑玩家行为分析、运营看板和游戏内推荐，为运营团队提供实时决策依据
这些管道每天处理数十亿条消息。任何中断都会直接影响玩家体验。当 Kafka 集群成本开始失控时，FunPlus 基础设施团队必须重新审视底层架构选择。
账单里隐藏的成本
FunPlus 最初在 AWS us-west-2 区域使用 Amazon MSK 运行 Kafka 集群。表面上看，MSK 成本结构很清晰：实例费用和存储费用都按项列出，也在预算范围内。但当基础设施团队做成本审计并深入拆解 AWS 账单时，他们发现了一个意外事实：跨可用区（AZ）数据传输费用在 MSK 云成本中占据了相当大的比例。
这部分成本之所以长期没有被注意到，是因为它并不会出现在 MSK 账单里。AWS 会把跨 AZ 流量费用归类到 “EC2-Other” 或 “Data Transfer” 下，与账号内几十种服务产生的网络费用混在一起。要单独识别 Kafka 贡献了多少成本，几乎不可能。
跨 AZ 流量成本是如何累积起来的？Kafka 的副本复制、生产者写入和消费者读取，都会在不同 AZ 之间传输数据。AWS 对每一次跨 AZ 传输收取 $0.02/GB。FunPlus 的集群每天处理约 70 亿条消息，这三类跨 AZ 流量迅速叠加，最终成为最大单项成本。关于跨 AZ 流量成本的详细拆解和计算方式，可以参考我们之前的文章 拆解 AWS/GCP Kafka 背后的隐性账单。
游戏行业会进一步放大这个问题：高吞吐数据管道、为保障玩家体验而必须采用的多 AZ 部署，以及全球多区域运营，都会成倍放大跨 AZ 成本。团队曾尝试通过 Fetch from Follower 等配置优化来降低消费者侧流量，但生产者写入和副本复制才是跨 AZ 传输的大头，这是 Kafka 存储架构带来的结果，无法通过配置调整彻底解决。更麻烦的是，每一次新游戏上线、每一轮玩家增长，都会让跨 AZ 成本按比例上升。FunPlus 需要一种从架构层面解决问题的新方案。
为什么选择 AutoMQ
在评估替代方案时，FunPlus 有两个不可妥协的要求
- 通过架构升级显著降低 Kafka 成本，且不能带来副作用
- 迁移过程不能影响生产负载，一个每天处理 70 亿条消息的集群没有试错空间
AutoMQ 同时满足这两个条件。在架构侧，AutoMQ 的 Diskless 架构将数据持久化从 Broker 本地的 Elastic Block Store（EBS）迁移到 S3，消除了 Broker 之间的副本复制，从根源上去除跨 AZ 流量成本（详见 AutoMQ 如何实现亚 10ms 延迟的 Diskless Kafka）。存储成本也大幅下降，从 EBS 三副本变成 S3 单副本存储。
在迁移侧，AutoMQ Linking 提供零停机迁移能力，支持字节级复制和 1:1 Offset 一致性。迁移可以按 Topic 分批推进，任何阶段都能无损回滚。对于 FunPlus 这样需要协调多个业务团队的大规模集群来说，这意味着迁移不再是一场全公司级别的动员。
AutoMQ 同时保持 100% Kafka 协议兼容。FunPlus 现有的生产者、消费者、Flink 作业、分析管道和可观测性系统都可以继续运行，不需要修改任何代码。
架构解决成本问题，AutoMQ Linking 解决迁移风险，协议兼容确保上下游零改造。三个条件全部满足后，FunPlus 决定推进迁移。
迁移：比选择技术更难的一步
很多团队都知道 Kafka 成本问题，也知道存在更优的架构。真正阻碍他们的是迁移本身。
生产环境里的 Kafka 集群不是一个孤立组件。它包含数十个甚至上百个 Topic，每个 Topic 都连接着不同业务团队。实时风控、数据湖入湖、玩家行为追踪，每条链路都有不同负责人，也有不同的中断容忍度。迁移意味着要和所有相关方协调：你的 Topic 什么时候切换？切换期间会不会丢消息？消费位点能否保留？Flink checkpoint 会不会失效？
这些问题不是基础设施团队单方面就能回答的。它们需要跨团队协调、逐个 Topic 做影响评估，并准备回滚方案。很多时候，仅仅是梳理“哪些 Topic 可以先迁，哪些绝对不能失败”这件事，就足以让迁移计划被搁置数月。
传统迁移方案让这些顾虑完全合理。MirrorMaker2 是最常见的社区工具，但它有三个硬限制：
- Offset 无法保留：MirrorMaker2 会重新序列化消息，目标集群上的 Offset 与源集群不一致。所有消费位点都会在迁移后失效，Flink checkpoint 作废，历史数据需要重新处理。对于每天处理 70 亿条消息的集群来说，这个代价无法接受
- “停机式”切换：所有客户端必须在同一个维护窗口内切换，需要所有业务团队同时协调停机。对于 7×24 小时运行的游戏服务来说，找到一个所有人都接受的窗口，本身就是一场谈判
- 回滚成本极高：如果切换后出现问题，回到源集群意味着再做一次反向迁移，而且新产生的数据可能丢失
问题并不是团队不想迁移，而是他们不敢迁移。
AutoMQ Linking：把迁移变成日常发布
FunPlus 使用了 AutoMQ Linking，这是 AutoMQ 内置的零停机迁移产品。它不是外部工具，而是 AutoMQ 产品化的一项迁移能力，专门解决前面提到的“迁不动”和“不敢迁”问题。这项能力已经在多家头部企业的生产环境中经过验证，持续获得客户的正向反馈，也显著降低了迁移到 AutoMQ 的门槛。
AutoMQ Linking 的核心设计目标，是解决 Kafka 迁移中业务团队最担心的问题：
| 相关方担忧 | AutoMQ Linking 的回答 | 实现方式 |
|---|---|---|
| “Offset 会不会变？” | 严格 1:1 一致 | 从源集群复制原始字节流，不做重新序列化，Offset 保持一致，不影响现有 Flink、Spark 等依赖 Offset 的任务 |
| “出问题能不能回滚？” | 任意阶段无损回滚 | 智能写转发机制，在过渡期内将写入新集群的数据透明代理回源集群 |
| “会不会重复消费或丢消息？” | 有序交接，保证一致 | 消费者协调逻辑会阻止新消费者在旧消费者断开前拉取数据 |
| “业务会不会感知切换？” | 对业务透明 | 生产者和消费者可逐步滚动切换，真正实现零停机迁移 |
| “必须一次性全部切完吗？” | 可以逐个 Topic 迁移 | 支持 Topic 级和消费者组级粒度 |
| “依赖外部迁移组件吗？” | 不依赖外部组件 | 内置于 AutoMQ，完全托管 |
这六项能力共同降低了迁移风险。Offset 一致意味着 Flink、Spark 和其他依赖 Offset 的任务不受影响；零停机滚动切换意味着业务团队无感；Topic 级粒度让不同团队可以按自己的节奏推进；任意阶段无损回滚意味着不需要孤注一掷。站在业务团队视角，迁移前后的 Kafka 集群看起来完全一致，变化的只是底层基础设施。
分阶段迁移：先小范围验证，再逐步推进
有了 Topic 级粒度，FunPlus 的迁移不再是一场全量切换，也不需要同时协调所有业务团队。团队采用了分阶段策略：
- 先迁移非核心负载：监控和日志 Topic 率先迁移到 AutoMQ，用来验证数据完整性和延迟表现。即使出现问题，影响范围也可控
- 逐步迁移核心链路：第一批负载稳定运行后，实时分析和玩家行为数据管道分批切换，每一批完成后都保留观察期，再继续推进下一批
- 滚动更新客户端：上游生产者和下游消费者通过标准滚动更新切换，不需要集中维护窗口
在整个过渡期内，AutoMQ Linking 提供了关键的安全网：如果某个生产者已经切到新集群并开始写入，而其他组件尚未迁移，这些写入会被自动代理回源集群。这样，新旧集群之间的数据始终保持一致。如果任何阶段出现问题，团队可以立即切回源集群，不丢数据，业务团队甚至不会感知切换发生过。
整场迁移最终以零停机、零应用改造完成。没有“停机式”切换，没有凌晨 3 点维护窗口，也没有十几个团队开会协调切换时间。
回头看，最大的变化并不是技术，而是心理预期。当 Offset 能保证不变、任意阶段都能回滚、迁移可以按 Topic 分批推进时，迁移就从一场全公司级别的动员，变成了团队可以按自己节奏执行的日常发布。
生产结果
FunPlus 的 AutoMQ 集群运行在 AWS us-west-2 区域，支撑其全球游戏产品矩阵中的游戏可观测性平台和实时数据分析平台。
基于 FunPlus 生产数据，60% 以上的成本下降主要来自两个架构因素：
- 消除跨 AZ 数据传输成本：此前最大单项成本现在接近于零，因为不再存在 Broker 之间的副本复制
- 存储模型变化：从 EBS 三副本变成 S3 单副本存储，显著降低存储成本
这不是一次性缩容或预留实例带来的节省，而是结构性的成本优化，并且会随集群规模持续体现。下游系统，包括 Flink 作业、分析管道、可观测性系统以及所有游戏客户端集成，都像之前一样继续运行；从它们的视角看，连接的仍然是一个标准 Kafka 集群。
未来展望
当 Kafka 基础设施成本不再与业务增长强绑定时，FunPlus 可以更有信心地扩展数据管道，支持新游戏上线和玩家规模增长。团队也在探索 AutoMQ stateless brokers 架构带来的进一步优化，例如使用 Spot Instance 降低计算成本。
对于任何在 AWS 或 GCP 上运行中大规模 Kafka 集群的团队，无论是游戏、电商、金融科技还是 SaaS，都值得仔细检查账单中的跨 AZ 流量成本。隐藏在 “EC2-Other” 下的数字，往往比预期更高。
多家头部游戏公司已经在生产环境中大规模部署 AutoMQ。如果你正在评估 Kafka 基础设施成本优化，联系我们，了解更多游戏行业部署实践。