!!! 本文已参与「新人创作礼」活动，一起开启掘金创作之路。更多干货文章，可以访问 菜鸟厚非

介绍

同步通讯与异步通讯属于微服务调间用的两种方式，其两种方式会应用于不同的场景，使用的合理可以是系统性能翻倍增长。

同步

同步调用是在某个服务调用后，会之间调用其他服务，在此之间会之间等待所以的服务完成调用，这几就是同步调用。

缺点

1. 耦合性 有一个很神奇的生物，叫做产品经理，经常脑洞大开。有时候开发人员觉得，已经开发完了没有问题了，但这个是产品经理总觉缺点什么，加个短信吧。这时，你就得加个发短信的业务，就得在支付服务里改动代码添加，发短信代码。假如说有一天添加了优惠价的功能，支付后是不是的扣除响应的优惠，你以为到这就结束了，加个积分系统，促使他下次还来买。等等这样需求该来该去谁受的了，所以呢这就是耦合性。

2. 性能下降 当支付服务耗时 50 ms、订单服务耗时 150ms等，那么支付整个动作耗时就是加起来的总和。当大量的并发进来了，系统抗的住吗，这个就是性能下降吞吐量也下降。

3. 资源浪费 当进行支付服务完成后，调用订单服务、仓库服务、休息服务，此事支付服务就在干等着啥也不干，也会一直占用着系统资源。当请求少了还没什么，当请求多了十万、百万等。这就是资源的利用率，资源浪费。

4. 级联失败 当用支付同步调用时，如果我们的仓促服务抗不住这么大的并发，就会对后面的请求造成阻塞，一两等多了之后，就会对支付服务造成系统异常，影响正常业务，出现系统bug。这就是级联失败问题。

总结

所以综上所述，虽然同步调用有着很高的时效性，但也会带来各种各样的问题。任何技术都有自己的优点与缺点，在合适的场景下使用，即是最合理的。

异步

上面讲解了同步调用，它存在着众多的不足。可以使用异步调用进行解决，但异步也不是完美的，它也有着对应的缺点。

异步调用的实现方式，最常用的就是事件驱动。

记得上面将的同步调用吧，支付服务调用之后，会调用订单等，支付一直会等待着直到全部服务完成调用。而异步是支付服务支付成功后，发布一个事件，之后立马返回结果给用户。

说到这可能有人会问，那其他服务不调用了吗？不，当然调用，记得支付成功后发布的事件吧

其他的服务会订阅这个事件，从而触发一系列的服务调用。

优点

1. 服务解耦 如果有一天产品经理，想添加一个积分功能，之需要添加积分服务模块，订阅事件即可。 如果有一天产品经理觉得短信成本有点高，想去掉，此时将短信服务取消订阅即可。

这两种情况，不像同步时，去更改支付服务里面的代码对吧。这就是服务解耦。

2. 性能提升，吞吐量提高 异步调用时，此时我们的总耗时已经不再是所有的服务总和，而是支付服务+发布事件耗时 60 ms。至于其他服务调用及每个服务抗并发的能力等会根据自身进行消费处理。这样就提升了吞吐量，系统的性能也得到的提升。

3. 没有强依赖关系，没有级联问题 异步调用，当仓储服务异常时，只是这一个服务异常，没有影响支付服务。因为支付完成后，发布个事件，没有像同步一样调用仓储服务，会应为仓储服务异常，而导致支付服务失败。

4. 流量削峰

当只有一个用户请求时，支付服务、订单服务、仓储服务、短信服务可以进行快速的请求。

突然，有大量用户支付，一下子来个三个甚至更多，如果我们的擦仓储服务处理并发只能处理两个，那么borker就会给他两个，处理完成后会再向，borker进行拿取根据自身的消费能力进行处理。

如果使用同步，三个甚至更多一下子给到仓储服务，此时仓储服务会因为并发而系统异常，从而导致支付服务失败。不能处理后边的并发请求。

异步情况下，borker就像一个大坝一样拦着，起到一个缓冲左右，订单、仓储等根据自身能进行处理。所以这就是流量削峰。比如秒杀系统经常这样使用架构。

缺点

看完了优点，可能有的同学会发现，无论是解耦。流量削峰等都依赖了 borker。

如果说在并发情况下扛不住那么高的并发 borker 挂了，此时系统是不是就瘫痪了，所以们对 borker 有着极高的可用性及并发性的要求。日常使用的有 kafka、rabbitMQ 。

使用场景

如果说在支付完成后，需要使用等待其他服务调用的结果，这必须得用同步，因为异步只是通知去做事件，支付成功后，其他服务接口支付服务不知道不清楚。

如果对之后的结果，我不需要知道而且对并发要求高、吞吐量要求高、还需解除之间的耦合，这样就的使用异步。