服务容错模式

服务容错模式

抄袭自《服务容错模式》

不进行服务容错的危害:

  1. 多个微服务之间存在相互调用,在高并发的情况下,由于某个微服务的不可用,导致所有请求都处在延迟状态,在很短时间内就会耗尽系统资源,造成“雪崩”。
  2. 系统遭受恶意爬虫攻击,在放大效应下没有对下游依赖服务做好限速处理,最终导致下游崩溃。

服务容错的目标:

  1. 一个依赖服务的故障不会严重破坏用户体验。
  2. 系统能够自动/半自动处理故障,具备自我恢复能力。

(一)超时 & 重试 (Timeout & Retry)

  1. 超时模式:常见的有设置网络连接超时时间/一次RPC的响应超时时间,目的是防止当依赖服务出现网络延迟时无期限等待,调用方可以根据事先设计的超时时间中断调用,及时释放关键资源,比如web容器连接数、DB连接数等,避免整个系统资源耗尽导致出现拒绝对外提供服务的情况
  2. 重试模式:超时模式和重试模式结合使用,可以保证上下游的强一致性。重试次数一般限制在3次以内,否则会导致请求响应时间延长,拖累整个系统
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class RetryCommand<T> {
private int maxRetries = 3; //最大重试次数
private long retryInterval = 5; //重试间隔(ms)
private Map<String, Object> params;

//构造器省略

public T command(Map<String, Object> params){
//调用服务
service.doSomethingWithTimeout(params, timeout);
}

//重试
private final T retry() throws RuntimeException{
int count = 0;
while(count < maxRetries){
try{
return command(params);
}catch(Exception e){
count++;
if(count >= maxRetries) break;
}
}
throw new RuntimeException("Command failed on all of"+ maxRetries + " retries");
}

}

(二)限流

《限流算法(漏桶/令牌桶)》


(三)熔断器 & 回退 (Circuit Breaker & Fallback)

Spring Cloud Hystrix中,当一个链路的某个微服务不可用或响应时间太长时,直接熔断该服务的调用,快速返回一个Fallback,用户不需要一直等待,直到检测到该微服务正常响应后才恢复链路

熔断器状态

  1. 闭合(Closed)状态:对目标服务正常调用。给定时间窗口内调用失败次数超过阈值,熔断器切换到Open状态

  2. 断开(Open)状态:对目标服务的请求会返回错误响应,如果设置了Fallback回退方法,会进入Fallback的流程

    熔断器切换到Open状态后,会设置一个计时器,当时钟超过了该时间,则切换到Half Open状态 —— 这么做是为了给系统错误修正的机会

  3. 半断开(Half Open)状态:允许一定数量的请求调用目标服务,相当于服务降级。如果这些请求调用成功,则认为错误已经修正,熔断器切换到Closed状态;如果有请求失败,熔断器切换到Open状态

回退策略

  1. 自定义处理:使用默认数据/本地数据/缓存数据进行临时支撑,也可以将所有请求加入队列,或者使用备用服务获取数据。适用于业务关键流程与严重影响用户体验的场景
  2. 故障沉默(fail-silent):直接返回空值或者缺省值,适用于可降级功能的场景,数据为空也不太影响用户体验
  3. 快速失败(fail-fast):直接抛出异常,适用于数据非强依赖的场景,比如非核心业务的超时处理
-------------本文结束感谢您的阅读-------------

本文标题:服务容错模式

文章作者:DragonBaby308

发布时间:2019年11月04日 - 21:44

最后更新:2020年01月25日 - 13:17

原始链接:http://www.dragonbaby308.com/Service-Fault-Tolerant/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

急事可以使用右下角的DaoVoice,我绑定了微信会立即回复,否则还是推荐Valine留言喔( ఠൠఠ )ノ
0%