哈囉大家好，我是古古

到上一篇文章為止，我們已經了解了 Google Cloud 中的 API 管理服務，那麼接著這篇文章，就會進入到第五部分，也就是介紹 Google Cloud 中的 Message Queue 服務：Pub/Sub

什麼是 Message Queue？

在開始介紹 Google Cloud 所提供的 Message Queue 服務之前，先稍微介紹一下「Message Queue」是個什麼樣的概念

Message Queue 的目的，是「透過新增一個 queue，達到 非同步傳遞消息 的目的」，重點在這個「非同步」

舉例來說的話，在以前沒有郵差的時候，你想要寄東西給別人，你就只能親自跑到你朋友家，見到你朋友本人，然後親手把包裹交給你朋友，你才算是完成這一整個的寄送流程

但是有了郵差之後，你想要寄包裹，就只要把包裹丟給郵差，你就可以拍拍屁股回家了，剩下郵差是怎麼樣冒著大風大雨趕著把包裹送到你朋友家的過程，你都不需要參與

這中間的「郵差」，就是 Message Queue 的概念，也就是透過中間人郵差，就可以「達到 非同步傳遞消息 的目的」

Message Queue 中的角色

了解了 Message Queue 的概念之後，在 Message Queue 裡面，通常會有三個角色：

1. Producer（生產者）
2. Queue（就是資料結構中的 queue，或是中文翻譯成隊列 or 佇列）
3. Consumer（消費者）

而在這套系統裡面，Producer 就是你（想要發包裹的生產者），Queue 就是郵差（中間人），Consumer 就是你朋友（想要收包裹的消費者），而你想要發送的這個包裹，就稱為是 message

常見的 Message Queue

常見的 Message Queue 有

• RabbitMQ
• ActiveMQ
• Kafka（狹義上雖然不算 Message Queue，不過這邊仍舊先把他放進來）

Google Cloud 中的 Message Queue 服務：Pub/Sub

了解了 Message Queue 的概念之後，接著可以回頭來介紹 Google Cloud 中的 Message Queue 服務了

在 Google Cloud 中，只有提供一個 Message Queue 的服務，就叫做「Pub/Sub」

Pub/Sub 作為 Google Cloud 中唯一的 Message Queue 的服務，支援非同步的 message 傳遞，所以簡單的說的話，其實 Pub/Sub 就只是提供了一個「雲端版的 Message Queue」服務給你用而已，並沒有新增什麼太厲害的特性在裡面

順便一提，Pub/Sub 這個名字看起來有點怪，但他其實就只是 Publisher/Subscriber 的縮寫而已XD（這名字也取的太簡單暴力了吧）

Pub/Sub 的特性

Pub/Sub 作為雲端版的 Message Queue 的服務，也是有 Message Queue 中的三個角色的概念

不過在 Pub/Sub 服務裡面，這三個角色分別叫做：

1. Publisher（即是 Producer）
2. Topic（即是 Queue）
3. Subscriber（即是 Consumer）

因此以下就會以 Publisher、Topic、Subscriber 這三個名詞，來介紹 Pub/Sub 的相關特性

1. 所有 message 都得經過 Topic，不能 Publisher 和 Subscriber 對傳

Pub/Sub 服務的第一個特性，就是在 Pub/Sub 裡面的所有 message，都一定得經手過 Topic，而不能夠說 Publisher 和 Subscriber 直接對傳

所以換句話說的話，假設 Publisher 想要發送 message，那麼 Publisher 只能夠將 message 傳到 Topic 上面，交由 Topic 保管

而對於 Subscriber 來說，他也只能夠去註冊 Topic 聽取 message，不能夠直接去註冊 Publisher

所以簡單的說的話，就是所有 message 都得經過 Topic，不能讓 Publisher 和 Subscriber 之間有任何直接交流就對了

2. 一個 Topic 可以有 0-N 個 Publisher、也可以有 0-N 個 Subscriber

在 Pub/Sub 服務裡面，每一個 Topic 都可以有 0-N 個 Publisher，也就是說可以有很多人發送包裹到同一個郵差身上，或是沒有任何人想發送包裹到這個郵差身上

而每一個 Topic 也可以有 0-N 個 Subscriber，也就是可以有很多人來這個郵差這領取包裹，或是沒有任何人想從郵差身上獲取包裹

3. 確保 message「至少」會到達一次

這句話有一點點保留空間，官方影片是說 Pub/Sub 會確保 message 一定會到達「至少一次」(ensure at-least-one delivery)

不過從字面上看起來，不排除同一個 message 可能會發生到達兩次以上的情況

4. 可以透過 API 發送 message

Pub/Sub 有提供公開的 API 給我們使用，因此我們就可以透過程式，直接去 call API 來發送 message

5. message 皆為加密處理

只要是在 Publisher、Topic、Subscriber 中的 message，Google Cloud 都會為其進行加密，確保資料是安全的

6. 支援兩種傳遞 message 的方式

在 Pub/Sub 中，當 Publisher 想要透過 Topic 傳遞 message 給 Subscriber 時，有兩種模式可以選

模式一：Push Subscription

上圖左呈現的是 Push Subscription 模式的運作邏輯，即是 Pub/Sub 直接把 message 推給 Subscriber

這個模式的優點是 message 可以即時的傳遞到 Subscriber 身上

但是缺點是如果 Subscriber 的 server 不夠力，承受不住短時間高流量的 message 轟炸，那麼 Subscriber 的 server 就很容易被流量沖垮，直接毀滅

模式二：Pull Subscription

上圖右呈現的，則是 Pull Subscription 模式的運作邏輯

在 Pull Subscription 中，當有新 message 出現時，Pub/Sub 不會直接像上一種模式一樣，直接傳給 Subscriber，相反的，Pub/Sub 反而是會先將該 message 給暫存起來

而等到有一天 Subscriber 主動發一個請求來說他想收了的時候，Pub/Sub 才會把暫存起來的這些 message 傳給 Subscriber

並且 Subscriber 最後要再發個 ack 給 Pub/Sub 表示他收成功了，整個流程才算真的結束

這個模式的缺點是 message 沒那麼即時，不過優點是可以由 Subscriber 自己決定什麼時候想收 message，而不用擔心被突如其來的 message 流量轟炸一波

總結

這篇文章介紹了 Google Cloud 中唯一的 Message Queue 服務：Pub/Sub，也介紹了 Pub/Sub 的特性，以及他所支援的兩種傳遞 message 的模式

那麼到這邊為止，我們就已經介紹完了 Google Cloud 中常見的後端開發服務了，我們一路以來，有介紹了運算服務、數據儲存服務、API 管理服務，再加上這篇文章的 Message Queue 服務，透過這些服務，大家基本上就可以架設出一個企業級的後端系統了

不過對於維護這樣子的一個企業級的後端系統來說，「權限管理」是非常重要的，有良好的權限管理，才不會發生新手工程師一個 sudo rm -rf 就刪除所有數據的慘案出現

因此從下一篇文章開始，我們就會進入到第六章節，介紹要如何運用 Google Cloud 中的權限管理服務，來管理我們所使用到的所有資源 ，那我們就下一篇文章見啦！

相關連結

• 同場加映：Spring Boot 零基礎入門，2023 鐵人賽同步連載！
• 歡迎追蹤 FB 粉絲頁：古古說