什麼是 Pub/Sub 和 Pub/Sub Lite?

本頁說明 Pub/Sub 的用途、企業需要 Pub/Sub 的原因,以及相較於類似技術,Pub/Sub 的優勢。此外,也請瞭解 Pub/Sub 的核心概念,包括主題、發布端和訂閱端等術語。

Pub/Sub 是可擴充的非同步訊息服務,會分離產生訊息的服務與處理訊息的服務。

Pub/Sub 可讓服務以非同步方式通訊,延遲時間約為 100 毫秒。

Pub/Sub 用於串流分析和資料整合管道,可擷取及發布資料。無論是做為服務整合的訊息導向中介軟體,還是做為平行處理工作的佇列,都同樣有效。

Pub/Sub 可讓您建立事件生產者和消費者系統,也就是發布者訂閱者。發布商會透過廣播事件,與訂閱者進行非同步通訊,而不是透過同步遠端程序呼叫 (RPC)。

發布者會將事件傳送至 Pub/Sub 服務,不必理會這些事件的處理方式或時間。接著,Pub/Sub 會將事件傳送至所有會對事件做出反應的服務。在透過 RPC 通訊的系統中,發布者必須等待訂閱者接收資料。不過,Pub/Sub 的非同步整合可提高整體系統的彈性和穩定性。

如要開始使用 Pub/Sub,請參閱使用 Google Cloud 控制台的快速入門導覽課程。如需更詳盡的介紹,請參閱「建立 Pub/Sub 訊息傳遞系統」。

常見用途

  • 擷取使用者互動和伺服器事件。如要使用來自使用者應用程式的使用者互動事件,或來自系統的伺服器事件,您可以將這些事件轉送至 Pub/Sub。接著,您可以使用串流處理工具 (例如 Dataflow),將事件傳送至資料庫。這類資料庫的例子包括 BigQuery、Bigtable 和 Cloud Storage。Pub/Sub 可讓你同時從多個用戶端收集事件。

  • 即時事件發布。事件 (原始或已處理) 可供團隊和機構中的多個應用程式即時處理。Pub/Sub 支援「企業事件匯流排」和事件導向應用程式設計模式。Pub/Sub 可與許多 Google 系統整合,將事件匯出至 Pub/Sub。

  • 在資料庫之間複製資料。Pub/Sub 通常用於發布資料庫中的變更事件。您可以使用這些事件,在 BigQuery 和其他資料儲存系統中建構資料庫狀態和狀態記錄的檢視畫面。

  • 平行處理和工作流程。您可以透過 Pub/Sub 訊息連結至 Cloud Run 函式,在多個工作人員之間有效分配許多工作。這類工作包括壓縮文字檔、傳送電子郵件通知、評估 AI 模型,以及重新格式化圖片。

  • 企業事件匯流排。您可以建立企業範圍的即時資料共用匯流排,在整個機構中發布業務事件、資料庫更新和分析事件。

  • 從應用程式、服務或物聯網裝置串流資料。舉例來說,SaaS 應用程式可以發布事件的即時動態消息。或者,住宅感應器可以透過 Dataflow 管道將資料串流至 Pub/Sub,供其他 Google Cloud 產品使用。

  • 重新整理分散式快取。舉例來說,應用程式可以發布失效事件,更新已變更物件的 ID。

  • 負載平衡可確保可靠性。舉例來說,服務的執行個體可能會部署在多個區域的 Compute Engine 上,但訂閱常見主題。如果任何區域的服務發生故障,其他區域可以自動接管負載。

Pub/Sub 服務類型

Pub/Sub 包含兩項服務:

  • Pub/Sub 服務。這項訊息服務是大多數使用者和應用程式的預設選擇。提供最高可靠性、最廣泛的整合功能,以及自動容量管理。Pub/Sub 保證會將所有資料同步複製到至少兩個區域,並盡可能複製到第三個額外區域。

  • Pub/Sub Lite 服務。這項服務與訊息服務類似,但建構成本較低。與 Pub/Sub 相比,可靠性較低。提供可用區或區域主題儲存空間。可用區 Lite 主題只會儲存在一個可用區。區域 Lite 主題會以非同步方式將資料複製到第二個區域。此外,您必須預先佈建及管理儲存空間和總處理量容量。只有在應用程式需要以低成本運作,且可接受額外的營運工作和較低的可靠性時,才考慮使用 Pub/Sub Lite。

如要進一步瞭解 Pub/Sub 與 Pub/Sub Lite 之間的差異,請參閱選擇 Pub/Sub 或 Pub/Sub Lite 一文。

比較 Pub/Sub 與其他訊息傳遞技術

Pub/Sub 結合了 Apache KafkaPulsar 的水平擴充性,以及傳統訊息傳遞中介軟體 (例如 Apache ActiveMQ 和 RabbitMQ) 的功能。例如無法傳送郵件的佇列和篩選功能。

Pub/Sub 從訊息中介軟體採用的另一項功能是訊息層級的平行處理,而非以分區為基礎的訊息傳遞。Pub/Sub 會將個別訊息「租給」訂閱端用戶端,然後追蹤特定訊息是否已成功處理。

相較之下,其他可水平擴充的訊息系統會使用分區進行水平擴充。這會強制訂閱者依序處理每個分區中的訊息,並將並行用戶端數量限制為分區數量。訊息處理作業可盡量提高訂閱者應用程式的平行處理能力,並確保發布者/訂閱者獨立運作。

比較服務對服務和服務對用戶端的通訊

Pub/Sub 適用於服務對服務通訊,而非與使用者或物聯網用戶端通訊。其他產品更適合處理其他模式:

您可以結合使用這些服務,建構用戶端 -> 服務 -> 資料庫模式。舉例來說,請參閱「透過 WebSocket 串流 Pub/Sub 訊息」教學課程。

整合

Pub/Sub 與其他 Google Cloud 產品整合,可建立功能齊全的訊息傳遞系統:

  • 串流處理和資料整合。Dataflow 支援,包括 Dataflow 範本SQL,可處理資料並將資料整合到 BigQuery 和 Cloud Storage 上的資料湖。您可以在Google Cloud 控制台的 Pub/Sub 和 Dataflow 使用者介面中,找到將資料從 Pub/Sub 移至 Cloud Storage、BigQuery 和其他產品的 Dataflow 範本。此外,您也可以與 Apache Spark 整合,特別是透過 Dataproc 管理時。如要以視覺化方式組合在 Spark + Dataproc 上執行的整合和處理管道,可以使用 Data Fusion
  • 監控、快訊與記錄功能。Monitoring 和 Logging 產品支援此功能。
  • 驗證和 IAM。Pub/Sub 採用其他 Google Cloud 產品使用的標準 OAuth 驗證,並支援精細的 IAM,可針對個別資源啟用存取權控管。
  • API。Pub/Sub 使用標準 gRPC 和 REST 服務 API 技術,以及多種語言的用戶端程式庫
  • 觸發條件、通知和 Webhook。Pub/Sub 會以 HTTP POST 要求的形式,將訊息推送至 Webhook。您可以使用 Cloud Functions 或其他無伺服器產品,實作工作流程自動化。
  • 自動化調度管理。Pub/Sub 可以宣告方式整合至多步驟無伺服器工作流程。大數據和分析協調作業通常使用 Cloud Composer 完成,該服務支援 Pub/Sub 觸發程序。您也可以整合 Pub/Sub 與 Application Integration (搶先版),這是整合平台即服務 (iPaaS) 解決方案。Application Integration 提供 Pub/Sub 觸發條件,可觸發或啟動整合作業。
  • Integration Connectors(預覽版) 這些連接器可讓您連線至各種資料來源。 透過連接器, Google Cloud 服務和第三方商務應用程式都會透過透明的標準介面,向整合項目公開。如果是 Pub/Sub,您可以建立 Pub/Sub 連線,用於整合作業。

核心概念

  • 主題。發布者傳送訊息的目標具名資源。
  • 訂閱。表示從單一特定主題傳送至訂閱應用程式之訊息串流的具名資源。如要進一步瞭解訂閱項目與訊息傳送語意,請參閱訂閱者指南
  • Message. 發布者傳送至主題並最終傳送至訂閱者之資料與 (選用) 屬性的組合。
  • 訊息屬性。發布者可針對訊息定義的鍵/值組合。例如,可將 iana.org/language_tag 鍵與 en 值新增至訊息,以將其標示為可由英文訂閱者讀取。
  • 發布商。應用程式可建立訊息,並將訊息傳送至一或多個主題。
  • 訂閱者。訂閱一或多個主題的應用程式,可接收主題傳送的訊息。
  • 確認 (或「ack」)。訂閱者成功接收訊息後,傳送至 Pub/Sub 的信號。已確認的訊息會從訂閱訊息佇列中移除。
  • 推送及提取。兩種訊息傳送方式。訂閱者會收到由 Pub/Sub「推送」至訂閱者選定端點的訊息,或是由訂閱者由服務「提取」訊息。

發布者與訂閱者之間的關係可以是一對多 (擴散傳遞功能)、多對一 (集中傳遞功能) 以及多對多,如下圖所示:

發佈者訂閱者關係

下圖說明訊息如何從發布者傳遞至訂閱者。如果是推送傳送,系統會在推送要求的回應中隱含確認,如果是提取傳送,則需要另外的 RPC。

訊息生命週期

後續步驟