網頁

2020/8/19

為何在微服務中使用訊息佇列 Why use Messaging Queue in Microservices

在微服務架構(Microservice Architecture)中總是可以看到訊息佇列(Messageing Queue, MQ)技術的存在,為什麼微服務系統要使用MQ呢?



微服務架構的特色是將一個大系統(Monolithic System)拆分成多個小服務(microservices),並由這些服務彼此互相溝通來達到整體的功能。因此服務間如何溝通是一個重要的問題。

現今網路應用微服務架構中的每個服務通常是一個網路應用程式(web application),傳統上服務間可透過Web Service/REST API來溝通,但基於HTTP的溝通是是同步的(syncronous),並衍伸出以下問題。

  1. 服務間高耦合。兩服務間必須同時是可運行的狀態,若一方故障會導致整個功能失效。
  2. 服務溝通阻塞。HTTP協定的特色是請求(Request)與回應(Response),當服務A送出Request給服務B後必須等待服務B的Response才會完成後續工作。
  3. 服務故障處理。當服務A傳資料給服務B時服務B發生故障,則服務A該如何處理錯誤,資料該如何暫存,多久該進行重送;當服務B回應而服務A故障會造成傳輸資料丟失的問題。
  4. 當服務接收多方送來的大量請求時會造成故障。
  5. 當服務要送訊息給多個服務時的問題。

而透過MQ溝通可達到非同步(asynchronous)的好處:

  1. 降低耦合。服務間透過MQ溝通,則彼此不需知道對方的存在,降低服務間的耦合。利用MQ的事件驅動(Event-driven)的出版/訂閱(publish/subscribe) or 生產/消費(producer/consumer)模式,當新的服務需要接收另個服務的資料時,只要向MQ訂閱即可,一旦有新的訊息MQ便會發送給訂閱方。
  2. 非阻塞溝通。服務送資料給MQ後即可繼續進行後續的任務,不會因等待回應而造成阻塞。
  3. 擴展容易。當一個服務實例處理不來時,可輕鬆地增加新的服務實例並由MQ進行分派。
  4. 增加可靠性。MQ可保存發送或回應訊息,在故障回復時可重送訊息,避免因服務故障造成的訊息丟失。

沒有留言:

張貼留言