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

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

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

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

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

什么是“邊緣”或“邊緣計(jì)算”?

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

邊緣的Apache Kafka

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

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

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

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

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

邊緣處Kafka的用例

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

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

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

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

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

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

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

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

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

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

通過(guò)三個(gè)以上的Kafka Broker在邊緣實(shí)現(xiàn)彈性部署

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

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

通過(guò)一個(gè)Kafka Broker在邊緣實(shí)現(xiàn)非彈性部署

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

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

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

移除ZooKeeper將有助于邊緣處Kafka

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

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

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

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

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

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

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

為了簡(jiǎn)化安裝和操作邊緣處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)品盒子。它能夠簡(jiǎn)化并自動(dòng)化邊緣處Kafka環(huán)境中的各項(xiàng)操作。用戶只需將一個(gè)或多個(gè)產(chǎn)品盒子運(yùn)到邊緣站點(diǎn)。在將其連接到本地WiFi之后，其他所有的操作都可以在遠(yuǎn)程進(jìn)行實(shí)現(xiàn)。該公司甚至號(hào)稱：能夠讓客戶不再需要技術(shù)人員，即可在邊緣部署和維護(hù)軟件。

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

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

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

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

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

混合架構(gòu)

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

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

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

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

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

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

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

總結(jié)

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

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

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