學習後端基礎 3 - 後端通訊設計模式

上一回介紹了幾種通訊模式，這一回將接續我們上次有提到但是沒有介紹完的。

Server-sent events: 同一條管子，慢慢把消息送來

在上一回有提到 push，而 Server-sent events 就是 push 的一種作法。您可以把它想像成：使用者打開一個網頁之後，和伺服器之間建立了一條管道。伺服器不會一次就把大量的資料全部送給你，而是他只要有新的東西要給你，就會往這條管子慢慢丟。

就像你在聽廣播，所有的消息不會在一瞬間內灌入你的腦袋，而是主持人有新的內容就會繼續講。你不需要重新打開收音機，聲音就會自然傳來。

Server-sent events 的特點就是方向單純，只有伺服器會說話，客戶端紙負責聽。因此這很適合用在即時通知、系統狀態更新、活動倒數、股票報價等等場景。

Pub/Sub：我只想知道跟我有關的事

當系統裡的角色越來越多，「誰該收到什麼資料」就會變成一個問題。這時候就會出現 Pub/Sub（Publish / Subscribe）這種模式。

你可以把它想成訂閱制的電子報。發送訊息的人只負責「發布」，完全不在乎誰會看到；接收的人則自己選擇要訂閱哪些主題。

新聞一發出來，訂閱體育版的人看到的是比賽結果，訂閱財經版的人看到的是股市消息，彼此互不干擾。

在系統裡也是一樣。發布者不需要知道有多少接收者，也不用關心對方是誰，這讓整個系統變得鬆散、好擴充，也更容易加新功能。

Multiplexing / Demultiplexing：一條路，跑很多車

現實世界中，我們很少為了每一台車就蓋一條新道路。大多數時候，是很多車共用同一條路，再在不同的出口分流。

Multiplexing / Demultiplexing 的概念正是如此。

多種不同的資料，先混在同一條連線上傳送，到了目的地之後，再依照規則拆開、分類、交給正確的處理者。

Multiplexing

可以想像一下，如果今天想要傳 100 張照片給你朋友，比較沒有效率的作法是傳一張照片就建立一個專屬通道，傳完一張之後把他關掉，然後再開一個通道再傳下一張照片。那這會發生什麼事呢？

• 浪費資源：光是處理那些開開關關的請求（TLS 連線握手、揮手）就飽了
• 延遲：每個新的連接都要重新跑一遍驗證，會很慢

所以 Multiplexing 就是把這很多張照片打散成多個小封包，然後塞進同條大水管裡面一起傳，這樣不論有多少個請求，大家都共用這條路，效率就會很高。

Demultiplexing

因為傳給伺服器的是一大堆的小封包，伺服器怎麼知道你原本要給它的資料長怎樣呢？Demultiplexing 就是根據封包上面的一些標籤，像是 port number 或 stream ID，把這些碎片重新組裝，準確發送給對應的程式去處理。

對使用者來說，一切都發生得很自然；

但對系統來說，這樣可以大幅減少連線數量，也能更有效率地利用資源。

Stateful 與 Stateless：我記不記得你來過

Stateful

有些系統會「記住你」，有些則刻意不這麼做。Stateful 的系統，就像常去的咖啡店。老闆記得你愛喝什麼、坐哪個位置，你每次進門都不需要重新介紹自己。

舉個 stateful 的例子，就是傳統登入的 session。當使用者帳號密碼正確之後，伺服器會在自己那邊建立一筆紀錄，裡面寫著「這個使用者已經登入了」，然後給使用者一個看起來沒有任何意義的代碼。使用者之後每一次請求，都只需要帶著這個代碼回來。這個代碼本身什麼都不代表，它只是用來讓伺服器查表的鑰匙。真正的登入狀態、使用者身分、權限資訊，全都放在伺服器自己的記憶體或資料庫裡。

Stateless

Stateless 的系統，則比較像便利商店。你每次結帳，都要把商品重新拿給店員看一次，不會因為你昨天來過就有特權。

Stateless 聽起來比較冷漠，但它的好處是清楚、穩定、容易擴充。每一次請求都是獨立的，不用擔心「上一次發生了什麼」，也不怕某一台機器壞掉就影響整個系統。

像是用來驗證身份的 JWT (JSON Web Token) 就是 stateless 的驗證方式。這個 token 上面可能紀錄了使用者的 ID、名字、token 有效期限等等，還會有一個伺服器給的簽名。這個簽名就很重要了，可以把它想成伺服器在這張通行證上蓋的一個專屬章，只有伺服器自己知道怎麼蓋這個章。當使用者成功登入時，伺服器會先把一些必要的資訊整理好，例如使用者的 ID、名字，還有這張通行證的有效期限。接著，伺服器會拿出一把只有自己知道的「秘密鑰匙」，把這些資料混在一起，經過一套固定的計算方式，算出一段看起來毫無意義的字串，這段字串就是簽名。

當使用者之後再帶著這個 token 回來請求資料時，伺服器會做一件很簡單的事：

它會用同一把秘密鑰匙、同一套計算方式，再重新算一次簽名，然後拿來和 token 裡附的簽名比對。如果兩個結果一模一樣，代表這張通行證沒有被竄改，而且確實是伺服器自己發出去的；如果對不起來，就表示資料被動過手腳，或是這張通行證根本是偽造的。

整個過程中，伺服器不需要查詢任何登入紀錄，也不用記得你是誰。它只是在反覆確認一件事：「這張證件，是不是我自己簽發的？」

以身份驗證的問題為例，該使用 stateful 的 session，還是 stateless 的 JWT 呢？主要還是看系統在意的是什麼。如果主要考量的是安全控制，可以使用 session 的作法；如果在意的是擴充性跟分散架構，伺服器上只要有相同的密鑰就可以驗證使用者，可以用 JWT。

Sidecar Pattern：你專心開車，我幫你處理雜事

當系統越來越大，把所有功能都塞進同一個程式，反而會變得難以維護。Sidecar Pattern 的想法很簡單：主程式只做它最擅長的事，其他輔助工作交給旁邊的小幫手。

想像一個沒有經紀人的藝人，除了唱歌表演以外，自己也要處理擋記者、談合約、訂機票、聯絡場地等等瑣事。如果今天換一個藝人了，這個新的藝人是不是就要重新摸索這些瑣事？這樣對藝人來說也太累了。

Sidecar 模式，可以把主程式當成是在台上發光發熱、負責唱歌跳舞的藝人，而 sidecar 就是那個在台下忙到不行的經紀人。有人表演是最重要的事情，因此藝人只管把歌唱好（業務邏輯），經紀人負責擋記者、談合約、訂機票、聯絡場地（網路通訊、安全性、監控）。不論是哪位藝人，經紀人都可以做相同的事情對吧？

以上內容還有前面兩篇，就是常見的後端設計模式了。雖然說我可能整理得有點零散，但還是希望讀者看完之後能有些幫助或收穫，或是在現實生活中也可以有所啟發，那就太好了！