异步通讯与同步通讯的优缺点、异步通讯RabbitMQ——安装和部署，构建简单的队列模型，通过SprignAMQP构建发布订阅模型（Fanout、Direct、Topic三种交换机的实现以及区别详解）

前言：在进行RabbitMQ的安装和应用之前，可以先了解一下什么是服务的同步通讯以及什么是服务的异步通讯，异步通讯能够解决的问题，以及其优缺点

服务同步通讯：典型代表就是微服务中我们使用的feign服务远程调用，比如一个自己开发的支付服务需要调用订单支付服务，可以通过feign功能远程调用实现，同时我们也能在调用结束后很快的拿到需要的数据，但如果我们不止调用这一个服务还要调用其他多个服务，那么我们也只有等到订单支付服务调用结束后，才能调用其他服务，当整个服务调用完成，所耗的时间是各个服务之和，在针对高并发的情况下会对服务器产生巨大的压力同时导致性能下降，同时在通过feign进行服务之间的远程调用会增加微服务之间的耦合度，不利于后续的代码维护，以及当某个服务提供者出现问题会导致调用方跟着发生问题，甚至导致服务群崩溃

优点：

时效性较强，可以立即得到结果

部署比较简单，可读性更高

缺点

耦合度高

性能和吞吐能力下降

有额外的资源消耗

有级联失败问题

服务异步通讯：这里我要介绍的服务异步通讯技术就是RabbitMQ(其他的还有ActiveMQ、RocketMQ、Kafka)，首先异步调用的常见实现是事件驱动模式（围绕事件的发布、捕获、处理和存储（或持久化），简单理解就是某个应用或服务执行一项操作或经历另一个应用或服务可能想知道的更改时，就会发布一个事件（也就是对该操作或更改的记录），另一个应用或服务便可以消费和处理该事件，继而执行更多操作。）如下图

当完成支付服务的相关事件后，就发布出一个事件到broker（事件代理者，统一管理和发布事件，就是上面的喇叭，同时也可以称为MQ （MessageQueue），中文是消息队列，字面来看就是存放消息的队列。）中，就不在需要亲自将事件转发给其他相关服务，解除了服务与服务之间的耦合度，其他服务会在broker中进行订阅，当有对应事件发布了，其他服务会更具发布的事件完成各自的业务，互相独立，同时并发执行，也就提高了服务性能，保证了业务之间的不会因为某个服务而崩溃，同时还可以通过broker作为一个缓冲池，避免因为流量过大导致服务崩坏

优点：

耦合度低

吞吐量提升

故障隔离

流量削峰

缺点：

依赖于Broker的可靠性、安全性、吞吐能力

架构复杂了，业务没有明显的流程线，不好追踪管理

时效性相对于同步通讯较低

无法应用于需要得到其他服务处理结果的业务场景