1、分布式系统面临的问题

**
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免失败！

2、服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”，如果扇出的链路上某个微服务的调用响应时间过长，或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

SpringCloud08：Hystrix服务熔断与降级 - 图1

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

我们需要，弃车保帅！

3、什么是Hystrix？

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

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

SpringCloud08：Hystrix服务熔断与降级 - 图2

4、Hystrix能干嘛？

  • 服务降级
  • 服务熔断
  • 服务限流
  • 接近实时的监控
  • …

当一切正常时，请求流可以如下所示：

SpringCloud08：Hystrix服务熔断与降级 - 图3

当许多后端系统中有一个潜在阻塞服务时，它可以阻止整个用户请求：

SpringCloud08：Hystrix服务熔断与降级 - 图4

随着大容量通信量的增加，单个后端依赖项的潜在性会导致所有服务器上的所有资源在几秒钟内饱和。

应用程序中通过网络或客户端库可能导致网络请求的每个点都是潜在故障的来源。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，从而备份队列、线程和其他系统资源，从而导致更多跨系统的级联故障。

SpringCloud08：Hystrix服务熔断与降级 - 图5

当使用Hystrix包装每个基础依赖项时，上面的图表中所示的体系结构会发生类似于以下关系图的变化。每个依赖项是相互隔离的，限制在延迟发生时它可以填充的资源中，并包含在回退逻辑中，该逻辑决定在依赖项中发生任何类型的故障时要做出什么样的响应

SpringCloud08：Hystrix服务熔断与降级 - 图6

官网资料：https://github.com/Netflix/Hystrix/wiki

5、服务熔断

什么是服务熔断?

熔断机制是赌赢雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阀值缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是：@HystrixCommand。

服务熔断解决如下问题：

  • 当所依赖的对象不稳定时，能够起到快速失败的目的；
  • 快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。

入门案例

新建springcloud-provider-dept-hystrix-8001模块并拷贝springcloud-provider-dept–8001内的pom.xml、resource和Java代码进行初始化并调整。

导入hystrix依赖

  1. <!--Hystrix-->
  2. <dependency>
  3.     <groupId>org.springframework.cloud</groupId>
  4.     <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
  5. </dependency>

修改描述配置信息：再熔断的时候区别于没有熔断机制的8001服务提供者提供的服务

  1. instance:
  2.   instance-id: springcloud-provider-dept-hystrix-8001 #修改Eureka上的默认描述信息

修改原来的controller，比如这里我们用按照id查询部门信息的方法举例子，我们让这个方法出错的时候就去调用我们备用的方法给前端返回信息(这就是使用hystrix实现的熔断机制，当原方法崩溃/报错不能正常提供服务的时候，直接切换备用的方法继续为客户端提供服务，而不是向客户端返回报错信息)

直接在方法queryDeptById()上加上注解@HystrixCommand，这个注解需要传递一个参数fallbackMethod，即失败的时候调用的方法的名称

  1. @GetMapping("/dept/get/{id}")
  2. @HystrixCommand(fallbackMethod = "hystrixGet")
  3. public Dept queryById(@PathVariable("id") Long id) {
  4.     Dept dept = deptService.queryById(id);
  5.     if (dept == null) {
  6.         throw new RuntimeException("id=>"+id+"，不存在该用户，或者信息无法找到~");
  7.     }
  8.     return dept;
  9. }
  11. //备选方法
  12. public Dept hystrixGet(@PathVariable("id") Long id){
  13.     return new Dept()
  14.             .setDeptno(id)
  15.             .setDname("id=>"+id+"没有对应的信息，null--@Hystrix")
  16.             .setDb_source("no this database in MySQL");
  17. }

注意：我们定义的hystrix用于在原来服务者提供的按照id查询部门信息的方法崩溃/报错的时候替换它继续提供服务的方法的定义除了方法名称，其他的应该和原方法保持一致，这是为了返回的数据仍是原来的数据类型；上面熔断处理方法返回的是一个我们临时new出来的Dept对象，这个对象的属性都是我们设置的提示信息，用于正常的结束本次消费者对于服务的请求并返回给消费者提示信息

注意：上面我们直接返回一个消费者期望的Dept对象，或者说是原服务相同的数据类型的数据，比我们直接抛出异常然后再捕获异常再返回给消费者来的好

注意：异常抛出必须有，否则hystrix不能发现这个方法执行的时候出现了异常

去这个model的入口程序/主启动类上加上注解@EnableXXX（@EnableHystrix继承了@EnableCircuitBreaker）

  1. @SpringBootApplication
  2. @EnableEurekaClient //EnableEurekaClient 客户端的启动类，在服务启动后自动向注册中心注册服务
  3. @EnableDiscoveryClient //服务发现
  4. @EnableCircuitBreaker  //开启熔断器，即添加对熔断的支持
  5. public class HystrixDeptProvider_8001 {
  6.     public static void main(String[] args) {
  7.         SpringApplication.run(HystrixDeptProvider_8001.class, args);
  8.     }
  9. }

测试：

可以发现我们的服务以及注册进去SpringCloud08：Hystrix服务熔断与降级 - 图7

查询一个存在我数据：

SpringCloud08：Hystrix服务熔断与降级 - 图8

查询一个不存在的数据：

SpringCloud08：Hystrix服务熔断与降级 - 图9

查询没熔断的8001：

SpringCloud08：Hystrix服务熔断与降级 - 图10

使用Hystrix实现熔断机制虽然效果很好，但是加大了增高开发的代码量，因为服务者每新增一个向外体提供服务的方法，我们就需要对应的为这个方法新增一个hystrix的熔断机制的备份方法，或许可以出现多个方法使用一个hystrix的熔断机制的备份方法，但是大多数情况下我们还是要针对不同的情境返回不同的提示信息，所以代码量还是会增高

显式提供服务的服务器的IP

SpringCloud08：Hystrix服务熔断与降级 - 图11

修改配置文件：

  1. instance:
  2.   instance-id: springcloud-provider-dept-hystrix-8001 #修改Eureka上的默认描述信息
  3.   prefer-ip-address: true #显式显示ip地址，默认false

SpringCloud08：Hystrix服务熔断与降级 - 图12

小结

  • Hystrix使用步骤
    • 编写hystrix熔断之后的备用方法
    • 使用注解@HystrixCommand指定熔断之后调用的方法的名称
    • 使用注解@EnableCircuitBreaker开启model的熔断器
  • Hystrix对于用户体验更好，但是代码量增加
  • 可以修改监控页面上对应的服务的Status字段下面超链接显示的地址为IP，而不是localhostXXX

6、服务降级

  • 服务降级是指当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系统资源让给优先级高的服务
  • 资源有限，而请求是无限的。如果在并发高峰期，不做服务降级处理，一方面肯定会影响整体服务的性能，严重的话可能会导致宕机某些重要的服务不可用。所以，一般在高峰期，为了保证核心功能服务的可用性，都要对某些服务降级处理。比如当双11活动时，把交易无关的服务统统降级，如查看蚂蚁深林，查看历史订单等等
  • 服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用
  • 降级的方式可以根据业务来，可以延迟服务，比如延迟给用户增加积分，只是放到一个缓存中，等服务平稳之后再执行 ；或者在粒度范围内关闭服务，比如关闭相关文章的推荐

SpringCloud08：Hystrix服务熔断与降级 - 图13

由上图可得，当某一时间内服务A的访问量暴增，而B和C的访问量较少，为了缓解A服务的压力，这时候需要B和C暂时关闭一些服务功能，去承担A的部分服务，从而为A分担压力，叫做服务降级。

服务降级需要考虑的问题

  • 1）那些服务是核心服务，哪些服务是非核心服务
  • 2）那些服务可以支持降级，那些服务不能支持降级，降级策略是什么
  • 3）除服务降级之外是否存在更复杂的业务放通场景，策略是什么？

自动降级分类

1）超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况

2）失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况

3）故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）

4）限流降级：秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

入门案例

在springcloud-api模块下的service包中创建一个实现FallbackFactory接口的实现类DeptClientServiceFallbackFactory

  1. @Component
  2. public class DeptClientServiceFallbackFactory implements FallbackFactory {
  3.     @Override
  4.     public DeptClientService create(Throwable throwable) {
  5.         return new DeptClientService() {
  6.             @Override
  7.             public boolean addDept(Dept dept) {
  8.                 return false;
  9.             }
  11.             @Override
  12.             public Dept queryById(Long id) {
  13.                 return new Dept()
  14.                         .setDeptno(id)
  15.                         .setDname("id=>" + id + "没有对应的信息，客户端提供了降级的信息，这个服务现在已经被关闭")
  16.                         .setDb_source("没有数据~");
  17.             }
  19.             @Override
  20.             public List<Dept> queryAll() {
  21.                 return null;
  22.             }
  23.         };
  24.     }
  25. }

在DeptClientService中指定降级配置类DeptClientServiceFallBackFactory

  1. @Component
  2. //@FeignClient(value = "SPRINGCOULD-PROVIDER-DEPT")
  3. @FeignClient(value = "SPRINGCOULD-PROVIDER-DEPT",fallbackFactory = DeptClientServiceFallbackFactory.class)
  4. public interface DeptClientService {
  6.     @PostMapping("/dept/add")
  7.     boolean addDept(Dept dept);
  9.     @GetMapping("/dept/get/{id}")
  10.     Dept queryById(@PathVariable("id") Long id);
  12.     @GetMapping("/dept/list")
  13.     List<Dept> queryAll();
  14. }

去使用Feign作为负载均衡的消费者的model中的配置文件中开启Hystrix的降级服务

  1. server:
  2.   port: 80
  4. # Eureka配置
  5. eureka:
  6.   client:
  7.     register-with-eureka: false # 不向 Eureka注册自己
  8.     service-url: # 从三个注册中心中随机取一个去访问
  9.       defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
  11. feign:
  12.   hystrix:
  13.     enabled: true #只需要设置该属性就可以开启该消费者model的hystrix服务降级

小结

  • 通过上面的案例我们大致可以明白服务降级的作用，以及它的实现
  • 上面的例子在实现服务降级的时候只是在公用的数据model springcould-api中实现了接口FallbackFactory，实现的方法create()返回的数据类型为DeptClientService，即前面我们为了实现Feign定义的一个接口对象，但是接口不能直接new，所以我们就在方法create()中实现了接口DeptClientService，为每一个方法定义了服务降级之后再被访问的时候返回的数据
  • 然后我们就需要去需要去对应的这个接口的注解@FeignClient中传入参数fallbackFactory，值就是上面我们实现接口FallbackFactory的类的class对象
  • 最后就是去使用了Feign作为负载均衡的消费者模块中的配置文件开启hystrix的服务降级功能
  • 在测试的流程中，在正常的情况下(开启了服务降级的消费者模块对应消费的服务提供者模块正常运行的情况下)，消费者可以正常的通过Feign的接口方式对于服务进行消费，但是一旦提供该服务的服务器不再对外提供服务的时候，即我们在IDEA中关闭了这个微服务的时候，再次请求该微服务中提供的任何服务功能，返回的都是一开始在接口FallbackFactory中定义好的提示信息
  • 注意：整个实现流程中，我们并没有修改服务提供者的任何代码，只是在公共数据模块springcould-api中添加了一个实现接口FallbackFactory的类，在Feign接口的注解@FeignClient上添加了一个传入的参数，在使用Feign的消费者模块中开启了Hystrix的服务降级功能，然后就开启的服务进行了测试

服务熔断和降级的对比

  • 服务熔断—>服务端：某个服务超时或异常，引起熔断~，类似于保险丝(自我熔断)
  • 服务降级—>客户端：从整体网站请求负载考虑，当某个服务熔断或者关闭之后，服务将不再被调用，此时在客户端，我们可以准备一个 FallBackFactory ，返回一个默认的值(缺省值)。会导致整体的服务下降，但是好歹能用，比直接挂掉强。
  • 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
  • 实现方式不太一样，服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断。

熔断，降级，限流：

限流：限制并发的请求访问量，超过阈值则拒绝；

降级：服务分优先级，牺牲非核心服务（不可用），保证核心服务稳定；从整体负荷考虑；

熔断：依赖的下游服务故障触发熔断，避免引发本系统崩溃；系统自动执行和恢复

7、Dashboard 流监控

新建springcloud-consumer-hystrix-dashboard模块

pom.xml

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project xmlns="http://maven.apache.org/POM/4.0.0"
  3.          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4.          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  5.     <parent>
  6.         <artifactId>spring-cloud-study</artifactId>
  7.         <groupId>com.godfrey</groupId>
  8.         <version>1.0-SNAPSHOT</version>
  9.     </parent>
  10.     <modelVersion>4.0.0</modelVersion>
  12.     <artifactId>springcloud-consumer-hystrix-dashboard</artifactId>
  14.     <dependencies>
  15.         <dependency>
  16.             <groupId>com.godfrey</groupId>
  17.             <artifactId>springcloud-api</artifactId>
  18.             <version>1.0-SNAPSHOT</version>
  19.         </dependency>
  20.         <dependency>
  21.             <groupId>org.springframework.boot</groupId>
  22.             <artifactId>spring-boot-starter-web</artifactId>
  23.         </dependency>
  24.         <!--erueka-服务注册与发现-->
  25.         <dependency>
  26.             <groupId>org.springframework.cloud</groupId>
  27.             <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
  28.         </dependency>
  29.         <!--actuator完善监控信息-->
  30.         <dependency>
  31.             <groupId>org.springframework.boot</groupId>
  32.             <artifactId>spring-boot-starter-actuator</artifactId>
  33.         </dependency>
  34.         <!--Hystrix-->
  35.         <dependency>
  36.             <groupId>org.springframework.cloud</groupId>
  37.             <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
  38.         </dependency>
  39.         <!--Dashboard-->
  40.         <dependency>
  41.             <groupId>org.springframework.cloud</groupId>
  42.             <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
  43.         </dependency>
  44.     </dependencies>
  46. </project>

主启动类

  1. @SpringBootApplication
  2. @EnableHystrixDashboard
  3. public class DeptConsumerDashboard_9001 {
  4.     public static void main(String[] args) {
  5.         SpringApplication.run(DeptConsumerDashboard_9001.class, args);
  6.     }
  7. }

给springcloud-provider-dept-hystrix-8001模块下的confing包下添加如下代码,添加监控

  1. @Configuration
  2. public class ConfigBean {
  4.     @Bean
  5.     public ServletRegistrationBean<HystrixMetricsStreamServlet> hystrixMetricsStreamServlet(){
  6.         ServletRegistrationBean<HystrixMetricsStreamServlet> registrationBean = new ServletRegistrationBean<>(new HystrixMetricsStreamServlet());
  7.         registrationBean.addUrlMappings("/actuator/hystrix.stream");
  8.         return registrationBean;
  9.     }
  10. }

访问：http://localhost:9001/hystrix

SpringCloud08：Hystrix服务熔断与降级 - 图14

填写信息

SpringCloud08：Hystrix服务熔断与降级 - 图15

效果

SpringCloud08：Hystrix服务熔断与降级 - 图16