共用方式為

IoT 中樞型多租使用者解決方案的架構方法

  • 發行項

多租戶 IoT 中心型解決方案有多種不同的類型和大小。 您可能有許多需求和限制，範圍從基礎結構擁有權到客戶數據隔離，到合規性。 定義符合所有這些設計條件約束的模式可能會很困難，而且這樣做通常需要考慮多個維度。 本文章介紹了幾種常用方法，旨在解決以 IoT 中樞為基礎的解決方案中的多租用戶問題。

重要考量與需求

這些考慮和需求會依照通常優先處理解決方案設計的順序來呈現。

治理和合規性

治理和合規性考慮可能需要您使用特定模式或一組IoT資源。 並非所有IoT服務都有相同的認證或功能。 如果您需要符合特定的合規性標準，您可能需要選取特定服務。 若要深入瞭解，請參閱 多租用戶解決方案中的治理與合規性架構方法。

IoT 中的治理也可以採取其他形式，例如裝置擁有權和管理。 客戶是否擁有裝置或解決方案提供者？ 誰擁有這些裝置的管理？ 這些考慮和影響對於每個解決方案提供者而言都是獨一無二的，而且可能會導致您在所使用的技術、部署模式和多租使用者模式中有不同的選擇。

調整

規劃解決方案的規模很重要。 這三個維度通常會考慮縮放比例：

  • 裝置數量：所有 Azure 裝置管理服務 - Azure IoT Central、Azure IoT 中樞 裝置布建服務 （DPS）和 Azure IoT 中樞 - 對於單一實例支援的裝置數目有所限制。

    提示

    如果您打算部署非常大量的裝置，請參閱大規模的檔。

  • 裝置輸送量：不同的裝置，即使在相同的解決方案中，也可能有不同的輸送量需求。 此內容中的「輸送量」是指一段時間內的訊息數目和訊息大小。 例如，在某個例子中：

    • 智慧型建築解決方案，控溫器通常會以低於電梯的頻率報告數據。
    • 在連網車輛方案中，車輛相機錄製數據訊息通常大於導航遙測訊息。

    如果您的訊息在頻率方面受到限制，請考慮擴展至更多個服務實例。 如果您的訊息因大小限制而受到控制，請考慮升級到更大型的服務設置。

  • 租戶：單一租戶的規模可能很小，但當乘以租戶數目時，規模可以迅速增長。

效能和可靠性

租用戶隔離

完全共用的解決方案可以有 嘈雜的鄰居。 在 IoT 中樞和 IoT Central 的情況中，干擾的鄰近資源可能會導致 HTTP 429（「太多要求」）響應碼，這些響應碼是會造成連鎖反應的嚴重失敗。 如需詳細資訊，請參閱 配額和節流。

在完全多租用戶解決方案中，這些效果可以串聯。 當客戶共用IoT中樞或IoT Central應用程式時，共用基礎結構上的所有客戶都會收到錯誤。 由於 IoT 中樞 和 IoT Central 通常是數據進入雲端的進入點，因此相依於此數據的其他下游系統也可能會失敗。 通常，這些錯誤的最常見原因是超過訊息配額限制。 在此情況下，IoT 中樞 解決方案最快速且最簡單的修正是升級 IoT 中樞 SKU、增加 IoT 中樞 單位數目，或兩者。 針對IoT Central解決方案，解決方案會視需要自動調整，最多 可記錄支援的訊息數目。

您可以使用 DPS 自訂配置原則，將租用戶隔離並分散到 IoT 控制、管理和通訊平面。 此外，當您遵循 大規模 IoT 解決方案的指引時，您可以在 DPS 負載平衡器層級管理其他配置分配。

數據記憶體、查詢、使用量和保留

IoT 解決方案通常在串流和靜止時都會需要大量數據。 如需管理多租使用者解決方案中數據的詳細資訊，請參閱 多租使用者解決方案中記憶體和數據的結構方法。

安全性

IoT 解決方案通常具有多層的安全性考慮，特別是在雲端修改 的 Purdue 企業參考架構 或 產業 4.0 解決方案中部署的解決方案中。 您選取的設計方法會影響網路層級和界限存在;選取實體設計之後，您可以選取安全性實作。 您可以在任何方法中使用下列工具：

  • Microsoft適用於 IoT 的 Defender，您應該考慮使用完整的 IoT 監視解決方案，為每個客戶裝置和/或網站提供 每個裝置的 EIoT 授權 和 OT 月台授權 。 根據本文稍後介紹的不同方法，Microsoft 365 具名用戶授權案例可能無法實現。 在此情況下，每個裝置和月台授權選項都可供使用，這些選項與Microsoft 365 租使用者授權無關。

  • Azure 防火牆 或非微軟防火牆設備，您應考慮以這些設備來隔離網路層並監控網路流量。 方法的正確選擇決定工作負載在何處具有網路隔離與共享網路，如本文稍後所述。

  • Azure IoT Edge。

這些安全性主題大部分適用於多租使用者解決方案，類似於在單一租用戶解決方案中的使用方式，且變化會系結至選取的方法。 整體IoT解決方案中可能會有很大的不同元件是使用者和應用程式身分識別。 多租用戶解決方案 中身分識別的架構方法會討論整體多租用戶解決方案的這一層面。

要考慮的方法

針對單一與多租戶的IoT解決方案，主要元件的考慮和選擇，例如管理、擷取、處理、存儲和安全性，是相同的。 主要差異在於您排列及利用元件來支援多租使用者的方式。 例如，下列專案的常見決策點：

  • 儲存可以選擇使用 SQL Server 或 Azure 數據總管。
  • 資料攝取和管理層需要在 IoT 中樞 和 IoT Central 之間進行選擇。

大部分的IoT解決方案都適合根 架構模式，這是部署目標、租用模型和部署模式的組合。 先前描述的主要需求和考慮會決定這些因素。

IoT 空間中需要做出的最大決策點之一，就是在應用程式平臺即服務 （aPaaS） 和平臺即服務 （PaaS） 方法之間選取。 若要深入瞭解，請參閱 比較物聯網（IoT）解決方案方法（PaaS 與 aPaaS）。

這個選擇是許多組織在許多專案中面臨的常見「建置與購買」困境。 請務必評估這兩個選項的優點和缺點。

aPaaS 解決方案的概念和考慮

使用 Azure IoT Central 作為解決方案核心的一般 aPaaS 解決方案，可能會使用下列 Azure PaaS 和 aPaaS 服務：

  • Azure 事件中樞 為跨平臺、企業級傳訊和數據流引擎。
  • Azure Logic Apps 即整合平臺即服務或 iPaaS 供應專案。
  • Azure 數據總 管作為數據分析平臺。
  • Power BI 作為視覺效果和報告平臺。

I O T 架構，顯示共用 I O T Central 環境、Azure 數據總管、Power B I 和 Azure Logic Apps 的租使用者。

在上圖中，租用戶會共用IoT Central環境、Azure數據總管、Power BI 和 Azure Logic Apps。

這種方法通常是取得市場解決方案最快的方法。 這是一項支援多租使用者的高規模服務，其使用 組織。

請務必瞭解，因為IoT Central是 aPaaS 供應專案，因此有某些決策不在實作者的控制之外。 這些決策包括：

  • IoT Central 會使用 Microsoft Entra 標識碼作為其識別提供者。
  • IoT Central 部署是使用控制和數據平面作業來達成，其結合了宣告式檔與命令式程序代碼。
  • IoT Central 型多租使用者模式中的節點限制上限 和最大樹狀結構深度，可能會強制服務提供者擁有多個 IoT Central 實例。 在此情況下，您應該考慮遵循 部署戳記模式。
  • IoT Central 會 API 呼叫限制，這可能會影響大型實作。

PaaS 解決方案的概念和考慮

以 PaaS 為基礎的方法可能會使用下列 Azure 服務：

  • Azure IoT 中樞 作為核心裝置組態和通訊平臺。
  • Azure IoT 裝置布建服務 作為裝置部署和初始組態平臺。
  • Azure 資料總 管可用來儲存和分析來自 IoT 裝置的暖冷路徑時間序列數據。
  • Azure 串流分析 ，用於分析來自 IoT 裝置的熱路徑數據。
  • Azure IoT Edge，以在 IoT Edge 裝置上執行人工智慧（AI）、非Microsoft服務或您自己的商業邏輯。

顯示 I O T 解決方案的圖表。每個租用戶都會連線到共用 Web 應用程式，此應用程式會從 I O T 中樞和函式應用程式接收數據。裝置會連線到裝置布建服務和 I O T 中樞。

在上圖中，每個租用戶都會連線到共用 Web 應用程式，此應用程式會接收來自 IoT 中樞 和函式應用程式的數據。 裝置會連線到裝置布建服務和 IoT 中樞。

這種方法需要更多開發人員努力來建立、部署和維護解決方案（與 aPaaS 方法）。 針對實作者的便利性，預先建置的功能較少。 因此，這種方法也提供更多的控制，因為基礎平臺內嵌的假設較少。

根架構模式

下表列出多租使用者IoT解決方案的常見模式。 每個模式都包含下列資訊：

  • Pattern 的名稱，其以目標、模型和部署類型的組合為基礎。
  • 部署目標，代表要部署資源的 Azure 訂用帳戶。
  • 模式所參考的租用模型，如多租使用者模型中所述
  • 部署模式，是指使用最少部署考慮的簡單部署、Geode 模式或部署戳記模式。
模式 部署目標 租用模型 部署模式
簡單 SaaS 服務提供者的訂用帳戶 完全多租使用者 簡易
水準 SaaS 服務提供者的訂用帳戶 水平分割 部署戳記
單一租用戶自動化 服務提供者或客戶的訂用帳戶 每位客戶的單一租使用者 簡易

簡單 SaaS

顯示 I O T 架構的圖表。租用戶會共用 I O T Central 環境、Azure 數據總管、Power B I 和 Azure Logic Apps。

部署目標 租用模型 部署模式
服務提供者的訂用帳戶 完全多租使用者 簡易

簡單 SaaS 方法是 SaaS IoT 解決方案最簡單的實作。 如上圖所示，所有基礎結構都會共用，而且基礎結構未套用地理或縮放戳記。 基礎結構通常位於單一 Azure 訂用帳戶內。

Azure IoT Central 支援組織的概念。 組織可讓解決方案提供者以安全、階層的方式輕鬆隔離租用戶，同時在所有租用戶之間共用基本應用程序設計。

透過其他Microsoft PaaS 和 aPaaS 供應專案，與 IoT Central 外部的系統進行通訊，例如，透過其他Microsoft PaaS 和 aPaaS 供應專案進行長期數據分析，或與商務營運的連線。 這些其他供應專案可能包含下列服務：

  • Azure 事件中樞 為跨平臺、企業級傳訊和數據流引擎。
  • Azure Logic Apps 即整合平臺即服務或 iPaaS。
  • Azure 數據總 管作為數據分析平臺。
  • Power BI 作為視覺效果和報告平臺。

如果您比較 Simple SaaS 方法與單一租使用者自動化 aPaaS 模型，則許多特性都類似。 這兩個模型的主要差異在於：

  • 在 單一租使用者自動化 模型中，您會為每個租使用者部署不同的 IoT Central 實例，
  • 在具有 aPaaS 模型的 Simple SaaS 中，您會為多個客戶部署共用實例，併為每個租使用者建立 IoT Central 組織。

由於在此模型中共用多租戶資料層，因此您必須實施列層級安全性，才能隔離客戶資料。 若要深入瞭解，請參閱 多租戶解決方案中的儲存和資料的架構方法。

優點：

  • 相較於此處顯示的其他方法，更容易管理和操作。

風險：

  • 這種方法可能不容易 擴展至大量的裝置、訊息或租戶，。

  • 共用服務和元件，因此任何元件中的失敗可能會影響您的所有租使用者。 此風險是解決方案可靠性和高可用性的風險。

  • 請務必考慮如何管理設備群組的合規性、操作、承租者生命週期和安全性。 由於控制、管理和通訊平面上此解決方案類型的共用本質，這些考慮會變得很重要。

水準 SaaS

部署目標 租用模型 部署模式
服務提供者的訂用帳戶 水平分割 部署戳記

常見的延展性方法是 水準分割解決方案。 這表示您有一些共享元件和一些個別客戶元件。

在IoT解決方案中，有許多元件可以水準分割。 水準分割子系統通常會使用 部署戳記模式 來排列，其與更大的解決方案整合。

水準 SaaS 範例

下列架構範例會分割每個端客戶的IoT Central，其可作為裝置管理、裝置通訊和管理入口網站。 此數據分割通常會以這樣的方式完成，讓取用解決方案的終端客戶完全控制新增、移除及更新其裝置，而不需要軟體廠商介入。 解決方案的其餘部分遵循標準共用基礎結構模式，可解決熱路徑分析、商務整合、SaaS 管理和裝置分析需求。

I O T 解決方案的圖表。每個租使用者都有自己的 I O T Central 組織，其會將遙測傳送至共用函式應用程式，並透過 Web 應用程式提供給租使用者的商務使用者。

每個租使用者都有自己的IoT Central組織，其會將遙測傳送至共用函式應用程式，並透過Web應用程式提供給租使用者的商務使用者。

優點：

  • 雖然單一租用戶元件可能需要額外的管理，但易於管理和操作。
  • 彈性調整選項，因為圖層會視需要進行調整。
  • 元件故障的影響會降低。 雖然共享元件的故障會影響所有客戶，但水平擴展的元件只會影響與特定擴展實例相關聯的客戶。
  • 已改善分割元件的個別租使用者耗用量深入解析。
  • 分割的元件可讓您更輕鬆地進行個別租使用者自定義。

風險：

  • 規模化解決方案，尤其適用於任何共用元件。
  • 可靠性和高可用性可能會受到影響。 共用元件中的單一失敗可能會同時影響所有租使用者。
  • 個別租使用者分割元件自定義需要長期 DevOps 和管理考慮。

下列是通常適用於水平分割的最常見元件。

資料庫

您可以選擇分割資料庫。 通常是分割的遙測和裝置數據存放區。 通常，多個數據存放區會用於不同的特定用途，例如暖與封存記憶體，或租使用者訂用帳戶狀態資訊。

針對下列優點，將每個租用戶的資料庫分開：

  • 支持合規性標準。 每個租用戶的數據會在數據存放區的實例之間隔離。
  • 補救嘈雜的鄰近問題。

裝置管理、通訊和管理

Azure IoT 中樞 裝置布建服務、IoT 中樞 和IoT Central應用程式通常可以部署為水準分割的元件。 在此方法中，您需要另一項服務，以便將裝置重新導向至適合該特定租戶的管理、控制及遙測平面的 DPS 實例。 若要深入瞭解，請參閱 向外延展 Azure IoT 解決方案，以支援數百萬個裝置 白皮書。

這種方法通常用來讓終端客戶管理及控制本身更直接且完全隔離的裝置車隊。

如果裝置通訊平面是水平分割的，則必須用能夠識別來源租戶的數據來增強遙測數據。 此充實功能使數據流處理器能夠識別和套用至數據流的租戶規則。 例如，如果遙測訊息在串流處理器中產生通知，則數據流處理器必須判斷相關聯租用戶的適當通知路徑。

串流處理

透過數據分割串流處理，您可以啟用串流處理器內分析的個別租使用者自定義。

單一租用戶自動化

單一租使用者自動化方法是以與企業解決方案類似的決策流程和設計為基礎。

此圖顯示三個租使用者的 I O T 架構。每個租使用者都有自己的相同隔離環境，具有 I O T Central 組織和其他專屬元件。

每個租使用者都有自己的相同隔離環境，以及IoT Central組織及其專用的其他元件。

部署目標 租用模型 部署模式
服務提供者或客戶的訂用帳戶 每位客戶的單一租使用者 簡易

此方法中的重要決策點是選擇應部署元件的 Azure 訂用帳戶。 如果元件部署至您的訂用帳戶，您可以更充分掌控解決方案的成本，但需要您擁有更多解決方案的安全性和治理考慮。 相反地，如果解決方案部署在客戶的訂用帳戶中，則客戶最終會負責部署的安全性和治理。

此模式支援高度延展性，因為租使用者和訂用帳戶需求通常是大部分解決方案的限制因素。 因此，隔離每個租使用者，以在解決方案開發人員身分的情況下，為調整每個租使用者的工作負載提供較大的範圍。

相較於其他模式，此模式通常也有低延遲，因為您可以根據客戶的地理位置來部署解決方案元件。 地理親和性可讓IoT裝置與 Azure 部署之間的網路路徑較短。

如有必要，您可以藉由在現有或新的地理位置中快速部署解決方案的額外實例，擴充自動化部署以支援改善的延遲或規模。

單 一租用戶自動化 方法類似於 簡單的 SaaS aPaaS 模型。 這兩個模型之間的主要差異在於，在單一租使用者自動化方法中，您會為每個租使用者部署不同的IoT Central實例，而在具有 aPaaS 模型的簡單 SaaS 中，您會為多個 IoT Central 組織部署 IoT Central 的共用實例。

優點：

  • 易於管理和操作。
  • 租戶隔離可獲得保證。

風險：

  • 新開發人員的初始自動化可能很複雜。
  • 必須強制執行高階部署管理的跨客戶認證安全性，或入侵可以跨客戶延伸。
  • 成本預期會更高，因為無法享受到跨客戶共享基礎設施的規模效益。
  • 若由解決方案提供者負責每個實例的維護，則需維護的實例會有很多。

增加 SaaS 的規模

當您將解決方案的規模擴充到大型部署時，會根據服務限制、地理考慮和其他因素而發生特定挑戰。 如需大規模IoT部署架構的詳細資訊，請參閱 相應放大 Azure IoT 解決方案以支援數百萬部裝置。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

下一步

  • 檢閱多租使用者和 Azure Cosmos DB 的指引。
  • 瞭解 Azure 上的 IoT 熱、暖和冷數據路徑。