基於異步消息模式的通信：
使用消息機制時，服務之間的通信採用異步交換消息的方式完成。基於消息機制的應用程序通常使用消息代理，它充當服務之間的中間件。
-
什麼是消息傳遞：
消息通過消息通道進行交換。發送方（客戶端或服務）將消息寫入通道，接收方（客戶端或服務）從消息通道讀取消息。
消息由消息頭部和消息主體組成。標題是名稱與值對的集合，描述正在發送的數據元數據。除了消息發送者提供的名稱與值對之外，消息頭部還包含其他消息，例如發件人或消息傳遞基礎設施生成的唯一消息ID，以及可選的返回地址，該地址指定發送回覆的消息通道。
有以下幾種不同類型的消息：- 文檔：僅包含數據的通用消息。如json、xml等 - 命令：一條等同於RPC請求的消息。它指定要調用的操作及參數 - 事件：表示發送方這一端發送了重要的事件。事件通常是領域事件，表示領域對象（如Order服務或User服務）的狀態更改。 -
關於消息通道：
消息通過消息通道進行交換。發送方中的業務邏輯調用發送端接口，接口封裝了底層通信機制。發送端由消息發送適配器類實現，消息發送適配器類通過消息通道向接收器發送消息。消息通道是消息傳遞基礎設施的抽象。調用接收器中的消息處理程序適配器類來處理消息。它調用接收方業務邏輯實現的接收端接口。任意數量的發送方都可以向通道發送消息。
有兩種類型的消息通道：- 點對點通道： 向正在從通道讀取的一個消費者傳遞消息。服務使用點對點通道來實現前面描述的一對一交互方式。例如命令消息通常通過點對點通道發送 - 發佈-訂閱： 通道將一條消息發送給所有定義的接收方。服務使用發佈-訂閱通道來實現前面描述的一對多交互方式。例如，事件式消息通常通過發佈-訂閱通道發送。
使用消息機制實現交互方式：
消息機制的一個有價值的特性是足夠靈活
-
實現請求/響應和異步請求 / 響應：
當客戶端和服務使用請求 / 響應或異步請求/響應時，客戶端會發送請求，服務會響應。區別在於，對於請求 / 響應，客戶端期望立即響應，而異步請求 / 響應，則不要求立即響應。消息機制本質上是異步的，因此只提供異步請求 / 響應。但客戶端可能會堵塞，直到收到回覆。客戶端和服務通過交換一對消息來實現異步請求 / 響應的交互。客戶端必須告訴服務發送回覆消息的位置，並且必須將回復消息與請求匹配。好在，解決這兩個問題並不困難。因爲客戶端發送具有回覆通道頭部的命令式消息，服務器將回復消息寫入回覆通道，該回復消息包含與消息標識具有相同值的相關性ID。客戶端使用相關性ID將回復消息與請求進行匹配。
由於客戶端和服務使用消息機制進行通信，因此交互本質上是異步的。理論上，使用消息機制的客戶端可能會阻塞，直到收到回覆，但實際上客戶端將使用異步處理回覆，並不會一直等待。而且，回覆通常可以由任何一個客戶端實例處理。
-
實現單向通知：
使用異步消息實現單向通知非常簡單。客戶端將消息發送到服務所擁有的點對點通道。服務訂閱該通道並處理該消息，但是服務不會發回回復。 -
實現發佈 / 訂閱：
消息機制內置了對發佈/訂閱交互方式的支持。客戶端將消息發佈到由多個接收方讀取發佈/訂閱通道。服務使用發佈/訂閱來發布領域事件，領域事件代表領域對象的更改。發佈領域事件的服務擁有自己的發佈 / 訂閱通道，通道的名稱往往派生自領域類。 -
實現發佈 / 異步響應：
發佈 / 異步響應交互方式是一種更高級別的交互方式，它通過把發佈 / 訂閱和請求 / 響應這兩種方式的元素組合在一起實現。客戶端發佈一條消息，在消息的頭部中指定回覆通道，這個通道同時也是一個發佈 - 訂閱通道。服務將包含相關性ID的回覆消息寫入回覆通道。客戶端通過使用相關性ID來收集響應，以此將回復消息與請求進行匹配。
記錄異步操作：
可以使用一下兩種不同交互方式之一調用服務的操作：
-
1：請求 / 異步響應方式API
包括服務的命令消息通道、服務接受的命令式消息的具體類型和格式，以及服務發送的回覆消息的類型和格式 -
2：單向通知式API
包括服務的命令消息通道，以及服務接受的命令式消息的具體類型和格式。