你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文介绍如何在 Azure IoT 中心平台上使用横向扩展模式缩放物联网（IoT）解决方案。 横向扩展模式通过向部署添加实例而不是增加实例大小来解决缩放难题。 此实现指南演示如何缩放支持数百万台设备的 IoT 解决方案，并考虑 Azure 服务和订阅限制。 本文概述了横向扩展模式中的低接触和零接触部署模型，您可以根据需求进行采用。
如需了解更多信息，请参阅以下文章：
注意
本文档不包括 Azure IoT Operations 平台，该平台根据托管 Kubernetes 平台配置进行扩展。
收集要求
在实现新的 IoT 解决方案之前收集要求。 该步骤有助于确保实施符合您的业务目标。 业务目标和运营环境应驱动需求。 至少收集以下需求：
标识要部署的设备类型。 IoT 包括各种解决方案，从简单的微控制器单元（MCU）到中型芯片系统（SoC）和微控制器单元（MPU），到完整的电脑级设计。 设备端软件功能直接影响解决方案设计。
确定需要部署的设备数。 实施 IoT 解决方案的一些基本原则适用于所有规模。 了解规模以帮助避免过度设计解决方案。 与 100 万台设备的解决方案相比，1000 台设备的解决方案存在根本差异。 如果解决方案设计开始时不考虑目标规模，10,000 台设备的概念证明（PoC）解决方案可能无法适当缩放到 1000 万台设备。
确定需要部署的设备数，以便选择正确的 Azure IoT 服务。 IoT 中心和 IoT 中心 DPS 的缩放有所不同。 根据设计，单个 DPS 实例可以路由到多个 IoT 中心实例。 因此，请考虑每个服务相对于设备数量的规模。 但是，隔离中不存在限制。 如果一个服务存在限制问题，其他服务也可能会这样做。 将服务限制视为不同但相关的配额。
记录预期的设备位置。 包括物理位置、电源可用性和 Internet 连接。 与全局解决方案相比，在单个地理位置（例如仅在北美）中部署的解决方案的设计方式不同。 同样，在具有全时功率的工厂中部署的工业 IoT 解决方案与在具有可变电源和位置的机动车中部署的车队管理解决方案不同。 通信协议和可用带宽（无论是网关还是直接连接到云服务）会影响每个层的设计可伸缩性。 另请考虑连接可用性。 确定设备是保持连接到 Azure 还是长时间以断开连接模式运行。
调查数据区域要求。 法律、合规性或客户要求可能会限制存储解决方案的数据（如遥测）或元数据（如设备信息）的位置。 这些限制严重影响了解决方案的地理设计。
确定数据交换要求。 每小时发送一次基本遥测（例如当前温度）的解决方案不同于每隔 10 分钟上传一次 1 MB 示例文件的解决方案。 单向设备到云（D2C）解决方案不同于双向 D2C 和云到设备（C2D）解决方案。 此外，产品可伸缩性限制将消息大小和消息数量视为不同的维度。
请记录预期的高可用性和灾难恢复要求。 与任何生产解决方案一样，完整的 IoT 解决方案设计包括可用性或运行时间要求。 设计需要涵盖计划维护情景和非计划停机时间，包括用户错误、环境因素和解决方案缺陷。 如果发生灾难（例如永久性区域丢失或恶意参与者），设计还需要有记录的 恢复点目标（RPO） 和恢复时间目标（RTO）。 本文重点介绍设备规模，因此它仅包含有关高可用性和灾难恢复问题的有限信息。
如果适用，请确定客户租赁模型。 在多租户软件开发公司解决方案中，解决方案开发人员在其中为外部客户创建解决方案，设计必须定义如何分离和管理客户数据。 有关详细信息，请参阅 租户模型 和相关 IoT 特定指南。
了解 Azure IoT 概念
创建解决方案时，请选择相应的 Azure IoT 组件和其他支持 Azure 服务。 解决方案的体系结构需要付出大量努力。 正确使用 IoT 中心和 IoT 中心 DPS 服务可帮助你将解决方案扩展到数百万台设备。
IoT 中心
IoT 中心是云中托管的托管服务，充当中心消息中心，用于 IoT 应用程序与其附加设备之间的通信。 可以单独使用 IoT 中心或与 IoT 中心 DPS 一起使用。
IoT 中心根据所需的功能和每天的消息数或数据量进行缩放。 使用以下三个输入来确定如何缩放实例：
免费层、基本层和标准 层 决定了可用的功能。 生产实例不使用免费层，因为它的规模有限，且仅用于引入开发场景。 大多数解决方案都使用标准层以获取 IoT 中心的完整功能。
大小确定 IoT 中心的 D2C 消息的消息和数据吞吐量基单位。 IoT 中心实例的最大大小为 3，支持每天 3 亿条消息，每天 1,114.4 GB 的数据（单位）。
单位计数确定规模（大小）乘数。 例如，三个单位支持一个单位规模的三倍。 大小为 1 或 2 的中心实例的限制为 200 个单位，大小 为 3 的中心实例的限制为 10 个单位。
除了基于大小和单位计数的每日限制以及基于层的常规功能限制外，IoT 中心还对吞吐量强制实施每秒限制。 每个 IoT 中心实例还支持多达 100 万台设备作为 硬性限制。 数据交换要求有助于定义适当的配置。 有关详细信息，请参阅 其他限制。
解决方案的要求会驱动将 IoT 中心实例的必要大小和数量作为起点。 如果使用 IoT 中心 DPS，Azure 有助于跨多个 IoT 中心实例分配工作负载。
IoT 中心 DPS
IoT 中心 DPS 是 IoT 中心的帮助程序服务，无需人工干预即可在正确的 IoT 中心进行零接触实时预配。 每个 Azure 订阅最多支持 10 个 DPS 实例。 每个服务实例最多支持 100 万个注册。 解决工作负荷设计限制中的服务限制，以避免将来出现问题。
DPS 实例驻留在特定地理区域中，但默认具有 全局公共终结点 。 通过 ID 范围访问特定实例。 由于实例位于特定区域，并且每个实例都有自己的 ID 范围，因此应该能够为设备配置 ID 范围。
了解共享复原能力概念
必须考虑共享复原概念，例如暂时性故障处理、设备位置影响，以及软件公司软件即服务（SaaS）数据复原能力。
了解暂时性故障处理。 任何生产分布式解决方案（无论是本地还是云中）都必须能够从暂时性或临时故障中恢复。 由于以下因素，云解决方案中可能会更频繁地发生暂时性故障：
- 依赖外部供应商
- 依赖于设备和云服务之间的网络连接
- 云服务的实施限制
暂时性故障处理要求你在设备代码中内置重试功能。 存在多个重试策略，包括随机化的指数退避，也称为 具有抖动的指数退避。 有关详细信息，请参阅 暂时性故障处理。
多种不同因素会影响设备的网络连接性：
设备的电源： 电池供电的设备或由暂时性电源（如太阳能或风能）供电的设备可能比全时线路供电设备具有更少的网络连接。
设备的部署位置： 城市工厂设置中的设备可能比隔离现场环境中的设备具有更好的网络连接。
设备的位置稳定性： 移动设备的网络连接可能比固定位置设备少。
这些问题还会影响设备可用性和连接的时间。 例如，密集的城市环境中的线路供电设备（如智能扬声器）可能会在大规模设备群中断开连接并重新连接。 请考虑下列情形：
停电可能导致 100 万台设备同时离线，并因电网失效和重新连接而同时重新联网。 此方案适用于两种使用者方案，例如智能扬声器，以及业务和工业 IoT 方案，例如向房地产管理公司报告的连接、线路供电的恒温器。
在短时间内进行大规模入驻活动（如 黑色星期五 或圣诞节）期间，许多消费者在相对较短的时间内首次启动设备。
许多设备在短时间内接收计划更新，所有这些设备都以大约相同的时间重新启动新更新。
这些设备同时启动的情况可能会触发云服务降速，即使网络连接接近恒定。
除了网络和配额问题之外，还应考虑 Azure 服务中断。 这些中断可能会影响单个服务或整个区域。 某些服务（如 IoT 中心）支持异地冗余。 其他服务（如 IoT 中心 DPS）将其数据存储在单个区域中。 可以将一个 IoT 中心链接到多个 DPS 实例，这有助于缓解区域风险。
如果区域冗余是个问题，请使用 Geode 模式。 此模式托管跨不同地理位置的独立分组资源。 同样，部署戳（也称为规模戳）会应用此模式以操作多个工作负荷或租户。 有关详细信息，请参阅 部署戳模式。
了解设备位置影响。 大多数 Azure 服务都是 区域服务，即使是具有全局终结点的 DPS。 例外包括 Azure 流量管理器和 Microsoft Entra ID。 有关设备位置、数据位置和元数据位置（如 Azure 资源组）的决定在设计中起着关键作用。
设备位置： 设备位置要求会影响区域选择，因为它们会影响事务延迟。
数据位置： 数据位置与设备位置相关联，这符合合规性问题。 例如，在美国存储某州数据的解决方案可能需要在美国 地理位置进行数据存储。 数据位置要求也可能驱动此需求。
元数据位置： 尽管设备位置通常不会影响元数据位置，因为设备与解决方案 数据 交互，而不是解决方案 元数据，但合规性和成本问题会影响元数据位置。 在许多情况下，便利性决定了元数据位置与区域性服务的数据位置相同。
Azure 云采用框架包括 有关区域选择的指导。
了解软件公司 SaaS 问题。 提供 SaaS 解决方案的软件公司应满足客户对可用性和复原能力的期望。 软件公司必须构建 Azure 服务才能高度可用，并在客户计费时考虑复原和冗余的成本。
根据每个软件客户的客户数据划分来区分销售商品的成本。 当用户与客户不同时，此区别非常重要。 例如，对于智能电视平台，平台供应商的客户可能是电视供应商，但用户是电视的购买者。 这种隔离由来自需求的客户租户模型驱动，需要单独的 DPS 和 IoT 中心实例。 预配服务还必须具有唯一的客户标识，可以通过唯一的终结点或设备身份验证过程进行定义。 有关详细信息，请参阅 IoT 多租户指南。
横向扩展组件及其支持服务
在扩展 IoT 解决方案时，评估每个服务及其相互关联的方式。 可以跨多个 DPS 实例或使用 IoT Hub 缩放 IoT 解决方案。
跨多个 DPS 实例横向扩展
由于 DPS 服务限制，通常需要扩展到多个 DPS 实例。 可以通过零接触预配或低触摸预配，跨多个 DPS 实例进行设备预配。
以下方法适用于复原和横向扩展的前面所述的 标记 概念。此概念包括在多个区域中部署 Azure 应用服务，以及使用 流量管理器 或 全局负载均衡器等工具。 为简单起见，下图不显示这些组件。
方法 1：使用多个 DPS 实例进行零接触预配
对于零接触或自动预配，经过验证的策略包括让设备从 Web API 请求 DPS ID 范围。 API 可了解和平衡横向扩展 DPS 实例中的设备。 此操作让 Web 应用成为预配过程的关键部分，因此该 Web 应用必须可缩放且高度可用。 此设计有三个主要变体。
下图显示了使用自定义预配 API 的第一个选项，该 API 管理如何将设备映射到相应的 DPS 池。 然后，每个 DPS 实例使用标准 DPS 负载均衡机制将设备映射到相应的 IoT 中心。
设备向应用服务中托管的预配 API 发出请求，以请求 DPS ID 范围。 预配 API 会检查其持久性数据库，以根据现有设备清单确定设备的最佳实例，并返回 DPS ID 范围。
在此示例中，数据库是一个已启用多主写入的 Azure Cosmos DB 实例，以实现跨区域高可用性。 此数据库存储每个设备的已分配 DPS。 它支持跟踪所有适当指标的 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 中心，以加快 C2D 消息传送的速度。 消息发送时无需询问 DPS 以获取分配的中心信息。
设备向应用服务实例中托管的预配 API 发出请求。 预配 API 会检查其持久性数据库，以根据现有设备清单确定设备的最佳实例，然后确定 DPS ID 范围。
在此示例中，数据库是一个已启用多主写入的 Azure Cosmos DB 实例，以实现跨区域高可用性。 此数据库存储每个设备的已分配 DPS。 它支持跟踪所有适当指标的 DPS 实例使用情况。 如果需要，数据库还可以使用相同的 DPS ID 范围重新预配。
对预配 API 进行身份验证，从而阻止不适当的预配请求。 可以使用预配服务针对 DPS 使用的相同身份验证，例如，使用已颁发证书的私钥。 但存在其他选项。 例如，FastTrack for Azure 可能与使用硬件唯一标识符的客户合作，作为其服务身份验证过程的一部分。 设备制造合作伙伴定期向设备供应商提供要加载到数据库的唯一标识符列表，该数据库会引用自定义预配 API 背后的服务。
预配 API 使用分配的 ID 范围（有效地充当 DPS 代理）执行 DPS 预配过程。
API 将 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 的应用程序。 此方法执行与零接触预配过程相同的作，但预配应用程序会将详细信息传输到设备。
管理员启动连接到设备的设备配置应用。
配置应用连接到应用服务实例中托管的预配 API，以请求 DPS ID 范围。 预配 API 会根据现有设备清单检查其持久性数据库，以确定设备的最佳实例，并返回 DPS ID 范围。
在此示例中，数据库是一个已启用多主写入的 Azure Cosmos DB 实例，以实现跨区域高可用性。 此数据库存储每个设备的已分配 DPS。 它支持跟踪所有适当指标的 DPS 实例使用情况。 如果需要，此数据库还允许使用相同的 DPS ID 范围重新预配。 对预配 API 进行身份验证，以防止不适当的预配请求被服务。
应用将预配 ID 范围返回到设备。
设备针对具有分配的 ID 范围的 DPS 发出请求。 DPS 将 IoT 中心分配详细信息返回到设备。
设备应将 ID 范围和 IoT 中心连接信息保留在永久性存储中，最好是位于安全的存储位置，因为 ID 范围属于针对 DPS 实例进行的身份验证的一部分。 设备使用此 IoT 中心连接信息进一步请求进入系统。
本文不介绍其他变体。 例如，可以将 DPS 调用移动到预配 API 配置此方法，如前面使用预配 API 进行零接触预配中所示。 目标是确保每个层可缩放、可配置且易于部署。
常规 DPS 预配指南
将以下建议应用于 DPS 部署：
不要在每次启动时都进行预配。 DPS 文档建议不要在每次启动时预配。 对于小型用例，在每次启动时预配可能很合理，因为这是部署的最短路径。 但是，当纵向扩展到数百万台设备时，DPS 可能会成为瓶颈 ，因为每个服务实例的硬性限制为每分钟 1,000 个注册。 即使是查询设备注册状态也可能会成为瓶颈，因为它们限制每秒的轮询操作次数为 5 到 10 次。 预配结果通常静态映射到 IoT 中心。 因此，除非要求包括自动重新预配请求，否则仅应在必要时启动预配。 如果预计会有更多流量，请横向扩展到多个 DPS 实例以支持使用场景。
使用错开的供应计划。 若要减少基于时间的限制，请使用 错开的预配计划。 对于初始预配，可以应用几秒钟的随机延迟或将延迟延长到几分钟，具体取决于部署要求。
在请求预配之前始终查询状态。 作为最佳做法，设备应始终在使用 设备注册状态查找 API 请求预配之前查询其状态。 此调用不计为计费项， 限制与注册限制无关。 与预配请求相比，查询作相对较快，因此设备可以验证其状态并更快地开始其正常工作负荷。 有关适当的设备注册逻辑，请参阅 大规模部署。
遵循预配 API 注意事项。 本文中的一些设计包括预配 API。 预配 API 需要一个后端元数据存储，例如 Azure Cosmos DB。 在这些规模下，应实现全局可用且具有弹性的设计模式。 Azure Cosmos DB 中的内置多主、异地冗余功能和延迟保证使其成为此方案的绝佳选择。 此 API 具有以下关键责任：
为 DPS ID 范围提供服务。 此接口可能使用 GET 请求。 物理设备或管理应用程序连接到此接口。
支持设备生命周期。 设备可能需要重新预配，或者可能发生意外事件。 至少维护设备 ID，并为设备分配 DPS。 此信息可用于取消当前分配的 DPS 的预配，并在另一个 DPS 上重新进行预配。 或者，如果设备的生命周期已结束，则可以将其完全从系统中删除。
对系统进行负载均衡。 系统使用与设备 ID 和 DPS 相同的元数据，以便它可以了解每个子系统上的当前负载，并应用该信息以更好地平衡跨横向扩展组件的设备。
维护系统安全性。 预配 API 应对每个请求进行身份验证。 建议的最佳做法是 为每个设备使用唯一的 X.509 证书。 如果体系结构支持该设备，此证书可以针对预配 API 和 DPS 实例对设备进行身份验证。 其他方法（如机队证书和令牌）可用，但安全性较低。 具体实现及其安全影响取决于是选择零接触还是低接触选项。
横向扩展 IoT 中心
与横向扩展 DPS 相比，横向扩展 IoT 中心相对简单。 DPS 的优点之一是能够链接到许多 IoT 中心实例。 遵循在 Azure IoT 解决方案中使用 DPS 的建议做法时，横向扩展 IoT 中心涉及以下步骤：
设计设备软件
可缩放的设备设计需要遵循最佳做法和设备端注意事项。 其中一些做法来自该领域遇到的反模式。 本部分介绍成功缩放部署的关键概念。
在设备生命周期的不同部分和生命周期内的方案中估计工作负荷。 设备注册工作负载在开发阶段（例如试点、开发、生产、停用和生命周期结束）之间可能有很大的不同。 在一些情况下，还会因之前提到的停电场景等外部因素而有所不同。 针对最差工作负荷进行设计，以帮助确保大规模成功。
支持按需重新预配。 可以通过设备命令和管理用户请求来提供此功能。 有关详细信息，请参阅重新预配设备。 此选项有助于转让所有权场景和工厂默认场景。
避免不必要的重新预配。 活动、工作设备很少需要重新预配，因为预配信息保持相对静态。 没有充分理由不要重新预配。
如果必须经常重新预配，例如在每个设备启动时，请查看预配状态。 如果不确定设备预配状态，请先 查询预配状态 。 查询操作是根据与预配操作不同的配额处理的，而且速度更快。 此查询允许设备在继续操作前验证预配状态。 当设备没有可用的持久性存储来存储预配结果时，此方法特别有用。
确保重试逻辑策略得当。 设备必须具有内置于设备代码中的相应重试算法，以便进行初始预配和以后的重新预配。 通过使用随机选择的指数退避等技术。 根据定义，初始预配在重试过程中可能需要比重新预配更加主动，具体取决于用例。 受限制时，DPS 返回 HTTP 429 请求过多 错误代码，如大多数 Azure 服务。 有关详细信息，请参阅 重试 和 反模式以避免。 DPS 文档还介绍了如何解释服务重试建议并计算抖动。 设备位置稳定性和连接性访问也会影响适当的重试策略。 例如，如果设备检测到它在一段时间内处于脱机状态，则应避免重试联机操作。
支持无线 （OTA） 更新。 两个简单的更新模型包括使用设备孪生属性结合 自动设备管理 和使用简单的设备命令。 有关更复杂的更新方案和报告，请参阅 Azure 设备更新。 使用 OTA 更新可以修复设备代码中的缺陷，并在必要时重新配置服务（如 DPS ID 范围）。
所有层和证书使用的证书更改的架构师。 此建议符合 OTA 更新最佳做法。 必须考虑证书轮换。 IoT 中心 DPS 文档 从设备标识证书 的角度解决了此方案。 在设备解决方案中，其他证书用于访问 IoT 中心、应用服务和 Azure 存储帐户等服务。 Azure 有时会更改证书颁发机构配置，因此必须预测所有层的更改。 此外，请谨慎使用证书固定，尤其是在证书不受设备制造商控制的情况下。
请考虑合理的默认状态。 若要解决初始预配失败，请根据具体情况进行合理的断开连接和未预配的配置。 如果设备在初始预配中具有繁重的交互组件，则在用户执行其他预配任务时，预配过程可以在后台进行。 始终将此方法与适当的重试模式和 断路器模式配对。
在适当情况下包括终结点配置功能。 允许配置 DPS ID 范围、DPS 终结点或自定义预配服务终结点。 尽管 DPS 终结点很少发生更改，但启用这种灵活性可以支持一些场景，例如通过集成测试自动验证设备预配过程，而无需直接访问 Azure，或支持使用代理服务的将来预配模型。
使用 Azure IoT SDK 进行预配。 无论 DPS 调用是在设备本身还是自定义预配 API 中，都使用 Azure IoT SDK 从内置最佳做法中获益并简化支持。 SDK 已发布开放源代码，因此可以查看它们的工作方式和建议更改。 你选择的 SDK 取决于设备硬件和设备上的可用运行时。
部署设备
设备部署是设备生命周期的关键部分，但它超出了本文的范围，因为它依赖于用例。 前面提到的有关所有权转让的讨论点可能适用于涉及预配应用程序的部署和模式，例如移动应用程序。 但必须根据正在使用的 IoT 设备类型选择部署方法。
监控设备
整体部署的重要部分是自始至终监视解决方案，从而确保系统正常运行。 本文明确重点介绍体系结构和设计，而不是解决方案的作方面，因此不包括监视。 但是，在高级别上，监视工具通过 Azure Monitor 内置于 Azure 中，以确保解决方案不会达到限制。 如需了解更多信息，请参阅以下文章：
可以单独使用这些工具，也可以作为更复杂的安全信息和事件管理（SIEM）解决方案的一部分，例如 Microsoft Sentinel。
使用以下 监视模式 监视一段时间内的 DPS 使用情况：
创建一个应用程序，该应用程序在 DPS 实例上查询每个注册组，检索注册到该组的总设备数，然后跨各种注册组聚合数字。 此方法提供当前通过 DPS 注册的设备的确切计数，并帮助监视服务的状态。
监视特定时段内的设备注册。 例如，可以监视过去五天内 DPS 实例的注册率。 此方法仅提供近似数字，并且仅限于设定的时间段。
结束语
纵向扩展 IoT 解决方案以支持数百万甚至数亿台设备需要仔细规划。 必须考虑多种因素和各种方法来解决这些问题。 本文总结了关键问题，并提供了有关如何在成功部署中解决这些问题的方法。
参与者
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- 迈克尔·巴扎鲁夫斯基 |高级客户工程师，Microsoft Azure CXP
其他参与者：
- 大卫·克鲁克 |首席客户工程经理，Microsoft Azure CXP
- Alberto Gorni |前高级客户工程师，Microsoft Azure CXP
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。