随着有价值的用例的出现，物联网（Internet of Things，IoT）越来越具有吸引力。然而，一个关键的挑战是集成设备和机器以实时和大规模地处理数据。Apache Kafka®及其周围的生态系统（包括Kafka Connect、Kafka Streams和KSQL）已成为集成和处理此类数据集的首选技术。

Kafka的本地选项(Kafka-native options )，用于MQTT集成，基于Kafka客户端API，如java、python、.net和C/C++，它们是：

• Kafka Connect source and sink connectors，它们在两个方向上与MQTT代理集成
• Confluent MQTT Proxy，它从物联网设备接收数据，而不需要MQTT代理
• Confluent REST Proxy实现简单但强大的基于HTTP的集成

在我更详细地讨论这些之前，让我们先来看看目前物联网项目中使用合流平台和合流云的一些常见用例。

物联网技术和事件流平台的用例

Confluent平台和Confluent云已经在许多物联网部署中使用，包括在消费者物联网和工业物联网（IIoT）中。大多数场景需要可靠、可扩展和安全的端到端集成，从而实现双向通信和实时数据处理。一些特定的用例是：

互联汽车基础设施：

汽车之间以及远程数据中心或云之间进行通信，以执行实时流量建议、预测维护或个性化服务。

示例：奥迪

智能城市和智能家庭：

建筑物、交通灯、停车场和许多其他东西相互连接，以便提高效率和提供更舒适的生活方式。能源供应商将房屋连接起来，购买或出售自己的太阳能，并提供额外的数字服务。

例子： E.ON

智能零售和客户360：

客户的移动应用程序和后端服务（如CRM、忠诚度系统、地理位置和天气信息）之间的实时集成创建特定于上下文的客户视图，并允许更好的交叉销售、促销和其他面向客户的服务。

示例：Target

智能制造：

工业公司整合机器和机器人，以优化其业务流程并降低成本，例如提前报废零件或预测性维护，以便在机器零件损坏前更换它们。向客户提供数字服务和订阅服务，而不仅仅是向他们销售产品。

示例：Severstal

机器学习在许多这样的用例中扮演着重要的角色，不管是哪个行业，您都可以使用Apache Kafka来驱动尖端的机器学习以获得更多的洞察力(Using Apache Kafka to Drive Cutting-Edge Machine Learning )。

现在让我们来看看10000英尺高的强大物联网集成架构。

端到端企业集成架构

物联网集成架构需要将边缘（设备、机器、汽车等）与数据中心（本地、云和混合）集成，以便能够处理物联网数据。

物联网集成架构的需求与挑战

物联网集成架构要具有灵活性和未来可用性，应具备以下要求：

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

但是，一些挑战增加了物联网集成架构的复杂性：

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

考虑到这些需求和挑战，现在让我们看看MQTT和其他IoT标准如何帮助集成数据中心和edge。

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

市场上有许多物联网标准和技术。如果必须选择，以下是实施物联网集成的最常见选项：

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

难怪技术诀窍在这两个领域中分布不均。例如，在物联网环境中，近年来发展了大量的数据交换协议。对于自动化技术员工来说，只有MQTT看起来很熟悉。

同样，工业协议也是一本书，有七个封条供软件工程师使用。可能有些工业协议非常适合于特定的物联网解决方案，正如现代物联网协议的某些安全特性适合于工业一样。但那没什么动静。

MQTT已经成为当今大多数物联网场景的标准解决方案，特别是在IIoT之外。尽管MQTT是本文的重点，但在以后的一篇文章中，我将通过利用PLC4X及其Kafka集成，介绍MQTT与IIoT及其专有协议（如Siemens S7、Modbus和ADS）的集成。有关在IIoT集成场景中使用Kafka Connect和PLC4X的更多详细信息，您可以查看这些关于自动化行业中灵活和可伸缩的集成的幻灯片，以及解释IIoT、Apache Kafka和PLC4X之间关系的随附视频。

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

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

赞成的意见

• 广泛采用
• Ressourcenschonend
• 有一个简单的API
• 为连接不良和高延迟情况而构建
• 支持多个客户机连接（每个MQTT服务器数万个）

弊端

• 只是排队，不是流处理
• 无法处理使用激增（无缓冲）
• 大多数MQTT代理不支持高可伸缩性
• 异步处理（通常长时间离线）
• 与企业其他部门缺乏良好的整合
• 单一基础设施（通常位于边缘）
• 无法重新处理事件

这些权衡表明，MQTT是为物联网场景构建的，但在集成到公司的企业架构中时需要帮助。这就是事件流平台Apache Kafka及其生态系统发挥作用的地方。

Apache-Kafka作为事件流平台

Apache Kafka是一个事件流平台，它将消息传递、存储和数据处理结合起来，构建高度可伸缩、可靠、安全和实时的基础设施。使用Kafka的人通常也使用Kafka Connect来实现与任何源或汇的集成。Kafka流也很有用，因为它允许连续的流处理。从物联网的角度来看，Kafka提出了以下折衷方案：

赞成的意见

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

弊端

• 不是为成千上万的连接而构建的
• 需要稳定的网络和坚实的基础设施
• 缺乏很多特别的特征，比如保持生存和最后的意志和遗嘱（ Keep Alive and Last Will and Testament）

由于Kafka不是为边缘物联网通信而构建的，因此Apache Kafka和MQTT的结合是构建可伸缩、可靠和安全的物联网基础设施的天作之合。

如何将两者结合起来？

以下各节演示了三种Kafka本机选项，这意味着您通常不需要除MQTT设备/网关/代理和汇合平台之外的其他技术来集成和处理物联网数据。

Confluent MQTT connectors (source and sink)

Kafka Connect是Apache Kafka中包含的一个框架，它将Kafka与其他系统集成在一起。它的目的是在充分利用Apache Kafka的所有特性（如高吞吐量、可伸缩性和可靠性）的同时，方便地向可伸缩和安全的事件流管道添加新系统。下载和安装新的源和汇连接器的最简单方法是通过合流集线器。您可以找到安装步骤、文档，甚至是开源连接器的源代码。

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

MQTT代理是持久的，并提供MQTT特定的特性。它使用IoT设备的推送数据，Kafka Connect以自己的速度拉动这些设备，而不会压倒源设备或被源设备压倒。开箱即用的可扩展性和集成特性（如Kafka Connect转换器和单消息转换（SMTs））是使用Kafka Connect连接器的进一步优势。

MQTT连接器独立于特定的MQTT代理实现。我看到有几个项目从mosquito开始，然后在从试点项目过渡到预生产阶段，转向像HiveMQ这样可靠、可扩展的代理。

MQTT Proxy for data ingestion without an MQTT broker

在某些场景中，主要的挑战和需求是将数据摄取到Kafka中，以便在其他后端系统中进行进一步的处理和分析。在本例中，MQTT代理只是增加了复杂性、成本和操作开销。

合流MQTT代理提供一个Kafka本地MQTT代理，允许组织消除中间MQTT代理的额外成本和延迟。MQTT代理访问、组合和保证物联网数据流入业务而不增加额外的复杂性层。

MQTT代理具有水平可伸缩性，使用来自物联网设备的推送数据，并将其转发到低延迟的Kafka代理。不需要MQTT代理作为中介。Kafka代理是负责物联网数据持久性、高可用性和可靠性的真相来源。

然而，尽管在集成物联网设备时，每个人都会考虑像MQTT或OPC UA这样的物联网标准，但通常REST和HTTP（S）是一个简单得多的解决方案。

REST Proxy as a “simple” option for an IoT integration

REST代理提供了一个到Kafka集群的RESTful接口，使得在不使用本地Kafka协议或客户端的情况下轻松地生成和使用消息、查看集群的状态以及执行管理操作。

为什么要使用HTTP（S）进行物联网集成？由于各种原因，与物联网特定技术相比，REST代理使实现和部署更简单、更快和更容易：

• 简单易懂
• HTTP（S）代理是基于推送的
• 从组织和治理的角度来看，安全性更容易要求您的安全团队！
• 使用标准负载平衡器的可伸缩性，尽管它仍然是同步HTTP，这对于高伸缩性来说并不理想
• 每秒支持数千条消息

无论您决定如何集成物联网设备，构建可靠的端到端监控基础设施都是必不可少的。

端到端监控和安全

分布式系统很难监控和保护。Kafka集群没有太大的不同，您需要监视和保护Kafka代理、ZooKeeper节点、客户机消费者组（Java、Python、Go、REST等）以及Connect和KSQL集群。

在端到端监控整个Kafka基础设施方面，Confluent Control Center提供了对Kafka集群内部工作和流经它们的数据的洞察。控制中心通过管理的仪表板为管理员提供监控和管理功能，以便他们能够提供最佳性能并满足其群集的sla要求。这包括：

• 从生产者到经纪人再到消费者的端到端监控
• 管理连接集群（源和汇），不管它是一个中心基础设施还是体系结构中是否有域驱动组件
• 基于角色的访问控制（RBAC）用于安全通信和确保遵从性
• 监视和警报可用性、延迟、消耗、数据丢失等。

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

为物联网集成挑战选择合适的组件

物联网集成场景的用例总是相似的：与设备或机器集成；将事件流数据实时摄取到Kafka集群（本地或云中）；使用Kafka Streams和KSQL处理数据；然后将数据发送回设备或机器，和/或像数据库一样发送到其他接收器，分析工具或任何其他业务应用程序。

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

如果你想阅读一个完整的关于从边缘到云构建端到端物联网架构的故事，请阅读在谷歌云平台上启用与Apache Kafka和TensorFlow的连接转换，该平台专注于谷歌云平台、合流云和MQTT集成，以构建可伸缩和可靠的机器学习基础设施。

这篇博文的内容也被捕获在这个叫做端到端集成：IoT边缘到Confluent云的交互式光板记录中。

原文：https://www.confluent.de/blog/iot-with-kafka-connect-mqtt-and-rest-proxy/

本文：http://jiagoushi.pro/node/1013

讨论：请加入知识星球或者微信圈子【首席架构师圈】