使用 Kafka 和 MQTT 大规模传输 IoT 和事件流

随着有价值的用例的曝光，物联网 （IoT） 变得越来越吸引人。然而，一个关键的挑战是集成设备和机器，以实时和大规模地处理数据。Apache Kafka ^®及其周边生态系统（包括卡夫卡连接、卡夫卡流和 KSQL）已成为集成和处理此类数据集的首选技术。

您可能还喜欢：
IoT：设备数据和流处理

对于卡夫卡客户端 API（如 Java、Python、.NET 和 C/C++）之外的 MQTT 集成，需要注意的 Kafka 原生选项包括：

• Kafka 连接源和接收器连接器，在两个方向与 MQTT 代理集成
• Confluent MQTT 代理， 从 IoT 设备引入数据，无需 MQTT 代理
• 集成 REST 代理，实现简单但功能强大的基于 HTTP 的集成

在详细讨论这些之前，让我们先看一下一些常见的用例，其中 Confluent 平台和 Confluent 云现在用于 IoT 项目。

IoT 技术和事件流平台的用例

Confluent 平台和Confluent 云是开源的，已用于许多 IoT 部署，包括消费者 IoT 和工业 IoT （IIoT）。大多数方案都需要可靠、可扩展和安全的端到端集成，从而实现双向通信和实时数据处理。一些特定的用例包括：

• 互联汽车基础设施：汽车相互通信，远程数据中心或云可执行实时流量建议、预测维护或个性化服务。
• 智能城市和智能家居：建筑物、交通灯、停车场和许多其他东西相互连接，以便提高效率，提供更舒适的生活方式。能源供应商将房屋连接起来，购买或出售自己的太阳能，并提供额外的数字服务。
• 智能零售和客户 360：客户移动应用与后端服务（如 CRM、忠诚度系统、地理位置和天气信息）之间的实时集成可创建特定于上下文的客户视图，并允许更好地交叉销售、促销和其他面向客户的服务。
• 智能制造：工业公司集成了机器和机器人，以优化其业务流程并降低成本，例如提前报废零件或预测性维护，以在机器部件断裂前更换它们。数字服务和订阅提供给客户，而不仅仅是销售产品。

无论在哪个行业，机器学习在许多这些用例中都扮演着巨大的角色，您可以阅读使用 Apache Kafka 来驱动尖端机器学习，获取更多见解。

现在，让我们看一下强大的 IoT 集成架构的 10，000 英尺视图）与数据中心（本地、云和混合）一起处理 IoT 数据。

物联网集成架构的要求和挑战

为了灵活且面向未来，IoT 集成体系结构应具备以下要求：

• 可扩展的数据移动和处理：处理背压，并可处理更高的吞吐量
• 敏捷开发和松散耦合：不同的源和汇应该是它们自己的分离域。不同的团队可以开发、维护和更改对设备和机器的集成，而无需依赖于处理和分析数据的其他源或接收器系统。微服务、Apache Kafka 和域驱动设计 （DDD）更详细地介绍了这一点。
• 创新开发：根据特定用例的灵活性和要求，可以使用新的和不同的技术和概念。例如，一个应用程序可能已经将数据发送到 MQTT 代理，以便您可以从那里使用，而另一个项目根本不使用 MQTT 代理，并且您只想将数据直接推送到事件流平台以进行进一步处理。

但是，以下几个挑战增加了 IoT 集成架构的复杂性：

• 复杂的基础结构和操作通常无法更改 – 尽管需要与现有计算机集成，但您无法轻松地向计算机本身添加代码
• 与许多不同的技术（如 MQTT 或 OPC 统一架构 （OPC UA） 集成，同时遵循传统和专有标准
• 由于物联网网络不良导致通信不稳定，导致成本高，在边缘投资

鉴于这些要求和挑战，现在让我们来看看 MQTT 和其他 IoT 标准如何帮助集成数据中心和边缘。

物联网标准和技术：MQTT、OPC UA、西门子S7和PROFINET

市场上有许多 IoT 标准和技术。如果我们必须选择，以下是实现 IoT 集成的最常见选项：

• 专有接口：尤其是在工业物联网 （IIoT） 中，这是最常见的方案。计算机以专有格式提供大量通常关闭和不兼容的协议。例如 S7、PROFINET、Modbus 或自动调度系统 （ADS）。监督控制和数据采集 （SCADA） 通常用于控制和监视这些系统。
• OPC UA：这是一种用于工业自动化的开放式跨平台机器对机器通信协议。每个设备都必须经过改装，能够说出新的协议并使用公共客户端与这些设备通话。启用 OPC UA 需要许可成本和对现有硬件的修改。
• PLC4X：作为 Apache 框架，它通过实现驱动程序（类似于关系数据库的 JDBC）来提供统一的 API，以便与它们本机理解的协议中的大多数工业控制器进行通信。无需任何许可证成本或硬件修改。
• MQTT：这是基于 TCP/IP 之上构建的受约束设备和不可靠的网络，适用于许多（开源）代理实现和许多客户端库。它包含特定于 IoT 的功能，用于不良网络/连接，并且广泛使用（主要用于 IoT，但也通过 WebSocket 的 MQTT 在 Web 和移动应用程序中）。

难怪技术诀窍在这两个领域分布不均匀只有 MQTT 对自动化技术员工来说似乎很熟悉。

同样，工业协议是一本有七个密封为软件工程师的书。可能某些工业协议非常适合特定的 IoT 解决方案，就像现代 IoT 协议的某些安全功能适合行业一样。但是，这并没有多大动能。

MQTT 已成为当今大多数 IoT 方案的标准解决方案，尤其是在 IIoT 之外。尽管 MQTT 是本博客文章的重点，但在未来的文章中，我将通过利用 PLC4X 及其卡夫卡集成，介绍 MQTT 与 IIoT 及其专有协议（如西门子 S7、Modbus 和 ADS）的集成。有关使用 Kafka Connect 和 PLC4X 进行 IIoT 集成方案的更多详细信息，您可以查看这些幻灯片，了解自动化行业灵活可扩展的集成，以及解释 IIoT 之间关系的视频，阿帕奇卡夫卡，和PLC4X。

根据我与工业客户的对话，他们因封闭、不灵活的接口而感到痛苦，我注意到越来越多的 IIoT 设备和机器还提供可集成到现代系统的 MQTT 接口。

关于 MQTT 的权衡，请考虑利弊：

优点

• 广泛采用
• 轻量级
• 具有简单的 API
• 专为不良连接和高延迟方案而构建
• 支持多个客户端连接（每个 MQTT 服务器数万次）

缺点

• 只是排队，而不是流处理
• 无法处理使用激增（无缓冲）
• 大多数 MQTT 代理不支持高可扩展性
• 异步处理（通常长时间脱机）
• 缺乏与企业其他部门的良好整合
• 单个基础结构（通常在边缘某处）
• 无法重新处理事件

这些权衡表明 MQTT 是为 IoT 方案构建的，但在集成到公司企业体系结构方面需要帮助。这就是事件流平台 Apache Kafka 及其生态系统发挥作用的地方。

Apache Kafka 作为事件流平台

Apache Kafka 是一个事件流平台，它结合了消息传递、存储和数据处理，构建了高度可扩展、可靠、安全和实时的基础架构。使用 Kafka 的用户通常使用 Kafka Connect，以便与任何源或接收器集成。Kafka 流也很有用，因为它允许连续流处理。从物联网的角度来看，Kafka 提出了以下权衡：

优点

• 流处理，而不仅仅是排队
• 高吞吐量
• 大型
• 高可用性
• 长期存储和缓冲
• 事件再处理
• 与企业其他部门的良好集成
• 混合、多云和全局部署

缺点

• 未为数以万计的连接构建
• 需要稳定的网络和坚实的基础设施
• 缺少特定于 IoT 的功能，如保持活力、最后遗嘱和约

由于 Kafka 并非专为边缘 IoT 通信而构建，因此 Apache Kafka 和 MQTT 的组合是构建可扩展、可靠和安全的物联网基础设施的天上匹配。

如何整合两者？

以下各节演示了三个 Kafka 原生选项，这意味着除了 MQTT 设备/网关/代理和 Confluent 平台之外，您通常不需要其他技术来集成和处理 IoT 数据confluent.io/current/connect/index.html”rel=”nofollow”目标=”\blank”_Kafka Connect是阿帕奇卡夫卡中一个框架，将卡夫卡与其他系统集成。其目的是使新系统易于添加到可扩展和安全的事件流管道中，同时利用 Apache Kafka 的所有功能，如高吞吐量、可扩展性和可靠性。下载和安装新源和接收器连接器的最简单方法是通过Confluent 集线器。您可以找到开源连接器的安装步骤、文档，甚至源代码。

Kafka Connect MQTT 连接器是一个插件，用于从 MQTT 代理发送和接收数据。

MQTT 代理是永久性的，提供特定于 MQTT 的功能。它消耗来自 IoT 设备的推送数据，Kafka Connect 以自己的速度拉取这些数据，而不会使源不堪重负或被源淹没。开箱即用的可扩展性和集成功能，如 Kafka 连接转换器和单消息转换 （SMT）是使用 Kafka Connect 连接器的进一步优势。

MQTT 连接器独立于特定的 MQTT 代理实现。我见过几个项目从Mosquitto开始，然后在从试点项目到预生产的过渡过程中，向像HiveMQ这样的可靠、可扩展的代理迈进。

没有 MQTT 经纪商的数据引入的 MQTT 代理

在某些情况下，主要的挑战和要求是将数据引入 Kafka，以便在其他后端系统中进行进一步处理和分析。在这种情况下，MQTT 代理只会增加复杂性、成本和操作开销。

Confluent MQTT 代理提供 Kafka 原生 MQTT 代理，允许组织消除中间 MQTT 代理的额外成本和延迟。MQTT 代理访问、合并和保证 IoT 数据流入业务，而不会增加额外的复杂性层。

MQTT 代理是水平可扩展的，使用来自 IoT 设备的推送数据，并将其转发到低延迟的 Kafka 代理。不需要 MQTT 代理作为中介。Kafka 代理是 IoT 数据的持久性、高可用性和可靠性的真理来源。

但是，尽管每个人都在集成 IoT 设备时考虑 IoT 标准（如 MQTT 或 OPC UA），但 REST 和 HTTP（S） 通常只是一个更简单的解决方案。

REST 代理作为 IoT 集成的”简单”选项

REST 代理为 Kafka 群集提供 RESTful 接口，便于生成和使用消息、查看群集状态以及执行管理操作，而无需使用本机 Kafka 协议或客户端。

为什么可以使用 HTTP （S） 进行 IoT 集成？由于各种原因，REST 代理使实施和部署变得更简单、更快、更容易，与特定于 IoT 的技术相比：

• 简单易懂
• HTTP（S） 代理基于推送
• 从组织和治理的角度来看，安全性更容易-询问您的安全团队！
• 具有标准负载均衡器的可扩展性，尽管它仍然是同步 HTTP，不适合高可伸缩性
• 每秒支持数千条消息

无论您决定如何集成 IoT 设备，构建可靠的端到端监控基础架构都至关重要Kafka 群集没有太大区别，您必须监视和保护 Kafka 代理、ZooKeeper 节点、客户端使用者组（Java、Python、Go、REST 等）以及连接和 KSQL 群集。

在端到端监控整个 Kafka 基础设施方面，Confluent 控制中心可深入了解您的 Kafka 集群的内部工作以及流经这些集群的数据。控制中心通过精心策划的仪表板为管理员提供监视和管理功能，以便他们能够提供最佳性能并满足群集的 S拉。这包括：

• 从生产商到经纪人到消费者的端到端监控
• 管理 Connect 群集（源和接收器），无论它是中央基础结构还是体系结构中是否有域驱动的组件
• 基于角色的访问控制 （RBAC），用于安全通信和确保合规性
• 监视和警报可用性、延迟、消耗、数据丢失等。

借助基于角色的访问控制 （RBAC） 等安全功能，您还可以为 Confluent 平台的所有组件启用简单和标准化的身份验证和授权。

为您的 IoT 集成挑战选择合适的组件

IoT 集成方案的用例始终相似：与设备或计算机集成;将事件实时流入 Kafka 群集（本地或云中）;使用 Kafka 流和 KSQL 处理数据;然后将数据发送回设备或机器，和/或发送到数据库、分析工具或任何其他业务应用程序等其他接收器。

借助 Kafka 原生选项（如客户端、MQTT 连接器、MQTT 代理或 REST 代理），您可以集成 IoT 技术和接口，以建立强大但简单的体系结构，而无需使用其他工具。这一点在 24/7 任务关键型部署中尤为推荐，其中每个附加组件都会增加复杂性、风险和成本。你有很多选择，所以选择一个最适合你的情况。

此博客文章的内容也捕获在此交互式光板记录称为端到端集成：IoT 边缘到康康云。

进一步阅读

IoT：设备数据和流处理

使用阿帕奇·卡夫卡进行实时流处理

[D区域参考卡]了解流处理