SpringCLoud——异步通信MQ技术

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

异步调用的问题

异步调用常见实现就是事件驱动模式。

所谓事件驱动，就是和之前的订阅消息模式是一样的。首先我们要有一个消息代理者，当我们的前置业务完成之后，会通知给消息代理者，告诉他我的业务完成了，并携带一些业务信息，然后所有的依赖于前置业务完成之后才能执行的后置业务，全部都去订阅消息的管理者，当消息管理者接收到前置业务完成的消息时，他会通知给所有订阅消息的后置业务去执行自己的业务，而前置业务完成之后，则不会去管后置业务有没有完成，而是直接返回回去继续去接受其他人的请求。

异步调用的优缺点

1. 服务解耦

当我们需要添加一个新的业务的时候，我们并不需要去像之前的同步调用的时候修改前置业务，而是直接让新加入的后置业务去订阅消息代理者，然后在接收到消息之后完成自己的逻辑即可。同样的，当我们想要移除一个业务的时候，只需要让他不在订阅消息即可。

1. 性能提升，吞吐量提高

在之前，我们的业务时长是所有服务完成的总和，如果一个业务需要150毫秒，则全部的业务走完需要550毫秒，当并发量高的时候，这种毫秒级的处理事件也会变得很大。但是在异步通信中，我们并不会计算所有服务的总和，而是只需要计算前置服务的执行时间，以及前置服务发送消息到消息管理者的时间，毕竟只有这段时间是用户可以感知到的，当前置服务完成了自己的服务，会直接给用户展示一个业务完成的信息，之后的所有的业务时间再长，用户也是不可知的，同样的，前置业务也无法感知后续业务的执行时间和执行结果。

1. 服务没有强依赖，不担心级联失败问题

在之前的同步调用的时候，当这个调用链上的某一个服务出现了问题，则这条链上的服务早晚都会全部都出问题，这就是级联失败。但是当我们使用异步调用的时候，由于前置业务只需要将业务完成的消息发送给消息管理者，然后后置任务去订阅即可，也就是说前置业务并不是直接调用后置业务，也就没有级联的现象，而后置业务出错也就只会有这一个单独的业务失败而已。

1. 流量削峰

流量削峰是异步通信的一个独有的优势，也就是当我们的并发量非常大的时候，此时如果消息一直来一直来，那么这些服务会承受不住压力而崩溃。但是在异步通信中，我们这么多的消息，可以暂时缓存在消息订阅者这里，然后后置服务依然用自己的稳定速度去消费这些消息，直到消息全部消费完成，而这中间所有的负载全部都是由消息管理者在扛着。

总结

异步通信的优点：

1. 耦合度低
2. 吞吐量提升
3. 故障隔离
4. 流量削峰

异步通信的缺点

1. 依赖于Broker的可靠性、安全性、吞吐能力
2. 架构复杂了，业务没有明显的流程线，不好追踪管理

异步通信的使用场景比较有限，在大部分的情况下，我们最长使用的还是同步通信。

MQ的实现技术

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

RabbitMQ

RabbitMQ概述

RabbitMQ是基于Erlang语言开发的开源消息通信中间件，官网地址：RabbitMQ: easy to use, flexible messaging and streaming — RabbitMQ

单机部署

在CentOS7中使用Docker来部署，首先，我们要打开Docker来搜索一下相关的镜像：

在docker中搜索RabbitMQ，就会出现相关的镜像，首先我们把镜像拉取到本地：

docker pull rabbitmq:3-management

好的，这样就完成了本地镜像的拉取。

然后就是通过命令启动一下RabbitMQ：

docker run \

-e RABBITMQ_DEFAULT_USER=admin \

-e RABBITMQ_DEFAULT_PASS=123456 \

--name rabbitmq \

--hostname mq1 \

-p 15672:15672 \

-p 5672:5672 \

-d \

rabbitmq:3-management

其中有一些参数，比如环境变量，也就是-e参数后面我们配置了用户名和密码，然后--hostname是之后在集群配置中会用到的，以及我们暴露了两个端口，15672是我们的管理界面端口，5672是消息通信端口。

这样就完成了RabbitMQ的启动。

然后我们就可以访问一下15672的管理界面端口：

进到这里之后，用我们刚才在docker run命令中配置的用户名和密码进行登录：

这样就进入到了RabbitMQ的一个管理界面。

RabbitMQ中的几个概念：

1. channel：操作MQ的工具，消费和生产消息都需要用到这个。
2. exchange：路由消息到队列中
3. queue：缓存消息
4. virtual host：虚拟主机，是对queue，exchange等资源的逻辑分组。

RabbitMQ的结构和概念

首先我们的队列两边分别是我们的消息的发布者和订阅者，同时在我们的RMQ（RabbitMQ的简写）中，会存在多个虚拟主机，因为我们的RMQ可以存在多个用户，每个用户最好分配一个独立的虚拟主机，用来分离不同用户的消息队列。而在虚拟主机中，exchange是路由器，负责将消息分发到不同的队列中，从而让不同的消费者去消费。而queue就是队列，是负责缓存消息的地方。