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 或先前版本

注意

這些值與連結可能會變更。 這只是嘗試判斷客戶可判斷之版本與預期版本的預留位置。

下一步

• 如何重新佈建裝置