同步操作将从 turnon/blog 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
title: 服务容错
date: 2022-04-20 17:27:42
categories:
- 分布式
- 分布式高可用
tags:
- 分布式
- 服务治理
- 监控
- APM
- 链路追踪
permalink: /pages/e32c7e/
从故障影响范围维度来看,分布式系统的故障可以分为三类:
一般而言,集群故障的产生原因不外乎有两种:
应付集群故障的思路,主要是采用流量控制,主要手段有:限流、降级、熔断。
单机房脱网的事情,多半是因为一些不可抗因素,如:机房失火、光缆被挖断等等。有句老话叫:不要把鸡蛋都放在一个篮子里。同理,不要把业务都部署在一个机房中,一旦机房出事,那就彻底完蛋了。所以,很多互联网公司的业务都采用多机房部署。如果要追求更高的可靠性,可以采用同城多活部署,甚至异地多活部署。
多机房部署的好处显而易见,即提高了系统的可用性,但是这种架构引入了其他的问题:如何保证不同机房数据的一致性,如何切换多机房的流量,等等。
针对流量切换问题,一般有两种手段:
对于大规模集群来说,出现单机故障的概率是很高的。当出现单机故障时,需要有一定的自动化处理手段。
处理单机故障一个有效的办法就是自动重启。具体来讲,你可以设置一个阈值,比如以某个接口的平均耗时为准,当监控单机上某个接口的平均耗时超过一定阈值时,就认为这台机器有问题,这个时候就需要把有问题的机器从线上集群中摘除掉,然后在重启服务后,重新加入到集群中。
服务调用并不总是一定成功的,前面我讲过,可能因为服务提供者节点自身宕机、进程异常退出或者服务消费者与提供者之间的网络出现故障等原因。对于服务调用失败的情况,需要有手段自动恢复,来保证调用成功。
常用的手段主要有以下几种:
断路器的基本思路是很简单的,就是通过代理(断路器对象)来一对一地(一个远程服务对应一个断路器对象)接管服务调用者的远程请求。断路器会持续监控并统计服务返回的成功、失败、超时、拒绝等各种结果,当出现故障(失败、超时、拒绝)的次数达到断路器的阈值时,它状态就自动变为“OPEN”,后续此断路器代理的远程访问都将直接返回调用失败,而不会发出真正的远程服务请求。通过断路器对远程服务的熔断,避免因持续的失败或拒绝而消耗资源,因持续的超时而堆积请求,最终的目的就是避免雪崩效应的出现。由此可见,断路器本质是一种快速失败策略的实现方式。
舱壁隔离模式是常用的实现服务隔离的设计模式,舱壁这个词是来自造船业的舶来品,它原本的意思是设计舰船时,要在每个区域设计独立的水密舱室,一旦某个舱室进水,也只是影响这个舱室中的货物,而不至于让整艘舰艇沉没。这种思想就很符合容错策略中失败静默策略。
Hystrix 就采用舱壁隔离模式来实现线程隔离。
故障转移和故障恢复策略都需要对服务进行重复调用,差别是这些重复调用有可能是同步的,也可能是后台异步进行;有可能会重复调用同一个服务,也可能会调用到服务的其他副本。无论具体是通过怎样的方式调用、调用的服务实例是否相同,都可以归结为重试设计模式的应用范畴。重试模式适合解决系统中的瞬时故障,简单的说就是有可能自己恢复(Resilient,称为自愈,也叫做回弹性)的临时性失灵,网络抖动、服务的临时过载(典型的如返回了 503 Bad Gateway 错误)这些都属于瞬时故障。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。