微服务架构中的进程间通信2（异步通信）

基于异步消息模式的通信：

使用消息机制时，服务之间的通信采用异步交换消息的方式完成。基于消息机制的应用程序通常使用消息代理，它充当服务之间的中间件。

• 什么是消息传递：
  消息通过消息通道进行交换。发送方（客户端或服务）将消息写入通道，接收方（客户端或服务）从消息通道读取消息。
  消息由消息头部和消息主体组成。标题是名称与值对的集合，描述正在发送的数据元数据。除了消息发送者提供的名称与值对之外，消息头部还包含其他消息，例如发件人或消息传递基础设施生成的唯一消息ID，以及可选的返回地址，该地址指定发送回复的消息通道。
  有以下几种不同类型的消息：

    - 文档：仅包含数据的通用消息。如json、xml等
    - 命令：一条等同于RPC请求的消息。它指定要调用的操作及参数
    - 事件：表示发送方这一端发送了重要的事件。事件通常是领域事件，表示领域对象（如Order服务或User服务）的状态更改。
  

• 关于消息通道：
  消息通过消息通道进行交换。发送方中的业务逻辑调用发送端接口，接口封装了底层通信机制。发送端由消息发送适配器类实现，消息发送适配器类通过消息通道向接收器发送消息。消息通道是消息传递基础设施的抽象。调用接收器中的消息处理程序适配器类来处理消息。它调用接收方业务逻辑实现的接收端接口。任意数量的发送方都可以向通道发送消息。
  有两种类型的消息通道：

   - 点对点通道：
   	向正在从通道读取的一个消费者传递消息。服务使用点对点通道来实现前面描述的一对一交互方式。例如命令消息通常通过点对点通道发送
   	
    - 发布-订阅：
    	通道将一条消息发送给所有定义的接收方。服务使用发布-订阅通道来实现前面描述的一对多交互方式。例如，事件式消息通常通过发布-订阅通道发送。
  

使用消息机制实现交互方式：

	消息机制的一个有价值的特性是足够灵活

• 实现请求/响应和异步请求 / 响应：
  当客户端和服务使用请求 / 响应或异步请求/响应时，客户端会发送请求，服务会响应。区别在于，对于请求 / 响应，客户端期望立即响应，而异步请求 / 响应，则不要求立即响应。消息机制本质上是异步的，因此只提供异步请求 / 响应。但客户端可能会堵塞，直到收到回复。

  客户端和服务通过交换一对消息来实现异步请求 / 响应的交互。客户端必须告诉服务发送回复消息的位置，并且必须将回复消息与请求匹配。好在，解决这两个问题并不困难。因为客户端发送具有回复通道头部的命令式消息，服务器将回复消息写入回复通道，该回复消息包含与消息标识具有相同值的相关性ID。客户端使用相关性ID将回复消息与请求进行匹配。

  由于客户端和服务使用消息机制进行通信，因此交互本质上是异步的。理论上，使用消息机制的客户端可能会阻塞，直到收到回复，但实际上客户端将使用异步处理回复，并不会一直等待。而且，回复通常可以由任何一个客户端实例处理。

• 实现单向通知：
  使用异步消息实现单向通知非常简单。客户端将消息发送到服务所拥有的点对点通道。服务订阅该通道并处理该消息，但是服务不会发回回复。

• 实现发布 / 订阅：
  消息机制内置了对发布/订阅交互方式的支持。客户端将消息发布到由多个接收方读取发布/订阅通道。服务使用发布/订阅来发布领域事件，领域事件代表领域对象的更改。发布领域事件的服务拥有自己的发布 / 订阅通道，通道的名称往往派生自领域类。

• 实现发布 / 异步响应：
  发布 / 异步响应交互方式是一种更高级别的交互方式，它通过把发布 / 订阅和请求 / 响应这两种方式的元素组合在一起实现。客户端发布一条消息，在消息的头部中指定回复通道，这个通道同时也是一个发布 - 订阅通道。服务将包含相关性ID的回复消息写入回复通道。客户端通过使用相关性ID来收集响应，以此将回复消息与请求进行匹配。

记录异步操作：

可以使用一下两种不同交互方式之一调用服务的操作：

• 1：请求 / 异步响应方式API

   包括服务的命令消息通道、服务接受的命令式消息的具体类型和格式，以及服务发送的回复消息的类型和格式
  

• 2：单向通知式API

   包括服务的命令消息通道，以及服务接受的命令式消息的具体类型和格式。