服务雪崩hystrix

2024-01-30 14:56:58

服务雪崩hystrix

https://segmentfault.com/a/1190000005988895

https://www.jianshu.com/p/4ec9368c7349

产生原因

我把服务雪崩的参与者简化为 服务提供者 和 服务调用者, 并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因:

  1. 服务提供者不可用
  2. 重试加大流量
    • 用户重试
    • 代码逻辑重试
  3. 服务调用者不可用
    • 同步等待造成的资源耗尽。当服务调用者使用 同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了.

解决策略

针对造成服务雪崩的不同原因, 可以使用不同的应对策略:

  1. 流量控制
  2. 改进缓存模式
  3. 服务自动扩容
  4. 服务调用者降级服务

流量控制

流量控制 的具体措施包括:

  • 网关限流
  • 用户交互限流
  • 关闭重试

因为Nginx的高性能, 目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制, 由此而来的OpenResty也越来越热门.

用户交互限流的具体措施有: 1. 采用加载动画,提高用户的忍耐等待时间. 2. 提交按钮添加强制等待时间机制.

改进缓存模式

改进缓存模式 的措施包括:

  • 缓存预加载
  • 同步改为异步刷新

服务自动扩容

服务自动扩容 的措施主要有:

AWS的auto scaling

基于阿里云

https://segmentfault.com/a/1190000022031040

前置知识：

  1. ECS：阿里云主机，将jar部署在上面作为一个集群的可用节点。
  2. 镜像：ECS运行中的一个快照，保存了当时所有落盘的文件，不包含内存数据。
  3. 启动模板：包含了硬件资源规格与镜像的启动配置，如果直接将镜像启动为ECS实例将使用镜像中的硬件资源配置。
  4. SLB：负载均衡，通过一定的策略实现流量均摊，并提供健康检查判定节点是否可用，权重0~100，请求越多分摊越均匀。
  5. ESS：弹性伸缩，在流量激增的情况下会根据配置的启动模板增加虚拟ECS(vEVS)，并将vECS加入SLB中，默认权重是50。
  6. NAS：文件存储，可以将硬盘设备挂载到多个主机上共享硬盘中的文件，我们主要用于在自动生成vECS的时候将jar文件更新为最新版本。
搭建步骤

服务雪崩hystrix

  1. 根据已有ECS创建镜像（可以包含已经配置的nginx和jre等数据）

  2. 创建启动模板

    • 根据第1步创建的自定义镜像

    • 网络硬盘不会与镜像一起挂载，需要手动在脚本挂载

      # !/bin/sh
sleep 5

  3. 伸缩组管理配置

    • 最多扩容数量
    • 最少数量
    • 扩容冷却时间（防止频繁创建删除实例）
    • 启动模块（对应第2步）
    • 关联负载均衡（SLB）

  4. 将手动加入的ECS设置为保护状态，防止缩容时被删除

  5. 配置扩容与缩容规则（简单规则为例，cpu使用率==）

  6. 报警任务与规则关联

服务调用者降级服务

服务调用者降级服务 的措施包括:

  • 资源隔离
  • 对依赖服务进行分类
  • 不可用服务的调用快速失败

资源隔离主要是对调用服务的线程池进行隔离.

我们根据具体业务,将依赖服务分为: 强依赖和弱依赖. 强依赖服务不可用会导致当前业务中止,而弱依赖服务的不可用不会导致当前业务的中止.不可用服务的调用快速失败一般通过 超时机制, 熔断器 和熔断后的 降级方法 来实现.

使用Hystrix预防服务雪崩

资源隔离

Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离, 从而避免服务雪崩.
如下图所示, 当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用.

服务雪崩hystrix

熔断器模式

熔断器模式定义了熔断器开关相互转换的逻辑:

服务雪崩hystrix

服务的健康状况 = 请求失败数 / 请求总数.
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.

  1. 当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于设定阈值, 开关则切换为打开状态.
  2. 当熔断器开关打开时, 请求被禁止通过.
  3. 当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.

熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.

命令模式

Hystrix使用命令模式(继承HystrixCommand类)来包裹具体的服务调用逻辑(run方法), 并在命令模式中添加了服务调用失败后的降级逻辑(getFallback).
同时我们在Command的构造方法中可以定义当前服务线程池和熔断器的相关参数. 如下代码所示:

public class Service1HystrixCommand extends HystrixCommand<Response> {
  private Service1 service;
  private Request request;

  public Service1HystrixCommand(Service1 service, Request request){
    supper(
      Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ServiceGroup"))
          .andCommandKey(HystrixCommandKey.Factory.asKey("servcie1query"))
          .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("service1ThreadPool"))
          .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
            .withCoreSize(20))//服务线程池数量
          .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
            .withCircuitBreakerErrorThresholdPercentage(60)//熔断器关闭到打开阈值
            .withCircuitBreakerSleepWindowInMilliseconds(3000)//熔断器打开到关闭的时间窗长度
      ))
      this.service = service;
      this.request = request;
    );
  }

  @Override
  protected Response run(){
    return service1.call(request);
  }

  @Override
  protected Response getFallback(){
    return Response.dummy();
  }
}

在使用了Command模式构建了服务对象之后, 服务便拥有了熔断器和线程池的功能.
服务雪崩hystrix

Hystrix的内部处理逻辑

下图为Hystrix服务调用的内部逻辑:
服务雪崩hystrix

  1. 构建Hystrix的Command对象, 调用执行方法.
  2. Hystrix检查当前服务的熔断器开关是否开启, 若开启, 则执行降级服务getFallback方法.
  3. 若熔断器开关关闭, 则Hystrix检查当前服务的线程池是否能接收新的请求, 若超过线程池已满, 则执行降级服务getFallback方法.
  4. 若线程池接受请求, 则Hystrix开始执行服务调用具体逻辑run方法.
  5. 若服务执行失败, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.
  6. 若服务执行超时, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.
  7. 若服务执行成功, 返回正常结果.
  8. 若服务降级方法getFallback执行成功, 则返回降级结果.
  9. 若服务降级方法getFallback执行失败, 则抛出异常.

Hystrix Metrics的实现

Hystrix的Metrics中保存了当前服务的健康状况, 包括服务调用总次数和服务调用失败次数等. 根据Metrics的计数, 熔断器从而能计算出当前服务的调用失败率, 用来和设定的阈值比较从而决定熔断器的状态切换逻辑. 因此Metrics的实现非常重要.

版本1.4之前的滑动窗口实现

Hystrix在这些版本中的使用自己定义的滑动窗口数据结构来记录当前时间窗的各种事件( 成功,失败,超时,线程池拒绝等)的计数.
事件产生时, 数据结构根据当前时间确定使用旧桶还是创建新桶来计数, 并在桶中对计数器经行修改.
这些修改是多线程并发执行的, 代码中有不少加锁操作,逻辑较为复杂.

服务雪崩hystrix

版本1.5之后的滑动窗口实现

Hystrix在这些版本中开始使用RxJava的Observable.window()实现滑动窗口.RxJava的window使用后台线程创建新桶, 避免了并发创建桶的问题.同时RxJava的单线程无锁特性也保证了计数变更时的线程安全. 从而使代码更加简洁.以下为我使用RxJava的window方法实现的一个简易滑动窗口Metrics, 短短几行代码便能完成统计功能,足以证明RxJava的强大:

@Test
public void timeWindowTest() throws Exception{
  Observable<Integer> source = Observable.interval(50, TimeUnit.MILLISECONDS).map(i -> RandomUtils.nextInt(2));
  source.window(1, TimeUnit.SECONDS).subscribe(window -> {
      int[] metrics = new int[2];
      window.subscribe(i -> metrics[i]++,
      InternalObservableUtils.ERROR_NOT_IMPLEMENTED,
      () -> System.out.println("窗口Metrics:" + JSON.toJSONString(metrics)));
  });
  TimeUnit.SECONDS.sleep(3);
}

总结

通过使用Hystrix,我们能方便的防止雪崩效应, 同时使系统具有自动降级和自动恢复服务的效果.

Sentinel

Sentinel 的侧重点在于：

  • 多样化的流量控制
  • 熔断降级
  • 系统负载保护
  • 实时监控和控制台

线程池隔离

  • 线程池隔离的好处是隔离度比较高，可以针对某个资源的线程池去进行处理而不影响其它资源，但是代价就是线程数目比较多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。
  • 另外，托管的线程切换可能会导致基于 ThreadLocal 的上下文传递丢失的问题（如 Spring 事务管理）。
  • Sentinel 没有提供线程池隔离这样比较重的隔离方式，而是提供了信号量隔离这种比较轻量级的隔离方式。

从Hystrix迁移到alibaba Sentinel

Resilience4j

Sentinel (阿里中间件，13年应用，18年开源) Hystrix（netflix) resilience4j(红薯)
隔离策略 信号量隔离（并发线程数限流） 线程池隔离/信号量隔离 信号量隔离
熔断降级策略 基于响应时间、异常比率、异常数 基于异常比率 基于异常比率、响应时间
实时统计实现 滑动窗口（LeapArray） 滑动窗口（基于 RxJava） Ring Bit Buffer
动态规则配置 支持多种数据源 支持多种数据源 有限支持
扩展性 多个扩展点 插件的形式 接口的形式
基于注解的支持 支持 支持 支持
限流 基于 QPS，支持基于调用关系的限流 有限的支持 Rate Limiter
流量整形 支持预热模式（冷启动）、匀速器模式、预热排队模式 不支持 简单的 Rate Limiter 模式
系统自适应保护 支持 不支持 不支持
控制台 提供开箱即用的控制台，可配置规则、查看秒级监控、机器发现等 简单的监控查看 不提供控制台，可对接其它监控系统
上一篇：SpringCloud Alibaba实战（9：Hystrix容错保护）


下一篇：从架构演进的角度聊聊Spring Cloud都做了些什么？