大白话详解Spring Cloud服务降级与熔断

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 服务，线程组配置参数如下：