服务和服务之间的调用方法有两种：同步调用和异步调用。 同步呼叫可以理解为a需要给b打电话并实时应答。 异步调用就像a向b发送邮件，b不需要立即回复。 这两种调用方法都应该有优缺点。 然而，在并发吞吐量较高的系统中，异步方案可以比同步方案大大提高系统吞吐量。 A、b、c、e可以同时向f发送邮件，f可以不在线，也可以不立即回复。 关于服务器化的服务器和服务器之间的调用也有这样的原理。 同步调用只是结合外部接口，比异步调用的实时性更高，但也会带来很多问题。
1 .调用方的吞吐量受限于调用方的吞吐量，如果某个服务器响应非常慢，整个调用链的性能将受到影响。
2 .同步调用会阻止线程。 想想如果一个调用需要等待来自另一个服务器的响应，线程将被阻止的地方。 服务器的线程资源非常大，我们的用户可以有上千个，但是我们的服务器不允许启动1w的线程。 在等待结果返回的过程中，系统整体性能会下降。
3 .服务与服务之间的调用只是一对一的关系，很难做到一对多。
4 .被叫方一定会失败，服务发起方也会失败，引起雪崩问题。
相对于同步调用，异步调用的请求响应时间理想情况下较慢，并且是同步调用，但它可以提高系统吞吐量，简化系统之间的耦合，并且在调用方关闭时不会影响业务启动器。
在资源服务器有限的情况下，为了实现大规模的加速，异步调用的模型会重新使用不重要的服务器，例如在用户成功下单后通知物流系统，停止所有发送订单消息的服务，然后移动到订单服务器。 因为直接停止这些服务不会影响系统的正常订购逻辑。 我们只需要保存好这些信息，在系统不太忙的时候，间转给他用的服务器就会重新启动回来，订单成功通知、物流通知系统就能恢复正常流程。 当然，异步调用的好处不仅仅是上面提到的那些。 什么样的场面适合这种方式，很多人都需要考虑。 我不知道大家是否知道saga，但是异步调用的最终模型实际上是saga (服务组织)。 其中，其实并不否认同步调用不好，从整个理解逻辑来看，同步是直观的。 如果一个系统中所有的通信都异步了，其实很可怕。因为他付出的代价其实也很大。APP间的异步应该是所有的呼叫都不同步，而是在系统瓶颈的位置、领域的边界上，这样的开发量太大，填补了损失或者，我们的系统是简单的管理系统，要求不是很高，同步的模式也可以。 适合不同地区，什么样的马配什么样的马鞍，捷豹就得增加法拉利V8的发动机，这不是不行，适合自己的项目、适合的场景很重要。