裝置透過 Pub/Sub 連線至 Google Cloud

某些機構可能會直接從邊緣裝置連線至 Pub/Sub,而不必實作特定架構,將裝置連線至數據分析應用程式。如果機構的連線裝置數量不多,但會匯總本機或內部部署網路中大量裝置和感應器的資料,建議採用這種做法。如果貴機構的連線裝置位於較安全的環境 (例如工廠),也建議採用這種做法。本文概要說明您需要考量的高階架構,以便使用這種方法將裝置連線至 Google Cloud 產品。

本文是系列文件之一,提供 Google Cloud上的 IoT 架構相關資訊。本系列的其他文件包括:

架構

下圖顯示已連線的匯總裝置或閘道,直接連線至 Pub/Sub。

已連線至 Pub/Sub 的匯總裝置或閘道架構 (事件流程說明請見下文)。

上圖中的事件流程如下:

  • 您可以使用 Identity and Access Management API,為服務帳戶建立新的金鑰配對。公開金鑰會儲存在 IAM 中。不過,您必須安全地下載私密金鑰,並將其儲存在閘道裝置中,以供驗證使用。
  • 彙整裝置會從安全本機網路中的多個其他遠端裝置和感應器收集資料。遠端裝置會使用本機邊緣通訊協定 (例如 MODBUS、BACNET、OPC-UA 或其他本機通訊協定) 與閘道通訊。
  • 匯總裝置會透過 HTTPS 或 gRPC 將資料傳送至 Pub/Sub。這些 API 呼叫會使用匯總裝置上的服務帳戶私密金鑰簽署。

架構考量和選擇

由於 Pub/Sub 是無伺服器資料串流服務,因此可用於建立由事件生產者和消費者 (稱為發布者和訂閱者) 組成的雙向系統。在某些連線裝置情境中,您只需要可擴充的發布及訂閱服務,即可建立有效的資料架構。以下各節說明在 Google Cloud上實作裝置至 Pub/Sub 架構時,需要考量的因素和選擇。

攝取端點

Pub/Sub 提供多種語言的預先建構用戶端程式庫,可實作 REST 和 gRPC API。這項服務支援兩種訊息擷取通訊協定:REST (HTTP) 和 gRPC。如要讓連線裝置透過 Pub/Sub 傳送及接收資料,裝置必須能夠與其中一個端點互動。

許多軟體應用程式都內建 REST API 支援功能,因此連線至 Pub/Sub REST API 通常是最簡單的解決方案。但在某些用途中,gRPC 可能是更有效率且更快速的替代方案。由於 gRPC 使用序列化通訊協定緩衝區做為訊息酬載,而非 JSON、XML 或其他文字型格式,因此更適合連線裝置使用案例中常見的低頻寬應用程式。此外,gRPC API 連線的資料傳輸速度也比 REST 快,且支援同步雙向通訊。一項研究發現,gRPC 比 REST 快了最多七倍。因此,在許多連線裝置情境中,如果 gRPC 連接器適用於連線裝置應用程式,或可為其導入,gRPC 會是較好的選擇。

裝置驗證和憑證管理

Pub/Sub 支援多種驗證方法,可供從外部 Google Cloud存取。

如果您的架構包含外部身分識別提供者 (例如 Active Directory 或本機 Kubernetes 叢集),可以使用工作負載身分聯合管理 Pub/Sub 的存取權。這種做法可為連線裝置建立短期存取權杖。您也可以將 IAM 角色授予已連結的裝置,不必使用服務帳戶金鑰,省去管理和安全方面的負擔。

如果沒有外部身分識別提供者,服務帳戶金鑰是唯一的驗證選項。如未妥善管理服務帳戶金鑰,可能會產生安全性風險,因此建議您遵循安全最佳做法,將服務帳戶金鑰部署至連線裝置。詳情請參閱「管理服務帳戶金鑰的最佳做法」。服務帳戶也是有限的資源,任何雲端專案的使用者代管服務帳戶配額都有限。因此,這種方法只適用於需要連線的裝置數量不多的部署作業。

後端應用程式

資料擷取至 Pub/Sub 主題後,任何在 Google Cloud 上執行的應用程式,只要具備適當的憑證和存取權,就能使用這些資料。除了應用程式中的 Pub/Sub API,您不需要其他連接器。訊息可供後端基礎架構中的多個應用程式使用,以進行平行處理或發出快訊,以及用於封存儲存空間和其他分析。

用途

以下各節說明範例情境,其中裝置與 Pub/Sub 的直接連線非常適合連線裝置用途。

從地端資料記錄器大量擷取資料

裝置到 Pub/Sub 的連線最適合用於端點數量少,但傳輸大量資料的應用程式。「營運資料記錄器」就是一個很好的例子,這類地端系統會儲存大量資料,需要傳輸至Google Cloud。在此用途中,必須驗證少數端點 (通常是一到幾個連線裝置),這符合服務帳戶驗證的典型參數。這些系統通常也採用模組化架構,可讓您實作與 Google Cloud通訊所需的 Pub/Sub API 連線。

工廠的本機閘道資料匯總

在本地閘道中彙整工廠感應器資料,也是非常適合直接使用 Pub/Sub 連線的用途。在這種情況下,本機資料管理和匯總系統會部署在工廠的閘道裝置上。這類系統通常是軟體產品,可連線至各種本機感應器和機器。產品會收集資料,並經常轉換為標準化表示法,然後傳遞至雲端應用程式。

在此情境中,可以連線的裝置數量眾多。不過,這些裝置通常只會連線至本機閘道,並由該裝置上的軟體管理,因此不需要雲端管理應用程式。與 MQTT 代理程式架構不同,在本例中,閘道會主動彙整及轉換資料。

閘道連線至 Google Cloud時,會透過服務帳戶金鑰向 Pub/Sub 進行驗證。這個金鑰會將匯總及轉換後的資料傳送至雲端應用程式,以進行後續處理。連線閘道的數量通常也介於數十到數百部裝置之間,這是在服務帳戶驗證的典型範圍內。

後續步驟