编辑导读：腾讯音乐娱乐集团作为中国在线音乐娱乐服务的领航者，旗下拥有 QQ 音乐、酷狗音乐、酷我音乐和全民 K 歌等众多国民级移动音频应用。每天，这些产品都会产生海量的用户行为和业务数据，为精准推荐、用户增长和商业化等核心业务提供着源源不断的数据驱动力。在这一切背后，一个强大、稳定且高效的 Kafka 流系统是支撑其业务持续创新和发展的关键。 然而，随着业务的飞速发展，传统的自建 Kafka 集群在运维复杂度和成本控制方面逐渐暴露出其局限性。为了应对日益增长的数据洪流和对成本效益的极致追求，腾讯音乐运维团队毅然开启了对下一代 Kafka 解决方案的探索与实践。

最终，他们选择了基于云原生架构的 AutoMQ。通过引入这一创新的解决方案，腾讯音乐不仅成功将成本降低了超过 50% ，更通过其独特的分区秒级迁移能力，极大地提升了集群的扩缩容效率，显著降低了原有 Kafka 的运维复杂度和负担。本次技术升级，是继其在数据仓库领域成功实践存算分离之后，在数据流处理领域的又一次重大突破。

本文将深入解读腾讯音乐娱乐集团是如何利用 AutoMQ 的云原生优势，破解传统 Kafka 的运维难题和成本瓶颈，并最终实现成本与效率双赢的。希望他们在此过程中积累的宝贵经验与最佳实践，能为正在面临相似挑战的您提供有价值的参考和指导！ 作者: 腾讯音乐 高级运维开发工程师 高盛远

背景介绍

腾讯音乐娱乐集团是中国在线音乐娱乐服务开拓者，提供在线音乐和以音乐为核心的社交娱乐两大服务。腾讯音乐娱乐在中国有着广泛的用户基础，拥有目前国内市场知名的移动音频产品：QQ 音乐、酷狗音乐、酷我音乐、全民 K 歌、懒人听书等产品。

技术架构

对于腾讯音乐这样拥有海量用户的平台而言，高效的数据流动、处理与分析是发挥数据价值、支持业务飞速发展的基石。在整个数据体系中，Kafka 作为核心的数据基础设施，扮演着至关重要的角色。它不仅是连接数据生产和消费的管道，更在可观测体系、数据平台等建设中承担着上下游解耦以及配合其他组件简化流程 的关键作用。Kafka 的引入，使得数据源和数据应用可以独立地演进，无需关心对方的实现细节。同时，它支持业务方按需实时消费数据，灵活处理各类旁路处理逻辑，这对于支撑腾讯音乐多元化的业务场景和高速发展至关重要。

下图清晰地展示了腾讯音乐基于 AutoMQ 构建的现代化实时数据流处理架构。整个数据流从数据源采集开始，经过数据接入、Kafka 流系统、实时计算、数据存储，最终服务于上层的各类数据应用，具体流程如下：

• 数据源 （Data Source） ：数据源主要分为两大类。第一类是可观测性数据 ，包括服务运行产生的海量日志、关键指标（Metrics）和 Trace 信息；第二类是分析数据，涵盖了歌曲、艺术家、版权等业务元数据，以及用户的播放、评论等行为数据。
• 数据接入 （Data Ingestion）：为了实现海量数据源数据的统一、高效接入，腾讯音乐内部的"数据通道"平台，作为所有业务方数据接入的统一入口。该平台底层封装了业务埋点、Kafka Producers 等多种上报方式。其核心价值在于，在数据进入 AutoMQ 之前，平台会进行一系列的预处理，包括地域与业务区分、字段过滤、安全鉴权和智能分发。这一流程不仅确保了只有合规、准确的数据才能进入核心系统，也极大地提升了数据接入的效率和治理水平。不同类型的数据通过相应的组件进行采集和上报。例如，应用程序内部通过集成的 SDK 进行埋点追踪，业务服务通过标准的 Kafka 生产者（Kafka Producers）上报数据，而部署在虚拟机上的 Agents 则负责采集各类系统的日志和指标。
• 流系统 （Kafka） ：所有接入的数据统一汇入作为核心数据总线的 AutoMQ 集群。在这里，AutoMQ 承接了来自不同业务线的数据洪峰，为下游的实时计算和数据存储提供高吞吐、低延迟的可靠数据流服务。通过部署多个 AutoMQ 集群（如图中的 Cluster A， B， C），可以实现业务隔离和精细化管理。
• 实时计算 （Computation） ：在数据写入最终存储之前，通常会经过一个可选的实时计算层。腾讯音乐使用 Flink 作为主流的计算引擎，对 Kafka 中的原始数据流进行实时的聚合、过滤和复杂计算。这一步是实现实时监控报警、数据清洗和预处理的关键。例如，Flink 作业会消费 AutoMQ 集群 A 的数据，经过处理后再写回，供其他服务使用。
• 数据存储 （Storage） ：经过实时计算处理后，数据被写入不同的存储系统以满足不同的查询需求。一部分数据会流入 OLAP 数据库 ，用于后续的交互式分析和 BI 报表；另一部分数据，尤其是日志和追踪数据，则会被写入 Elasticsearch，以支持快速的搜索和问题定位。
• 数据应用 （Data Application）：在架构的最上层，是直接面向业务和技术团队的各类数据应用。这些应用大致可分为两类：
• 可观测性应用：基于实时数据流，构建强大的实时监控与告警、智能故障诊断、事件和性能分析，保障业务的稳定运行。
• 数据分析应用：利用处理后的数据，驱动上层业务决策，包括个性化推荐、用户洞察、商业智能（BI）分析和数据科学建模等，实现数据驱动的精细化运营。

Kafka 挑战

随着腾讯音乐旗下 QQ 音乐、酷狗音乐等多款应用的高速发展，数据规模呈指数级增长，作为数据流中枢的 Kafka 集群也面临着日益严峻的挑战。这些挑战主要集中在成本和运维两个方面。

日益严峻的成本压力

在腾讯音乐的业务体量下，Kafka 的成本问题变得尤为突出，主要体现在以下几个方面：

• 资源预留成本高昂 ：由于 Kafka 存算一体的架构限制，集群的计算和存储资源必须同步扩展。为了从容应对业务流量的波峰，生产环境的资源预留水位通常需要保持在 30%～40% 甚至更高。这意味着有大量的服务器资源在大部分时间处于闲置状态，造成了巨大的浪费。
• 存储成本居高不下：为了保证数据的 TTL 时长和高并发下的读写性能，Kafka 的 Broker 节点通常需要配置多块大容量的高性能本地磁盘。昂贵的存储介质和大量的资源预留，共同推高了 Kafka 集群的总体拥有成本（TCO）。
• 多副本机制带来额外开销：Kafka 内置的多副本机制虽然保障了数据的高可靠，但在进行分区数据同步时，会对 Broker 节点的 CPU 产生额外的开销。这不仅增加了资源消耗，也对机型的规格提出了更高的要求，间接导致了硬件成本的上升。

运维成本高

在传统 Kafka 架构下，运维团队面临着巨大挑战，尤其是在集群的弹性伸缩和日常维护方面。

• 扩缩容操作"伤筋动骨" ：随着业务发展，集群扩缩容是家常便饭。然而，Kafka 的扩缩容流程却较为繁琐和漫长。业务方首先需要提交扩容申请并等待审核，业务运维团队会等到业务低峰期才执行操作，以避免影响线上服务。扩缩容过程中最耗时的是 Kafka 的分区数据搬迁，它会产生较大的网络和磁盘 I/O，同时耗费大量时间。并且团队成员还需要投入大量精力，去验证流量是否被正确、均衡地引导至新的 Broker 节点。整个扩缩容流程走完，通常需要 1 天左右的时间，并且依赖人工介入，整个过程是耗时且有风险的。
• 数据热点处理棘手：除了计划内的扩容，当突发的数据热点出现时，运维团队也需要人工介入，通过调整生产端的写入策略来打散流量，以避免单个 Broker 或分区过载。这种手动干预的方式不仅响应不及时，而且操作复杂，给系统的稳定性带来了潜在风险。

这些长期存在的成本与运维难题，给负责 Kafka 运维的团队带来了沉重的负担，也成为了制约数据基础设施进一步发展的瓶颈。因此，寻找一个更具弹性、更低成本、运维更友好的下一代 Kafka 解决方案，被提上了议程。

为什么选择 AutoMQ

在评估下一代 Kafka 解决方案时，我们团队有几个非常明确的目标。经过深入的技术调研和对比，我们认为 AutoMQ 是最能满足我们当前和未来需求的方案。

• 解决运维瓶颈，实现快速弹性：我们面临最大的痛点是传统 Kafka 扩缩容的低效和高风险。AutoMQ 存算分离的架构，将 Broker 变成了无状态节点，数据则存放在对象存储上。这对我们来说，最直接的好处就是分区迁移可以按秒级完成，集群扩容不再需要漫长的数据搬迁，整个过程可以自动化，从过去耗时一两天的人工操作，缩短到了几分钟，极大地提升了我们的运维效率。
• 在保证性能稳定的前提下，实现架构性降本：成本是另一个核心考量。AutoMQ 的架构让我们能够独立扩展计算和存储资源，这意味着我们不再需要为应对流量峰值而预留大量昂贵的计算实例。同时，将数据从本地磁盘转移到成本低得多的对象存储，直接降低了存储开销。这种架构上的改变，是从根本上解决了成本问题，而不是小修小补。
• 真正适配云原生（Kubernetes Native）：我们的基础设施正在全面拥抱 Kubernetes。传统 Kafka 的有状态特性，使其难以充分利用 Kubernetes 在资源调度和故障恢复上的优势。AutoMQ 的无状态 Broker 则能与 Kubernetes 完美协同，像普通应用一样被自由调度，这为我们未来将整个 Kafka 服务迁移至 K8s 铺平了道路，有助于最大化资源利用率。
• 原生支持 Iceberg，简化数据入湖 ：我们未来的数据平台规划之一是构建基于 Apache Iceberg 的流式数据湖。AutoMQ 在这方面的前瞻性设计是一个重要加分项。它提供的 Table Topic 功能可以直接将 Topic 数据流式写入为 Iceberg 表格式，并存入对象存储。这意味着我们未来可以省去一个独立的 Flink 或 Spark 作业来进行数据转换和入湖，从而显著简化数据栈的架构和维护成本。
• 平滑无感的迁移路径：替换核心基础设施，最大的风险在于迁移过程。AutoMQ 提供了 100% 的 Kafka 协议兼容性，这一点至关重要。这意味着我们现有的所有生产者、消费者程序代码都无需任何改动。同时，我们已经构建多年的监控、运维和安全等配套设施也能无缝集成。这为我们提供了一个低风险、低成本的迁移方案，是项目能够成功落地的基本保障。

评估和迁移过程

对于一项如此核心的基础设施升级，一个严谨且分阶段的评估与迁移计划是必不可少的。我们的目标是确保 AutoMQ 在真实的生产负载下，其稳定性、性能和兼容性都达到甚至超过我们的预期。整个过程可以分为两个阶段：负载验证 和生产迁移。

负载验证阶段

我们设计了两种典型的业务场景来对 AutoMQ 进行压力测试，以覆盖我们主要的负载模型：

• 2025 年 6 月 - 大流量场景验证：我们首先上线了一个承载高数据吞吐量、但 QPS（每秒请求数）相对不高的集群。这个测试的目的是验证 AutoMQ 在处理海量数据持续写入和读取场景下的性能和稳定性，特别是在网络 I/O 和对象存储交互方面的表现。
• 2025 年 7 月 - 高 QPS 场景验证：随后，我们部署了第二个集群，用于承载一个高 QPS、但单条消息流量较小的业务。这个场景重点考验的是 AutoMQ 在处理高频元数据请求、客户端连接管理以及小 I/O 聚合能力上的性能极限。

在这两个月的测试中，我们通过构造多组不同的测试负载，对 AutoMQ 进行了全面的评估。结果表明，AutoMQ 在各种压力场景下都展现出了非常好的稳定性，其吞吐量、延迟等关键性能指标完全符合我们生产环境的要求。这给了我们充足的信心，正式启动生产环境的迁移工作。

生产迁移阶段

从 2025 年 8 月开始，我们正式将生产环境的业务流量迁移至 AutoMQ。得益于 AutoMQ 对 Apache Kafka 协议 100% 的兼容性，整个迁移过程异常丝滑，对业务方完全透明，也无需我们进行额外的开发适配。

我们的迁移遵循了以下标准的三步流程，以确保数据的零丢失和服务的不中断：

1. 切换生产者 （Producer）：我们首先修改生产者的客户端配置，将它们的接入点地址指向新的 AutoMQ 集群。这个过程通过滚动更新（rolling update）的方式进行，线上流量被平滑地切换过来，新的数据开始源源不断地写入 AutoMQ。
2. 排空旧集群数据：在生产者完全切换后，旧的 Kafka 集群不再接收新的数据。我们会让消费者继续运行在旧集群上，直到它们消费完所有堆积的历史数据。
3. 切换消费者 （Consumer）：确认旧集群数据已被消费完毕后，我们同样以滚动更新的方式，修改消费者的接入点地址，使其指向新的 AutoMQ 集群。消费者会配置为从新集群中最早的可用位点（Offset）开始消费，从而无缝衔接，保证了数据处理的连续性。

上线情况与效果

经过平滑的迁移，AutoMQ 目前已经在我们内部稳定运行，并承接了核心的生产流量。截至目前，我们总计上线了 6 个 AutoMQ 集群 ，整体峰值写入吞吐量达到 1.6 GiB/s ，峰值 QPS 约为 480K。

为了更直观地展示其运行表现，下图是我们其中一个较大集群的生产集群监控概览：

迁移到 AutoMQ 后，我们获得了非常显著的收益，完美解决了之前在传统 Kafka 上遇到的核心痛点。

• 成本大幅度降低 ：最直接、最显著的收益来自于成本的优化。AutoMQ 存算分离的创新架构，从根本上解决了传统 Kafka 因资源捆绑而导致的成本问题。我们不再需要为应对流量高峰而预留大量的计算资源，同时通过将数据持久化到对象存储，也极大地降低了存储开销。综合计算和存储两方面的节省，腾讯音乐 Kafka 集群成本平均降低超过了 50%。
• 获得"秒级"的极速扩缩容能力 ：过去困扰我们运维团队的扩容难题，在 AutoMQ 上彻底成为了过去式。由于扩容新的 Broker 节点不再需要进行耗时的数据搬迁，整个过程变得异常迅速。凭借 AutoMQ 分区的秒级迁移能力 以及其内置的 Self-Balancing 自动流量均衡机制 ，我们现在可以在数十秒内，平滑地为集群扩展出 1 GiB/s 的吞吐容量。这种极致的弹性伸缩能力，意味着我们可以从容应对任何突发的业务流量增长，为腾讯音乐未来的业务发展提供了坚实而灵活的基础设施保障。

未来展望

回顾这次技术升级之旅，AutoMQ 在腾讯音乐生产环境中的表现令人印象深刻。无论是在高负载下的稳定性、优秀的性能指标，还是在降本增效和简化运维方面取得的实质性成果，都完全符合甚至超出了我们运维团队的预期。这次成功的实践，验证了 AutoMQ 这种云原生架构在 Kafka 流领域的巨大价值。

基于当前的成功经验，我们制定了清晰的未来演进路线图，按优先级逐步推进：

• 全面推进存量迁移 ：我们将加速推进剩余 Kafka 集群的迁移工作。计划将所有服务于全量可观测和多维分析业务的 Kafka 集群全部迁移至 AutoMQ，以最大化地释放成本红利并统一运维体系。
• 落地流式数据入湖 ：在数据架构演进方面，我们将着手落地 AutoMQ 的 Table Topic 功能。充分利用其对 Iceberg 的原生支持，构建更加简洁、高效、实时的流式数据入湖链路，为上层的数据分析业务提供更强有力的支撑。
• AutoMQ 组件标准化与推广 ：我们计划将 AutoMQ 打造成腾讯音乐内部标准化的基础设施组件，并积极将其推广应用到更多样化的业务场景中，让更多的业务线受益于新架构带来的极致弹性和低成本优势。
• 迈向完全的 Kubernetes 云原生 ：最后，依托 AutoMQ 天然无状态的云原生特性，我们将启动将 Kafka 服务整体搬迁至 Kubernetes 的探索与实践。这将有助于我们进一步提升资源管理的自动化水平和整体利用率，推动腾讯音乐的数据基础设施向着完全云原生的方向迈进。