2024 年 MQTT 市场趋势：云、统一命名空间、Sparkplug 和 Kafka 集成

轻量级、开放式物联网消息传输协议 MQTT 已被各行业广泛采用。这篇文章探讨了 MQTT 的相关市场趋势：云部署和完全托管服务、统一命名空间和 Sparkplug B 的数据管理、MQTT 与 OPC-UA 的争论，以及与 Apache Kafka 的集成以实现 OT/IT 数据的实时处理。

本文作者：Kai Wähner，在 Confluence 担任技术传播者。

慕尼黑 MQTT 峰会

2023 年 12 月，我参加了康纳克 MQTT 峰会。HiveMQ 赞助了此次活动。会议议程包括各种行业专家。演讲内容涉及工业物联网部署、统一命名空间、Sparkplug B、安全和车队管理，以及 Kafka 与 MQTT 结合的使用案例，如联网车辆或智能城市（我的演讲）。

我很高兴能结识 MQTT 社区的许多业界同行、独立顾问和软件供应商。我学到了很多关于 MQTT 在现实世界中的应用、最佳实践以及 Sparkplug B 的一些折衷方法。以下部分总结了我在这次活动中了解到的 MQTT 趋势以及我今年在世界各地客户会议中获得的经验。

特别感谢 HiveMQ 的 Kudzai Manditereza 组织了这次盛大的活动，众多来自不同行业的国际与会者参加了此次活动。

什么是 MQTT？

MQTT 是消息队列遥测传输（Message Queuing Telemetry Transport）的缩写。MQTT 是一种轻量级的开源消息传输协议，专为使用高延迟或不可靠网络的小型传感器和移动设备而设计。IBM 最初于 20 世纪 90 年代末开发了 MQTT，后来成为一种开放标准。

MQTT 采用发布/订阅模式，设备（或客户端）通过中央消息代理进行通信。MQTT 的主要组件包括

• Client： 连接到 MQTT 代理发送或接收消息的设备或应用程序。
• Broker： 管理客户端之间通信的中心枢纽。它接收来自发布客户端的消息，并根据主题将消息转发给订阅客户端。
• Topic： 作为信息标签的分层字符串。客户端订阅主题以接收信息，并向特定主题发布信息。

何时使用 MQTT

发布/订阅模式可实现设备间的高效通信。当客户端向特定主题发布消息时，订阅该主题的所有其他客户端都会收到消息。这就将发送方和接收方分离开来，实现了一个可扩展且灵活的通信系统。

MQTT 标准以其简单性、低带宽使用率和对不可靠网络的支持而著称。这些特点使其非常适合物联网（IoT）应用，因为在物联网应用中，设备通常资源有限，并可能在具有挑战性的网络条件下运行。良好的 MQTT 实现为物联网项目提供了一个可扩展的可靠平台。

MQTT 已在各行各业得到广泛应用，用于物联网部署、家庭自动化以及其他需要轻量级高效通信的场景。

下面我将讨论 MQTT 的四个市场趋势。这些趋势对采用和决定选择 MQTT 有着巨大的影响：

• 公共云中的 MQTT
• MQTT 的数据管理
• MQTT 与 OPC-UA 之争
• 用于 OT/IT 数据处理的 MQTT 和 Apache Kafka

趋势 1：公共云中的 MQTT

大多数公司都有云优先战略。如果可以，就采用无服务器模式！这样做的结果是：专注于业务问题，加快产品上市速度，并提供弹性基础设施。

成熟的 MQTT 云服务已经存在。在 Confluent，我们经常与 HiveMQ 合作。这种组合甚至可以在两种云产品之间提供完全可管理的集成。

话虽如此，但并不是所有的东西都可以或应该上（公共）云。安全性、延迟和成本往往使在数据中心或边缘（如智能工厂）部署成为首选或必选方案。混合架构可将两种方案结合起来，构建最具成本效益、可靠和安全的物联网基础设施。

自动化和安全是公有云的典型障碍

成功的关键，尤其是在混合架构中，是利用 CI/CD 和 GitOps 进行多集群管理的自动化和机群管理。许多项目利用 Kubernetes 作为边缘和私有云的云原生基础设施。不过，在公有云中，首选应始终是完全托管的服务（如果安全和其他要求允许的话）。

在采用完全托管的 MQTT 云服务时要小心： 各云供应商对 MQTT 的支持并不总是相同的。许多供应商并没有实施整个协议，遗漏了一些功能，并要求使用限制。

公共云采用 MQTT 最棘手的问题是安全性！尽早仔细检查需求。延迟、可用性或特定功能通常不是问题所在。部署和集成必须符合要求并遵循云战略。由于工业物联网项目总是必须包含某种边缘故事，因此它比销售或营销项目更难讨论。

趋势 2：MQTT 的数据治理

数据治理对整个企业都至关重要。从物联网和 MQTT 的角度来看，两个主要议题是作为概念的统一命名空间和作为技术的 Sparkplug B。

工业物联网的统一命名空间

在工业物联网（IIoT）的背景下，统一命名空间（UNS）通常是指在工业网络或生态系统中对设备、数据和资源进行命名和组织的一种标准化、有凝聚力的方式。其目的是提供一致的命名结构，促进互操作性、数据共享以及 IIoT 设备和系统的管理。

统一命名空间（在工业物联网中）一词是由工业物联网专家和内容创建者 Walker Reynolds 提出并推广的。

统一命名空间的概念

以下是工业物联网统一命名空间的一些关键方面：

• 设备命名： IIoT 环境中的设备可能来自不同的制造商，具有不同的功能。统一的命名空间可确保设备命名的一致性，使管理员、应用程序和其他设备更容易识别设备并与之交互。
  数据命名和标记： 物联网涉及大量数据的生成和交换。统一的命名空间包括与设备相关的数据点、变量或属性的标准化命名约定和标记机制。对于需要跨不同设备访问和解释数据的应用程序来说，这种一致性至关重要。

• 互操作性：统一的命名空间可为设备和系统通信提供通用框架，从而促进互操作性。当设备和应用程序遵循相同的命名约定时，就更容易将新设备集成到现有系统中或更换组件，而不会造成中断。

• 安全和访问控制：一个定义明确的命名空间可实现有效的访问控制机制，从而提高安全性。可根据标准化名称和层次结构实施安全策略，确保只有授权实体才能访问特定设备或数据。

• 管理和可扩展性：在大规模工业环境中，拥有统一的命名空间可简化设备和资源管理。它允许采用可扩展的解决方案，可以添加或更换新设备，而无需进行大量的重新配置。

• 语义互操作性：除了命名之外，统一命名空间还可包括语义定义和标准。这有助于实现语义互操作性，确保设备和系统理解它们所交换数据的含义和上下文。

总之，工业物联网中的统一命名空间就是为设备、数据和资源的命名建立一个通用的标准化结构，为高效、安全和可扩展的 IIoT 部署奠定基础。标准组织和行业联盟通常在制定和推广这些标准方面发挥作用，以确保在不同的工业生态系统中得到广泛采用和兼容。

Sparkplug B：MQTT 主题和有效载荷的互操作性和标准化通信

统一命名空间是互操作性的理论概念。Sparkplug B 是有效载荷结构执行的标准化实现。这是 Eclipse 基金会制定的规范，后来成为 ISO 标准。

Sparkplug B 提供了一套组织数据的约定，并为设备交换信息定义了一种通用语言。下面是 HiveMQ 的一个示例，描述了统一的命名空间如何使设备、系统和站点之间的通信变得更容易：

Sparkplug B 的主要特点包括

• 有效载荷结构： Sparkplug B 为 MQTT 消息的有效载荷定义了特定格式。该格式包括时间戳、数据类型和值等信息字段。这种标准化的有效载荷结构可确保设备能够始终如一地理解和解释所交换的数据。
• 主题命名空间： 该规范为 MQTT 消息定义了一个标准化的主题命名空间。这有助于对消息进行组织和分类，使设备更容易发现和订阅相关信息。
• 出生和死亡证明： Sparkplug B 引入了设备 “出生 “和 “死亡 “证书的概念。当设备上线时，它会发送包含自身信息的 “出生证明”。相反，当设备离线时，它会发送一份死亡证书。这种机制有助于监控 IIoT 网络中设备的状态。
• 状态管理： 该规范包括管理设备状态的功能。设备可以发布其当前状态，其他设备可以订阅以接收更新。这有助于在整个网络中保持设备状态的同步视图。

Sparkplug B 为工业环境中的 MQTT 通信提供了一个标准化框架，旨在提高 IIoT 部署的互操作性、可扩展性和效率。采用 Sparkplug B 可以简化工业生态系统中各种设备和系统的集成，促进无缝通信和数据交换。

Sparkplug B 的局限性

Sparkplug B 有一些局限性，例如

• 仅支持服务质量（QoS）0，最多只能保证一次信息传递。
• 主题命名空间结构的限制。
• 非常以设备为中心（但 MQTT 适用于许多 “事物”）。
• 了解 Sparkplug B 的优缺点。但对于其他一些情况来说，上述局限性是阻碍因素。特别是，对于关键任务用例而言，仅支持 QoS 0 是一个巨大的限制。

趋势 3：MQTT 与 OPC-UA 之争

与其他工业协议相比，MQTT 有很多优点。然而，OPC-UA 是物联网领域的另一种标准，其市场影响力至少不亚于 MQTT。关于选择正确的物联网标准的争论是有争议的，往往是由情绪和观点主导的，但讨论仍然是绝对有效的。

OPC-UA（开放平台通信统一架构）是一种用于工业自动化的机器对机器通信协议。它实现了各种工业环境中设备和系统之间无缝、安全的通信和数据交换。

OPC UA 已成为工业自动化和控制领域广泛采用的标准，为设备、机器和系统之间安全、可互操作的通信提供了基础。OPC UA 的开放性和行业组织的支持使其广泛应用于从制造和过程控制到能源管理等多个领域。

从 MQTT 和 OPC-UA 的承诺来看，两者有很多重叠之处：

• 可扩展
• 可靠
• 实时性
• 开放式
• 标准化

这两种标准都是如此。不过，权衡利弊还是存在的。我不会在这里挑起战火。只需搜索 “MQTT 与 OPC-UA”。您会发现许多博文、文章和视频。大多数人都很有主见（而且往往是由供应商推动的）。实际情况是，业界广泛采用了 MQTT 和 OPC-UA。

虽然上述特点在总体上对这两种标准都适用，但细节决定了具体实施的不同。例如，如果您尝试通过 OPC-UA 连接大量的西门子 S3 PLC，那么您很快就会发现并行连接的数量并不像 OPC-UA 标准规范告诉您的那样具有可扩展性。

何时选择 MQTT，何时选择 OPC-UA？

明确的建议是从业务问题入手，而不是从技术入手。评估两种标准及其实现、支持的接口、供应商的云服务等。然后选择正确的技术。

如果您必须开始技术讨论，以下是我使用的简化经验法则：

MQTT：用于连接物联网设备、车辆和其他接口的用例，支持轻量级基础设施、大量连接和/或不良网络。
OPC-UA：工业自动化用例，用于连接重型设备、PLC、SCADA 系统、数据记录器等。

这只是经验之谈。情况会发生变化。现代 PLC 和其他设备增加了对多种协议的支持，以提高灵活性。但如今，您很少有选择的余地，因为特定的设备、装置或车辆只支持其中一种。你仍然可以很高兴： 否则，您就需要使用另一个 IIoT 平台来连接 S3、Modbus 等专有传统协议。

趋势 4：用于 OT/IT 数据处理的 MQTT 和 Apache Kafka

与 MQTT 相反，Apache Kafka 并不是一个物联网平台。相反，Kafka 是一个事件流平台，它以事件驱动架构为基础，适用于各行各业的各种用例。它为消息传递、存储、数据集成和流处理提供了一个可扩展、可靠和弹性的实时平台。Apache Kafka 和 MQTT 是许多物联网用例的完美组合。

让我们从物联网的角度来探讨这两种技术的利弊。

MQTT 的利弊

MQTT 的优点：

• 轻量级
• 专为数千个连接而构建
• 支持所有编程语言
• 适用于连接不畅/高延迟的情况
• 高可扩展性和可用性（取决于代理实施）-ISO 标准
• 最流行的物联网协议（与 OPC UA 竞争）

MQTT 的缺点：

• 主要在物联网用例中采用
• 只有发布/子协议，不支持流处理
• 无法对事件进行再处理

Apache Kafka 的利弊权衡

Kafka 的优点：

• 流处理，而不仅仅是发布/订阅
• 高吞吐量
• 大规模
• 高可用性
• 长期存储和缓冲
• 事件再处理
• 与企业其他部门的良好集成

Kafka 的缺点

• 不适合数以万计的连接
• 需要稳定的网络和良好的基础设施
• 没有物联网特有的功能，如 keep alive, last will, or testament。

使用 Sparkplug 和 Kafka 进行 MQTT 数据治理（以及更多）

统一命名空间（Unified Namespace）和 Sparkplug B 的具体实施对于使用 MQTT 的物联网工作负载的数据治理非常有用。同样，模式注册中心也为 Apache Kafka 数据管道定义了数据合约。

模式注册（Schema Registry）应该是任何 Kafka 项目的基础！数据合约（又称模式，类似于 REST/HTTP API 中的 Swagger）可确保良好的数据质量以及 Kafka 生态系统中独立微服务之间的互操作性。每个业务部门及其数据产品可以选择任何技术或 API。但是，只有在数据质量良好（强制）的情况下，才能与他人共享数据。

您可以看到问题所在： 每种技术都使用自己的数据治理技术。如果您添加了自己喜欢的数据湖，就会添加另一个概念，如 Apache Iceberg，以定义分析存储系统的数据表。这也没关系！每个数据治理套件都针对其工作负载和要求进行了优化。在过去二十年中，全公司范围的主数据管理都失败了，因为每个软件类别都有不同的要求。

因此，我看到的一个明显趋势是在不同系统中采用企业范围的数据治理战略（采用 Collibra 或 Azure Purview 等技术）。它具有开放接口，并与特定的数据合约集成，如用于 MQTT 的 Sparkplug B、用于 Kafka 的 Schema Registry、用于 HTTP/REST 应用程序的 Swagger 或用于数据湖的 Iceberg。不要试图用单一技术解决整个企业范围的数据治理战略。这会失败的！我们以前见过这种情况…

Legacy PLC（S7、Modbus、BACnet 等）如何使用 MQTT 或 Kafka？

MQTT 和 Kafka 可在物联网和 IT 系统之间建立可靠、可扩展的端到端数据管道。至少，如果您能使用现代 API 和标准的话。如今，大多数物联网项目仍然是棕地项目。许多传统的 PLC、SCADA 系统和数据记录器只支持西门子 S7、Modbus、BACnet 等专有协议。

MQTT 或 Kafka 开箱即不支持这些传统协议。因此需要另一个中间件。通常，企业会为此选择专用的物联网平台。这意味着更高的成本和复杂性，以及更慢的项目进度。

在 Kafka 领域，如果你想用 Kafka 构建一个现代化的云原生数据历史学家，Apache PLC4X 是一个不错的开源选择。该框架提供了与许多传统协议的集成。它还提供了一个 Kafka Connect 连接器。主要问题是背后没有官方供应商支持。公司无法为关键任务应用购买全天候业务模式的支持。而这通常是任何工业部署的障碍。

由于 MQTT 只是一个发布/子消息代理，因此无法帮助实现传统协议集成。HiveMQ 尝试通过一个名为 “HiveMQ Edge：基于软件的工业边缘协议转换器 “的新框架来解决这一难题。这是一个年轻的项目，刚刚起步。其核心是开源的。第一个支持的传统协议是 Modbus。我认为这是一个很好的产品战略。我希望该项目能获得牵引力，并发展到支持许多其他传统 IIoT 技术，以实现棕地车间的现代化。实际上，该项目还支持 OPC-UA。我们将拭目以待该功能会带来多少需求。

物联网使用案例中的 MQTT 和 Sparkplug 采用率逐年增长

在物联网领域，MQTT 和 OPC UA 已成为工业物联网和工业 4.0 使用案例中数据交换的开放和平台独立标准。使用 Apache Kafka 的数据流是实时集成和处理任何规模的海量数据的数据枢纽。物联网中的数据流三位一体 “详细探讨了 MQTT、OPC-UA 和 Apache Kafka 的组合。

随着设备、设备、车辆和 IT 后端之间需要更多可扩展、可靠和开放的物联网通信，MQTT 的采用率逐年增长。MQTT 的优势在于不可靠的网络、轻量级（但可靠且可扩展）的通信和基础设施，以及与成千上万物联网的连接。

随着使用 Sparkplug B 的统一命名空间、全面管理的云服务以及与 Apache Kafka 的结合使用等趋势的成熟，MQTT 已成为制造、汽车、航空、物流和智慧城市等垂直领域最相关的物联网标准之一。

但不要被架构图和理论所迷惑。例如，MQTT 和 Sparkplug 的大多数图表都显示了与 ERP（如 SAP）和数据湖（如 Snowflake）的集成。您真的应该直接从 OT 世界集成到分析平台吗？大多数情况下，答案是否定的，因为成本、业务部门脱钩、法律问题和其他原因。这就是 MQTT 和 Kafka（或其他集成平台）组合的优势所在。

原文：https://dzone.com/articles/mqtt-market-trends