大家好，我是Hank，一名專注于計(jì)算機(jī)技術(shù)和軟件架構(gòu)的工程師。最近，我讀到一篇關(guān)于Netflix的文章，標(biāo)題是“Why Netflix Removed Kafka from Tudum’s Architecture ? — And What We Can All Learn From It”，作者是Pudari Madhavi。這篇文章讓我感觸頗深，因?yàn)镹etflix作為流媒體巨頭，竟然選擇放棄像Kafka這樣熱門的技術(shù)，這讓我忍不住想深入剖析一下。

背景故事：Tudum是什么？

在跳入技術(shù)細(xì)節(jié)之前，我們先來了解一下背景吧。就像原文說的，如果你是個(gè)Netflix的粉絲，肯定聽過節(jié)目開頭那個(gè)標(biāo)志性的“ta-dum”聲音。這個(gè)聲音啟發(fā)了Netflix推出一個(gè)名為Tudum的公共網(wǎng)站，它本質(zhì)上是一個(gè)內(nèi)容中心，專門為粉絲提供幕后故事、訪談、預(yù)告片、角色深度剖析之類的玩意兒。說白了，它不是像Netflix.com那樣的視頻播放平臺(tái)，而是一個(gè)高度動(dòng)態(tài)、快速更新的內(nèi)容站點(diǎn)，由多個(gè)微服務(wù)支撐。

在我的經(jīng)驗(yàn)中，這種內(nèi)容站點(diǎn)通常需要從內(nèi)部系統(tǒng)拉取數(shù)據(jù)，比如生產(chǎn)目錄、元數(shù)據(jù)服務(wù)、本地化管道、內(nèi)容管理系統(tǒng)（CMS）等等。Tudum早期團(tuán)隊(duì)選擇了Apache Kafka作為事件驅(qū)動(dòng)架構(gòu)的核心，這在初期運(yùn)行得挺順利。但隨著系統(tǒng)成熟和擴(kuò)展，一些問題開始顯現(xiàn)，最終Netflix做出了驚人的決定：完全從Tudum的后端移除Kafka。這讓我想到，我自己在項(xiàng)目中也遇到過類似情況——一開始選了個(gè)牛逼的技術(shù)，結(jié)果后來發(fā)現(xiàn)它成了負(fù)擔(dān)。

Kafka是什么？簡單回顧一下

為了讓大家跟上節(jié)奏，先快速復(fù)習(xí)一下Kafka。Apache Kafka是一個(gè)分布式事件流平臺(tái)，它允許應(yīng)用通過實(shí)時(shí)發(fā)送和接收消息來通信。它以高吞吐量、可擴(kuò)展性、耐用性和異步通信聞名。成千上萬的公司用它來構(gòu)建數(shù)據(jù)管道、消息系統(tǒng)和事件溯源。

Netflix作為技術(shù)創(chuàng)新的領(lǐng)導(dǎo)者，為什么要放棄它呢？原文分析得很到位，我覺得這點(diǎn)值得我們所有開發(fā)者警醒。Kafka不是不行，而是要看場景。我在擴(kuò)展時(shí)想說，Kafka特別適合那些需要處理海量數(shù)據(jù)的場景，比如實(shí)時(shí)日志分析或大數(shù)據(jù)流，但如果你的系統(tǒng)沒那么極端，用它可能就是殺雞用牛刀了。

原因1：Kafka對(duì)他們的用例來說太復(fù)雜了

Netflix并沒有說Kafka本身有問題，它確實(shí)強(qiáng)大。但在Tudum中，管理Kafka的復(fù)雜性與它解決的問題不成比例。這是我最認(rèn)同的一點(diǎn)，因?yàn)槲乙娺^太多團(tuán)隊(duì)因?yàn)樽非蟆跋冗M(jìn)”而陷入泥潭。

Kafka對(duì)低吞吐量工作負(fù)載來說是過度殺傷

Tudum的服務(wù)不像視頻流系統(tǒng)那樣每秒處理成千上萬的請(qǐng)求，很多是圍繞編輯變更、CMS更新或內(nèi)部數(shù)據(jù)同步的事件驅(qū)動(dòng)工作流。事件率很低，可能每小時(shí)就幾十個(gè)。

舉個(gè)例子：假設(shè)編輯在CMS中更新了一個(gè)博客帖子的標(biāo)題，Kafka會(huì)把這個(gè)事件發(fā)送到下游服務(wù)，用于重新索引內(nèi)容、更新翻譯和再生前端HTML。這聽起來沒毛病，但低事件率讓Kafka的高吞吐設(shè)計(jì)毫無用武之地。相反，它帶來了運(yùn)營開銷：監(jiān)控broker、擴(kuò)展集群、管理消費(fèi)者偏移和重試策略。這些對(duì)小型內(nèi)部更新工作流來說太重了。

從我的角度擴(kuò)展一下，我在開發(fā)一個(gè)內(nèi)部工具時(shí)也用過Kafka，結(jié)果發(fā)現(xiàn)維護(hù)它花的時(shí)間比實(shí)際開發(fā)多得多。后來我學(xué)乖了，對(duì)于低頻事件，直接用簡單的隊(duì)列就夠了。

原因2：更簡單的工具可以完成相同的工作

另一個(gè)主要原因是，有更簡單的替代方案，能以更少的運(yùn)營努力完成同樣的工作。這讓我想起“Keep It Simple, Stupid”（KISS）原則——越簡單越好。

用REST和Pub/Sub替換Kafka

在某些情況下，Tudum用直接的REST API調(diào)用替換了Kafka。對(duì)于實(shí)時(shí)用戶動(dòng)作，HTTP同步調(diào)用更簡單，也更容易調(diào)試。對(duì)于異步流程，輕量級(jí)消息隊(duì)列如Google Pub/Sub或Amazon SQS就夠用了。這些工具內(nèi)置重試、無需管理集群、易于集成云原生環(huán)境。

舉例：原本用Kafka通知渲染服務(wù)CMS更新的，現(xiàn)在改用Google Cloud Pub/Sub——一個(gè)簡單的話題，無需消費(fèi)者偏移跟蹤，部件更少。這讓系統(tǒng)更容易調(diào)試、部署和維護(hù)。

Netflix認(rèn)識(shí)到，如果80%的 workflow 是低量異步的，就沒必要用Kafka的重型能力。我擴(kuò)展一下：在我的項(xiàng)目中，我曾經(jīng)從Kafka切換到RabbitMQ或SQS，結(jié)果團(tuán)隊(duì)效率提升了30%，因?yàn)樯倭四切┓植际絾栴}的困擾。

原因3：排查Kafka問題拖慢了團(tuán)隊(duì)

Kafka的分布式特性在出問題時(shí)會(huì)增加一層復(fù)雜性，這點(diǎn)原文描述得很生動(dòng)。

當(dāng)服務(wù)通過Kafka通信時(shí)，調(diào)試意味著追蹤事件日志、檢查偏移、分析broker日志、確保冪等性和重試。現(xiàn)在，想象內(nèi)容團(tuán)隊(duì)抱怨：“編輯后博客帖子沒顯示正確。”工程師就得開啟一場Kafka-centric的調(diào)查之旅，拖慢一切。

舉例：編輯更新文章，但翻譯沒同步。工程師得查Kafka日志，看消息是否產(chǎn)生、消費(fèi)、重試或丟棄——跨多個(gè)服務(wù)。

相比之下，REST調(diào)用有內(nèi)置響應(yīng)和日志。移除Kafka后，平均解決時(shí)間（MTTR）降低了，團(tuán)隊(duì)能更快行動(dòng)，花更少時(shí)間調(diào)試事件管道。

我個(gè)人經(jīng)歷過類似：一次Kafka分區(qū)問題讓我調(diào)試了半天，如果是REST，早解決了。這讓我意識(shí)到，工具的選擇直接影響開發(fā)者的幸福感。

原因4：擁抱云原生簡單性

Netflix一直是云計(jì)算的先鋒，但即使是他們，也在轉(zhuǎn)向云原生托管服務(wù)，以減輕內(nèi)部團(tuán)隊(duì)負(fù)擔(dān)。

Kafka，尤其是開源版，不是“即插即用”。它需要Zookeeper（或KRaft）、分區(qū)管理、集群擴(kuò)展、監(jiān)控管道（用Kafka Connect等）。相比，云原生消息系統(tǒng)如Google Pub/Sub或AWS SNS/SQS提供：無需管理服務(wù)器、自動(dòng)擴(kuò)展、集成監(jiān)控、更易IAM/安全集成。

對(duì)于像Tudum這樣專注于內(nèi)容的團(tuán)隊(duì)，云原生工具更合適。我擴(kuò)展說，在云時(shí)代，自管Kafka的風(fēng)險(xiǎn)越來越高，尤其是團(tuán)隊(duì)規(guī)模小時(shí)。Netflix的舉動(dòng)提醒我，優(yōu)先考慮托管服務(wù)，能讓工程師專注核心業(yè)務(wù)。

Kafka強(qiáng)大，但不是總是正確選擇

這里要澄清：Kafka不是壞工具。對(duì)于高規(guī)模實(shí)時(shí)用例——如視頻分析、推薦系統(tǒng)或欺詐檢測——它是黃金標(biāo)準(zhǔn)。

但Netflix教給我們一個(gè)重要教訓(xùn)：“強(qiáng)大不等于合適?！盩udum需要更簡單的 workflow、更低的運(yùn)營開銷、更快的開發(fā)周期、更少的調(diào)試時(shí)間。在這種語境下，Kafka帶來的痛大于益。

我同意這點(diǎn)，并擴(kuò)展：在架構(gòu)設(shè)計(jì)時(shí)，我現(xiàn)在總是問自己，這個(gè)工具的復(fù)雜性是否匹配問題規(guī)模？

開發(fā)者能從中吸取什么

基于原文，我提取了一些清晰的 takeaway，能應(yīng)用到你自己的項(xiàng)目中。我會(huì)稍作擴(kuò)展，結(jié)合我的見解。

1. 基于實(shí)際需求選擇工具，而不是趨勢
Kafka很流行，大家都談“事件驅(qū)動(dòng)架構(gòu)”。但總是問：我們解決什么問題？這會(huì)增加復(fù)雜性嗎？更簡單的工具能更好嗎？即使Netflix最初過工程化了，后來也修正了。我的經(jīng)驗(yàn)：趨勢工具往往讓小團(tuán)隊(duì)陷入維護(hù)地獄。

2. 優(yōu)先云原生，其次自管
盡可能用云原生托管服務(wù)，而不是自托管平臺(tái)。它們減少團(tuán)隊(duì)工作，讓你專注業(yè)務(wù)邏輯。如果你的團(tuán)隊(duì)花更多時(shí)間管Kafka而不是建功能，那就是問題了。我切換到AWS SQS后，運(yùn)維成本直線下降。

3. 內(nèi)部工具青睞簡單性
用戶面向功能可能需要復(fù)雜性。但內(nèi)部 workflow——如CMS更新、定時(shí)同步或管理員工具——保持簡單。REST + 隊(duì)列往往勝過Kafka。我在公司內(nèi)部系統(tǒng)上驗(yàn)證過這點(diǎn)。

4. 監(jiān)控MTTR和開發(fā)者摩擦
如果工具造成太多停機(jī)、事件或長調(diào)試周期，就該重思棧了。Netflix看了事件歷史，看到Kafka相關(guān)減速，才觸發(fā)架構(gòu)審查。我建議大家定期審計(jì)工具的影響。

真實(shí)例子：CMS事件流中的Kafka vs REST

原文給了一個(gè)對(duì)比，我覺得很實(shí)用，就擴(kuò)展一下。

舊的Kafka-based流程：

CMS編輯更新帖子 → Kafka Producer發(fā)送事件 → Kafka Topic接收 → Consumer Service讀取 → 觸發(fā)翻譯 → 觸發(fā)重新索引 → 再生前端。

如果任何步驟失敗，調(diào)試需要Kafka CLI工具、日志解析、偏移跟蹤。痛點(diǎn)多。

新的REST + Pub/Sub流程：

CMS編輯更新帖子 → 后端API直接調(diào)用Translation Service → Translation發(fā)布到Pub/Sub → 其他服務(wù)并行訂閱更新。

無偏移、無broker、更簡單邏輯。我擴(kuò)展說，這種流程在微服務(wù)中更易測試，錯(cuò)誤處理也更直觀。

最終想法

Netflix從Tudum移除Kafka的決定，不是拒絕Kafka，而是選擇合適復(fù)雜度的水平。這鼓勵(lì)所有開發(fā)者、架構(gòu)師和工程領(lǐng)導(dǎo)審視自己的系統(tǒng)：你是否在輕量工具就能搞定的地方用了重型工具？你的系統(tǒng)調(diào)試快嗎？初級(jí)工程師能快速上手而不迷失在工具中？如果Netflix——以其技術(shù)火力——都能優(yōu)先簡單性，我們也能。