IoT 平台產品通常提供基本的 MQTT 和 HTTPS 資料連線。您也可以透過這些服務佈建裝置，並進行驗證和管理、遙測儲存和視覺化、資料處理和警報。如果獨立 MQTT 代理程式無法滿足用途需求，且需要更完整的物聯網平台產品，機構通常會使用物聯網平台。IoT 平台提供統一介面，可管理各種裝置。這個介面對於許多連線裝置應用程式來說非常重要，也是 IoT 平台與獨立 MQTT 代理程式的主要差異。本文概述在 Google Cloud上部署 IoT 平台產品架構前，您需要考量的基本架構和建議。
本文是系列文件之一，提供有關 Google Cloud上的 IoT 架構資訊。本系列的其他文件包括：
- 已連結裝置架構總覽 Google Cloud
- Google Cloud獨立 MQTT 代理程式架構
- IoT 平台產品架構(本文件) Google Cloud
- 在 Google Cloud 上執行 IoT 後端的最佳做法
- 裝置在 Pub/Sub 架構上 Google Cloud
- 自動佈建及設定邊緣和裸機系統與伺服器的最佳做法
下圖顯示範例架構，其中通用 IoT 平台產品在 Google Cloud上執行。
如上圖所示，IoT 平台會部署 MQTT 代理程式或端點，供裝置連線。IoT 平台會連線至外部 Proxy 網路負載平衡器，以分配邊緣裝置的流量。其他 IoT 應用程式可透過 Pub/Sub 或使用 Dataflow MQTT 連接器，連線至 IoT 平台。
IoT 平台提供一系列裝置管理服務，如圖所示，這些服務如下：
- 裝置憑證儲存空間
- 規則引擎
- 裝置驗證與授權
- 裝置設定管理
- 裝置登錄
- 裝置更新管理
IoT 平台產品通常也包含數位分身功能、低程式碼開發介面、警報和通知功能，以及其他分析功能等服務。
架構考量和選擇
以下各節說明 IoT 平台產品架構的架構選項，以及這些選項的影響。
擷取端點
大多數商用 IoT 平台應用程式都包含 MQTT 端點，通常也會包含 HTTPS 端點，用於從連線裝置擷取資料。
MQTT
物聯網平台會透過下列其中一種方式實作 MQTT 端點：
- MQTT 與其他訊息服務之間的連接器
- 實作完整 MQTT 規格的 MQTT 代理程式
評估商用物聯網平台時，請務必瞭解供應商為產品選擇了上述哪種方法，以便判斷對您使用情境的影響。
在某些情況下，MQTT 端點只會將 MQTT 用戶端連線至後端訊息服務，例如 Kafka 或 Pub/Sub。這類端點通常不會實作完整的 MQTT 協定規格，而且通常不包含 QoS 等級 1 和 2 或共用訂閱等功能。這種做法的優點是可降低 IoT 平台複雜度，因為沒有個別的 MQTT 代理程式應用程式。與使用獨立 MQTT 代理程式的平台相比，作業成本較低，維護也較簡單。不過，由於對更進階的 MQTT 通訊協定功能支援度降低，與實作完整 MQTT 規格的獨立 MQTT 代理程式相比，這種做法的 MQTT 訊息傳輸彈性和功能較少。
其他 IoT 平台會提供完整的 MQTT 代理程式，做為平台的一部分，如本文的架構範例所示。這個代理程式可以是現有的開放原始碼代理程式，也可以是專有代理程式實作。完整 MQTT 代理程式提供前述完整的雙向 MQTT 功能，但完整代理程式可能會增加 IoT 平台管理的複雜度和營運成本。
HTTPS 和其他補充通訊協定
除了 MQTT 之外，許多物聯網平台提供的資料擷取端點，都比本文主要架構中顯示的端點更多。
HTTPS 是 MQTT 以外的常見替代通訊協定，適用於連線裝置用途。雖然與 MQTT 相比，HTTP 的額外負荷較高，但手機等行動裝置、網頁瀏覽器和其他應用程式都廣泛支援 HTTP。這項技術常用於特定連線裝置應用程式，並支援 Eclipse Hono 等開放原始碼平台和許多商用產品。
許多受限裝置應用程式會使用受限應用程式通訊協定 (CoAP，定義於 RFC 7252)，做為 MQTT 的替代方案。CoAP 的目標是為嵌入式裝置和感應器提供低負荷和小型用戶端。許多商用物聯網平台應用程式也提供 CoAP 端點。
負載平衡
如要進一步瞭解如何為架構選擇最佳負載平衡器，請參閱「 Google Cloud獨立 MQTT 代理程式架構」的負載平衡一節，因為這些考量因素也適用於這個案例。
裝置驗證和憑證管理
管理裝置憑證和驗證是 IoT 平台運作的重要環節。連網裝置支援的驗證方法因應用程式和裝置板型規格而異。請務必為目標用途選取適當的驗證方式，並正確實作所選的驗證機制。
與獨立的 MQTT 代理程式不同，IoT 平台提供整合式服務，可管理裝置身分和憑證。大多數物聯網平台會使用 X.509 用戶端憑證驗證、以 JWT 權杖為基礎的驗證 (通常會搭配 OAuth 2.0)，以及使用者名稱和密碼驗證。部分平台也支援與外部 LDAP 驗證供應商整合。
對於某些資源受限的裝置，JWT 或使用者名稱和密碼驗證可能更合適，因為這些機制在連線裝置上需要的資源較少。使用 JWT 或使用者名稱和密碼驗證時，請務必將網路連線與 mTLS 驗證分開加密，因為這兩種驗證方法都不需要加密連線。相較之下，X.509 憑證驗證會耗用連線裝置的更多資源，但通常用於 mTLS 加密連線，因此可提供高安全等級。
在製造時於邊緣裝置上佈建驗證憑證，也是連線裝置驗證機制的重要環節，但不在本文的討論範圍內。
如要進一步瞭解驗證和憑證管理，請參閱「在 Google Cloud上執行 IoT 後端的最佳做法」。
管理已連結的裝置
一般來說，連線裝置會透過 MQTT 等擷取端點，將遙測事件和狀態資訊發布至平台。如果您使用多重通訊協定 IoT 平台，裝置可以透過任何支援的通訊協定進行通訊。
建議貴機構使用具備下列功能的 IoT 平台：
- 軟體和系統更新：將韌體、軟體和應用程式更新傳送至連線裝置，以及將這些更新還原至連線裝置。這些更新通常也涉及更新本身的儲存和管理作業。
- 設定更新：將更新項目傳送、儲存及回溯至已部署在連線裝置上的應用程式設定。
- 憑證建立和管理：建立新的裝置憑證、將這些憑證傳送至連線裝置、稽核裝置存取嘗試和活動，以及在適當時間撤銷遭盜用或過期的憑證。
- 規則引擎和資料處理：定義及執行資料驅動規則和其他資料處理步驟。這項功能通常包含某種低程式碼介面，可定義規則和資料處理管道。
後端工作負載
大多數 IoT 平台都提供內部資料儲存和傳輸功能，可讓您連線至後端工作負載和應用程式。AMQP、RabbitMQ 和 Kafka 通常用於提供內部資料傳輸。您可以使用 Pub/Sub SDK 將這些項目連結至 Pub/Sub。您也可以使用 PostgreSQL 等整合式資料庫系統，在平台上儲存資料。在許多情況下，您可以設定 IoT 平台直接使用其中一項 Cloud Storage 產品，例如 Cloud SQL、Firebase 或 BigQuery。
如果 IoT 平台有完整的 MQTT 代理程式，後端應用程式也可以使用平台的 MQTT 功能與裝置通訊。如果應用程式支援 MQTT，應用程式可以訂閱者的身分連線至代理程式。如果沒有 MQTT 支援，Apache Beam 會提供 MQTT 驅動程式，可與 Dataflow 及其他 Beam 部署作業進行雙向整合。
用途
以下各節說明範例情境，在這些情境中，IoT 平台是比獨立 MQTT 代理程式或直接連線至 Pub/Sub 更合適的架構選擇。
智慧型家電管理
管理多個智慧型家電的應用程式非常適合 IoT 平台。舉例來說，這類應用程式可以是管理廚房電器 (例如洗碗機和咖啡機) 的平台。這類裝置通常會直接透過 Wi-Fi 連線至雲端應用程式，或是透過使用藍牙低功耗 (BLE) 或其他本機通訊協定的本機閘道連線。IoT 平台管理功能在此扮演重要角色，可監控各裝置的狀態、管理軟體更新和安全性修補程式，以及擷取裝置活動，為製造商和客戶提供重要情報。這些功能超出基本 MQTT 代理程式的範圍。如要建構成功的智慧型家電平台，至少需要裝置資訊存放區、裝置狀態資料庫、遙測資料存放區和分析介面。
物流和資產追蹤
以物流和資產追蹤應用程式為例，IoT 平台產品提供的功能比基本的 MQTT 代理程式更完整，因此是這類用途的理想選擇。監控大量資產的目前和過去狀態與位置，取決於健全的裝置狀態資料庫和身分管理系統。部署新資產時，必須盡可能順利地將資產連線至平台，並在資產生命週期內持續監控。在許多情況下，應用程式也會收集資產的其他感應器資訊，例如當地溫度、濕度和大氣壓力，或是 3D 定位和加速度資料，以偵測意外移動或掉落。所有這些資料都必須擷取並與正確的資產建立關聯，才能在任何後端應用程式中進行分析，因此 IoT 平台提供的全功能裝置管理是重要的功能。
後續步驟
- 請參閱 Google Cloud 「Intelligent Products Essentials」，瞭解如何連線裝置及建構 IoT 應用程式。
- 瞭解如何自動佈建及設定邊緣和裸機系統與伺服器。
- 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。