十亿用户、32万亿条日处理量：LinkedIn为何弃用了Kafka？

起源故事：卡夫卡还是个“金童”的时候

The Origin Story: When Kafka Was the Golden Child

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

时间回到2010年，那时的LinkedIn正面临一个典型的“成长的烦恼”：平台拥有9000万用户（还记得那个年代的体量吗？），海量数据让系统不堪重负。他们急需一种能够实时传输日志和事件的高效方案。于是，Kafka诞生了。

不得不说，它的出现具有革命性意义——速度极快，架构优雅，迅速成为Apache软件基金会旗下的“明星项目”。然而，技术世界的发展速度总是超乎想象。快进到2026年，LinkedIn的用户规模已膨胀至12亿，每天需要处理的记录更是超过了32万亿条。

这就好比，孩子已经长大乘人，但住的房子却还是童年那间。对于LinkedIn而言，他们需要的不仅仅是一间更大的“房子”，而是一套彻头彻尾的全新“地基”与“架构”。

裂缝为何开始显现

Why the Cracks Started Showing

Kafka固然优秀，但在LinkedIn这种“行星级”的业务规模面前，它开始显得有些力不从心，甚至像个性情不定的青少年，时不时闹点脾气。这正是工程师们着手寻找替代方案的核心原因：

元数据噩梦：想象一下，你需要管理150个集群，而每个集群包含多达40万个主题。Kafka依赖的中央“控制器”在这种情况下，就成了一个巨大的性能瓶颈。这无异于让一位经理去管理上万名员工——所有人都等着他签字，结果就是所有工作都陷入停滞。

“暂停世界”式的重新平衡：在Kafka集群中添加一个新的袋里（Broker），其过程堪比搬进新公寓时，必须把整栋楼里所有住户的家具都重新挪动一遍，只为给你新买的椅子腾个地方。这个过程不仅缓慢、痛苦，更伴随着极高的操作风险。

资源倾斜：某些分区（Partition）会变得异常“炙手可热”，而另一些则长期“无人问津”。这种冷热不均直接导致磁盘使用率失衡，让运维工程师们不得不在凌晨三点对着监控面板抓耳挠腮。

Northguard登场：新王者降临

Enter Northguard: The New King in Town

LinkedIn的应对策略并非简单地修补Kafka，而是选择从头构建一个全新的系统——Northguard。这绝非“Kafka 2.0”式的升级，而是一次根本性的架构重塑。下面就来拆解一下它的制胜之道：

1.日志分块（秘诀）

Log Striping (The Secret Sauce) ?

Northguard摒弃了整体式的分区设计，转而将日志数据切割成1GB大小的“块”。这个改动看似微小，效果却堪称神奇——就像用多个轻便的登山包替换一个笨重无比的大行李箱。负载均衡因此变得自动化且丝滑顺畅。

2.去中心化元数据

单点控制的瓶颈在此成为历史。Northguard采用基于Raft共识算法的状态机，将元数据分片后分布式地存储在整个集群中。这种高科技的、彻底去中心化的架构，意味着系统不再存在一个可能引发全局故障的“心脏”。

3.Xinfra：神奇的迁移层

Xinfra: The “Magic” Migration Layer

面对每天32万亿条记录的庞大体量，“一键切换”无异于天方夜谭。为此，LinkedIn专门构建了Xinfra——一个虚拟化的发布/订阅抽象层。你可以把它理解为一个“万能遥控器”，允许应用程序在不修改代码的情况下，同时与后端的Kafka和Northguard进行通信，从而实现了平滑过渡。

Kafka vs Northguard：巅峰对决

图片

卡夫卡对我们其他人来说已经过时了吗？

答案很明确：并没有。

必须认识到，LinkedIn是一个极端案例。对于绝大多数企业而言，午饭前都处理不完PB级的数据。事实上，对于市场上99%的公司来说，Kafka（尤其是Confluent这类提供托管服务的版本）依然是流处理领域毋庸置疑的黄金标准。

这就好比，LinkedIn为了追求时速200英里的极限性能，亲手打造了一辆一级方程式赛车。而你可能只需要一辆性能可靠、空间充裕的SUV来满足日常通勤。除非你的业务也在一夜之间迎来了十亿用户，否则，实在不必因为一篇顶尖公司的工程博客，就急着推翻自己整个技术栈。

常见问题

（1）今天可以下载 Northguard 吗？

目前还不行。Northguard仍是LinkedIn内部专用的系统。尽管团队暗示未来有开源的可能，但就现阶段而言，这无疑是他们的“秘密武器”。

（2）我应该停止学习 Kafka 吗？

绝对不应该。在这个行业里，Kafka是赖以生存的“面包和黄油”，而Northguard更像是顶级的“鱼子酱”。要想吃饱，你首先得拥有面包。

（3）迁移有多难？

借助Xinfra这样的中间层，LinkedIn让整个迁移过程在表面上看起来轻而易举（他们已有90%的应用基于Xinfra运行！）。然而，对于外部团队而言，光是理解和运维现有的数据流水线就已经足够复杂。所以，或许还是先从掌握好基础知识开始更为稳妥。

结语

LinkedIn用Northguard替代Kafka，无疑是现代工程史上一个值得铭记的里程碑。它清晰地揭示了一个道理：即便是最成功、最革命性的工具，当被推向其设计极限时，也必然会暴露出固有的局限性。

那么，Northguard会不会在三年后，成为下一个我们必须掌握的大型开源项目呢？历史或许会给出肯定的答案。但在那一天到来之前，我们不妨先驻足欣赏一下这种令人惊叹的工程“魄力”：仅仅因为速度不再满足需求，便毅然替换掉自己曾经亲手改变世界的发明。

作者丨Cloud With AzeemC 编译丨dbaplus社群

来源丨网址：https://cloudwithazeem.medium.com/linkedin-kafka-replacement-new-streaming-system-76e56073eb97