哈囉大家好，我是古古
到上一篇文章為止，我們已經了解了 Google Cloud 中的 API 管理服務，那麼接著這篇文章，就會進入到第五部分，也就是介紹 Google Cloud 中的 Message Queue 服務：Pub/Sub
在開始介紹 Google Cloud 所提供的 Message Queue 服務之前，先稍微介紹一下「Message Queue」是個什麼樣的概念
Message Queue 的目的，是「透過新增一個 queue，達到 非同步傳遞消息 的目的」，重點在這個「非同步」
舉例來說的話，在以前沒有郵差的時候，你想要寄東西給別人，你就只能親自跑到你朋友家，見到你朋友本人，然後親手把包裹交給你朋友，你才算是完成這一整個的寄送流程
但是有了郵差之後，你想要寄包裹，就只要把包裹丟給郵差，你就可以拍拍屁股回家了，剩下郵差是怎麼樣冒著大風大雨趕著把包裹送到你朋友家的過程，你都不需要參與
這中間的「郵差」，就是 Message Queue 的概念，也就是透過中間人郵差，就可以「達到 非同步傳遞消息 的目的」
了解了 Message Queue 的概念之後，在 Message Queue 裡面，通常會有三個角色：
而在這套系統裡面，Producer 就是你（想要發包裹的生產者），Queue 就是郵差（中間人），Consumer 就是你朋友（想要收包裹的消費者），而你想要發送的這個包裹，就稱為是 message
常見的 Message Queue 有
了解了 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 作為雲端版的 Message Queue 的服務，也是有 Message Queue 中的三個角色的概念
不過在 Pub/Sub 服務裡面，這三個角色分別叫做：
因此以下就會以 Publisher、Topic、Subscriber 這三個名詞，來介紹 Pub/Sub 的相關特性
Pub/Sub 服務的第一個特性，就是在 Pub/Sub 裡面的所有 message，都一定得經手過 Topic，而不能夠說 Publisher 和 Subscriber 直接對傳
所以換句話說的話，假設 Publisher 想要發送 message，那麼 Publisher 只能夠將 message 傳到 Topic 上面，交由 Topic 保管
而對於 Subscriber 來說，他也只能夠去註冊 Topic 聽取 message，不能夠直接去註冊 Publisher
所以簡單的說的話，就是所有 message 都得經過 Topic，不能讓 Publisher 和 Subscriber 之間有任何直接交流就對了
在 Pub/Sub 服務裡面，每一個 Topic 都可以有 0-N 個 Publisher，也就是說可以有很多人發送包裹到同一個郵差身上，或是沒有任何人想發送包裹到這個郵差身上
而每一個 Topic 也可以有 0-N 個 Subscriber，也就是可以有很多人來這個郵差這領取包裹，或是沒有任何人想從郵差身上獲取包裹
這句話有一點點保留空間，官方影片是說 Pub/Sub 會確保 message 一定會到達「至少一次」(ensure at-least-one delivery)
不過從字面上看起來，不排除同一個 message 可能會發生到達兩次以上的情況
Pub/Sub 有提供公開的 API 給我們使用，因此我們就可以透過程式，直接去 call API 來發送 message
只要是在 Publisher、Topic、Subscriber 中的 message，Google Cloud 都會為其進行加密，確保資料是安全的
在 Pub/Sub 中，當 Publisher 想要透過 Topic 傳遞 message 給 Subscriber 時，有兩種模式可以選
上圖左呈現的是 Push Subscription 模式的運作邏輯，即是 Pub/Sub 直接把 message 推給 Subscriber
這個模式的優點是 message 可以即時的傳遞到 Subscriber 身上
但是缺點是如果 Subscriber 的 server 不夠力，承受不住短時間高流量的 message 轟炸，那麼 Subscriber 的 server 就很容易被流量沖垮，直接毀滅
上圖右呈現的，則是 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 中的權限管理服務，來管理我們所使用到的所有資源 ，那我們就下一篇文章見啦！
iThome鐵人賽
看影片追技術