Apache Kafka 在傳統的物理機部署時代，採取的是一種共享無狀態（Shared-nothing）設計。它將數據順序寫入本地磁碟，並依賴操作系統的頁快取（Page Cache）來達成極低延遲。然而，當企業將這套架構直接搬到雲端時，會面臨巨大的成本挑戰：為了高可用性，數據必須在多個可用區（Availability Zones）之間同步，這會產生高昂的網路傳輸費；而使用高性能的雲端塊儲存（Block Storage）來存放海量歷史數據，則會讓預算迅速崩潰。
為了適應雲端環境，Kafka 正在從硬體綁定轉向一種解耦的架構，將儲存與計算分離，並將成本管理納入核心設計。
儲存與計算解耦：分層儲存（Tiered Storage）
為了解決儲存成本問題，Kafka 引入了分層儲存（Tiered Storage，KIP-405）。這將數據保留分為兩個層級：本地層（Local Tier）使用快速的塊儲存處理即時數據，遠端層（Remote Tier）則將較舊的數據異步遷移到便宜的物件儲存（如 Amazon S3）。
對於需要長期保留數據（例如法規要求存放七年的審計日誌）或需要頻繁回溯歷史數據進行機器學習訓練的場景，分層儲存能降低 90% 以上的儲存成本。但請注意，這並非萬能藥。如果你的數據保留週期很短（例如低於七天），引入分層儲存反而會增加架構複雜度。
這裡有一個關鍵的工程風險：請求放大（Request Amplification）。雲端物件儲存是按 API 請求次數收費的。如果消費者（Consumer）的抓取大小設定不當，一次歷史數據回溯可能會觸發數以萬計的 GET 請求，導致帳單暴增。目前的建議是調整消費者的抓取參數，使其與遠端分段大小對齊，以減少 API 調用次數。
FinOps 與成本歸屬的挑戰
當儲存成本從固定基礎設施轉向按量計費的 API 時，平台團隊面臨一個痛點：無法知道是哪個應用程式導致了帳單飆升。傳統指標僅能看到 Broker 或 Topic 層級的流量，無法追蹤到具體的 Client ID。
針對此問題，KIP-1267 提議引入客戶端層級的遙測指標，讓運維人員能透過 Prometheus 和 Grafana 建立成本歸屬儀表板。透過計算每個 Client ID 的遠端抓取位元組數與請求數，平台團隊可以實現精確的內部計費（Chargeback），甚至能針對異常的高成本消費者自動觸發配額限制（Quotas），防止帳單失控。
計算資源的彈性：新一代消費者協調協議
在過去，擴展 Kafka 消費者群組（Consumer Group）是一件危險的事。舊版的再平衡（Rebalance）協議在有新成員加入時，會觸發全域停止（Stop-the-world），所有消費者必須停止處理並重新分配分區，導致處理管線出現明顯停頓。
這使得在 Kubernetes 上使用 HPA（水平 Pod 自動擴展）變得極其困難。而新一代的協調協議（KIP-848，Kafka 4.0 GA）將分配邏輯移至伺服器端的協調器（Group Coordinator），實現增量且協作式的再平衡。消費者不再需要全部停止，而是逐個交接分區。這讓基於 KEDA 等工具，根據消費滯後量（Lag）來動態擴展 Pod 變得安全可行。
多租戶隔離與虛擬集群
在大型企業中，為每個團隊部署獨立集群會浪費大量資源，但共享集群又缺乏強隔離性。目前的做法通常是依賴複雜的命名規範與 ACL（存取控制列表），但這在規模擴大後難以維護。
虛擬集群（Virtual Clusters, KIP-1134）提出了一種邏輯命名空間的概念。在同一個物理集群中，不同租戶擁有獨立的命名空間，其 Topic 名稱與消費群組 ID 彼此隔離，無需在名稱前加上冗長的前綴，在維持資源共享的同時提供更好的管理邊界。
打破分區限制：共享群組（Share Groups）
傳統 Kafka 的並行處理能力受限於分區（Partition）數量。如果你需要 256 個消費者並行處理，就必須將 Topic 設置為 256 個分區，這在實務上常導致過度分區的效能問題。
共享群組（Share Groups, KIP-932，Kafka 4.2.0 已正式推出）引入了類隊列（Queue-like）的語義。多個消費者可以獨立處理同一個分區內的記錄，Broker 會負責追蹤處理狀態與租約。
這裡需要區分兩種場景： 任務分發（Task Distribution）：如發送郵件、圖片處理。這類場景不要求絕對順序，應使用 Share Groups 以獲得極高的水平擴展能力。 事件處理（Event Processing）：如計算帳戶餘額、CDC 數據同步。這類場景對順序有嚴格要求，必須維持傳統的消費者群組（Classic Groups）。
邁向無碟化（Diskless）的未來
分層儲存雖然解決了容量問題，但寫入日誌（Write-ahead Log）依然依賴昂貴的本地磁碟與跨可用區同步。KIP-1150 提出的無碟化主題（Diskless Topics）試圖將持久化邊界完全移至物件儲存，本地磁碟僅作為臨時快取。
雖然 Aiven 的基準測試顯示這能降低 90% 以上的基礎設施成本，但目前的技術權衡非常劇烈： 首先是延遲增加，端到端延遲可能飆升至 1.5 秒以上。 其次是垃圾回收（GC）風險，在 Broker 崩潰時可能會在 S3 留下孤兒分段，導致隱形成本增加。 最後是交易完整性問題，在無碟化架構下，實現精確一次（Exactly-Once Semantics, EOS）的挑戰依然存在。
目前的建議是：對於延遲敏感的核心交易系統，請繼續使用分層儲存；對於高吞吐、延遲容忍度高且成本敏感的分析型工作負載（如遙測數據、審計日誌），可以開始試行無碟化方案。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。