极客时间已完结课程限时免费阅读

43 | 弹力设计篇之“异步通讯设计”

43 | 弹力设计篇之“异步通讯设计”-极客时间

43 | 弹力设计篇之“异步通讯设计”

讲述:杨超

时长13:00大小11.88M

你好,我是陈皓,网名左耳朵耗子。
前面所说的隔离设计通常都需要对系统做解耦设计,而把一个单体系统解耦,不单单是把业务功能拆分出来,正如前面所说,拆分完后还会面对很多的问题。其中一个重要的问题就是这些系统间的通讯。
通讯一般来说分同步和异步两种。同步通讯就像打电话,需要实时响应,而异步通讯就像发邮件,不需要马上回复。各有千秋,我们很难说谁比谁好。但是在面对超高吞吐量的场景下,异步处理就比同步处理有比较大的优势了,这就好像一个人不可能同时接打很多电话,但是他可以同时接收很多的电子邮件一样。
同步调用虽然让系统间只耦合于接口,而且实时性也会比异步调用要高,但是我们也需要知道同步调用会带来如下几个问题。
同步调用需要被调用方的吞吐不低于调用方的吞吐。否则会导致被调用方因为性能不足而拖死调用方。换句话说,整个同步调用链的性能会由最慢的那个服务所决定。
同步调用会导致调用方一直在等待被调用方完成,如果一层接一层地同步调用下去,所有的参与方会有相同的等待时间。这会非常消耗调用方的资源。因为调用方需要保存现场(Context)等待远端返回,所以对于并发比较高的场景来说,这样的等待可能会极度消耗资源。
同步调用只能是一对一的,很难做到一对多。
同步调用最不好的是,如果被调用方有问题,那么其调用方就会跟着出问题,于是会出现多米诺骨牌效应,故障一下就蔓延开来。
所以,异步通讯相对于同步通讯来说,除了可以增加系统的吞吐量之外,最大的一个好处是其可以让服务间的解耦更为彻底,系统的调用方和被调用方可以按照自己的速率而不是步调一致,从而可以更好地保护系统,让系统更有弹力。
异步通讯通常来说有三种方式。

异步通讯的三种方式

请求响应式

在这种情况下,发送方(sender)会直接请求接收方(receiver),被请求方接收到请求后,直接返回——收到请求,正在处理。
对于返回结果,有两种方法,一种是发送方时不时地去轮询一下,问一下干没干完。另一种方式是发送方注册一个回调方法,也就是接收方处理完后回调请求方。这种架构模型在以前的网上支付中比较常见,页面先从商家跳转到支付宝或银行,商家会把回调的 URL 传给支付页面,支付完后,再跳转回商家的 URL。
很明显,这种情况下还是有一定耦合的。是发送方依赖于接收方,并且要把自己的回调发送给接收方,处理完后回调。

通过订阅的方式

这种情况下,接收方(receiver)会来订阅发送方(sender)的消息,发送方会把相关的消息或数据放到接收方所订阅的队列中,而接收方会从队列中获取数据。
这种方式下,发送方并不关心订阅方的处理结果,它只是告诉订阅方有事要干,收完消息后给个 ACK 就好了,你干成啥样我不关心。这个方式常用于像 MVC(Model-View-Control)这样的设计模式下,如下图所示。
这就好像下订单的时候,一旦用户支付完成了,就需要把这个事件通知给订单处理以及物流,订单处理变更状态,物流服务需要从仓库服务分配相应的库存并准备配送,后续这些处理的结果无需告诉支付服务。
为什么要做成这样?好了,重点来了!前面那种请求响应的方式就像函数调用一样,这种方式有数据有状态的往来(也就是说需要有请求数据、返回数据,服务里面还可能需要保存调用的状态),所以服务是有状态的。如果我们把服务的状态给去掉(通过第三方的状态服务来保证),那么服务间的依赖就只有事件了。
你知道,分布式系统的服务设计是需要向无状态服务(Stateless)努力的,这其中有太多的好处,无状态意味着你可以非常方便地运维。所以,事件通讯成为了异步通讯中最重要的一个设计模式。
就上面支付的那个例子,商家这边只需要订阅一个支付完成的事件,这个事件带一个订单号,而不需要让支付方知道自己的回调 URL,这样的异步是不是更干净一些?
但是,在这种方式下,接收方需要向发送方订阅事件,所以是接收方依赖于发送方。这种方式还是有一定的耦合。

通过 Broker 的方式

所谓 Broker,就是一个中间人,发送方(sender)和接收方(receiver)都互相看不到对方,它们看得到的是一个 Broker,发送方向 Broker 发送消息,接收方向 Broker 订阅消息。如下图所示。
这是完全的解耦。所有的服务都不需要相互依赖,而是依赖于一个中间件 Broker。这个 Broker 是一个像数据总线一样的东西,所有的服务要接收数据和发送数据都发到这个总线上,这个总线就像协议一样,让服务间的通讯变得标准和可控。
在 Broker 这种模式下,发送方的服务和接收方的服务最大程度地解耦。但是所有人都依赖于一个总线,所以这个总线就需要有如下的特性:
必须是高可用的,因为它成了整个系统的关键;
必须是高性能而且是可以水平扩展的;
必须是可以持久化不丢数据的。
要做到这三条还是比较难的。当然,好在现在开源软件或云平台上 Broker 的软件是非常成熟的,所以节省了我们很多的精力。

事件驱动设计

上述的第二种和第三种方式就是比较著名的事件驱动架构(EDA – Event Driven Architecture)。正如前面所说,事件驱动最好是使用 Broker 方式,服务间通过交换消息来完成交流和整个流程的驱动。
如下图所示,这是一个订单处理流程。下单服务通知订单服务有订单要处理,而订单服务生成订单后发出通知,库存服务和支付服务得到通知后,一边是占住库存,另一边是让用户支付,等待用户支付完成后通知配送服务进行商品配送。
每个服务都是“自包含”的。所谓“自包含”也就是没有和别人产生依赖。而要把整个流程给串联起来,我们需要一系列的“消息通道(Channel)”。各个服务做完自己的事后,发出相应的事件,而又有一些服务在订阅着某些事件来联动。
事件驱动方式的好处至少有五个。
服务间的依赖没有了,服务间是平等的,每个服务都是高度可重用并可被替换的。
服务的开发、测试、运维,以及故障处理都是高度隔离的。
服务间通过事件关联,所以服务间是不会相互 block 的。
在服务间增加一些 Adapter(如日志、认证、版本、限流、降级、熔断等)相当容易。
服务间的吞吐也被解开了,各个服务可以按照自己的处理速度处理。
我们知道任何设计都有好有不好的方式。事件驱动的架构也会有一些不好的地方。
业务流程不再那么明显和好管理。整个架构变得比较复杂。解决这个问题需要有一些可视化的工具来呈现整体业务流程。
事件可能会乱序。这会带来非常 Bug 的事。解决这个问题需要很好地管理一个状态机的控制。
事务处理变得复杂。需要使用两阶段提交来做强一致性,或是退缩到最终一致性。

异步通讯的设计重点

首先,我们需要知道,为什么要异步通讯。
异步通讯最重要的是解耦服务间的依赖。最佳解耦的方式是通过 Broker 的机制。
解耦的目的是让各个服务的隔离性更好,这样不会出现“一倒倒一片”的故障。
异步通讯的架构可以获得更大的吞吐量,而且各个服务间的性能不受干扰相对独立。
利用 Broker 或队列的方式还可以达到把抖动的吞吐量变成均匀的吞吐量,这就是所谓的“削峰”,这对后端系统是个不错的保护。
服务相对独立,在部署、扩容和运维上都可以做到独立不受其他服务的干扰。
但我们需要知道这样的方式带来的问题,所以在设计成异步通信的时候需要注意如下事宜。
用于异步通讯的中间件 Broker 成为了关键,需要设计成高可用不丢消息的。另外,因为是分布式的,所以可能很难保证消息的顺序,因此你的设计最好不依赖于消息的顺序。
异步通讯会导致业务处理流程不那么直观,因为像接力一样,所以在 Broker 上需要有相关的服务消息跟踪机制,否则出现问题后不容易调试。
因为服务间只通过消息交互,所以业务状态最好由一个总控方来管理,这个总控方维护一个业务流程的状态变迁逻辑,以便系统发生故障后知道业务处理到了哪一步,从而可以在故障清除后继续处理。
这样的设计常见于银行的对账程序,银行系统会有大量的外部系统通讯,比如跨行的交易、跨企业的交易,等等。所以,为了保证整体数据的一致性,或是避免漏处理及处理错的交易,需要有对账系统,这其实就是那个总控,这也是为什么银行有的交易是 T+1(隔天结算),就是因为要对个账,确保数据是对的。
消息传递中,可能有的业务逻辑会有像 TCP 协议那样的 send 和 ACK 机制。比如:A 服务发出一个消息之后,开始等待处理方的 ACK,如果等不到的话,就需要做重传。此时,需要处理方有幂等的处理,即同一条消息无论收到多少次都只处理一次。

小结

好了,我们来总结一下今天分享的主要内容。首先,同步调用有四个问题:影响吞吐量、消耗系统资源、只能一对一,以及有多米诺骨牌效应。于是,我们想用异步调用来避免该问题。
异步调用有三种方式:请求响应、直接订阅和中间人订阅。最后,我介绍了事件驱动设计的特点和异步通讯设计的重点。下节课,我们讲述幂等性设计。希望对你有帮助。
也欢迎你分享一下你在分布式服务的设计中,哪些情况下使用异步通讯?是怎样设计的?又有哪些情况使用同步通讯?
文末给出了《分布式系统设计模式》系列文章的目录,希望你能在这个列表里找到自己感兴趣的内容。
分享给需要的人,Ta购买本课程,你将得29
生成海报并分享

赞 17

提建议

上一篇
42 | 弹力设计篇之“隔离设计”
下一篇
44 | 弹力设计篇之“幂等性设计”
unpreview
 写留言

精选留言(38)

  • wgy
    2018-02-28
    陈老师能不能推荐几个开源的Broker软件?
    共 4 条评论
    20
  • Sam_Deep_Thinking
    2018-02-27
    见过的,写异步最好的文章了。总结的太好了。不过有些业务呢,像下完订单并支付后,用消息通知的方式,立刻流单也不是很好。一方面可能要等到某个时机才流单,尤其是大促时,用户取消订单的很多。另外,也想在高峰期优先全部资源搞下单和支付处理,不搞其他,等高峰小一些的时候,才处理售后的一些业务。
    16
  • Bing
    2018-05-11
    进程内,使用EventBus,进程外使用MQ。现在业务难点就是在消息的顺序性上😔
    共 4 条评论
    14
  • 小沫
    2018-03-13
    broker方式 是否可以理解成 消息中间件方式 发送方为 消息生产者 将消息发送到 Q 中 接收方为 消息消费者 将消息从Q中取出
    6
  • 几度嘟嘟
    2020-06-01
    读陈皓老师文章令我感觉最棒的是知识由浅极深层层灌入的感觉。虽然文章篇幅不长,但是从文章的一开始便破题“为什么分布式架构中要使用异步通讯”,然后介绍了异步通讯的三种方式,这三种方式的介绍过程也是以一种不断补充方式,得出“异步通讯的最佳方式是Broker机制”,而后究其本质引出“事件驱动架构”,言尽于此但远不止于此。最后,结合自身丰富的工作经验,循循善诱的告诉读者,Broker方式虽好但是仍有许多需要注意的地方。 (评论虽略显油腻,但是也是出自真心觉得陈皓老师写得好~)
    展开
    6
  • Cutler
    2019-04-16
    broker可以理解成消息队列吧,用的比较多的是kafka,个人觉得需要注意在消费消息的时候业务失败了要做好相应的处理,要不然会出现数据不一致。
    5
  • 名贤集
    2018-03-01
    是否能推荐个靠谱的事件框架
    5
  • Freezer
    2018-03-01
    干货
    4
  • Darren
    2019-12-25
    为什么我不太理解订阅机制和Broker机制,我怎么觉得是一样的?目前主流的发布订阅机制就是MQ,而Broker也是MQ呀?哪位大神能解释下
    共 3 条评论
    3
  • 又双叒叕是一年啊
    2018-07-28
    事件可能会乱序请问这个如何保证需要有序处理业务的场景,状态机主要做什么?
    共 1 条评论
    3
  • 朱海峰
    2018-03-21
    这篇无意中讲了微服务的东西,在go-micro一直猜broker是啥作用

    作者回复: 是有意的,嘿嘿

    3
  • 你为啥那么牛
    2020-09-28
    我在想第三方商家调用支付接口,用的是第一种请求响应方式。在支付宝/微信内部的流程内,应该是用的broker机制,在第三方接入的环节,是无法直接参与EDA流程的。
    2
  • 华烬
    2018-02-27
    我们现在大部的异步都是通过请求响应的方式完成的,在http的接口下感觉耦合还不明显,现在工公司推了rpc,在rpc接口下,耦合很明显的,感觉可能用订阅的方式比较好,但这请求响应的方式应该可靠性更好一些,而且设计简单一些,不涉及到丢消息(中间件自身问题或网络原因等等),因为每一次丢消息都可能带来比较高的运维成本,耗子叔怎么看,至于无状态,在这个场景下的坑能简单说下么,没经历过。所以感觉不到重要性。
    2
  • 秋天
    2020-06-03
    统计一批任务下得一批机器得监控指标时,使用了异步调用 具体到本人使用得语言java 使用了java.util.concurrent包下得CompletableFuture
    1
  • 闫冬
    2020-04-20
    异步通讯的三种方式 回调式响应 通过回调地址解决 订阅者与发布者 通过消息推送实现 通过中间broker来解藕
    1
  • 程序员小跃
    2019-07-26
    才疏学浅,现在用的是MQ的方式,在看今天的课程之前,我都不知道Broker的方式,涨知识了。
    共 1 条评论
    1
  • 剑八
    2018-11-11
    下单成功,支付成功,库存失败需要回退用户钱 这个场景流程扣库存和支付是一个串行流程
    1
  • 2018-05-20
    目前系统中的异步通信主要是采用消息中间件,消息中间件采用的异步方式为broker方式。目前系统中异步通信的使用场景如下: 1、削峰上游系统调用的压力,借助mq先将订单接下来,然后根据系统自身的处理能力来处理请求 2、当某一动作、事件完成后,将消息广播出去,其它业务系统监听此消息,然后做响应业务处理 我对异步的理解是:对一些对实时性要求不高的服务可以异步处理,这样的好处是可以提高系统响应时间,尽早释放资源,从而提高了系统的性能
    展开
    1
  • 昵称
    2018-03-29
    gokit 或go micro 的rpc机制是否适合大文件的流式上传或下载,目前想把手头的服务rpc话,但是涉及到文件的上传或下载不知道怎么处理
    1
  • 方勇(gopher)
    2021-10-25
    消息中间件变成了消息总线,也是我们现在的模式,需要99.99%的高可用。