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

MQTT 是 OASIS 標準通訊協定，適用於連線裝置應用程式，可透過發布及訂閱代理程式架構提供雙向訊息傳輸功能。MQTT 通訊協定輕巧，可減少網路負擔，且 MQTT 用戶端非常小，可盡量減少受限裝置的資源用量。如果機構要支援Google Cloud 上的連線裝置應用程式，其中一個解決方案是在 Compute Engine 或 GKE 上執行獨立的 MQTT 代理程式。如要在貴機構部署 MQTT 代理程式，您需要做出幾項重要決策，這些決策會影響整體架構，尤其是負載平衡和部署環境。本文說明在 Google Cloud上部署 MQTT 代理程式 (MQTT 部署作業的核心應用程式) 的架構。本文也會說明部署這個代理程式時需要做出的決策，以及這些決策對架構的影響。

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

下圖顯示在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 通訊協定在初始 Connect 封包中支援基本的使用者名稱和密碼驗證，而這些欄位也經常由代理程式實作使用，以支援其他形式的驗證，例如 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 代理程式叢集，在雲端和邊緣環境之間進行通訊，不必將內部部署裝置和系統暴露於公開網際網路。

後續步驟