随着有价值的用例的出现，物联网(IoT)正得到越来越多的关注。然而，一个关键的挑战是整合设备和机器来实时和大规模地处理数据。Apache Kafka®及其周边的生态系统，包括Kafka Connect、Kafka Streams和ksqlDB，已经成为集成和处理这类数据集的首选技术。

在Kafka客户端api(如Java、Python、.NET和C/ c++)之外，需要注意的是:

• Kafka连接源和接收连接器，它们在两个方向上与MQTT代理集成
  
• 汇合式MQTT代理，它从物联网设备中摄取数据，而不需要MQTT代理
  
• Confluent REST代理用于简单但功能强大的基于http的集成
  

在我更详细地讨论这些问题之前，让我们先看一看目前在物联网项目中使用Confluent Platform和Confluent Cloud的一些常见用例。

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

Confluent Platform和Confluent Cloud已经被用于许多物联网部署，包括消费者物联网和工业物联网(IIoT)。大多数场景都需要可靠、可伸缩和安全的端到端集成，从而支持实时的双向通信和数据处理。一些具体的用例是:

联网的汽车基础设施:

汽车彼此和远程数据中心或云进行通信，以执行实时交通建议、预测维护或个性化服务。

例如:Audi

智能城市和智能家居:

建筑、交通灯、停车场等很多东西都相互连接，以实现更高的效率，提供更舒适的生活方式。能源供应商将房屋连接起来，买卖自己的太阳能，并提供额外的数字服务。

例如:E.ON

智能零售和客户360:

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

例如: Target

智能制造:

工业企业将机器和机器人集成在一起，优化业务流程，降低成本，比如提前报废零部件，或者提前进行预防性维护，在机器部件损坏之前更换它们。数字服务和订阅服务提供给客户，而不仅仅是向他们销售产品。

例如:Severstal

在这些用例中，机器学习发挥了巨大的作用，无论行业是什么，您可以使用Apache Kafka阅读来推动尖端的机器学习，以获得更多的见解。

现在让我们来看看一个健壮的物联网集成架构。

端到端企业集成架构

物联网集成架构需要将edge(设备、机器、汽车等)与数据中心(on-premises、cloud和hybrid上)集成，以便能够处理物联网数据。

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

为了灵活和面向未来，物联网集成架构应该具备以下要求:

• 可伸缩的数据移动和处理:处理反向压力，可以处理不断增加的吞吐量
  
• 敏捷开发和松耦合:不同的源和汇应该是各自的解耦域。不同的团队可以开发、维护和更改对设备和机器的集成，而不依赖于处理和分析数据的其他源或sink系统。微服务、Apache Kafka和域驱动设计(DDD)更详细地介绍了这一点。
  
• 创新开发:根据特定用例的灵活性和需求，可以使用新的和不同的技术和概念。例如，一个应用程序可能已经将数据发送到MQTT代理，以便您可以从那里消费，而另一个项目根本不使用MQTT代理，您只是想直接将数据推入事件流平台以进行进一步处理。
  

但是几个挑战增加了物联网集成架构的复杂性:

• 复杂的基础设施和操作通常无法更改——尽管需要与现有的机器集成，但您无法轻松地向机器本身添加代码
  
• 与许多不同的技术集成，比如MQTT或OPC统一架构(OPC Unified Architecture, 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之上，用于受限制的设备和不可靠的网络，应用于许多(开放源码)代理实现和许多客户机库。它包含用于不良网络/连接的IoT特定特性，并被广泛使用(主要用于物联网，但也通过MQTT通过WebSockets用于web和移动应用程序)。
  

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

用同样的方法，工业协议对软件工程师来说是一本有七个封条的书。可能有些工业协议非常适合特定的物联网解决方案，就像现代物联网协议的某些安全特性适合工业一样。但这并不能改变什么。

MQTT已经成为当今大多数物联网场景的标准解决方案，特别是在IIoT之外。尽管MQTT是这篇博客文章的重点，但在以后的文章中，我将通过利用PLC4X及其Kafka集成，讨论MQTT与IIoT及其专有协议(如西门子S7、Modbus和ADS)的集成。有关在IIoT集成场景中使用Kafka Connect和PLC4X的更多细节，您可以查看这些关于自动化行业中灵活和可伸缩集成的幻灯片(flexible and scalable integration in the automation industry)，以及解释IIoT、Apache Kafka和PLC4X之间关系的视频(video explaining the relation between IIoT, Apache Kafka, and PLC4X)。

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

关于MQTT的权衡，考虑利弊:

优点

• 广泛采用
  
• 轻量级
  
• 有一个简单的API
  
• 为连接差和延迟高的场景而构建
  
• 支持许多客户机连接(每个MQTT服务器数万个)
  

缺点

• 只是排队，而不是流处理
  
• 无法处理使用量激增(没有缓冲)
  
• 大多数MQTT代理不支持高可伸缩性
  
• 异步处理(通常脱机很长时间)
  
• 缺乏与企业其他部分的良好集成
  
• 单一基础设施(通常位于边缘)
  
• 不能对事件进行再处理
  

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

Apache Kafka作为一个事件流平台

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

优点

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

缺点

• 不是为成千上万的连接而建的
  
• 需要稳定的网络和坚实的基础设施
  
• 缺乏信息技术特有的特征，比如“活着”和“遗嘱”
  
• 由于Kafka不是为边缘物联网通信而构建的，因此Apache Kafka和MQTT的结合是构建可伸缩、可靠和安全的物联网基础设施的天成之选。
  

如何将两者结合起来?

下面几节将演示三种kafka本地选项，这意味着除了MQTT设备/网关/代理和Confluent平台之外，您通常不需要其他技术来集成和处理IoT数据。

Confluent MQTT连接器(源和汇)

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

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

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

MQTT连接器独立于特定的MQTT代理实现。我曾见过几个项目在从试验项目到预生产的过渡过程中从使用mosquito to开始，然后转向可靠的、可伸缩的代理，如HiveMQ。

用于在没有MQTT Broker的情况下摄入数据的MQTT Proxy

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

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

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

然而，尽管在集成物联网设备时，每个人都考虑诸如MQTT或OPC UA之类的物联网标准，但REST和HTTP往往是更简单的解决方案。

REST代理作为物联网集成的“简单”选项

REST Proxy为Kafka集群提供了一个RESTful接口，使其可以轻松地生成和使用消息、查看集群的状态以及执行管理操作，而无需使用本机Kafka协议或客户机。

为什么要使用HTTP(S)进行物联网集成?由于各种原因，与特定于iot的技术相比，REST Proxy使实现和部署更简单、更快、更容易:

• 它简单易懂
  
• HTTP代理是基于推的
  
• 从组织和治理的角度来看，安全性更容易——问问您的安全团队吧!
  
• 可伸缩性与标准负载均衡器，尽管它仍然是同步HTTP，这不是高可伸缩性的理想
  
• 支持数以千计的消息每秒
  

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

端到端监控和安全性

分布式系统很难监控和安全。Kafka集群没有太大的不同——您必须监视和保护Kafka代理、ZooKeeper节点、客户端消费者组(Java、Python、Go、REST等)以及Connect和ksqlDB集群。

就端到端监控您的整个Kafka基础设施而言，Confluent Control Center提供了对Kafka集群内部工作和流经它们的数据的洞察。Control Center通过精心策划的仪表板为管理员提供监视和管理功能，以便他们能够提供最佳性能并满足集群的sla。这包括:

• 从生产者到代理到消费者的端到端监控
  
• 连接集群(源和接收)的管理，无论它是中心基础设施还是体系结构中是否有域驱动的组件
  
• 用于安全通信和确保遵从性的基于角色的访问控制(RBAC)
  
• 对可用性、延迟、消耗、数据丢失等进行监视和警报。
  

通过使用诸如基于角色的访问控制(RBAC)这样的安全特性，您还可以为Confluent平台的所有组件启用简单的、标准化的身份验证和授权。

为您的物联网集成挑战选择正确的组件

物联网集成场景的用例总是类似的:与设备或机器集成;将事件流数据实时输入Kafka集群(在场所或云中);使用Kafka流和ksqlDB处理数据;然后将数据发送回设备或机器，和/或其他接收器，如数据库，分析工具，或任何其他业务应用程序。

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

如果你想读一个完整的故事建立一个端到端物联网体系结构从边缘到云,读启用连接转换与Apache卡夫卡和TensorFlow在谷歌的云平台,专注于谷歌的云平台,融合性的云,MQTT集成构建一个可伸缩的、可靠的机器学习的基础设施。