【51CTO.com快譯】在邊緣技術(shù)領(lǐng)域，那些從事制造業(yè)、自動化行業(yè)、航空、物流、以及零售等行業(yè)應(yīng)用的開發(fā)人員經(jīng)常會思考的一個問題是：到底應(yīng)該在邊緣處，還是應(yīng)該在“真實”的數(shù)據(jù)中心、或是在公共云基礎(chǔ)架構(gòu)中部署Apache Kafka?

在本文中，我們將向邊緣計算領(lǐng)域的開發(fā)者介紹Kafka在物聯(lián)網(wǎng)(IoT)邊緣處的不同用例和架構(gòu)用法。文末，我們還會討論Kafka作為事件流平臺，是如何在邊緣處對其他IoT框架及產(chǎn)品進行補充，進而實現(xiàn)大規(guī)模的實時數(shù)據(jù)集成與邊緣處理。

常態(tài)化的多個Kafka群集

如今，Apache Kafka的多集群和跨數(shù)據(jù)中心的部署方式，已成為了業(yè)界的某種規(guī)范。雖然“邊緣處Kafka(Kafka at the edge)”可以被部署為一個獨立的項目；但是在大多數(shù)情況下，它處于整個Kafka架構(gòu)中的一部分。許多企業(yè)會根據(jù)如下原因，來創(chuàng)建多個Kafka集群：

• 獨立的項目需求。
• 混合式的集成方法。
• 邊緣計算。
• 組件聚合。
• 平臺移植。
• 災(zāi)難恢復(fù)。
• 區(qū)域或洲際通信所需的全球架構(gòu)。
• 跨企業(yè)之間的溝通。

什么是“邊緣”或“邊緣計算”?

在考慮部署邊緣處Kafka之前，讓我們先來了解一下與“邊緣技術(shù)”相關(guān)的定義。維基百科上說：“邊緣計算是一種分布式的計算范式。它通過讓計算本身和數(shù)據(jù)存儲更加靠近所需的位置，從而縮短了響應(yīng)的時間并節(jié)省了帶寬”。同時，它的其他優(yōu)勢還包括：降低成本，提高系統(tǒng)的靈活性，以及分離關(guān)注點。

邊緣的Apache Kafka

目前，業(yè)界對如何將Kafka應(yīng)用于邊緣計算有著不同的見解，其中包括：

• 僅在邊緣客戶端：Kafka客戶端運行在邊緣處;而Kafka集群則被部署在數(shù)據(jù)中心或公共云的環(huán)境中。
• 一切都在邊緣：將Kafka集群和Kafka客戶端都部署在邊緣處(例如工廠里的各種傳感器上)。
• 邊緣與遠端：Kafka集群被部署在邊緣;而Kafka客戶端(例如該地區(qū)的智能手機)則運行在接近邊緣處。

可見，邊緣處Kafka具有比較靈活且廣泛的使用范圍，其中包括：

• 工業(yè)物聯(lián)網(wǎng)(Industrial Internet of Things，IIoT)車間邊緣處的Kafka客戶端可以由C語言來編寫，并部署到傳感器的微控制器中。此類傳感器通常只有幾千個字節(jié)的內(nèi)存，而且可以“服役”一定的年限。
• 在電信業(yè)務(wù)中邊緣處，完整的分布式Kafka集群，可以運行在StarlingX上(https://www.starlingx.io/)。StarlingX是一個基于Kubernetes的開源私有云架構(gòu)棧，可被用于IIoT、電信、視頻交付、以及其他具有超低延遲等苛刻要求的應(yīng)用邊緣環(huán)境中。
• 通過部署，銜接傳統(tǒng)銀行或保險公司的核心硬件與邊緣硬件。

可見，在大多數(shù)情況下，邊緣處Kafka就是指：部署在系統(tǒng)邊緣處的Kafka集群。而對應(yīng)的Kafka客戶端程序既可以在本地運行，也可以在附近運行。當(dāng)然在某些情況下，“附近”可能在指幾英里開外。

邊緣處Kafka的用例

下面，我們來討論一下邊緣處Kafka在許多不同企業(yè)中的運行用例。

• 工業(yè)物聯(lián)網(wǎng)：實時邊緣集成與處理，是現(xiàn)代物聯(lián)網(wǎng)架構(gòu)成功的關(guān)鍵。在工業(yè)4.0中，此類用例比比皆是，包括：預(yù)測性維護、質(zhì)量保證、流程優(yōu)化、以及網(wǎng)絡(luò)安全等方面。其中使用Kafka來構(gòu)建數(shù)字孿生(Digital Twin，譯者注：在虛擬空間中仿真、映射并反映對應(yīng)的實體設(shè)備的整個生命周期過程)就是最常見的場景之一。
• 零售：無論是沃爾瑪這樣的零售商，還是星巴克之類的咖啡店，抑或亞馬遜Go之流的潮店，數(shù)字化轉(zhuǎn)型都會帶來許多方面的創(chuàng)新。其中包括：客戶的360度體驗，商家與消費者之間的交叉銷售，以及與其他合作供應(yīng)商的協(xié)作等方面。
• 物流：大規(guī)模的實時數(shù)據(jù)關(guān)聯(lián)，是改變?nèi)魏挝锪鲌鼍暗年P(guān)鍵元素。其中包括：端到端的包裹跟蹤和交付，無人機(或自動駕駛)與本地自助服務(wù)站的通信，物流中心的加速處理，共享汽車的協(xié)調(diào)和計劃，以及智慧城市中的交通信號燈管理等方面。

無論是上述哪種用例，邊緣處Kafka的通用架構(gòu)都會如下圖所示：

邊緣計算的挑戰(zhàn)

在企業(yè)試圖將各種創(chuàng)新的實時應(yīng)用引入工廠、零售店、咖啡店等場景，并將數(shù)據(jù)分發(fā)到邊緣站點時，往往會遇到如下的挑戰(zhàn)：

• 由于不良的網(wǎng)絡(luò)狀態(tài)和許多其他方面的限制，邊緣處的各種硬件、機器、以及設(shè)備難以順暢實現(xiàn)集成。
• 許多用例都要求進行大規(guī)模的、且實時的處理。而這些處理都必須在現(xiàn)場邊緣處實施，而不是在遠端的數(shù)據(jù)中心、或幾百英里開外的云端進行。
• 各種技術(shù)和協(xié)議都必須在邊緣處集成。而且各種傳統(tǒng)或?qū)Ｓ械膮f(xié)議，必須通過隧道，與另一端的大數(shù)據(jù)工具進行通信。
• 有限的硬件資源與人員。鑒于成本的考慮，IT專家無法到達每一個邊緣站點，進行硬件的運維。
• 各種數(shù)據(jù)必須大規(guī)模地在本地進行實時存儲和處理。同時，這些數(shù)據(jù)需要被復(fù)制到數(shù)據(jù)中心或云端，以便進一步匯總、處理與分析。另外，為了實現(xiàn)由單一節(jié)點以發(fā)送命令或事件的方式控制各個邊緣站點，各種通信最好是雙向的。

用于邊緣計算的Kafka架構(gòu)

在開始討論有哪些邊緣處Kafka的部署方案之前，我們需要事先搞清楚的一個問題是：到底是否需要高可用性的邊緣架構(gòu)。

其實，邊緣計算并不一定需要具有高可用性。如果您的確需要的話，就請部署傳統(tǒng)的Kafka集群;而如果不需要的話，則只需在邊緣處設(shè)置一個簡單、且低成本的Kafka Broker即可。而且如果需要在上百個站點進行部署的話，那么現(xiàn)成的硬件設(shè)備會更加容易實現(xiàn)。

下圖展示了三個邊緣站點。每個站點上都部署了一個Kafka集群，而每個集群里都包括有不同的Kafka組件。

通過三個以上的Kafka Broker在邊緣實現(xiàn)彈性部署

Kafka及其生態(tài)系統(tǒng)旨在確保即使某一單個節(jié)點發(fā)生故障，也能實現(xiàn)系統(tǒng)的高可用性和零停機時間。如下圖所示，為了部署一套分布式的系統(tǒng)，您至少需要三個Kafka節(jié)點和三個Zookeeper節(jié)點。而其他組件則需要至少兩個節(jié)點，才能確保操作的可靠性和數(shù)據(jù)的防丟失。

您可以參考《Apache Kafka與Confluent平臺參考架構(gòu)》一文，以了解部署的最佳實踐。當(dāng)然，由于流量負(fù)載和吞吐量通常在邊緣處都比較低，因此如果SLA允許的話，較少的內(nèi)存與磁盤空間也就足夠了。

通過一個Kafka Broker在邊緣實現(xiàn)非彈性部署

如今，在邊緣處部署“輕量級的Kafka群集”，然后與更大的中央Kafka群集同步或復(fù)制數(shù)據(jù)的需求已日益增多。不過，由于硬件本身的限制、以及SLA對于高可用性的要求并不高，因此在邊緣處僅部署一個Kafka Broker加上一個Zookeeper即可。如下圖所示，您甚至可以將整個Kafka的環(huán)境只部署在一臺服務(wù)器上。

不過，該部署方案存在著一個明顯的缺陷：由于沒有數(shù)據(jù)之間的復(fù)制，當(dāng)該節(jié)點或網(wǎng)絡(luò)出現(xiàn)故障而造成停機時，您的數(shù)據(jù)就有丟失的風(fēng)險。當(dāng)然，此類單節(jié)點式的Kafka部署方案仍具有如下方面的優(yōu)勢：

• 實現(xiàn)了producers與consumers之間的解耦。
• 能夠有效地處理背壓(back-pressure)。
• 即使只有一個Broker，也能實現(xiàn)實時地處理大容量數(shù)據(jù)。
• 在磁盤上進行存儲。
• 能夠重新處理數(shù)據(jù)。
• Kafka Connect可用于集成，Kafka Streams或ksqlDB可用于流處理，Schema Registry可用于管理，真可謂Kafka本地組件的“全家桶”。

移除ZooKeeper將有助于邊緣處Kafka

和諸如Hadoop、Spark等其他分布式系統(tǒng)類似，由于過分依賴于ZooKeeper，因此Kafka不但在操作上有一定的難度，而且擴展性也比較差。那么對于大多數(shù)物聯(lián)網(wǎng)項目而言，由于整體部署的耗時較長，我們建議您通過移除ZooKeeper，而使得Kafka更輕量級，更易于操作。

將Kafka作為邊緣設(shè)備和云服務(wù)之間的網(wǎng)關(guān)

在某些配置中，您可能希望邊緣設(shè)備與本地的網(wǎng)關(guān)進行通信。此時，您就可以使用網(wǎng)關(guān)式的Kafka架構(gòu)方案。例如，在工廠中，多臺機器或生產(chǎn)線被視為邊緣設(shè)備。它們需要與各自的Kafka群集相集成，實現(xiàn)將數(shù)據(jù)發(fā)送給作為網(wǎng)關(guān)的Kafka群集。據(jù)此，在Kafka集群網(wǎng)關(guān)上，您可以直接在本地進行分析，通過過濾或轉(zhuǎn)換數(shù)據(jù)，最終發(fā)送并聚合到遠程大型的Kafka集群中。

如上圖所示：首先，兩個獨立的工廠分別在各處部署了非彈性的單一Kafka Broker，以實現(xiàn)數(shù)據(jù)的本地處理。然后，由一個彈性Kafka群集網(wǎng)關(guān)聚合三個Kafka Broker，并在工廠的本地處理各項數(shù)據(jù)。接著，只有那些重要、且經(jīng)過預(yù)處理的數(shù)據(jù)才會被轉(zhuǎn)發(fā)到遠程的Kafka群集中(在圖中體現(xiàn)為Confluent Cloud)。最終，該云中的Kafka集群聚集了來自不同工廠的數(shù)據(jù)，以便與其他業(yè)務(wù)應(yīng)用或分析工具相集成。

邊緣處Kafka作為OEM或硬件組件

企業(yè)在邊緣處安裝硬件，會比在本地數(shù)據(jù)中心、或公共云端要復(fù)雜且麻煩得多。如果我們在邊緣處采用標(biāo)準(zhǔn)化的Kafka組件安裝方法，則會大幅減少工作量與潛在的風(fēng)險。

目前，已有數(shù)十家硬件供應(yīng)商可以協(xié)助您構(gòu)建OEM的硬件設(shè)備。當(dāng)然，您也可以通過遠程管理并使用某些DevOps工具，來安裝所有必需的軟件組件。

為了簡化安裝和操作邊緣處Kafka集群，以Hivecell(https://hivecell.io/)為代表，公司推出了預(yù)裝有Kubernetes、Kafka生態(tài)系統(tǒng)、Confluent Operator(https://www.confluent.io/confluent-operator/)工具、以及其他業(yè)務(wù)應(yīng)用的產(chǎn)品盒子。它能夠簡化并自動化邊緣處Kafka環(huán)境中的各項操作。用戶只需將一個或多個產(chǎn)品盒子運到邊緣站點。在將其連接到本地WiFi之后，其他所有的操作都可以在遠程進行實現(xiàn)。該公司甚至號稱：能夠讓客戶不再需要技術(shù)人員，即可在邊緣部署和維護軟件。

通信、連接、集成、數(shù)據(jù)處理

正如上述各圖所展示的那樣，Kafka的環(huán)境中并不僅僅包括了Kafka Broker與Zookeeper。無論是在云端、本地、還是在邊緣處，通信、連接、集成、以及數(shù)據(jù)處理都是Kafka基礎(chǔ)架構(gòu)中的重要組件。

具體而言，在Kafka Broker與Kafka客戶端之間，從邊緣處到遠程的通信流程為：設(shè)備->邊緣處Kafka->復(fù)制->數(shù)據(jù)中心與云端的Kafka群集->數(shù)據(jù)分析與實時處理。通常，此類通信是雙向的。那么對于Kafka原生的各個組件而言，您只需要管理一個Kafak的后臺，即可進行大規(guī)模的實時通信、集成和數(shù)據(jù)處理。其中涉及如下方面：

• Kafka Connect：包括MQTT(消息隊列遙測傳輸)、OPC-UA、FTP、CSV、PLC4X(一組傳統(tǒng)與專有IIoT協(xié)議，例如Modbus、Siemens S7、Beckhoff、Allen Bradley四種可編程序控制器，即PLC)。
• Mirror maker與Confluent Replicator：實現(xiàn)兩個Kafka群集之間的單向或雙向復(fù)制。
• Kafka客戶端(Producers/Consumers)：支持Java、Python、C++、C、Go、Javascript等語言。
• 數(shù)據(jù)處理：使用Kafka Streams或ksqlDB進行流處理(包括無狀態(tài)流的ETL和其他有狀態(tài)的應(yīng)用)。
• 代理：使用REST proxy進行HTTP(S)通信，使用MQTT proxy進行MQTT集成。
• 架構(gòu)注冊表：負(fù)責(zé)治理與模式的實施。

可見，由于邊緣處硬件資源的受限，我們應(yīng)當(dāng)在開始時就規(guī)劃好整體架構(gòu)和數(shù)據(jù)通信，讓Kafka全棧能夠真正滿足邊緣的需求。

混合架構(gòu)

物聯(lián)網(wǎng)的實際需求往往是五花八門的。面對24小時/7天的實時部署，零數(shù)據(jù)量的丟失，以及無延遲的實時處理，我們光靠Kafka架構(gòu)有時會力不從心。此時，我們就需要結(jié)合使用其他的IoT框架或方案，來實現(xiàn)與Kafka的端到端集成。

如上圖所示，我們可以在工廠車間里使用西門子的MindSphere(這是一種功能強大，適用范圍廣泛，但也復(fù)雜且昂貴的物聯(lián)網(wǎng)解決方案)，來作為網(wǎng)關(guān)或代理。當(dāng)然，我們可以將HiveMQ(譯者注：一種企業(yè)級的MQTT Broker)部署為可擴展的MQTT集群，以連接到機器和設(shè)備。

在某些情況下，Kafka也可以被直接用作IoT的網(wǎng)關(guān)或代理，以連接PLC或分布式控制系統(tǒng)(Distributed Control System，DCS)。同時，Kafka也可連接諸如AWS IoT或谷歌云的MQTT Bridge等IoT解決方案，實現(xiàn)進一步的處理和分析。

由于數(shù)據(jù)通信往往是雙向的，因此無論您選擇哪一種架構(gòu)，都必須能夠從車間或其他IoT設(shè)備中提取數(shù)據(jù)，通過實時的處理與關(guān)聯(lián)，最后將控制類事件發(fā)回給機器。例如：在預(yù)測分析中，您首先需要使用TensorFlow之類的云端工具訓(xùn)練分析模型，然后才能在邊緣處部署分析模型，以進行實時預(yù)測。

可見，通過與其他物聯(lián)網(wǎng)框架或解決方案的結(jié)合，Kafka生態(tài)系統(tǒng)不但得到了有效的補足，而且各自都能夠?qū)Ｗ⒂诓煌墓δ苡美?。例如：Kafka可專注于設(shè)備管理，模型訓(xùn)練。主流的云提供商能夠為設(shè)備管理提供IoT服務(wù)、云端代理、以及分析工具。而開源的框架Eclipse則可以用于構(gòu)建數(shù)字孿生。

慎用過多的分布式系統(tǒng)組合

當(dāng)然，如果您想為邊緣計算和混合架構(gòu)構(gòu)建可擴展的、可靠的流式結(jié)構(gòu)，并且達到不會造成任何宕機或數(shù)據(jù)丟失的效果，這實際上很難在集成了多種中間件工具的環(huán)境中實現(xiàn)。也就是說：參與組合的工具越多，服務(wù)中斷或數(shù)據(jù)丟失的風(fēng)險也就越高。例如：NiFi(譯者注：Apache的NiFi項目是一種實時數(shù)據(jù)流處理系統(tǒng))有著自己的分布式基礎(chǔ)架構(gòu)，那么您必須保證從producer通過NiFi和Kafka能夠最終到達consumer，這整個過程都具有24小時/7天的端到端正常運行時間。同理，諸如Kafka Connect和Kafka Streams之類的原生工具，使用Kafka Topic在后臺提供高可用性時，您也需要保障此類24小時/7天的無宕機或數(shù)據(jù)丟失。因此，請慎用“傳感器ABC -> NiFi(捕獲) -> Kafka Topic A -> NiFi(轉(zhuǎn)換) -> Kafka Topic B -> NiFi(加載) -> 應(yīng)用程序XYZ”之類的管道架構(gòu)，來進行無數(shù)據(jù)丟失的大規(guī)模實時處理。

總結(jié)

邊緣計算往往只是整個體系結(jié)構(gòu)的一部分，但是作為該領(lǐng)域的“黑馬”，邊緣處Kafka可以通過混合架構(gòu)的部署方式，提高數(shù)據(jù)的處理速度，降低網(wǎng)絡(luò)的傳輸成本，并且能給整個系統(tǒng)帶來更好可擴展性、可靠性和健壯性。

原文標(biāo)題：Apache Kafka Is the New Black at the Edge in IoT Projects，作者：Kai Wähner

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】