为什么需要异步设计
刚开始参加工作，发现有一些API设计中回落数据之后，然后将数据写入到消息队列中，当时很是不理解为什么要这么做，直到后边系统学习消息队列之后才发现原来这其实就是异步处理，当流量很多的时候，可以通过消息队列进行缓存用户请求，后续下游系统根据自身处理水平消费。其实说白了排队设计也大多采用消息队列实现。
另一点就是当系统进行拆分后，系统的通讯就需要评判使用同步还是异步通讯。
同步通讯有点打电话，需要实时响应，而异步通讯类似发邮件，可以异步处理。两种方式各有千秋，但是总的来说，异步方式在处理超高吞吐量的时候更具备优势。
同步调用的问题
- 同步调用需要被调用方的吞吐量不能消息调用方，否则被调用方会拖死调用方。整体同步调用链路由最慢的服务决定。
- 同步调用需要保存现在context，如果调用层级过多，那么比较耗费资源。
- 同步调用只能一对一，而异步可以一对多。
- 同步调用就是 A->B 一旦B系统出现问题，整个链路就会出问题。
异步通讯相比于同步来说 1.可以增加系统的吞吐量 2.系统之间服务的解耦合 3.系统可以按照自己的速率进行处理。
异步通讯的三种方式
请求响应式
请求响应式的，发送方发送请求 接受方进行处理，如果处理时间短的话，可以基于一个请求的响应进行返回数据。这种就是同步方式。
异步的方式的话。一般来说有两种方式，
1.发送方定时去查询接口 查询有没有处理完毕
2.接受方处理完毕后，进行回调通知发送方。
通过订阅的方式
订阅模式就是接收方需要订阅发送方写入的队列，然后进行处理，发送方不需要直到对方处理的结果。
基于请求响应的方式其实是有数据往来，这种服务是有状态的，如果去掉服务的状态那么就只有事件了。
但是这种方式接收方需要订阅发送方的事件。有一定耦合。
通过Broker方式
通过一个中间人，引入一个Broker，发送方和接收方都不需要关心对方的存在
发送方写入消息到Broker，接收方订阅对应的Topic，然后进行消费,进行处理。
Broker需要保证几点
1.需要高可用，所以一般搭建的是一个集群模式。通过冗余来实现。
2.需要高性能，水平拓展。
3.需要持久化数据。
其实就是消息队列，Kafka，Rabbitmq等
异步通讯的设计重点
异步设计带来的好处
- 提升系统的整体吞吐量，系统可以解耦合
- 提高系统之间的隔离性，不会出现一倒倒一片
- 利用Broker可以把抖动的吞吐量变成均匀的吞吐量，削峰。
- 在部署、扩容和运维上可以做到服务不互相干扰
异步设计需要引入一个Broker
- 这个Broker 高可用 （集群模式）高性能，以及消息顺序，消息丢失等问题引入 需要在业务上设计好
- 异步通讯会导致流程上不那么直观，所以在梳理业务流程的时候，需要通过Topic进行梳理上下游系统之间的关系。
- 服务间只通过消息交互，所以业务状态由一个总控方来管理，维护业务流程的状态变迁逻辑。
- 消息传递过程中，TCP那样发送send和ACK机制，所以A服务发出一个消息之后，开始等待处理方的ACK。需要重传机制。以及需要处理方的幂等机制。
小结
本篇主要设计了弹力设计中异步设计的要点，聊了异步设计的好处和坏处 以及异步设计的几种方式请求响应，直接订阅和中间人订阅。
