為何在微服務中使用訊息佇列 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可保存發送或回應訊息，在故障回復時可重送訊息，避免因服務故障造成的訊息丟失。

• Microservice Architecture Best Practices: Messaging Queues
• Message Queue vs. Web Services?
• Communication in a microservice architecture