将 IoT 数据和 MQTT 消息流式传输到 Apache Kafka

用于 MQTT 的 Kafka 连接

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

MQTT 代理

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

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

MQTT 代理的局限性在于它不是真正的 MQTT 实现。MQTT 代理不基于发布/订阅，而是在设备和 Kafka 之间创建紧密耦合的流。MQTT 发布/订阅的好处是，它创建了一个松散耦合的端点系统（设备或后端应用程序），可以在每个端点之间通信和移动数据。例如，MQTT 允许两个设备之间进行通信，例如两辆联网汽车可以相互通信，但 MQTT 代理应用程序只允许从一辆汽车到 Kafka 集群的数据传输，而不允许与另一辆汽车的数据传输。

一些 Kafka MQTT 代理应用程序支持Qos级别等功能。值得注意的是，只有当 MQTT 重新连接到同一个 MQTT 代理实例时，连接丢失后才能恢复 QoS 消息流，如果使用使用最少连接或循环策略来实现可扩展性的负载均衡器，则不可能恢复该消息流。 。因此，在 MQTT 中使用 QoS 级别的主要原因是没有消息丢失，仅适用于这种场景中的稳定连接，这在大多数 IoT 场景中是不切实际的假设。

使用这种方法的主要风险是代理不是功能齐全的 MQTT 代理，因此它不是 MQTT 规范定义的 MQTT 实现，因为它只实现了一个很小的子集，因此它不是标准化的解决方案。为了正确地将 MQTT 与 MQTT 客户端结合使用，需要功能齐全的 MQTT 代理。

如果消息丢失不是一个重要因素，并且不使用专为可靠 IoT 通信而设计的 MQTT 功能，那么如果您只想通过 Internet 单向向 Kafka 发送数据，则代理方法可能是一个轻量级替代方案。

建立您自己的定制桥梁

一些公司构建自己的 MQTT 到 Kafka 的桥梁。典型的方法是使用开源 MQTT 客户端库和开源 Kafka 客户端库创建应用程序。自定义应用程序负责在 MQTT 代理和 Kafka 实例之间转置和路由数据。

这种方法的主要挑战是定制应用程序通常没有设计成容错和弹性的。如果物联网解决方案需要端到端保证至少一次或恰好一次消息传递，这一点就变得很重要。例如，发送到自定义应用程序的设置为服务质量级别 1 或 2 的 MQTT 消息将确认收到该消息。但是，如果自定义应用程序在将消息转发到 Kafka 之前崩溃，则消息将丢失。同样，如果 Kafka 集群不可用，自定义应用程序将需要缓冲 MQTT 消息。如果自定义应用程序在 Kafka 集群可用之前崩溃，则所有缓冲的消息都将丢失。为了解决这些问题，

MQTT 代理扩展

最后一种方法是扩展 MQTT 代理以创建包含本机 Kafka 协议的扩展。这允许 MQTT 代理充当一流的 Kafka 客户端，并将 IoT 设备数据流式传输到多个 Kafka 集群。

要实现此方法，您需要有权访问 MQTT 代理，并且代理需要能够安装扩展。

这种方法允许 IoT 解决方案使用本机 MQTT 实现和本机 Kafka 实现。IoT 设备使用 MQTT 客户端将数据发送到功能齐全的 MQTT 代理。MQTT 代理经过扩展，包含原生 Kafka 客户端，并将 MQTT 消息转置为 Kafka 协议。这使得 IoT 数据可以路由到多个 Kafka 集群，同时路由到非 Kafka 应用程序。使用 MQTT 代理还可以访问 IoT 设备所需的所有 MQTT 功能，例如遗嘱和遗嘱。MQTT 代理（如 HiveMQ）专为高可用性、持久性、性能和弹性而设计，因此消息可以在代理上缓冲，而 Kafka 不可写，因此重要的消息永远不会从物联网设备中丢失。所以，库伯内斯）。

适用于 Kafka 的 HiveMQ 企业扩展

在与 HiveMQ 客户（一些拥有数百万台设备和非常高的消息吞吐量的操作集群）的对话中，我们看到了为 Kafka 创建 MQTT 代理扩展的必要性。我们的客户希望受益于 MQTT 和 Kafka 协议的本机实现以及这两种协议的所有交付保证。因此，我们很高兴宣布推出适用于 Kafka 的 HiveMQ 企业扩展。

我们的客户看到了 MQTT 和 Kafka 联合解决方案的巨大价值。他们将 Kafka 视为在数据中心或云环境中处理和分发实时数据的优秀平台。他们希望使用 MQTT 和 HiveMQ 将数据从设备移动到不同的后端系统。后端系统包括Kafka，也包括非Kafka系统。他们还知道，如果他们尝试连接数百万台设备（例如联网汽车），则需要使用经过实战考验的 MQTT 本地实现，例如 HiveMQ。

HiveMQ Kafka 企业扩展在 HiveMQ 代理内部实现本机 Kafka 协议。这允许 MQTT 消息同时与单个 Kafka 集群或多个 Kafka 集群无缝集成。它 100% 支持整个 MQTT 3 和 MQTT 5 规范。我们甚至可以将潜在的数百万个 MQTT 主题映射到有限数量的 Kafka 主题。最后，我们扩展了 HiveMQ 控制中心，使其能够监控写入 Kafka 的 MQTT 消息。