今天我們來建立處理緩衝層的 Message Service 服務 Pub/Sub，它是全託管的SaaS服務，基本上只要建立好 Topic 跟 Subscription 就可以了，不需要管理甚麼 CPU Memory 這些 Infra 的相關資訊。

建立 Topic

首先我們建立一個 Topic

給我們的 Topic 一個名稱，其他配置選擇預設值就可以。

# 建立 Subscription
預設就會建立一個 Sub，但最好確認一下預設的 Sub 設置是否符合需求

調整 Sub

進入到 Sub 的設定確認一下設置

傳送類型

預設是 Pull 這個選項會根據架構裡面的 Process Service 要怎麼處理 Message 來決定，我們這裡可以先保留預設值使用 Pull

訊息保留時間

基本上越長能夠確保訊息丟失的機率越低，但相會會多花一些成本，不過 Pub/Sub 的費用並不高，這裡我們就用最久 7 天。根據架構 Process Service 處理完的資料就已經持久化了，因此我們不需要保留已確認的訊息。

確認期限

這個時間會根據 Process Service 將資料持久化所需要的時間而定，目前還不確定需要多久，我們就先使用預設的 10 秒

訂閱項目篩選器

我們的 Message 沒有甚麼特別的 Filter，全部都要送到 Process Service 去，而且此選項在建立 Sub 時才能設定，後續編輯無法作變更

僅傳送一次 & 訊息排序

此二選項開啟主要會讓 Pub/Sub 服務比較像一個 Queue 服務，確保順序性及正確性，但相對會增加 Message 傳遞的延遲，我們把資料正確性的檢查放在 Sales Service 裡面， Process Service 也可以在資料持久化的過程檢查是否有重複的 Message 出現，此二選項目前先不使用。

無效信件

基本上就是將一直處理失敗的 Message 送到另外一個 Topic ，我們可以在 Process Service 做此類Message 的處理，這裡選用。

重試政策

除非你的 Message 在短時間內重試會造成問題，大部分的情況下都選擇立即重試。

測試

確認完我們的 Topic 跟 Sub 之後一樣的我們就可以來測試一下 Message 的傳遞，我們可以直接使用 GCP Console 來做測試。

發布 Message

在 Topic 的頁面可以找到發送 Message 的地方

我們發送一段 “Test” 的內文

下方選擇我們先前建立的 Sub，按下”提取”

可以看到我們先前送出的 Test Message 已經順利被接收到

勾選 “啟用確認訊息”，可以回復 Pub/Sub 訊息已確認，將訊息清除。

這樣就完成了 Pub/Sub 的資源建立，也確定訊息的傳送接收都沒問題，後續可能會根據 Process Service 的處理機制再來做調整。