(3)弹力设计篇之“异步通讯设计”

异步三种方式：请求响应、直接订阅和中间人订阅。

事件驱动设计的特点

异步通讯设计的重点。

一、异步通讯的三种方式

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，如果等不到的话，就需要做重传。需要幂等的处理。