您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

Azure IoT 参考体系结构

Blob 存储
函数
IoT 中心
逻辑应用
流分析

本参考体系结构说明了 Azure 上使用 PaaS(平台即服务)组件的 IoT 应用程序的建议体系结构。

体系结构图

IoT 应用程序可描述为发送生成 见解 的数据的 (设备)。 这些见解生成 操作 来改进业务或流程。 例如,一个发送温度数据的引擎(物)。 此数据用于评估引擎是否按预期工作(见解)。 该见解用于主动优先引擎的维护计划(操作)。

此参考体系结构使用 Azure PaaS(平台即服务)组件。 在 Azure 上生成 IoT 解决方案的另一个建议选项是:

  • Azure IoT Central。 IoT Central 是完全托管的 SaaS(软件即服务)解决方案。 它抽象出技术选择,让你专注于你的解决方案。 随这种简单性而来的是一种折衷:可自定义的程度会低于基于 PaaS 的解决方案。

概括而言,处理遥测数据的方式有两种:热路径和冷路径。 具体采用哪种方式与延迟和数据访问的要求有关。

  • 热路径 在数据到达时以近实时方式分析数据。 在热路径中,必须以非常低的延迟处理遥测数据。 热路径通常是使用流处理引擎实现的。 输出可能会触发一个警报,或写入为可以使用分析工具查询的结构化格式。
  • 冷路径 以较长的时间间隔(每小时或每天)执行批处理。 冷路径通常处理大量数据,但结果不需要与热路径一样及时。 在冷路径中,原始遥测数据会被捕获,然后馈送到批处理流程中。

体系结构

该体系结构包括以下组件。 某些应用程序可能不需要此处列出的每个组件。

IoT 设备。 设备可以安全地注册到云中,并且可以连接到云以发送和接收数据。 某些设备可能会是在设备本身上或在现场网关中执行一些数据处理的 边缘设备。 我们建议将 Azure IoT Edge 用于边缘处理。

云网关。 云网关提供一个云中心,以便设备安全地连接到云并发送数据。 它还提供设备管理功能,包括设备的命令和控制。 对于云网关,我们建议使用 IoT 中心。 IoT 中心是从设备引入事件的托管云服务,充当设备与后端服务之间的消息代理。 IoT 中心提供安全连接、事件引入、双向通信和设备管理。

设备预配。 对于注册和连接许多组设备,我们建议使用 IoT 中心设备预配服务 (DPS)。 DPS 可用于大规模分配设备并将设备注册到特定 Azure IoT 中心终结点。

流处理。 流处理分析数据记录的大型流,并评估这些流的规则。 对于流处理,我们建议使用 Azure 流分析。 流分析可以使用时间开窗函数、流聚合和外部数据源联接大规模执行复杂分析。 另一个选项是 Azure Databricks 上的 Apache Spark。

机器学习 允许对历史遥测数据执行预测算法,从而启用预测性维护等方案。 对于机器学习,我们建议使用 Azure 机器学习

暖路径存储 保留一些数据,这些数据必须可从设备中立即提供,以用于报告和可视化。 对于暖路径存储,我们建议使用 Cosmos DB。 Cosmos DB 是一种全球分布式多模型数据库。

冷路径存储 保留一些数据,这些数据会保留较长时间,用于批处理。 对于冷路径存储,我们建议使用 Azure Blob 存储。 数据可无限期地以较低成本在 Blob 存储中存档,并且可以轻松访问以进行批处理。

数据转换 操作或聚合遥测数据流。 示例包括协议转换,例如,将二进制数据转换为 JSON,或者合并数据点。 如果数据在到达 IoT 中心之前必须转换,我们建议使用协议网关(未显示)。 否则,数据可以在到达 IoT 中心后转换。 在这种情况下,建议使用 Azure Functions,因为它已内置了与 IoT 中心、Cosmos DB 和 Blob 存储的集成。

业务流程集成 根据来自设备数据的见解执行操作。 这可能包括:存储信息性消息、引发警报、发送电子邮件或短信,或者与 CRM 集成。 我们建议将 Azure 逻辑应用用于业务流程集成。

用户管理 限制哪些用户或组可以在设备上执行操作,例如升级固件。 它还定义应用程序中的用户功能。 我们建议使用 Azure Active Directory 对用户进行身份验证和授权。

适用于 IoT的安全监视 Azure 安全中心 为 IoT 工作负载提供端到端安全解决方案,并通过边缘和云提供统一的可见性和控制、自适应威胁防护以及跨叶设备以及云的智能威胁检测和响应来简化其保护。

可伸缩性注意事项

IoT 应用程序应作为可以独立缩放的独立服务构建。 请考虑以下可伸缩性要点:

IoTHub。 对于 IoT 中心,请考虑以下缩放因素:

  • 发送到 IoT 中心的消息的最大每日配额
  • IoT 中心实例中连接的设备的配额。
  • 引入吞吐量 — IoT 中心可以采用多快的速度引入消息。
  • 处理吞吐量 — 可以采用多快的速度处理传入消息。

每个 IoT 中心都在特定层中预配了特定单位数。 层和单位数决定了设备可以发送到中心的消息的最大每日配额。 有关详细信息,请参阅“IoT 中心配额和限制”。 可以纵向扩展中心而无需中断现有操作。

流分析。 如果流分析作业在流分析管道中的所有方面(从输入到查询到输出)都是并行的,那么它们的扩展效果最佳。 完全并行的作业使流分析可以将工作拆分到多个计算节点上。 否则,流分析必须将流数据合并到一个位置。 有关详细信息,请参阅利用 Azure 流分析中的查询并行化

IoT 中心自动基于设备 ID 对设备消息进行分区。 所有来自某一特定设备的消息将始终到达同一分区,但单个分区将具有来自多个设备的消息。 因此,并行化的单元是分区 ID。

函数。 从事件中心终结点进行读取时,每个事件中心分区都有函数实例的上限。 该最大处理速率取决于一个函数实例可以采用多快的速度处理来自单个分区的事件。 此函数应成批处理消息。

Cosmos DB。 若要横向扩展 Cosmos DB 集合,请使用分区键创建集合,并将该分区键包含在你编写的每个文档中。 有关详细信息,请参阅选择分区键时的最佳做法

  • 如果按设备存储和更新单个文档,那么设备 ID 就是不错的分区键。 写入操作将均匀分布于这些键。 每个分区的大小是受严格限制的,因为每个键值都有单个文档。
  • 如果为每个设备消息都存储一个单独的文档,那么使用设备 ID 作为分区键将很快超过每分区 10 GB 的限制。 在这种情况下,消息 ID 是更好的分区键。 通常仍应将设备 ID 包含在文档中,以便进行索引和查询。

Azure 时序见解 (TSI) 是一种用于时序数据的分析、存储和可视化服务,提供类似 SQL 的筛选和聚合等功能,从而减轻了用户定义函数需求。 时序见解提供 用于可视化和查询数据的数据资源管理器,以及 REST 查询 API。 除了时序数据之外,TSI 还非常适合需要查询大型数据集聚合的解决方案。 支持多层存储、丰富的 API、模型及其与 Azure IoT 生态系统、可视化资源管理器的集成,以及通过 Power BI 扩展性等。TSI 是有关时序数据存储和分析的建议。

安全注意事项

可信和安全通信

从设备接收的所有信息和发送到设备的所有信息都必须都是可信的。 除非设备可以支持以下加密功能,否则它都应限制到本地网络,并且所有网间通信都应经过现场网关:

  • 采用已证实安全、经过公开分析并且已广泛实现的对称密钥加密算法的数据加密。
  • 采用已证实安全、经过公开分析并且已广泛实现的对称密钥加密算法的数字签名。
  • 支持用于 TCP 或其他基于流的通信路径的 TLS 1.2,或者支持用于基于数据报的通信路径的 DTLS 1.2。 支持 X.509 证书处理是可选的,可由在计算方面和传输方面更高效的 TLS 预共享密钥模式替换,该模式可以在具有对 AES 和 SHA-2 算法的支持时实现。
  • 可更新的密钥存储和每个设备的密钥。 每个设备必须具有唯一的密钥材料或向系统标识其身份的令牌。 设备应在设备上安全存储密钥(例如,使用安全的密钥存储)。 设备应能够定期更新密钥或令牌,或在紧急情况(例如系统入侵)下响应性地更新密钥或令牌。
  • 设备上的固件和应用程序软件必须允许更新,以实现修复已发现的安全漏洞。

但是,许多设备太受限制,无法支持这些要求。 在这种情况下,应使用现场网关。 设备通过局域网安全地连接到现场网关,并且网关实现与云的安全通信。

防止物理篡改

强烈建议设备设计包含防御物理操作尝试的功能,以帮助确保整个系统的安全完整性和可信度。

例如:

  • 选择提供安全存储和加密密钥材料(例如受信任的平台模块和 TPM 集成)的微控制器/ (或) 硬件。
  • 保护启动加载程序并保护软件加载(在 TPM 中定位)。
  • 使用传感器检测入侵尝试以及对操纵设备环境的尝试,并在检测到这些尝试时发出警报或可能执行设备的“数字式自破坏”。

有关其他安全注意事项,请参阅物联网 (IoT) 安全体系结构

监视和日志记录

日志记录和监视系统用于确定解决方案是否正常工作,并且用来帮助排查问题。 监视和日志记录系统帮助回答以下运行问题:

  • 设备或系统是否处于错误状况?
  • 设备或系统是否已正确配置?
  • 设备或系统是否在生成准确的数据?
  • 系统是否满足商业客户和最终客户的预期?

日志记录和监视工具通常包括以下四个组成部分:

  • 系统性能和时间线可视化工具,用于监视系统以及进行基本的故障排除。
  • 缓冲的数据引入,用于缓冲日志数据。
  • 持久性存储,用于存储日志数据。
  • 搜索和查询功能,用于在执行详细故障排除时查看日志数据。

监视系统提供对 IoT 解决方案的运行状况、安全性和稳定性以及性能的见解。 这些系统还可以提供更详细的视图,记录组件配置更改并提供已提取的日志记录数据,以便揭示潜在的安全漏洞、改进事件管理流程并帮助系统的所有者排查问题。 全面的监视解决方案包括在特定子系统中查询信息或跨多个子系统进行聚合的功能。

开发监视系统时应首先定义正常操作、法规遵从性和审核要求。 收集的指标可包括:

  • 报告配置更改的物理设备、边缘设备和基础设施组件。
  • 报告托管语言的配置更改、安全审核日志、请求速率、响应时间、错误率和垃圾回收统计信息的应用程序。
  • 报告查询和写入性能、架构更改、安全审核日志、锁或死锁、索引性能以及 CPU、内存与磁盘使用情况的数据库、持久性存储和缓存。
  • 报告可影响依赖系统运行状况和性能的运行状况指标和配置更改的托管服务(IaaS、PaaS、SaaS 和 FaaS)。

监视指标的可视化,这些指标用于向操作员发出警报,提醒其注意系统的不稳定状况,并促进事件响应。

跟踪遥测数据

跟踪遥测数据使操作员可以跟踪一段遥测数据从创建起在该系统中经历的整个过程。 跟踪对于调试和故障排除而言十分重要。 对于使用 Azure IoT 中心和 IoT 中心设备 SDK 的 IoT 解决方案,跟踪数据报可以源自云到设备的消息并包含在遥测数据流中。

Logging

日志记录系统对于了解解决方案执行了哪些操作或活动、已发生的故障而言不可或缺,并可提供帮助来排除这些故障。 可以对日志进行分析,以帮助了解和纠正错误状况、增强性能特性,并确保符合管控规则和法规。

虽然纯文本日志记录对前期开发成本的影响较低,但它对于计算机进行分析/读取而言更具挑战性。 我们建议使用结构化日志记录,因为收集的信息既可供计算机分析,又可供用户阅读。 结构化日志记录会将情况上下文和元数据添加到日志信息。 在结构化日志记录中,属性是支持所有常见操作的实体,已格式化为键/值对或具有固定架构,以增强搜索和查询功能。

DevOps 注意事项

使用基础结构即代码 (IaC) 。 IaC 是使用声明性 (管理基础结构网络、虚拟机、负载均衡) 连接拓扑。 模板应进行版本控制,并属于发布管道。 最可靠的部署过程是自动化且幂等的。 一种方法是创建 Azure 资源管理器模板 来预配 IoT 资源和基础结构。

若要自动进行基础结构部署,可以使用 Azure DevOps Services、Jenkins 或其他 CI/CD 解决方案。 Azure PipelinesAzure DevOps Services 的一部分,可运行自动化的生成、测试和部署。

请考虑通过部署到各个阶段并在每个阶段运行验证,然后再转到下一个阶段,来暂存工作负荷;这样,你就可以以高度控制的方式将更新推送到生产环境,并最大程度地减少意外的部署问题。 对于更新实时生产环境,建议使用蓝绿色部署和非配置的部署策略。 此外,请考虑在部署失败时为其提供良好的回退策略;例如,你可以从你的部署历史记录中自动重新部署以前的、成功的部署,Azure CLI 中的--error 标志参数就是个好示例。

请考虑使用 Azure Monitor监视解决方案。 Azure Monitor 是所有 Azure 服务的监视和日志记录的主要来源,它为 Azure 资源提供诊断信息。 例如,可以监视 IoT 中心内发生的操作。 Azure Monitor 支持的特定指标和事件,以及 Azure 诊断日志的服务、架构和类别。

有关详细信息,请参阅 Microsoft Azure Well-Architected Framework中的 DevOps 部分。

成本注意事项

通常,使用 Azure 定价计算器 来估算成本。 其他注意事项,请参阅 Microsoft Azure Well-Architected 框架的 "成本" 部分。

有多种方法可以优化此参考体系结构中使用的服务相关的成本。

Azure IoT 中心

在此体系结构中,IoT 中心是从设备引入事件的云网关。 IoT 中心计费因操作类型而异。 创建、更新、插入、删除是免费的。 成功的操作(如设备到云和云到设备的消息)会收费。

成功发送的设备到云消息在进入 IoT 中心时按 4 KB 区块收费。 例如,6 KB 的消息按两条消息收费。

IoT 中心在设备孪生 JSON 文档中维护有关每个已连接设备的状态信息。 设备孪生文档中的读取操作需要付费。

IoT 中心提供两个层:基本层和****标准层

如果 IoT 体系结构使用 双向通信功能,请考虑使用标准层。 此层还提供最适用于测试目的的免费版本。

如果只需要从设备到云的单向通信,请使用"基本"层,该层更经济实惠。

有关详细信息,请参阅 IoT 中心定价

Azure 流分析

Azure 流分析流处理和规则评估。 Azure 流分析按每小时 SU (SU) 数进行定价,这将占用处理数据所需的计算、内存和吞吐量。 Azure IoT Edge 流分析按作业计费。 无论作业状态如何、运行、失败或已停止,流分析作业部署到设备时,都会开始计费。

有关定价的详细信息,请参阅 流分析定价

Azure Functions

Azure Functions在到达 IoT 中心后转换数据。 从成本的角度来看,建议使用消耗 计划 ,因为只需为使用的计算资源付费。 每次事件触发函数执行时,将基于每秒资源消耗进行收费。 在单个执行或批处理中处理多个事件可以降低成本。

Azure 逻辑应用

在此体系结构中,逻辑应用用于业务流程集成。

逻辑应用定价适用于即用即付模型。 每次运行逻辑应用时,都会计量触发器、操作和连接器的执行。 所有成功和失败的操作(包括触发器)都视为执行。

例如,逻辑应用一天处理1000消息。 5个操作的工作流将成本低于 $6。

有关详细信息,请参阅 逻辑应用定价

数据存储

对于冷路径存储,Azure Blob 存储是最具成本效益的选项。

对于热路径存储,请考虑使用 Azure Cosmos DB。 有关详细信息,请参阅 Cosmos DB 定价

后续步骤