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

背景故事：Tudum是什么？

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

在我的經驗中，這種內容站點通常需要從內部系統拉取數據，比如生產目錄、元數據服務、本地化管道、內容管理系統（CMS）等等。Tudum早期團隊選擇了Apache Kafka作為事件驅動架構的核心，這在初期運行得挺順利。但隨著系統成熟和擴展，一些問題開始顯現，最終Netflix做出了驚人的決定：完全從Tudum的后端移除Kafka。這讓我想到，我自己在項目中也遇到過類似情況——一開始選了個牛逼的技術，結果后來發現它成了負擔。

Kafka是什么？簡單回顧一下

為了讓大家跟上節奏，先快速復習一下Kafka。Apache Kafka是一個分布式事件流平臺，它允許應用通過實時發送和接收消息來通信。它以高吞吐量、可擴展性、耐用性和異步通信聞名。成千上萬的公司用它來構建數據管道、消息系統和事件溯源。

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

原因1：Kafka對他們的用例來說太復雜了

Netflix并沒有說Kafka本身有問題，它確實強大。但在Tudum中，管理Kafka的復雜性與它解決的問題不成比例。這是我最認同的一點，因為我見過太多團隊因為追求“先進”而陷入泥潭。

Kafka對低吞吐量工作負載來說是過度殺傷

Tudum的服務不像視頻流系統那樣每秒處理成千上萬的請求，很多是圍繞編輯變更、CMS更新或內部數據同步的事件驅動工作流。事件率很低，可能每小時就幾十個。

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

從我的角度擴展一下，我在開發一個內部工具時也用過Kafka，結果發現維護它花的時間比實際開發多得多。后來我學乖了，對于低頻事件，直接用簡單的隊列就夠了。

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

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

用REST和Pub/Sub替換Kafka

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

舉例：原本用Kafka通知渲染服務CMS更新的，現在改用Google Cloud Pub/Sub——一個簡單的話題，無需消費者偏移跟蹤，部件更少。這讓系統更容易調試、部署和維護。

Netflix認識到，如果80%的 workflow 是低量異步的，就沒必要用Kafka的重型能力。我擴展一下：在我的項目中，我曾經從Kafka切換到RabbitMQ或SQS，結果團隊效率提升了30%，因為少了那些分布式問題的困擾。

原因3：排查Kafka問題拖慢了團隊

Kafka的分布式特性在出問題時會增加一層復雜性，這點原文描述得很生動。

當服務通過Kafka通信時，調試意味著追蹤事件日志、檢查偏移、分析broker日志、確保冪等性和重試。現在，想象內容團隊抱怨：“編輯后博客帖子沒顯示正確。”工程師就得開啟一場Kafka-centric的調查之旅，拖慢一切。

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

相比之下，REST調用有內置響應和日志。移除Kafka后，平均解決時間（MTTR）降低了，團隊能更快行動，花更少時間調試事件管道。

我個人經歷過類似：一次Kafka分區問題讓我調試了半天，如果是REST，早解決了。這讓我意識到，工具的選擇直接影響開發者的幸福感。

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

Netflix一直是云計算的先鋒，但即使是他們，也在轉向云原生托管服務，以減輕內部團隊負擔。

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

對于像Tudum這樣專注于內容的團隊，云原生工具更合適。我擴展說，在云時代，自管Kafka的風險越來越高，尤其是團隊規模小時。Netflix的舉動提醒我，優先考慮托管服務，能讓工程師專注核心業務。

Kafka強大，但不是總是正確選擇

這里要澄清：Kafka不是壞工具。對于高規模實時用例——如視頻分析、推薦系統或欺詐檢測——它是黃金標準。

但Netflix教給我們一個重要教訓：“強大不等于合適。”Tudum需要更簡單的 workflow、更低的運營開銷、更快的開發周期、更少的調試時間。在這種語境下，Kafka帶來的痛大于益。

我同意這點，并擴展：在架構設計時，我現在總是問自己，這個工具的復雜性是否匹配問題規模？

開發者能從中吸取什么

基于原文，我提取了一些清晰的 takeaway，能應用到你自己的項目中。我會稍作擴展，結合我的見解。

1. 基于實際需求選擇工具，而不是趨勢
Kafka很流行，大家都談“事件驅動架構”。但總是問：我們解決什么問題？這會增加復雜性嗎？更簡單的工具能更好嗎？即使Netflix最初過工程化了，后來也修正了。我的經驗：趨勢工具往往讓小團隊陷入維護地獄。

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

3. 內部工具青睞簡單性
用戶面向功能可能需要復雜性。但內部 workflow——如CMS更新、定時同步或管理員工具——保持簡單。REST + 隊列往往勝過Kafka。我在公司內部系統上驗證過這點。

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

真實例子：CMS事件流中的Kafka vs REST

原文給了一個對比，我覺得很實用，就擴展一下。

舊的Kafka-based流程：

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

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

新的REST + Pub/Sub流程：

CMS編輯更新帖子 → 后端API直接調用Translation Service → Translation發布到Pub/Sub → 其他服務并行訂閱更新。

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

最終想法

Netflix從Tudum移除Kafka的決定，不是拒絕Kafka，而是選擇合適復雜度的水平。這鼓勵所有開發者、架構師和工程領導審視自己的系統：你是否在輕量工具就能搞定的地方用了重型工具？你的系統調試快嗎？初級工程師能快速上手而不迷失在工具中？如果Netflix——以其技術火力——都能優先簡單性，我們也能。