在 Google Cloud 上使用獨立的 MQTT 代理程式架構

Last reviewed 2024-08-09 UTC

MQTT 是一種 OASIS 標準通訊協定，適用於連網裝置應用程式，可透過發布/訂閱代理程式架構提供雙向訊息傳遞功能。MQTT 通訊協定體積輕巧，可減少網路額外負擔，而 MQTT 用戶端體積非常小，可盡量減少在受限裝置上使用資源。Google Cloud 如果機構希望支援連結裝置應用程式，可以在 Compute Engine 或 GKE 上執行獨立 MQTT 中介軟體，如要在貴機構中部署 MQTT 中介軟體，您需要做出幾項影響整體架構的重要決策，特別是負載平衡和部署環境。本文說明在 Google Cloud上部署 MQTT 中介服務 (MQTT 部署作業中的核心應用程式) 的架構。並說明部署此媒介服務時需要做出的決策，以及這些決策對架構的影響。

本文是一系列文件的一部分，這些文件提供 Google Cloud的物聯網架構相關資訊。本系列的其他文件包括：

下圖顯示在Google Cloud上執行的 MQTT 代理程式架構。

MQTT 代理程式架構圖 (詳見下文)。

上圖中的架構組成方式如下：

  • MQTT 代理程式會部署為叢集，其中包含三個與 Cloud Load Balancing 服務連線的執行個體。如要使用雲端負載平衡器，您可以選擇其中一個負載平衡產品，詳情請參閱本文後續內容。
  • 代理程式叢集包含裝置憑證存放區，以及裝置驗證和授權服務。叢集會透過 Dataflow 或 Pub/Sub 連線至後端工作負載。
  • 在用戶端端，邊緣閘道會透過 MQTT over TLS，在邊緣裝置和 MQTT 中介軟體叢集之間提供雙向通訊。

一般來說，我們建議您在叢集中部署此架構的 MQTT 中介軟體應用程式，以便擴充。特定仲介器實作會處理叢集功能、叢集縮放管理、資料同步處理和網路分區處理等因素。

架構考量和選擇

以下各節說明您必須為獨立 MQTT 中介服務架構做出的不同架構選擇和考量，以及這些選擇對架構的影響。

已連結的裝置

連上網際網路的邊緣裝置會將遙測事件和其他資訊發布至 MQTT 中介軟體。如要實作本文所述的獨立 MQTT 中介服務架構，裝置必須具備 MQTT 用戶端、用於 TLS 驗證的伺服器憑證公開金鑰，以及用於驗證 MQTT 中介服務的憑證。

此外，邊緣裝置通常會連結至本機感應器、內部資料系統，以及其他沒有網際網路存取或 IP 連線的裝置。舉例來說，邊緣裝置可做為閘道，讓其他本機受限裝置透過 BLE、有線連線或其他近場通訊協定連線至閘道。本指南不涵蓋連網裝置架構的詳細規格。

負載平衡

在這個架構中，會在公用網路和 MQTT 中介軟體叢集之間設定外部負載平衡服務。這項服務提供多項重要網路功能，包括在後端節點之間分配傳入連線、會話加密和驗證。

Google Cloud 支援多種負載平衡器類型。如要為架構選擇最佳負載平衡器，請考量下列事項：

如要進一步瞭解 Cloud Load Balancing 支援的負載平衡器類型，請參閱「負載平衡器 Google Cloud 摘要」。

負載平衡策略

任何負載平衡服務都會根據其中一個演算法或平衡模式，將邊緣裝置的連線分配至叢集中的節點。對於 MQTT，工作階段相依性負載平衡策略比隨機負載平衡更有效。由於 MQTT 用戶端-伺服器連線是持續性的雙向工作階段，因此會在停止連線的中介節點上維持狀態。在叢集設定中，如果用戶端連線後又重新連線至其他節點，工作階段狀態就會移至新節點，進而增加叢集的負載。使用工作階段相依性負載平衡功能，就能大幅避免這個問題。如果用戶端經常變更 IP 位址，連線可能會中斷，但在大多數情況下，MQTT 會使用會話相依性。所有 Cloud Load Balancing 產品皆支援工作階段相依性。

裝置驗證和憑證管理

MQTT 中介軟體應用程式會單獨處理裝置驗證和存取權控管功能，不受 Google Cloud影響。仲介應用程式也會提供自己的憑證儲存庫和管理介面。MQTT 通訊協定支援初始連線封包中的基本使用者名稱和密碼驗證，這些欄位也經常用於仲介器實作，以支援其他形式的驗證，例如 X.509 憑證或 JWT 驗證。MQTT 5.0 也新增了對使用挑戰和回應式驗證的進階驗證方法支援。使用的驗證方法取決於所選的 MQTT 中介軟體應用程式和連結裝置用途。

無論代理程式使用的驗證方法為何，都會維護裝置憑證儲存庫。這個儲存庫可以是本機 SQL 資料庫或平面檔案。部分仲介也支援使用 Cloud SQL 等代管資料庫服務。您需要使用其他服務來管理裝置憑證儲存庫，並處理與其他驗證服務 (例如 IAM) 的整合作業。這項服務的開發作業不在本指南的討論範圍內。

如要進一步瞭解驗證和憑證管理，請參閱「在 Google Cloud上執行 IoT 後端的最佳做法」。

後端工作負載

任何連線裝置用途都包含一或多個後端應用程式，這些應用程式會使用從連線裝置擷取的資料。有時，這些應用程式也需要將指令和設定更新傳送至裝置。在本文件的獨立 MQTT 代理程式架構中，傳入資料和傳出指令都會透過 MQTT 代理程式進行路由。在仲介的主題階層中，有不同的主題可用於區分資料和指令。

您可以透過多種方式，在仲介和後端應用程式之間傳送資料和指令。如果應用程式本身支援 MQTT，或是可修改為支援 MQTT，則應用程式可做為用戶端直接訂閱仲介。透過這種做法，您可以直接使用 MQTT Pub/Sub 雙向訊息傳遞功能，透過應用程式接收資料，並傳送指令至已連結的裝置。

如果您的應用程式不支援 MQTT，還有其他幾個選項。在本文件所述的架構中，Apache Beam 提供 MQTT 驅動程式，可讓您與 Dataflow 和其他 Beam 部署進行雙向整合。許多仲介也提供外掛程式功能，可支援與 Google Pub/Sub 等服務整合。這些通常是資料整合的一方向整合，但部分仲介支援雙向整合。

用途

MQTT 中介服務架構特別適合下列各節所述的裝置用途。

從異質裝置擷取標準化資料

如果您想從大量異質裝置中收集及分析資料，MQTT 中介軟體通常是個不錯的解決方案。由於 MQTT 是廣泛採用且實作的標準，許多邊緣裝置都內建支援，而輕量 MQTT 用戶端可在未支援的裝置上新增 MQTT 支援。發布和訂閱架構也是 MQTT 標準的一部分，因此支援 MQTT 的裝置無須額外實作工作，即可充分利用這項架構。相較之下，連線至 Pub/Sub 的裝置必須實作 Pub/Sub API，或使用 Pub/Sub SDK。因此，在Google Cloud 上執行符合標準的 MQTT 中介軟體，可提供簡單的解決方案，從各種裝置收集資料。

如果連結的裝置不是由您的應用程式控制，而是由第三方控制，您可能無法存取裝置系統軟體，且裝置本身的管理責任將由對方負責。在這種情況下，建議您執行 MQTT 中介軟體，並向第三方提供驗證憑證，以設定裝置與雲端的通訊管道。

雙向通訊，用於多方應用程式整合

MQTT 的雙向訊息傳送功能非常適合多方行動應用程式用途，例如隨選外送服務或大型網頁即時通訊應用程式。MQTT 的通訊協定額外負擔較低，而 MQTT 用戶端的資源需求也較低。MQTT 也提供發布及訂閱路由、多個服務品質 (QoS) 等級、內建訊息保留功能，以及廣泛的通訊協定支援。MQTT 中介軟體可做為可擴充的訊息傳遞平台核心元件，用於隨選服務應用程式和類似用途。

邊緣到雲端整合式訊息傳遞

由於 MQTT 提供標準化和低開銷，因此也是整合內部部署和雲端式訊息應用程式的理想解決方案。舉例來說，工廠作業人員可以在內部部署多個 MQTT 仲介，以便連線至防火牆後方的感應器、機器、閘道和其他裝置。本機 MQTT 中介服務可處理所有雙向指令和控制，以及內部基礎架構的遙測訊息。本機代理程式也可以透過雙向訂閱連線至雲端中的平行 MQTT 代理程式叢集，讓雲端和邊緣環境之間進行通訊，而不會將內部裝置和系統暴露於公開網際網路。

後續步驟