你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure IoT 操作的内置本地 MQTT 代理

重要

本页包含使用 Kubernetes 部署清单(目前为预览版)管理 Azure IoT 操作组件的说明。 此功能存在若干限制,不应该用于生产工作负载。

有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款,请参阅 Microsoft Azure 预览版的补充使用条款

Azure IoT 操作具有符合标准的企业级 MQTT 代理,该代理可缩放、高度可用且是 Kubernetes 原生。 它为 Azure IoT 操作提供消息传送平面,支持双向边缘/云通信,并为边缘的事件驱动型应用程序提供支持。

MQTT 合规性

消息队列遥测传输 (MQTT) 已成为 IoT 空间协议中的通用语。 MQTT 的简单设计允许单个代理同时为数以万计的客户端提供服务,并创建和管理轻型发布-订阅主题。 许多 IoT 设备支持本机现成的 MQTT,下游转换网关将 IoT 协议的长尾合理化为 MQTT。

MQTT 代理在 IoT 操作中支撑消息层,并支持 MQTT v3.1.1 和 MQTT v5。 有关支持的 MQTT 功能的详细信息,请参阅 MQTT 代理中的 MQTT 功能支持

体系结构

MQTT 代理有两个主要层:

  • 无状态前端层。
  • 有状态和分片后端层。

前端层处理客户端连接和请求,并将其路由到后端。 后端层按不同的键对数据进行分区,例如客户端会话的客户端 ID,以及主题消息的主题名称。 它使用链复制以复制每个分区中的数据。

体系结构的目标包括:

  • 容错和隔离:如果后端 Pod 发生故障,消息发布会继续并阻止故障传播到系统的其余部分
  • 故障恢复:自动故障恢复,无需操作员干预
  • 无消息丢失:如果分区中至少有一个前端 Pod 和一个后端 Pod 正在运行,则消息可送达
  • 弹性缩放:发布和订阅吞吐量的水平缩放以支持边缘和云部署
  • 大规模一致的性能:由于链复制,限制消息延迟开销
  • 操作简单性:对外部组件的依赖最少,以简化维护和复杂性

配置

对于配置,MQTT 代理由多个 Kubernetes 自定义资源组成,这些资源定义了代理的行为和功能的不同方面。

  • 主要资源是代理,用于定义全局设置,例如基数、内存使用量配置文件和诊断设置。
  • 一个代理最多可以有三个 BrokerListener,每个侦听指定服务类型(NodePort、LoadBalancer 或 ClusterIP)上的传入 MQTT 连接。 每个 BrokerListener 可以有多个端口。
  • BrokerListener 中的每个端口都可以与 BrokerAuthentication 资源和 BrokerAuthorization 资源相关联。 这些是身份验证和授权策略,用于确定哪些客户端可以连接到端口,以及他们可以在代理上执行的操作。

因此,代理与 BrokerListener 之间的关系是“一对多”,BrokerListener 与 BrokerAuthentication/BrokerAuthorization 之间的关系是“多对多”。 这些资源的实体关系图 (ERD) 如下所示:

关系图显示代理资源模型。

默认情况下,Azure IoT 操作部署默认代理默认 BrokerListener默认 BrokerAuthentication。 所有这些资源都命名为 default。 这些资源共同提供了 Azure IoT 操作正常运行所需的基本 MQTT 代理设置。 默认设置如下所示:

关系图显示默认代理资源和它们之间的关系。

重要

为了防止 Azure IoT 操作内部组件之间的通信意外中断,建议不要修改任何默认配置。

若要自定义 MQTT 代理部署,请将新资源(如 BrokerListeners、BrokerAuthentication 和 BrokerAuthorization)添加到默认代理

代理资源本身是不可变的,在部署后无法修改,但它只需要在高级方案中进行自定义。 若要详细了解如何自定义代理资源,请参阅自定义默认代理

在完整部署中,可以有多个 BrokerListener,每个都有多个端口,每个端口可以具有与之关联的不同 BrokerAuthentication 和 BrokerAuthorization 资源。

例如,从默认设置开始,可以添加:

  • 一个名为 example-lb-listener 的 LoadBalancer BrokerListener,其包含两个端口 1883 和 8883
  • 一个名为 example-nodeport-listener 的 NodePort BrokerListener,其包含单个端口 1884 (nodePort 31884)
  • 一个名为 example-authn 的 BrokerAuthentication 资源,其使用自定义身份验证方法
  • 一个名为 example-authz 的 BrokerAuthorization 资源,其使用自定义授权设置

然后,如果配置所有新端口都使用相同的 BrokerAuthentication 和 BrokerAuthorization 资源,则设置将如下所示:

关系图显示完整的自定义代理部署和每个代理之间的关系。

这样就可以保持默认设置不变,然后添加新资源,以根据需要自定义 MQTT 代理部署。

默认代理资源

每个 Azure IoT 操作部署只能有一个代理,并且必须将其命名为 default。 Azure IoT 操作正常运行需要默认代理资源。 它是不可变的,在部署后无法修改。

注意

请勿删除默认代理资源。 这样做会中断 Azure IoT 操作内部组件之间的通信,并且部署将停止运行。

自定义默认代理

大多数设置不需要自定义默认代理资源。 需要自定义的设置包括:

  • 基数:决定代理处理更多连接和消息的能力,并在出现 Pod 或节点故障时增强高可用性
  • 内存配置文件:设置代理的最大内存使用量,以及如何在代理纵向扩展时处理内存使用量
  • 磁盘支持的消息缓冲区:配置在 RAM 填满时将消息缓冲到磁盘
  • 诊断设置:配置诊断设置,如日志级别和指标终结点
  • 高级 MQTT 客户端选项:配置高级 MQTT 客户端选项,例如会话过期、消息过期和保持活动状态设置
  • 内部流量加密:配置加密在代理前端和后端 Pod 之间的内部流量

在初始部署期间必须使用 Azure CLI 或 Azure 门户自定义默认代理。 如果需要不同的代理配置设置,则需要新的部署。

若要在部署期间自定义默认代理,请执行以下操作:

按照以下指南部署 Azure IoT 操作时,请在“配置”部分的“MQTT 代理配置”下进行查看。 在这里,可以自定义基数和内存配置文件设置。 若要配置其他设置(包括磁盘支持的消息缓冲区和高级 MQTT 客户端选项),请使用 Azure CLI。

查看默认代理设置

若要查看默认代理的设置,请执行以下操作:

  1. 在 Azure 门户中,转到 Azure IoT 操作实例。
  2. 在“组件”下,选择“MQTT 代理”
  3. 在“代理详细信息”下,选择“JSON 视图”

后续步骤

将 Azure IoT 操作部署到已启用 Arc 的 Kubernetes 群集