腾讯音乐娱乐集团作为中国在线音乐娱乐服务的领航者，旗下拥有众多国民级移动音频应用。每天，这些产品都会产生海量的用户行为和业务数据，为精准推荐、用户增长和商业化等核心业务提供着源源不断的数据驱动力。在这一切背后，一个强大、稳定且高效的 Kafka 流系统是支撑其业务持续创新和发展的关键。
然而，随着业务的飞速发展，传统的自建 Kafka 集群在运维复杂度和成本控制方面逐渐暴露出其局限性。为了应对日益增长的数据洪流和对成本效益的极致追求，腾讯音乐运维团队毅然开启了对下一代 Kafka 解决方案的探索与实践。
最终，他们选择了基于云原生架构的 AutoMQ。通过引入这一创新的解决方案，腾讯音乐不仅成功将成本降低了超过 50%，更通过其独特的分区秒级迁移能力，极大地提升了集群的扩缩容效率，显著降低了原有 Kafka 的运维复杂度和负担。本次技术升级，是继其在数据仓库领域成功实践存算分离之后，在数据流处理领域的又一次重大突破。
背景介绍
腾讯音乐娱乐集团是中国在线音乐娱乐服务开拓者，提供在线音乐和以音乐为核心的社交娱乐两大服务。腾讯音乐娱乐在中国有着广泛的用户基础。
技术架构
对于腾讯音乐这样拥有海量用户的平台而言，高效的数据流动、处理与分析是发挥数据价值、支持业务飞速发展的基石。在整个数据体系中，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% 的兼容性，整个迁移过程异常丝滑，对业务方完全透明，也无需我们进行额外的开发适配 。
我们的迁移遵循了以下标准的三步流程，以确保数据的零丢失和服务的不中断：切换生产者 （Producer）：
我们首先修改生产者的客户端配置，将它们的接入点地址指向新的 AutoMQ 集群。这个过程通过滚动更新（rolling update）的方式进行，线上流量被平滑地切换过来，新的数据开始源源不断地写入 AutoMQ。
排空旧集群数据
在生产者完全切换后，旧的 Kafka 集群不再接收新的数据。我们会让消费者继续运行在旧集群上，直到它们消费完所有堆积的历史数据。
切换消费者 （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 的探索与实践。这将有助于我们进一步提升资源管理的自动化水平和整体利用率，推动腾讯音乐的数据基础设施向着完全云原生的方向迈进。