你好，我是陈浩网名做耳朵耗子。

在前面的课程中呢，我所说的隔离设计啊，通常都需要对系统做解耦设计，而把一个单体系统做解耦，不单单是要把业务功能拆分出来。

正如前面所说，拆分完之后呢，还会面对很多的问题。

那其中一个重要的问题呢，就是这些系统间的通讯。

那通讯一般来说呢分同步和异步两种，同步，通讯呢就想打电话需要实时响应。

而异步通讯呢就像发邮件啊，不需要马上回复，这两者各有千秋啊，我们很难说谁比谁好。

但是呢在面对超高吞吐量的场景下，异步处理呢就比同步处理有比较大的优势了。

啊，这就好像一个人不可能同时接打很多的电话，但是他可以同时接收很多的电子邮件一样同步调用呢。参考资料:https://51gx.top/detail/264

虽然让系统间只耦合于接口，而且实时性呢也会比异步调用要高。

但是我们也需要知道，同步调用呢会带来以下的几个问题。

那第一个问题呢就是同步调用需要被调用方的吞吐，不低于调用方的吞吐，否则呢就会导致被调用方因为性能不足而拖死调用方。

那换句话说呢，就是整个同步调用电的性能啊，会由最慢的那个服务所决定。

那第二呢就是同步调用啊，会导致调用方一直在等待被调用方完成。

那如果一层接一层的同步调用下去，所有的参与方都会有相同的等待时间。

那这样呢会非常消耗调用方的资源，因为调用方需要保存现场等待远端返回。

所以对于病发比较高的场景来说呢，这样的等待啊可能会极度消耗资源。

呃，第三呢同步调用只能是一对一的，很难做到一对多。

最后一个问题啊，也就是同步调用最不好的一个问题，就是如果被调用方有问题，那么调用方呢就会跟着出问题。

于是呢就会出现多米诺骨牌效应，故障一下就蔓延开来。

所以呢异步通讯相对于同步通讯来说，除了可以增加系统的吞吐量之外呢，最大的一个好处呢是它可以让服务间的解耦更为彻底。

服务的调用方和被调用方可以按照自己的速率，而不是步调一致啊，从而可以更好的保护系统，让系统更有弹力。

那异步通讯通常来说呢，有三种方式，那第一种方式呢是请求响应式。

在这种情况下呢，发送方会直接请求接受方。

那被请求方接收到请求之后呢，会直接返回收到请求，正在处理这类的信息。

那对于返馈结果呢有两种方法，一种呢是发送方，时不时的去轮询一下啊，问一下干没干完。

那另一种方式呢是发送方注册一个回调方法啊，也就是让接收方处理完之后呢，回调给请求方。

那这种架构模型呢在以前的网上支付中啊比较常见页面，先从商家跳转到支付宝或者银行。

那商家呢会把回调的UIL传给支付页面。

那支付完成之后呢，再跳转回商家的URL.那很明显这种情况下呢，还是有一定的耦合的。

发送方呢要依赖于接收方，并且呢要把自己的回调发送给接收方。

处理完成之后呢，再回调异步通讯的。

第二种方式呢是通过订阅的方式，在这种情况下呢接收方会来订阅发送方的消息。

那发送方呢会把相关的消息或者数据放到接收方所订阅的队列中，而接收方呢会从队列中来获取数据。

在这种方式下呢，发送方并不关心订阅方的处理结果啊，他只是告诉订阅方有事情要干，收完消息之后给个ACK就可以了。

你干成啥样？我不关心。

那这个方式呢常用于像MVC这样的设计模式里啊，我在文中呢给你画了一张图，你可以看一看。

那这个呢就好像是在下订单的时候，一旦用户支付完成了，那就需要把这个事件啊通知给订单处理和物流订单处理变更状态。

而物流服务呢需要从仓库服务分配相应的库存，并准备配送。

那后续这些处理的结果呢，无需告诉支付服务。

那为什么要做成这样呢？好了，重点来了，前面那种请求响应的方式啊，就像函数调用一样。

那这种方式呢有数据有状态的往来，也就是说需要请求数据返回数据。

那服务里面呢还可能需要保存调用的状态，所以呢这个服务是有状态的那如果我们把服务的状态给去掉，那么服务间的依赖啊就只有事件了。

你要知道分布式系统的服务设计呢是需要向无状态服务努力的这其中啊有太多的好处了无状态，就意味着你可以非常方便的运维。

所以事件通讯呢就成为了异步通讯中最重要的一个设计模式。

在前面支付的那个例子中呢，商家这边只需要订阅一个支付完成的事件。

那这个事件呢带一个订单号，他不需要让支付方知道自己的回调的UL.那这样的异步是不是更干净一些呢？但是呢在这种方式下，接收方需要向发送方订阅事件，所以呢是接收方依赖于发送方。

那这种方式呢还是有一定的耦合，所以呢就有了异步通讯的第三种方式，通过broker的方式。

那所谓broker呢，就是一个中间人发送方和接收方都互相看不到对方，他们能看到的是一个broker.那发送方向broker发送消息，接收方呢向broker订阅消息。

那文中呢有一张图展示了这个流程，那这个呢就是完全的解耦了，所有的服务呢都不需要相互依赖，而是依赖于一个中间件broker.那这个broker呢是一个像数据总线一样的东西，所有的服务呢要接收数据和发送数据啊都发到这个总线上。

那这个总线啊就像协议一样，让服务间的通讯啊变得标准和可控。

在broker这种模式下，发送方的服务和接收方的服务，最大程度的结耦了。

但是所有的人啊都依赖于一个总线，所以这个总线呢就需要有这样几个特性。

那第一呢必须是高可用的，因为它成了整个系统的关键。

那第二呢必须是高性能，而且啊是可以水平扩展的那第三呢必须是可以持久化，不丢数据的那要做到这三条啊还是比较难的那当然呢好在现在开源软件或者云平台上broker的软件是非常成熟的，所以呢也节省了我们很多的精力。

那前面讲的第二种和第三种方式就是比较著名的事件驱动架构。

正如前面所说，事件驱动啊最好是使用broker的方式服务间，通过交换消息来完成交流和整个流程的驱动。

那再来看一看文中这张图，那这个呢是一个订单处理流程，下单服务通知，订单服务有订单要处理。

而订单服务生成订单之后呢，发出通知，库存服务和支付服务得到通知之后呢，一边是占着库存，另一边呢是让用户支付等待用户支付完成之后啊，通知配送服务进行商品的配送。

那整个流程中的每个服务呢都是自包含的。

所谓自包含呢，也就是没有和别人产生依赖，而要把整个流程给串联起来呢，我们需要一系列的消息通道，各个服务做完自己的事儿之后呢，发出相应的事件，而又有一些服务在订阅着某些事件来联动。

那事件驱动方式的好处呢至少有这么几个。

那第一呢服务间的依赖没有了，服务间是平等的，每一个服务呢都是高度可乘用啊，并且可替换的那第二呢，服务的开发测试、运维和故障处理啊都是高度隔离的那第三呢服务间通过事件来关联，所以服务间呢不会相互的block.那第四呢在服务之间增加一些adapter会相当的容易。

那还有一个好处呢，就是服务间的吞吐啊也被解开了。

那各个服务呢可以按照自己的处理速度来处理。

我们知道任何设计呢都有好有不好。

那事件驱动的架构呢也会有一些不好的地方，那首先呢就是业务流程不再那么明显，好管理。

那整个架构呢会变得比较复杂。

而解决这个问题呢，需要有一些可视化的工具来呈现整体业务流程。

那其次呢事件可能会乱序，那这个呢会带来非常bug的事儿。

要解决这个问题呢，需要很好的管理，一个状态机的控制。

那另外呢事务处理会变得复杂啊，需要使用两阶段提交来做强一致性，或者退缩到最终一致性。

最后呢我们来讲一讲异步通讯的设计重点。

首先呢我们需要知道为什么要异步通讯，那主要呢有这么几个原因。

那第一呢异步通讯最重要的是解耦服务间的依赖。

那最佳的解耦方式呢是通过broker的机制。

那第二呢解耦的目的是让各个服务的隔离性更好。

那这样呢不会出现一导倒一片的故障。

那第三呢，异步通讯的架构可以获得更大的吞吐量，而且各个服务间的性能不受干扰，相对独立。

那第四呢利用broker或者队列的方式，还可以实现把抖动的吞吐量变成均匀的吞吐量。

那这个呢就是所谓的萧峰，这对后端系统啊是个不错的保护。

那最后一点，异步通讯的服务相对独立，在部署扩容和运维上啊，都可以做到独立，不受其他服务的干扰。

但我们需要知道这样的方式带来的问题。

所以在设计成异步通信的时候呢，我们需要注意一些事情。

呃，首先呢用于异步通讯的中间件broker就成为了关键需要设计成高可用不丢消息的。

另外呢因为是分布式的，所以可能很难保证消息的顺序。

所以你的设计呢最好不要依赖于消息的顺序。

那其次呢，异步通讯会导致业务处理流程不那么直观。

因为像接力一样，所以在broker上面呢需要有相关的服务消息跟踪机制，否则出现问题了，不容易调试。

那另外呢因为服务间只通过消息来交互，所以业务状态呢最好由一个总控方来管理。

那这个总控方呢维护一个业务流程的状态变迁逻辑，以便在系统发生故障之后啊，知道业务处理到了哪一步，从而可以在故障清除后继续处理。

那这样的设计在银行的对账程序里啊比较常见。

那银行系统里呢会有大量的外部系统通讯，比如跨行的交易，跨企业的交易啊等等。

所以呢为了保证整体数据的一致性啊，或者避免漏处理，或者处理错的交易，需要有对账系统。

那这个呢其实就是那个总控。

那这个呢也是为什么银行有的交易是t加一隔天结算啊，就是因为要对个账，确保数据是对的那最后需要注意的是在消息传递中呢，可能有的业务逻辑会有像TCP协议那样的send和ACK机制。

比如a服务发出了一个消息之后啊，开始等待处理方的ACK.那如果等不到的话，就需要做重传。

那这个时候就需要处理方有密等的处理，就是同一件消息，无论收到多少次啊，都只处理一次。

好了，我们来总结一下今天分享的主要内容。

那首先呢同步调用有四个问题，影响吞吐量消耗系统资源只能一对一啊，还有多米诺骨牌效应。

于是呢我们想用义务调用来避免这些问题。

那异步调用呢有三种方式，包括请求响应、直接订阅和中间人订阅。

在最后呢我介绍了事件驱动设计的特点和异步通讯设计的重点。

在下节课中呢我们会讲述密等型设计啊，希望对你有帮助。

也欢迎你分享一下你在分布式服务的设计中哪些情况下会使用异步通讯啊，是怎样设计的，又有哪些情况使用同步通讯呢？文末，我给出了分布式系统模式系列文章的目录啊，希望你能在这个列表里找到自己感兴趣的内容。