你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
基于 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 防火墙 或非 Microsoft 防火墙设备，应考虑用于隔离网络层并监视网络流量。 方法的确切选择决定了工作负载在何处具有网络隔离与共享网络，如本文后面部分所述。
这些安全主题在多租户解决方案中的应用与在单租户解决方案中的应用类似，只是会因所选的方法而存在差异。 在整个 IoT 解决方案中，用户和应用程序身份识别是一个很可能大相径庭的组件。 多租户解决方案中的标识体系结构方法讨论了整体多租户解决方案的这一方面。
要考虑的方法
对于单租户和多租户 IoT 解决方案，主要组件的注意事项和选择（例如管理、引入、处理、存储和安全性）是相同的。 主要区别在于如何安排和利用这些组件来支持多租户。 例如，以下常见决策点：
- 存储可能选择使用 SQL Server 或 Azure 数据资源管理器。
- 引入和管理层需要在 IoT Hub 与 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）、非 Microsoft 服务或自己的业务逻辑。
在上图中，每个租户都连接到一个共享 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 应用程序通常可以部署为水平分区的组件。 在这种方法中，您需要另一项服务将设备重定向到适合该特定租户的管理、控制和遥测平面的 DPS 实例。 若要了解详细信息，请参阅 横向扩展 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 热、暖和冷数据路径。