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 中樞的情況下恢復出廠預設值。

  

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

注意

不論重新布建原則為何，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. 裝置的註冊項目未設定裝置重新佈建原則。

此相容性可確保先前部署的裝置會經歷與初始測試期間相同的行為。 若要保留先前的行為，請不要將重新佈建原則儲存到這些註冊中。 如果設定了重新佈建原則，重新佈建原則的優先順序會高於該行為。 透過允許重新佈建原則取得優先順序，客戶就可以在不需要為裝置重新安裝映像的情況下更新裝置行為。

下列流程圖顯示存在該行為的時間：

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

注意

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

下一步

• 如何重新布建裝置