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

IoT 中心设备重新预配概念

在 IoT 解决方案的生命周期中,设备在 IoT 中心之间频繁移动。 此举动的原因可能包括以下情形:

  • 地理位置/地理延迟:当设备在两位置之间移动时,通过将设备迁移到更近的 IoT 中心来改善网络延迟。

  • 多租户:设备可以在同一 IoT 解决方案中使用,并重新分配给新客户或客户站点。 此新客户可能使用不同的 IoT 中心提供服务。

  • 解决方案更改:可将设备移到新版或更新后的 IoT 解决方案中。 此重新分配可能需要设备与连接到其他后端组件的新 IoT 中心通信。

  • 隔离:类似于解决方案更改。 故障、泄露或过期的设备可以重新分配到只能更新并恢复合规性的 IoT 中心。 一旦设备正常运行,它就会迁移回主中心。

在设备预配服务中重新预配支持可满足这些需求。 可以根据在设备的注册条目上配置的重新预配策略自动将设备重新分配到新的 IoT 中心。

设备状态数据

设备状态数据由设备孪生和设备功能组成。 此数据存储在设备预配服务实例和设备所分配到的 IoT 中心中。

显示设备预配服务如何工作的图。

设备初次使用设备预配服务实例进行预配时,将执行以下步骤:

  1. 设备向设备预配服务实例发送预配请求。 服务实例基于注册项对设备标识进行身份验证,并创建设备状态数据的初始配置。 服务实例根据注册配置将设备分配给 IoT 中心,并将该 IoT 中心分配返回给设备。

  2. 预配服务实例将任何初始设备状态数据的副本提供给所分配的 IoT 中心。 设备连接到已分配的 IoT 中心,并开始进行操作。

随着时间的推移,设备操作后端操作可能会更新 IoT 中心的设备状态数据。 存储在设备预配服务实例中的初始设备状态信息保持不变。 此未动的设备状态数据为初始配置。

展示通过设备预配服务预配的设备状态变化的关系图。

根据方案,当设备在 IoT 中心之间移动时,可能需要将之前 IoT 中心更新的设备状态迁移到新的 IoT 中心。 在设备预配服务中重新预配策略可以支持此迁移。

重新预配策略

根据具体情况,设备可能会在重启时向预配服务实例发送请求。 还支持按需手动触发预配的方法。 注册项上的重新预配策略将确定设备预配服务实例处理这些预配请求的方式。 该策略还确定是否应在重新预配期间迁移设备状态数据。 单个注册和注册组可使用相同的策略:

  • 重新预配和迁移数据:此策略是新注册项的默认策略。 当与注册项关联的设备提交新的请求时,此策略将执行操作 (1)。 根据注册项配置,设备可能会被重新分配到另一个物联网中心。 如果设备正在更改 IoT 中心,则会删除初始 IoT 中心的设备注册。 从该初始 IoT 中心更新的设备状态信息将迁移到新的 IoT 中心(2)。 在迁移期间,设备的状态将报告为 “分配”。

    显示与注册项关联的设备提交新的请求时策略将采取措施的图。

  • 重新预配并重置为初始配置:当与注册项关联的设备提交新的预配请求时,此策略将执行操作 (1)。 根据注册项配置,设备可能会被重新分配到另一个物联网中心。 如果设备正在更改 IoT 中心,则会删除初始 IoT 中心的设备注册。 将向新的 IoT 中心提供预配服务实例在预配设备时接收到的初始配置数数据 (2)。 在迁移期间,设备的状态将报告为 “分配”。

    此策略通常用于恢复出厂设置而无需更改 IoT 中心。

    此图显示了当与注册条目关联的设备提交新的预配请求时策略如何采取措施。

  • 从不重新预配:设备从不重新分配到不同的中心。 此策略用于管理后向兼容性。

注意

如果设备有新的 ReturnData,DPS 将始终调用自定义分配 Webhook,而不考虑重新预配策略。 如果重新预配策略设置为 从不重新预配,则会调用 Webhook,但设备不会更改其分配的集线器。

设计解决方案并定义重新预配逻辑时,需要考虑一些事项。 例如:

  • 希望设备重启的频率
  • DPS 配额和限制
  • 你的机群的预期部署时间(分阶段推出与一次性全部部署)
  • 按照 Azure 体系结构中心的重试常规指导中的说明重试针对客户端代码实现的功能

提示

建议不要在每次重新启动设备时进行预配,因为此作可能会导致一次性重新预配数千或数百万台设备时出现问题。 应改为尝试使用设备注册状态查询 API,并尝试利用该信息连接到 IoT 中心。 如果尝试失败,请尝试重新配置,因为 IoT 中心的信息可能会发生变化。 请记住,查询注册状态会算作新的设备注册,因此应考虑 设备注册限制。 另请考虑实现适当的重试逻辑,例如使用随机化进行指数退避,如 重试常规指南中所述。 在某些情况下,根据设备功能,可以直接在设备上保存 IoT 中心信息,在使用 DPS 进行首次预配后直接连接到 IoT 中心。 如果选择直接在设备上保存,请确保在发生 IoT 中心的特定错误 时实现回退机制。 例如,考虑以下情况:

  • 如果结果代码为 429(请求过多)或为 5xx 范围内的错误,请重试 IoT 中心操作。 请勿针对其他任何错误重试操作。
  • 对于 429 错误,仅在 Retry-After 标头中指示的时间后重试。
  • 对于 5xx 错误,应采用指数退避,第一次重试至少应比该响应晚 5 秒。
  • 对于除了 429 和 5xx 之外的其他错误,则通过 DPS 重新注册
  • 理想情况下,还应支持 直接方法,以按需手动触发配置。

我们还建议在计划活动(例如,将更新推送到你的机群)时考虑服务限制。 例如,一次性全部更新机群可能会导致所有设备通过 DPS 重新注册(这样可能很容易超过注册配额限制)- 对于这些情况,请考虑分阶段计划设备更新,而不是同时更新整个机群。

管理后向兼容性

2018 年 9 月之前,设备分配到 IoT 中心具有粘性行为。 当设备经由预配过程返回时,它只会分配回同一个 IoT 中心。

对于依赖于此行为的解决方案,预配服务包括向后兼容性。 目前,根据以下标准对设备维护此行为:

  • 在设备预配服务中提供本机重新预配支持之前,设备与某 API 版本相连。 请参阅以下 API 表。

  • 设备的注册项没有在设备上设置重新预配策略。

此兼容性可确保先前部署的设备经历与初始测试期间相同的行为。 要保留以前的行为,请勿将重新预配策略保存到这些注册中。 如果设置了重新预配策略,则重新预配策略优先于该行为。 通过允许重新预配策略优先,客户可以更新设备行为,而无需重置设备映像。

以下流程图有助于显示行为出现时的情况:

显示设备行为的向后兼容性的流程图。

下表显示了在设备预配服务中提供本机重新预配支持之前的 API 版本:

REST API C SDK Python SDK Node SDK Java SDK .NET SDK
2018-04-01 及更低版本 1.2.8 及更低版本 1.4.2 及更低版本 1.7.3 及更低版本 1.13.0 及更低版本 1.1.0 及更低版本

注意

这些值和链接可能会有所更改。 Azure IoT SDK 和 API 经过版本控制,以确保应用程序和服务在产品和 API 不断发展时继续工作。 建议在这些 SDK 和 API 的参考文档中验证最新版本的 Azure IoT SDK 和 API。 例如,最新版本的 Azure IoT 中心设备预配服务 REST API 为 2021-10-01。

后续步骤