Share via

IoT 中樞裝置重新布建概念

  • 發行項

在 IoT 解決方案的生命週期中，通常會在 IoT 中樞之間移動裝置。 此移動的原因可能包括下列案例：

  • 地理位置/地理位置/地理位置 ：當裝置在位置之間移動時，藉由讓裝置移轉至更接近的 IoT 中樞來改善網路延遲。

  • 多租使用者 ：裝置可以在相同的 IoT 解決方案內使用，並重新指派給新客戶或客戶網站。 這個新客戶可以使用不同的 IoT 中樞來提供服務。

  • 解決方案變更 ：裝置可以移至新的或更新的 IoT 解決方案。 此重新指派可能需要裝置與連線至其他後端元件的新 IoT 中樞通訊。

  • 隔離 ：類似于解決方案變更。 故障、遭入侵或過期的裝置可能會重新指派給只能更新並返回合規性的 IoT 中樞。 裝置正常運作之後，就會移轉至其主要中樞。

裝置布建服務內的重新布建支援可解決這些需求。 根據裝置註冊專案上設定的重新布建原則，裝置可以自動重新指派給新的 IoT 中樞。

裝置狀態資料

裝置狀態資料是由裝置 對應項和裝置功能所組成 。 此資料會儲存在裝置布建服務實例中，以及指派裝置的 IoT 中樞。

Diagram that shows how provisioning works with the Device Provisioning Service.

一開始使用裝置布建服務實例布建裝置時，會完成下列步驟：

  1. 裝置會將布建要求傳送至裝置布建服務實例。 服務實例會根據註冊專案來驗證裝置身分識別，並建立裝置狀態資料的初始設定。 服務實例會根據註冊組態將裝置指派給 IoT 中樞，並將該 IoT 中樞指派傳回給裝置。

  2. 布建服務實例會將任何初始裝置狀態資料的複本提供給指派的 IoT 中樞。 裝置會連線到指派的 IoT 中樞，並開始作業。

一段時間後，IoT 中樞上的裝置狀態資料可能會由 裝置作業 和 後端作業 更新。 儲存在裝置布建服務實例中的初始裝置狀態資訊會維持不變。 這個未觸控的裝置狀態資料是初始設定。

Provisioning with the Device Provisioning Service

視案例而定，當裝置在 IoT 中樞之間移動時，可能需要將先前 IoT 中樞上更新的裝置狀態移轉至新的 IoT 中樞。 裝置布建服務中的重新布建原則支援此移轉。

重新布建原則

視案例而定，裝置可以在重新開機時將要求傳送至布建服務實例。 它也支援手動觸發隨選布建的方法。 註冊專案上的重新布建原則會決定裝置布建服務實例如何處理這些布建要求。 此原則也會決定在重新布建期間是否應該移轉裝置狀態資料。 個別註冊和註冊群組可以使用相同的原則：

  • 重新布建和移轉資料 ：此原則是新註冊專案的預設值。 當與註冊專案相關聯的裝置提交新要求 （1） 時，此原則會採取動作。 視註冊專案組態而定，裝置可能會重新指派給另一個 IoT 中樞。 如果裝置正在變更 IoT 中樞，將會移除初始 IoT 中樞的裝置註冊。 來自該初始 IoT 中樞的更新裝置狀態資訊將會移轉至新的 IoT 中樞 （2）。 在移轉期間，裝置的狀態會回報為 指派 。

    Diagram that shows that a policy takes action when devices associated with the enrollment entry submit a new request.

  • 重新布建並重設為初始設定 ：當與註冊專案相關聯的裝置提交新的布建要求 （1） 時，此原則會採取動作。 視註冊專案組態而定，裝置可能會重新指派給另一個 IoT 中樞。 如果裝置正在變更 IoT 中樞，將會移除初始 IoT 中樞的裝置註冊。 布建裝置時，布建服務實例接收到的初始組態資料會提供給新的 IoT 中樞 （2）。 在移轉期間，裝置的狀態會回報為 指派 。

    此原則通常用於原廠重設，而不需要變更 IoT 中樞。

    Diagram that shows how a policy takes action when devices associated with the enrollment entry submit a new provisioning request.

  • 永不重新布建 ：裝置永遠不會重新指派給不同的中樞。 此原則是為了管理回溯相容性而提供。

注意

不論重新布建原則為何，DPS 一律會呼叫自訂配置 Webhook，以防裝置有新的 ReturnData 。 如果重新布建原則設定為 永不重新 布建，則會呼叫 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. 裝置的註冊專案未設定重新布建原則。

此相容性可確保先前部署的裝置在初始測試期間遇到相同的行為。 若要保留先前的行為，請勿將這些註冊儲存重新布建原則。 如果已設定重新布建原則，重新布建原則的優先順序高於行為。 藉由允許重新布建原則優先，客戶可以更新裝置行為，而不需要重新映射裝置。

下列流程圖有助於顯示行為出現時機：

backwards compatibility flow chart

下表顯示裝置布建服務中原生重新布建支援可用性之前的 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 或更早版本

注意

這些值和連結可能會變更。 這只是一個預留位置嘗試，以判斷客戶可以決定版本的位置，以及預期的版本。

下一步