【51CTO.com快譯】如今，在IoT(物聯網)的邊緣處，使用Apache Kafka來進行事件流傳輸，已不再是什么高深的技術了。作為一種通用的方法，Kafka在邊緣處提供了與云端、以及數據中心，相同的開放、靈活且可擴展的架構。它是橫跨IoT和非IoT(如：傳統數據中心和云端基礎架構)的流式神經系統的基本組件。實際上，Kafka可以被部署在零售商店、手機信號塔、火車、小型工廠、以及飯店等各種邊緣位置。

本文將重點向您介紹Kafka客戶和Kafka代理(brokers)在跨行業邊緣處的用例與架構，其中包括邊緣的處理、集成、去耦、低延遲、以及經濟高效的數據處理。

Kafka在邊緣的類別和體系架構

大多數物聯網項目的構建，都與在數據中心或云端的普通Kafka項目有著本質的區別。它們無法提供可靠的Kafka集群，以及在云端建立穩定的網絡連接，而具有如下的邊緣功能：

• 由于沒有與中央數據中心、或云端的高可用性連接，因此不具備一些本地的預處理，低延遲的實時分析，低帶寬的斷續連接等，而離線式的業務連續就顯得非常重要。
• 項目通常需要在零售店、火車、飯店、手機信號塔、小型工廠等數百個地點部署Kafka代理。因此，單個代理雖然不需要高可用性，但是要能夠承受背壓(backpressure)，并提供本地的處理能力。
• Kafka代理(不僅是客戶端)需要低空間占用率，少接觸，以及盡量少的DevOps安裝必需性(即：幾乎沒有IT人員到現場運維Kafka)。因此，使用經過認證的OEM硬件，是在邊緣安裝和操控Kafka的絕佳選擇。
• 許多邊緣用例都會涉及到傳感器和遙測數據(telemetry data)。與不能丟失每條交易數據的電商系統不同，IoT應用場景允許在每秒處理數百萬條消息的應用中，丟失少量消息，而且不會影響到最終的計算結果。
• 混合云或非云：消費物聯網(Consumer IoT，CIoT)會涉及到智能家居、共享乘車、零售商店等環境，而工業物聯網(Industrial IoT，IIoT)則會涉及到汽車、食品、能源等生產場景。
• 通常包含了傳感器、主機、移動設備等成千上萬個連接接口。

邊緣處Kafka的用例

總的說來，Kafka在邊緣處的體系架構和部署場景會包括：數據集成，預處理，云端復制，邊緣大(小)數據的處理和分析，連接中斷時的脫機方案，具有數百個點位的極低硬件空間占用率方案，以及非高可用性的方案等。下面，我們來看幾個典型行業的應用：

• 公共服務部門：由政府行政機構牽頭的公共交通管理，來自不同汽車制造商的各種車聯網平臺的集成，圖像捕獲和處理，物聯網安全等智慧城市的項目。
• 運輸/物流/鐵路/航空：在列車上，Kafka可用于離線處理和本地存儲，航旅信息的Track&Trace(包括延遲或取消等信息的跟蹤)，實時的用戶忠誠度平臺(包括艙位的升級，休息室的使用權)。
• 汽車/航天/半導體/化工/食品等制造業：物聯網售后客戶服務，機器和車輛的OEM，嵌入式標準軟件(如：ERP或MES系統)，設備/機器/生產線的數字孿生/流程，以及通過監控工廠的生產線，執行預測性的維護，質量控制，儀表板/車間/外圍健康狀況的跟蹤等。
• 能源/公用事業/石油和天然氣：智能家居/建筑/電表，遠程設備的監控(如：鉆探機、風車或采礦機)，針對管道和煉油操作的預測性異常檢測與故障診斷。
• 電信/媒體：OSS(運營支撐系統)的實時監控，指標報告，問題分析，根本原因分析，網絡設備和基礎設施(如：路由器、交換機、及其他網絡設備)的響應，BSS(業務支撐系統)的客戶體驗，OTT服務(各種第三方移動應用的集成)，以及5G邊緣(如：街道上的傳感器)設備的狀態。
• 醫療保健：在醫院中實施追蹤，遠程監控，設備傳感器分析等。
• 零售/食品/餐廳/銀行業務：客戶溝通，交叉銷售，忠誠度分析，零售付款，庫存盤點，PoS機集成，遠程CRM集成，以及EFTPOS(銷售點的電子資金轉帳)。

我們曾經為一個零售快餐連鎖品牌--Chic-fil-A，部署了針對邊緣計算的相關服務。我們在其2000家餐廳中都部署了Kubernetes集群(請參見--https://www.infoq.com/presentations/chick-fil-a-k8-clusters/)，以便在沒有互聯網連接的情況下，仍然可以憑借著邊緣計算實現實時的分析(請參見--https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2)。下圖是他們的硬件邊緣設備，外觀體積非常小，內部配置了Intel四核處理器、8 GB RAM和SSD。

邊緣架構示例：運輸和物流行業的Kafka

讓我們通過一個鐵路公司的特定案例，來具體討論邊緣處的Kafka混合方案。該方案利用離線式邊緣處理，實現了客戶通信，云端復制分析，以及與第三方合作伙伴的接口和API相集成。雖然這是一個鐵路和運輸行業的例子，但是我們可以輕松地將其映射到其他的行業中。

混合架構—從邊緣到云端

設想，一列火車正在邊緣處對產生的信息進行局部處理。如果有互聯網連接和免費的網絡資源，那么這列火車會將相關的數據實時復制到云端。而如果火車在行進中失去網絡連接，那么Kafka將處理背壓，并在網絡連接恢復時將數據復制到云端。下圖是在邊緣和云端用到的Kafka混合架構：

Kafka在邊緣處的事件流

如下圖所示，火車在邊緣處使用Apache Kafka，實現對實時消息/事件流的傳遞和背壓處理。

在掉線/離線場景中使用Kafka

火車在駛過隧道或到達沒有網線連接的區域時，就會出現離線的情況。此時，我們需要火車上的邊緣設備仍然可以進行本地處理。畢竟，業務連續性是改善客戶體驗和增加銷售量的關鍵因素。即使火車處于離線，乘客仍然需要通過移動應用，來查看時刻表信息，在餐廳購買食物，或在火車的本地服務器上觀看電影。同時，一旦火車重建互聯網連接，乘客的購買交易將會被轉移到云端的用戶忠誠度系統中，需要查詢的最新消息也會從云端被傳遞(consume)過來，并存儲在火車的邊緣--Kafka代理處。下圖展示了Kafka在離線和斷開連接的模式下，如何在邊緣處進行數據處理。

跨公司的Kafka和邊緣整合

由于數據處理會在邊緣(如：火車)和云端系統(如：CRM、忠誠度系統等)之間的整合系統中持續發生，因此不同的合作伙伴也要進行此類整合。與通過非擴展性的同步REST API調用/API管理，進行合作伙伴間的整合相比，使用Kafka原生的事件流復制機制，是一種更好、更具可擴展性的方法。下圖展示了合作伙伴之間如何進行跨公司的Kafka復制與API管理。

在邊緣部署Kafka的基礎架構和硬件要求

下面我們來討論如何在邊緣處部署Kafka。注意，Kafka需要目標系統具有一定的計算能力。這取決于您正在使用的：硬件供應商、基礎架構、特定的SLA、以及高可用性要求等諸多因素。值得慶幸的是，Kafka可以被部署在包括裸金屬(bare metal)、虛擬機、容器、Kubernetes在內的許多基礎架構中。而當前廠商能夠生產的、可被用在邊緣處的最小芯片通常具有4GB、8GB、甚至16GB的RAM。

在實際應用中，運行Kafka所需的最低硬件配置為：單核處理器 + 幾個100MB的RAM。該配置已經能夠讓單個Kafka節點(復制因子 = 1)以超過100Mb/sec的吞吐量進行邊緣處理了。當然，實際數值也會取決于分區的數量、消息的大小、網絡的速度等各方面的因素。這與數據中心或云端的性能和可擴展性肯定是沒法比的。

所以說，您可以將Kafka代理部署在樹莓派(Raspberry Pi)上，但不能部署到小型嵌入式設備上，畢竟我們可以在設備上運行Kafka客戶端。

在邊緣處部署Kafka的“Confluent Way(融合方式)”

從技術角度來看，在邊緣處部署Kafka與在數據中心或云端比較類似，只是環境和要求有所不同。而且一些附加的功能還會方便我們部署和操作Kafka。下面，讓我們來了解一下Confluent部署方式的創新與差異化功能：

1. Confluent服務器包含了Kafka代理和各種增強型功能，其中包括：自平衡群集、分層存儲、嵌入式REST API、服務器端模式驗證等。它可以被部署為單個節點(非常輕便，但不具備高可用性)或群集模式(主要針對依賴于邊緣處高可用性的關鍵任務負載)。

2. 雖然目前該方式仍需要ZooKeeper作為附加組件，以實現協同工作，但是預計2021年將不再需要。屆時，它將是一個由Kafka支持的、獨立且單流程化的邊緣解決方案。

3. 群集鏈接(Cluster Linking，請參見--https://www.confluent.io/blog/kafka-cluster-linking-with-confluent-platform)允許所有小的Kafka邊緣站點使用Kafka協議，連接到數據中心或云端更大的Kafka群集中，而無需使用諸如Confluent Replicator或MirrorMaker等其他工具與架構。據此，開發人員可以大幅減少在基礎架構上的成本與工作量。

4. 使用Confluent的工具集，來進行監控和主動支持(Proactive Support，請參見--https://docs.confluent.io/5.4.0/proactive-support.html)。例如，一個控制中心可以監控幾個不同的遠程Kafka群集。受監控的目標不僅包括技術架構，還包括應用程序，以及端到端的集成。而Confluent Telemetry Reporter(請參見--https://docs.confluent.io/current/kafka/telemetry.html#what-data-is-sent-and-how-it-is-used)則會從邊緣站點收集相關的數據。

5. 目前，Kubernetes(MicroK8s Kubernetes發行版，請參見--https://microk8s.io/)正在成為許多邊緣部署的首選編排平臺。Confluent Operator恰好能以CRD(自定義資源定義，https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)的方式，提供了對邊緣處單一代理、或群集部署的滾動升級、以及安全自動化等操作功能。前文提到的Chic-fil-A其在2000多家快餐店中運行著Kubernetes(請參見--https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2)，并提供各項低延遲的邊緣服務，恰恰是Confluent Operator在Confluent Cloud和數據中心內Confluent Platform上進行大型實際部署的成功案例。當然，Kubernetes是按需選用的。有些邊緣處在使用了Kubernetes后，反而增加了復雜性，以及對于有限資源的耗費。

6. 由于數據集成和數據處理是邊緣計算的關鍵，Confluent提供了用于新舊系統的連接器，其中包括針對PLC、OPC-UA和IIoT集成的PLC4X(請參見--https://www.kai-waehner.de/blog/2019/09/02/apache-kafka-ksql-and-apache-plc4x-for-iiot-data-integration-and-processing/)、數據庫CDC的連接器、MQ與MQTT的集成、云端連接器、以及用于高安全性或“骯環境”中的單向UDP網絡的Data Diode連接器(請參見--https://docs.confluent.io/current/connect/kafka-connect-data-diode/index.html)。當然，Kafka Streams和ksqlDB則允許輕量級且功能強大的事件流處理。

7. 輕量級邊緣客戶端(如：嵌入式設備)可以利用Kafka和REST代理的C與C++客戶端上的API(請參見--https://github.com/edenhill/librdkafka)，通過HTTP(S)與任何編程語言進行通信。這對于許多計算能力有限的低功率邊緣設備來說是非常重要的。畢竟，我們在這些設備中無法部署Java、或類似的“資源密集型(resource-hungry)技術”。

8. 您也可以選擇將已認證的、預配置的OEM硬件放置在邊緣處，將其連接到LAN或WiFi上，然后使用由硬件商提供的遠程軟件，對基礎架構進行管理和監控。“在Hivecell上進行可行性處理”的視頻(請參見--https://medium.com/hivecell/feasible-video-processing-on-hivecell-a28f9a059ccf)展示了如何通過Kafka集群、Kafka Streams應用、以及用于圖像識別的嵌入式機器學習模型，進行邊緣分析。

小結

作為絕佳的邊緣解決方案，Kafka使您能夠在邊緣處、數據中心和云端，部署同樣開放、可靠、且可擴展的技術。希望上述介紹的有關邊緣處Kafka的用例與架構，能夠幫助您更好地了解如何在各個行業中，利用事件流和工具來構建從邊緣到云端的物聯網架構。

原文標題：Kafka at the Edge — Use Cases and Architectures，作者：Kai Wähner

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