轻量级、开放式的物联网消息协议MQTT已在各行业得到更广泛的采用。本博文探讨了 MQTT 的相关市场趋势：云部署和完全托管服务、使用统一命名空间和 Sparkplug B 的数据治理、MQTT 与 OPC-UA 辩论，以及与 Apache Kafka 集成以进行实时 OT/IT 数据处理.
HiveMQ 写了一篇很棒的文章展示了这一点。这篇文章有点过时了（当然，作为竞争的 MQTT 供应商，也很固执己见）。但它很好地表明了一些供应商提供的产品与良好的 MQTT 云解决方案相去甚远。
公有云采用MQTT最难的问题是安全！尽早仔细检查要求。延迟、可用性或特定功能通常不是问题。部署和集成需要合规并遵循云策略。由于工业物联网项目总是必须包含某种边缘故事，因此这是一个比销售或营销项目更艰难的讨论。
趋势 2：MQTT 数据治理
数据治理对于整个企业至关重要。从 IoT 和 MQTT 的角度来看，两个主要主题是作为概念的统一命名空间和作为技术的 Sparkplug B。
工业物联网统一命名空间
在工业物联网 (IIoT) 背景下，统一命名空间 (UNS) 通常是指在工业网络或生态系统中命名和组织设备、数据和资源的标准化且一致的方式。目标是提供一致的命名结构，促进 IIoT 设备和系统的互操作性、数据共享和管理。
“统一命名空间”一词（在工业物联网中）是由 Walker Reynolds 创造并推广的，工业物联网专家和内容创建者。
统一命名空间的概念
以下是工业物联网中统一命名空间的一些关键方面：
- 设备命名：IIoT 环境中的设备可能来自不同的制造商并具有不同的功能。统一的命名空间可确保设备的命名保持一致，从而使管理员、应用程序和其他设备更轻松地识别它们并与之交互。
- 数据命名和标记：IIoT 涉及大量数据的生成和交换。统一的命名空间包括与设备关联的数据点、变量或属性的标准化命名约定和标记机制。这种一致性对于需要跨不同设备访问和解释数据的应用程序至关重要。
- 互操作性：统一命名空间通过为设备和系统通信提供通用框架来促进互操作性。当设备和应用程序遵循相同的命名约定时，将新设备集成到现有系统或更换组件就会变得更加容易，而不会造成中断。
- 安全和访问控制：定义明确的命名空间通过启用有效的访问控制机制来提高安全性。安全策略可以基于标准化名称和层次结构来实施，确保只有授权实体才能访问特定设备或数据。
- 管理和可扩展性：在大规模工业环境中，拥有统一的命名空间可以简化设备和资源管理。它支持可扩展的解决方案，无需大量重新配置即可添加或更换新设备。
- 语义互操作性：除了命名之外，统一的命名空间还可能包括语义定义和标准。这有助于实现语义互操作性，确保设备和系统理解它们交换的数据的含义和上下文。
总体而言，工业物联网中的统一命名空间旨在建立一个通用且标准化的结构来命名设备、数据和资源，为高效、安全和可扩展的 IIoT 部署提供基础。标准组织和行业联盟经常在制定和推广这些标准方面发挥作用，以确保不同工业生态系统的广泛采用和兼容性。
Sparkplug B：MQTT 主题和负载的互操作性和标准化通信
统一命名空间是互操作性的理论概念。有效负载结构实施的标准化实现是 Sparkplug B。这是 Eclipse 基金会创建的规范，后来变成了 ISO 标准。
Sparkplug B 提供了一组用于组织数据和定义设备交换信息的通用语言的约定。这是 HiveMQ 示例描述了统一命名空间如何使设备、系统和站点之间的通信变得更容易：
来源：HiveMQ
Sparkplug B 的主要功能包括：
- 负载结构：Sparkplug B 定义了 MQTT 消息负载的特定格式。此格式包括时间戳、数据类型和值等信息字段。这种标准化的有效负载结构可确保设备能够一致地理解和解释正在交换的数据。
- 主题命名空间：该规范为 MQTT 消息定义了标准化主题命名空间。这有助于对消息进行组织和分类，使设备更容易发现和订阅相关信息。
- 出生证明和死亡证明：Sparkplug B 引入了设备“出生”和“死亡”证明的概念。当设备上线时，它会发送包含其自身信息的出生证明。相反，当设备离线时，它会发送死亡证书。此机制有助于监控 IIoT 网络内设备的状态。
- 状态管理：该规范包含管理设备状态的功能。设备可以发布其当前状态，其他设备可以订阅以接收更新。这有助于维护整个网络中设备状态的同步视图。
Sparkplug B 旨在通过为工业环境中的 MQTT 通信提供标准化框架来增强 IIoT 部署的互操作性、可扩展性和效率。它的采用可以简化工业生态系统内不同设备和系统的集成，促进无缝通信和数据交换。
Sparkplug B 的局限性
Sparkplug B 有一些限制，例如：
- 仅支持服务质量 (QoS) 0，最多提供一次消息传送保证。
-
主题命名空间结构的限制。
-
非常以设备为中心（但 MQTT 适用于许多“事物”）
了解 Sparkplug B 的优缺点。它非常适合某些用例。但上述限制对其他一些人来说是障碍。特别是，仅支持 QoS 0 对于关键任务用例来说是一个巨大的限制。
趋势 3：MQTT 与 OPC-UA 争论
与其他工业协议相比，MQTT 有很多优点。然而，OPC-UA 是物联网领域的另一个标准，它在市场上的吸引力至少与 MQTT 一样多。关于选择正确的物联网标准的争论是有争议的，通常是由情绪和观点主导的，但仍然绝对值得讨论。
OPC-UA（开放平台通信统一架构）是一种用于工业自动化的机器对机器通信协议。它可以在各种工业环境中的设备和系统之间实现无缝、安全的通信和数据交换。
OPC UA 已成为工业自动化和控制领域广泛采用的标准，为设备、机器和系统之间的安全和可互操作通信奠定了基础。其开放性和行业组织的支持有助于其在制造、过程控制、能源管理等领域的广泛应用。
如果你看看 MQTT 和 OPC-UA 的承诺，就会发现存在很多重叠：
- 可扩展
- 可靠
- 实时
- 打开
- 标准化
所有这些对于这两个标准都是正确的。尽管如此，权衡仍然存在。我不会在这里发动口水战。只需搜索“MQTT 与 OPC-UA”即可。您会发现许多博客文章、文章和视频。大多数人都非常固执己见（并且通常是由供应商驱动的）。现实情况是，业界广泛采用 MQTT 和 OPC-UA。
虽然上述特征对于这两个标准来说可能都是正确的，但细节对于特定的实现来说却是不同的。例如，如果您尝试通过 OPC-UA 连接大量西门子 S3 PLC，那么您很快就会意识到并行连接的数量并不像 OPC-UA 标准规范告诉您的那样可扩展。
何时选择 MQTT 与 OPC-UA？
明确的建议是从业务问题开始，而不是从技术开始。评估标准及其实现、支持的接口、供应商的云服务等。然后选择正确的技术。
如果您必须开始技术讨论，以下是我用作简化的经验法则：
- MQTT：互联 IoT 设备、车辆和其他接口的用例，支持轻量级基础设施、大量连接和/或不良网络。
- OPC-UA：用于连接重型设备、PLC、SCADA 系统、数据历史数据库等的工业自动化用例。
这只是一个经验法则。情况发生了变化。现代 PLC 和其他设备增加了对多种协议的支持，更加灵活。但是，如今，您几乎没有选择，因为特定的设备、装置或车辆仅支持其中之一。您仍然可以感到高兴：否则，您需要使用另一个 IIoT 平台来连接到 S3、Modbus 等专有旧协议。
MQTT 和 OPC-UA 陷阱
我从过去几个季度与世界各地的各种客户对话中意识到的一些额外问题：
- 理论上，MQTT 和 OPC-UA 可以很好地协同工作，即 MQTT 是 OPC-UA 的底层传输协议。我还没有在现实世界中看到过这一点（没有统计证据，只是我的个人经历）。但我看到的是 OPC-UA 的组合，用于最后一英里集成到 PLC，然后通过 MQTT 将数据转发给其他消费者。所有这些都在一个网关中，通常是专有的物联网平台。
- OPC-UA 为不同行业或用例定义了许多子标准。从理论上讲，这很棒。在实践中，我认为这更像是 SOAP/WSDL Web 服务世界中的 WS-* 地狱，其中大多数项目都迁移到更简单的 HTTP/REST 架构。同样，我看到的大多数 OPC-UA 集成都使用 Java 或其他编程语言中的简单自定义编码客户端，因为这些工具不支持复杂的标准。
- 物联网供应商在营销中宣传任何可能的集成场景。令我惊讶的是，MQTT 和 OPC-UA 平台直接与 SAP 等 MES 和 ERP 系统以及任何数据仓库和数据湖（如 Google Big Query、Snowflake 或 Databricks）集成。但这只是理论。你真的应该这样做吗？您是否尝试过将 SAP ECC 连接到 MQTT 或 OPC-UA？从技术角度来看，祝你好运，从组织角度来看，祝你好运。您是否希望 OT 世界和 ERP 之间紧密耦合和点对点通信？在大多数情况下，不同业务单元、领域和用例之间的关注点清晰分离是一件好事。选择合适的工具和企业架构；不仅仅是 POC 和第一个管道，而是整个长期战略和愿景。
最后一点让我想到了另一个不断增长的趋势：将用于物联网/OT 工作负载的 MQTT 和数据流与 Apache Kafka 相结合，以与 IT 世界集成。
趋势 4：用于 OT/IT 数据处理的 MQTT 和 Apache Kafka
与 MQTT 相反，Apache Kafka 不是一个物联网平台。相反，Kafka 是一个事件流平台，并使用 事件的基础 -跨行业各种用例的驱动架构。它为消息传递、存储、数据集成和流处理提供了可扩展、可靠且弹性的实时平台。 Apache Kafka 和 MQTT 是许多物联网用例的完美组合。
让我们从物联网的角度探讨这两种技术的优缺点。
MQTT 的权衡
MQTT 的优点：
- 轻量级
- 专为数千个连接而构建
- 支持所有编程语言
- 专为连接不良/高延迟场景而打造
- 高可扩展性和可用性（取决于代理实施）•ISO 标准
- 最流行的 IoT 协议（与 OPC UA 竞争）
MQTT 的缺点：
- 主要在物联网用例中采用
- 仅发布/订阅，不进行流处理
- 不重新处理事件
Apache Kafka 的权衡
卡夫卡的优点：
- 流处理，而不仅仅是发布/订阅
- 高吞吐量
- 大规模
- 高可用性
- 长期存储和缓冲
- 事件的重新处理
- 与企业其他部门的良好集成
卡夫卡的缺点：
- 并非为数万个连接而构建
- 需要稳定的网络和良好的基础设施
- 没有 IoT 特定功能，例如“保持活动状态”、“遗嘱”或“遗嘱”
MQTT 和 Kafka 的用例、架构和案例研究
我结合 Apache Kafka 撰写了有关 MQTT 的博客系列，其中包含更多技术细节和跨行业的实际案例研究。
第一篇博文探讨了 MQTT 和 Apache Kafka 之间的关系。随后，其他四篇博文讨论了各种用例、架构和参考部署。
- 第 1 部分 – 概述：Kafka 和 MQTT 之间的关系、优缺点、架构
- 第 2 部分 – 互联车辆：Kubernetes 私有云中的 MQTT 和 Kafka；用例：远程控制和命令汽车
- 第 3 部分 – 制造：智能工厂边缘的 MQTT 和 Kafka；使用案例：在 PLC、物联网网关、数据历史数据库、MES、ERP、数据湖等之间与 Sparkplug B 进行双向 OT-IT 集成。
- 第 4 部分 – 移动服务：利用无服务器云基础设施的 MQTT 和 Kafka；用例：使用机器学习的交通拥堵预测服务
- 第 5 部分 – 智慧城市：边缘的 MQTT 连接到公共云中完全托管的 Kafka；用例：通过组合和关联不同的第一方和第三方服务来实现智能流量路由
以下演示来自我在 MQTT 峰会上的演讲。它探讨了 MQTT 和 Apache Kafka 的各种用例和参考架构：
[pvfw-embedviewer_id=”5956″ width=”100%” height=”800″]
如果您的网络状况不佳、有数以万计的客户端，或者需要轻量级的基于推送的消息传递解决方案，那么 MQTT 是正确的选择。在其他方面，Kafka 这个强大的事件流平台可能是实时消息传递、数据集成和数据处理的正确选择。在许多物联网用例中，该架构结合了这两种技术。即使在工业领域，各种项目也使用 Kafka 进行用例，例如构建一个云原生数据历史学家或r实时状态监测和预测性维护。
使用 Sparkplug 和 Kafka（及其他）进行 MQTT 数据治理
统一命名空间和 Sparkplug B 的具体实现非常适合使用 MQTT 进行物联网工作负载中的数据治理。以类似的方式，架构注册表定义 Apache Kafka 数据管道的数据契约。
模式注册表应该是任何 Kafka 项目的基础！数据契约（又名模式，类似于 REST/HTTP API 中的 Swagger）在 Kafka 生态系统中的独立微服务之间强制执行良好的数据质量和互操作性。每个业务部门及其数据产品可以选择任何技术或API。但是，只有在良好（强制）数据质量的情况下，才能与他人共享数据。
您可以看到问题：每种技术都使用自己的数据治理技术。如果您添加您最喜欢的数据湖，您将添加另一个概念，例如 Apache Iceberg，来定义分析存储系统的数据表。没关系！每个数据治理套件都针对其工作负载和要求进行了优化。过去二十年里，全公司范围内的主数据管理失败了，因为每个软件类别都有不同的要求。
因此，我看到的一个明显趋势是跨不同系统的企业范围数据治理策略（使用 Collibra 或 Azure Purview 等技术）。它具有开放接口，并与特定数据合约集成，例如用于 MQTT 的 Sparkplug B、用于 Kafka 的架构注册表、用于 HTTP/REST 应用程序的 Swagger 或用于数据湖的 Iceberg。不要试图用单一技术解决整个企业范围的数据治理策略。它会失败！我们以前见过这个…
使用 MQTT 或 Kafka 的传统 PLC（S7、Modbus、BACnet 等）？
MQTT 和 Kafka 在物联网和 IT 系统之间实现可靠且可扩展的端到端数据管道。至少，如果您可以使用现代 API 和标准的话。如今，大多数物联网项目仍然处于棕地状态。许多传统 PLC、SCADA 系统和数据历史数据库仅支持西门子 S7、Modbus、BACnet 等专有协议。
MQTT 或 Kafka 不支持这些现成的旧协议。需要另一个中间件。通常，企业会为此选择专用的物联网平台。这意味着更高的成本和复杂性，以及更慢的项目。
在 Kafka 世界中，如果您想构建一个 使用 Kafka 的现代云原生数据历史记录。该框架提供了与许多遗留协议的集成。它提供了 Kafka Connect 连接器。主要问题是没有官方供应商支持。公司无法通过 24/7 业务模式购买关键任务应用程序的支持。这通常是任何工业部署的障碍。
由于 MQTT 只是一个发布/订阅消息代理，它无法帮助遗留协议集成。 HiveMQ 尝试使用名为 HiveMQ Edge 的新框架来解决这一挑战：基于软件的工业边缘协议转换器。这是一个年轻的项目，刚刚起步。核心是开源的。第一个受支持的传统协议是 Modbus。我认为这是一个非常好的产品策略。我希望该项目能够得到关注并不断发展，以支持许多其他传统工业物联网技术，从而实现棕地车间的现代化。该项目实际上也支持OPC-UA。我们将看到该功能也会创造多少需求。
物联网用例中 MQTT 和 Sparkplug 的采用率逐年增长
在物联网世界中，MQTT 和 OPC UA 已成为工业物联网和工业 4.0 用例中数据交换的开放且独立于平台的标准。 Apache Kafka 的数据流是用于实时集成和处理任何规模的海量数据的数据中心。 “物联网数据流三位一体探索 MQTT、OPC-UA 和 Apache Kafka 的组合”更详细。
随着设备、设备、车辆和 IT 后端之间对更具可扩展性、可靠和开放的 IoT 通信的需求，MQTT 的采用率逐年增长。 MQTT 的优点是不可靠的网络、轻量级（但可靠且可扩展）的通信和基础设施，以及与数千种事物的连接。
采用 Sparkplug B 的统一命名空间、完全托管的云服务以及与 Apache Kafka 的结合使用等日趋成熟的趋势，使 MQTT 成为制造、汽车、航空、物流和智能城市等垂直行业最相关的物联网标准之一。
但是不要被建筑图片和理论所愚弄。例如，MQTT 和 Sparkplug 的大多数图表显示了与 ERP（例如 SAP）和数据湖（例如 Snowflake）的集成。您真的应该直接从 OT 世界集成到分析平台吗？大多数时候，由于成本、业务部门脱钩、法律问题和其他原因，答案是否定的。这就是 MQTT 和 Kafka（或其他集成平台）组合的闪光点。
您现在如何使用 MQTT 和 Sparkplug？有哪些用例？您是否将其与 Apache Kafka 等其他技术相结合，以实现跨 OT/IT 管道的端到端集成？让我们在 LinkedIn 上联系并进行讨论！加入数据流社区并通过订阅我的时事通讯.
