Spring Cloud (断路器) Hystrix(三)

  在微服务当道的现下,系统架构中由业务拆分出多个系统之间,通常是通过远程RPC调用进行通信,比如系统1调用系统2的服务,系统2调用系统3,当系统3发生故障的时候就会导致,可能会导致前置的两个系统发生崩溃,所以在系统架构中通常要保证系统的健壮性,比如使用降级策略,来保证由其他系统提供的服务发生错误不可用的时候,服务的调用方可以切换降级到正常的服务上使用。

Hystrix开源的一个限流熔断的项目

  Netflix开源了Hystrix组件,实现了断路器模式,Spring Cloud 对这一组组件进行了组合

特点:隔离、降级、熔断、缓存

  隔离:包括线程池隔离和信号隔离,限制调用分布式服务的资源使用,一个微服务出现问题不会影响其他服务

  降级:超时降级、资源不足时降级、降级后可以配合降级接口返回托底数据

  熔断:当失败率达到阀值自动触发降级(比如网络故障、服务异常),熔断器触发的快速失败会进行快速恢复。

  缓存:提供请求缓存、请求合并实现

熔断

  正常情况下,断路器处于关闭状态。如果在某段时间内,调用持续出错或者超时,断路器会被打开进入熔断状态,后续一段时间内的所有请求调用都会被拒绝。一段时间以后,保护器会尝试进入半熔断状态,开放少量的请求进来,如果调用败任然回到熔断状态,如果调用成功服务会到正常状态,断路状态关闭。

三种状态的转换:

  closed -> open: 正常情况熔断器为close状态,当访问的同一个服务或者接口次数超过一定的阀值,并且错误比例超过我们预定的阀值时,就会打开熔断机制,这个时候熔断器的状态就会从closed变成open状态

  open -> half-open:当服务的熔断器状态为open的时候,所有的服务调用方在请求该服务的时候都是在执行本地的降级方法,Hystrix提供了一个策略,从open状态开始的时候记录了一个时间窗口,当熔断时间超过了这个时间时,就会把状态变更为half-open,这个时候远程调用请求服务接口时,发起的是服务正常应该提供的调用,而不再是降级策略,如果服务调用正常熔断状态会从half-open->closed转变,熔断关闭

如果请求还是异常,就继续从half-open->open转变

如果没有发生熔断,还有一道门槛,Hystrix提供了一个信号量限流器,限制进入熔断器最大并发数,可以控制请求下游的并发量,如果超过这个阈值,会被降级处理,有效的保护下游服务不会被突发流量给攻击。

在ribbon使用断路器

  将前两节中的eureka服务与client启动起来,在service-ribbon项目中添加Hystrix引用

 <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

  启动类中添加注解@EnableHystrix

@EnableDiscoveryClient
@EnableEurekaClient
@SpringBootApplication
@EnableHystrix
public class ServiceribbonApplication {

    public static void main(String[] args) {
        SpringApplication.run(ServiceribbonApplication.class, args);
    }

    @Bean
    @LoadBalanced
    RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

  修改Controller加上@HystrixCommand注解。该注解对该方法创建了熔断器的功能,并指定了fallbackMethod熔断方法

@RestController
@RequestMapping("hello")
public class HelloControler {
    @Autowired
    HelloService helloService;

    @HystrixCommand(fallbackMethod = "hiError")
    @GetMapping(value = "/hi")
    public String hi(@RequestParam String name) {
        String a=helloService.hiService( name );
        return a;
    }

    public  String hiError(String name){
        return "调用服务下线";
    }
}

  run起来,请求hi接口的时候,调用服务不通或者异常的时候将会执行指定的熔断方法。

  正常启动eureka的client后,运行service-ribbon可以正常调用服务并返回字符串

hi aa ,i am from port:1002

  手动停掉client后,再次请求

调用服务下线

 

原文地址:https://www.cnblogs.com/li-lun/p/11494500.html

时间: 2024-11-10 08:18:34

Spring Cloud (断路器) Hystrix(三)的相关文章

断路器Hystrix与Turbine集群监控-Spring Cloud学习第三天

文章大纲 一.Hystrix基础介绍二.断路器Hystrix简单使用三.自定义Hystrix请求命令四.Hystrix的服务降级与异常处理五.Hystrix的请求缓存与请求合并六.Hystrix仪表盘与Turbine集群监控七.项目源码与参考资料下载八.参考文章 一.Hystrix基础介绍 1. Hystrix简介   一个用户管理项目,里边就三个功能:用户注册.用户登录.用户详情浏览.按照传统的软件开发方式直接创建一个Web项目,分分钟就把这三个功能开发出来了,但是我现在想使用微服务+服务治理

Spring Cloud中Hystrix、Ribbon及Feign的熔断关系

在Spring Cloud中Hystrix.Ribbon以及Feign它们三者之间在处理微服务调用超时从而触发熔断降级的关系是什么? 我们知道在Spring Cloud微服务体系下,微服务之间的互相调用可以通过Feign进行声明式调用,在这个服务调用过程中Feign会通过Ribbon从服务注册中心获取目标微服务的服务器地址列表,之后在网络请求的过程中Ribbon就会将请求以负载均衡的方式打到微服务的不同实例上,从而实现Spring Cloud微服务架构中最为关键的功能即服务发现及客户端负载均衡调

(三)Spring Cloud教程——Hystrix(F版本)

参考:方志鹏的专栏 1. Hystrix简介 在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用.为了保证其高可用,单个服务通常会集群部署.由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪.服务与服务之间的依赖性,故障会传播,会对整个微服务

springcloud学习04- 断路器Spring Cloud Netflix Hystrix

依赖上个博客:https://www.cnblogs.com/wang-liang-blogs/p/12072423.html 1.断路器存在的原因 引用博客 https://blog.csdn.net/zhou199252/article/details/80745151 的说明 在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用.为了保证其高可用,单个服务通常会集群部署.

笔记:Spring Cloud Feign Hystrix 配置

在 Spring Cloud Feign 中,除了引入了用户客户端负载均衡的 Spring Cloud Ribbon 之外,还引入了服务保护与容错的工具 Hystrix,默认情况下,Spring Cloud Feign 会为将所有 Feign客户端的方法都封装到 Hystrix 命令中进行服务保护,需要注意的是 Ribbon 的超时与 Hystrix 的超时是二个概念,需要让 Hystrix 的超时时间大于 Ribbon 的超时时间,否则 Hystrix 命令超时后,该命令直接熔断,重试机制就没

Spring Cloud 入门教程(三): 配置自动刷新

之前讲的配置管理, 只有在应用启动时会读取到GIT的内容, 之后只要应用不重启,GIT中文件的修改,应用无法感知, 即使重启Config Server也不行. 比如上一单元(Spring Cloud 入门教程(二): 配置管理)中的Hello World 应用,手动更新GIT中配置文件config-client-dev.properties的内容(别忘了用GIT push到服务器) hello=Hello World from GIT version 1 刷新 http://locahost/8

spring cloud深入学习(三)-----服务消费

在上一篇博文中简单实现了eureka-server以及eureka-provider,后面会实现eureka-cosumer,现在针对eureka做进一步的详解. 微服务整体架构 文字再美也没有图片直观,下面通过一张图来说明微服务的整体架构以及调用过程,如下: 服务注册中心-1和服务注册中心-2互相组成了高可用集群:服务提供者启动了两个实例,一个注册到服务注册中心-1上,另外一个注册到服务注册中心-2上:两个服务消费者,也都分别指向了一个注册中心. 服务提供者 1.服务注册 服务提供者在启动的时

(五)springcloud 断路器-Spring Cloud Netflix Hystrix

较低级别的服务中的服务故障可能导致级联故障一直到用户. 当对特定服务的调用超过circuitBreaker.requestVolumeThreshold(默认值:20个请求)且失败百分比大于circuit.rolllingStats.timeInMilliseconds定义的滚动窗口中的circuitBreaker.errorThresholdPercentage(默认值:> 50%)时(默认值:10秒) 设计原则: 防止单个服务的故障,耗尽整个系统服务的容器(比如tomcat)的线程资源,避免

【微服务架构】Spring Cloud之Hystrix(三)

一.雪崩效应 在微服务架构中,由于服务和服务之间可以互相调用,一项工作的完成可能会依赖调用多个微服务模块,但由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪:再加上服务和服务之间的依赖性,瘫痪会迅速传播,给整个微服务系统造成严重的后果,这就是服务故障的“血崩”效应. 服务雪崩效应形成的阶段 1.服务提供者不可用 硬件故障.硬件损坏导致服务器主机宕机,或网络硬件

spring cloud feign+hystrix

server: port: 8081 spring: application: name: spring-hy-sale feign: hystrix: enabled: true hystrix: command: HelloClient#toHello(): execution: isolation: thread: timeoutInMilliseconds: 500 circuitBreaker: requestVolumeThreshold: 3 eureka: client: ser