SpringCloud Day04---服务降级(Hystrix)(二)

简介: SpringCloud Day04---服务降级(Hystrix)

7.3.3 故障现象和解决方法


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


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


如何解决?解决的要求


超时导致服务器变慢(转圈)—>超时不再等待

出错(宕机或程序运行出错)—>出错要有兜底

解决:


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

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

对方服务(8001)OK,调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者),自己处理降级


7.4 服务降级

8001先从自身找问题:

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

7.4.1 8001fallback处理

  • 业务类启用 @HystrixCommand
@Service
public class PaymentServiceImpl implements PaymentService {
    /**
     * 正常访问,返回OK
     * @param id
     * @return
     */
    @Override
    public String paymentInfo_OK(Integer id) {
        return "线程池:  "+Thread.currentThread().getName()+" paymentInfo_OK,id:   "+id+"O(∩_∩)O哈哈哈~~~";
    }
    /**
     * 超时访问
     * @param id
     * @return
     */
    @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
    })
    public String paymentInfo_TimeOut(Integer id) {
        int timeNumber = 5;
        // int a  =  10 / 0;
        try {
            TimeUnit.SECONDS.sleep(timeNumber);
        }catch (InterruptedException e){
            e.printStackTrace();
        }
        return "线程池:  " + Thread.currentThread().getName() + " paymentInfo_TimeOUt,id:   " + id + "O(∩_∩)O哈哈哈~~~" + "耗时(秒):" + timeNumber;
    }
    public String paymentInfo_TimeOutHandler(Integer id){
        return "线程池:  " + Thread.currentThread().getName() + " 8001系统繁忙或者运行报错,请稍后再试,id: " + id + "\t"+"o(╥﹏╥)o呜呜呜"  ;
    }
}

@HystrixCommand报异常后如何处理?


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


132322df1f1cef27986fa87f91d8af39.png


上图故意制造两个异常:

1 int age = 10/0; 计算异常

2 我们能接受3秒钟,它运行5秒钟,超时异常。


当前服务不可用了,做服务降级,兜底的方案都是paymentInfo_TimeOutHandler


主启动类激活:添加新注解**@EnableCircuitBreaker**


7.4.2 80fallback

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

  • YML
feign:
  hystrix:
    enabled: true


  • 主启动添加@EnableHystrix


@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) {
        // int age = 10 / 0;
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }
    public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id){
        return "我是消费者80,对方支付系统繁忙请10s后再试或者自己运行出错请检查自己,o(╥﹏╥)o";
    }

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


7.4.3 存在的问题以及解决方案


存在的问题:


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


解决方案:


1、每个方法配置一个???膨胀==>需要对相同功能的进行抽取. 可以使用 @DefaultProperties(defaultFallback="" )


使用说明:


1:1 每个方法配置一个服务降级方法,技术上可以,实际上傻X


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

通用的和独享的各自分开,避免了代码膨胀,合理减少了代码量,O(∩_∩)O哈哈~

controller配置

@RestController
@Slf4j
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
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")
    // })
    @HystrixCommand //加了DefaultProperties注解,并且没有写具体方法名字,就使用统一全局的fallback
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        // int age = 10 / 0;
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }
    public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id){
        return "我是消费者80,对方支付系统繁忙请10s后再试或者自己运行出错请检查自己,o(╥﹏╥)o";
    }
    public String payment_Global_FallbackMethod(){
        return "Global异常处理信息,请稍后信息,o(╥﹏╥)o";
    }
}

d2cc78bf9f6cc87d8fd048d96ad4bec5.png


2、和业务逻辑混一起???混乱 ==>需要进行解耦,把逻辑和服务降级代码分开此处是 服务降级 最终的处理方式


  • 演示:服务降级,客户端去调用服务端,碰上服务端宕机或关闭


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

未来我们要面对的异常:运行,超时,宕机


  • 再看我们的业务类PaymentController

a760eb5405a9d36cf48ef122d0f370ee.png


修改cloud-consumer-feign-hystrix-order80

根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口,

重新新建一个类(PaymentFallbackService)实现该接口,统一为接口里面的方法进行异常处理

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


  • 为PaymentHystrixService添加@FeignClient
@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT",fallback = PaymentFallbackService.class)
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) ;
}


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


26e2b6143efc2fc4e3fd10c82ba141cb.png


2e867e3a021e4bb80045036115068646.png


7.5 服务熔断


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


7.5.1 熔断是什么


熔断机制概述


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

当检测到该节点微服务调用响应正常后,恢复调用链路。


在Spring Cloud框架里,熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,

当失败的调用到一定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。熔断机制的注解是**@HystrixCommand。**


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


7.5.2 实操


  • 修改cloud-provider-hystrix-payment8001
  • PaymentService
//===服务熔断
    @HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",commandProperties = {
            @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),//是否开启断路器
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),//请求次数  当在配置时间窗口内达到此数量的失败后,进行短路。默认20个
            @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"),//时间窗口期,也等于短路多久以后开始尝试是否恢复的时间. 默认5s
            @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),//出错百分比阈值,失败率达到此阈值后,开始短路跳闸。默认50%
    })
    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(╥﹏╥)o id:"+id;
    }

why配置这些参数

bfa070771ada012a8b4951b5a6111b12.jpg


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


  • 测试

正确: http://localhost:8001/payment/circuit/31

错误: http://localhost:8001/payment/circuit/31


5fbaa16ce582f69aa1a5fb73d78ac420.png

8614681a6caf947f16765a5eea387aa2.png

一次正确一次错误trytry.

多次错误,然后慢慢正确,发现刚开始不满足条件,就算是正确的访问地址也不能进行


b17ba6c89ef9e9fc2958c539368a3c1e.png

相关文章
|
17天前
|
存储 数据可视化 Java
基于MicrometerTracing门面和Zipkin实现集成springcloud2023的服务追踪
Sleuth将会停止维护,Sleuth最新版本也只支持springboot2。作为替代可以使用MicrometerTracing在微服务中作为服务追踪的工具。
61 1
|
2月前
|
Java UED 开发者
Spring Boot 降级功能的神秘面纱:Hystrix 与 Resilience4j 究竟藏着怎样的秘密?
【8月更文挑战第29天】在分布式系统中,服务稳定性至关重要。为应对故障,Spring Boot 提供了 Hystrix 和 Resilience4j 两种降级工具。Hystrix 作为 Netflix 的容错框架,通过隔离依赖、控制并发及降级机制增强系统稳定性;Resilience4j 则是一个轻量级库,提供丰富的降级策略。两者均可有效提升系统可靠性,具体选择取决于需求与场景。在面对服务故障时,合理运用这些工具能确保系统基本功能正常运作,优化用户体验。以上简介包括了两个工具的简单示例代码,帮助开发者更好地理解和应用。
54 0
|
1月前
|
消息中间件 存储 Java
SpringCloud基础9——服务异步通信-高级篇
消息可靠性、死信交换机、惰性队列、MQ集群
SpringCloud基础9——服务异步通信-高级篇
|
1月前
|
存储 NoSQL 调度
|
1月前
|
XML 监控 Java
Spring Cloud全解析:熔断之Hystrix简介
Hystrix 是由 Netflix 开源的延迟和容错库,用于提高分布式系统的弹性。它通过断路器模式、资源隔离、服务降级及限流等机制防止服务雪崩。Hystrix 基于命令模式,通过 `HystrixCommand` 封装对外部依赖的调用逻辑。断路器能在依赖服务故障时快速返回备选响应,避免长时间等待。此外,Hystrix 还提供了监控功能,能够实时监控运行指标和配置变化。依赖管理方面,可通过 `@EnableHystrix` 启用 Hystrix 支持,并配置全局或局部的降级策略。结合 Feign 可实现客户端的服务降级。
131 23
|
1月前
|
Java 对象存储 开发者
故障隔离与容错处理:Hystrix在Spring Cloud和Netflix OSS中的应用
故障隔离与容错处理:Hystrix在Spring Cloud和Netflix OSS中的应用
42 3
|
1月前
|
Java API 对象存储
微服务魔法启动!Spring Cloud与Netflix OSS联手,零基础也能创造服务奇迹!
这段内容介绍了如何使用Spring Cloud和Netflix OSS构建微服务架构。首先,基于Spring Boot创建项目并添加Spring Cloud依赖项。接着配置Eureka服务器实现服务发现,然后创建REST控制器作为API入口。为提高服务稳定性,利用Hystrix实现断路器模式。最后,在启动类中启用Eureka客户端功能。此外,还可集成其他Netflix OSS组件以增强系统功能。通过这些步骤,开发者可以更高效地构建稳定且可扩展的微服务系统。
46 1
|
2月前
|
存储 Java Spring
【Azure Spring Cloud】Azure Spring Cloud服务,如何获取应用程序日志文件呢?
【Azure Spring Cloud】Azure Spring Cloud服务,如何获取应用程序日志文件呢?
|
4月前
springCloud之服务降级熔断Hystrix、OpenFeign
springCloud之服务降级熔断Hystrix、OpenFeign
271 0
|
5月前
|
监控 Java API
Spring cloud Hystrix 、Dashboard、API(zuul)相关报错
Spring cloud Hystrix 、Dashboard、API(zuul)相关报错
56 2