异步通讯设计
前面所说的隔离设计通常都需要对系统做解耦设计，而把一个单体系统解耦，不单单是把业务功能拆分出来，正如上面所说，拆分完后还会面对很多的问题。其中一个重要的问题就是这些系统间的通讯。
通讯一般来说分同步和异步两种。同步通讯就像打电话，需要实时响应，而异步通讯就像发邮件，不需要马上回复。各有千秋，我们很难说谁比谁好。但是在面对超高吐吞量的场景下，异步处理就比同步处理有比较大的优势了，这就好像一个人不可能同时接打很多电话，但是他可以同时接收很多的电子邮件一样。
异步不一定是多线程！！！，如akka的信箱，它异步可以把消息重新发到自己的信箱，但还是单线程的
但异步也不是完全的好，时延还是不如同步的
但同步有以下问题的
- 同步调用需要被调用方的吞吐不低于调用方的吞吐。否则会导致被调用方因为性能不足而拖死调用方。换句话说，整个同步调用链的性能会由最慢的那个服务所决定，发送方会被接收方限制死。
- 同步调用会导致调用方一直在等待被调用方完成，如果一层接一层地同步调用下去，所有的参与方会有相同的等待时间。这会非常消耗调用方的资源（因为调用方需要保存现场（Context）等待远端返回，所以对于并发比较高的场景来说，这样的等待可能会极度消耗资源）。还是那句话，发送方会被接收方限制死
- 接受发崩了，发送方也得跟着崩
- 很难做到一对多，跟打电话一样，注意不是微信电话 狗头
所以，异步比同步好的原因，除了提高调用方的吞吐量，最大的一个好处是其可以让服务间的解耦更为彻底，系统的调用方和被调用方可以按照自己的速率而不是步调一致，从而可以更好地保护系统，让系统更有弹力
异步通信几种方式
请求响应式
这种模式下，调用方直接请求被调用方，然后被调用方回复—收到，正在处理
一般分为两种模式，一种是调用方去轮询询问干没干哦。还有一种是调用方写个回调方法，然后被
调用方处理好请求后通过这个方法回调，游戏支付领域就是这么干的，支付完成后支付中台会回调
游戏服务端，前端回调的这个http / rpc 接口游戏服务端会交给支付中台。
但以上两种还是会有一定耦合的
订阅方式
pub/sub，各个服务之间依靠事件交互，但接收方还是依赖于发送方
服务肯定是无状态好，运维会方便很多
broker模式
即消息中间件
这种模式就做到了发送和接受完全解耦
但你broker要做到三高，高性能，高可靠，高可用
事件驱动架构
订阅和broker其实都是事件驱动架构
正如前面所说，事件驱动最好是使用 Broker 方式，服务间通过交换消息来完成交流和整个流程的驱
动。
例如：
好处就是 运维测试很容易，故障不容易扩散，服务治理比较容易，吞吐量互不影响
但任何技术都有它不好的一面
可观察性变差了
:::color4
ps：NIO/Epoll + Eventloop 本身就是事件驱动的设计
:::
总结
首先为什么要有异步通信
异步通信需要注意哪些地方
好了，我们来总结一下今天分享的主要内容。首先，同步调用有四点问题：影响吞吐量、消耗系统资
源、只能一对一，以及有多米诺骨牌效应。于是，我们想用异步调用来避免该问题。异步调用有三种
方式：请求响应、直接订阅和中间人订阅。最后，我介绍了事件驱动设计的特点和异步通讯设计的重点