微服务之服务降级(Hystrix)

最新推荐文章于 2024-04-23 15:36:49 发布

69岁的老程序员

最新推荐文章于 2024-04-23 15:36:49 发布

阅读量865

点赞数

分类专栏： SpringCloud hytrix 文章标签： java

本文链接：https://blog.csdn.net/weixin_48420669/article/details/108414369

版权

SpringCloud 同时被 2 个专栏收录

16 篇文章 1 订阅

订阅专栏

hytrix

1 篇文章 0 订阅

订阅专栏

需求

许多微服务之间存在着复杂的调用链关系，总体配置的openfeign超时时间不能满足需求，需要可以满足配置默认feign超时时间，并且支持指定方法的超时。

选型

熔断降级设计理念
在限制的手段上，Sentinel 和 Hystrix 采取了完全不一样的方法。

Hystrix 通过线程池隔离的方式，来对依赖（在 Sentinel 的概念中对应资源）进行了隔离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成本（过多的线程池导致线程数目过多），还需要预先给各个资源做线程池大小的分配。

Sentinel 对这个问题采取了两种手段:

通过并发线程数进行限制
和资源池隔离的方法不同，Sentinel 通过限制资源并发线程的数量，来减少不稳定资源对其它资源的影响。这样不但没有线程切换的损耗，也不需要您预先分配线程池的大小。当某个资源出现不稳定的情况下，例如响应时间变长，对资源的直接影响就是会造成线程数的逐步堆积。当线程数在特定资源上堆积到一定的数量之后，对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。

通过响应时间对资源进行降级
除了对并发线程数进行控制以外，Sentinel 还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后，所有对该资源的访问都会被直接拒绝，直到过了指定的时间窗口之后才重新恢复。

结论

当前需求只有hystrix信号量级别的隔离才能满足需求。使用hystrix作为熔断降级框架

为什么需要服务降级

在多个微服务之间相互调用的过程中,可能会因为其中的一个服务不可用,导致整个链路崩溃,这时候就需要一个东西事先想好,如果我调用这个服务挂了该怎么办.这就是服务降级软件

模拟需要降级的情况

创建两个服务, provider 和 consumer. provider 提供两个接口

@RestController
public class Controller {

    @GetMapping("/test01")
    public String test01(){
        return "test01";
    }


    @GetMapping("/test02")
    public String test02(){
        try {
            Thread.sleep(3000);
        }catch (Exception e){

        }
        return "test02";
    }
}

consumer 通过 openfeign 请求test01 接口,里面上是秒回的级别
用 jemeter 压测 test02 接口.导致最后请求 test01接口的速度也被拖累

Hystrix

服务降级

修改provider 层,如果该接口时间超过2秒就算异常,使得消费者不在等待

引入pom文件

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>

启动类上添加@EnableHystrix
需要降级的方法上添加注解

@HystrixCommand(fallbackMethod = "back",commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000")
    })
    @GetMapping("/test02")
    public String test02(){
        try {
            Thread.sleep(3000);
        }catch (Exception e){

        }
        return "test02";
    }


    public String back(){
        return "牛逼";
    }

消费者降级 consumer
4. 引入pom文件

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>

启动类上添加@EnableHystrix
配置文件上添加

feign:
  hystrix:
    enabled: true

创建一个feign客户端的实现类,并且在@FeignClient 上指定实现类,实现类上要写上@Component 注解

@FeignClient(value = "provider", fallback = ProviderClientImpl.class)
public interface ProviderClient {
    @GetMapping("/test01")
    String test01();
}

@Component
public class ProviderClientImpl implements ProviderClient {
    public String test01() {
        return "服务降级了";
    }
}

服务熔断

熔断和降级的区别:
熔断是请求直接不会请求到下游服务,而降级是请求到下游服务如果出现异常的兜底策略

熔断个人认为一般是写在生产者,当消费者配置了降级和生产者配置了服务熔断,发声问题的顺序是,在还没熔断之前调用生产者熔断方法,超过熔断阈值之后,调用消费者降级方法.
生产者方法

 @GetMapping("/test03")
    @HystrixCommand(fallbackMethod = "fallback",commandProperties = {
            @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),// 是否开启断路器
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),// 请求次数
            @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"), // 时间窗口期
            @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),// 失败率达到多少后跳闸
    })
    public String test03(Integer value){
        System.out.println("被调用");
        if (value>10){
            int i = 10/0;
        }

        return "test03";
    }

    public String fallback(Integer value){
        return "熔断后返回的友好提示";
    }

当消费者多次调用产生熔断之后,消息直接不会发送到生产者这里来,一段时间之后才会恢复.

原理

在这里插入图片描述

构造一个 HystrixCommand或HystrixObservableCommand对象，用于封装请求，并在构造方法配置请求被执行需要的参数；
执行命令，Hystrix提供了4种执行命令的方法，后面详述；
判断是否使用缓存响应请求，若启用了缓存，且缓存可用，直接使用缓存响应请求。Hystrix支持请求缓存，但需要用户自定义启动；
判断熔断器是否打开，如果打开，跳到第8步；
判断线程池/队列/信号量是否已满，已满则跳到第8步；
执行HystrixObservableCommand.construct()或HystrixCommand.run()，如果执行失败或者超时，跳到第8步；否则，跳到第9步；
统计熔断器监控指标；
走Fallback备用逻辑
返回请求响应

**从流程图上可知道，第5步线程池/队列/信号量已满时，还会执行第7步逻辑，更新熔断器统计信息，而第6步无论成功与否，都会更新熔断器统计信息 **

执行命令的几种方法

Hystrix提供了4种执行命令的方法，execute()和queue() 适用于HystrixCommand对象，而observe()和toObservable()适用于HystrixObservableCommand对象。

execute()

以同步堵塞方式执行run()，只支持接收一个值对象。hystrix会从线程池中取一个线程来执行run()，并等待返回值。

queue()

以异步非阻塞方式执行run()，只支持接收一个值对象。调用queue()就直接返回一个Future对象。可通过 Future.get()拿到run()的返回结果，但Future.get()是阻塞执行的。若执行成功，Future.get()返回单个返回值。当执行失败时，如果没有重写fallback，Future.get()抛出异常。

Hystrix容错

资源隔离

资源隔离主要指对线程的隔离。Hystrix提供了两种线程隔离方式：线程池和信号量。

线程隔离-线程池

Hystrix通过命令模式对发送请求的对象和执行请求的对象进行解耦，将不同类型的业务请求封装为对应的命令请求。如订单服务查询商品，查询商品请求->商品Command；商品服务查询库存，查询库存请求->库存Command。并且为每个类型的Command配置一个线程池，当第一次创建Command时，根据配置创建一个线程池，并放入ConcurrentHashMap，如商品Command：

final static ConcurrentHashMap<String, HystrixThreadPool> threadPools = new ConcurrentHashMap<String, HystrixThreadPool>();
...
if (!threadPools.containsKey(key)) {
    threadPools.put(key, new HystrixThreadPoolDefault(threadPoolKey, propertiesBuilder));
}

在这里插入图片描述
通过将发送请求线程与执行请求的线程分离，可有效防止发生级联故障。当线程池或请求队列饱和时，Hystrix将拒绝服务，使得请求线程可以快速失败，从而避免依赖问题扩散

线程池隔离优缺点

优点：

保护应用程序以免受来自依赖故障的影响，指定依赖线程池饱和不会影响应用程序的其余部分。
可以快速失败，超过了指定超时时间的请求可以直接返回失败

缺点:

通常情况下，线程池引入的开销足够小，不会有重大的成本或性能影响。但对于一些访问延迟极低的服务，如只依赖内存缓存，线程池引入的开销就比较明显了，这时候使用线程池隔离技术就不适合了，我们需要考虑更轻量级的方式，如信号量隔离。

线程隔离-信号量

上面提到了线程池隔离的缺点，当依赖延迟极低的服务时，线程池隔离技术引入的开销超过了它所带来的好处。这时候可以使用信号量隔离技术来代替，通过设置信号量来限制对任何给定依赖的并发调用量。下图说明了线程池隔离和信号量隔离的主要区别：
在这里插入图片描述
使用线程池时，发送请求的线程和执行依赖服务的线程不是同一个，而使用信号量时，发送请求的线程和执行依赖服务的线程是同一个，都是发起请求的线程。

由于Hystrix默认使用线程池做线程隔离，使用信号量隔离需要显示地将属性execution.isolation.strategy设置为ExecutionIsolationStrategy.SEMAPHORE，同时配置信号量个数，默认为10。客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。

信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。

线程池信号量总结

线程池和信号量都支持熔断和限流。相比线程池，信号量不需要线程切换，因此避免了不必要的开销。但是信号量不支持异步，也不支持超时，也就是说当所请求的服务不可用时，信号量会控制超过限制的请求立即返回，但是已经持有信号量的线程只能等待服务响应或从超时中返回，即可能出现长时间等待。线程池模式下，当超过指定时间未响应的服务，Hystrix会通过响应中断的方式通知线程立即结束并返回。

熔断器

Hystrix中的熔断器(Circuit Breaker)在运行过程中会向每个commandKey对应的熔断器报告成功、失败、超时和拒绝的状态，熔断器维护并统计这些数据，并根据这些统计信息来决策熔断开关是否打开。如果打开，熔断后续请求，快速返回。隔一段时间（默认是5s）之后熔断器尝试半开，放入一部分流量请求进来，相当于对依赖服务进行一次健康检查，如果请求成功，熔断器关闭。

熔断器配置

Circuit Breaker主要包括如下6个参数：

1、circuitBreaker.enabled

是否启用熔断器，默认是TRUE。
2 、circuitBreaker.forceOpen

熔断器强制打开，始终保持打开状态，不关注熔断开关的实际状态。默认值FLASE。
3、circuitBreaker.forceClosed
熔断器强制关闭，始终保持关闭状态，不关注熔断开关的实际状态。默认值FLASE。

4、circuitBreaker.errorThresholdPercentage
错误率，默认值50%，例如一段时间（10s）内有100个请求，其中有54个超时或者异常，那么这段时间内的错误率是54%，大于了默认值50%，这种情况下会触发熔断器打开。

5、circuitBreaker.requestVolumeThreshold

默认值20。含义是一段时间内至少有20个请求才进行errorThresholdPercentage计算。比如一段时间了有19个请求，且这些请求全部失败了，错误率是100%，但熔断器不会打开，总请求数不满足20。

6、circuitBreaker.sleepWindowInMilliseconds

半开状态试探睡眠时间，默认值5000ms。如：当熔断器开启5000ms之后，会尝试放过去一部分流量进行试探，确定依赖服务是否恢复。

熔断器工作原理

在这里插入图片描述
熔断器工作的详细过程如下：

第一步，调用allowRequest()判断是否允许将请求提交到线程池

如果熔断器强制打开，circuitBreaker.forceOpen为true，不允许放行，返回。
如果熔断器强制关闭，circuitBreaker.forceClosed为true，允许放行。此外不必关注熔断器实际状态，也就是说熔断器仍然会维护统计数据和开关状态，只是不生效而已。

第二步，调用isOpen()判断熔断器开关是否打开

如果熔断器开关打开，进入第三步，否则继续；
如果一个周期内总的请求数小于circuitBreaker.requestVolumeThreshold的值，允许请求放行，否则继续；
如果一个周期内错误率小于circuitBreaker.errorThresholdPercentage的值，允许请求放行。否则，打开熔断器开关，进入第三步。

第三步，调用allowSingleTest()判断是否允许单个请求通行，检查依赖服务是否恢复

如果熔断器打开，且距离熔断器打开的时间或上一次试探请求放行的时间超过circuitBreaker.sleepWindowInMilliseconds的值时，熔断器器进入半开状态，允许放行一个试探请求；否则，不允许放行。
此外，为了提供决策依据，每个熔断器默认维护了10个bucket，每秒一个bucket，当新的bucket被创建时，最旧的bucket会被抛弃。其中每个blucket维护了请求成功、失败、超时、拒绝的计数器，Hystrix负责收集并统计这些计数器。

69岁的老程序员

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
微服务之服务降级(Hystrix)

服务降级为什么需要服务降级模拟需要降级的情况Hystrix为什么需要服务降级在多个微服务之间相互调用的过程中,可能会因为其中的一个服务不可用,导致整个链路崩溃,这时候就需要一个东西事先想好,如果我调用这个服务挂了该怎么办.这就是服务降级软件模拟需要降级的情况创建两个服务, provider 和 consumer. provider 提供两个接口@RestControllerpublic class Controller { @GetMapping("/test01")
复制链接

扫一扫

专栏目录