周志明的软件架构课
周志明
博士,远光软件研究院院长,《深入理解 Java 虚拟机》《凤凰架构》等书作者
54203 人已学习
免费领取
课程目录
已完结/共 74 讲
架构师的视角 (24讲)
周志明的软件架构课
15
15
1.0x
00:00/00:00
登录|注册

36 | 面对程序故障,我们该做些什么?

你好,我是周志明。接下来的两节课,我们一起来学习服务的容错性设计这个话题。
“容错性设计”(Design for Failure)是微服务的另一个核心原则,也是我在这门课中反复强调的开发观念的转变。
不过,虽然已经有了一定的心理准备,但在首次将微服务架构引入实际生产系统时,在服务发现网关路由等支持下,踏出了服务化的第一步以后,我们还是很可能会经历一段阵痛期。随着拆分出的服务越来越多,随之而来的,我们也会面临以下两个问题的困扰:
某一个服务的崩溃,会导致所有用到这个服务的其他服务都无法正常工作,一个点的错误经过层层传递,最终波及到调用链上与此有关的所有服务,这便是雪崩效应。如何防止雪崩效应,便是微服务架构容错性设计原则的具体实践,否则服务化程度越高,整个系统反而越不稳定。
服务虽然没有崩溃,但由于处理能力有限,面临超过预期的突发请求时,大部分请求直至超时都无法完成处理。这种现象产生的后果跟交通堵塞是类似的,如果一开始没有得到及时地治理,后面就会需要很长时间才能使全部服务都恢复正常。
这两个问题,就是“流量治理”这个话题要解决的了。在这个小章节,我们将围绕着如何解决这两个问题,提出服务容错、流量控制、服务质量管理等一系列解决方案。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在微服务架构中,面对程序故障,容错性设计至关重要。本文介绍了面临的容错性设计挑战以及解决方案。作者指出,随着服务数量增加,可能出现雪崩效应和处理能力不足的问题。为了解决这些挑战,文章提出了一系列解决方案,包括服务容错、流量控制、服务质量管理等。在讨论服务容错时,文章强调了容错性设计在构建微服务系统中的重要性,因为分布式系统的本质是不可靠的,需要保证系统的可用性。文章还提到了分布式系统中可能出现的程序崩溃、节点宕机、网络中断等“意外情况”,并强调了提升系统可用性的重要性。总的来说,本文强调了在微服务架构中如何应对程序故障,以及为保证系统可用性而进行的容错性设计的重要性。 文章还介绍了7种常见的容错策略,包括故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用。这些策略涵盖了面对故障时的应对方法,以及如何实现容错设计。通过对这些策略的介绍,读者可以了解在实践中如何落实容错性设计原则,以及如何应对不同类型的故障情况。这些策略的应用可以帮助读者更好地理解容错性设计在实际工作中的应用场景和优缺点。 总的来说,本文通过介绍微服务架构中的容错性设计挑战和解决方案,以及常见的容错策略,为读者提供了在面对程序故障时的实际指导和应对方法。这些内容对于在微服务架构中工作的技术人员来说具有重要的参考价值。

该试读文章来自《周志明的软件架构课》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • Demon.Lee
    周老师,请教一个面试问题。 面试官问我:“如果一个业务系统需要调用第三方的5个接口,这5个接口中只要有3个接口返回成功了就认为成功,问如何设计并实现。” 我的想法是主线程进来之后,用一个线程池对多个接口并行调用,每当一个线程调用返回之后就将结果持久化下来。主线程定时轮询判断是否满足了3个成功或3个失败的要求,如果满足,就可以打断另外两个还未结束的线程,如果在一定超时时间内,还没有结果,就将多个未结束的线程都打断。感觉方案比较low,如果第三方的服务不是幂等的,会有很多问题。 想听听老师对这道题的想法,谢谢您。

    作者回复: 我看这题是个圈套呀,大多数的架构设计题目,固定答案往往都是不对的。因为做技术设计是为了解决实际问题,不能谈兵,所以方案要根据希望实现的目标而定: 如果目的是这项业务尽可能快速地完成,那就forking策略,5个一起调用,成功3个算过。 如果目的是这项业务尽可能少消耗资源,那就failfast策略,先对它们出错概率做个先验判断,排序后先调用最容易出错的,错够3次算失败,后面的不执行。 如果目的是这项业务尽可能高概率地完成,那就failover策略。etc。

    2021-03-25
    9
    32
  • zhanyd
    生活中的容错策略的例子: 1.故障转移:向爸爸要零花钱不给,转身向妈妈要。 2.快速失败:遇见渣男,果断分手,不要拖泥带水。 3.安全失败:赶飞机,发现少带了件衣服没关系,到了目的地再买。 4.沉默失败:前男友想复合?果断拒绝,不要给第二次机会。 5.故障恢复:找中介买房,看了房不满意,先回家,中介有好房源再通知你。 6.并行调用:同时和两个同事说,帮你开一下电脑,只要有一个人帮你开了就行了。 7.广播调用:给领导敬酒,每个领导都要敬,不要落下,否则。。。
    2021-02-08
    4
    89
  • tt
    总结一下。面对故障,我们要重试,尽最大努力交付。 故障转移:多节点下的重试策略。 快速失败:不允许重试的重试策略。 安全失败:根本就不需重试的策略。 沉默失败:主动避免重试的策略。 故障恢复:带任务调度的、基于异步的重试策略。
    2021-02-08
    1
    13
  • neohope
    之前做个一个折中的处理方案,类似于快速接收,批处理,反馈处理状态。之所以这样处理,是因为合作机构IT水平参差不齐,而且配合程度不高,如果把数据接收+处理+反馈放到一起的话,一旦有错误,就要麻烦对方重新推送最新数据,或者自己脚本重新处理数据,而且一天峰值十分明显,峰值时根本来不及处理数据。 1、数据接收阶段,采用了快速失败策略。一旦数据落库文件落盘,就返回成功,反之失败。 2、数据处理阶段,会进行重试,三次后进入失败队列 3、进入失败队列后,会通知运维和开发,去看下数据什么问题。有时会把文件手工处理一下,再重试。如果实在无法处理,就线下通知合作方相关人员如何修改数据。 4、数据处理成功后或彻底失败后,发送处理结果给合作方。 这种方式,在对合作方约束很小、合作方缺乏技术支持、项目前期阶段、以快速开展业务为优先考量时,可以尝试一下。后面自己做起来后,就可以要求对方,做一些统一要求了。
    2021-04-12
    3
  • 李二木
    容错策略 故障转移(Failover) 如果调用的服务器出现故障,系统不会立即向调用者返回失败结果,而是自动切换到其他服务副本,尝试其他副本能否返回成功调用的结果,从而保证了整体的高可用性 快速失败(Failfast) 尽快让服务报错并抛出异常,坚决避免重试 安全失败(Failsafe) 旁路逻辑(非主逻辑)调用失败了,也当作正确来返回,如果需要返回值的话,系统就自动返回一个默认值 沉默失败(Failsilent) 当请求失败后,就默认服务提供者一定时间内无法再对外提供服务,不再 向它分配请求流量,并将错误隔离开来,避免对系统其他部分产生影响 故障恢复(Failback) 当服务调用出错了以后,将该次调用失败的信息存入一个消息队列中,然 后由系统自动开始异步重试调用 并行调用(Forking) 同时向多个服务副本发起调用,只要有其中任何一个返回成功,那调用便 宣告成功 广播调用(Broadcast) 同时向多个服务副本发起调用,要求所有的请求全部都成功,才算是成功
    2021-02-20
    3
  • Johar
    项目中使用过服务灾备策略,在网关同步核心业务数据,在核心业务服务不可用的情况下,使用本地的核心数据返回给客户端,支持核心业务的高可用。另外请教一下老师,目前微服务,提高可用性的方法,一般都是增加服务节点,避免单点故障,但是部署多个节点,会带来一定的项目成本,产品的竞争力下降,特别是一些老项目,前期的机房、网络、机架都已经规划好,不能变更,在提升整个系统可用性的方面,还有什么好的方法?
    2021-10-20
  • 李雷
    降级属于安全失败还是故障恢复?
    2021-02-23
    3
  • Helios
    还有熔断,和沉默失败类似都是在客户端做的。 比如一个服务返回了类似429这种触发了熔断的错误,就会导致在一段时间内不去请求这个服务,但是这样会造成某次请求返回429就触发熔断,可能是瞬间造成的,所以需要有个窗口,当窗口大于某个值的时候才去触发熔断。 但是一个触发熔断的固定值不好取,所以我们可以采取tcp慢启动的方式,逐步给这个服务放量,直至取消熔断
    2021-02-15
  • walnut
    沉默失败,数据库连接失败后,10秒后再重连。
    2021-02-09
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部