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

横向扩展 Azure IoT 中心解决方案以支持数百万台设备

项目
2025/02/09

本文介绍如何在 Azure IoT 中心平台上使用横向扩展模式缩放物联网（IoT）解决方案。横向扩展模式可将实例添加到部署（而不是增加实例大小），从而解决缩放难题。此处的实现指南展示了如何使用数百万台设备缩放 IoT 解决方案，并考虑了 Azure 中的服务和订阅限制。本文概述了可根据需要采用的横向扩展模式的低接触和零接触部署模型。有关详细信息，请参阅以下文章：

备注

本文档不介绍 Azure IoT 操作平台，该平台基于托管 Kubernetes 平台配置进行缩放。

收集要求

在实现新的 IoT 解决方案之前，应始终收集要求。从要求开始有助于确保实现符合业务目标。业务目标和运营环境应驱动需要收集的要求。至少应了解以下要求。

了解要部署的设备类型。 IoT 包含各种解决方案，从简单的微控制器(MCU)到中级单片系统(SOC)和微处理器(MPU)解决方案，再到完整的电脑级设计。设备端软件功能直接影响解决方案的设计。

了解需要部署的设备数。实现 IoT 解决方案的一些基本原则适用于所有规模。了解规模有助于避免设计出比必要解决方案更复杂的解决方案。适用于 1,000 台设备的解决方案与适用于 100 万台设备的解决方案存在一些根本差异。如果在解决方案设计开始时不考虑目标规模，适用于 10,000 台设备的概念证明(PoC)解决方案可能无法适当扩展到 1000 万台设备。

了解需要部署的设备数有助于选择合适的 Azure IoT 服务。 IoT 中心的缩放与 IoT 中心设备预配服务(DPS)的缩放不同。根据设计，单个 DPS 实例可以路由到多个 IoT 中心实例。因此，需要根据设备数单独考虑每项服务的规模。但是，限制在真空中不存在。如果限制在一项服务上是个问题，通常在其他服务上也是个问题。因此，应将服务限制视为不同但相关的配额。

记录预期的设备位置。不仅包括物理位置，还包括电源可用性和 Internet 连接性。部署在单个地理位置（例如仅在北美）中的解决方案的设计不同于全局解决方案。同样，在具有全时电源的工厂中部署的工业 IoT 解决方案也不同于在电源和位置可变的机动车辆中部署的舰队管理解决方案。此外，使用的协议和用于设备通信、网关或直接连接到云服务的带宽也会影响每层的设计可伸缩性。这方面隐藏了连接可用性。设备是否应保持与 Azure 的连接，或者它们是否在断开连接模式下长时间运行？

调查数据位置要求。在哪里存储解决方案的数据（例如遥测数据）或元数据（有关数据的数据，例如存在哪些设备) 可能存在法律、合规性或客户要求。这些限制（如果存在）是解决方案地理设计的关键输入。

确定数据交换要求。每小时发送一次基本遥测数数据（例如“当前温度”）的解决方案不同于每 10 分钟上传一次 1 MB 示例文件的解决方案。主要为单向设备到云(D2C)解决方案的解决方案不同于双向设备到云和云到设备(C2D)解决方案。此外，产品可伸缩性限制将消息大小和消息数量视为不同的维度。

记录预期的高可用性和灾难恢复要求。与任何生产解决方案一样，完整的 IoT 解决方案设计包括可用性（运行时间）要求。设计需要涵盖计划内维护场景和计划外故障时间，包括用户错误、环境因素和解决方案 bug。如果发生灾难（例如永久性区域丢失或恶意参与者），此类设计还需要记录恢复点目标（RPO）和恢复时间目标（RTO）。由于本文重点介绍了设备规模，因此有关高可用性和灾难恢复(HA/DR)问题的信息量有限。

确定客户租赁模型（如果适当）。在多租户独立软件供应商(ISV)解决方案中，解决方案开发人员正在为外部客户创建解决方案，设计必须考虑如何隔离和管理客户数据。 Azure 体系结构中心讨论了常规模式，并提供了特定于 IoT 的指南。

了解 Azure IoT 概念

创建解决方案的一部分是选择用作解决方案一部分的 Azure IoT 组件（可能还有其他支持 Azure 服务），包括支持服务。大量工作来自体系结构角度，这是本文档的重点。正确使用 Azure IoT 中心和 Azure IoT 中心 DPS 服务有助于将解决方案扩展到数百万台设备。

Azure IoT 中心

Azure IoT 中心是托管在云中的托管服务，充当中央消息中心，用于 IoT 应用程序及其连接设备之间的通信。它可以单独使用，也可以与 Azure IoT 中心 DPS 结合使用。

Azure IoT 中心根据所需功能和所需的每天消息数或每天数据量的组合进行缩放。三个输入用于选择实例的缩放：

层 – 免费、基本或标准 – 确定可用的功能。生产实例不使用免费层，因为它的规模有限，且仅用于引入开发场景。大多数解决方案都使用标准层以获取 IoT 中心的完整功能。
大小确定 IoT 中心设备到云消息的消息和数据吞吐量基础单位。 IoT 中心实例的最大大小为 3，支持每天 3 亿条消息及每个单位每天 1,114.4 GB 的数据。
单位计数确定规模（大小）乘数。例如，三个单位支持一个单位规模的三倍。大小为 1 或 2 的中心实例的限制为 200 个单位，大小为 3 的中心实例的限制为 10 个单位。

除了与大小和单位计数相关的每日限制以及与层相关的常规功能限制外，吞吐量还有每秒限制。每个 IoT 中心实例都有 100 万台设备的限制，作为软限制。虽然这是软限制，但也有硬限制。即使打算请求提高限制，也应该将软限制设计为设计限制，从而避免未来出现问题。数据交换要求有助于指导此处的解决方案。有关详细信息，请参阅其他限制。

解决方案的要求会驱动将 IoT 中心的必要大小和数量作为起点。如果使用 IoT 中心 DPS，Azure 有助于跨多个 IoT 中心实例分配工作负载。

Azure IoT 中心设备预配服务：

Azure IoT 中心设备预配服务(DPS)是 IoT 中心的帮助程序服务，支持零接触、实时预配到适当的 IoT 中心，无需人为干预。存在每个 Azure 订阅 10 个 DPS 实例的硬限制。此服务还存在 100 万次注册的硬限制。必须解决工作负荷设计限制中的服务限制，以避免将来出现问题。

DPS 服务实例的位置区别地区，但默认都有全局公共终结点。通过 ID 范围访问特定实例。由于实例位于特定区域，且每个实例都有自己的 ID 范围，因此应能够配置设备的 ID 范围。

了解共享复原能力概念

需要考虑的一些关键共享复原能力概念包括暂时性故障处理、设备位置影响，以及对于 ISV 的软件即服务(SaaS)数据复原能力。

了解暂时性故障处理。 无论是本地还是云生产分布式解决方案，都必须能够从暂时性（临时性）故障恢复。有时，云解决方案更有可能发生暂时性故障，原因如下：

依赖于外部提供商。
依赖于设备和云服务之间的网络连接性。
云服务的实现限制。

正如 Azure 体系结构中心所述，暂时性故障处理要求你在设备代码中内置有重试功能。 暂时性故障处理中介绍了多种重试策略（例如，使用随机选择的指数退避，也称为使用抖动的指数退避）。本文提到了这些模式，但没有给出任何进一步说明。如果对这些模式还不熟悉，请参阅此页面。

多种不同因素会影响设备的网络连接性：

设备的电源。依靠电池供电或暂时性能源（如太阳能或风能）供电的设备的网络连接性可能弱于所有时间都由线路供电的设备。
设备的部署位置。与位于偏远现场环境内的设备相比，市区工厂环境下的设备具有更好的网络连接性。
设备的位置稳定性。移动设备的网络连接性可能弱于固定位置设备。

上述所有问题还会影响设备可用性和连接性的计时。例如，市区环境下由线路供电的普通密集型设备（例如，智能音箱）可能会出现大量设备同时掉线，然后又同时恢复联网的情况。可能的方案包括：

停电期间，由于电网停电和恢复供电，可能会出现 100 万台设备同时掉线，然后又同时恢复联网的情况。此场景适用于使用者场景（例如智能音箱）以及业务和工业 IoT 场景（例如向房地产管理公司报告的连接型线路供电恒温器）。
短时间内的大规模登录（例如黑色星期五或圣诞节），很多使用者都在相对较短的时间内首次开启设备。
计划的设备更新，即许多设备在很短的时间窗口内收到更新，并且所有设备在更新后大概都在同一时间重启。

因为存在“许多设备同时重启”这样的场景，云服务问题会影响假定为将近 100% 网络连接性的均衡场景，例如网络带宽限制（限制允许流向服务的流量）。

除了网络和配额问题外，还需要考虑 Azure 服务中断。它们可能是服务中断或区域性中断。一些服务（例如 IoT 中心）是异地冗余服务，而其他服务（例如 DPS）将其数据存储在单个区域中。虽然区域冗余似乎受到限制，但必须认识到可以将单个 IoT 中心链接到多个 DPS 实例。

如果区域冗余是个问题，请使用地理节点模式，该模式是跨不同地理位置托管异类资源组的位置。同样，部署戳（也称为 规模戳）会应用此模式以操作多个工作负载或租户。有关详细信息，请参阅部署戳模式。

了解设备位置影响。 当架构师选择组件时，他们还必须了解大多数 Azure 服务都是区域性服务，甚至包括具有全局终结点的 DPS 等服务。例外包括 Azure 流量管理器和 Microsoft Entra ID。因此，你关于设备位置、数据位置和元数据位置（有关数据的数据：例如，Azure 资源组）制定的决策都是设计中的重要输入。

设备位置。由于设备位置的要求会影响事务延迟，因此它会影响区域选择。
数据位置。数据位置与设备位置相关，这也受合规性问题的影响。例如，在美国存储某个州数据的解决方案可能需要在美国地理位置中存储数据。数据位置要求也可能驱动此需求。
元数据位置。虽然设备位置通常不会影响元数据位置，但由于设备与解决方案数据（而非解决方案元数据）交互，因此合规性和成本问题会影响元数据位置。在许多情况下，便利性决定了元数据位置与区域性服务的数据位置相同。

Azure 云采用框架包括区域选择指南。

了解独立软件供应商(ISV) SaaS 问题。 作为提供 SaaS 的 ISV，必须满足客户对可用性和复原能力的期望。 ISV 必须构建高度可用的 Azure 服务，并且必须在向客户计费时考虑复原能力和冗余的成本。

根据每个软件客户的客户数据隔离，隔离所售货物成本(COGS)。当最终用户与客户不同时，这一差异非常重要。例如，在智能电视平台中，平台供应商的客户可能是电视供应商，但最终用户是电视的购买者。这种隔离由来自需求的客户租户模型驱动，需要单独的 DPS 和 IoT 中心实例。预配服务还必须具有唯一的客户身份，通过唯一终结点或设备身份验证过程指示该身份。有关详细信息，请参阅 IoT 多租户指南。

使用支持服务横向扩展组件

在讨论缩放 IoT 解决方案时，最好查看每项服务及其相互关联的方式。可以跨多个 DPS 实例或使用 Azure IOT 中心缩放 IOT 解决方案。

跨多个 DPS 实例横向扩展

考虑到 DPS 服务限制，通常需要扩展到多个 DPS 实例。可以通过多种方式跨多个 DPS 实例进行设备预配，这分为两大类：零接触预配和低接触预配。

以下所有方法都应用前面所述的“标记”概念来实现复原和横向扩展。此方法包括使用工具在多个区域中部署 Azure 应用服务，例如 Azure 流量管理器或全局负载均衡器。为简单起见，下图未展示该内容。

(1) 使用多个 DPS 实例进行零接触配置： 对于零接触（自动）预配，经过验证的策略是让设备从 Web API 请求 DPS ID 范围，该 API 可跨横向扩展的 DPS 实例了解并平衡设备。此操作让 Web 应用成为预配过程的关键部分，因此该 Web 应用必须可缩放且高度可用。此设计有三个主要变体。

以下关系图阐明了第一个选项：使用自定义预配 API 以管理设备到相应 DPS 池的映射方式，进而（通过标准 DPS 负载均衡机制）映射到相应的 IoT 中心实例：

设备向托管在 Azure 应用服务中的预配 API 发出请求，请求 DPS ID 范围。预配 API 会根据现有设备库存检查其永久数据库，查看最适合将设备分配到哪个实例，并返回 DPS ID 范围。这种情况下，建议使用启用了多主数据库写入（实现跨区域高可用性）、可存储每台设备分配到的 DPS 的 Azure Cosmos DB 实例。然后，可以使用此数据库从所有合适的指标（例如，每分钟预配请求数、预配的设备总数等）跟踪 DPS 实例利用率。此数据库还允许根据需要为重新预配提供相同的 DPS ID 范围。对预配 API 进行身份验证，从而阻止不适当的预配请求。
设备针对具有分配的 ID 范围的 DPS 发出请求。 DPS 将关于应分配给哪个 IoT 中心的详细信息返回给设备。
设备将 ID 范围和 IoT 中心连接信息存储在永久性存储中，最好是位于安全的存储位置中（因为 ID 范围属于针对 DPS 实例进行身份验证的一部分）。然后，设备使用此 IoT 中心连接信息进一步请求进入系统。

此设计要求设备软件包含 DPS SDK 并管理 DPS 注册过程，这是 Azure IoT 设备的典型设计。但在微控制器环境中，设备软件大小是设计的关键组件，它可能不可接受，这会导致另一种设计。

(2) 使用预配 API 进行零接触预配： 第二种设计将 DPS 调用移动到预配 API。在此模型中，与大多数重试逻辑一样，针对 DPS 的设备身份验证也包含在预配 API 中。此过程允许在设备本身中使用更高级的排队方案和可能更简单的预配代码。它还允许缓存分配的 IoT 中心，从而更快地传递云到设备消息。无需询问 DPS 分配的中心信息即可发送消息：

设备向托管在 Azure 应用服务中某个实例中的预配 API 发出请求。预配 API 会根据现有设备库存检查其永久数据库，查看最适合将设备分配到哪个实例，然后确定 DPS ID 范围。这种情况下，建议使用启用了多主数据库写入（实现跨区域高可用性）、可存储每台设备分配到的 DPS 的 Azure Cosmos DB 实例。然后，可以使用此数据库从所有合适的指标（例如，每分钟预配请求数、预配的设备总数等）跟踪 DPS 实例的使用情况。数据库还允许根据需要使用相同的 DPS ID 范围以提供重新预配请求。以某种方式对预配 API 进行身份验证，从而阻止不适当的预配请求。为此，可以使用预配服务针对 DPS 使用的相同身份验证，例如，使用已颁发证书的私钥。但也可以使用其他选项。例如，FastTrack for Azure（FTA）已与使用硬件唯一标识符作为其服务身份验证过程的一部分的客户合作。设备制造合作伙伴定期向设备供应商提供要加载到数据库的唯一标识符列表，该数据库会引用自定义预配 API 背后的服务。
预配 API 使用分配到的 ID 范围执行 DPS 预配过程，有效充当 DPS 代理。
DPS 结果转发到设备。
设备将 IoT 中心连接信息存储在永久性存储中，最好是位于安全的存储位置，因为 ID 范围属于针对 DPS 实例进行的身份验证的一部分。设备使用此 IoT 中心连接信息稍后请求进入系统。

此设计避免了引用 DPS SDK 或 DPS 服务的必要。它还避免了在设备上存储或维护 DPS 范围的必要。因此，它允许所有权转让场景，因为预配服务可以定向到相应的最终客户 DPS 实例。但是，这会导致预配 API 在概念上出现一些重复的 DPS，这可能并不理想。

(3) 使用所有权转让进行零接触预配： 第三种可能的零接触预配设计是将工厂配置的 DPS 实例用作起点，然后根据需要重定向到其他 DPS 实例。此设计允许在无自定义预配 API 的情况下进行预配，但需要管理应用程序以跟踪 DPS 实例并根据需要提供重定向。

管理应用程序要求包括跟踪哪个 DPS 应是每台特定设备的活动 DPS。可以将此方法用于“所有权转让”场景，其中设备供应商将设备的所有权从供应商转让给最终设备客户。

设备连接到工厂配置的 DPS 实例，并请求初始预配过程。
设备接收初始配置，包括所需的目标 DPS 实例。
设备连接到所需的目标 DPS 实例并请求预配。
然后，设备将 IoT 中心连接信息存储在永久性存储中，最好是位于安全的存储位置中（因为 ID 范围属于针对 DPS 实例进行身份验证的一部分）。设备利用此 IoT 中心连接信息进一步请求进入系统。

(4) 使用多个 DPS 实例进行低接触预配 在一些情况下（例如在面向使用者的场景中或具有现场部署团队设备时），常见的选择是提供低接触（用户辅助型）预配。低接触预配示例包括安装程序手机上的移动应用程序，或设备网关上的基于 Web 的应用程序。在这种情况下，经过验证的方法是执行与零接触预配过程中相同的操作，但预配应用程序会将详细信息传输到设备。

管理员启动连接到设备的设备配置应用。
配置应用连接到托管在 Azure 应用服务中某个实例中的预配 API，请求一个 DPS ID 范围。预配 API 会根据现有设备库存检查其永久数据库，查看最适合将设备分配到哪个实例，并返回 DPS ID 范围。这种情况下，建议使用启用了多主数据库写入（实现跨区域高可用性）、可存储每台设备分配到的 DPS 的 Azure Cosmos DB 实例。然后，可以使用此数据库从所有合适的指标（例如，每分钟预配请求数和预配的设备总数）跟踪 DPS 实例的利用率。适当时，此数据库还允许为重新预配提供相同的 DPS ID 范围。应以某种方式对预配 API 进行身份验证，防止为不适当的预配请求提供服务。
应用将预配 ID 范围返回到设备。
设备针对具有分配的 ID 范围的 DPS 发出请求。 DPS 将关于应分配给哪个 IoT 中心的详细信息返回给设备。
设备应将 ID 范围和 IoT 中心连接信息保留在永久性存储中，最好是位于安全的存储位置，因为 ID 范围属于针对 DPS 实例进行的身份验证的一部分。设备使用此 IoT 中心连接信息进一步请求进入系统。

本文未详细介绍其他可能的变体。例如，可以将 DPS 调用移动到预配 API 以配置此处所示的体系结构，如前面使用预配 API 进行零接触预配中所示。目标是确保每一层都是可缩放、可配置且轻松可部署。

常规 DPS 预配指南： 应将以下建议应用于 DPS 部署，这些建议表示此 Azure 服务的常规最佳做法：

不要在每次启动时都进行预配。 DPS 文档指定最佳做法不是每次启动时都进行预配。对于小型用例，每次启动时都进行预配似乎合理，因为这是部署的最短路径。然而，当纵向扩展到数百万台设备时，考虑到其硬限制：每个服务实例每分钟 1,000 次注册，DPS 会成为瓶颈。甚至是设备注册状态查找也会成为瓶颈，因为其每秒轮询操作次数限制为 5-10 次。预配结果通常是 IoT 中心的静态映射。因此，除非你的需求中包括自动化重新预配请求，否则最好只按需执行此类操作。如果您预计会有更多流量，则横向扩展到多个 DPS 实例可能是支持此类场景的唯一方法。

使用交错预配计划。关于缓解一些基于时间的限制，建议使用交错预配计划。对于初始预配，根据部署要求，此计划可能基于几秒（也可能最多几分钟）的随机偏移量。

始终在请求预配前查询状态。作为最佳做法，设备应始终在使用设备注册状态查找 API 请求预配之前查询其状态。此调用当前不计为计费项，限制独立于注册限制。与预配请求相比，查询操作相对较快，这意味着设备可以验证其状态并更快地转到正常设备工作负载。大规模部署文档中记录了相应的设备注册逻辑。

遵循预配 API 注意事项。此处建议的一些设计包括预配 API。预配 API 需要后备元数据存储，例如 Azure Cosmos DB。在这些缩放级别，最好实现全局可用且可复原的设计模式，这是此 API 和后备数据存储的良好模式。 Azure Cosmos DB 中的内置多主数据库、异地冗余功能和延迟保证使其成为此场景下的绝佳选择。此 API 的主要职责包括：

为 DPS ID 范围提供服务。此接口可以是 GET 请求。请记住，物理设备或管理应用程序正在连接到此接口。
为设备生命周期提供支持。设备可能需要重新预配，否则可能会发生一些其他意外事件。至少，必须维护设备 ID 以及为设备分配的 DPS。通过这种方式，可以从分配的 DPS 取消预配，并在另一个 DPS 上重新预配。或者，如果设备的生命周期已结束，可以将其从系统完全删除。
对系统进行负载均衡。通过使用与 DeviceID 和 DPS 相关的相同元数据，可以更轻松地了解每个子系统的当前负载并应用这些信息，从而更好地跨横向扩展的组件平衡设备。
维护系统安全性。如前所述，预配 API 应对每次请求进行身份验证。推荐的最佳做法是为每台设备使用唯一的 X.509 证书，该证书可以针对预配 API 和 DPS 实例进行身份验证（如果体系结构支持）。也可以使用舰队证书和令牌等其他方法，但安全性更低。具体实现方式以及实现的安全含义取决于是选择使用零接触选项还是低接触选项。

横向扩展 Azure IoT 中心

与横向扩展 DPS 相比，横向扩展 Azure IoT 中心相对简单。如前所述，DPS 的优点之一是实例可以链接到多个 IoT 中心实例。如果按建议将 DPS 用于所有 Azure IoT 解决方案，横向扩展 IoT 中心涉及：

新建 IoT 中心服务的实例。
使用适当的路由和其他详细信息配置新实例。
将新实例链接到适当的 DPS 实例。
如有必要，重新配置 DPS 分配策略或自定义分配策略。

设计设备软件

对于可缩放的设备设计，需要遵循许多最佳做法和设备端注意事项。其中一些直接派生自现场遇到的反模式。本部分介绍了成功缩放部署的关键概念。

评估设备生命周期不同阶段的工作负载，以及生命周期内的使用场景。开发阶段（试点、开发、生产、解除授权和生命周期结束）之间的设备注册工作负载差别很大。在一些情况下，还会因之前提到的停电场景等外部因素而有所不同。针对“最坏情况”工作负载进行设计有助于确保大规模成功。

支持按需重新预配。可以通过设备命令和管理用户请求提供此功能，如产品文档中所述。此选项允许转让所有权场景和工厂默认场景。

不需要时，不要重新预配。现场处于活动状态的工作设备需要重新预配是不寻常的，因为预配信息相对静态。没有充分理由不要重新预配。

如果必须经常重新预配（例如每次设备启动时），请检查预配状态。如果设备预配状态不确定，请先查询预配状态。查询操作针对与预配操作不同的配额进行处理，其操作速度比预配操作要快。此查询允许设备在继续操作前验证预配状态。例如，当设备没有可用于存储预配结果的永久性存储时，可能会看到这种情况。

确保重试逻辑策略得当。设备代码中必须内置适当的重试算法以进行初始预配和之后的重新预配，例如，前面提到的“使用随机选择的指数退避”。对于这两种用例，此类场景可能不同。根据定义，初始预配在重试过程中可能需要比重新预配更加主动，具体取决于用例。当网络宽带受限时，与大多数 Azure 服务一样，DPS 会返回 HTTP 429（“请求数过多”）的错误代码。 Azure 体系结构中心提供有关重试的指导，更重要的是，有关反面模式的指导，以避免在重试场景中出现这些问题。 DPS 文档还包含有关如何了解服务针对重试间隔推荐的内容以及如何计算适当抖动（作为其缩放指南的一部分）的信息。设备位置稳定性和连接性访问也会影响适当的重试策略。例如，如果已知某设备在一段时间内处于脱机状态，并且该设备可以检测到它处于脱机状态，则在设备脱机时重试联机操作就没有意义。

支持无线(OTA)更新。两种简单的更新模型分别使用自动设备管理的设备管理属性，和简单设备命令。有关更复杂的更新场景和报告的详细信息，请参阅 Azure Device Update 服务预览版。 OTA 更新允许更正设备代码中的缺陷，并可用于基本服务重新配置（例如 DPS ID 范围）（如有必要）。

所有层和所有证书使用的证书更改的架构师。此建议与 OTA 更新最佳做法相关。必须考虑证书轮换。 IoT 中心 DPS 文档从设备标识证书角度介绍了此场景。但一定请切记，作为设备解决方案的一部分，还会使用 IoT 中心访问、应用服务访问和 Azure 存储帐户访问等其他证书。整个 Azure 平台的根证书更改表明，必须预测所有层的更改。此外，请谨慎使用证书固定，尤其是在证书不受设备制造商控制的情况下。

请考虑合理的“默认”状态。若要解决初始预配失败，请根据具体情况进行合理的断开连接和未预配的配置。如果设备在初始预配中具有繁重的交互组件，则在用户执行其他预配任务时，预配过程可以在后台进行。任何情况下，使用默认值都暗示使用适当的重试模式，并适当使用断路器架构模式。

适用时包含终结点配置功能。允许配置 DPS ID 范围、DPS 终结点或自定义预配服务终结点。 DPS 终结点不会更改，但由于可以在设备上更改它，因此具有更大的灵活性。例如，考虑在无直接 Azure 访问权限的情况下通过集成测试对设备配置过程进行自动验证的情况。或者，考虑未来可能出现目前尚不存在的预配场景，例如通过预配代理服务。

使用 Azure IoT SDK 进行预配。无论是在设备本身还是在自定义预配 API 中进行 DPS 调用，使用 Azure IoT SDK 都意味着可以在实现中“免费”获得一些最佳做法，并获得更简洁的支持体验。由于 SDK 都是开源发布的，因此可以查看它们的工作原理并提出更改建议。你选择的设备硬件和设备上一个或多个可用的运行时的组合主要驱动你选择的 SDK。

部署设备

设备部署是设备生命周期的关键部分，但它不在本文讨论范围内，因为它依赖于用例。前面提到的有关“所有权转让”的讨论点可能适用于部署和涉及预配应用程序的模式（例如移动应用程序），但你可根据正在使用的 IoT 设备类型进行选择。

监控设备

整体部署的重要部分是自始至终监视解决方案，从而确保系统正常运行。由于本文明确侧重于介绍体系结构和设计，而不是解决方案的操作方面，因此有关于监视的详细信息并不在本文的讨论范围内。但是，在高级别上，Azure 中通过 Azure Monitor 内置了监视工具，从而确保解决方案不会达到上限。有关详细信息，请参阅以下文章：

可以单独使用这些工具，也可以作为更复杂的安全信息和事件管理（SIEM）解决方案的一部分，例如 Microsoft Sentinel。

本文档包括以下监视模式，用于监视 DPS 随时间推移的使用情况：

创建应用程序以查询 DPS 实例上的每个注册组，获取注册到该组的全部设备，然后聚合来自各个注册组的数字。此数字提供当前通过 DPS 注册的设备的确切计数，可用于监视服务的状态。
监视特定时段内的设备注册。例如，监视 DPS 实例在前五天的注册率。此方法仅提供近似数字，并且限制在设定的时间段内。

结论

纵向扩展 IoT 解决方案以支持数百万甚至数千万台设备不是一项简单的任务。需要考虑许多因素，并且有各种方法来解决在这些规模上出现的问题。本文总结了这些问题，并提供有关如何在成功部署中解决这些问题的方法。

作者

本文由 Microsoft 维护，它最初是由以下贡献者撰写的。

主要作者：

Michael C. Bazarewsky | Microsoft Azure CXP G&I 高级客户工程师

其他参与者：

David Crook | Microsoft Azure CXP G&I 首席客户工程师
Alberto Gorni | 高级客户工程师

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

查看产品组指南，了解大规模部署 Microsoft Azure IoT 设备的最佳做法
查看云采用框架中的恢复信息

通过

横向扩展 Azure IoT 中心解决方案以支持数百万台设备

收集要求