什麼是 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 Kafka 和 Pulsar 的水平擴充性，以及傳統訊息傳遞中介軟體 (例如 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。

訊息生命週期

後續步驟