作者 ｜ Viquar Khan

譯者 ｜ 平川

云原生轉型與“經濟型操作系統”

要理解 Apache Kafka 當前的架構發展方向，首先需要明確其本質。Kafka 是一個分布式事件流平臺，旨在實時發布、訂閱、存儲和處理記錄流。其演進由開源社區通過 “Kafka 改進提案”（KIP）來推動，這些正式的設計文檔概述了主要的架構變更和功能特性。

多年來，Kafka 一直嚴格依賴于一種專為優化裸機部署的“無共享”設計。它將順序的僅追加日志直接寫入本地代理磁盤，并直接從操作系統的頁面緩存中提供讀取服務，從而實現了其傳奇般的個位數毫秒級延遲。這種方法既保證了低延遲，又保證了高吞吐量。然而，將這種受硬件限制的架構“原樣遷移”到現代云環境中，卻暴露出了嚴峻的財務問題。

以 Discover Financial Services 的現代化轉型歷程為例。Discover 總部位于伊利諾伊州的里弗伍茲，其全球網絡每天處理數百萬筆交易。為了提高工程開發速度并支持數據科學項目，Discover 將其傳統的信用卡結算環境遷移到了以 Apache Kafka 作為核心事件主干的云原生架構上，將信用卡結算交易實時流式傳輸至下游處理層（包括 Amazon EMR 和 Apache Spark），用于欺詐檢測和風險評分。此次遷移將價格變更的落地時間從六個月大幅縮短至僅三周，使該平臺能夠在短短九分鐘內處理四百萬條交易記錄（亞馬遜云科技客戶案例研究（https://aws.amazon.com/solutions/case-studies/discover-case-study/）、2021 年亞馬遜云科技 re:Invent 大會上的演講（https://www.youtube.com/watch?v=JRMheZRarW4））。

在現代化技術棧中，Kafka 發揮著獨特的作用：其事件流架構為風險分析和欺詐檢測提供了實時處理的主干，可以持續地為下游模型提供數據，而 EMR 和 Spark 則負責批處理結算。

然而，將一個龐大的多租戶平臺遷移到云端，會暴露出云端單位經濟性的現實問題。在可用區（AZ）之間對交易數據進行三次鏡像復制，會產生巨額的網絡出站費用。此外，將數 PB 的審計日志或歷史事件流式存儲在高級云塊存儲上，成本很快就會高得令人望而卻步。

為了在云環境中生存，Kafka 正從一個嚴格受硬件限制的系統，逐步演變為一種由嚴格財務控制所主導的高度解耦的架構。雖然這種架構常被稱為“經濟型操作系統”，但這一術語不僅僅是一個比喻；它代表了一種具體的運營現實，即平臺團隊必須積極構建基于遙測數據的成本分攤管道，推行注重成本的回放治理工作流，并有選擇地應用隊列語義來管理波動劇烈的云支出。

下圖所示的決策矩陣說明了架構師應該如何將具體的工作負載與這些不斷演進的能力進行匹配：

圖 1. 將工作負載映射到分層存儲能力的決策矩陣（圖片由作者提供）

如圖 1 所示，架構師應該根據事務順序要求、延遲敏感度以及數據保留需求，將具體的工作負載映射到這些不斷演進的能力上。

在本文中，我們將結合從分層存儲到無盤未來的各個架構演進階段，探討現實中的運營挑戰，并詳細說明架構師和平臺團隊必須如何調整其部署策略。

解耦計算與存儲容量：分層存儲的實踐現狀

KIP-405：Kafka 分層存儲（https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage）通過將數據保留劃分為兩個獨立的層，改變了代理與狀態之間的關系：一個是利用塊存儲的、針對延遲進行優化的本地層，另一個是利用對象存儲（如 Amazon S3）的、針對存儲容量進行優化的遠程層。一個名為“遠程日志管理器”（Remote Log Manager）的內部代理組件充當協調器，當滾動日志段超過特定的大小或時間閾值時，會將其異步地從本地磁盤移動到外部存儲。

實用指南：何時啟用分層存儲

平臺團隊不應該盲目地在所有集群中啟用 Kafka 分層存儲。架構師必須根據三個因素來評估磁盤存儲與對象存儲之間的取舍：數據保留時長、讀取模式以及當前塊存儲卷的成本狀況。那些數據保留時間遠超其活躍處理窗口（通常超過七天）的集群是最理想的候選對象，因為其中存儲的大部分數據都屬于冷數據，可以以遠低于塊存儲成本的價格遷移到對象存儲。然而，對于保留窗口較短或具有延遲敏感型熱讀取模式的集群，收益可能微乎其微，甚至會因為對象存儲 API 的開銷（參見下文的請求放大效應）而增加成本。有多種標準可以幫助我們做出有利的取舍。

合規與審計需求

你的工作負載需要長期保留數據（例如，為符合《薩班斯-奧克斯利法案》（SOX）或《支付卡行業數據安全標準》（PCI-DSS）而保留七年的審計日志）。假設某金融機構在 EBS gp3 卷上（根據 AWS EBS 定價頁面，費用為 0.08 美元/GB-月）為每個 Kafka 代理存儲 50 TB 的審計日志。若 Kafka 復制因子為 3，僅是塊存儲每月每代理的成本就約為 12288 美元（50 TB × 1024 GB/TB × 0.08 美元 × 3 ）。將冷數據段遷移至 S3 Standard（根據 AWS S3 定價頁面（https://aws.amazon.com/s3/pricing/），0.023 美元/GB-月）可以將數據保留成本降至每月約 1178 美元，節省約 90%。對于使用預配置 IOPS 高性能 io2 卷（ 0.125 美元/GB-月）的集群，節省幅度可以超過 93%。這些數據基于 2025 年美國東部（北弗吉尼亞）的標價；實際成本因區域、協商折扣及數據檢索模式而異。讀者可使用亞馬遜云科技的定價計算器（https://calculator.aws/）驗證并自定義這些估算值。

基于回放的深度分析

機器學習管道和數據科學團隊經常需要通過掃描多年的歷史交易數據來重建狀態存儲。分層存儲通過遠程層處理這些讀取請求，從而將本地磁盤上對延遲敏感的實時交易處理與高 I/O 負載相隔離。

如果你的工作負載主要屬于實時處理，數據保留時間不足七天，那么架構復雜性的增加以及潛在的 API 開銷將導致無法帶來正向的投資回報。

FinOps 風險：請求放大

雖然分層存儲能大幅降低塊存儲的開支，但云對象存儲 API 的引入卻帶來了嚴重的 FinOps 風險。云基礎設施提供商對對象存儲的計費不僅基于靜態存儲的千兆字節數，還基于 API 交互的數量（例如，按每千次 GET 請求收費）。

本質上，Kafka 消費者執行的是順序讀取操作，因此，如果配置錯誤的消費者試圖獲取數年的歷史數據，就可能會引發請求放大效應，導致每秒產生數千個獨立的 S3 GET 請求，使 API 費用急劇飆升。

架構措施：為降低請求放大風險，平臺工程師應該考慮將消費者的 max.partition.fetch.bytes 與消息代理的遠程分段大小保持一致。其原理很簡單：如果消費者的獲取窗口與遠程對象的大小高度匹配，那么代理在每次獲取數據時發出的單獨 GET 調用就會減少，從而可以降低尾部延遲并減少 API 成本暴露。不過，這仍然只是一種優化模式，而非放之四海皆準的方案；實際的對象存儲 API 調用次數取決于分段大小、獲取頻率、消費者的并行度以及訪問局部性。

值得注意的是，社區已經意識到了這一調優鴻溝：KIP-1178（https://cwiki.apache.org/confluence/display/KAFKA/KIP-1178） 提議引入一個專用的 remote.max.partition.fetch.bytes 消費者配置，將遠程獲取的大小與本地獲取行為解耦，并且承認，當前 1 MB 的默認值與典型云連接器的 4 MB 數據塊大小不匹配。在 KIP-1178 或類似提案投入生產環境之前，團隊應該將抓取大小調優視為一項經驗性操作，并通過遠程抓取指標驗證其對特定工作負載的影響，而不是假設它能普遍消除 API 成本風險。

彌補可視化方面的不足：FinOps 與成本歸因

起初，分層存儲會讓平臺工程團隊在財務方面處于“盲區”。如果內部開發團隊啟動了一個掃描五年交易記錄的重型批處理任務，云服務賬單就會飆升，但運維人員卻無法將成本歸因于特定的應用程序，因為傳統的 Kafka 指標僅在代理或主題級匯總數據。正是這一治理缺口催生了 KIP-1267：分層存儲成本歸因指標。該提案建議引入客戶端 JMX 遙測數據，包括 RemoteFetchBytesPerSec 和 RemoteFetchRequestsPerSec 等指標，實現針對每個消費應用的精細化成本歸因。

重要提示：KIP-1267 目前正處于社區討論階段，尚未被采納或合并到 Apache Kafka 的發布版本中。下文所述的遙測管道（利用 Prometheus 抓取這些指標，并通過 Grafana 可視化每個客戶端的成本歸因）代表了該 KIP 投入生產環境后的預期架構模式，并非當前上游 Kafka 版本中已有的功能。對于在 KIP-1267 發布前就需要進行成本歸因的組織，可以結合代理級指標與消費者組延遲跟蹤來做近似實現，但這種方法缺乏 KIP 所提出的客戶端粒度。

KIP-1267 解決了這一關鍵的可視化缺口。它引入了專門針對遠程存儲操作而設計的精細化 JMX 遙測功能，并將其直接與客戶端 ID 相關聯。這項增強功能使運維人員能夠將遠程讀取成本準確地歸因到特定的消費者，從而實現嚴格的成本分攤和 FinOps 治理。

構建基于遙測數據的成本分攤管道

平臺團隊必須將這些指標轉化為具體的治理工作流。以下是利用 Prometheus 和 Grafana 實現這一目標的實用路徑：

• 指標暴露與集中抓取

在代理節點上配置 Prometheus JMX 導出代理。定義 YAML 規則用于捕獲新指標（例如 RemoteFetchBytesPerSec 和 RemoteFetchRequestsPerSec），并通過集中式抓取服務器將其對外暴露。

• 成本歸因儀表盤（PromQL）

平臺工程師可以在 Grafana 中使用 PromQL 構建儀表板，計算每位客戶每小時的預計成本。使用多維成本公式，將出站字節數乘以云服務提供商的 GB 傳輸費率，并將請求數乘以 API 定價層級：

CODE

# 注意：下文中的指標名稱遵循 JMX-to-Prometheus 命名約定，# 并應用于 KIP-1267 中提出的指標（RemoteFetchBytesPerSec、# RemoteFetchRequestsPerSec）。確切的 Prometheus 指標名稱取決于你的 JMX 導出器# 映射配置。各團隊在將這些查詢應用于生產環境之前，應根據已采納的 KIP 規范及其導出器# 配置核對最終的指標命名。# 出站成本組成# 將字節/秒的速率轉換為 GB/小時，然后乘以服務商的出站速率(sum(rate(kafka_server_remote_fetch_bytes_total[1h])) by (client_id)  * 3600                    # 速率以秒為單位，擴展到以小時為單位  / 1073741824              # 將字節轉換為 GB  * 0.09)                   # 需要根據云服務商的規則，對出站流量速率進行驗證+# API 請求成本組成# 將每秒請求數轉換為每小時請求數，并按每 1000 次請求計價(sum(rate(kafka_server_remote_fetch_requests_total[1h])) by (client_id)  * 3600                    # 擴展到以小時為單位  / 1000                    # 按每千次請求為單位進行標準化  * 0.0004)                 # 需要根據云服務商的規則，對 S3 GET 速率進行驗證

• 惡意用戶檢測（告警）

為了實施基于成本的回放治理，團隊應該配置 Prometheus Alertmanager 規則，用于檢測失控的歷史掃描。例如，如果某個特定的客戶端 ID 超過了預定義的閾值（如每小時 50 美元的遠程獲取成本），則觸發告警。隨后，自動化管道可以動態調用 Kafka AdminClient API 來應用嚴格的客戶端配額，在月度賬單生成之前對該違規消費者進行限流。

計算治理：彈性與新一代消費者

雖然控制持久化存儲成本至關重要，但下一階段需要關注的是計算資源的彈性管理。從以往情況來看，為了應對流量激增而擴展 Kafka 消費者組往往會造成嚴重的運營中斷。

在舊版消費者重新平衡協議下，每當組中有新的消費者實例加入時，整個組都會被迫暫停處理。每個消費者都會撤銷其分配的分區，并在組領導者重新計算分配結果期間處于空閑等待狀態；這種全局性的“世界暫停”事件嚴重降低了管道的吞吐量。

新一代消費者重新平衡協議（ KIP-848（https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol），在 Kafka 4.0 中正式發布）從根本上解決了這一問題。它將復雜的分配邏輯從厚客戶端庫轉移到了服務器端的組協調器。現在，重新平衡操作以增量協作的方式執行。協調器會指示消費者 A 撤銷對某個分區的分配，但消費者 B 只有在撤銷操作得到顯式確認后才會接管該分區。關鍵在于，兩個消費者都不會因此暫停對其他已分配分區的處理。

運營影響：安全的 Kubernetes 自動縮放

將這些協議改進轉化為部署決策，從根本上改變了平臺團隊管理彈性擴展的方式。過去，將 Kubernetes Horizontal Pod Autoscalers (HPA) 與 Kafka 消費者部署相關聯是極其危險的。動態縮放會觸發連鎖的“重新平衡風暴”，導致應用程序癱瘓。隨著 KIP-848 的推出，基于 HPA 的消費者縮放終于變得安全可靠。不過，在生產環境中啟用該功能前，團隊應該驗證其特定的工作負載特征和延遲指標的穩定性是否支持可靠的自動縮放。

重新平衡風暴大幅減少：服務器端協調（KIP-848）消除了此前導致 HPA 擴展存在風險的“世界暫停”。不過，對于計劃性擴展事件，由代理故障或網絡分區觸發的重新平衡仍然需要謹慎處理。平臺團隊應利用類似 Kubernetes Event-Driven Autoscaling（KEDA）這樣的操作符來動態地縮放消費者 Pod。通過將 KEDA ScaledObject 直接關聯到消費者延遲指標（而非通用的 CPU 利用率），集群能夠根據實際積壓的任務量進行彈性擴展和收縮。

如果要依賴這一行為，就要嚴格遵守最低版本要求：消息代理必須升級至 Kafka 4.0 或更高版本，客戶端應用程序必須使用兼容的庫，并明確啟用 group.protocol=consumer 配置。

大規模多租戶架構：虛擬集群與傳統隔離機制

隨著企業流處理平臺的規模不斷擴大，集群的物理整合已經成為經濟上的必然選擇。為各個產品團隊運行數十個彼此孤立、互不關聯的 Kafka 集群，會導致大量的資源閑置浪費。目前正在社區討論中、尚未被 Apache Kafka 采納的 KIP-1134（虛擬集群）提案，為解決這一挑戰指明了一條架構路徑。

大多數組織試圖通過強制執行嚴格的主題命名約定（如 domain.entity.event），并結合復雜的基于前綴的訪問控制列表（ACL）來管理多租戶環境。在企業級規模下，這種方法難以奏效：在動態變化的開發團隊中管理數千條自定義的前綴規則會成為配置負擔，而且前綴機制本身并不能有效防止消費者無意中劫持其他團隊的消費者組 ID。

KIP-1134（虛擬集群）（https://cwiki.apache.org/confluence/display/KAFKA/KIP-1134%3A+Multi-tenancy+in+Kafka%3A+Virtual+Clusters）提出了一種替代方案，即在單個物理集群內建立專用的邏輯命名空間，取代基于弱訪問控制列表（ACL）的分離方案以及“每個團隊一個集群”的高成本部署模式。下文所述的設計體現的就是該 KIP 提出的架構，而不是已經具備生產環境部署能力的功能。作為內部流數據提供商的大型企業應該密切關注該提案，并在其逐步成熟時進行評估。

根據該設計方案，虛擬實體將映射到底層的物理 UUID，從而使消息代理能夠在元數據和命名空間層面強制執行租戶邊界，這意味著主題名稱、消費者組 ID 以及訪問控制列表 (ACL) 范圍將按虛擬集群進行隔離。請注意，當前的 KIP-1134 提案主要側重于命名空間和元數據隔離；存儲層隔離、按租戶配額以及調度保證則不屬于當前提案的范圍，除非后續修訂版本中包含這些內容。

例如，平臺團隊可以將八個團隊專用的 Kafka 集群整合到一個物理部署中，為合規、分析和欺詐檢測團隊提供一個專用的虛擬命名空間，諸如 transactions 之類的通用主題名可以在這個空間中共存而不發生沖突。然而，KIP 的當前范圍主要側重于命名空間和元數據隔離；在做出整合決策之前，應參考最新的 KIP 討論帖，確認其是否涵蓋存儲級隔離、按租戶配額或調度保證等功能。

重新定義可擴展性：共享組與隊列語義

Apache Kafka 4.2.0 正式將共享組（KIP-932（https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka））提升至生產就緒狀態。傳統上，Kafka 將主題的物理分區數與其最大消費者并行度緊密耦合。如果某個應用程序需要 256 個并發消費者來處理大量涌入的任務，那么架構師就不得不人為地將分區數增加到 256，這是一種眾所周知的不良設計模式。

共享組（KIP-932）通過將隊列式的語義原生集成到 Kafka 生態系統中解決了這一限制。并發消費者數量不再受分區數量的限制，多個消費者可以獨立地處理單個分區的記錄，而代理則負責跟蹤處理中的記錄以及基于租期的交付，它們能夠同時處理來自同一物理分區的獨立記錄。當消費者獲取一條記錄時，代理會授予它一個可配置鎖定時長的排他性獲取鎖。

實用指南：事件處理與任務分發

實施人員必須仔細評估在何種情況下應該用共享組取代傳統的分區擴展策略。

任務分配（采用共享組）

對于分發促銷郵件、單圖片上傳尺寸調整或運行后臺任務隊列的管道而言，精確的執行順序并不重要。在這些場景下，共享組（Share Groups）是最佳選擇。如果在零售活動期間流量激增，Kubernetes HPA 可以動態地將消費者部署擴展至數百個 Pod，從而處理積壓任務，而不需要對主題底層的分區拓撲做任何物理調整。

事件處理（保留經典組）

如果財務數據管道需要按順序計算實時賬戶余額，或通過變更數據捕獲（CDC）重建數據庫狀態，那么嚴格的時間順序就是絕對必要的。在處理前一筆存款之前處理賬戶取款，這違反了業務邏輯。顯然，為了實現無上限的水平并行處理，共享組犧牲了分區級排序保證。對于高度有序的事件流，經典消費者組仍然是唯一正確的架構選擇。

采用風險

共享組（KIP-932）已經在 Kafka 4.2.0 中投入生產應用，但更廣泛的配套機制生態系統還在不斷演進。例如，上游 Kafka 目前尚未提供完整的一等死信隊列（DLQ）支持，包括自動路由無法處理的“毒丸”消息、針對 DLQ 溢出的斷路器模式，以及標準化的錯誤處理標頭。針對這些缺失的社區提案正在積極討論中，但尚未確定具體的實現時間表。作為臨時措施，目前采用共享組進行任務分發的工作負載團隊應計劃實現應用層 DLQ 處理，并關注 Apache Kafka 開發者郵件列表，獲取與 DLQ 有關的 KIP 的最新動態。

在此期間，采用共享組的團隊必須手動構建應用程序級機制，用于檢索和歸檔失敗的消息。為了彌補這一缺口，社區正在積極開展工作：KIP-1191 提議為共享組提供原生的死信隊列（DLQ）路由；KIP-1316 引入了斷路器機制，當超過死信隊列溢出閾值時自動暫停共享組；而 KIP-1317 則強制要求使用處置標頭，以便對無法處理的記錄進行標準化故障追蹤。各團隊應密切關注這些提案，直至其成熟并獲得采納。

未來：“無盤化”的岔路口

雖然分層存儲解決了存儲容量限制問題，但活躍的預寫日志仍然與昂貴的本地代理磁盤緊密相連，而且受制于跨可用區復制所產生的巨額網絡出站成本。鑒于實現真正的云原生效率需要徹底地解耦狀態，Apache Kafka 社區正式批準了 KIP-1150：無盤主題（https://cwiki.apache.org/confluence/display/KAFKA/KIP-1150%3A+Diskless+Topics）。

由 Aiven 提出的 KIP-1150 將持久性邊界完全轉移到了云對象存儲上。本地代理磁盤不再作為權威數據源，而僅被用作臨時緩存。數據將作為“共享日志分段（Shared Log Segments）”直接推送到對象存儲中，并由一個全新的外部 Kafka 批處理協調器分配確定的偏移量。

其經濟潛力巨大。通過消除跨可用區（AZ）復制和塊存儲開支，Aiven 的 OpenMessaging 基準測試（OMB）結果表明，對于高吞吐量的入站工作負載，基礎設施成本降低了 94% 以上；不過，這些結果反映的是特定的基準測試配置，未必適用于所有生產環境。然而，無盤架構正進入社區評估的下一階段，其涉及的架構權衡意味著這并非簡單的升級，而是一項需要針對每項工作負載進行仔細評估的戰略性設計選擇。

可付諸行動的遷移信號：觀望還是采用

無盤主題（Diskless topics）要求架構設計提前做好規劃，技術團隊必須搭建一套嚴謹的、基于工作負載的適配選型矩陣。

何時需要等待（延遲與數據完整性約束）

對于核心事務型應用程序，無盤主題應嚴格遵守僅作為實驗性功能使用的原則。截至本文撰寫之時，KIP-1150 仍然處于社區積極討論狀態（ KIP-1150 討論帖）（https://lists.apache.org/thread/ljxc495nf39myp28pmf77sm2xydwjm6d），而且 Kafka 項目管理委員會尚未授予其生產就緒狀態。Aiven 自身的路線圖文檔（KIP-1150 已被接受（https://aiven.io/blog/kip-1150-accepted-and-the-road-ahead））確認，無盤主題被定位為一項仍在演進且存在未解決設計依賴關系的功能，而不是經過生產環境驗證的特性。

延遲是有代價的：繞過本地磁盤會帶來不可避免的性能開銷。在 Aiven Open Messaging Benchmark (OMB) 配置下，P99 端到端延遲會激增至約 1.5 到 1.6 秒；開發團隊應根據自身的工作負載特征驗證這些數據，因為延遲會隨分區數量、記錄大小和吞吐量而變化。

垃圾回收存在風險：KIP-1150 依賴于“先上傳后提交”的模式。在代理崩潰后，孤立且不可見的段會在 S3 中不斷積累，這是該模式固有的設計風險，是對象存儲架構中任何“上傳過程發生崩潰”時可預見的故障模式，而非理論上的擔憂。該故障模式在 KIP-1150 郵件列表（https://lists.apache.org/thread/ljxc495nf39myp28pmf77sm2xydwjm6d）討論中有記錄，也是 KIP-1163：無盤核心提案背后的核心動因。KIP-1163 提議通過周期性核對循環來檢測并回收孤立的分段，但該提案目前仍在社區討論當中，尚未被采納。

這些孤立的分段會悄無聲息地推高云服務費用，而 KIP-1150 本身并不具備原生的檢測機制。目前正在社區討論當中的 KIP-1163（https://cwiki.apache.org/confluence/display/KAFKA/KIP-1163%3A+Diskless+Core）：無盤核心（Diskless Core），提議通過周期性的核對循環來安全地回收這些孤立的分段。然而，那還只是一個未解決的設計依賴項，尚未被上游 Kafka 接受或實現。缺少已經落地的垃圾回收機制是當前存在的設計風險。因此，當前評估 KIP-1150 的團隊必須規劃外部監控和手動核對流程，以便檢測并清除孤立的分段。

數據完整性與“僅執行一次”語義（EOS）：在關于 KIP-1164 的設計討論中，一個關鍵且尚未解決的問題聚焦在“僅執行一次”語義上。轉向無領導者的數據平面，本質上會使事務狀態機去中心化。如果無盤協調器（Diskless Coordinator）需要為大量復用的分區計算最后穩定偏移量（LSO），那么它可能成為嚴重的性能瓶頸——這是提案中尚未解決的設計風險。如果設計不周，該架構可能會引發腦裂（split-brain）場景或破壞 read_committed 隔離級別。

社區討論過程中提出了一種緩解方案，建議將“_diskless-metadata”主題定義為一個不可變的事件存儲。在這種模型下，協調器的嵌入式 SQLite 數據庫將純粹作為該事件流上的物化視圖（投影），維護一個持續更新的活躍生產者 ID（PID）索引，從而在 O(1) 時間內動態地解析 LSO，而不需要掃描無限長的交易日志。請注意，這種基于投影的 SQLite 方案源自社區郵件列表的討論，并非 KIP-1164 正式規范的一部分，是否會納入最終設計仍然取決于社區共識。在這些機制正式確立之前，如果團隊運行的管道對 EOS 敏感，就必須將無盤主題視為與事務性保證不兼容，并等待該提案進一步完善。

決定何時采用海量數據分析。架構師應立即針對對延遲不敏感的海量工作負載（例如應用程序遙測數據聚合、分布式追蹤跨度、全面審計日志記錄以及大規模批處理分析）積極試點無盤主題。在這些場景中，以 1.6 秒的延遲代價換取 94% 的基礎設施成本削減，是一項極具價值的商業決策。

小 結

隨著已準備就緒的分層存儲將數據保留與磁盤容量解耦、服務器端消費者重新平衡（KIP-848）實現了安全的 Kubernetes 自動縮放，以及共享組（KIP-932）釋放了與分區無關的并行處理能力，Kafka 已經為云原生流式處理平臺打下了若干基礎性的支柱。與此同時，諸如 KIP-1267（成本歸因）和 KIP-1134（虛擬集群）等提案，則明確表明社區致力于解決財務治理和多租戶隔離方面的剩余缺口，盡管這些功能仍然在積極討論當中，尚未投入生產環境。

因此，最恰當的理解是，“經濟型操作系統”是一種正在形成的架構模式而非成品。在這種架構模式中，成本意識、彈性計算和租戶隔離融合為一種統一的設計理念。在當前已經生產就緒的 KIP 的支持下，企業已經可以構建由 Prometheus 驅動的成本分攤管道，依靠 Kubernetes 自動縮放器來應對流量峰值，并針對任務分發工作負載有選擇地應用隊列語義。

對于嚴格地將運行穩定性和上游數據完整性置于首位的團隊而言，經典的分層存儲結合 FinOps 治理仍然是經過驗證且可投入生產使用的方案。無盤方案（KIP-1150：無盤主題分區、KIP-1176：通過僅遠程主題實現的無盤代理，以及 KIP-1183： 無盤復制）有望進一步重塑流處理的底層經濟模式，但這些相互競爭的設計方案也凸顯出，社區尚未就單一方案達成共識。通過將工作負載與正確的存儲和計算范式進行精準匹配，并在采用前跟蹤每個 KIP 的成熟度，架構師可以確保其事件驅動架構既能經受住首席財務官的審查，又能滿足行星級基礎設施不斷演變的需求。

https://www.infoq.com/articles/architecting-cloud-native-kafka/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。