Apache Kafka是一個實時流平臺，在大大小小的組織中得到了廣泛的采用。Kafka的分布式微服務架構和發布/訂閱協議使得它非常適合在企業系統和應用程序之間實時移動數據。據統計，超過三分之一的財富500強公司正在使用Kafka。在Github上，Kafka是最受歡迎的Apache項目之一，有超過11K之星和超過500名貢獻者。毫無疑問，Kafka是一個開源項目，它改變了企業在云和數據中心內移動數據的方式。

Kafka的架構已經被優化為在系統和應用程序之間以可伸縮的方式盡可能快地流數據。Kafka客戶端/生產者與Kafka集群緊密耦合，要求每個客戶端知道Kafka集群的IP地址，并直接訪問所有單獨的節點。在可信網絡內部，這允許對代理拓撲進行更改，這意味著可以通過直接使用來自Kafka客戶端的多個節點來擴展主題和分區。在大多數情況下，Kafka主題空間也保持相當扁平，因為通常使用多個分區來擴展單個Kafka主題。在Kafka系統中擁有數百甚至數千個主題通常是不可取的，首選的方法是對大多數數據流使用很少的主題。Kafka非常適合在具有穩定IP地址和連接的相同可信網絡內的系統之間進行通信。

對于設備連接到公共互聯網上的數據中心或云的物聯網用例，Kafka架構不適合開箱即用。如果您試圖在Internet上使用Kafka從數千甚至數百萬設備流數據，那么Apache Kafka架構是不合適的。有許多原因Kafka本身不是很適合物聯網用例：

Kafka代理需要由客戶端直接處理，這意味著每個客戶端需要能夠直接連接到Kafka代理。專業的IoT部署通常利用負載均衡器作為云中的第一道防線，因此設備只使用負載均衡器的IP地址連接到基礎設施，負載均衡器有效地充當代理。如果您希望您的設備直接連接到Kafka，您的Kafka代理必須暴露給公共互聯網。Kafka不支持大量的主題。當通過公共Internet連接數以百萬計的物聯網設備時，通常使用單個和唯一的主題（通常在主題名稱中包含一些唯一的物聯網設備標識符），因此可以根據單個客戶機的權限限制讀寫操作。你不希望你的智能恒溫器被黑客攻擊，那些證書可能被用來竊聽系統中的所有數據流。與物聯網協議的客戶端庫相比，Kafka客戶端是相當復雜和資源密集型的。大多數編程語言的Kafka api都非常直接和簡單，但是在其內部存在很多復雜性。例如，客戶端將使用并維護到Kafka代理的多個TCP連接。物聯網的部署通常會限制設備的使用，這些設備需要最小的內存占用，并且在設備端不需要很高的吞吐量。默認情況下，Kafka客戶端針對吞吐量進行了優化。Kafka客戶端需要一個穩定的TCP連接來獲得最好的結果。許多物聯網使用案例涉及不可靠的網絡，例如聯網的汽車或智能農業，因此典型的物聯網設備需要不斷地重新建立與Kafka的連接。將數萬甚至數百萬客戶機連接到一個Kafka集群是不尋常的（通常甚至根本不可能）。在物聯網使用案例中，通常有大量設備同時連接到后端，并不斷產生數據。Kafka缺少一些關鍵的物聯網功能。Kafka協議缺少了諸如《活著》和《遺囑》等功能。這些特性對于構建一個有彈性的物聯網解決方案非常重要，該解決方案可以處理遇到意外連接丟失和網絡不可靠的設備。

Kafka仍然為物聯網用例帶來了很多價值。物聯網解決方案創建了大量的實時數據，很適合由Kafka處理。挑戰在于：如何將物聯網數據從設備連接到Kafka集群？

許多實現物聯網用例的公司正在研究集成MQTT和Kafka來處理物聯網數據的可能性。MQTT是另一個發布/訂閱協議，它已經成為連接IoT設備數據的標準。MQTT標準設計用于通過不可靠的網絡連接大量的物聯網設備，解決了Kafka的許多限制。具體來說，MQTT是一種輕量級協議，需要在每個設備上占用較小的客戶機空間。它可以在不可靠的網絡上安全地支持數百萬個連接，并在高延遲和低吞吐量環境下無縫工作。它包括物聯網功能，如保持活力，最后的遺囑和遺囑功能，不同質量的服務水平的可靠消息，以及客戶端負載平衡（共享訂閱）在其他功能設計的公共互聯網通信。主題是動態的，這意味著系統中可以存在任意數量的MQTT主題，在MQTT服務器集群中，每次部署通常多達數千萬個主題。

盡管Kafka和MQTT有不同的設計目標，但兩者在一起工作得非常好。問題不是Kafka vs MQTT，而是如何將這兩個世界集成在一起，形成一個物聯網端到端數據管道。為了將MQTT消息集成到Kafka集群中，需要某種類型的橋接器將MQTT消息轉發到Kafka。

有四種不同的架構方法來實現這種類型的橋梁：

1. Kafka連接（Kafka Connect）MQTT

Kafka有一個擴展框架，叫做Kafka Connect，它允許Kafka從其他系統攝取數據。Kafka Connect for MQTT充當一個MQTT客戶端，訂閱來自MQTT代理的所有消息。

如果您沒有對MQTT代理的控制權，那么Kafka Connect for MQTT是一個值得追求的方法。這種方法允許Kafka攝取MQTT消息流。

在MQTT中使用Kafka Connect存在性能和可伸縮性限制。如前所述，Kafka Connect for MQTT是一個MQTT客戶機，它訂閱通過代理傳遞的所有MQTT消息。MQTT客戶機庫并不打算處理大量的MQTT消息，因此使用這種方法的物聯網系統將存在性能和可伸縮性問題。

這種方法集中了業務和消息轉換邏輯，并創建了緊密耦合，這在分布式（微服務）體系結構中應該避免。業界領先的咨詢公司Thoughtworks稱這是一種反模式，甚至在他們之前的技術雷達出版物中將Kafka歸入“持有”類別。

2. MQTT代理

另一種方法是使用代理應用程序，它接受來自物聯網設備的MQTT消息，但不實現發布/訂閱或任何MQTT會話特性，因此不是MQTT代理。物聯網設備連接到MQTT代理，然后該代理將MQTT消息推送到Kafka代理。

MQTT代理方法允許在Kafka部署中完成MQTT消息處理，因此可以從單個控制臺完成管理和操作。MQTT代理通常是無狀態的，因此通過添加代理的多個實例，它（理論上）可以獨立于Kafka集群進行伸縮。

MQTT代理的限制是它不是真正的MQTT實現。MQTT代理不是基于發布/訂閱的。相反，它在設備和Kafka之間創建了一個緊密耦合的流。MQTT發布/訂閱的好處是，它創建了一個松散耦合的端點系統（設備或后端應用程序），可以在每個端點之間通信和移動數據。例如，MQTT允許兩個設備之間的通信，例如兩個連接的汽車可以彼此通信，但是MQTT代理應用程序只允許從一輛汽車到Kafka集群的數據傳輸，而不允許與另一輛汽車的數據傳輸。

一些Kafka MQTT代理應用程序支持QoS級別等特性。值得注意的是，只有在MQTT客戶端重新連接到相同的MQTT代理實例時，才可能在連接丟失后恢復QoS消息流，而這是不可能的，前提是使用負載均衡器，該均衡器使用最少連接或循環策略來實現可伸縮性。因此，在MQTT中使用QoS級別的主要原因（即沒有消息丟失）僅適用于穩定連接，這在大多數物聯網場景中是一個不現實的假設。

使用這種方法的主要風險是代理不是功能完整的MQTT代理，因此它不是MQTT規范定義的MQTT實現，只是實現了一個很小的子集，因此它不是一個標準化的解決方案。為了在MQTT客戶機中正確地使用MQTT，需要一個功能齊全的MQTT代理。

如果消息丟失不是一個重要因素，并且沒有使用為可靠的物聯網通信而設計的MQTT特性，如果您只想通過Internet單向地向Kafka發送數據，那么代理方法可能是一個輕量級的替代方法。

3.構建您自己的自定義橋接

一些公司建立了他們自己的MQTT到Kafka橋。典型的方法是使用開源MQTT客戶端庫和開源Kafka客戶端庫創建應用程序。自定義應用程序負責在MQTT代理和Kafka實例之間調換和路由數據。

這種方法的主要挑戰是，自定義應用程序通常沒有設計成容錯和彈性。如果物聯網解決方案要求和端到端保證至少一次或確切一次消息傳遞，這就變得很重要。例如，設置為服務質量級別1或2的MQTT消息發送到自定義應用程序將確認收到消息。但是，如果自定義應用程序在將消息轉發給Kafka之前崩潰，則消息將丟失。類似地，如果Kafka集群不可用，自定義應用程序將需要緩沖MQTT消息。如果定制應用程序在Kafka集群恢復可用之前崩潰，所有緩沖的消息將丟失。要解決這些問題，定制應用程序將需要大量的開發工作，構建與Kafka和MQTT代理中已經發現的技術類似的功能。

4. MQTT代理擴展

最后一種方法是擴展MQTT代理，以創建包含本機Kafka協議的擴展。這允許MQTT代理充當一流的Kafka客戶機，并將物聯網設備數據流傳遞給多個Kafka集群。

要實現這種方法，您需要訪問MQTT代理，代理需要能夠安裝擴展。

這種方法允許物聯網解決方案使用本地MQTT實現和本地Kafka實現。物聯網設備使用MQTT客戶機將數據發送到功能齊全的MQTT代理。MQTT代理被擴展為包括一個本地Kafka客戶機，并將MQTT消息置換到Kafka協議。這使得物聯網數據可以同時路由到多個Kafka集群和非Kafka應用程序。使用MQTT代理還將提供對物聯網設備所需的所有MQTT特性的訪問，例如遺囑和遺囑。MQTT代理（如HiveMQ）是為高可用性、持久性、性能和彈性而設計的，因此消息可以在Kafka不可寫時在代理上緩沖，因此重要消息不會從物聯網設備中丟失。因此，這種方法提供了真正的端到端消息傳遞保證，即使是在不可靠的網絡、公共Internet通信和不斷變化的網絡拓撲（在容器化部署中經常看到，例如Kubernetes）。

用于Kafka的HiveMQ企業擴展

在與HiveMQ客戶的對話中，一些操作集群具有數百萬臺設備和非常高的消息吞吐量，我們看到需要為Kafka創建MQTT代理擴展。我們的客戶希望從MQTT和Kafka協議的本地實現中受益，因為這兩個協議都有所有的交付保證。因此，我們很高興地宣布Kafka的HiveMQ企業擴展。

我們的客戶看到了MQTT和Kafka聯合解決方案的巨大價值。他們將Kafka視為在數據中心或云環境中處理和分發實時數據的優秀平臺。他們希望使用MQTT和HiveMQ將數據從設備移動到不同的后端系統。后端系統包括Kafka和非Kafka系統。他們還知道，如果他們試圖連接數以百萬計的設備，比如連接的汽車，他們需要使用MQTT的本機和經過實戰測試的實現，比如HiveMQ。

用于Kafka的HiveMQ企業擴展在HiveMQ代理中實現了本地Kafka協議。這允許MQTT消息與單個Kafka集群或多個Kafka集群同時無縫集成。它100%支持整個MQTT 3和MQTT 5規范。我們甚至可以將潛在的數百萬個MQTT主題映射到數量有限的Kafka主題。最后，我們擴展了HiveMQ控制中心，使其能夠監視寫入Kafka的MQTT消息。

我們很高興能將這個新產品帶給我們的HiveMQ客戶。這是在物聯網用例中使用Apache Kafka的最佳方法。
? ? ? ?責任編輯:pj