文章目录
前言
在分布式系统之上,衍生出了微服务。
然而,分布式系统面临的问题,在微服务上更加凸显了。
一、分布式系统是什么
分布式系统,是多台计算机节点,为了完成共同任务而组成的系统,它们通过网络进行通信。
可以把它视为,一个系统被分成了多个部分,分到了不同的节点上。
二、分布式系统面临的问题
分布式系统面临的主要问题是:一个任务需要多个节点通过网络协同完成,这带来了各种故障
。
例如:
节点硬件故障
节点软件bug报错
节点运行慢
网络延时高
网络不通
网络不稳定
再加上可能有多种网络、多种计算机系统、多种编程语言,
故障无法避免,容错设计势在必行。
三、容错的实现思路
1.复制(replication)
服务无状态,可以通过复制服务节点保障高可用。
2.抑制(containment)
故障被抑制在单个组件中,不扩散到其他组件。
3.隔离(isolation)
组件相互隔离。
包含了软件层面的隔离、硬件层面的隔离。
使系统在部分组件失败时,可以不影响整体的功能。
4.委托(delegation)
组件的恢复委托给另一个(外部)组件。
例如:运维层面的健康监测和重启。
四、容错方案
表格简单介绍了容错方案,详情请继续阅读
容错方案 | 使用场景 | 优点 | 缺点 | 常见实现方案 |
---|---|---|---|---|
限流 | 防范流量攻击; 防范突发流量; 外网服务建议使用 | 可以代码无侵入; 代码的可复用性高 | 允许有损 | Sentinel Guava Redis+Lua Nginx+Lua |
自动降级 | 有一定调用量, 且依赖下游服务 | 代码自动触发 | 代码有侵入; 实现复杂 | Sentinel Hystrix |
人工降级 | 大流量,高并发 例如:秒杀 | 后端可以代码无侵入; 可以有计划地提前介入 | 需要人工介入; 会降低用户体验 | 前端关闭流量入口; 后端关闭外部流量入口 |
1.限流
概念
限制系统进入的流量, 舍弃或者排队超出流量后的请求。
保障的是整个系统的可用。
应对的问题
请求流量超过系统承受能力,导致系统或者调用链的下游系统瘫痪
使用场景
防范流量攻击;
防范未能预估的突发流量;
暴露到外网的服务都建议使用
优点
可以代码无侵入;
侵入式代码的可复用性高
缺点
允许有业务的损失,
因此一般作为保底,和其他容错设计搭配使用
落地难点
流量阈值难以界定:
要评估当前系统的承受阈值,
也要评估下游系统的承受阈值
常见实现方案
技术方案 | 限流模式 | 代码侵入 |
---|---|---|
Sentinel | 单机限流、集群限流 | 代码侵入 |
Guava | 单机限流 | 代码侵入 |
Redis+Lua | 集群限流 | 代码侵入 |
Nginx+Lua | 集群限流 | 代码无侵入 |
2.自动降级
自动降级有多种处理预案,基础组合是1+2+5+6
No. | 自动降级处理预案 | 解释 |
---|---|---|
1 | 故障检测 | 检测超时(未获得响应)、异常(获得响应); 检测负载(调用方的线程数、系统load) |
2 | 故障自动恢复 | 故障时进入关闭模式、半开模式, 恢复后进入全开模式 |
3 | 兜底 | 下游服务提供者发生故障时,针对或统一的处理,不停止服务调用 |
4 | 快速超时 | 缩短调用下游服务的超时时间,不停止服务调用 |
5 | 服务熔断 | 故障检测达到阈值后停止服务调用 |
6 | 服务降级 | 停止原服务调用,使用备选服务,或者立即失败 |
7 | 重试 | 重试调用,需要幂等 |
8 | 补偿 | 失败的后流程中补偿业务损失数据 |
概念
在下游服务故障时(特指通过网络通信的服务出现故障),
自动降级调用方对下游服务的调用。
保障的是系统中的上游调用方的可用。
应对的问题
调用链的下游服务超时或者异常,导致调用方资源占用堆积无法响应,进而产生雪崩效应,引起系统瘫痪
使用场景
有一定的调用量,且依赖下游服务
优点
代码自动检测处理和自动恢复
缺点
代码有侵入;
要根据业务场景做各种处理预案,实现复杂
落地难点
难点在于制订处理预案:
下游服务众多,需要根据业务做场景出不同的处理预案
常见实现方案
上图来自sentinel的github
3.人工降级
概念
限制甚至关闭非核心功能,留出服务器资源给核心功能。
保障的是系统的核心功能可用。
应对的问题
核心功能和非核心功能共用服务器资源(例如:数据库),
非核心功能占用了一定比例资源后,导致核心功能无法及时响应
使用场景
大流量,高并发。
例如:秒杀
优点
后端可以代码无侵入;
可以有计划地提前介入
缺点
需要人工介入;
会降低一定的用户体验
落地难点
难点在于决定哪些功能可以关闭:
功能关闭可能会影响业务量
常见实现方案
前端关闭流量入口;
后端关闭外部流量入口
总结
本文总结了分布式系统中的容错设计,
主要针对的是分布式系统常见问题的容错,对硬件以及运维层面的通用容错设计并未提及。
核心是以下2个表格:
容错方案
容错方案 | 使用场景 | 优点 | 缺点 | 常见实现方案 |
---|---|---|---|---|
限流 | 防范流量攻击; 防范突发流量; 外网服务建议使用 | 可以代码无侵入; 代码的可复用性高 | 允许有损 | Sentinel Guava Redis+Lua Nginx+Lua |
自动降级 | 有一定调用量, 且依赖下游服务 | 代码自动触发 | 代码有侵入; 实现复杂 | Sentinel Hystrix |
人工降级 | 大流量,高并发 例如:秒杀 | 后端可以代码无侵入; 可以有计划地提前介入 | 需要人工介入; 会降低用户体验 | 前端关闭流量入口; 后端关闭外部流量入口 |
自动降级处理预案,基础组合是1+2+5+6
No. | 自动降级处理预案 | 解释 |
---|---|---|
1 | 故障检测 | 检测超时(未获得响应)、异常(获得响应); 检测负载(调用方的线程数、系统load) |
2 | 故障自动恢复 | 故障时进入关闭模式、半开模式, 恢复后进入全开模式 |
3 | 兜底 | 下游服务提供者发生故障时,针对或统一的处理,不停止服务调用 |
4 | 快速超时 | 缩短调用下游服务的超时时间,不停止服务调用 |
5 | 服务熔断 | 故障检测达到阈值后停止服务调用 |
6 | 服务降级 | 停止原服务调用,使用备选服务,或者立即失败 |
7 | 重试 | 重试调用,需要幂等 |
8 | 补偿 | 失败的后流程中补偿业务损失数据 |