36 | 面对程序故障,我们该做些什么?
- 深入了解
- 翻译
- 解释
- 总结
在微服务架构中,面对程序故障,容错性设计至关重要。本文介绍了面临的容错性设计挑战以及解决方案。作者指出,随着服务数量增加,可能出现雪崩效应和处理能力不足的问题。为了解决这些挑战,文章提出了一系列解决方案,包括服务容错、流量控制、服务质量管理等。在讨论服务容错时,文章强调了容错性设计在构建微服务系统中的重要性,因为分布式系统的本质是不可靠的,需要保证系统的可用性。文章还提到了分布式系统中可能出现的程序崩溃、节点宕机、网络中断等“意外情况”,并强调了提升系统可用性的重要性。总的来说,本文强调了在微服务架构中如何应对程序故障,以及为保证系统可用性而进行的容错性设计的重要性。 文章还介绍了7种常见的容错策略,包括故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用。这些策略涵盖了面对故障时的应对方法,以及如何实现容错设计。通过对这些策略的介绍,读者可以了解在实践中如何落实容错性设计原则,以及如何应对不同类型的故障情况。这些策略的应用可以帮助读者更好地理解容错性设计在实际工作中的应用场景和优缺点。 总的来说,本文通过介绍微服务架构中的容错性设计挑战和解决方案,以及常见的容错策略,为读者提供了在面对程序故障时的实际指导和应对方法。这些内容对于在微服务架构中工作的技术人员来说具有重要的参考价值。
请先领取课程
全部留言(9)
- 最新
- 精选
- Demon.Lee周老师,请教一个面试问题。 面试官问我:“如果一个业务系统需要调用第三方的5个接口,这5个接口中只要有3个接口返回成功了就认为成功,问如何设计并实现。” 我的想法是主线程进来之后,用一个线程池对多个接口并行调用,每当一个线程调用返回之后就将结果持久化下来。主线程定时轮询判断是否满足了3个成功或3个失败的要求,如果满足,就可以打断另外两个还未结束的线程,如果在一定超时时间内,还没有结果,就将多个未结束的线程都打断。感觉方案比较low,如果第三方的服务不是幂等的,会有很多问题。 想听听老师对这道题的想法,谢谢您。
作者回复: 我看这题是个圈套呀,大多数的架构设计题目,固定答案往往都是不对的。因为做技术设计是为了解决实际问题,不能谈兵,所以方案要根据希望实现的目标而定: 如果目的是这项业务尽可能快速地完成,那就forking策略,5个一起调用,成功3个算过。 如果目的是这项业务尽可能少消耗资源,那就failfast策略,先对它们出错概率做个先验判断,排序后先调用最容易出错的,错够3次算失败,后面的不执行。 如果目的是这项业务尽可能高概率地完成,那就failover策略。etc。
2021-03-25932 - zhanyd生活中的容错策略的例子: 1.故障转移:向爸爸要零花钱不给,转身向妈妈要。 2.快速失败:遇见渣男,果断分手,不要拖泥带水。 3.安全失败:赶飞机,发现少带了件衣服没关系,到了目的地再买。 4.沉默失败:前男友想复合?果断拒绝,不要给第二次机会。 5.故障恢复:找中介买房,看了房不满意,先回家,中介有好房源再通知你。 6.并行调用:同时和两个同事说,帮你开一下电脑,只要有一个人帮你开了就行了。 7.广播调用:给领导敬酒,每个领导都要敬,不要落下,否则。。。2021-02-08489
- tt总结一下。面对故障,我们要重试,尽最大努力交付。 故障转移:多节点下的重试策略。 快速失败:不允许重试的重试策略。 安全失败:根本就不需重试的策略。 沉默失败:主动避免重试的策略。 故障恢复:带任务调度的、基于异步的重试策略。2021-02-08113
- neohope之前做个一个折中的处理方案,类似于快速接收,批处理,反馈处理状态。之所以这样处理,是因为合作机构IT水平参差不齐,而且配合程度不高,如果把数据接收+处理+反馈放到一起的话,一旦有错误,就要麻烦对方重新推送最新数据,或者自己脚本重新处理数据,而且一天峰值十分明显,峰值时根本来不及处理数据。 1、数据接收阶段,采用了快速失败策略。一旦数据落库文件落盘,就返回成功,反之失败。 2、数据处理阶段,会进行重试,三次后进入失败队列 3、进入失败队列后,会通知运维和开发,去看下数据什么问题。有时会把文件手工处理一下,再重试。如果实在无法处理,就线下通知合作方相关人员如何修改数据。 4、数据处理成功后或彻底失败后,发送处理结果给合作方。 这种方式,在对合作方约束很小、合作方缺乏技术支持、项目前期阶段、以快速开展业务为优先考量时,可以尝试一下。后面自己做起来后,就可以要求对方,做一些统一要求了。2021-04-123
- 李二木容错策略 故障转移(Failover) 如果调用的服务器出现故障,系统不会立即向调用者返回失败结果,而是自动切换到其他服务副本,尝试其他副本能否返回成功调用的结果,从而保证了整体的高可用性 快速失败(Failfast) 尽快让服务报错并抛出异常,坚决避免重试 安全失败(Failsafe) 旁路逻辑(非主逻辑)调用失败了,也当作正确来返回,如果需要返回值的话,系统就自动返回一个默认值 沉默失败(Failsilent) 当请求失败后,就默认服务提供者一定时间内无法再对外提供服务,不再 向它分配请求流量,并将错误隔离开来,避免对系统其他部分产生影响 故障恢复(Failback) 当服务调用出错了以后,将该次调用失败的信息存入一个消息队列中,然 后由系统自动开始异步重试调用 并行调用(Forking) 同时向多个服务副本发起调用,只要有其中任何一个返回成功,那调用便 宣告成功 广播调用(Broadcast) 同时向多个服务副本发起调用,要求所有的请求全部都成功,才算是成功2021-02-203
- Johar项目中使用过服务灾备策略,在网关同步核心业务数据,在核心业务服务不可用的情况下,使用本地的核心数据返回给客户端,支持核心业务的高可用。另外请教一下老师,目前微服务,提高可用性的方法,一般都是增加服务节点,避免单点故障,但是部署多个节点,会带来一定的项目成本,产品的竞争力下降,特别是一些老项目,前期的机房、网络、机架都已经规划好,不能变更,在提升整个系统可用性的方面,还有什么好的方法?2021-10-20
- 李雷降级属于安全失败还是故障恢复?2021-02-233
- Helios还有熔断,和沉默失败类似都是在客户端做的。 比如一个服务返回了类似429这种触发了熔断的错误,就会导致在一段时间内不去请求这个服务,但是这样会造成某次请求返回429就触发熔断,可能是瞬间造成的,所以需要有个窗口,当窗口大于某个值的时候才去触发熔断。 但是一个触发熔断的固定值不好取,所以我们可以采取tcp慢启动的方式,逐步给这个服务放量,直至取消熔断2021-02-15
- walnut沉默失败,数据库连接失败后,10秒后再重连。2021-02-09