前言
基于OpenFeign的同步调用会存在一些问题：
- 拓展性差：随着产品功能的完善，业务会越来越臃肿。
- 性能下降：每次远程调用，调用者都是阻塞等待状态，如果微服务过多，整个业务耗时过久。
- 级联失败：基于OpenFeign调用某一业务功能下的服务时，当某服务出现故障，整个事务都会回滚。但如果某些服务在整个业务中不是主要功能（比如支付后的短信通知等），失败后回滚会影响业务的效率。
要解决这些问题，就要用异步调用的方式来代替同步调用。
一、异步调用
1. 异步调用方式就是基于消息通知的方式，一般包含三个角色：
- 消息发送者：投递消息的人，就是原来的调用方。
- 消息Broker：管理、暂存、转发消息。
- 消息接收者：接收和处理消息的人，就是原来的服务提供方。
2. 异步调用的优势：
- 耦合度更低
- 性能更好
- 业务拓展性强
- 故障隔离，避免级联失败
3. 异步调用的缺点：
- 完全依赖于Broker的可靠性、安全性和性能
- 架构复杂、后期维护和调试麻烦
二、消息队列MQ
消息Broker，目前常见的实现方案就是消息队列（Message Queue），简称MQ。
几种常见MQ的对比：
| RabbitMQ | ActiveMQ | RocketMQ | Kafka | |
| 公司/社区 | Rabbit | Apache | 阿里 | Apache |
| 开发语言 | Erlang | Java | Java | Scala&Java |
| 协议支持 | AMQP，XMPP，SMTP，STOMP | OpenWire,STOMP，REST,XMPP,AMQP | 自定义协议 | 自定义协议 |
| 可用性 | 高 | 一般 | 高 | 高 |
| 单机吞吐量 | 一般 | 差 | 高 | 非常高 |
| 消息延迟 | 微秒级 | 毫秒级 | 毫秒级 | 毫秒以内 |
| 消息可靠性 | 高 | 一般 | 高 | 一般 |
- 追求可用性：Kafka、 RocketMQ 、RabbitMQ
- 追求可靠性：RabbitMQ、RocketMQ
- 追求吞吐能力：RocketMQ、Kafka
- 追求消息低延迟：RabbitMQ、Kafka
三、RabbitMQ
RabbitMQ架构
- Publisher：生产者，消息发送方。
- consumer：消费者，消息接收方。
- queue：队列，存储消息；生产者投递的消息会暂存在消息队列中，等待消费者处理。
- exchange：交换机，负责消息路由。生产者发送的消息由交换机决定投递到哪个队列。
- VirtualHost：虚拟主机，起到数据隔离的作用。每个虚拟主机相互独立，有各自的exchange、queue。
Work Queues模型
Work Queues模型，任务模型，就是让多个消费者绑定到一个队列，共同消费队列中的消息。
- 多个消费者绑定到一个队列，同一条消息只会被一个消费者处理。
- 通过设置prefetch来控制消费者预取的消息数量。
交换机类型
交换机只负责转发消息，不具备存储消息的能力，如果没有任何队列与交换机绑定，或者没有符合路由规则的队列，消息就会丢失。
交换机的类型有四种：
- Fanout：广播，将消息交给所有绑定到交换机的队列。
- Direct：订阅，基于RoutingKey发送给订阅了消息的队列。
- Topic：通配符订阅，与Direct类似，只不过RoutingKey可以使用通配符。
- Headers：头匹配，基于MQ的消息头匹配，用的较少。