左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
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 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

48 | 弹力设计篇之“熔断设计”

陈皓 2018-03-15
熔断机制这个词对你来说肯定不陌生,它的灵感来源于我们电闸上的 " 保险丝 ",当电压有问题时(比如短路),自动跳闸,此时电路就会断开,我们的电器就会受到保护。不然,会导致电器被烧坏,如果人没在家或是人在熟睡中,还会导致火灾。所以,在电路世界通常都会有这样的自我保护装置。
同样,在我们的分布式系统设计中,也应该有这样的方式。前面说过重试机制,如果错误太多,或是在短时间内得不到修复,那么我们重试也没有意义了,此时应该开启我们的熔断操作,尤其是后端太忙的时候,使用熔断设计可以保护后端不会过载。

熔断设计

熔断器模式可以防止应用程序不断地尝试执行可能会失败的操作,使得应用程序继续执行而不用等待修正错误,或者浪费 CPU 时间去等待长时间的超时产生。熔断器模式也可以使应用程序能够诊断错误是否已经修正。如果已经修正,应用程序会再次尝试调用操作。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • ZhYB
    看到第一个留言问熔断粒度的,您回复的是服务粒度,这个错了吧,应该是接口粒度的吧。另外,相关方面你文中说在半断开后通过ping来探活,这个也不行吧,探活是成功的,不代表被熔断的那个接口是活的。说白了,还是觉得您对熔断粒度理解有点偏差,不是服务粒度的。因为一个服务会暴露多个接口,每个接口有不同的计算逻辑和依赖不同的依赖,一个接口挂不代表别的接口也挂。
    2019-06-26
    6
  • 曾凡伟
    请问熔断的最小粒度,是针对每个单一请求,还是针对整个应用来实施呢

    作者回复: 服务的粒度

    2018-03-16
    5
  • 多米
    可惜更新有点慢~
    2018-03-17
    2
  • slark
    弹性设计相关,看一看 spring微服务实战 很有帮助。或者把spring cloud的组件,背景了解一下,对于微服务为什么要这样做就有谱了。大型互联网公司里在没有通用组件前都会有自研的类似组件,比如负载均衡,通用网关,鉴权,流水日志等。有一定经历,再来看微服务的设计会觉得他们其实非常相似。java在这方面有成熟组件,实在是非常有利于开发
    2018-08-01
    1
  • edisonhuang
    熔断设计受保险丝设计的启发,可以保证系统在出问题是客户端及时停止调用而非一直失败重试。
    熔断的设计会涉及三种状态,闭合状态,半开状态和打卡状态,三种状态可以由一个状态机来转换。
    熔断设计还需要考虑的几个重要问题包括错误类型的区分,日志监控,允许手动恢复的设置,并发问题等
    2019-07-10
  • 涛哥迷妹
    理论总结的挺好,应该多一些实际的落地方案便于理解。要不有些抽象
    2019-06-24
  • 拉欧
    设计熔断器的关键,在于维护三个状态(open,half-open,close)之间的流转,以及接口(is
    Allowed, timeout, fail, success)的正确响应逻辑
    2019-06-04
  • Sunshine
    陈老师,基于滑动时间窗口进行调用(success & fail)的统计,底层的数据结构有什么好的推荐吗?目前在使用逻辑环形数组
    2019-05-22
  • godtrue
    熔断是否可认为切断对服务的依赖不再依赖了,是降级的升级版。
    2019-01-30
    2
  • Geek_fb3db2
    服务都是多实例部署的 一个服务不可用就熔断 但是其他同样服务是可用的 这个怎么处理
    2018-12-06
  • 李顺翔
    @Adrian 极客好像非作者不能回复,专门留言回复你。。
    首先下游服务可以分为第三方服务跟微服务,第三方服务没见过谁直接调用某个服务节点的,都是通过网关去负载均衡,所以服务不可用即代表了网关服务不可用,对上游服务来说,跟集群不可用没有区别,而微服务的话,调用的时候单节点不可用会自动给你负载到可用服务节点,除非服务提供者全部挂了(网络波动导致连不通也算),否则不会触发这个断路器,设置了超时时间的断路另说
    2018-09-06
  • 欧星星
    如果服务A的一个功能依赖服务B和服务C,当服务B出现问题触发熔断的时候这时候这个熔断有必要吗?
    2018-07-12
  • Adrian
    “一些错误是远程服务挂掉,恢复时间比较长;这种错误不必走重试,可以直接打开熔断策略”,这句话感觉说的有些绝对,如果下游服务只是单机挂掉了,上游系统监测不可恢复异常,如果非超时类耗费机器资源的异常,如果直接熔断,会导致正常的服务也不可用,必然导致业务有损,毕竟下游集群部分机器可能还是正常工作的
    2018-03-21
  • shufang
    以前一直觉得是高大上的东西,现在越看越明白,谢谢老师~
    2018-03-15
收起评论
14
返回
顶部