43 | 弹力设计:异步通讯设计
陈皓
该思维导图由 AI 生成,仅供参考
你好,我是陈皓,网名左耳朵耗子。
前面所说的隔离设计通常都需要对系统做解耦设计,而把一个单体系统解耦,不单单是把业务功能拆分出来,正如前面所说,拆分完后还会面对很多的问题。其中一个重要的问题就是这些系统间的通讯。
通讯一般来说分同步和异步两种。同步通讯就像打电话,需要实时响应,而异步通讯就像发邮件,不需要马上回复。各有千秋,我们很难说谁比谁好。但是在面对超高吞吐量的场景下,异步处理就比同步处理有比较大的优势了,这就好像一个人不可能同时接打很多电话,但是他可以同时接收很多的电子邮件一样。
同步调用虽然让系统间只耦合于接口,而且实时性也会比异步调用要高,但是我们也需要知道同步调用会带来如下几个问题。
同步调用需要被调用方的吞吐不低于调用方的吞吐。否则会导致被调用方因为性能不足而拖死调用方。换句话说,整个同步调用链的性能会由最慢的那个服务所决定。
同步调用会导致调用方一直在等待被调用方完成,如果一层接一层地同步调用下去,所有的参与方会有相同的等待时间。这会非常消耗调用方的资源。因为调用方需要保存现场(Context)等待远端返回,所以对于并发比较高的场景来说,这样的等待可能会极度消耗资源。
同步调用只能是一对一的,很难做到一对多。
同步调用最不好的是,如果被调用方有问题,那么其调用方就会跟着出问题,于是会出现多米诺骨牌效应,故障一下就蔓延开来。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
异步通讯设计在分布式系统中的重要性不言而喻。本文深入探讨了同步和异步通讯的区别,以及异步通讯的三种方式:请求响应式、通过订阅的方式和通过Broker的方式。特别强调了通过Broker的方式最为解耦,但也需要保证高可用、高性能和数据持久化。此外,还介绍了事件驱动设计的优点和不足之处。总的来说,异步通讯设计可以提高系统的弹性和吞吐量,但也需要注意处理乱序事件和复杂的事务处理。这些设计模式对于构建高效、可靠的分布式系统具有重要意义。文章内容丰富,涵盖了异步通讯设计的重点和注意事项,对于分布式系统的设计和实践具有重要的指导意义。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《左耳听风》,新⼈⾸单¥98
《左耳听风》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(41)
- 最新
- 精选
- 朱海峰这篇无意中讲了微服务的东西,在go-micro一直猜broker是啥作用
作者回复: 是有意的,嘿嘿
2018-03-214 - 403我也想知道消息的顺序性怎么保证
作者回复: 分布式环境下,非常之难。
2018-07-3021 - wgy陈老师能不能推荐几个开源的Broker软件?2018-02-28420
- Sam_Deep_Thinking见过的,写异步最好的文章了。总结的太好了。不过有些业务呢,像下完订单并支付后,用消息通知的方式,立刻流单也不是很好。一方面可能要等到某个时机才流单,尤其是大促时,用户取消订单的很多。另外,也想在高峰期优先全部资源搞下单和支付处理,不搞其他,等高峰小一些的时候,才处理售后的一些业务。2018-02-27116
- Bing进程内,使用EventBus,进程外使用MQ。现在业务难点就是在消息的顺序性上😔2018-05-11414
- 几度嘟嘟读陈皓老师文章令我感觉最棒的是知识由浅极深层层灌入的感觉。虽然文章篇幅不长,但是从文章的一开始便破题“为什么分布式架构中要使用异步通讯”,然后介绍了异步通讯的三种方式,这三种方式的介绍过程也是以一种不断补充方式,得出“异步通讯的最佳方式是Broker机制”,而后究其本质引出“事件驱动架构”,言尽于此但远不止于此。最后,结合自身丰富的工作经验,循循善诱的告诉读者,Broker方式虽好但是仍有许多需要注意的地方。 (评论虽略显油腻,但是也是出自真心觉得陈皓老师写得好~)2020-06-019
- 小沫broker方式 是否可以理解成 消息中间件方式 发送方为 消息生产者 将消息发送到 Q 中 接收方为 消息消费者 将消息从Q中取出2018-03-137
- Cutlerbroker可以理解成消息队列吧,用的比较多的是kafka,个人觉得需要注意在消费消息的时候业务失败了要做好相应的处理,要不然会出现数据不一致。2019-04-165
- 名贤集是否能推荐个靠谱的事件框架2018-03-015
- Darren为什么我不太理解订阅机制和Broker机制,我怎么觉得是一样的?目前主流的发布订阅机制就是MQ,而Broker也是MQ呀?哪位大神能解释下2019-12-2544
收起评论