微服务框架 SpringCloud微服务架构 14 初识MQ 14.2 异步通讯的优缺点

微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

SpringCloud微服务架构

14 初识MQ

14.2 异步通讯的优缺点

14.2.1 异步调用方案

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

【举个栗子】

用户在完成下单操作后，肯定会调用支付服务，支付服务完成支付后，就需要后面的订单服务、仓储服务、短信服务各自完成各自的业务

事件驱动模式就不能像之前那样挨个儿 调了

它引入了一个东西叫 Broker【事件代理者】

在这里栗子中，一旦有人支付成功，就是一个事件，接着这个事件就会交给Broker 进行管理

后面仨服务就会去找这个Broker，希望它知道有人支付这个事件后，通知它们，这个就叫“订阅事件”

一旦订阅成功后

将来支付服务发现有人支付成功，就会发布一个事件出去，那Broker 就会通知后面那仨服务

接着它们仨就会去处理对应的业务

在这整个过程当中，支付服务完成事件发送之后就算结束了自己的业务，就可以去返回给用户了，就不需要再去等待后面那仨完成。【这就是异步的方式】

14.2.2 事件驱动优势

优势一：服务解耦

一旦添加了新的后置业务，它要做的事就是去订阅Broker，这样就不用修改支付服务的代码了，因为支付服务并不会直接调用其它服务了

而且，如果哪项服务将来想取消，

以前同步还得改回去代码，现在直接取消订阅就行了，通知不到，短信服务就不会进行了

【即增加业务、删除业务都不用改代码了】

优势二：性能提升，吞吐量提高

这下支付服务就不用管其他仨服务了

优势三：服务没有强依赖，不担心级联失败问题

现在假设仓储服务挂了，和支付服务无瓜了

优势四：流量削峰

随着业务量增加、用户增多， 请求变多了

一瞬间来了仨

这个时候Broker 就可以起到一个缓冲的作用【这样一来，压力都由Broker 扛着】

这样一个高峰并发， 就会被砍平，变得平坦【也对微服务起到了保护作用】

14.2.3 总结

异步通信的优点：

• 耦合度低
• 吞吐量提升
• 故障隔离
• 流量削峰

异步通信的缺点：

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