Google Cloud 上的 IoT 平台产品架构

Last reviewed 2024-08-09 UTC

IoT 平台产品通常提供基本 MQTT 和 HTTPS 数据连接。它们还允许您预配设备，并提供身份验证和管理、遥测存储和可视化、数据处理和提醒。当独立的 MQTT 代理不足以满足使用场景的需求，需要更完整的 IoT 平台产品时，组织通常会使用 IoT 平台。IoT 平台提供了一个统一的界面，可用于管理异构设备集合。此界面对于许多已连接的设备应用非常重要，它是 IoT 平台与独立 MQTT 代理之间的主要区别。本文档概述了在 Google Cloud 上部署 IoT 平台产品架构之前需要考虑的基本架构注意事项和建议。

本文档是系列文档中的一篇，该系列介绍了 Google Cloud 上的 IoT 架构。本系列中的其他文档包括以下内容：

下图展示了在 Google Cloud 上运行的一般 IoT 平台产品的示例架构。

一般 IoT 平台架构（在以下文本中说明事件流）。

如上图所示，IoT 平台为设备连接部署了 MQTT 代理或端点。该 IoT 平台连接到外部代理网络负载均衡器，以分配来自边缘设备的流量。其他 IoT 应用可以通过 Pub/Sub 或使用 Dataflow MQTT 连接器连接到 IoT 平台。

该 IoT 平台提供一组设备管理服务。如图中所示，这些服务如下：

  • 设备凭据存储空间
  • 规则引擎
  • 设备身份验证和授权
  • 设备配置管理
  • 设备注册表
  • 设备更新管理

IoT 平台产品通常还包括数字孪生功能、低代码开发界面、提醒和通知功能以及其他分析功能等服务。

架构注意事项和选择

以下各部分介绍了您可为 IoT 平台产品架构选择的架构，以及这些选择的影响。

注入端点

大多数商业 IoT 平台应用都包含一个 MQTT 端点，通常也是一个 HTTPS 端点，用于从已连接的设备注入数据。

MQTT

IoT 平台通过下面其中一种方法实现 MQTT 端点：

  • MQTT 与其他消息服务之间的连接器
  • 实现完整 MQTT 规范的 MQTT 代理

在评估商业 IoT 平台时，请务必了解供应商为产品选择了前面的哪些方法，以便确定对您的使用场景的影响。

在某些情况下，MQTT 端点仅将 MQTT 客户端与后端消息传递服务（例如 Kafka 或 Pub/Sub）连接。这种类型的端点通常不会实现完整的 MQTT 协议规范，并且通常不包含 QoS 级别 1 和 2 等功能或共享订阅。这种方法的优势在于，它可以降低 IoT 平台的复杂性，因为没有单独的 MQTT 代理应用。与平台使用单独的 MQTT 代理相比，运营费用更低，维护更简单。但是，由于对更先进的 MQTT 协议功能的支持较少，因此与实现完整 MQTT 规范的独立 MQTT 代理相比，MQTT 消息传输的灵活性和功能较少。

其他 IoT 平台提供完整的 MQTT 代理作为平台的一部分，如本文档中的示例架构所示。此代理可以是现有开源代理之一，也可以是专有代理实现。完整的 MQTT 代理可提供前面介绍的完整双向 MQTT 功能，但完整的代理可能会增加 IoT 平台管理的复杂性和运营费用。

HTTPS 和其他补充协议

除了 MQTT 之外，许多 IoT 平台提供的数据都比本文档介绍的主要架构中显示的数据注入端点提供的数据多。

HTTPS 是用于已连接的设备使用场景的 MQTT 的常见替代协议。它比 MQTT 的开销更高，但是受移动设备（如手机）以及网络浏览器和其他应用更广泛的支持。它通常用于某些已连接的设备应用，并且受 Eclipse Hono 等开源平台和许多商业产品的支持。

许多受限设备应用将（受限应用协议 (CoAP)（在 RFC 7252 中定义））用作 MQTT 替代方案。CoAP 面向嵌入式设备和传感器的低开销和小型客户端。许多商业 IoT 平台应用还提供 CoAP 端点。

负载均衡

如需详细了解如何为架构选择最佳负载均衡器，请参阅 Google Cloud 上独立 MQTT 代理架构的负载均衡部分，因为这些注意事项也适用于此情况。

设备身份验证和凭据管理

管理设备凭据和身份验证是 IoT 平台运维的关键部分。连接的设备支持的身份验证方法因应用和设备类型而异。为目标使用场景选择合适的身份验证方法并正确实施所选的身份验证方案非常重要。

与独立的 MQTT 代理不同，IoT 平台提供集成式服务来管理设备身份和凭据。大多数 IoT 平台都使用 X.509 客户端证书身份验证进行身份验证、基于 JWT 令牌的身份验证（通常与 OAuth 2.0 结合使用）以及用户名和密码身份验证。有些平台还支持与外部 LDAP 身份验证提供商集成。

对于某些受限设备，JWT 或用户名和密码身份验证可能更合适，因为这些架构需要已连接的设备上较少的资源。使用 JWT 或用户名和密码身份验证时，请务必独立于 mTLS 身份验证对网络连接进行加密，因为这两种身份验证方法都不需要加密连接。相比之下，X.509 证书身份验证会占用已连接的设备上的更多资源，但通常用于 mTLS 加密连接，因此可提供高级别的安全性。

在制造时在边缘设备上预配身份验证凭据也是已连接的设备身份验证方案的重要组成部分，但不在本文档的讨论范围内。

如需详细了解身份验证和凭据管理，请参阅在 Google Cloud 上运行 IoT 后端的最佳做法。

管理已连接的设备

通常，已连接的设备通过其中一个注入端点（例如 MQTT）将遥测事件和状态信息发布到平台。如果您使用的是多协议 IoT 平台，设备可以使用任何受支持的协议进行通信。

我们建议您的组织使用具有以下功能的 IoT 平台：

  • 软件和系统更新：传送和回滚对已连接的设备的固件、软件和应用更新。这些更新通常还涉及更新本身的存储和管理。
  • 配置更新：传送、存储和回滚对在已连接的设备上部署的应用配置的更新。
  • 创建和管理凭据：创建新设备凭据、将这些凭据传送到已连接的设备、设备访问尝试和活动的审核，以及在合适的时间撤消遭到破解或已过期的凭据。
  • 规则引擎和数据处理：定义和执行数据驱动型规则和其他数据处理步骤。此功能通常包含某种类型的低代码接口，用于定义规则和数据处理流水线。

后端工作负载

大多数 IoT 平台都提供自己的内部数据存储和传输功能，可让您连接到后端工作负载和应用。AMQP、RabbitMQ 和 Kafka 通常用于提供内部数据传输。所有这些都可以使用 Pub/Sub SDK 连接到 Pub/Sub。您还可以使用 PostgreSQL 等集成式数据库系统来存储数据。在许多情况下，IoT 平台可以配置为直接使用其中一个 Cloud Storage 产品，例如 Cloud SQL、Firebase 或 BigQuery。

如果 IoT 平台具有完整的 MQTT 代理，后端应用还可以使用平台 MQTT 功能与设备进行通信。如果应用支持 MQTT，则应用可以作为订阅者与代理连接。如果没有 MQTT 支持，Apache Beam 会提供 MQTT 驱动程序，其可实现与 Dataflow 以及其他 Beam 部署的双向集成。

使用场景

以下部分介绍了 IoT 平台比独立 MQTT 代理或与 Pub/Sub 直接连接更好的架构选择。

智能设备管理

管理多个虚拟设备的应用非常适合 IoT 平台。此类应用的一个示例是用于管理洗碗机和咖啡机等厨房设备的平台。这些设备通常基于 Wi-Fi 或通过使用蓝牙低功耗 (BLE) 或其他本地协议的本地网关直接连接到云端应用。IoT 平台的管理功能对于监控每个设备的状态、管理软件更新和安全补丁以及捕获设备活动来为制造商和客户提供关键情报至关重要。这些功能超出了基本 MQTT 代理的范围。至少设备信息仓库、设备状态数据库、遥测数据存储区和分析接口对于构建成功的虚拟设备平台至关重要。

物流和资产跟踪

对于物流和资产跟踪应用，IoT 平台产品提供比基本 MQTT 代理更完整的功能，因此更适合此使用场景。监控大型资源的当前状态和过往状态以及位置依赖强大的设备状态数据库和身份管理系统。部署新资源时，需要将它们与平台连接起来并尽可能减少摩擦，以及后续在整个资源生命周期内对进行监控。在许多情况下，应用还会收集有关资产的其他传感器信息，例如本地温度、湿度和大气压力，或 3D 定位和加速度数据以检测意外移动或下降。必须将这些数据注入所有后端应用并将数据与正确的资产相关联以便进行分析，因此 IoT 平台提供的功能全面的设备管理是一项重要的功能。

后续步骤