SpringCloud（八）Hystrix断路器

最新推荐文章于 2021-02-12 22:08:33 发布
最新推荐文章于 2021-02-12 22:08:33 发布
阅读量274 收藏 2
点赞数 2
分类专栏： Spring Cloud / Alibaba 文章标签： springcloud hystrix 降级 熔断 断路器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_45606067/article/details/108679304
版权

文章目录

1、概述

分布式系统面临的问题

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

在这里插入图片描述

服务雪崩

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

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

所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

是什么

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

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

能干嘛

  • 服务降级
  • 服务熔断
  • 接近实时的监控
  • 。。。。

官网资料

https://github.com/Netflix/Hystrix/wiki/How-TO-Use

Hystrix官宣，停更进维

https://github.com/Netflix/Hystrix
在这里插入图片描述

  • 被动修复bugs
  • 不在接受合并请求
  • 不在发布新版本

2、Hystrix重要概念

  1. 服务降级

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

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

类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示，break
就是保险丝：服务的降级 -> 进而熔断-> 恢复调用链路

  1. 服务限流

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

3、hystrix案例

构建项目

  • 新建cloud-provider-hystrix-payment8001
  • POM
<dependencies>
   <!--hystrix-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    </dependency>
    <!-- eureka-client -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <!--引入自己定义的api通用包，可以使用payment 支付Entity-->
    <dependency>
        <groupId>com.kuang</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.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <scope>runtime</scope>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>
  • YML
server:
  port: 8001

spring:
  application:
    name: cloud-provider-hystrix-payment

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      #defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka
      defaultZone: http://eureka7001.com:7001/eureka
  • 主启动
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001 {
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8001.class, args);
    }
}
  • 业务类
    Service
@Service
public class PaymentService {

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

    public String paymentInfo_TimeOut(Integer id)
    {
        int timeNumber = 5;
        try { TimeUnit.SECONDS.sleep(timeNumber); } catch (InterruptedException e) { e.printStackTrace(); }
        return "线程池:  "+Thread.currentThread().getName()+" id:  "+id+"\t"+"O(∩_∩)O哈哈~"+"  耗时(秒): "+timeNumber;
    }
}

Controller

@RestController
@Slf4j
public class PaymentController {

    @Resource
    private PaymentService paymentService;

    @Value("${server.port}")
    private String serverPort;

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

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id)
    {
        String result = paymentService.paymentInfo_TimeOut(id);
        log.info("*****result: "+result);
        return result;
    }
}
  • 正常测试
    启动eureka7001
    启动cloud-provider-hystrix-payment8001
    访问：
    success的方法：http://localhost:8001/payment/hystrix/ok/1
    每次调用耗费5秒钟：http://localhost:8001/payment/hystrix/timeout/1
    上述module均OK：以上述为根基平台，从正确 -> 错误 -> 降级熔断 -> 恢复

高并发测试

上述在非高并情形下，还能勉强满足 ，but…

Jmeter压测测试

  • 开启Jmeter，来20000个并发压死8001，20000个请求都去访问paymentInfo_TimeOut服务
    在这里插入图片描述
  • 再来一个访问：http://localhost:8001/payment/hystrix/ok/1
  • 看演示结果
    两个都在转圈圈
    为什么会被卡死：tomcat的默认的工作线程数被打满了，没有多余的线程来分解压力和处理。

Jmeter压测结论

上面还是服务提供者8001自己测试，假如此时外部的消费者80也来访问，那消费者只能干等，最终导致消费端80不满意，服务端8001直接被拖死

看热闹不嫌弃事大，80新建加入

  • 新建cloud-consumer-feign-hystrix-order80
  • POM
<dependencies>
    <!--openFeign-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>
    <!--hystrix-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    </dependency>
    <!-- eureka-client -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <!--引入自己定义的api通用包，可以使用payment 支付Entity-->
    <dependency>
        <groupId>com.kuang</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.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <scope>runtime</scope>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>
  • YML
server:
  port: 80

eureka:
  client:
    register-with-eureka: false
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/
  • 主启动
@SpringBootApplication
@EnableFeignClients
public class OrderHystrixMain80 {
    public static void main(String[] args)
    {
        SpringApplication.run(OrderHystrixMain80.class,args);
    }
}
  • 业务类
    service
@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT")
public interface PaymentHystrixService
{
    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id);
}

controller

@RestController
@Slf4j
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

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

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id)
    {
        String result = paymentHystrixService.paymentInfo_TimeOut(id);
        return result;
    }
}
  • 正常测试：http://localhost/consumer/payment/hystrix/ok/1
  • 高并发测试
    2W个线程压8001
    消费端80微服务再去访问正常的ok微服务8001地址
    http://localhost/consumer/payment/hystrix/ok/1
    消费者80，哭了：
    要么转圈圈等待
    要么消费端报超时错误
    在这里插入图片描述

故障现象和导致原因

8001同一层次的其它接口服务被困死，因为tomcat线程池里面的工作线程已经被挤占完毕
80此时调用8001，客户端访问响应缓慢，转圈圈

上诉结论

正因为有上述故障或不佳表现
才有我们的降级 / 容错 / 限流等技术诞生

如何解决？解决的要求

  • 超时导致服务器变慢（转圈）：超时不再等待
  • 出错（宕机或程序运行出错）：出错要有兜底
  • 解决：
    • 对方服务（8001）超时了，调用者（80）不能一直卡死等待，必须有服务降级
    • 对方服务（8001）down机了，调用者（80）不能一直卡死等待，必须有服务降级
    • 对方服务（8001）OK，调用者（80）自己出故障或有自我要求（自己的等待时间小于服务提供者）

服务降级

降级配置

这里使用注解的方式：@HystrixCommand

8001先从自身找问题

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

8001fallback

  • 业务类启用
@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="5000")
})
 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()+" id:  "+id+"\t"+"O(∩_∩)O哈哈~"+"  耗时(秒): "+timeNumber;
 }
 public String paymentInfo_TimeOutHandler(Integer id)
 {
     return "线程池:  "+Thread.currentThread().getName()+"  8001系统繁忙或者运行报错，请稍后再试,id:  "+id+"\t"+"o(╥﹏╥)o";
 }

一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的执行方法

  • 主启动类激活
    添加新注解@EnableCircuitBreaker
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class PaymentHystrixMain8001 {
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8001.class, args);
    }
}

运行，此时访问：http://localhost:8001/payment/hystrix/timeout/1

80fallback

80订单微服务，也可以更好保护自己，自己也一样画葫芦进行客户端降级保护

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

  • YML
feign:
  hystrix:
    enabled: true

在之前的基础上添加上述配置

  • 主启动
    需要添加@EnableHystrix注解
@SpringBootApplication
@EnableFeignClients
@EnableHystrix
public class OrderHystrixMain80 {
    public static void main(String[] args)
    {
        SpringApplication.run(OrderHystrixMain80.class,args);
    }
}
  • 业务类
@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)
 {
//        int age = 10/0;
     String result = paymentHystrixService.paymentInfo_TimeOut(id);
     return result;
 }
 public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id)
 {
     return "我是消费者80,对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,o(╥﹏╥)o";
 }

运行，此时访问：http://localhost/consumer/payment/hystrix/timeout/1

目前问题

每个业务方法对应一个兜底的方法，代码膨胀
统一和自定义的分开

解决问题

  1. 每个方法配置一个？？？膨胀

  • feign接口系列

  • @DefaultProperties(defaultFallBack="")
    1:1 每个方法配置一个服务降级方法，技术上可以，实际上傻X
    1:N 除了个别重要核心业务有专属，其它普通的可以通过@DefaultProperties(defaultFallback="")统一跳转到统一处理结果页面
    通用的和独享的各白分开，避免了代码膨胀，合理减少了代码量

  • controller配置
    这里添加@HystrixCommand注解，表示有服务降级

@RestController
@Slf4j
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
public class OrderHystrixController {

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

    // 下面是全局fallback方法
    public String payment_Global_FallbackMethod()
    {
        return "Global异常处理信息，请稍后再试，/(ㄒoㄒ)/~~";
    }
}

运行，此时访问：http://localhost/consumer/payment/hystrix/timeout/1

  1. 和业务逻辑混在一起？？？混乱

服务降级，客户端去调用服务端，碰上服务端宕机或关闭

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

未来我们要面对的异常

  • 运行
  • 超时
  • 宕机

修改cloud-consumer-feign-hystrix-order80

根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口，重新新建一个类（PaymentFallbackService）实现该接口，统一为接口里面的方法进行异常处理

PaymentFallbackService类实现PaymentHystrixService接口

@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";
    }
}

PaymentFeignClientService接口

修改@FeignClient注解的fallback属性

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT" ,fallback = PaymentFallbackService.class)
public interface PaymentHystrixService
{
    // .....
}

测试

  • 单个eureka先启动7001
  • PaymentHystrixMain8001启动
  • 正常访问测试：http://localhost/consumer/payment/hystrix/ok/1
  • 故意关闭微服务8001
  • 客户端自己调用提示：
    此时服务端provider已经down了，但是我们做了服务降级处，让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器

服务熔断

断路器：一句话就是家里的保险丝

熔断是什么

熔断机制概述：
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。
当检测到该节点微服务调用响应正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。

大神论文：https://martinfowler.com/bliki/CircuitBreaker.html

实操

  • 修改cloud-provider-hystrix-payment8001

  • PaymentService

//=====服务熔断
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",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(@PathVariable("id") Integer id)
{
    if(id < 0)
    {
        throw new RuntimeException("******id 不能负数");
    }
    String serialNumber = IdUtil.simpleUUID();

    return Thread.currentThread().getName()+"\t"+"调用成功，流水号: " + serialNumber;
}
public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id)
{
    return "id 不能负数，请稍后再试，/(ㄒoㄒ)/~~   id: " +id;
}

why配置这些参数

在HystrixCommandProperties类中查看
在这里插入图片描述

  • PaymentController
//====服务熔断
@GetMapping("/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id)
{
    String result = paymentService.paymentCircuitBreaker(id);
    log.info("****result: "+result);
    return result;
}
  • 测试
    自测cloud-provider-hystrix-payment8001
    正确：http://localhost:8001/payment/circuit/1
    错误：http://localhost:8001/payment/circuit/-1
    一次正确一次错误
    重点测试：多次错误，然后慢慢正确，发现刚开始不满足条件，就算是正确的访问地址也不能进行。

原理小总结
结论：
在这里插入图片描述
熔断类型

  • 熔断打开：请求不再进行调用当前服务，内部设置时钟一般为MTTR(平均故障处理时间)，当打开时长达到所设时钟则进入半熔断状态
  • 熔断关闭：熔断关闭不会对服务进行熔断
  • 熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断

官网断路器流程图：

在这里插入图片描述
断路器在什么情况下开始起作用

在这里插入图片描述
断路器开启或者关闭的条件

  • 当满足一定的阀值的时候(默认10秒内超过20个请求次数)
  • 当失败率达到一定的时候( 默认10秒内超过50%的请求失败)
  • 到达以上阀值，断路器将会开启
  • 当开启的时候，所有请求都不会进行转发
  • 一段时间之后(默认是5秒)，这个时候断路器是半开状态，会让其中一一个请求进行转发。
    如果成功，断路器会关闭，若失败，继续开启。重复4和5

断路器打开之后

1、再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback。通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

2、原来的主逻辑要如何恢复呢?
对于这一问题，hystrix也为我们实现了自动恢复功能。
当断路器打开，对主逻辑进行熔断之后，hystrix会启动一 个休眠时间窗， 在这个时间窗内，降级逻辑是临时的成为主逻辑，
当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。

服务限流

后面讲解alibaba的Sentinel说明

4、hystrix工作流程

官网：https://github.com/Netflix/Hystrix/wiki/How-it-Works

Hystrix工作流程

官网图例：

在这里插入图片描述

5、服务监控hystrixDashboard

概述

除了隔离依赖服务的调用以外，Hystrixi还提供了准实时的调用监控(Hystrix Dashboard)，Hystrix会持续地记录所有通过Hystri发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

仪表盘9001

  • 新建cloud-consumer-hystrix-dashboard9001
  • POM
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
    </dependency>
    <!--actuator监控信息完善-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <scope>runtime</scope>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>
  • YML
server:
  port: 9001
  • 主启动类HystrixDashboardMain9001
    添加新注解@EnableHystrixDashboard
@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboardMain9001.class, args);
    }
}

  • 所有Provider微服务提供类（8001/8002/8003）都需要监控依赖配置
    在这里插入图片描述

  • 启动cloud-consumer-hystrix-dashboard9001该微服务后将监控微服务8001
    访问：http://localhost:9001/hystrix

断路器演示

修改cloud–provider-hystrix-payment8001

注意：新版本Hystrix需要在主启动类MainAppHystrix8001中指定监控路径，
否者会报 Unable to connect to Command Metric Stream.404

/**
 * 此配置是为了服务监控而配置，与服务容错本身无关，springcloud升级后的
 * ServletRegistrationBean 因为springboot的默认路径不是"hystrix.stream"，
 * 只要是自己的项目里配置上下面的servlet就可以了
 */
@Bean
public ServletRegistrationBean getServlet(){
    HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
    ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
    registrationBean.setLoadOnStartup(1);
    registrationBean.addUrlMappings("/hystrix.stream");
    registrationBean.setName("HystrixMetricsStreamServlet");
    return registrationBean;
}

监控测试

启动1个eureka或者3个eureka集群均可
观察监控窗口

  • 9001监控8001
    在这里插入图片描述
    填写的地址：http://localhost:8001/hystrix.stream
  • 测试地址
    http://localhost:8001/payment/circuit/1
    http://localhost:8001/payment/circuit/-1
    先访问正确地址，在访问错误地址，在正确地址，会发现图示断路器都是慢慢放开的
    监控结果，正确
    在这里插入图片描述
    监控结果，错误
    在这里插入图片描述
  • 如何看待？
    七色
    1圈
    实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从绿色<黄色<橙色<红色递减。
    该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例。

1线
曲线:用来记录2分钟内流量的相对变化，可以通过它来观察到流量的上升和下降趋势。
整个图说明
在这里插入图片描述
整个图说明2
在这里插入图片描述

如果有收获！！！ 希望老铁们来个三连，点赞、收藏、转发。
创作不易，别忘点个赞，可以让更多的人看到这篇文章，顺便鼓励我写出更好的博客
七月J
关注
  • 2
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
SpringCloud-06-Hystrix断路器
六甲的博客
05-22 951
Hystrix断路器 1. 概述 1. 分布式系统面临的问题 复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。这就造成有可能会发生服务雪崩。那么什么是服务雪崩呢？ 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”（向一把打开的折扇）。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的”雪崩效应“。也就是系统的 高可用
四、Spring cloud Hystrix断路器
qq_44333590的博客
10-26 64
概念 因为微服务调用服务是一层调用一层，当其中一层出现问题后，服务一直调用，导致上一层也出现问题，最终导致雪崩。为了避免这种情况的出现，就要引入断路器组件。断路器的工作原理是，当程序调用服务出现问题时，就调用备用的方法，返回备用的值。 使用 准备工作 基于第三Spring Cloud第三篇文章的工程，启动eureka-server 工程；启动service-hi工程，它的端口为8762。 在ribbon使用断路器 改造serice-ribbon 工程的代码，首先在pox.xml文件中加入spring-c
C/C++编程：模板的代码膨胀问题
OceanStar的博客
08-30 2083
模板的另一个重要缺点是其所带来的**代码膨胀**。代码膨胀可以分为两种情况： 源代码的增加 编译生成目标代码尺寸的增加 源代码的增加 虽然模板大大增加了代码的复用性，同时也降低了代码总量。但是，有时需要为同一模板提供不同情景下的不同实现，也就是模板特例机制。 但是，C++的模板特例机制有很大的局限性，就是特例必须以函数或者类为单位整体生成，对于模板特例只需要根据模板参数值答对小部分代码块进行微调的情况，就会生成重复代码。 目标代码的增加 会在每一次编译过程中，产生越来越大的文件尺寸，耗费
Spring Cloud(四)-服务降级
上千主上-贝库塔
02-12 1066
一.Hystrix(黑斯坠斯)断路器 1.概述 A.分布式系统面临的问题 复杂分布式体系结构中的应用程序又数十个依赖关系，每个依赖关系在某些时候将不可避免地失败 服务雪崩 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的"扇出"。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“”“雪崩效应” 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源
【Hystrix（三）】Hystrix核心之服务降级
qmqm33的博客
03-30 210
Hystrix核心之服务降级一、服务提供者服务降级1.1 降级配置 @HystrixCommand1.2 主启动类添加@EnableHtstrix1.3 测试1.3.1 正常超时测试1.3.2 运行错误测试二、消费者服务降级2.1 改yml2.2 主启动类添加注解@EnableHystrix2.3 业务类2.4 测试三、目前问题，以及问题解决3.1 全局降级@DefaultProperties3...
代码膨胀
weixin_34336292的博客
08-04 167
KOL，不知道有多少朋友知道这个东西。它是一个VCL的替代品。如果你连VCL也不知道，也没关系，VCL是Delphi的标准库，提供全方面的功能。KOL的作者认为使用VCL写出来的程序太庞大了，所以他编写了KOL，并且成功的给出了现有技术下的解决方案。KOL的主页位于：http://bonanzas.rinet.ru/KOL，其实并不是我喜欢的库。可能是因为里面用的奇技淫巧太多了吧。12k的GUI程...
析构与代码膨胀
pud_zha的专栏
07-24 795
毫无疑问，内联析构函数可能时程序代码膨胀的一个源泉，因为它被插入到函数中的每个退出点，以析构每一个活动的局部类对象。例如，在如下代码段中： Account acct ( “Tina Lee” );  int swt; // ...  switch( swt ) {  case 0:  return;  case 1:  // 进行操作  return;  case
Spring Cloud Netfix Hystrix断路器例子
08-16
Spring Cloud Netfix Hystrix断路器例子工程。使用Spring Cloud Netflix Hystrix以及Spring RestTemplate或Spring Cloud Netflix Feign实现断路器模式。
详解Spring Cloud Hystrix断路器实现容错和降级
08-27
Spring Cloud Hystrix断路器实现容错和降级 Spring Cloud Hystrix断路器是一种实现容错和降级的机制，它可以在服务不可用时，对配置了断路器的方法实行降级策略，临时调用备用方法。这种机制可以避免服务雪崩效应，...
spring cloud Hystrix断路器的使用(熔断器)
08-27
"spring cloud Hystrix断路器的使用" spring cloud Hystrix断路器是Netflix开发的一种断路器模式，用于防止级联故障在微服务架构中。断路器的使用可以防止服务之间的级联故障，使得系统更加稳定和可靠。 Hystrix...
深入分析:C++模板究竟会使代码膨胀吗
09-05
今天和同事说到C++模板会使代码膨胀, 可同事觉得不会。同事的依据是: 如果模板会使代码膨胀, 那么ATL和WTL里为什么还要大量使用模板? 同样功能 ，ATL和WTL编译出的可执行文件可比MFC编译的要小的多
spring cloud 使用Hystrix 实现断路器进行服务容错保护的方法
08-27
为了解决这个问题，Spring Cloud 提供了Hystrix组件，用于实现服务容错管理，特别是断路器机制。断路器是一种设计模式，它在检测到服务故障时能够快速失败，防止系统因等待故障服务恢复而消耗过多资源。 Spring ...
详解SpringCloud微服务架构之Hystrix断路器
08-28
通过以上步骤，我们可以构建一个利用Hystrix断路器的Feign客户端，实现对故障服务的智能处理，提高系统的整体稳定性和可靠性。 总结来说，Spring Cloud Hystrix是一个强大的工具，它通过断路器模式有效地解决了...
c++实现的一种代码膨胀变形壳
imJaron的博客
03-25 1236
主要实现3个功能：1.代码膨胀2.代码变形3.对地址常量包括字符串常量进行加密代码膨胀：代码膨胀无非就是指令等价替换，不过这里没条指令最好能有多个膨胀规则，这样会加大还原难度。原始程序大小为6kb,经过5次混淆后，大小变为66kb.混淆前代码：混淆后代码：从上图会发现有大量的垃圾代码生成。说一下代码变形：1.有分支跳转改成无分支跳转。在逆向分析时主要是通过条件跳转来确定函数的流程，根据跳转的目标地...
我对代码膨胀的理解
bmqnctrue的博客
09-30 264
代码膨胀不是一件好事，我看云风的blog上说网易那款经典游戏的核心代码只有10w行。合理的组织代码结构（运用设计模式等）是可以控制住代码的。 代码量的多少我觉得不能单一的作为程序员优秀与否的唯一标志，我觉得更重要的是代码的质量，程序员写出来代码质量（代码结构，清晰性，可读性，对于性能要求高的软件，还包括算法的复杂性等）我觉得更是评判程序员优秀与否的更重要的衡量标准。 真搞不懂为什么现在...
C++拾趣——使用多态减少泛型带来的代码膨胀
方亮的专栏
09-01 1148
        泛型编程是C++语言中一种非常重要的技术，它可以让我们大大减少相似代码编写量。有时候，我和同事提及该技术时，称它是“一种让编译器帮我们写代码的技术”。（转载请指明出于breaksoftware的csdn博客）         C++是一门静态语言，它最终的编译成果是可以直接运行于冯诺依曼体系的计算机上，而不像其他动态语言，可以运行于虚拟机等容器中。由于对运行效率得追求，C++也是...
44template代码膨胀
小小酥的博客
08-11 167
非类型参数膨胀 类型参数膨胀 共同点：共享代码，解决代码膨胀问题
SpringCloud Alibaba 全部组件说明
星海IT学习之路
12-02 5559
一、SpringCloud Alibaba 1、SpringCloud Alibaba简介 1)、简介 Spring Cloud Alibaba致力于提供微服务开发的一站式解决方案。 此项目包含开发分布式应用微服务的必需组件，方便开发者通过Spring Cloud编程模型轻松便用这些组件来开发分布式应用服务。 依托Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将SpringCloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。 https://gi
SpringCloud的Hystrix断路器特性
最新发布
06-12
Hystrix断路器的特性主要有以下几个方面： 1. 断路器机制：当某个服务出现故障或者响应时间过长时，Hystrix会自动断开该服务的请求，避免请求阻塞和资源浪费。 2. 降级处理：Hystrix提供了一些降级处理的策略，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值