一、服务容错的背景
在微服务开发中,随着各个模块和服务数量的增多,导致整个微服务架构也越来越复杂,所以每个服务健康状况对整个微服务系统的影响也越来越大。而在系统上线之前,我们不可能保证每个服务都能够完美地、毫无差错地一直运行下去,所以我们必须考虑其中一些服务模块儿因为各种原因导致其不能继续运行的情况。除了采取集群部署的方式来降低系统的故障发生率外,我们还希望系统能够拥有实时监控各个服务健康状况、并且能够自动采取一些手段来解决服务出错导致整个微服务系统雪崩的情况。
二、服务容错的常见解决方案
2.1 超时:服务调用方在一定时间未得到响应则放弃请求,在异常时确保整个系统资源的消耗不被占用;
2.2 限流:在服务被调用方限制进入系统的流量,确保在系统的负载范围内,保证系统能够正常运转;
2.3 仓壁模式:资源隔离手段,在调用方使用线程池等方式,限制资源消耗在某个范围之内;
2.4 熔断器: 在调用方,在系统上检测调用,如果发现了某个底层服务故障,则自动熔断,不再调用该服务,隔一段时间再次检测是否恢复,如果恢复则加入集群;
三、Sentinel的流控和熔断
3.1 流控:
- 阀值类型:QPS(每秒查询数)、线程数(调用该服务的线程数)
- 流控模式:
- 直连: 该服务达到限流条件时,直接限流;
- 关联: 当关联的资源达到阈值的时候,就限流自己;
- 链路: 指记录指定链路上的流量(指定资源从入口资源进来的流量,如果达到阈值,就进行限流)
- 流控效果:
- 匀速排队:匀速排队,让请求以匀速的速度通过,阈值类型必须设置为QPS,否则无效;
- 快速失败:直接失败,抛异常 + Warm Up: 根据codeFactor(冷加载因子,默认为3)的值,从阈值/codeFactor,经过预热时长,才打到设置的QPS的阈值。
3.2 熔断:
- 概要:当A服务调用另外一个B服务的失败次数达到一定程度时,则A服务默认关闭的熔断器被打开,后续的一定时间段内将阻断B服务的调用;该时间段过后A服务的熔断器将会发送一个探测请求到B服务:
情况1:若成功,A服务则关闭熔断器;
情况2:若失败,则继续开启熔断器。