初探 Google Cloud Pub/Sub

Google Cloud Pub/Sub 基本介紹

ta-ching chen

1 minute read

 文章目錄

介紹 

Cloud Pub/Sub 為 Google 推出的 message service,主要用途是讓每個獨立的應用(Application)間能透過 Publish-Subscribe 的模式來進行訊息交換與溝通,一般而言利用 message service 當作中介層(Middleware)來傳遞訊息,有著以下幾項優/缺點:

優點 

  • 透過非同步的訊息傳遞,降低 Publisher、Subscriber 間的耦合度。意即彼此間無需知道對方位置,亦不會任意一方出現問題而導致連鎖反應。
  • 當作訊息緩衝區(Buffer),避免後端消化速度不夠快而無法接收新進的訊息請求。
  • 根據不同用途來訂閱/散佈訊息。

缺點 

  • 由於是非同步處理,因此訊息的即時性/順序性/重覆性無法受到保證。
  • 需要熟悉 message service 服務的遞送流程,避免異常或訊息無法正確傳送。

就先前經驗來說,一個高可用/彈性的 message service,通常會考慮以下幾點:

  • 訊息傳遞效率
  • 可擴展性(Scalability)、可靠性(Reliability)、可用性(Availability)

從 Google 官方的說明可以看到

Google Cloud Pub/Sub brings the scalability, flexibility, and reliability of enterprise message-oriented middleware to the cloud.

而且為方便開發者瞭解及使用,Cloud Pub/Sub 將 AMQP(Advanced Message Queuing Protocol) 中 Message Broker、Exchange、Queue 等不會直接被開發者接觸的部分隱藏起來大幅降低進入門檻,開發者僅需要瞭解 Topic、Publisher、Subscriber、Push/Pull Subscription 即可撰寫相關程式。因此儘管我們可以利用 NSQRabbitMQ 等開源軟體架設專屬的 message service,但在人力或相關經驗不足的情況下,會建議使用第三方服務讓團隊能專心在更重要的事情(開發)上。

Pub/Sub 流程 

Pub/Sub Flow

上圖為 Google 官方 介紹 Pub/Sub 的流程,主要流程如下:

  1. Publisher 首先在 Cloud Pub/Sub 建立傳訊息用的 Topic,然後開始向該 Topic 傳送訊息
  2. 當訊息被接收前或尚未收到 Acknowledge(Ack) 時,會被保存起來並等待在次傳送出去
  3. Subscriber 向服務註冊訂閱(Subscription)後,所有發送到 Topic 的訊息會轉發給該 Topic 下的所有 Subscriber
  4. Subscriber 收到訊息後會回傳 Ack 訊息給 Cloud Pub/Sub,以確認訊息已經收到
  5. 當 Ack 被 Cloud Pub/Sub 收到後,將該訊息自 Message Storage 刪除

使用 Cloud Pub/Sub 時需要小心以下幾點:

  • 若 Ack 因為意外或超時而尚未傳到 Cloud Pub/Sub 時該訊息會至多保留 7 天(請參考 Retry Policy),因此程式撰寫時需考慮到訊息延遲遞送的問題,比方說加上時間戳來過濾超時的訊息。
  • 為求傳遞效能,服務不保證訊息的順序性
  • 訊息可能會發生重覆(duplicate)的情況,面對訊息重覆有兩種處理方式
    • 若該請求不能重覆執行(比方說銀行扣款),就需要針對訊息夾帶的 uuid 進行重覆性確認
    • 若該請求可以重覆執行(比方說查看銀行餘額),程式便能忽略重覆性確認的流程,除非重覆次數太多導致系統性能受到影響
  • 訊息在尚未接收完畢前切勿刪除該 Topic ,避免 Subscriber 無法接收其他存留的訊息
  • 建議 Subscriber 在起來時,產生其專用的 uuid 用來向服務註冊訂閱,避免名稱衝突

接下來就來看看如何使用 Golang 來實作 Publisher 以及 Subscriber 吧

參考連結 

相關文章

comments powered by Disqus