Azure IoT 參考架構

Blob 儲存體
函式
IoT 中樞
IoT 裝置佈建服務
Logic Apps
串流分析

本文討論使用 Azure PaaS (平臺即服務) 元件的建議 IoT 應用程式架構。 下圖反映可用於架構 IoT 解決方案的不同 Azure 元件。 下圖顯示的是大部分常用的服務,而這篇文章也有重點,但是沒有解決方案需要所有的服務。 如果您剛開始使用 Azure IoT 或想要建立您的第一個概念證明解決方案,請從這裡開始:

架構 圖表

此參考架構使用 Azure PaaS (平台即服務) 元件。 Microsoft 建議開始使用Azure IoT Central,這是一個 aPaaS (應用程式平臺即服務) IoT 解決方案平臺。 其設計目的是要藉由 preassembling、調整及管理此參考架構中所述的許多相同 PaaS 服務,來簡化及加速 IoT 解決方案元件和作業。 這項結果是現成可用的 UX 和 API 介面區,可透過大規模連線、管理及操作機群所需的功能來完成。 深入瞭解 如何根據您的解決方案需求,比較 IoT Central (aPaaS) 與 PaaS 解決方案的方法。

Azure IoT 的解決方案 牽涉到 (通常會產生資料的 裝置) 、您針對資料所形成的 見解,以及您根據見解所採取的 動作。 考慮傳送溫度資料的馬達。 這項資料是用來評估馬達是否如預期般執行。 其效能的深入解析會用來優先處理馬達的維護排程。

裝置

Azure IoT 支援大量的裝置,從執行 Azure rto 的微控制器,到 Azure Sphere 的開發人員面板(例如MX 晶片和 Raspberry Pi)。 Azure IoT 也支援能夠執行自訂程式碼的智慧型伺服器閘道。 裝置可能會透過 Azure IoT Edge 之類的服務來執行某些本機處理,或直接連線到 Azure,讓他們可以將資料傳送至 IoT 解決方案並從中接收資料。

當裝置連線到雲端時,有幾項服務可協助擷取資料。 Azure IoT 中樞 是雲端閘道服務,可以安全地連接和管理裝置。 IoT 中樞裝置布建服務 (DPS) 可讓您以安全且可調整的方式,以無需觸控的即時布建方式來註冊大量的裝置。 Azure 數位 Twins 可啟用真實世界系統的虛擬模型。

深入解析

在雲端中連線到裝置之後,就可以處理及探索其資料,以取得其環境的自訂見解。 概括而言,有三種方式可以處理資料 — 熱路徑、暖路徑和冷路徑。 它們之間的差異與延遲和資料存取的需求不同。

  • 最忙碌 路徑 會在資料到達時,以近乎即時的方式分析資料。 在最忙碌路徑中,必須以非常低的延遲處理遙測。 最忙碌路徑通常是使用串流處理引擎來實作。 請考慮使用 Azure 串流分析HDInsight 之類的服務。 輸出可能會觸發警示,或寫入可以使用分析工具查詢結構化的格式。
  • 暖路徑 會分析可以容納較長延遲的資料,以進行更詳細的處理。 請考慮 Azure 資料總管Azure 時間序列深入解析 來儲存和分析大量資料。
  • 非經常性路徑 以較長的時間間隔 (每小時或每日) 執行批次處理。 冷路徑通常會在大量資料上運作,這些資料可以儲存在 Azure Data Lake 中,而且結果不需要像經常性存取或暖路徑一樣及時進行。 請考慮使用 Azure Machine LearningAzure Databricks 來分析冷資料。

動作

您可以使用收集到的資料見解來管理和控制您的環境。 商務整合動作可能包括儲存資訊訊息、引發警示、傳送電子郵件或 SMS 訊息,或與 CRM 和 ERP 等商務應用程式整合。 下列服務適用于管理和商務整合:

  • Power BI 會連接、模型化資料,以及將資料視覺化。 Power BI 可讓您在資料上共同作業,並使用人工智慧來做出資料驅動的決策。
  • Azure 地圖服務 可讓您使用地理空間服務來建立定位感知的 web 和行動應用程式 (搜尋、地圖、路由、追蹤和流量) 、api 和 sdk。
  • Azure 認知搜尋 會針對不同類型的內容提供搜尋服務。 這包括編制索引、AI 擴充和查詢功能。
  • AZURE API 管理 提供單一位置來管理您的所有 api。
  • Azure Web Apps 可讓您部署可隨著組織調整的 Web 應用程式。
  • Mobile Apps 可讓您建立適用于 iOs、Android、Windows 或 Mac 的跨平臺和原生應用程式。
  • Dynamics 365 結合 CRM (客戶關係管理) 和 ERP (雲端中的企業資源規劃) 。
  • Microsoft Flow 是一項 SaaS 服務,可跨應用程式和其他 SaaS 服務自動化工作流程。
  • Azure Logic Apps 是以雲端為基礎的 PaaS 供應專案,用來建立及自動化整合您的應用程式、資料、服務和系統的工作流程。

另外還有數個 Azure 提供的服務可協助您監視整個 IoT 解決方案,並保持安全。 診斷服務包含 Azure 監視器Azure Active Directory 的安全性服務和 適用于 IoT 的 Azure Defender 可協助您控制、查看及管理安全性設定、威脅偵測和回應。

Digital Twins

客戶正在探索 數位 Twins ,作為控制和監視連線環境的機制。 數位對應項是真實環境環境的虛擬模型,其會與來自商務系統和 IoT 裝置的資料驅動。 它是用來為企業或組織啟用見解和動作。 開發人員和架構設計人員想要以數位 twins 作為解決方案,以啟用智慧型和連線環境,如下所示:

  • 製造業中的預測性維護
  • 供應鏈可見度
  • 適用于即時清查的智慧型貨架
  • 連接的家庭和智慧建築

大規模部署

打造您的解決方案,以全球規模進行部署。 為了達到最佳的擴充性,請將您的 IoT 應用程式建立為可獨立擴充的離散服務。 本節包含各種 Azure 服務的擴充性考慮。

函數。 從事件中樞端點讀取時,每個事件中樞分割區最多有一個函式執行個體。 最快的處理速率取決於一個函式執行個體處理來自單一分割區事件的速度。 該函式應該批次處理訊息。

IoT 中樞。 對於 IoT 中樞,請考慮下列比例因素:

  • IoT 中樞每日配額訊息的上限。
  • IoT 中樞執行個體中已連線裝置的配額。
  • 擷取輸送量 — IoT 中樞可以擷取訊息的速度。
  • 處理輸送量 — 處理內送訊息的速度。

每個 IoT 中樞都會以特定定價和級別層中的特定單位數進行布建。 層級和單位數會決定裝置每天可傳送至中樞的訊息配額上限。 如需詳細資訊,請參閱 IoT 中樞配額和節流。 您可以相應增加一個中樞,而不會中斷現有作業。

串流分析。 如果串流分析作業與串流分析管道 (從輸入到查詢再到輸出) 中的所有點為平行處理,則串流分析作業的擴展性最佳。 完全平行的作業允許串流分析橫跨多個計算節點來分割工作。 如需詳細資訊,請參閱利用 Azure 串流分析中的查詢平行化作業

IoT 中樞根據裝置識別碼自動分割裝置訊息。 特定裝置的所有訊息一定會抵達相同的磁碟分割,但單一分割區將具有來自多個裝置的訊息。 因此,平行處理的單位是分割區識別碼。

安全性

本節包含建立安全解決方案的考慮。

零信任安全性模型

零信任是一種安全性模型,會假設會發生缺口,並將每個存取嘗試視為來自開放式網路。 零信任假設您已執行基本功能,例如保護身分識別和限制存取。 這包括明確驗證使用者、查看其裝置,以及能夠使用即時風險偵測來進行動態存取決策。 符合基本概念之後,您可以將焦點轉移到下列零信任 IoT 解決方案的需求:

  • 使用強身份識別來驗證裝置。
  • 使用最小的特殊許可權存取,以減少群發半徑。
  • 監視裝置健康情況以存取閘道,或旗標裝置以進行補救。
  • 執行更新以保持裝置狀況良好。
  • 用來偵測及回應新興威脅的監視器。

如需完整的詳細資料,請參閱物聯網白皮書的 零信任網路安全性

可信任和安全的通訊

從裝置接收和傳送的所有資訊都必須是可信任的。 除非裝置可支援下列密碼編譯功能,否則應限制為區域網路,並且所有網際網路通訊都應當透過現場閘道:

  • 具有可證明安全、公開分析且廣泛實行對稱金鑰加密演算法的資料加密和數位簽章。
  • 支援 TCP 的 TLS 1.2 或其他以資料流為基礎的通訊路徑,或 DTLS 1.2 以資料包為基礎的通訊路徑。 X.509 憑證處理的支援是選擇性的,可以替換為 TLS 的 的計算效率更高且網路效率預先共用金鑰模式,其可透過支援 AES 和 SHA-2 演算法來實作。
  • 可更新的金鑰存放區和每一裝置索引鍵。 每個裝置都必須有唯一的金鑰材質或權杖,以將其識別為系統。 裝置應將金鑰安全地儲存在裝置 (例如,使用安全金鑰存放區) 上。 裝置應能夠定期更新金鑰或權杖,或在緊急情況 (例如系統漏洞) 下進行反應。
  • 必須允許裝置上的韌體和應用程式軟體進行更新,以便修復發現的安全性漏洞。

許多裝置的限制不支援這些需求。 在此情況下,您應該使用現場閘道。 裝置透過區域網路安全地連線到現場閘道上,並且閘道可啟用與雲端的安全通訊。

實體竄改

強烈建議裝置設計納入防止實體操作嘗試的功能,以協助確保安全性完整性和整體系統的可信度。

例如:

  • 選擇微控制器/微處理器或輔助硬體,以提供安全的儲存和使用密碼編譯金鑰內容,例如可信賴平臺模組 (TPM) 整合。
  • 安全開機載入器和安全軟體載入(錨定在 TPM 中)。
  • 使用感應器偵測入侵嘗試,並嘗試使用裝置的警示和可能的「數位自我損毀」來操作裝置環境。

如需額外的安全性考量,請參閱物聯網 (IoT) 安全性架構

可靠性和效能

復原 IoT 解決方案的重要考慮範圍是商務持續性和嚴重損壞修復。 針對高可用性設計 (HA) 和嚴重損壞修復 (DR) 可協助您定義和達成解決方案所需的執行時間目標。

不同的 Azure 服務提供不同的冗余和容錯移轉選項,可協助您達成最符合您商務目標的執行時間目標。 若要將其中任何 HA/DR 替代方案納入您的 IoT 解決方案中,必須先謹慎評估下列事項的取捨:

  • 您需要的復原層級
  • 實作和維護的複雜度
  • 銷售 (COGS) 影響的商品成本

《 Azure 商務持續性技術指南」   一文說明可協助您思考商務持續性和嚴重損壞修復的一般架構。  Azure 應用程式的嚴重損壞修復和高可用性   白皮書提供適用于 azure 應用程式之策略的架構設計指導方針,以達成高可用性 (HA) 和嚴重損壞修復 (DR) 。

您也可以在每個 Azure IoT 服務的檔中找到服務特定的效能資訊。

成本考量

一般情況下,請使用 Azure 定價計算機 來預估成本。 Microsoft Azure Well-Architected Framework的「成本」一節中會說明其他考慮。

下一步

如需解決方案架構個別部分的詳細資訊,請參閱下列主題: