你当前正在访问 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 中心的已更新设备状态信息将迁移到新的 IoT 中心 (2)。 迁移期间，设备的状态将报告为“正在分配” 。

  

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

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

  

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

注意

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

在设计解决方案和定义重新预配逻辑时，需要考虑几个事项。 例如：

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

提示

建议不要在每一次重新启动设备时都进行预配，因为这可能会导致在一次性重新预配数千或数百万台设备时出现一些问题。 应改为尝试使用设备注册状态查询 API，并尝试利用该信息连接到 IoT 中心。 如果这样操作失败，则请尝试重新预配，因为 IoT 中心信息可能已更改。 请记住，查询获取注册状态将会计为新设备注册，因此，应考虑设备注册限制。 还要考虑实现相应的重试逻辑，例如，通过随机化进行的指数退避，如重试常规指导中所述。 在有些情况下，根据设备功能不同，或许可以在首次发生了使用 DPS 进行的预配后，直接在设备上保存 IoT 中心信息，以便直接连接到 IoT 中心。 如果你选择这样操作，请确保实现退避机制，以防收到中心发生的特定错误，例如，请考虑以下情形：

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

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

管理后向兼容性

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

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

1. 在设备预配服务中提供本机重新预配支持之前，设备与某 API 版本相连。 请参阅下面的 API 表。

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

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

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

下表显示了在设备预配服务中提供本机重新预配支持之前的 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 及更早版本

注意

这些值和链接可能会有所更改。 这只是占位符，尝试确定客户可以在何处确定版本以及预期的版本是什么。

后续步骤

• 如何重新预配设备