譯者 | 吉鍇
策劃 | 云昭
Apache Kafka是處理流式數據的事實標準。隨著它在各行各業中的廣泛應用，我經常會聽到一個非常有意思的問題：我什么時候不適合使用Apache Kafka？流式數據處理平臺有哪些限制？Kafka在什么場合下不能勝任？
這篇文章探討了Kafka擅長做的和不擅長做的場景。并且用單獨的章節列出了何時適合使用Kafka，何時不適合使用Kafka，以及何時可以將Kafka作為可選項。
首先，Kafka的應用如此廣泛，已經證明了它在流式事件處理領域有著巨大的市場需求。但同時也要注意：Kafka并沒有提供流式事件處理領域的完整解決方案。簡言之，Kafka不是銀彈，而是流式事件處理領域中一個至關重要的組成部分！
今天所在的世界，信息互聯互通變得無處不在。這種越來越緊密的連接生成了大量相互關聯的實時數據。通過對這些數據的處理和加工，企業可以有效的降低成本和風險，并提高業務收入。
車聯網和游戲就是其中兩個最典型的例子：
車聯網：大量的采集數據和售后服務
以下是Allied Market Research制作的2020-2027年全球機會分析和行業預測：
車聯網領域所涉及的場景和行業比大多數人想象的要廣泛得多，比如:網絡基礎設施、安全、娛樂、零售、售后市場、車輛保險、智慧城市等場景。
游戲行業：數十億的玩家和龐大的收入
正如Bitkraft所描述的那樣，游戲行業已經超過了所有其他媒體類別的總和，而這只是一個新時代的開始：
全球每個月都有數百萬新玩家加入游戲社區。那些生活在不富裕國家的玩家，現在也可以負擔得起平價的智能手機和移動網絡資費。而新的游戲商業模式，比如通過玩游戲來賺錢，會改變下一代玩家玩游戲的方式。5G等更具可擴展性和低延遲的技術支持新的場景出現。區塊鏈和NFT（非同質化代幣）正在永遠改變貨幣形態和收藏市場。
這些趨勢數據印證了實時數據處理的需求日益增加。因此了解何時在項目中使用已經成為大規模數據處理分析和業務數據流的事實標準的Apache Kafka及其生態系統就變得很有價值。
Apache Kafka能做什么、不能做什么？
一些開發者常常對Kafka功能存在著誤解。例如認為Kafka只是一個消息隊列。這很大程度上是由于一些供應商為了銷售他們的產品，而只針對Kafka的特定功能（例如將數據導入到數據湖或數據倉庫）進行介紹。
Kafka能做什么：
- 一個可擴展的實時消息平臺，每秒可處理數百萬條消息
- 用于海量大數據分析和少量業務數據處理的事件流平臺
- 支持分布式存儲，具有消息緩存功能，支持各種通信協議，支持按順序消息重放。
- 流式ETL的數據集成框架
- 用于連續無狀態或有狀態流處理的數據處理框
- cheng'gong'di成功迪在一個平臺上結合了全部這些特點。
Kafka不能做什么：
- 不是一個數百萬客戶端（如移動應用程序）的接入網關；但Kafka原生代理（如REST或MQTT）適用于某些場景
- 不是一個接口管理平臺，但這些工具通常是互補的；用于Kafka API的創建、生命周期管理或貨幣化
- 不是一個用于復雜查詢和執行批處理分析的數據庫；但可以勝任業務查詢和相對簡單的聚合（尤其是使用ksqlDB）
- 不是一個具有設備管理等功能物聯網平臺；但可以直接與支持某些物聯網協議（如MQTT或OPC-UA）的設備進行集成，并且是一些場景下的推薦做法。
- 不是一種用于完全實時系統（如安全關鍵或確定性系統）框架，但對于任何其他IT框架也是如此，畢竟嵌入式系統是一種不同的軟件。
由此可見，Kafka與其他技術是互補的，而不是競爭性的。因此我們應該根據任務的特點選擇是否使用Kafka，并將它和其他的框架結合使用！
萬物互聯世界中的Apache Kafka
Kafka與其他技術結合的成功例子不在少數，這些案例展示了Kafka如何解決了業務問題。這里的重點是對案例的研究，實際上對于端到端數據流解決方案，Kafka往往需要和其他組件配合使用。
的在Apache Kafka的實時數據流方面，已經有大量用于車聯網、物聯網邊緣計算、移動互聯網游戲等領域的大數據分析或業務數據處理de成功案例。
這里我列出了幾個不同行業和場景的案例：
- 奧迪：推出跨地區和跨云供應商的車聯網平臺
- 寶馬：高效物流和供應鏈的智能工廠
- Solar Power：提供完整的太陽能解決方案和服務
- 皇家加勒比：以混合云部署、支持離線的邊緣服務為基礎構建得游輪娛樂系統
- 迪士尼+Hotstar：為數百萬粉絲提供在智能手機上的交互式媒體和游戲/博彩
像這樣的案例一直在不停的增加
然而我們需要進一步說明何時在Apache Kafka系統中使用事件流，以及其他補充解決方案如何和為Kafka提供補充。
何時適合使用Apache Kafka
在討論什么時候不使用Kafka之前，讓我們先了解應該在何時使用Kafka，并了解如何使用其他技術來補充Kafka。我將在每個部分中添加真實示例。這會使得理解這些場景變得更加容易。
1、通過Kafka實時處理物聯網和移動端大數據
大數據實時處理是Kafka的關鍵能力之一。
特斯拉不僅僅是一家汽車制造商。還是一家科技公司，他開發了大量創新和尖端軟件。他們為汽車提供能源基礎設施，包括特斯拉超級充電站、生產太陽能得超級工廠的等等。特斯拉成功的關鍵技術之一，就是實時處理和分析來自汽車智能電網和工廠的數據，并與其他IT后端服務集成。
特斯拉建立了一個基于Kafka的數據平臺基礎設施，支持數百萬臺設備和數萬億個數據埋點。2019年，特斯拉在Kafka峰會上展示了他們實時數據業務的演進過程：
請注意，Kafka的作用不僅是信息傳遞。Kafka是一個分布式存儲層，它真正將生產者和消費者解耦。此外，Kafka原生處理工具（如Kafka Streams和ksqlDB）支持實時處理。
2、通過Kafka將物聯網數據集成到MES和ERP等業務系統
Kafka Connect和其他非Kafka中間件為大規模實時數據集成系統與業務系統（如ERP或MES系統）提供了核心的事件流功能。
BMW在邊緣節點（即智能工廠）和公有云上部署了著執行重要任務的Kafka實例。對制造業的來說每一分鐘的停機時間都會耗費大量資金，因此穩定性就會變得至關重要。而Confluent的Kafka發行版本相比較原生Kafka在穩定性上有了大幅度提高。
寶馬通過對供應鏈的實時優化和管理。實現了在業務系統（如基于SAP的寶馬ERP）中實現正確的物理庫存的信息。我在該領域接觸的近50%的客戶，都在使用Kafka和SAP互相集成的方案。除了和SAP集成，許多下一代ERP和MES平臺也直接使用了Kafka作為底層技術支持。
3、通過Kafka將部署在邊緣端、混合云或多云的非物聯網IT系統集成到企業系統。
將Apache Kafka部署在多集群和跨數據中心已成為常態。一些特定的需求可能需要采用多集群解決方案，包括災難恢復、聚合分析、云遷移、關鍵任務擴展部署、全球Kafka。
相對于其他消息傳遞平臺（如IBM MQ、RabbitMQ或MQTT代理），實現不同協議之間解耦是Kafka的獨特優勢。關于Kafka的領域驅動設計（DDD）也是一個值得詳細探討的方向。
4、通過Kafka為跨行業應用提供可基于混合云部署的現代化基礎設施。
這方面以Unity公司為例，該公司提供了一個游戲實時3D開發平臺，并憑借其AR/VR功能成功進入制造業等其他行業。2019年，這家數據驅動公司產品生成的內容已經在全球達到30億部設備安裝，安裝次數已經達到330億次。同時Unity運營著世界上最大的盈利網絡之一。他們的項目團隊將這個平臺從自建的Kafka遷移到了托管的Confluent 云上，過程中沒有停機或數據丟失。
5、Kafka為移動服務和游戲/博彩平臺提供可擴展的實時后端
許多游戲和移動服務都將事件流作為其基礎設施的支柱。使用場景包括用戶行為分析、基于位置的服務、支付、欺詐檢測、用戶/玩家留存率和用戶黏度的處理。游戲和移動服務領域幾乎所有的應用都需要大規模的實時數據流。
例如：
- 移動服務：優步、Lyft、FREE NOW、Grab、Otonomo和Here Technologies
- 游戲服務：迪士尼+Hotstar、索尼Playstation、騰訊、大魚游戲
- 博彩服務：威廉山、天空博彩
一個有意思的現象是：并不是每家移動或游戲服務的廠商都在公開談論Kafka的使用，但幾乎每家都在尋找Kafka專家來開發和運營他們的平臺。
這些場景對安全性的要求與銀行核心平臺中的支付流程一樣高。遵守合規性和零數據丟失也是至關重要。因此利用Kafka多區域集群（例如跨越美國東部、中部和西部等地區的Kafka集群）實現了高可用性，即使在發生災難的情況下也不會出現停機和數據丟失。
游戲中的多區域Kafka集群示例
6、在車輛或物聯網設備中內嵌單獨Kafka實例
邊緣計算技術在日新月異的發展，出于低延遲、成本效率、網絡安全或沒有互聯網連接等原因的考量，某些場景需要在數據中心外的邊緣部署Kafka集群或實例。
邊緣的Kafka的例子包括：
- 在交通運輸過程中無法連接到中心服務器時（例如，街道上的卡車或圍繞船舶飛行的無人機），用于離線時存儲日志、傳感器數據和圖像。
- 車輛到周邊（V2X）通信場景，通過本地小型數據中心（如AWS Outposts）構建MQTT網關，適用于大面積、大量車輛或糟糕的網絡，或通過Kafka客戶端直連數百臺機器（如在智能工廠中）等。
- 線下移動服務，如將汽車基礎設施與地圖集成，或將推薦引擎與本地服務的合作伙伴集成(例如，10英里內出現的下一個麥當勞會提供優惠券)
皇家加勒比游輪一個成功案例。它經營著世界上四艘最大的游輪。截至2021年1月，該航線運營24艘船舶，另有6艘船舶在訂購中。皇家加勒比在邊緣側實現了最著名的Kafka場景之一。每艘游輪都有一個Kafka集群在本地運行，用于支付處理、用戶黏度、客戶推薦等業務。
Kafka邊緣部署要注意根據實際業務場景做出調整，這樣才能保證足夠的低時延性能。
Apache Kafka的擱淺區
首先要了解何時使用Kafka。才會搞明白什么場景下不適用Kafka。
在本節中，假設我們討論的是生產環境，而不是一些丑陋的變通方式，當你需要在全球范圍內部署和彈性伸縮、遵守合規性并保證業務性服務不會丟失數據時，情況就會發生變化。考慮到這一點，對于一些用例和問題來說，把Kafka排除在外是相對容易的：
1、Kafka不是完全實時的
實時一詞的定義很難。這通常是一個營銷術語。實時程序必須保證在指定的時間限制內做出響應。Kafka（以及在此上下文中使用的所有其他框架、產品和云服務）只是相對實時的，并且是為IT應用構建的。但是許多自動化控制和物聯網應用需要具有零延遲峰值的完全實時。
實時一詞的定義很難。這通常是一個營銷術語。實時程序必須保證在指定的時間限制內做出響應。Kafka（以及在此上下文中使用的所有其他框架、產品和云服務）只是相對實時的，并且是為IT應用構建的。但是許多自動化控制和物聯網應用需要具有零延遲峰值的完全實時。
Kafka是實時的，但不是完全實時的。相對實時通常用于以下應用：
- IT應用程序之間的點對點消息傳遞
- 從各種數據源到歸集到一個或多個數據接收器
- 數據處理和數據關聯（通常稱為事件流或事件流處理）
如果應用程序需要亞毫秒的延遲，那么Kafka不是合適的技術。例如，高頻交易通常通過專門構建的專有商業解決方案來實現。
請始終記住：在爭取最低延遲的比賽中，Kafka每次都會輸，最低延遲的最佳方案是根本不使用消息傳遞系統，而是只使用共享內存。然而，對于審計日志和業務日志或持久化引擎的交換部分來說，沒有什么數據丟失比延遲和Kafka的勝利更重要。實際上大多數實時場景只需要毫秒到秒范圍內的數據處理。在這種情況下，Kafka是一個完美的解決方案。許多金融科技公司，如羅賓漢，依賴Kafka完成關鍵任務的業務工作，甚至是金融交易。多接入邊緣計算（MEC）則是通過Apache Kafka和云原生5G基礎設施構建的低延遲數據流的另一個優秀示例。
2、Kafka對于嵌入式和安全關鍵型系統來說是不確定的
需要明確的是，Kafka不是一個確定性系統。不能用于汽車發動機控制系統、醫療系統（如心臟起搏器）或工業過程控制器等安全關鍵型應用程序。
Kafka不適用的典型場景如下：
- 汽車或車輛中的安全關鍵數據處理，包括Autosar/MINRA/Assembler和類似技術
- ECU之間的CAN總線通信
- 機器人技術：C/C++或類似的低級語言，與工業ROS（機器人操作系統）等框架相結合
- 安全關鍵機器學習/深度學習（例如，用于自動駕駛）
- 車對車（V2V）通信：5G sidelink不能使用類似Kafka的轉發。
安全相關數據處理并非Kafka能勝任的，必須使用專用的低級編程語言和解決方案來實現。同樣，類Kafka 的軟件如IBM MQ、Flink、Spark、Snowflake也不適用。
3、Kafka不是為不穩定的網絡而建
Kafka需要客戶端和實例之間良好穩定的網絡連接。因此，如果網絡不穩定，導致客戶端需要不停地嘗試重新連接，那么這種情況往往很難達到預先設定的SLA。
也有一些例外，例如通過其他技術來解決不良網絡問題而構建的。MQTT是最典型的例子。因此，Kafka和MQTT是朋友，而不是敵人。這種組合功能強大，在各個行業中廣泛使用。因此，我寫了一系列關于Kafka和MQTT的Blog。
例如我們使用MQTT、Kafka和TensorFlow構建了一個Kappa架構的汽車連接基礎設施，用于處理100000個數據流以進行實時預測。
4、Kafka不提供與成千上萬個客戶端的連接
將Kafka定義為集成解決方案的另一個具體點是，Kafka無法連接到數萬個客戶端。如果您需要為移動玩家構建互聯汽車基礎設施或游戲平臺，客戶端（即汽車或智能手機）將通過一個集成了Kafka 的解決方案連接，而不會直接連接到Kafka。
一般來說在數千個客戶端和Kafka之間加入一個專用代理（如HTTP網關或MQTT代理）負責客戶端和Kafka的連接，而數據最終會被Kafka集成到數據倉庫，數據湖或者自定義后端應用中。
Kafka客戶端連接的限制在哪里? 通常情況下，這很難說。 我看到客戶通過.net直接從工廠車間連接，通過Java Kafka客戶端直接連接到運行Kafka集群的云。 如果機器plc、物聯網網關和物聯網設備的數量在數百臺，直接混合連接通常會工作得很好。 對于更多的客戶端應用程序，開發者需要針對以下問題來進行評估:
- 中間是否需要一個代理
- 在邊緣及項目是否需要部署Kafka，以降低延遲和并提高經濟消息
什么時候有可能使用Apache Kafka？
這里探討一下哪些場景中Kafka是可選的選擇：
1、Kafka（通常）不會替換另一個數據庫
Apache Kafka本身是一個提供了ACID保證，并被數百家公司用于任務關鍵型部署的數據庫。然而大多數情況下Kafka與其他數據庫相比并沒有競爭力。Kafka是一個事件流平臺，用于實時大規模的消息傳遞、存儲、處理和集成，并保證無停機時間或無數據丟失。
Kafka通常被用作流式數據集成層。然后根據應用場景選擇其他數據庫作為實體視圖，如實時時序分析、近似實時的將文本導入搜索基礎設施、通過數據湖進行數據的長期存儲。
總之，當你被問及Kafka是否可以取代數據庫時，可以進行如下的回答：
- Kafka可以以持久和高可用性的方式永久存儲數據，提供ACID保證。
- Kafka提供了多種方式查詢歷史數據。
- Kafka原生的插件，如ksqlDB或分級存儲，為Kafka提供了強大的數據處理和基于事件的長期存儲能力。
- 無需其他外部數據庫，即可利用Kafka構建有狀態應用程序。
- 不能替代現有的數據庫、數據倉庫或數據湖，比如MySQL、MongoDB、Elasticsearch、Hadoop、Snowflake、谷歌BigQuery等。
- 其他類型數據庫往往和Kafka相輔相成，通常創建和更新實體視圖的實時數據往往來源于事件中心。
- Kafka和數據庫之間數據同步，有基于雙向拉和推集成有不同的選項，可以相互補充。
2、Kafka（通常）不處理大型消息
Kafka不是為大型信息而設計的。
但是越來越多的項目通過Kafka發送和處理1MB、10MB甚至更大的文件或其他的大消息體。一個原因是Kafka是為大容量/吞吐量設計的，這是大消息所需要的。經常出現的一個非常常見的用法是，使用Kafka從遺留系統中提取和處理大文件。并處理過的數據存入數據倉庫。然而并不是所有的大消息都適合用Kafka處理。一般來說您應該使用正確的存儲系統，僅僅利用Kafka進行編排。基于引用的消息傳遞（即將文件存儲在存儲系統中并只發送鏈接和元數據）通常是更好的設計模式：
了解不同的設計模式，并為選擇正確的技術。
有關使用Kafka處理大型文件的更多詳細信息和場景，請參閱以下博客文章：《使用Apache Kafka處理大型消息（CSV、XML、圖像、視頻、音頻、文件）》。
3、Kafka（通常）不作為物聯網工業協議的最后一公里集成網
物聯網設備和移動應用程序的最后一公里集成是一個棘手的問題。如上所述，Kafka無法連接到數千個客戶端。然而，許多物聯網和移動應用只有數十或數百個客戶端。在這種情況下，就可以使用世界上幾乎任何編程語言的都提供支持各種Kafka客戶端，直連到Kafka實例。
如果出現了無法在TCP協議層面上建立到Kafka服務端的連接的情況下。一個非常流行的解決方案是通過REST代理作為客戶端和Kafka集群之間的代理。客戶端通過同步HTTP(S)協議與REST代理通信。Apache Kafka的HTTP和REST API場景包括控制平面（=管理）、數據平面（=生成和消費消息）和DevOps自動化任務。
不幸的是，許多物聯網項目需要更復雜的集成。這里不能只討論通過MQTT或OPC-UA連接器進行的相對簡單的集成。工業物聯網項目面臨的挑戰包括:
- 自動化行業通常不使用開放標準，而是使用速度慢、不安全、不可擴展的專有標準。
- 產品的生命周期非常長(幾十年)，沒有簡單的更改或升級的方法。
- 物聯網常使用不兼容的協議，通常為一個特定的供應商專用。
- 不可伸縮且不可擴展，專有且昂貴的龐然大物。
因此，許多物聯網項目用一個專門構建的物聯網平臺來補充Kafka。大多數物聯網產品和云服務是專有的，但提供開放的接口和架構。在這個行業中開源的項目相對較少。一個很好的方案(對于某些場景)是Apache PLC4X。該框架集成了許多遺留專有的協議，如Siemens S7、Modbus、Allen Bradley、Beckhoff ADS等。PLC4X還提供了一個Kafka Connect連接器，用于本地和可擴展的Kafka集成。
現代數據記錄系統是開放和靈活的。許多基于混合云的現代化物聯網項目是由事件流驅動的：
4、Kafka與區塊鏈
Kafka不是區塊鏈（但與web3、加密交易、NFT、鏈外、側鏈、預言機相關）。
Kafka是一個分布式日志提交系統。這些概念和基礎非常類似于區塊鏈。對于大多數企業項目，區塊鏈會增加不必要的復雜性。這種情況下用一個分布式提交日志(= Kafka)或一個防篡改分布式賬本(= enhanced Kafka)就足夠了。只有當不同的不受信任方需要協作時，才應使用區塊鏈。
有趣的是，越來越多的公司在其加密交易平臺、市場交易所和代幣交易市場中使用Kafka。
需要明確的是:Kafka并不用于構成這些平臺上的區塊鏈。區塊鏈是一種像比特幣一樣的加密貨幣，或者像以太坊一樣提供智能合約的平臺，人們可以在那里為游戲或藝術行業構建新的分布式應用程序(dApps)，如NFT。Kafka是將這些區塊鏈與其他預言機(=非區塊鏈應用)連接起來的流平臺，如CRM，數據湖，數據倉庫等。
TokenAnalyst是一個典型的例子，它用Kafka把比特幣/以太坊的區塊鏈數據和他們的分析工具集成起來。Kafka Streams提供了一個有狀態的流式應用程序來防止在下游聚合計算中使用無效塊。例如，TokenAnalyst開發了一個塊確認器組件，該組件通過臨時保留塊來解決重組場景，并僅在達到大量確認(挖掘該塊的子塊)的閾值時進行傳播。
在一些高級場景中，Kafka用于實現邊鏈或鏈外平臺，因為原始區塊鏈的擴展性不夠好（區塊鏈稱為鏈上數據）。并非只有比特幣存在每秒只處理個位數交易的問題（！）。大多數現代區塊鏈解決方案的性能沒有辦法擴展到Kafka的處理速度。
無論是去中心化自治組織還是藍籌公司，在分布式網絡中衡量區塊鏈基礎設施和物聯網組件的健康狀況，避免停機，確保基礎設施的安全，并使區塊鏈數據可訪問都是非常必要的。Kafka提供了一種無代理和可擴展的方式來展示數據給相關各方，并確保在節點丟失之前，相關數據被公開給正確的團隊。這與最前沿的Web3物聯網項目(如Helium)或更簡單的封閉分布式賬本(DLT)(如R3 Corda)有關。
我最近發表了一篇關于活動流媒體和Kafka改變零售元世界的實時商業的文章，展示了零售和游戲行業是如何連接虛擬和實體事物的。零售業務流程和客戶溝通是實時發生的;無論你是想賣衣服、智能手機還是為你的收藏品或視頻游戲出售基于區塊鏈的NFT代幣。
寫在最后
小結一下，Kafka不能取代數據庫或數據倉庫，也不適用于完全實時性的安全關鍵性嵌入式業務、不穩定網絡中數千個客戶端的代理、API管理解決方案、物聯網網關，也更不等同于區塊鏈。
對于某些場景和需求，很容易將Kafka排除。
然而，幾乎所有行業的分析和業務工作都使用Kafka。它是無處不在的事件流的事實標準。因此Kafka經常與其他技術結合使用。
原文鏈接：https://dzone.com/articles/when-not-to-use-apache-kafka
譯者介紹
吉鍇，51CTO社區編輯，18年軟件開發經驗。現在阿里云全球培訓中心任講師，負責云計算，云原生，數字化轉型等領域的課程設計，交付。先后于富士通，聯想集團，歡聚時代，搜狗任職，手機YY首任架構師。2014年開始從事專業技術培訓和顧問工作。
