訊息的溝通 - Message Queue
大型網頁應用程式系統中，一般不會單獨一隻程式存在，而是會有多隻程式同時負責各種不同的任務，以及雲端服務盛行的微服務架構下，難免會有服務間互相傳遞資料進行溝通，而這類的需求，都統稱為 Applcation 的整合。
什麼是 Message Queue
本章要介紹的訊息佇列(Message Queue 簡稱：MQ)是一種非同步服務對服務通訊形式，本質是一個佇列，FIFO先入先出，只不過存放的內容是message。不同系統傳遞訊息時，兩個系統會因為耦合程度過高，改動一個系統，引發必須修改另一個系統，為了隔離這兩個系統，在兩個系統間抽離出一層（一個模組），所有兩系統之間的溝通，都必須通過 Message Queue 來傳遞。
基本上 Message Queue 的架構由 Producers, Queue, Consumers 所組成。
Producers (訊息提供者)：
負責建立訊息並傳遞至Message Queue。
Queue (佇列)：
接收傳遞訊息的任務並依序排好，之後依照任務順序取出並處理。
Message (傳遞內容)：
Message 其實就是系統之間傳遞的資料，例如通知一個服務執行某項任務的訊息，像是訊息中心系統，傳遞要通知的訊息及相關人員到服務中，告知服務執行Email等相關通知功能。
Consumers (訊息接收者)
負責從queue中取出訊息並執行對應的服務內容。存放在queue中的message會在被接收後移除。
Message Queue 優勢
1. 更好的效能
非同步的優勢下，提供更好的效能，Consumers 有空才會處理 message，比起持續的 polling 的方式相對有效率。
2. 程式解偶
訊息的發送方和接受方都不需要知道彼此，在交互的過程中，插入了一個隱含的，並基於數據的接口層，兩邊的處理過程只需要實現這一接口，Producers 和 Consumers 可隨意使用不同語言開發，且獨立的擴展及自由的處理過程，只需要遵守相同的接口約束。
3. 可靠性
Consumer 暫時無法提供服務時，Message queue 可以暫存資料，等待 Consumers 重新上線後再接收訊息。
4. 訊息快取
訊息的快取機制，在某些情況下，處理數據可能會發生錯誤造成失敗等，除非數據已被持久化，否則可能會造成數據的遺失。Message Queue 把數據持久化直到他們被完全處理，以規避數據丟失的風險。
5. 擴展的靈活性
當處理的訊息太多，生產的速度快於消耗的速度，此時 Producers , Queue, Consumers 可以依照需求擴張或縮減。
Message Streaming 與 Web APIs 選擇
基於 REST 的 Web API
基於 REST 的 Web API 在用戶端（Frontend）和 API 服務（Backend）之間的溝通，我們使用 HTTP 作為我們的協議。 我們的設計很大的程度上依賴於 HTTP，從方法（例如 GET、POST、PUT、PATCH、DELETE）到幫助我們在客戶端和服務器之間進行通信的標頭（例如授權、接受、內容類型）。
特徵：
● Request / Response 對應 - Consumers 向 API 服務端發起請求，服務端返回響應結果。
● 基於 Pull-based - Consumers 需要資料或功能時，需主動向 API 服務端發起請求。
● 同步 - Consumers 在發送請求後接收響應。
訊息流 (Message Streaming)
與 REST API 不同的是，訊息流更擅長在新訊息到達時提供通知。客戶端訂閱後，會在有新訊息時，收到通知。
特徵：
● Publish / Subscribe 對應 - Producers 發送訊息，可能有0個或多個訂閱者可接收訊息，而不是 Request/Response 單一對應模式。
● Subscriber 通知 - Consumers 如有訂閱，將會在有新訊息時，接收到通知。
● 異步 - 與 REST API 不同的是，傳遞訊息後，無法立即得到回應。
同樣都是透過 network，processes之間的通訊，他們之間最大的不同就是一個是 asynchronous message passing，而 HTTP request是synchronous(同步)的，也就是client發出了request，會等待在那邊，期待著response回來。
參考來源：
