你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
多租户解决方案中的 IoT 体系结构方法
多租户 IoT 解决方案具有许多不同的风格和规模。 从基础结构所有权到客户数据隔离，再到符合性，你可能有许多要求和约束。 定义一个满足所有这些设计约束的模式可能很困难，这样做通常需要考虑多个维度。 本文介绍一些通常用于为基于 IoT 的解决方案解决多租户考虑因素的方法。 本文档包含了根据 IoT 参考体系结构利用通用组件的示例多租户体系结构。
关键考虑因素和要求
这些考虑因素和要求按照其在解决方案设计中通常的优先顺序呈现。
管理和符合性
治理和符合性考虑因素可能需要你使用特定模式或一组 IoT 资源。 并非所有 IoT 服务都具有相同的认证或功能。 如果需要满足特定符合性标准，可能需要选择特定服务。 有关治理和符合性的信息，请参阅有关该主题的专用文章。
IoT 中的治理还可能采用其他形式，例如设备所有权和管理。 是客户还是解决方案提供商拥有设备？ 谁拥有这些设备的管理权？ 这些考虑因素和影响对于每个解决方案提供商来说都是独一无二的，并且可能导致在所用技术、部署模式和多租户模式方面的不同选择。
缩放
规划解决方案的规模非常重要。 通常在以下三个维度上考虑规模：
设备数量：所有 Azure 设备管理服务（Azure IoT Central、Azure IoT 中心设备预配服务 (DPS) 和 Azure IoT 中心）对单个实例中支持的设备数量都有限制。
提示
如果计划部署海量设备，请参阅大规模文档。
设备吞吐量：不同设备（即使在同一解决方案中）可能具有不同的吞吐量要求。 此上下文中的“吞吐量”是指一段时间内的消息数和消息大小。 例如，在智能建筑解决方案中，恒温器报告数据的频率可能会低于电梯报告数据的频率，而在联网车辆解决方案中，车辆摄像头记录的数据消息可能会大于导航遥测消息。 如果消息在频率方面受到限制，则可能需要横向扩展到特定服务的更多实例，但如果消息在大小方面受到限制，则可能需要纵向扩展到特定服务的更大实例。
租户：单个租户的规模可能很小，但当乘以租户数时，它可能会快速增长。
性能和可靠性
租户隔离
完全共享的解决方案可能有近邻干扰。 对于 IoT 中心和 IoT Central，这可能会导致 HTTP 429（“请求过多”）响应代码，此代码表示存在可能导致级联效应的硬故障。 有关详细信息，请参阅配额和限制。
在完全多租户解决方案中，这些效应可能会级联。 当客户共享 IoT 中心或 IoT Central 应用程序时，共享基础结构上的所有客户都将开始收到错误。 由于 IoT 中心和 IoT Central 通常是发往云的数据的入口点，因此依赖于此数据的其他下游系统也可能会发生故障。 通常，发生这种情况的最常见原因是超出了消息配额限制。 在这种情况下，IoT 中心解决方案的最快和最简单的解决方法是升级 IoT 中心 SKU 并/或增加 IoT 中心单位数。 对于 IoT Central 解决方案，该解决方案会根据需要自动缩放，最多可缩放到此处记录的受支持消息数。
可以使用 DPS 的 自定义分配策略将租户隔离并分布到 IoT 控制平面、管理平面和通信平面中。 此外，当遵循大规模 IoT 解决方案指南时，可以在 DPS 负载均衡器级别管理其他分配分布。
数据存储、查询、使用情况和保留
IoT 解决方案往往是数据密集型的，无论是在流式传输数据时还是在数据处于静态时。 有关在多租户解决方案中管理数据的详细信息，请参阅多租户解决方案中存储和数据的体系结构方法。
安全性
IoT 解决方案通常需要考虑多层次的安全问题，尤其是在云修改的Purdue 企业参考体系结构或工业 4.0解决方案中部署的解决方案。 从以下方法中选择的设计方法将影响网络层和边界的存在；一旦选择了物理设计，就可以选择安全实现。 可用于任何方法的工具包括：
Microsoft Defender for IoT 是一个值得考虑的全面 IoT 监控解决方案，可为每台客户设备和/或站点提供每台设备 EIoT 许可证和 OT 站点许可证。 根据本文后面所选的方法，Microsoft 365 命名用户许可方案可能无法实现。 在这种情况下，可使用每台设备和站点许可证选项，而这些许可证选项独立于 Microsoft 365 租户许可证。
Azure 防火墙或第三方防火墙设备，应考虑使用它们来隔离网络层以及监控网络流量。 具体选择哪种方法，将影响工作负载的网络隔离与共享网络，如下所述。
Azure IoT Edge 或 Azure IoT 操作，应考虑将其作为设备连接到 Azure 托管服务的一部分，而无需将设备直接公开到直接 Internet 访问。 由于 Azure IoT 操作目前处于预览阶段，因此本文档不介绍该产品的一般使用。 本文档今后的修订版将解决此问题。
这些安全主题在多租户解决方案中的应用与在单租户解决方案中的应用类似，只是会因所选的方法而存在差异。 在整个 IoT 解决方案中，用户和应用程序身份识别是一个很可能大相径庭的组件。 多租户解决方案中的标识体系结构方法讨论了整体多租户解决方案的这一方面。
要考虑的方法
通常在 IoT 体系结构中对所有主要组件（例如管理、引入、处理、存储、安全等）需做出的所有考虑，都是你在寻求多租户解决方案时仍然必须做出的所有选择。 主要区别在于如何安排和利用这些组件来支持多租户。 例如，针对存储的常见决策点可能是决定是使用 SQL Server 还是 Azure 数据资源管理器，也可能是在引入和管理层上，你需在 IoT 中心和 IoT Central 之间进行选择。
大多数 IoT 解决方案都适合根体系结构模式，该模式是部署目标、租户模型和部署模式的组合。 这些因素取决于上述关键要求和考虑因素。
在 IoT 领域需要做出的最大决策点之一，是在应用程序平台即服务 (aPaaS) 和平台即服务 (PaaS) 方法之间进行选择。 有关详细信息，请参阅比较物联网 (IoT) 解决方案方法（PaaS 与 aPaaS）。
这是许多组织在许多项目中面临的常见“构建与购买”困境。 评估这两个选项的优点和缺点非常重要。
aPaaS 解决方案的概念和考虑因素
使用 Azure IoT Central 作为解决方案核心的典型 aPaaS 解决方案可能使用以下 Azure PaaS 和 aPaaS 服务：
- Azure 事件中心（作为跨平台的企业级消息传递和数据流引擎）。
- Azure 逻辑应用（作为集成平台即服务 (iPaaS) 产品/服务）。
- Azure 数据资源管理器（作为数据分析平台）。
- Power BI（作为可视化和报告平台）。
在上图中，租户共享 IoT Central 环境、Azure 数据资源管理器、Power BI 和 Azure 逻辑应用。
这种方法通常是将解决方案推向市场的最快方法。 这是一项通过使用组织来支持多租户的大规模服务。
重要的是要了解，由于 IoT Central 是一种 aPaaS 产品/服务，因此某些决策超出了实施者的控制范围。 这些决策包括：
- IoT Central 使用 Microsoft Entra ID 作为其标识提供程序。
- IoT Central 部署是使用控制和数据平面操作来实现的，这些操作将声明性文档与命令性代码相结合。
- 在多租户模式下，IoT Central 最大节点限制（适用于父节点和叶节点）和最大树深度都可能会强制服务提供商拥有多个 IoT Central 实例。 在这种情况下，应考虑遵循“部署缩放单元”模式。
- IoT Central 施加了 API 调用限制，这可能会影响大型实施。
PaaS 解决方案的概念和考虑因素
基于 PaaS 的方法可能会使用以下 Azure 服务：
- Azure IoT 中心（作为核心设备配置和通信平台）。
- Azure IoT 设备预配服务（作为设备部署和初始配置平台）。
- Azure 数据资源管理器（用于存储和分析来自 IoT 设备的暖路径和冷路径时序数据）。
- Azure 流分析（用于分析来自 IoT 设备的热路径数据）。
- Azure IoT Edge（用于在 IoT Edge 设备上运行 人工智能 (AI)、第三方服务或你自己的业务逻辑）。
在上图中，每个租户都连接到一个共享 Web 应用，该应用从 IoT 中心和函数应用接收数据。 设备连接到设备预配服务和 IoT 中心。
这种方法需要开发人员付出更多努力来创建、部署和维护解决方案（与 aPaaS 方法相比）。 为方便实施者而预先构建的功能较少。 这意味着此方法还提供更多的控制，因为基础平台中嵌入的假设更少。
根体系结构模式
下表列出了多租户 IoT 解决方案的常见模式。 每种模式包含以下信息：
- 模式的名称，它基于目标、模型和部署类型的组合。
- 部署目标，表示要将资源部署到的 Azure 订阅。
- 模式引用的租户模型，如多租户模型中所述
- 部署模式，指的是具有最少部署考虑因素的简单部署、地理节点模式或“部署缩放单元”模式。
| 模式 | 部署目标 | 租户模型 | 部署模式 |
|---|---|---|---|
| 简单 SaaS | 服务提供商的订阅 | 完全多租户 | 简单 |
| 横向 SaaS | 服务提供商的订阅 | 水平分区 | 部署缩放单元 |
| 单租户自动化 | 服务提供商的订阅或客户的订阅 | 每个客户一个租户 | 简单 |
简单 SaaS
| 部署目标 | 租户模型 | 部署模式 |
|---|---|---|
| 服务提供商的订阅 | 完全多租户 | 简单 |
简单 SaaS 方法是 SaaS IoT 解决方案的最简单实现。 如上图所示，所有基础结构都是共享的，并且基础结构未应用地理或缩放标记。 基础结构通常存在于单个 Azure 订阅中。
Azure IoT Central 支持组织的概念。 组织使解决方案提供商能够以安全、分层的方式轻松隔离租户，同时在所有租户之间共享基本应用程序设计。
使用冷路径或与业务运营部门的连接与 IoT Central 外部的系统进行的通信（例如，用于长期数据分析）通过其他 Microsoft PaaS 和 aPaaS 产品/服务完成。 这些附加产品/服务可能包括以下服务：
- Azure 事件中心（作为跨平台的企业级消息传递和数据流引擎）。
- Azure 逻辑应用（作为集成平台即服务 (iPaaS)）。
- Azure 数据资源管理器（作为数据分析平台）。
- Power BI（作为可视化和报告平台）。
如果将简单 SaaS 方法与单租户自动化 aPaaS 模型进行比较，则会发现许多特征都类似。 这两个模型之间的主要区别是，在“单租户自动化”模型中，需为每个租户部署不同的 IoT Central 实例，而在“带有 aPaaS 的简单 SaaS”模型中，则需为多个客户部署一个共享实例，并为每个租户创建一个 IoT Central 组织。
在此模型中共享多租户数据层时，需要实现行级安全性（如多租户解决方案中存储和数据的体系结构方法中所述），以便隔离客户数据。
优点：
- 与这里介绍的其他方法相比，更易于管理和操作。
风险：
此方法可能不容易扩展到海量设备、消息或租户。
由于所有服务和组件都是共享的，因此任何组件中的故障都可能会影响所有租户。 这会给解决方案的可靠性和高可用性带来风险。
请务必考虑如何管理设备的子机群的符合性、操作、租户生命周期和安全性。 这些考虑因素变得非常重要是因为此解决方案类型在控制、管理和通信平面上的共享性质。
横向 SaaS
| 部署目标 | 租户模型 | 部署模式 |
|---|---|---|
| 服务提供商的订阅 | 水平分区 | 部署缩放单元 |
常见的可伸缩性方法是对解决方案进行水平分区。 这意味着你有一些共享组件和一些“每客户”组件。
在 IoT 解决方案中，有许多组件可以水平分区。 水平分区的子系统通常是使用与更大解决方案集成的“部署缩放单元”模式安排的。
横向 SaaS 示例
以下体系结构示例将 IoT Central（充当设备管理、设备通信和管理门户）按每个最终客户进行分区。 通常采用的分区方式会让使用该解决方案的最终客户对自行添加、删除和更新设备拥有完全控制权，而无需软件供应商的干预。 该解决方案的其余部分遵循标准的共享基础结构模式，该模式解决了热路径分析、业务集成、SaaS 管理和设备分析需求。
每个租户都有自己的 IoT Central 组织，该组织将遥测数据发送到共享函数应用，并通过 Web 应用将遥测数据提供给租户的业务用户。
优点：
- 通常易于管理和操作，尽管单租户组件可能需要其他管理。
- 灵活的缩放选项，因为层是根据需要缩放的。
- 组件故障的影响会降低。 虽然共享组件故障会影响所有客户，但水平缩放的组件仅影响与特定缩放实例关联的客户。
- 改进了已分区组件的每租户消耗见解。
- 在组件已分区的情况下，更易于实现按每个租户进行自定义。
风险：
- 考虑解决方案的规模，尤其是对于任何共享组件。
- 可靠性和高可用性可能会受到影响。 共享组件中的单个故障可能会同时影响所有租户。
- 按租户分区的组件自定义需要长期 DevOps 和管理方面的考虑。
下面是通常适合于水平分区的最常见组件。
数据库
可以选择对数据库进行分区。 通常是对遥测和设备数据存储进行分区。 通常，多个数据存储用于不同的特定用途，例如暖存储与存档存储，或用于保存租户订阅状态信息。
为每个租户分隔数据库，从而获得以下优势：
- 支持符合性标准。 每个租户的数据在数据存储的实例之间隔离。
- 解决“近邻干扰”问题。
设备管理、通信和管理
Azure IoT 中心设备预配服务、IoT 中心和 IoT Central 应用程序通常可以部署为水平分区的组件。 如果遵循此方法，则需要有一个附加服务，用于将设备重定向到适用于该特定租户的管理、控制和遥测平面的设备预配服务。 有关详细信息，请参阅白皮书横向扩展 Azure IoT 解决方案以支持数百万台设备。
这样做通常是为了使最终客户能够管理和控制他们自己的设备群，这些设备群已更直接、完全地进行了隔离。
如果设备通信平面是水平分区的，则必须使用源租户的数据扩充遥测数据，以便流处理器知道要将哪些租户规则应用于数据流。 例如，如果遥测消息在流处理器中生成通知，则流处理器将需要确定关联租户的正确通知路径。
流处理
通过对流处理进行分区，可以在流处理器中实现对分析进行按租户自定义。
单租户自动化
单租户自动化方法基于与企业解决方案类似的决策过程和设计。
每个租户都有自己的相同且独立的环境，其中包含一个 IoT Central 组织和其他专用组件。
| 部署目标 | 租户模型 | 部署模式 |
|---|---|---|
| 服务提供商的订阅或客户的订阅 | 每个客户一个租户 | 简单 |
此方法中的一个关键决策点是选择组件应部署到的 Azure 订阅。 如果组件部署到你的订阅，你便可以更好地控制和更好地了解解决方案的成本，但这会要求你承担更多的解决方案安全和治理问题。 相反，如果解决方案部署在客户的订阅中，则客户最终负责部署的安全和治理。
此模式支持高度可伸缩性。 这是因为租户和订阅要求通常是大多数解决方案中的限制因素。 因此，请隔离每个租户，以便为缩放每个租户的工作负载提供更大的范围，而你作为解决方案开发人员则无需付出大量努力。
与其他模式相比，此模式下的延迟通常也较低，因为你可以根据客户的地理位置部署解决方案组件。 利用地理相关性可以使 IoT 设备与 Azure 部署之间的网络路径较短。
如有必要，可以通过允许为现有或新地理区域中的客户快速部署解决方案的额外实例，来扩展自动化部署以支持缩短延迟或扩大规模。
“单租户自动化”方法类似于简单 SaaS aPaaS 模型。 这两个模型之间的主要区别是，在“单租户自动化”方法中，需为每个租户部署不同的 IoT Central 实例，而在“带有 aPaaS 的简单 SaaS”模型中，则需部署一个包含多个 IoT Central 组织的 IoT Central 共享实例。
优点：
- 相对易于管理和操作。
- 租户隔离基本上有保证。
风险：
- 对于新的开发人员来说，初始自动化可能很复杂。
- 必须强制实施用于更高级别部署管理的跨客户凭据的安全性，否则入侵行为可能会在客户之间蔓延。
- 成本预计将更高，因为无法获得在客户之间共享的基础结构的规模优势。
- 如果解决方案提供商承担每个实例的维护，那么你可能有许多实例要维护。
增大 SaaS 的规模
将解决方案的规模扩展到非常大的部署时，会出现基于服务限制、地理问题和其他因素的特定难题。 有关大规模 IoT 部署体系结构的详细信息，请参阅横向扩展 Azure IoT 解决方案以支持数百万台设备。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Michael C. Bazarewsky | FastTrack for Azure 高级客户工程师
- David Crook | FastTrack for Azure 首席客户工程师
其他参与者：
- John Downs | 首席软件工程师
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
后续步骤
- 查看有关多租户和 Azure Cosmos DB 的指南。
- 了解 Azure 上的 IoT 热、暖和冷数据路径。
- 参阅 Azure IoT 参考体系结构。