服务与服务间的调用方式分为两种同步调用、异步调用。同步调用可以理解为A打电话给B，需要实时响应，异步调用类似A给B发送邮件，B不需要马上回复。这两种调用方式应该说都有的优缺点。但是在面对一个高并发吞吐量的系统，异步方式比同步方式可以大大增加系统的吞吐量。A,B,C,E 可以同时给F发送邮件，F可以不在线，不用立即回复。对于服务化后服务与服务之间的调用也类似这样一个原理。同步调用虽然只是耦合外部接口，实时性上会高于异步调用，但是会带来很多的问题。
1.调用方的吞吐量受限于被调用方的吞吐量，一旦某个服务响应特别慢，那么整个调用链的性能都会受到影响。
2.同步调用会导致线程被阻塞，你想想当一个调用需要等待另外一个服务响应回来时，相当于线程被阻塞在哪里，服务的线程资源是很可观，我们用户可以有成千上万个，但是我们服务器缺不允许启动1w个线程。这样会导致整个系统的性能都耗费在等待返回结果的这一个过程中。
3.服务与服务之间的调用只能是1对1的关系，想要做到一对多是很困难的。
4.被调用方一定失败，会导致服务发起方也跟着失败，从而引起雪崩的问题。
异步调用相对于同步调用来说，虽然在理想的情况下请求响应时间会慢与同步调用，但是可以加大系统的吞吐量，还可以简化系统与系统之间的耦合性，即使被调用方宕机了也不影响业务发起方。
在资源服务器有限的情况下，在针对大促的时候可以，异步调用的模式把一些非关键的服务器挪作他用，例如用户下单成功后通知物流系统，发送下单成的消息这些服务全部停止掉，挪给订单服务器使用。因为这些服务直接停了也不会影响系统的正常下单逻辑。我们只需要保存好这些消息，当系统不那么繁忙的时候在把之间挪作他用的服务器在重新启动回来，这样下单成功通知、物流通知系统又可以恢复正常的流转。当然异步调用的好处远不止以上说的这些，什么样的场景适合这类方式，还需要大家多多的思考，不知道大家有没了解过saga，异步调用的最终模型其实就是saga（服务编排），这里面其实也并不是否定同步调用的不好，同步从整个理解逻辑上来说是很直观的。如果一个系统里面所有的通讯都走异步其实也是很恐怖的他的代价其实也是蛮大的，所以应用异步应该在系统的瓶颈位置上，领域边界上，而不是所有的调用都是异步，这样的开发量太大了，得不偿失。又或者我们的系统压根就是一个简单的管理系统，要求没那么高，同步的模型也是ok的，因地制宜，什么马配什么鞍，一定要给捷达增加一个法拉利V8的引擎不是不行，适合自己的项目，适合的场景才是追重要的。