左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

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

陈皓 2018-02-27
前面所说的隔离设计通常都需要对系统做解耦设计,而把一个单体系统解耦,不单单是把业务功能拆分出来,正如上面所说,拆分完后还会面对很多的问题。其中一个重要的问题就是这些系统间的通讯。
通讯一般来说分同步和异步两种。同步通讯就像打电话,需要实时响应,而异步通讯就像发邮件,不需要马上回复。各有千秋,我们很难说谁比谁好。但是在面对超高吐吞量的场景下,异步处理就比同步处理有比较大的优势了,这就好像一个人不可能同时接打很多电话,但是他可以同时接收很多的电子邮件一样。
同步调用虽然让系统间只耦合于接口,而且实时性也会比异步调用要高,但是我们也需要知道同步调用会带来如下几个问题。
同步调用需要被调用方的吞吐不低于调用方的吞吐。否则会导致被调用方因为性能不足而拖死调用方。换句话说,整个同步调用链的性能会由最慢的那个服务所决定。
同步调用会导致调用方一直在等待被调用方完成,如果一层接一层地同步调用下去,所有的参与方会有相同的等待时间。这会非常消耗调用方的资源。因为调用方需要保存现场(Context)等待远端返回,所以对于并发比较高的场景来说,这样的等待可能会极度消耗资源。
同步调用只能是一对一的,很难做到一对多。
同步调用最不好的是,如果被调用方有问题,那么其调用方就会跟着出问题,于是会出现多米诺骨牌效应,故障一下就蔓延开来。
所以,异步通讯相对于同步通讯来说,除了可以增加系统的吞吐量之外,最大的一个好处是其可以让服务间的解耦更为彻底,系统的调用方和被调用方可以按照自己的速率而不是步调一致,从而可以更好地保护系统,让系统更有弹力。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(23)

  • wgy
    陈老师能不能推荐几个开源的Broker软件?
    2018-02-28
    3
    11
  • Bing
    进程内,使用EventBus,进程外使用MQ。现在业务难点就是在消息的顺序性上😔
    2018-05-11
    2
    7
  • 幻想
    见过的,写异步最好的文章了。总结的太好了。不过有些业务呢,像下完订单并支付后,用消息通知的方式,立刻流单也不是很好。一方面可能要等到某个时机才流单,尤其是大促时,用户取消订单的很多。另外,也想在高峰期优先全部资源搞下单和支付处理,不搞其他,等高峰小一些的时候,才处理售后的一些业务。
    2018-02-27
    7
  • 山分子
    broker可以理解成消息队列吧,用的比较多的是kafka,个人觉得需要注意在消费消息的时候业务失败了要做好相应的处理,要不然会出现数据不一致。
    2019-04-16
    3
  • Freezer
    干货
    2018-03-01
    3
  • 名贤集
    是否能推荐个靠谱的事件框架
    2018-03-01
    3
  • 涛哥迷妹
    事件可能会乱序请问这个如何保证需要有序处理业务的场景,状态机主要做什么?
    2018-07-28
    2
  • 小沫
    broker方式 是否可以理解成 消息中间件方式
    发送方为 消息生产者 将消息发送到 Q 中
    接收方为 消息消费者 将消息从Q中取出

    2018-03-13
    2
  • 华烬
    我们现在大部的异步都是通过请求响应的方式完成的,在http的接口下感觉耦合还不明显,现在工公司推了rpc,在rpc接口下,耦合很明显的,感觉可能用订阅的方式比较好,但这请求响应的方式应该可靠性更好一些,而且设计简单一些,不涉及到丢消息(中间件自身问题或网络原因等等),因为每一次丢消息都可能带来比较高的运维成本,耗子叔怎么看,至于无状态,在这个场景下的坑能简单说下么,没经历过。所以感觉不到重要性。
    2018-02-27
    2
  • 恒修
    下单成功,支付成功,库存失败需要回退用户钱
    这个场景流程扣库存和支付是一个串行流程
    2018-11-11
    1
  • 目前系统中的异步通信主要是采用消息中间件,消息中间件采用的异步方式为broker方式。目前系统中异步通信的使用场景如下:
    1、削峰上游系统调用的压力,借助mq先将订单接下来,然后根据系统自身的处理能力来处理请求
    2、当某一动作、事件完成后,将消息广播出去,其它业务系统监听此消息,然后做响应业务处理

    我对异步的理解是:对一些对实时性要求不高的服务可以异步处理,这样的好处是可以提高系统响应时间,尽早释放资源,从而提高了系统的性能
    2018-05-20
    1
  • kingeasternsun
    gokit 或go micro 的rpc机制是否适合大文件的流式上传或下载,目前想把手头的服务rpc话,但是涉及到文件的上传或下载不知道怎么处理
    2018-03-29
    1
  • 朱海峰
    这篇无意中讲了微服务的东西,在go-micro一直猜broker是啥作用

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

    2018-03-21
    1
  • Dimple
    才疏学浅,现在用的是MQ的方式,在看今天的课程之前,我都不知道Broker的方式,涨知识了。
    2019-07-26
    1
  • edisonhuang
    通讯设计有同步和异步的方式。同步设立会带来由于一个环节的处理慢卡住整个系统的问题。所以分布式系统中为了提高吞吐量通常是异步通讯的方式。
    异步通讯有请求响应方式,发布订阅模式和broker模式。使用broker模式解除了请求发送方和接收方的耦合,因此可以极大提高系统的处理能力,易扩展运维。但同时要保证broker是高可用,同时也让业务处理本身看起来不如以前直接了。
    2019-07-03
  • 涛哥迷妹
    服务间只通过消息交互,所以业务状态最好由一个 总控方 来管理,这个 总控方 维护一个业务流程的状态变迁逻辑 -> 请问这个总控方有什么成熟的解决方案? 有的话大家帮我科普下
    2019-06-21
  • 涛哥迷妹
    读这些文章对我编程 架构 认知 是一次质的洗礼点赞了
    2019-06-21
  • sprzhing
    有哪些broker呢?
    2019-05-11
  • godtrue
    消息的接受有序性确实不好控制,不过可以通过发送消息的时间戳来感知一下。我们的订单全程跟踪消息的有序性就是这么弄的。
    2019-01-25
    1
  • 阿康
    事件驱动 发布订阅模型只适用于内部系统,对外的服务还是只能用 请求响应式的异步通信方式,这样理解没问题吧?
    2018-09-18
收起评论
23
返回
顶部