异步三种方式：请求响应、直接订阅和中间人订阅。
事件驱动设计的特点
异步通讯设计的重点。
一、异步通讯的三种方式
1.请求响应式
发送方（sender）会直接请求接收方（receiver），直接返回——收到请求，正在处理。返回结果两种方法：
（1）发送方轮询一下，问干没干完。
（2）发送方注册回调方法，接收方处理完后回调请求方。
以前的网上支付中常见，页面先从商家跳转到支付宝或银行，商家会把回调的 URL 传给支付页面，支付完再跳转回商家的 URL。这种情况下有一定耦合的。发送方依赖于接收方，把自己的回调发送给接收方，处理完后回调。
2.通过订阅的方式
接收方（receiver）会来订阅发送方（sender）的消息，发送方会把相关的消息或数据放到接收方所订阅的队列中，而接收方会从队列中获取数据。发送方并不关心订阅方的处理结果，它只是告诉订阅方有事要干，收完消息后给个ACK 就好了，你干成啥样我不关心。这个方式常用于像 MVC设计模式下，如下图所示。
这就好像下订单的时候，一旦用户支付完成了，需要把这个事件通知给订单处理以及物流，订单处理变更状态，物流服务需要从仓库服务分配相应的库存并准备配送，后续这些处理的结果无需告诉支付服务。
为什么要做成这样？好了，重点来了！前面那种请求响应的方式就像函数调用一样，这种方式有数据有状态的往来（也就是说需要有请求数据、返回数据，服务里面还可能需要保存调用的状态），所以服务是有状态的。如果我们把服务的状态给去掉（通过第三方的状态服务来保证），那么服务间的依赖就只有事件了。接收方依赖于发送方。还是有一定的耦合。
3.通过 Broker 的方式
所谓 Broker，就是一个中间人，发送方（sender）和接收方（receiver）都互相看不到对方，它们看得到的是一个 Broker，发送方向 Broker 发送消息，接收方向 Broker 订阅消息。如下图所示。
完全的解耦。依赖于一个中间件 Broker。这个 Broker是一个像数据总线一样的东西，所有的服务要接收数据和发送数据都发到这个总线上，就像协议一样，让服务间的通讯变得标准和可控。所有人都依赖于一个总线，需要有如下的特性：
(1)高可用的（整个系统的关键）；
(2)高性能（水平扩展）的；
(3)持久化不丢数据的。
要做到这三条还是比较难的。当然，好在现在开源软件或云平台上 Broker 的软件是非常成熟的，所以节省了我们很多的精力。
二、事件驱动设计
上述的第二种和第三种方式就是比较著名的事件驱动架构（EDA – Event DrivenArchitecture）。正如前面所说，事件驱动最好是使用 Broker 方式，服务间通过交换消息来完成交流和整个流程的驱动。
如下图所示，这是一个订单处理流程。下单服务通知订单服务有订单要处理，而订单服务生成订单后发出通知，库存服务和支付服务得到通知后，一边是占住库存，另一边是让用户支付，等待用户支付完成后通知配送服务进行商品配送。
每个服务都是“自包含”的。所谓“自包含”也就是没有和别人产生依赖。而要把整个流程给串联起来，我们需要一系列的“消息通道（Channel）”。各个服务做完自己的事后，发出相应的事件，而又有一些服务在订阅着某些事件来联动。
好处:
服务间依赖没有了，服务间是平等的，每个服务都是高度可重用并可被替换的。
服务的开发、测试、运维，以及故障处理都是高度隔离的。
服务间通过事件关联，所以服务间是不会相互 block 的。
在服务间增加一些 Adapter（如日志、认证、版本、限流、降级、熔断等）相当容易。
服务间的吞吐也被解开了，各个服务可以按照自己的处理速度处理。
不好：
业务流程不再那么明显和好管理。整个架构变复杂。解决这个问题需要有一些可视化的工具来呈现整体业务流程。
事件可能会乱序。这会带来非常 Bug 的事。解决这个问题需要很好地管理一个状态机的控制。
事务处理变得复杂。需要使用两阶段提交来做强一致性，或是退缩到最终一致性。
三、异步通讯的设计重点
为什么要异步通讯？
解耦:最佳通过 Broker 的机制。让各个服务的隔离性更好，这样不会出现“一倒倒一片”的故障。性能不受干扰（服务间的），获得更大的吞吐量。
削峰:利用 Broker 或队列把抖动的吞吐量变成均匀。
设计注意：不受其他服务的干扰,在部署、扩容和运维上都独立。
不依赖于消息的顺序，分布式的很难保证消息的顺序。
服务消息跟踪机制（Broker 上需要），因为业务处理流程不那么直观，因为像接力一样，否则不容易调试。
总控方管理业务状态，因为服务间只通过消息交互，总控方维护状态变迁逻辑，故障后知道处理到了哪一步，可在故障清除后继续处理。（跨行的交易，为了保证整体数据的一致性，有对账系统（总控），银行有的交易是 T+1（隔天结算），就是因为要对账）
消息传递中，可能有的业务逻辑会有像 TCP 协议那样的 send 和 ACK 机制。比如：A 服务
发出一个消息之后，开始等待处理方的 ACK，如果等不到的话，就需要做重传。需要幂等的处理。
评论:
有些业务:下完订单并支付后，用消息通知的方式，立刻流单也不是很好。
一方面可能要等到某个时机才流单，尤其是大促时，用户取消订单的很多。
另外，也想在高峰期优先全部资源搞下单和支付处理，不搞其他，等高峰小一些的时候，才处理售后的一些业务。