怎么将物联网数据从设备连接到Kafka集群？

发布时间：2022-06-15 15:27:03 所属栏目：交互来源：互联网

导读：Apache Kafka是一个实时流平台，在大大小小的组织中得到了广泛的采用。Kafka的分布式微服务架构和发布/订阅协议使得它非常适合在企业系统和应用程序之间实时移动数据。据统计，超过三分之一的财富500强公司正在使用Kafka。在Github上，Kafka是最受欢迎的Apac

　　Apache Kafka是一个实时流平台，在大大小小的组织中得到了广泛的采用。Kafka的分布式微服务架构和发布/订阅协议使得它非常适合在企业系统和应用程序之间实时移动数据。据统计，超过三分之一的财富500强公司正在使用Kafka。在Github上，Kafka是最受欢迎的Apache项目之一，有超过11K之星和超过500名贡献者。毫无疑问，Kafka是一个开源项目，它改变了企业在云和数据中心内移动数据的方式。

　　对于设备连接到公共互联网上的数据中心或云的物联网用例，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协议缺少了诸如《活着》和《遗嘱》等功能。这些特性对于构建一个有弹性的物联网解决方案非常重要，该解决方案可以处理遇到意外连接丢失和网络不可靠的设备。

　　有四种不同的架构方法来实现这种类型的桥梁：

　　1. Kafka连接（Kafka Connect）MQTT

　　Kafka有一个扩展框架，叫做Kafka Connect，它允许Kafka从其他系统摄取数据。Kafka Connect for MQTT充当一个MQTT客户端，订阅来自MQTT代理的所有消息。

　　如果您没有对MQTT代理的控制权，那么Kafka Connect for MQTT是一个值得追求的方法。这种方法允许Kafka摄取MQTT消息流。

　　2. MQTT代理

　　另一种方法是使用代理应用程序，它接受来自物联网设备的MQTT消息，但不实现发布/订阅或任何MQTT会话特性，因此不是MQTT代理。物联网设备连接到MQTT代理，然后该代理将MQTT消息推送到Kafka代理。

　　MQTT代理方法允许在Kafka部署中完成MQTT消息处理，因此可以从单个控制台完成管理和操作。MQTT代理通常是无状态的，因此通过添加代理的多个实例，它（理论上）可以独立于Kafka集群进行伸缩。

　　MQTT代理的限制是它不是真正的MQTT实现。MQTT代理不是基于发布/订阅的。相反，它在设备和Kafka之间创建了一个紧密耦合的流。MQTT发布/订阅的好处是，它创建了一个松散耦合的端点系统（设备或后端应用程序），可以在每个端点之间通信和移动数据。例如，MQTT允许两个设备之间的通信，例如两个连接的汽车可以彼此通信，但是MQTT代理应用程序只允许从一辆汽车到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消息。
　　

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!