RabbitMQ

同步通讯和异步通讯

微服务间通讯有同步和异步两种方式。同步通讯就像打电话，需要实时响应；异步通讯就像发邮件，不需要马上回复。两种方式各有优劣，打电话可以立即得到响应，但是却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件，但是往往响应会有延迟。

Feign调用就属于同步方式

同步通讯的问题：

支付服务完成后依次调用订单服务，仓储服务，短信服务...

1. 耦合度高，每次加入新的需求都要修改调用代码
2. 性能和吞吐量下降，调用者需要每次等待提供者的响应，如果调用链过长则响应时间等于每次调用的时间之和
3. 资源浪费，调用链中每个服务在等待后续调用者响应的过程中，不能释放请求占用的资源，高并发场景下会极度浪费系统资源
4. 级联失败，如果服务提供者出现问题，所有调用者都会出现问题，迅速导致整个服务集群故障，

异步调用则可以避免上述问题，异步调用常见实现就是事件驱动模式

发布订阅：为了解除事件发布者与订阅者之间的耦合，两者并不是直接通信，而是有一个中间人（Broker）。发布者发布事件到Broker，不关心谁来订阅事件。订阅者从Broker订阅事件，不关心谁发来的消息。

Broker 是一个像数据总线一样的东西，所有的服务要接收数据和发送数据都发到这个总线上，这个总线就像协议一样，让服务间的通讯变得标准和可控。

支付服务完成后通知订单服务，仓储服务，短信服务...

1. 耦合度极低，每个服务都可以灵活插拔，可替换；加新虚求的时候，让新服务订阅Broker就可以
2. 性能和吞吐量提升：服务提供者通知完就可以进行另外的业务了，提升了吞吐量，无需等待订阅者处理完成，响应更快速
3. 调用间没有阻塞，不会造成无效的资源占用
4. 故障隔离：服务没有直接调用，不存在级联失败问题；某一个服务调用者挂了也和服务提供者没有关系，不会影响服务提供者继续提供服务
5. 流量削峰：通知先放在Broker上(Broker承担压力)，不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件，高并发就会变成低并发

缺点：

• 架构复杂了，业务没有明显的流程线，不好管理
• 需要依赖于Broker的可靠、安全、性能

大多数情况下都会选择同步，因为大多数情况下对并发的要求很低，但是对时效性要求较高；异步调用通知完后没有返回结果
当不需要知道结果，只是这件事干完去干另一件事，而且对并发，解耦的要求很高时，才会用异步通信。

MQ

好在现在开源软件或云平台上 Broker 的软件是非常成熟的，比较常见的一种就是我们今天要学习的MQ技术。

MQ，中文是消息队列（MessageQueue），字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。

几种常见MQ实现的对比：

	RabbitMQ	ActiveMQ	RocketMQ	Kafka
公司/社区	Rabbit	Apache	阿里	Apache
开发语言	Erlang	Java	Java	Scala&Java
协议支持	AMQP，XMPP，SMTP，STOMP	OpenWire,STOMP，REST,XMPP,AMQP	自定义协议	自定义协议
可用性	高	一般	高	高
单机吞吐量	一般	差	高	非常高
消息延迟	微秒级	毫秒级	毫秒级	毫秒以内
消息可靠性	高	一般	高	一般

RabbitMQ

RabbitMQ是基于Erlang语言开发的开源消息通信中间件，官网地址：https://www.rabbitmq.com/

• publisher：生产者
• consumer：消费者
• exchange：交换机，负责消息路由
• queue：队列，存储消息
• virtualHost：虚拟主机，隔离不同租户的exchange、queue、消息的隔离

RabbitMQ中的几个概念：
channel：操作MQ的工具
exchange：路由消息到队列中
queue：缓存消息
virtual host：虚拟主机，是对queue、exchange等资源的逻辑分组

基本消息队列的消息发送流程：
建立connection
创建channel
利用channel声明队列
利用channel向队列发送消息

基本消息队列的消息接收流程：

建立connection
创建channel
利用channel声明队列
定义consumer的消费行为handleDelivery()
利用channel将消费者与队列绑定