微服务异步通信->消息代理

使用消息代理
基于消息传递通常使用消息代理，即服务通信的基础设施。还可以使用无代理的消息传递架构，其中服务之间通信。两种方法（如下图所示）具有不同的利弊，但通常基于消息代理的架构是更好的一种方法。

无代理消息：

无代理架构中，服务可以直接交互消息。ZeroMQ是一种流行的无代理消息技术。它既是规范，也是一组适用于不同编程语言的库，支持各种传输协议，包括TCP、UNIX风格的套接字和多播。	

无代理架构的好处：

1. 允许更轻的网络流量和更低的延迟，因为消息直接从发送方到接收方，而不是经过了一层消息代理
2. 消除了消息代理可能成为性能瓶颈或单点故障的可能性
3. 降低操作复杂性，不需要设置和维护消息代理

无代理的弊端：

• 服务需要了解彼此的位置，必须使用服务发现机制
• 会导致可用性降低，因为在交换消息时，消息的发送方和接收方都必须同时在线
• 在实现 例如确保消息能够投递成功这些功能更复杂

基于代理的消息：

消息代理是所有消息的中介节点。发送方将消息写入消息代理，消息代理将消息发送给接收方。使用消息代理的一个重要好处是不需要知道接收方的网络位置。另一个好处是消息代理缓冲消息，直到接收方能够出来它们。

流行的开源消息代理包括：

• Apache ActiveMQ
• RabbitMQ
• Apache Kafka

选择消息代理，需要考虑如下因素：

• 支持的编程语言

   选择消息代理应该尽可能支持多种编程语言
  

• 支持的消息标准

   消息代理是否支持多种消息标准，比如AMQP和STOMP，还是它仅支持专用的消息标准
  

• 消息排序

   消息代理是否能够保留消息的排序
  

• 投递保证

   消息代理提供什么样的消息投递保证
  

• 持久性

   消息是否支持持久化保存到磁盘上并且能够在代理崩溃后恢复
  

• 耐久性

   如果接收方重新连接到消息代理，它是否会收到断开连接时发送的消息
  

• 可扩展性

   消息代理的扩展性如何
  

• 延迟

   端到端是否有较大的延迟
  

• 竞争性（并发）接收方

   消息代理是否支持竞争性接收方？
  

基于消息代理的好处

• 松耦合

   客户端发起请求时只要发送给特定的消息通道即可。客户端不需要获取服务实例的情况，也不需要知道服务的网络位置
  

• 消息缓存

   消息代理可以在消息被处理之前一直缓存消息
  

• 灵活的通信

   消息机制支持很多交互方式，如HTTP REST GRPC
  

• 明确的进程间通信

   基于RPC的机制总数企图让远程服务调用和本地调用看上去没有区别（客户端和服务同时使用远程调用代理）。
  

消息代理的弊端

• 潜在的性能瓶颈

   消息代理可能存在性能瓶颈。但是许多消息代理都支持集群
  

• 潜在的单点故障

   消息代理的高可用性至关重要，否则整个系统的可靠性将会受到影响。大多数现代消息代理都是高可用的
  

• 操作的复杂性

   消息代理是一个必须独立安装、配置和运维的系统组件