【微服务&云原生】用实际案例探究Hystrix 断路器执行流程

最新推荐文章于 2024-05-21 22:52:50 发布

IT派同学

最新推荐文章于 2024-05-21 22:52:50 发布

阅读量1k

点赞数 7

分类专栏： # SpringCloud学习笔记云原生文章标签：云原生微服务

本文链接：https://blog.csdn.net/Gaowumao/article/details/125325332

版权

云原生同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

SpringCloud学习笔记

2 篇文章 0 订阅

订阅专栏

🏡 博客首页：派大星

⛳️ 欢迎关注 ❤️ 点赞 🎒 收藏 ✏️ 留言

🎢 本文由派大星原创编撰

🚧 系列专栏：微服务—云原生

🎈 本系列记录容器化技术的初次探险与深入思考历程，如有描述有误的地方还望诸佬不吝赐教

在这里插入图片描述

🌵 Hystrix断路器

🎄 概述

分布式系统面临的问题

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

服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩盘，所谓的“雪崩效应”
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的i所有资源都在几秒钟内饱和，比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还会发生级联故障，或者叫雪崩

是什么？

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出现问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器“本身是一种开关装备，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

能干嘛？

● 服务降级
● 服务熔断
● 接近实时的监控
● 等等

🌾 Hystrix重要概念

服务降级fallback

服务器忙，请稍后再试，不让客户端等待并立刻饭hi一个友好的提示，fallback
哪些情况会触发降级
● 程序运行异常
● 超时
● 服务熔断触发服务降级
● 线程池/信号量打满也会导致服务降级
服务熔断
● 类似保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示
● 就是保险丝
○ 服务的降级——>进而熔断——>恢复调用链路
服务限流
● 秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行

🌲 Hystrix案例

<!--新增hystrix-->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

启动类添加openFeign注解

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

前端控制层

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

如何解决？解决的要求

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

🌳 服务降级

降级配置@HystrixCommand

● 8001先从自身找问题
○ 设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级fallback
● 8001fallback
○ 业务类启用@HystrixCommand报异常后如何处理
■ 一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定的方法

@Service
public class PaymentService {

    /**
     * 正常访问ok
     * @param id
     * @return
     */
    public String paymentInfo_Ok(Integer id){
        return "线程池"+Thread.currentThread().getName()+"   paymentInfo_Ok,id: "+id+"\t"+"哈哈";
    }

    @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            @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 (Exception e){
            e.printStackTrace();
        }
        return "线程池"+Thread.currentThread().getName()+"   paymentInfo_TimeOut,id: "+id+"\t"+"哈哈"+"  耗时(秒)";
    }

    /**
     * 兜底的方法
     * @param id
     * @return
     */
    public String paymentInfo_TimeOutHandler(Integer id){
        return "线程池"+Thread.currentThread().getName()+"   系统繁忙，请稍后再试,id: "+id+"\t"+"哈哈Handler";
    }
}

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

● 80fallback
○ 80订单微服务，也可以更好的保护自己，自己也依样画葫芦进行客户端降级保护
○ 我们自己配置过热部署方式对Java代码的改动明显，但对@HystrixCommand内属性的修改建议重启微服务

##yaml配置feign
feign:
  hystrix:
    enabled: true

//主启动类
@EnableHystrix
//业务层代码
    @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){
        String result = paymentHystrixService.paymentInfo_TimeOut(id);
        return result;
    }

    public String paymentTimeOutFallBackMethod(@PathVariable("id")Integer id){
        return "我是消费者80，对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己";
    }

🌴 目前的问题：

● 每个业务方法对应一个兜底的方法，代码膨胀
● 统一和自定义的分开
解决问题：
● 代码膨胀
○ feign接口系列 @DefaultProperties(defaultFallBack="")

@DefaultProperties(defaultFallBack=" ")

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

● 和业务逻辑混一起？？
● 服务降级，客户端去调用服务端，碰上服务端宕机或关闭
● 本次案例服务降级处理是在客户端80实现完成的，与服务端8001没有关系，只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦

//编写一个类实现Feign接口
@Service
public class PaymentFallBackService implements PaymentHystrixService{
    @Override
    public String paymentInfo_OK(Integer id) {
        return "---PaymentFallBackService fall back-paymentInfo_OK,o(Π__Π)0";
    }

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

在这里插入图片描述

🌱 服务熔断

熔断机制的概述

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

实操

修改cloud-provider-hystrix-payment8001

Service业务逻辑层

//===============以下服务熔断=====上面是服务降级=============
@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 不能为负数，请稍后再试，/(T o T)/~~~ id: "+id;
}

Controller前端控制器

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

结论：
● 熔断类型
○ 熔断打开请求不再进行调用当前服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态
○ 熔断关闭熔断关闭不会对服务进行熔断
○ 熔断半开部分请求根据规则调用当前服务，如果请求成功且符合规则认为当前服务恢复正常，关闭熔断
● 断路器在什么情况下起作用
在这里插入图片描述

涉及到断路器的三个重要参数：快照时间窗、请求总数阈值、错误百分比阈值

快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒
请求总数阈值：在快照时间窗内，必须满足请求总数阈值才有资格熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用次数不足20次，即使所有的请求都超时或者其他原因失败，断路器都不会打开
错误百分比阈值：当请求总数在快照时间窗内超过了阈值，比如发生了30次调用，如果在这30次调用中，有15次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%阈值情况下，这时候就会将断路器打开。
● 断路器开启或关闭的条件
○ 当满足一定的阈值的时候（默认10秒内超过20个请求次数）
○ 当失败率达到一定的时候（默认10秒内超过50%的请求失败）
○ 到达以上阈值，断路器将会开启
○ 当开启的时候，所有请求都不会进行转发
○ 一段时间之后（默认是5秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，继续开启。重复4和5
● 断路器打开之后
○ 再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback，通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果
○ 原来的主逻辑要如何恢复呢？
hystrix为我们实现了自动恢复功能。当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器将继续进入打开状态，休眠时间窗重新计时。

🎍 Hystrix工作流程

🎋 服务监控HystrixDashboard

概述

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard）,Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表的和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-stream项目实现了对以上指标的监控，SpringCloud也提供了Hystrix Dashboard的整合，对监控内容转换成可视化界面
实心圈：共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康从绿色<黄色<橙色<红色递减
该实心圈除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圈就越大，所以通过该实心圈的展示，就可以在大量的实例中快速的发现故障实例和高压力实例

$🔔 🔔 🔔 E n d i n g 🔔 🔔 🔔$

在这里插入图片描述

IT派同学

关注

7
点赞
踩
8

收藏

觉得还不错? 一键收藏
打赏
6
评论
【微服务&云原生】用实际案例探究Hystrix 断路器执行流程

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩盘，所谓的对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的i所有资源都在几秒钟内饱和，比失败更糟糕的是，这些应用程序还可能导致服务之间的，，和其他系统资源紧张，导致整个系统发生
复制链接

扫一扫