Apache Kafka是一個實時流媒體平臺，在大型和小型組織中得到廣泛採用。Kafka的分布式微服務架構和發布/訂閱協議使其成為在企業系統和應用程式之間移動實時數據的理想選擇。據一些人稱，超過三分之一的財富500強公司正在使用Kafka。在GitHub上，Kafka是最受歡迎的Apache項目之一，擁有超過11,000名明星和超過500名貢獻者。毫無疑問，Kafka是一個開源項目，正在改變組織在雲和數據中心內部移動數據的方式。
Kafka的體系結構已經過優化，可以以可擴展的方式儘可能快地在系統和應用程式之間傳輸數據。Kafka客戶端/生產者與Kafka集群緊密耦合，要求每個客戶端知道Kafka集群的IP位址並直接訪問所有單個節點。在可信網絡內部，這允許更改代理拓撲，這意味著可以通過直接從Kafka客戶端使用多個節點來擴展主題和分區。在大多數情況下，Kafka主題空間也保持相當平坦，因為通常使用多個分區來縮放單個Kafka主題。在Kafka系統中擁有數百甚至數千個主題通常是不可取的，但對大多數數據流使用一些主題。
對於物聯網使用情況，設備通過公共網際網路連接到數據中心或雲，Kafka架構不適合開箱即用。如果您嘗試通過Internet使用Kafka從數千甚至數百萬設備流式傳輸數據，則Apache Kafka架構不適用。單獨Kafka不適合物聯網使用案例有很多原因：
Kafka經紀人需要由客戶直接解決，這意味著客戶需要直接聯繫Kafka經紀人。專業物聯網部署通常使用負載均衡器作為其雲中的第一道防線，因此設備只需使用負載均衡器的IP位址連接到基礎架構，負載均衡器就可以充當代理。如果您希望您的設備直接連接到Kafka，那麼您的Kafka經紀人必須接觸公共網際網路。Kafka不支持大量主題。通過公共Internet連接數百萬個IoT設備時，通常會使用單個和唯一的主題（通常在主題名稱中包含一些唯一的IoT設備標識符），因此可以根據各個客戶端的權限限制讀寫操作。您不希望智能恆溫器被黑客入侵，並且用於竊聽系統中所有數據流的憑據。與用於物聯網協議的客戶端庫相比，Kafka客戶端相當複雜且資源密集。用於大多數程式語言的Kafka API非常簡單明了，但引擎蓋下卻存在很多複雜性。例如，客戶端將使用和維護與Kafka代理的多個TCP連接。物聯網部署通常具有受限設備，這些設備需要最小的佔用空間，但在設備端不需要非常高的吞吐量。默認情況下，Kafka客戶端針對吞吐量進行了優化Kafka客戶端需要穩定的TCP連接才能獲得最佳結果。許多物聯網用例涉及不可靠的網絡，例如聯網汽車或智能農業，因此物聯網設備需要始終如一地重新建立與卡夫卡的連接。將數萬甚至數百萬個客戶端連接到單個Kafka集群是不常見的（通常甚至根本不可能）。在物聯網用例中，通常有大量設備，它們同時連接到後端並不斷產生數據。Kafka缺少一些關鍵的物聯網功能。Kafka協議缺少諸如保持活力以及遺囑和遺囑等功能。這些功能對於構建具有彈性的物聯網解決方案非常重要，即使設備遇到意外斷開連接並且網絡不可靠也是如此。Kafka仍然為物聯網用例帶來了很多價值。物聯網解決方案創建了大量的實時數據，非常適合Kafka的處理。面臨的挑戰是如何將物聯網數據從設備橋接到Kafka集群？
許多實施物聯網用例的公司正在尋找集成MQTT和Kafka來處理其物聯網數據的選項。MQTT是另一種發布/訂閱協議，已成為連接IoT設備數據的標準。MQTT標準旨在通過不可靠的網絡連接大量物聯網設備，解決了卡夫卡的許多局限性。特別是，MQTT是一種輕量級協議，需要在每個設備上佔用較少的客戶端。它旨在通過不可靠的網絡安全地支持數百萬個連接，並在高延遲和低吞吐量環境中無縫工作。它包括物聯網功能，如保持活動，遺囑和遺囑功能，可靠消息的不同服務質量等級，以及客戶端負載平衡（共享訂閱）和為公共Internet通信設計的其他功能。主題是動態的，這意味著系統中可以有任意數量的MQTT主題，在MQTT伺服器群集中每個部署通常高達數千萬個主題。
雖然Kafka和MQTT有不同的設計目標，但兩者都能很好地協同工作。問題不是Kafka與MQTT，而是如何將兩個世界整合在一起，形成物聯網端到端數據管道。為了將MQTT消息集成到Kafka集群中，您需要某種類型的橋接器將MQTT消息轉發到Kafka。實現此類橋接有四種不同的體系結構方法：
Kafka Connect for MQTT
Kafka有一個名為Kafka Connect的擴展框架，它允許Kafka從其他系統中提取數據。Kafka Connect for MQTT充當MQTT客戶端，訂閱來自MQTT代理的所有消息。
如果您無法控制MQTT代理，那麼Kafka Connect for MQTT是一種很好的方法。這種方法允許Kafka攝取MQTT消息流。
使用Kafka Connect for MQTT存在性能和可伸縮性限制。如前所述，Kafka Connect for MQTT是一個MQTT客戶端，可以訂閱 通過代理的潛在所有MQTT消息。MQTT客戶端庫不用於處理極大量的MQTT消息，因此使用此方法的物聯網系統將存在性能和可伸縮性問題。
這種方法集中了業務和消息轉換邏輯，並創建了緊密耦合，這應該在分布式（微服務）體系結構中避免。業界領先的諮詢公司Thoughtworks 將此稱為反模式，甚至將Kafka納入其先前技術雷達出版物的「保留」類別。
MQTT代理
另一種方法是使用代理應用程式，該代理應用程式接受來自IoT設備的MQTT消息，但不實現發布/訂閱或任何MQTT會話功能，因此不是MQTT代理。IoT設備連接到MQTT代理，然後將MQTT消息推送到Kafka代理。
MQTT代理方法允許在Kafka部署中完成MQTT消息處理，因此管理和操作來自單個控制臺。MQTT代理通常是無狀態的，因此它（理論上）可以通過添加代理的多個實例來獨立於Kafka集群進行擴展。
MQTT代理的局限性在於它不是真正的MQTT實現。MQTT代理不是基於pub / sub，而是在設備和Kafka之間創建緊密耦合的流。MQTT pub / sub的好處是它創建了一個鬆散耦合的端點系統（設備或後端應用程式），可以在每個端點之間進行通信和移動數據。例如，MQTT允許兩個設備之間的通信，例如兩個連接的汽車可以相互通信，但MQTT代理應用程式只允許從汽車到Kafka集群的數據傳輸，而不是與另一輛汽車的數據傳輸。
一些Kafka MQTT代理應用程式支持QoS級別等功能。值得注意的是，只有當MQTT重新連接到同一個MQTT代理實例時，才能在連接丟失後恢復QoS消息流，如果使用的負載均衡器使用最小連接或循環策略進行擴展，則無法實現。因此，在MQTT中使用QoS級別的主要原因（無消息丟失）僅適用於此類場景中的穩定連接，這在大多數物聯網場景中是不切實際的假設。
使用這種方法的主要風險是代理不是一個功能齊全的MQTT代理，因此它不是MQTT規範定義的MQTT實現，因為它只實現了一個很小的子集，所以它不是標準化的解。為了正確使用MQTT和MQTT客戶端，需要一個功能齊全的MQTT代理。
如果消息丟失不是一個重要因素，並且如果不使用為可靠的IoT通信而設計的MQTT功能，則如果您只想通過Internet將數據單向發送到Kafka，則代理方法可能是一種輕量級替代方法。
建立自己的自定義橋梁
一些公司為卡夫卡橋建立了自己的MQTT。典型的方法是使用開源MQTT客戶端庫和開源Kafka客戶端庫創建應用程式。自定義應用程式負責在MQTT代理和Kafka實例之間轉置和路由數據。
這種方法面臨的主要挑戰是自定義應用程式通常不具備容錯能力和彈性。如果物聯網解決方案需要至少一次或完全一次消息傳遞的端到端保證，這就變得很重要。例如，設置為發送到自定義應用程式的服務質量等級1或2的MQTT消息將確認收到消息。但是，如果自定義應用程式在將消息轉發到Kafka之前崩潰，則消息將丟失。同樣，如果Kafka集群不可用，則自定義應用程式將需要緩衝MQTT消息。如果自定義應用程式在Kafka群集可用之前崩潰，則所有緩衝的消息都將丟失。要解決這些問題，
MQTT經紀人擴展
最後一種方法是擴展MQTT代理以創建包含本機Kafka協議的擴展。這允許MQTT代理充當一流的Kafka客戶端，並將IoT設備數據流式傳輸到多個Kafka集群。
要實現此方法，您需要具有對MQTT代理的訪問權限，並且代理需要能夠安裝擴展。
此方法允許IoT解決方案使用本機MQTT實現和本機Kafka實現。物聯網設備使用MQTT客戶端將數據發送到功能齊全的MQTT代理。MQTT代理擴展為包含本機Kafka客戶端，並將MQTT消息轉換為Kafka協議。這允許將物聯網數據路由到多個Kafka群集，同時路由到非Kafka應用程式。使用MQTT代理還可以訪問物聯網設備所需的所有MQTT功能，例如last will和tesament。像HiveMQ這樣的MQTT代理是為高可用性，持久性，性能和彈性而設計的，因此當Kafka不可寫時，消息可以緩存在代理上，因此IoT設備永遠不會丟失重要消息。所以，Kubernetes）。
Kafka的HiveMQ企業擴展
在與HiveMQ客戶的對話中，一些具有數百萬設備和非常高的消息吞吐量的操作集群，我們發現需要為Kafka創建MQTT代理擴展。我們的客戶希望從MQTT和Kafka協議的本機實現中受益，並提供兩種協議的所有交付保證。因此，我們很高興地宣布Kafka的HiveMQ企業擴展。
我們的客戶在聯合MQTT和Kafka解決方案中看到了巨大的價值。他們將Kafka視為在數據中心或雲環境中處理和分發實時數據的絕佳平臺。他們希望使用MQTT和HiveMQ將數據從設備移動到不同的後端系統。後端系統包括Kafka和非Kafka系統。他們還知道，如果他們試圖連接數百萬臺設備，如聯網汽車，他們需要使用原生且經過實戰考驗的MQTT實施，如HiveMQ。
Kafka的HiveMQ Enterprise Extension在HiveMQ代理中實現了本機Kafka協議。這允許MQTT消息與單個Kafka集群或多個Kafka集群同時無縫集成。它支持100％的整個MQTT 3和MQTT 5規範。我們甚至可以將數百萬個MQTT主題映射到有限數量的Kafka主題。最後，我們擴展了HiveMQ控制中心，以便監控寫入Kafka的MQTT消息。
我們很高興能將這款新產品帶給我們的HiveMQ客戶。這是使用Apache Kafka和IoT用例的最佳方法。可以在我們的Marketplace中下載 HiveMQ Enterprise Extension for Apache Kafka的免費試用版。將MQTT和Apache Kafka集成到物聯網用例中從未如此簡單。