介紹 

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 即可撰寫相關程式。因此儘管我們可以利用 NSQ、RabbitMQ 等開源軟體架設專屬的 message service，但在人力或相關經驗不足的情況下，會建議使用第三方服務讓團隊能專心在更重要的事情(開發)上。

Pub/Sub 流程 

上圖為 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 吧

參考連結 

• https://cloud.google.com/pubsub/docs/

相關文章

• 實作 Google Cloud Pub/Sub Push Subscription
• 實作 Google Cloud Pub/Sub Pull Subscription
• 實作 Google Cloud Pub/Sub Publisher
• 在 Kubernetes 內取得使用者 IP - HTTP Loadbalancer
• 從 Google Kubernetes Engine 移除節點