微服务【同步和异步通讯详解】第6章

• 💂 个人主页: 爱吃豆的土豆
• 🤟 版权: 本文由【爱吃豆的土豆】原创、在CSDN首发、需要转载请联系博主
• 💬 如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)和订阅专栏哦

• 🏆人必有所执，方能有所成！

• 🐋希望大家多多支持😘一起进步呀！

目录

1.1：同步和异步通讯

1.1.1：同步通讯

1.1.2：异步通讯

---

1.1：同步和异步通讯

微服务间通讯有同步和异步两种方式：

同步通讯：就像打电话，打视频，需要实时响应。（就像你给一个妹子打视频，视频接通，你们两人就建立了同步通讯，什么叫同步？就是接通后你说的任何话即刻传输给对方，对方即刻进行响应就像直播一样，这就是同步。但是呢！万一这个时候又来两个妹子打了过来，你就无法接通，容易措施良机）

异步通讯：就像发邮件，微信什么的，不需要马上回复。（异步通讯就当于微信聊天，你给妹子发个信息，妹子不给你回你就收不到消息，这种时效性比较差。但是呢！异步通讯你可以咔咔给好多妹子发信息，这样就可以等待多个妹子回复。）

两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发送微信可以同时与多个人收发信息，但是往往响应会有延迟。

1.1.1：同步通讯

我们之前学习的Feign调用就属于同步方式，虽然调用可以实时得到结果，但存在下面的问题：

总结：

同步调用的优点：

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

同步调用的问题： 

• 耦合度高：（如下图：产品经理说你支付服务里面在加个短信服务，过一会产品经理又说支付服务里面再加个优惠卷服务，就造成了每次加入新业务就需要修改支付服务里面原先的代码。存在耦合度高的问题）

• 性能和吞吐能力下降（就像现在支付服务调用自己的每个服务都是150ms处理完整的一次请求就是500ms，1秒才能处理两个用户支付请求，当用户量大，并发量大的时候处理的如此慢。就存在一个性能和吞吐的能力下降的问题）

• 有额外的资源消耗（就像支付服务调用订单服务，订单服务处理150ms，其他服务在这150ms内静静的看着，占用着Cpu和内存啥都不干，造成额外的资源浪费）

• 有级联失败问题  （假设仓储服务，扛不住压力服务挂了，支付服务调用一直调用都不行，导致支付服务也资源也占用完了服务也挂了，那么这条链路上的服务都不能用了，就造成了级联失败的问题）

1.1.2：异步通讯

异步调用则可以避免上述问题：

我们以购买商品为例，用户支付后需要调用订单服务完成订单状态修改，调用物流服务，从仓库分配响应的库存并准备发货。

在事件模式中，支付服务是事件发布者（publisher），在支付完成后只需要发布一个支付成功的事件（event），事件中带上订单id。

订单服务和物流服务是事件订阅者（Consumer），订阅支付成功的事件，监听到事件后完成自己业务即可。

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

好处：

• 耦合度极低，每个服务都可以灵活插拔，可替换（就像项目经理说在支付服务里面再添加一个积分服务，在同步通讯的场景下你还需要在支付服务里面添加代码去调用积分服务。在异步通讯的场景下就不需要了，为什么呢？因为现在支付服务不负责调用自己的子服务，有用户下支付了，支付服务只需要发布一个成功事件到Broker中，Broker拿着喇叭喊一下哪个订单支付了，其关联的服务只需要订阅一下事件，做自己的事就好了，支付服务压根就不管了，或者说产品经理说短信真贵，不让发了只需要取消订阅短信服务就ok了也不需要删除代码，这样就大大的降低了耦合度。）

• 吞吐量提升：无需等待订阅者处理完成，响应更快速（这样理解在同步通讯的时候，整个完成的工程需要累加起来也就是500ms，而现在异步通讯就不需要了，当用户发起支付服务，支付动作完成给Borker发布一个事件信息，直接就返回给用户，整个流程下来也就60ms，效率提高，吞吐量也大大提升。而不需要等待订阅者服务处理完成后返回，像（订单服务，仓储服务）它做多久都和支付服务没什么关系，只要最后完成就行。）

• 故障隔离：服务没有直接调用，不存在级联失败问题（这个这样理解，你就假如仓储服务挂了出故障了，在同步通讯中极有可能出现级联失败。在异步通讯中就可以避免这种问题，用户支付完成之后，支付服务发布个事件就成功返回了，Borker拿个喇叭一喊这些服务都来订阅，结果仓储服务挂了出现故障了，那没事我修修这个仓储服务，反正支付服务已经成功了也不会造成堵塞，不存在调用关系）

• 调用间没有阻塞，不会造成无效的资源占用（在同步通讯操作中一个服务在进行中，其他服务就静静的等着造成资源浪费。在异步通讯中，事件订阅后各干各的不会造成无效的资源占用）

• 流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件（这个就是，当大量的用户下单了支付服务，然后支付服务就像发洪水一样发布事件到Broker中，但是呢！假设【订单服务，仓储服务，短信服务】一次只能处理一个，如果大批量的订阅搞不好这些服务有挂机了，所以呢！这时候Borker就化身一个大坝把这些支付服务订单事件都给拦下，保证【订单服务，仓储服务，短信服务】能处理几个处理几个保证正常进行，这样就把并发量高峰降低到趋于平稳。）

缺点：

• 需要依赖于Broker的可靠、安全、性能(相信大家了解完上面的异步通讯的优势已经明显发现异步通讯需要依赖Broker，当然异步通讯虽然好，但也有缺点，你就像异步通讯处理流量削峰，大量的用户支付生成大量的事件交给了Broker，万一Borker没有抗住压力崩了怎么办呢！就像洪水来了大坝没有建好直接轰然倒塌了，这还能玩吗？所以昂这就是存在的第一个问题就是对Broker的性能，安全，可靠要求很高)

• 架构复杂了，业务没有明显的流程线，不好管理（第二个问题就是使用异步通讯服务之间的调用问题不在那么清晰明了，你发布了一个事件，但是你并不知道这个事件是哪个服务处理的，这种调用链不清晰，就导致以后出了问题，不容易进行排查问题所在。）

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