tcp实时传输kafka数据_将物联网数据和MQTT消息流式传输到Apache Kafka

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集成到物联网用例中从未如此简单。