五. SpringCloud服务降级与熔断

1. Hystrix断路器概述

1.1 分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败。这就造成有可能会发生服务雪崩。那么什么是服务雪崩呢?

多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务,这就是所谓的“扇出”(像一把打开的折扇)。如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,这就是所谓的”雪崩效应“。也就是系统的 高可用 受到了破坏。

对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源在几秒内饱和。比失败更糟的是,这些应用程序还可能导致 服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发送更过的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便 单个依赖关系的失败,不能取消整个应用程序或系统

所以,通常当发现一个模块下的某个实例失败后,这时候这个模块依然还会接受流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫做雪崩。而面对这种糟糕的问题,我们就应该采取 服务降级、服务熔断 等方式来解决。

1.2 Hystrix是什么

Hystrix是一个用于处理分布式系统的 延迟容错 的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整个服务失败,避免级联故障,以提高分布式系统的弹性

“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似于物理的熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。

1.3 Hystrix作用

主要有服务降级、服务熔断、接近实时的监控、限流、隔离等等,其官方文档参考。当然Hystrix现在已经停更了,虽然有一些替代品,但是学习Hystrix及其里面的思想还是非常重要的!

1.4 Hystrix重要概念

服务降级(Fall Back) 假设微服务A要调用的服务B不可用了,需要服务B提供一个兜底的解决方法,而不是让服务A在那里傻等,耗死。不让客户端等待并立刻返回一个友好提示,比如像客户端提示服务器忙,请稍后再试等。哪些情况会触发服务降级呢?比如 程序运行异常超时服务熔断触发服务降级线程池/信号量打满也会导致服务降级。

服务熔断(Break) 服务熔断就相当于物理上的熔断保险丝。类比保险丝达到最大服务访问后,直接拒绝访问,拉闸断电,然后调用服务降级的方法并返回友好提示。

**服务限流(Flow Limit) ** 秒杀高并发等操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序进行。

2. Hystrix案例

2.1 服务提供者8003模块

建Module

cloud-provider-hystrix-payment8003

pom.xml

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

yml配置文件 / 主启动类

server:
  port: 8003

spring:
  application:
    name: cloud-provider-hystrix-payment

eureka:
  client:
    register-with-eureka: true
    fetchRegistry: true
    service-url:
      # 单机版
      defaultZone: http://localhost:7001/eureka # 入驻的服务注册中心地址
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8003 {
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8003.class,args);
    }
}

业务类

  • service
@Service
public class PaymentService {
    /**能够正常访问的方法*/
    public String paymentInfo_OK(Integer id) {
        return "线程池: " + Thread.currentThread().getName()
                + " paymentInfo_OK,id: " + id + "\t" + "哈~";
    }

    /**模拟出错的方法*/
    public String paymentInfo_FAIL(Integer id) {
        int timeNumber = 3;
        //暂停几秒钟线程,程序本身没有错误,就是模拟超时
        try {
            TimeUnit.SECONDS.sleep(timeNumber);
        }catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "线程池: " + Thread.currentThread().getName()
                + " paymentInfo_FAIL,id: " + id + "\t" + "哈~ "
                + "耗时" + timeNumber + "s";
    }
}
  • controller
@RestController
@Slf4j
@RequestMapping("/payment/hystrix")
public class PaymentController {
    @Resource
    private PaymentService paymentService;

    @Value("$server.port")
    private String serverPort;

    @GetMapping("ok/{id}")
    public String paymentInfo_OK(@PathVariable("id")Integer id) {
        String result = paymentService.paymentInfo_OK(id);
        log.info("===> result: " + result);
        return result;
    }

    @GetMapping("timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id")Integer id) {
        String result = paymentService.paymentInfo_FAIL(id);
        log.info("===> result: " + result);
        return result;
    }
}

也就是说cloud-provider-hystrix-payment服务提供了两个方法,paymentInfo_OK 方法可以很快访问,paymentInfo_TimeOut 方法我们模拟了一个复杂的业物逻辑,通过线程休眠的方式使其模拟一个需要执行3秒的服务方法。

在启动了注册中心和8003服务后,我们对服务的 paymentInfo_OK(下面用OK代替) 和 paymentInfo_TimeOut(下面用TO代替)分别进行访问,我们发现http://localhost:8003/payment/hystrix/ok/1 可以很快的访问,而http://localhost:8003/payment/hystrix/timeout/1 每次访问大约需要3秒的时间。

上述为根基平台,开始演示:正确 => 错误 => 降级熔断 => 正确

2.2 8003高并发测试

服务提供方自测压力测试:

需要3秒的复杂业务逻辑 TO 访问时,需要时间很少的 OK 是完全可以正常访问的,但是在高并发的情况下,也就是说 TO 有很多访问量的时候,OK 还能够这么正常的访问吗?下面我们用 Jmeter 进行高并发压力测试,用20000个请求都去访问 TO 服务。

在 Jmeter 中新建一个线程组:测试Hystrix用来模拟高并发访问 TO 服务,线程组配置参数如下:

image-20210227003830057

然后我们用该线程组发送HTTP请求给 TO 服务,创建如下的HTTP请求进行压力测试:

image-20210227004313624

我们观察8001服务的后端控制台,可以看到对 TO 服务进行了大量的访问。而此时我们再去访问 OK 服务时什么样的呢?=> 可以看到,OK 服务无法像之前一样很快能够得到访问,这里我们模拟的是20000的访问量(没敢模拟数字太大的访问量,怕把系统直接搞死),实际中可能会有远大于20000的访问量,当访问量更多的时候,甚至可能卡死服务,原因就是 Tomcat的默认的工作线程数被打满了,没有多余的线程来分解压力和处理

而刚才做的压力测试还只是服务提供方8001自己实现的测试,如果此时是外部的服务消费方80来访问该服务,那么服务消费方只能够进行干等,消费方显然会对这样的等待时间不满意,服务提供方很有可能直接被拖死。我们发现8001自测都会出现问题,那如果我们再用服务消费方测试呢?

2.3 服务消费者80模块进行压力测试

新建一个Module:cloud-consumer-feign-hystrix-order80作为服务消费方,服务消费方利用feign访问提供方的服务,编写对应的service接口如下:

@Component
@FeignClient("CLOUD-PROVIDER-HYSTRIX-PAYMENT")
public interface PaymentHystrixService {

    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_FAIL(@PathVariable("id") Integer id);
}

然后编写其Controller:

@RestController
@Slf4j
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_OK(id);
        return result;
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_FAIL(id);
        return result;
    }
}

将80服务启动,用http://localhost/consumer/payment/hystrix/ok/1 对服务提供方的 OK 服务进行访问,再进行压力测试,和之前一样,无法迅速访问该服务,如果压力测试中的线程数更多的时候,很可能会造成超时错误,出现以下错误提示:

image-20210227202938314

故障原因:8003同一层次的其他接口服务被困死,因为Tomcat线程池里面的工作线程已经被挤占完毕,80此时再调用8003,必然导致客户端访问响应缓慢。正是因为出现了这种现象,所以我们才需要 服务降级、容错、服务限流 等技术。

2.4 发现问题

要解决的问题:

  • 超时导致服务器变慢(转圈) => 超时不再等待
  • 出错(宕机或程序运行出错) => 出错要有兜底

解决方案:

  • 对方服务(8003)超时了,调用者(80)不能一直卡死等待,必须有服务降级
  • 对方服务(8003)宕机了,调用者(80)不能一直卡死等待,必须有服务降级
  • 对方服务(8003)OK,调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者),自己处理降级

3. Hystrix服务降级Fall Back

3.1 服务端服务提供方的服务降级

降级的配置用 @HystrixCommand 注解,在服务提供方自身找问题,设置自身调用超时时间的峰值,在峰值内可以正常运行,超过了峰值需要有兜底的方法处理,用作服务降级。

首先在服务提供方的业务类上启用 @HystrixCommand实现报异常后如何处理,也就是一旦调用服务方法失败并抛出了错误信息后,会自动调用 @HystrixCommand 标注好的fallbackMethod服务降级方法。在服务提供方的service中我们修改 TO 服务:

@Service
public class PaymentService {
    /**能够正常访问的方法*/
    public String paymentInfo_OK(Integer id) {
        return "线程池: " + Thread.currentThread().getName()
                + " paymentInfo_OK,id: " + id + "\t" + "哈~";
    }

    /**模拟出错的方法*/
    @HystrixCommand(fallbackMethod = "paymentInfo_FailHandler",
                    commandProperties = {
            @HystrixProperty(
                    name = "execution.isolation.thread.timeoutInMilliseconds",
                    value = "3000")
    })
    public String paymentInfo_FAIL(Integer id) {
        //int age = 10/0; //模拟异常,也会兜底
        int timeNumber = 5;
        
        //暂停几秒钟线程,程序本身没有错误,就是模拟超时
        try {
            TimeUnit.SECONDS.sleep(timeNumber);
        }catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "线程池: " + Thread.currentThread().getName()
                + " paymentInfo_FAIL,id: " + id + "\t" + "哈~ "
                + "耗时" + timeNumber + "s";
    }

    /** 定制服务降级方法*/
    public String paymentInfo_FailHandler(Integer id) {
        return "系统忙,请稍后再试";
    }
}

然后在主启动类上添加 @EnableCircuitBreaker 注解对熔断器进行激活,TO服务的访问时间5秒,而我们用Hystrix配置的时间峰值为3秒,也就是当服务超时或服务出错时,会访问我们设置的fallbackMethod服务降级方法,再次访问TO服务,我们发现其执行的方法确实为服务降级方法:

image-20210227234449381

注意:我们自己配置过的热部署方式对Java代码的改动明显,但对 @HystrixCommand内属性的修改建议重启微服务(有时不能及时生效)

3.2 客户端服务消费方的服务降级

既然服务的提供方可以进行降级保护,那么服务的消费方,也可以更好的保护自己,也可以对自己进行降级保护,也就是说Hystrix服务降级既可以放在服务端(服务提供方),也可以放在客户端(服务消费方),但是!通常是用客户端做服务降级,下面在服务消费方即客户端配置自己的服务降级保护,修改80消费方的配置文件,添加如下配置已使其支持Hystrix:

feign:
  hystrix:
    enabled: true

在80消费方的主启动类上添加 @EnableHystrix 激活Hystrix服务。然后在80的Controller中同样加入@HystrixCommand注解已实现服务降级:

@RestController
@Slf4j
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_OK(id);
        return result;
    }


    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    @HystrixCommand(fallbackMethod = "paymentInfo_FailHandler",
            commandProperties = {
                    @HystrixProperty(
                            name = "execution.isolation.thread.timeoutInMilliseconds",
                            value = "1500")
            })
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_FAIL(id);
        return result;
    }

    /** 定制服务降级方法*/
    public String paymentInfo_FailHandler(Integer id) {
        return "我是消费者80,系统忙,请稍后再试";
    }
}

也就是说如果消费方访问服务提供方的时间超过了1.5秒,那么就会访问自己的降级服务方法。

3.3 统一全局服务降级方法

而当前的这种处理方式是有问题的,也就是每个业务方法都对应了一个服务降级方法,这会导致代码膨胀,所以我们应该定义一个统一的服务降级方法,统一的方法和自定义的方法分开。而且我们将服务降级方法和业务逻辑混合在了一起,这会导致代码混乱,业务逻辑不清晰。

对于第一个问题,我们可以用feign接口中的 @DefaultProperties(defaultFallback = "") 注解来配置全局的服务降级方法,也就是说 自己配置过@HystrixCommand(fallbackMethod = "")fallbackMethod方法的采用自己配置的服务降级方法,而没有配置过的就采用@DefaultProperties(defaultFallback = "") 配置的全局的服务降级方法。这样的话通用的服务降级方法和独享的服务降级方法分开,避免了代码膨胀,合理减少了代码量,修改服务消费方80的Controller入下:

@RestController
@Slf4j
//没有特别指明就用这个统一的
@DefaultProperties(defaultFallback = "payment_Global_FailHandler")
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_OK(id);
        return result;
    }


    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    //特别指明使用哪一个兜底方法
//    @HystrixCommand(fallbackMethod = "paymentInfo_FailHandler",
//            commandProperties = {
//                    @HystrixProperty(
//                            name = "execution.isolation.thread.timeoutInMilliseconds",
//                            value = "1500")
//    })
    @HystrixCommand //没有具体指明就使用全局的
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_FAIL(id);
        return result;
    }

    /** 定制服务降级方法*/
    public String paymentInfo_FailHandler(Integer id) {
        return "我是消费者80,系统忙,请稍后再试";
    }

    /**
     * 全局服务降级方法
     * @return
     */
    public String payment_Global_FailHandler() {
        return "全局异常处理信息";
    }
}

这里需要注意的是,无论是否配置了定制服务降级方法,都要在其服务上加入注解 @HystrixCommand, 否则服务降级和该服务没关系。

而对于第二个问题, 我们可以为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦,我们的80客户端已经有了PaymentHystrixService接口,我们新建一个类PaymentFallbackService实现该接口,并重写接口中的方法,为接口里的方法进行异常处理,并且我们在PaymentHystrixService@FeignClient注解中声明其服务降级方法所在的类:

@Service
//当出现错误是到PaymentFallbackService类中找服务降级方法
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT",
              fallback = PaymentFallbackService.class)
public interface PaymentHystrixService {

    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_FAIL(@PathVariable("id") Integer id);
}
@Service
public class PaymentFallbackService implements PaymentHystrixService{
    @Override
    public String paymentInfo_OK(Integer id) {
        return "PaymentHystrixService paymentInfo_OK出现异常";
    }

    @Override
    public String paymentInfo_FAIL(Integer id) {
        return "PaymentHystrixService paymentInfo_Fail出现异常";
    }
}

然后我们将Controller中耦合的代码都取消:

@RestController
@Slf4j
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_OK(id);
        return result;
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentInfo_FAIL(id);
        return result;
    }
}

然后我们关闭8001服务提供方服务,模拟服务器宕机,在服务访问出现错误时,访问了我们配置的PaymentFallbackService类中的服务降级方法,这样就实现了代码的解耦,使业务逻辑不再混乱。

4. Hystrix服务熔断Break

4.1 熔断机制概述

服务的降级 => 进而熔断 => 恢复调用链路

熔断机制是应对雪崩效应的一种微服务链路保护机制,当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,也就是说服务熔断会导致服务降级,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后,恢复调用链路。也就是说,服务熔断在服务好了之后会重新允许访问服务。

在SpringCloud框架中,熔断机制通过Hystrix实现。Hystrix会监控微服务间的调用状况,当失败的调用到一定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。熔断机制的注解是 @HystrixCommand。关于熔断机制,具体可以参考论文CircuitBreaker

image-20210228140850191
4.2 实例

在8003服务提供方的Service中添加如下代码:

/**
 * 服务熔断
 * fallbackMethod                               服务降级方法
 * circuitBreaker.enabled                       是否开启断路器
 * circuitBreaker.requestVolumeThreshold        请求次数
 * circuitBreaker.sleepWindowInMilliseconds     时间窗口期
 * circuitBreaker.errorThresholdPercentage      失败率达到多少后跳闸
 *
 * 以下配置意思是在10秒时间内请求10次,如果有6次是失败的,就触发熔断器
 *
 * 注解@HystrixProperty中的属性在com.netflix.hystrix.HystrixCommandProperties类中查看
 */
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_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 paymentCircuitBreaker(@PathVariable("id") Integer id) {
    if (id < 0) {
        throw new RuntimeException("===> id 不能为负数");
    }
    //hutool工具类的使用,等价于UUID.randomUUID().toString()
    String serialNumber = IdUtil.simpleUUID();
    return Thread.currentThread().getName() + " 调用成功,流水号: " + serialNumber;
}

/**
 * 服务熔断触发的服务降级方法
 * @param id
 * @return
 */
public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {
    return "id 不能为负数,请稍后再试。id:" + id;
}

@HystrixCommand 注解中配置熔断机制的参数,配置的参数含义如下:

属性名 含义 默认值
circuitBreaker.enabled 是否开启断路器 true
circuitBreaker.requestVolumeThreshold 请求次数 20次
circuitBreaker.sleepWindowInMilliseconds 时间窗口期 5000ms
circuitBreaker.errorThresholdPercentage 失败率达到多少后跳闸 50%

这些属性名的具体含义以及其默认值可以在 com.netflix.hystrix.HystrixCommandProperties 类中进行查看。而我们在service中配置的意思就是在10秒时间内请求10次,如果有6次是失败的,就触发熔断器

在Controller中添加该服务:

@GetMapping("circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Long id) {
    String result = paymentService.paymentCircuitBreaker(id);
    log.info("====> result:" + result);
    return result;
}
4.3 测试

根据我们的业物逻辑,也就是当我们的id为整数时,服务可以正常访问,而当id为负数时,访问服务出错。我们先访问 http://localhost:8003/payment/hystrix/circuit/11 代表正确的服务请求,可以发现一切正常!

然后我们进行大量的错误访问,强行触发服务熔断,然后在进行正确的访问。我们发现在进行超出我们阈值的错误访问后,触发了服务熔断,即使再进行正确的访问也无法进行,但是一定时间后,正确的服务访问又可以顺利进行,这就是服务熔断的整体过程:在触发了服务熔断后,先进行服务的降级,再逐渐恢复调用链路

4.4 总结
image-20210228142306949

结合官网中对熔断机制的描述,其熔断过程可以如下描述:

熔断器打开和关闭的精确方式如下:

  • 假设电路上的访问达到某个阈值(HystrixCommandProperties.circuitBreakerRequestVolumeThreshold())…
  • 并假设误差百分比超过阈值误差百分比(HystrixCommandProperties.circuitBreakerErrorThresholdPercentage())…
  • 然后,断路器从CLOSEDOPEN,触发熔断机制。
  • 当它断开时,它会使针对该断路器的所有请求短路。
  • 经过一段时间(HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds())后,下一个单个请求被允许通过(这是HALF-OPEN状态)。如果请求失败,断路器将OPEN在睡眠窗口期间返回到该状态。如果请求成功则断路器切换到CLOSED,并且第一条中的逻辑再次接管。

也就是在熔断机制中,熔断器分为三个状态:

状态 说明
熔断器打开OPEN 请求不再进行调用当前服务,内部设置时钟一般为MTTR(平均故障处理时间),当打开时长达到所设时钟则进入半熔断状态(HALF-OPEN)。
熔断器关闭CLOSED 熔断关闭不会对服务进行熔断。
熔断器半开HALF-OPEN 部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断。

下面是官网上的熔断器流程图:20200522001425174

那么熔断器在什么情况下开始起作用呢?

涉及到熔断器的三个重要参数:快照时间窗,请求总数阈值,错误百分比阈值

  • 快照时间窗口期circuitBreaker.sleepWindowInMilliseconds:熔断器是否打开需要统计一些请求和错误数据,而统计的时间范围就是快找时间窗,默认为最近的10秒;

  • 请求总数阈值circuitBreaker.requestVolumeThreshold:在快照时间窗内,必须满足请求总数阈值才有资格触发熔断,默认为20次,这意味着在快照时间窗规定的时间内,如果该Hystrix命令的调用次数不足20次,即使所有请求都超时或其他原因失败,熔断器都不会打开;

  • 错误百分比阈值circuitBreaker.errorThresholdPercentage:当请求总数在快照时间窗内超过了阈值,且在这些调用中,超过错误百分比阈值比例的错误调用,熔断器就会打开。

在熔断器打开后

熔断器打开后再有请求调用的时候,将不会调用主逻辑,而是直接调用服务降级的方法,实现了自动发现错误并将降级逻辑切换为主逻辑,减少响应延迟的效果。

原来的主逻辑如何恢复呢? => 当熔断器打开后,对主逻辑进行熔断之后,Hystrix会启动一个 休眠时间窗 , 在这个时间窗内,降级逻辑是临时的主逻辑,当休眠时间窗到期,熔断器会进入半开状态,释放一次请求到原来的主逻辑上,如果此次请求能够正常访问,则熔断器会进入闭合状态,从而恢复主逻辑,如果注册请求依然有问题,则熔断器继续保持打开状态,并且休眠时间窗重新计时。

Hystrix所有常用配置

image-20210228161057425 image-20210228161128573

服务限流在Alibaba的Sentinel框架中会详解

5. Hystrix工作流程

官网说明(Hystrix怎么实操降级熔断限流

整体的Hystrix工作流程图入下:

20200522001442973

步骤说明:

image-20210228160554789

6. Hystrix服务监控Hystrix Dashboard

6.1 理解

除了隔离依赖服务的调用以外,Hystrix还提供了准实时的调用监控——Hystrix Dashboard,Hystrix会持续的记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求,多少成功,多少失败等。SpringCloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。

6.2 使用步骤

新建Module:cloud-consumer-hystrix-dashboard9001作为Hystrix Dashboard服务

添加Hystrix Dashboard的依赖:

<dependencies>
    <!-- Hystrix Dashboard -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
    </dependency>
    <!-- actuator监控 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <!-- 通用配置 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <scope>runtime</scope>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

写配置文件application.yml,加个端口即可:

server:
  port: 9001

编写主启动类,在主启动类上添加@EnableHystrixDashboard注解开启Hystrix Dashboard功能:

@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboardMain9001.class);
    }
}

注意:所有的服务提供方微服务(如我们的8001/8002/8003)都需要监控依赖配置:

<!--actuator监控信息完善-->
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

访问 http://localhost:9001/hystrix 我们就可以看见Hystrix Dashboard的图形化界面

注意:新版本Hystrix需要在主启动类中指定监控路径(否则会报错:Unable to connect to Command Metric Stream)。为了让服务提供方的服务能被Hystrix Dashboard监控到,需要在提供方服务的主启动类中添加如下配置:

/**
 * 此配置是为了服务监控而配置,与服务容错本身无关,springcloud升级后的坑
 * ServletRegistrationBean因为springboot的默认路径不是"/hystrix.stream",
 * 只要在自己的项目里配置上下面的servlet就可以了
 */
@Bean
public ServletRegistrationBean getServlet() {
    HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
    ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
    registrationBean.setLoadOnStartup(1);
    registrationBean.addUrlMappings("/hystrix.stream");
    registrationBean.setName("HystrixMetricsStreamServlet");
    return registrationBean;
}

在Hystrix Dashboard的图形化界面中输入要监控的服务提供者:

image-20210228154411594

下面就是Dashboard对服务的监控状态:

image-20210228154635386

如何看?

  • 七色
  • 一圈 实现圆共有两种含义。它通过颜色的变化代表了实例的健康程度,它的健康度从绿色<黄色<橙色<红色递减。该实心圆除了颜色的变化之外,它的大小也会根据实例的请求流量发生变化,流量越大该实心圆也就越大。所以通过该实心圆的展示,就可以在大量的实例中快速的发现 故障实例和高压力实例。
  • 一线 曲线用来记录2分钟内流量的相对变化,可以通过它来观察到流量的上升和下降趋势
  • 整图说明1
image-20210228155330038
  • 整图说明2
image-20210228155431090
  • 一些复杂的情况
image-20210228155537514
posted @ 2021-02-28 16:14  MPolaris  阅读(264)  评论(0编辑  收藏