SpringCloud hystrix服务降级概念介绍

目录
  • Hystrix
    • 初识Hystrix
  • Hystrix三大概念
    • 服务降级(fallback)
      • fallback是什么
      • 服务提供方实现服务降级
      • 服务调用方实现服务降级
      • 服务降级优化
    • 服务熔断(break)
      • break是什么
      • 服务提供方实现服务熔断
    • 服务限流(flowlimit)
      • flowlimit是什么
  • Hystrix图形化监控

Hystrix

初识Hystrix

Hystrix是什么?

  Java应用程序讲求“高内聚低耦合”,而spring cloud是一种微服务架构理念,将原来的一个应用程序拆分成许多微服务来调用,这样的话就可以满足“低耦合”的要求,但是随之而来的就是“服务雪崩”问题。

  所谓的服务雪崩就是指,由于服务提供者不可用导致服务调用者不可用,并且在生产过程中,这种不可用逐渐扩大的现象。想要解决“服务雪崩”问题就需要用到Hystrix(豪猪)

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

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

Hystrix三大概念

服务降级(fallback)

fallback是什么

  所谓的服务降级就是当服务出现程序运行异常、超时、服务熔断触发服务降级、线程池/信号量打满等情况,此时应该返回一个符合预期的、可处理的备选响应(fallback),以提高用户的使用体验而不是长时间的等待请求或者返回一个超时异常页面。总而言之,当出现以上问题时,要有一个兜底方案来提高用户的使用体验

  服务降级的解决方案可以分为服务提供方和服务调用方,两面都可以实现服务降级

服务提供方实现服务降级

  第一步: 对服务提供方的service接口方法进行加强,主要就是针对可能出现超时等异常情况的接口,新建方法对其进行兜底,如果原接口出现问题则使用兜底方案进行反馈

  使用@HystrixCommand注解的fallbackMethod属性指定兜底方法名,使用commandProperties属性的@HystrixProperty注解指定异常类型(超时异常和超时时间)

/**
 * 超时访问,设置自身调用超时的峰值,峰值内正常运行,超过了峰值需要服务降级 自动调用fallbackMethod 指定的方法
 * 超时异常或者运行异常 都会进行服务降级
 * @param id
 * @return
 */
@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
})
public String paymentInfoTimeOut(Integer id) {
    int second = 5;
    try {
        TimeUnit.SECONDS.sleep(second);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return "线程池:  " + Thread.currentThread().getName() + " paymentInfoTimeOut,id:  " + id + "\t"
            + "O(∩_∩)O哈哈~" + "  耗时(秒): " + second;
}
public String paymentInfo_TimeOutHandler(Integer id) {
    return "超时异常兜底方案!线程池:  " + Thread.currentThread().getName() + " paymentInfo_TimeOutHandler,id:  " + id + "\t";
}

  第二步: 服务提供方的主启动类上使用@EnableCircuitBreaker注解开启“熔断器”,这样的话前面的配置才能生效

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

  除了上述可以自定义超时时间的异常,出现其他运行时异常也会调用兜底方案返回

服务调用方实现服务降级

  第一步: 使用配置文件开启hystrix

feign:
  hystrix:
    enabled: true

  第二步: 服务调用方的controller加强,新建方法对其进行兜底,使用方式与服务提供方一样,主要就是服务调用方和服务提供方两套方案,可以实现两边定制化。

@GetMapping("/payment/hystrix/timeout/{id}")
@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod", commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
})
public String paymentInfoTimeOut(@PathVariable("id") Integer id) {
    String result = paymentHystrixService.paymentInfoTimeOut(id);
    return result;
}
public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id) {
    return "服务调用方兜底方案!我是消费者80,对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,o(╥﹏╥)o";
}

  第三步: 服务调用方的主程序类上使用@EnableHystrix注解开启hystrix

服务降级优化

  • 解决冗余问题

  前面的每一个方法都对应一个兜底方案,这样的话会显得代码十分臃肿,实际上很多的接口都可以使用一个兜底方案,于是我们就可以配置默认的兜底方案,在没有使用@HystrixCommand注解指定的时候,类中的所有接口都会走默认兜底方案

  @DefaultProperties注解的defaultFallback属性指定默认兜底方法,如果类中存在@HystrixCommand注解中不使用属性指定特定兜底方案的情况,就说明这个接口使用是默认兜底方案

@RestController
@RequestMapping("consumer")
@Slf4j
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
public class OrderHystrixController {
    @Resource
    private PaymentHystrixService paymentHystrixService;
    @HystrixCommand
    @GetMapping("/payment/hystrix/ex/{id}")
    public String paymentInfoException(@PathVariable("id") Integer id) {
        int age = 10/0;
        String result = paymentHystrixService.paymentInfoException(id);
        return result;
    }
    /**
     * hystrix 全局fallback方法
     * @return
     */
    public String payment_Global_FallbackMethod() {
        return "Global异常处理信息,请稍后再试,/(ㄒoㄒ)/~~";
    }
}
  • 解决耦合问题

  上述操作中,原方案和兜底方案都在controller中定义,想要解决这个耦合问题可以使用一个类实现service接口,然后重写所有的接口方法,然后使用service接口上@FeignClient注解的fallback属性指定接口的实现类为兜底类

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackService.class)
public interface PaymentHystrixService {
    @GetMapping("/payment/hystrix/ok/{id}")
    String paymentInfoOK(@PathVariable("id") Integer id);
    @GetMapping("/payment/hystrix/timeout/{id}")
    String paymentInfoTimeOut(@PathVariable("id") Integer id);
    @GetMapping("/payment/hystrix/ex/{id}")
    String paymentInfoException(Integer id);
}
@Component
public class PaymentFallbackService implements PaymentHystrixService {
    @Override
    public String paymentInfoOK(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_OK ,o(╥﹏╥)o";
    }
    @Override
    public String paymentInfoTimeOut(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_TimeOut ,o(╥﹏╥)o";
    }
    @Override
    public String paymentInfoException(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfoException ,o(╥﹏╥)o";
    }
}

服务熔断(break)

break是什么

  微服务链路中某个微服务的请求达到最大访问之后,直接拒绝访问,然后调用服务降级的方法返回友好的提示;当检测到该节点微服务调用响应正常之后,还可以恢复链路的正常调用。hystrix会默认在服务5秒内调用失败20次后触发熔断机制,但是也可以使用配置对其进行修改。

服务提供方实现服务熔断

  首先service层使用注解配置服务熔断的相关值和熔断时的备选方案,就以下代码为例:在10S的时间窗口期中,10次请求中失败率达到60%就会触发熔断启动备选方案。

  如果在10S的时间窗口期中,请求次数不足10次,那么根本就不可能触发熔断器。当熔断器开启后所有的请求都不会被转发,一段时间窗口期之后(默认5秒,可以自定义配置)断路器切换为半开状态,此时会让其中一个请求进行转发,成功则关闭断路器,反之继续开启

@HystrixCommand(fallbackMethod = "paymentCircuitBreakerFallback", 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(Integer id) {
    if (id < 0) {
        throw new RuntimeException("******id 不能负数");
    }
    String serialNumber = IdUtil.simpleUUID();
    return Thread.currentThread().getName() + "\t" + "调用成功,流水号: " + serialNumber;
}
public String paymentCircuitBreakerFallback(Integer id) {
    return Thread.currentThread().getName() + "\t" + "id 不能负数或超时或自身错误,请稍后再试,/(ㄒoㄒ)/~~   id: " + id;
}

  controller中调用service方法

@GetMapping("/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
    String result = paymentService.paymentCircuitBreaker(id);
    log.info("****result: " + result);
    return result;
}

服务限流(flowlimit)

flowlimit是什么

  在秒杀等高并发的操作下,为了防止大量请求一块发送过来,采用排队的方式,把请求按照顺序排队发送过来。由于hystrix已经停止更新,而且Alibaba的sentinel在进行服务限流的处理时比hystrix更加优秀,所以说这一部分知识可以放在后面进行学习。

Hystrix图形化监控

  第一步: 新建一个模块用于监控,导入相关依赖

<dependencies>
	<!--最主要的依赖,用于引入图形化dashboard-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
    </dependency>
    <!-- 引入自己定义的api通用包 -->
    <dependency>
        <groupId>com.xiaochen</groupId>
        <artifactId>cloud-api-commons</artifactId>
        <version>${project.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

  第一步: 配置文件配置端口号

server:
  port: 9001

  第三步: 主启动类开启HystrixDashboard,

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

  此外,所有的服务提供方也就是被监控的服务都要引入spring-boot-starter-actuator依赖,表示自己可以受监控。然后就是在服务的主启动类上要使用以下代码中的addUrlMappings配置受监控的路径

/**
 * 注意:新版本Hystrix需要在主启动类中指定监控路径
 * 此配置是为了服务监控而配置,与服务容错本身无关,spring cloud升级后的坑
 * ServletRegistrationBean因为springboot的默认路径不是"/hystrix.stream",
 * 只要在自己的项目里配置上下面的servlet就可以了
 *
 * @return ServletRegistrationBean
 */
@Bean
public ServletRegistrationBean getServlet() {
    HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
    ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
    // 一启动就加载
    registrationBean.setLoadOnStartup(1);
    // 添加url
    registrationBean.addUrlMappings("/hystrix.stream");
    // 设置名称
    registrationBean.setName("HystrixMetricsStreamServlet");
    return registrationBean;
}

  启动监控模块、eureka模块、受监控模块之后,访问以下路径可以通过路径监控指定的服务,设置后点击下面的Monitor Stream按钮即可进入图形化监控界面

图形化界面各处代表的含义如下:

到此这篇关于SpringCloud hystrix服务降级概念介绍的文章就介绍到这了,更多相关SpringCloud hystrix内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • springcloud使用Hystrix进行微服务降级管理

    前言:目前我们的项目是微服务架构,基于dubbo框架,服务之间的调用是通过rpc调用的.刚开始没有任何问题,项目运行健康.良好.可是过了一段时间,线上总有人反应查询订单失败,等过了一段时间才能查到.这是怎么回事呢?打开后台的日志一看出现了一些RpcException和TimeOutException,原来是远程调用超时了,可能某个服务在请求的高发期访问数据库异常,IO阻塞,返回接口异常了.后来这个问题越来越频繁,如何解决这个棘手的问题呢? 一:Hystrix是什么? 1.1:基本解释 Hystr

  • SpringCloud hystrix服务降级学习笔记

    目录 一.Hystrix简介 1.Hystrix是什么 2.Hystrix能干什么 二.服务熔断 1.服务熔断简介 2.配置pom.xml 3.配置application.yaml 4.修改Controller 5.修改启动类 6.效果图 三.服务降级 1.什么是服务降级 2.DeptClientFailBackFactory类 3.添加注解 4.修改application.yaml 5.效果图 四.DashBorder 1.新建一个module 2.pom.xml配置 3.配置applicat

  • 详解springcloud 基于feign的服务接口的统一hystrix降级处理

    springcloud开发微服务时,基于feign来做声明式服务接口,当启用hystrix服务熔断降级时,项目服务众多,每个Feign服务接口都得写一些重复问的服务降级处理代码,势必显得枯燥无味: Feign服务接口: @FeignClient(name="springcloud-nacos-producer", qualifier="productApiService", contextId="productApiService", fallb

  • SpringCloud-Alibaba-Sentinel服务降级,热点限流,服务熔断

    前言: 除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一.一个服务常常会调用别的模块,可能是另外的一个远程服务.数据库,或者第三方 API 等.例如,支付的时候,可能需要远程调用银联提供的 API:查询某个商品的价格,可能需要进行数据库查询.然而,这个被依赖服务的稳定性是不能保证的.如果依赖的服务出现了不稳定的情况,请求的响应时间变长,那么调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用 熔断策略 Sentin

  • SpringCloud hystrix断路器与局部降级全面介绍

    目录 服务降级 一.Hystrix的服务使用前的问题 1.ProductController 中方法异常和超时 2.访问查看效果 3.问题分析 二. 商品服务 Hystrix的 局部降级 1.降级配置 2.回调(兜底降级)方法 3.具体代码 4.主启动类激活Hstrix 5.进行测试 三. 订单服务 Hystrix的 局部降级 1.降级配置 2.回调(兜底降级)方法 3.具体代码 4.将商品服务中的超时时间为正常 5.主启动类激活Hstrix 6.进行测试 服务降级 服务压力剧增的时候,根据当前

  • springcloud 服务降级的实现方法

    1 .简介 什么是服务降级?当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作. 如果还是不理解,那么可以举个例子:假如目前有很多人想要给我付钱,但我的服务器除了正在运行支付的服务之外,还有一些其它的服务在运行,比如搜索.定时任务和详情等等.然而这些不重要的服务就占用了JVM的不少内存与CPU资源,为了能把钱都收下来(钱才是目标),我设计了一个动态开关,把这些不重要的服务直接在最外层拒掉,这样处

  • SpringCloud灾难性雪崩效应处理方法之降级实现流程详解

    目录 一.前言 二.代码实现 1.新建ApplicationServiceDemo 1.1配置pom.xml 1.2新建配置文件 1.3新建控制器 1.4新建启动类 2.新建DemoFallback 2.1编写pom.xml 2.2新建配置文件 2.3新建配置类 2.4新建service及实现类 2.5新建控制器 2.6新建启动类 2.7访问 3.测试降级 一.前言 解决服务雪崩效应,都是避免application client请求application service时,出现服务调用错误或网络

  • SpringCloud Feign隔离与降级详细分析

    目录 序篇 FeignClient整合Sentinel 1.1 修改配置,开启sentinel功能 1.2 编写失败降级逻辑 1.3 总结 序篇 限流是一种预防措施,虽然限流可以尽量避免因高并发而引起的服务故障,但服务还会因为其它原因而故障. 而要将这些故障控制在一定范围,避免雪崩,就要靠线程隔离(舱壁模式)和熔断降级手段了. 线程隔离:调用者在调用服务提供者时,给每个调用的请求分配独立线程池,出现故障时,最多消耗这个线程池内资源,避免把调用者的所有资源耗尽. 熔断降级:是在调用方这边加入断路器

  • hystrix服务降级方法使用介绍

    当一个服务端的业务响应的时间过长的时候或者业务处理逻辑处理异常,不应该等待,应该给出一种处理方法 超时导致服务器变慢(转圈) --->超时不再等待 出错(宕机或程序运行出错) --->出错要有兜底 pom文件依赖 : <!--hystrix--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netf

  • SpringCloud Hystrix熔断器使用方法介绍

    目录 Hystrix(hi si ju ke si)概述 Hystix 主要功能 隔离 Hystrix 降级 Hystrix降级-服务提供方 初始化程序和Fiegn程序一致 Hystrix降级-服务消费方 provider与Fiegin一致 Hystrix 熔断 Hystrix 熔断监控 Turbine聚合监控 搭建监控模块 修改被监控模块 启动测试 Hystrix(hi si ju ke si)概述 Hystix 是 Netflix 开源的一个延迟和容错库,用于隔离访问远程服务.第三方库,防止

  • Springcloud hystrix服务熔断和dashboard如何实现

    服务在经过一定负荷之后,如果达到一定上限之后会中断进行报错,而服务调用的方法也会报错等等,一旦整体服务停下,别的客户端再来访问就会无法调用.对此需要进行另外一种服务熔断模式. 不同于现实中的熔断保险丝,服务熔断是在系统服务达到一定错误之后,自动熔断降级,采取备用方法,但是在一定时间后客户端再次调用成功后,一定时间内成功率上去,系统的熔断机制会慢慢的关闭,恢复到正常请求的状态. 本篇接上一章直接改动. 1.主启动类加上新的注解. @EnableCircuitBreaker 2.service写入新

  • SpringCloud微服务之Hystrix组件实现服务熔断的方法

    一.熔断器简介 微服务架构特点就是多服务,多数据源,支撑系统应用.这样导致微服务之间存在依赖关系.如果其中一个服务故障,可能导致系统宕机,这就是所谓的雪崩效应. 1.服务熔断 微服务架构中某个微服务发生故障时,要快速切断服务,提示用户,后续请求,不调用该服务,直接返回,释放资源,这就是服务熔断. 熔断生效后,会在指定的时间后调用请求来测试依赖是否恢复,依赖的应用恢复后关闭熔断. 2.服务降级 服务器高并发下,压力剧增的时候,根据当业务情况以及流量,对一些服务和页面有策略的降级(可以理解为关闭不必

  • SpringCloud微服务熔断器Hystrix使用详解

    目录 什么是Hystrix Hystrix实战 总结 什么是Hystrix 在日常生活用电中,如果我们的电路中正确地安置了保险丝,那么在电压异常升高时,保险丝就会熔断以便切断电流,从而起到保护电路安全运行的作用. 在货船中,为了防止漏水和火灾的扩散,一般会将货仓进行分割,避免了一个货仓出事导致整艘船沉没的悲剧,这就是舱壁保护机制. Hystrix提供的熔断器也类似,在调用某个服务提供者时,当一定时间内请求总数超过配置的阈值,且窗口期内错误率过高,那Hystrix就会对调用请求熔断,后续的请求直接

  • SpringCloud微服务熔断器使用详解

    目录 一.简介 二.作用 三.核心概念 3.1 熔断目的 3.2 降级目的 四.实例 4.1 基于Hystrix 4.1.1 熔断触发降级 4.1.2 超时触发降级 4.1.3 资源隔离触发降级 4.2 基于OpenFeign pom.xml 一.简介 当微服务中的某个子服务,发生异常服务器宕机,其他服务在进行时不能正常访问而一直占用资源导致正常的服务也发生资源不能释放而崩溃,这时为了不造成整个微服务群瘫痪,进行的保护机制 就叫做熔断,是一种降级策略 熔断的目的:保护微服务集群 二.作用 对第三

随机推荐