前言
提到同步调用和异步调用两者的区别,首先笔者是从微服务间通讯方式角度出发来阐述这两者的区别。
同步通讯
- 调用方需要等待执行方的调用结果。(就像打电话一样,需要实时响应)
- 典型就是:Dubbo的rpc远程过程调用方式

异步通讯
- 调用方无需等待执行方的执行结果 (就像发微信,不需要马上回复)
- 典型就是消息队列(也称消息中间件):MQ
- 目前市场主流的中间件框架有:RabbitMq,RocketMq,Kafka,ActiveMq

这两种方式各有优劣:
- 打电话可以立即得到响应,但是你却不能跟多个人同时通话。
- 发送微信可以同时与多个人收发微信,但是往往响应会有延迟。
同步调用:
优点:时效性强,可以立即得到结果。
缺点: 虽然调用可以实时得到结果。在开发中存在以下问题:

耦合度高:如上图所示如果支付服务需要添加新需求就需要更改原来服务代码,需要重新编译,重新运行。性能下降:支付服务需要等待下边的所有服务方法全部逐次执行完后才算支付服务成功,假如订单服务 仓储服务 短信服务等每个服务都需要150s才能执行完成那么支付服务需要等待的时间链路就过长了。资源浪费:高并发场景下会极度浪费系统资源,假如有A,B,C…等来调用支付服务,A调用支付服务后还没来得及响应,B就来了。所以会迟迟导致其他用户无法调用该服务。调用链中的每个服务等待响应过程中不能释放请求占用的资源。级联失败:如果上图如果服务提供者出现问题那么所有的调用方就会跟着出现问题。
异步调用
异步通讯的出现是为了解决同步通讯所带来的问题,支付网站一般都会使用消息中间件。

服务解耦:
- 用户提交支付服务后,瞬间支付服务会直接提示用户支付成功。然后将订单服务,仓储服务,短信服务,放到中间件(Broker)中。至于中间件中的这三个服务什么时候执行我们不用关心,(Broker)会去同时执行这三个服务。

提升性能:
- 比如:用户支付服务花费时间50ms,支付成功事件花费10ms。此时会将订单服务,仓储服务,短信服务放入(Broker)中,Broker中会同时执行这三个服务总共就用150ms,提升性能。

服务没有强依赖性,不担心级联失败问题
- 各个服务互相隔离,仓储服务出现问题的话不影响其他两个服务。用户正常显示支付成功

流量削峰 - 比如:第一用户提交支付服务后,提示用户支付成功。此时Borker中服务可能会有延迟但是不应影响后边用户过来提交。第二,三个用户逐次提交服务后也会像第一个用户一样提示成功支付。但是Broker它也会按照先后次序去执行每个用户提交的服务。
异步通信总结:
优点:
- 也就是上述四点。耦合度低,提升吞吐量,故障隔离,流量削峰。
缺点:
- 依赖与Broker的可靠性,安全性,吞吐能力
- 架构复杂业务没有明显的流程线,不好追管理。
900

被折叠的 条评论
为什么被折叠?



