參考資料


Pattern: Messaging
Client 使用非同步 messaging 來呼叫服務。參見 http://microservices .io/patterns/communication-style/messaging.html。

基於 messaging 的應用程式
  1. message broker：broker 作為服務之間的中介
  2. brokerless 架構：服務之間直接溝通

訊息
由 header 和 message body 組成：
  1. Header 是一組 name-value pair
  2. 由訊息的發送者提供
  3. 例如由發送者或 messaging 基礎設施產生的唯一 message id

Message body 是被傳送的資料
  • Document：只包含資料。對 command 的回覆就是一個 document message 的例子
  • Command：等同於 RPC 請求。
  • Event：一個訊息，表示發送者端發生了某個值得注意的事

Message Channel
  1. 發送者呼叫 sending port interface
  2. sending port 由 message sender adapter class 實作，透過 message channel 將訊息發送給接收者。
  3. Message channel 是 messaging 基礎設施的抽象
  4. 接收者端的 message handler adapter class 被呼叫來處理訊息
  5. Message handler 呼叫由消費者商業邏輯實作的 receiving port interface。
  6. 兩種 channel 類型
    1. point-to-point：將訊息只傳遞給其中一個消費者
    2. publish-subscribe：將每個訊息傳遞給所有已訂閱的消費者



使用 messaging 實作互動風格
  • Client 發送一個帶有 reply channel header 的 command message
  • Server 將 reply message 寫入 reply channel，其中包含一個 correlation id，值與 message identifier 相同
  • Client 使用 correlation id 將 reply message 與 request 配對

實作單向通知
服務訂閱 channel 並處理訊息

實作 PUBLISH/SUBSCRIBE
Client 將訊息發佈到一個 publish-subscribe channel，由多個消費者讀取
發佈 domain event 的服務擁有一個 publish-subscribe channel，名稱取自 domain class

實作 PUBLISH/ASYNC RESPONSES
Client 將一個帶有 reply channel header 的訊息發佈到 publish-subscribe channel
消費者將帶有 correlation id 的 reply message 寫入 reply channel。
Client 透過 correlation id 將 reply message 與 request 配對來收集回應

為基於 messaging 的服務 API 建立規格
服務非同步 API 的規格必須指定 message channel 的名稱、每個 channel 上交換的訊息類型及其格式。

記錄非同步操作
  • Request/async response 風格的 API
    • 服務的 command message channel
    • command message 的類型和格式
    • reply message 的類型和格式
  • 單向通知風格的 API
    • 服務的 command message channel
    • command message 的類型和格式
  • 一個服務可以對 asynchronous request/response 和 one-way notification 使用相同的 request channel

記錄發佈的 Event
服務也可以使用 publish/subscribe 互動風格來發佈 event
  • event channel
  • event message 的類型和格式



You May Also Enjoy