有些機構可能會從邊緣裝置直接連線至 Pub/Sub 中受益，而非實作特定架構來將裝置連線至數據分析應用程式。如果機構內有少數已連結的裝置，這些裝置會從本機或內部網路中的大量裝置和感應器匯總資料，則建議採用這種做法。如果貴機構的連線裝置位於更安全的環境 (例如工廠)，也建議採用這種做法。本文件概略說明使用這種方法將裝置連線至 Google Cloud 產品時，需要考量的高階架構。
本文是一系列文件的一部分，這些文件提供 Google Cloud的物聯網架構相關資訊。本系列的其他文件包括：
- 連結裝置架構 Google Cloud 總覽
- 在 Google Cloud上使用獨立的 MQTT 代理程式架構
- IoT 平台產品架構 Google Cloud
- 在 Google Cloud上執行 IoT 後端的最佳做法
- 在 Pub/Sub 架構中，裝置會將資料傳送至 Google Cloud (本文件)
- 自動佈建及設定邊緣和裸機系統與伺服器的最佳做法
架構
下圖顯示直接連線至 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 支援同時進行雙向通訊。一項研究發現，gRPC 的速度比 REST 快上七倍。因此，如果有 gRPC 連接器可用，或可為連線裝置應用程式實作 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。這個鍵會將匯總及轉換後的資料傳送至雲端應用程式，以利後續處理。連線閘道的數量通常介於數十到數百個裝置之間，這在服務帳戶驗證的一般範圍內。
後續步驟
- 瞭解管理服務帳戶金鑰的最佳做法。
- 閱讀外部工作負載身分聯盟總覽。
- 進一步瞭解 Pub/Sub
- 探索Google Cloud的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。