您的当前位置：首页八、Hystrix断路器（上）

八、Hystrix断路器（上）

来源：筏尚旅游网

1.Hystrix 理论知识

官网资料：

分布式系统面临的问题：

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

服务雪崩：

Hystrix 简介：

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

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

Hystrix 官宣：停更进入维护阶段

但是它推荐使用 resilience4j 替代，但是国内用的比较少，后续会介绍 SpringCloud Alibaba Sentinel 实现熔断和断流。

Hystrix 功能：

服务降级
*服务熔断
接近实时的监控
*限流、隔离等

Hystrix重要概念：

1.服务降级：

服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示，fallback
哪些情况会发出降级？

程序运行异常
超时
服务熔断触发服务降级
线程池 / 信号量打满也会导致服务降级

2.服务熔断

类似保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示

3.服务限流

秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行

2.Hystrix 支付微服务构建

3.降级容错解决的维度要求

超时导致服务器变慢 (转圈)

 超时不再等待

出错（宕机或程序运行出错）

 出错要有兜底

解决

 对方服务(8001)超时了，调用者(80)不能一直卡死等待，必须有服务降级

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

4.如何使用 Hystrix 服务降级

设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级fallback

服务降级 fallback 既可以放在服务端，也可以放在客户端，但是我们一般放在客户端，这里两种都演示一下。

pml文件

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

（1）服务提供者服务降级

服务提供者配置

@EnableCircuitBreaker 主启动类添加该注解
降级的方法添加@HystrixCommand注解
参数说明：
fallbackMethod：出现异常进行降级调用的方法注意降级的方法需要和该方法返回值参数一致
HystrixProperty：降级的有一些配置 @HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “3000” 3秒没有完成该方法就进去降级方法

//业务类启用 @HystrixCommand
package com.atguigu.springcloud.service;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;

@Service
public class PaymentService {
    /**
     * 正常访问
     * @param id
     * @return
     */
    public String paymentInfo_OK(Integer id){
        return "线程池："+Thread.currentThread().getName()+"   paymentInfo_OK,id："+id+"\t"+"O(∩_∩)O哈哈~";
    }

    /**
     * http://localhost:8001/payment/hystrix/timeout/31
     * @HystrixCommand报异常后如何处理：
     * 一旦调用服务方法失败并抛出了错误信息后，
     * 会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
     *
     * @param id
     * @return
     */
    @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            //设置这个线程的超时时间是3s，3s内是正常的业务逻辑，超过3s调用fallbackMethod指定的方法进行处理
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
    })
    public String paymentInfo_Timeout(Integer id){
        int timeNumber = 5;
        //int age = 10/0;
        try{
            TimeUnit.SECONDS.sleep(timeNumber);
        }catch (InterruptedException e){
            e.printStackTrace();
        }
        return "线程池："+Thread.currentThread().getName()+"   paymentInfo_Timeout,id："+id+"\t"+"O(∩_∩)O哈哈~"+"   耗时(秒)："+timeNumber;
    }

    public String paymentInfo_TimeOutHandler(Integer id){
        return "线程池："+Thread.currentThread().getName()+"   系统繁忙，请稍后再试,id："+id+"\t"+"o(╥﹏╥)o";
    }
}
//主启动类激活 @EnableCircuitBreaker
package com.atguigu.springcloud;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class PaymentHystrixMain8001 {
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8001.class,args);
    }
}

启动测试，没有报错，而是执行了fallbackMethod指定的方法

再来测试一下计算错误，也是会调用 fallbackMethod 指定的方法

总结：

如果我们故意制造两个异常：

int age = 10/0; 运行时异常
我们能接受3秒钟，它运行5秒钟，超时异常。
当前服务不可用了，做服务降级，兜底的方案都是paymentInfo_TimeOutHandler

（2）消费者服务降级

消费者服务配置开启 hystrix

主启动类添加：@EnableHystrix 才能处理非feign调用产生的降级
本地方法使用@HystrixCommand降级需要主启动类开启配置

配置yml 处理feign远程调用产生的降级
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackService.class)需要配置yml才可以进行降级

使用远程在@FeignClient添加 fallback = PaymentFallbackService.clas

yml

feign:
 hystrix:
   enabled: true

实例代码

//主启动

@SpringBootApplication
@EnableFeignClients
@EnableHystrix
public class OrderHystrixMain80 {
    public static void main(String[] args) {
        SpringApplication.run(OrderHystrixMain80.class,args);
    }
}

//业务类

@RestController
@Slf4j
public class OrderHystrixController {
    @Resource
    private PaymentHystrixService paymentHystrixService;

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

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

    public String paymentTimeOutFallBackMethod(@PathVariable("id") Integer id){
        return "我是消费者80，对方支付系统繁忙，请稍后再试，o(╥﹏╥)o";
    }
}

测试，超时异常：

运行时异常：

PS： 我们自己配置过的热部署方式对Java代码的改动明显，但对@HystrixCommand内属性的修改建议重启微服务。

（3）全局默认降级处理

问题1：

这样如果每个业务方法都对应一个兜底的方法，100个方法就有100个服务降级，会出现代码膨胀问题，我们需要一个统一的 fallbackMethod，统一的和自定义的分开。

解决问题：

注意全局默认降级的方法不可以有参数
优先级问题：就近原则 @HystrixCommand(fallbackMethod=“ ”)配置的降级方法优先全局的降级方法

@DefaultProperties(defaultFallback = "")
没有添加 @HystrixCommand注解的方法出现异常不会触发默认降级配置

1 : 1 每个方法配置一个服务降级方法，造成代码膨胀

1 : N 除了个别重要核心业务有专属，其他普通的可以通过@DefaultProperties(defaultFallback = “”) 统一跳转到统一处理结果页面

这样通用的和独享的各自分开，避免了代码膨胀，合理减少了代码量。

测试

（4）fegin远程调用降级配置

问题2：

现在客户端与服务端关系紧紧耦合，客户端能跑是因为接口调用了微服务的业务逻辑方法，我们如果针对客户端接口做一些处理，把它调用的所有微服务方法进行降级，就可以解决耦合问题。

解决问题：

这个案例服务降级处理是在客户端80完成的，与服务端8001没有关系，只需要为 Feign 客户端定义的接口添加一个服务降级处理的实现类即可实现解耦。

package com.atguigu.springcloud.service;
@Component
public class PaymentFallbackService implements PaymentHystrixService {
    @Override
    public String paymentInfo_OK(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_OK ,o(╥﹏╥)o";
    }

    @Override
    public String paymentInfo_TimeOut(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_TimeOut ,o(╥﹏╥)o";
    }
}

接口使用@FeignClient(fallback = xxx.class)指定哪个类来处理异常

测试

记得配置feign的yml

feign:
  hystrix:
    enabled: true #如果处理自身的容错就开启。开启方式与生产端不一样。

先启动服务端8001，在启动客户端80，客户端正常调用微服务

现在关闭8001，客户端自己进行了降级，调用处理异常的方法

（5）@EnableHystrix注解与@EnableCircuitBreaker注解的区别

查看源码可知，@EnableHystrix注解的作用和@EnableCircuitBreaker注解的作用一样，@EnableHystrix注解对
@EnableCircuitBreaker注解进行了封装；
@EnableHystrix注解的底层源码：

 		@Target({ElementType.TYPE})
        @Retention(RetentionPolicy.RUNTIME)
        @Documented
        @Inherited
        @EnableCircuitBreaker  //还是使用该注解
        public @interface EnableHystrix {
        }

针对Hystrix断路器（上）的补充

Hystrix重点补充

在对8001进行服务降级的时候，@HystrixCommand里面用来兜底的fallbackMethod是用的一个单独的线程池，所以与主运行类的线程池起到了一定的隔离效果。

fallback服务降级可以放在客户端也可以放在服务端，但是一般都是放在客户端。
问题2：

现在客户端与服务端关系紧紧耦合，客户端能跑是因为接口调用了微服务的业务逻辑方法，我们如果针对客户端接口做一些处理，把它调用的所有微服务方法进行降级，就可以解决耦合问题。
- 新设一个类 PaymentFallbackService来继承接口PaymentHystrixService的方法，在这个类中进行统一的调度和fallback降级处理。

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文