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