【微服务】服务熔断与降级(二)

秒速五厘米 2022-05-15 06:42 401阅读 0赞

上篇博客,我们了解到服务熔断和降级解决的问题,这篇小编将为您介绍服务熔断与降级的用法,从实践中更深理解熔断与降级。

Hystrix断路器

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

不错,服务熔断和降级就靠它了。

服务熔断:

从服务提供者考虑:消费者调用提供者,提供者无法提供服务时(异常),提供者会给出提示。

1、添jar
2、改application.yml
3、启动类加@Enable…注解
4、写各层代码:dao/service/controller

  1. @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
  2. //一旦调用服务方法失败并抛出错误信息后,会自动调用@HystrixCommand标注的fallbackMethod,调用类中的指定方法
  3. @HystrixCommand(fallbackMethod = "processHystrix_Get")
  4. public Dept get(@PathVariable("id") Long id) {
  5. Dept dept = service.findById(id);
  6. if (null == dept) {
  7. throw new RuntimeException("该ID:" + id + "没有对应的信息");
  8. }
  9. return dept;
  10. }
  11. public Dept processHystrix_Get(@PathVariable("id") Long id) {
  12. return new Dept().setDeptno(id).setDname("该ID:" + id + "没有对应的信息,,null--@HystrixCommand").setDb_source("no this database in MySQL");
  13. }

但是这种方式,有不合理的地方:
第一、加一个方法都要加一个@Hystrix注解,方法膨胀;
第二、处理异常和业务逻辑高耦合。根据面向切面AOP,可以实现处理异常和业务逻辑解耦。

要实现解耦,我们看controller,注入了service,所以我们可以把异常放到接口的地方,这样就可以解耦。别急,接着看服务降级。

服务降级:

降级是在客户端。

在服务熔断后,服务器不再被调用,消费端会调用fallbackfactory的方法,拿到提示:服务提供者已停止服务,不要再访问。

这就是所谓服务水平下降,但还可用,比直接挂掉要好。

controller代码:

  1. @Autowired
  2. private DeptClientService service;
  3. @RequestMapping(value = "/consumer/dept/get/{id}")
  4. public Dept get(@PathVariable("id") Long id)
  5. {
  6. return this.service.get(id);
  7. }

api层定义:DeptClientService

  1. //该接口下哪个方法抛异常,会调fallbackFactory
  2. @FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory=DeptClientServiceFallbackFactory.class)
  3. public interface DeptClientService
  4. {
  5. @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
  6. public Dept get(@PathVariable("id") long id);
  7. }

定义DeptClientServiceFallbackFactory类:

  1. @Component // 不要忘记添加
  2. public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
  3. @Override
  4. public DeptClientService create(Throwable throwable)
  5. {
  6. return new DeptClientService() {
  7. @Override
  8. public Dept get(long id)
  9. {
  10. return new Dept().setDeptno(id).setDname("该ID:" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
  11. .setDb_source("no this database in MySQL");
  12. }
  13. @Override
  14. public List<Dept> list()
  15. {
  16. return null;
  17. }
  18. @Override
  19. public boolean add(Dept dept)
  20. {
  21. return false;
  22. }
  23. };
  24. }
  25. }

Dashboard

Hystrix dashboard,一个可视化界面,监控所有Provider,所有Provider都需要配置监控依赖spring-boot-starter-actuator。
这里写图片描述
填好对应信息,监控的服务器,点击Monitor Stream即可看到监控页面:
这里写图片描述

监控窗口怎么看?

7色——7种颜色
1圈——绿色的圈,颜色变化代表实例的健康程度,它的健康度从绿色<黄色<橙色<红色递减,大小代表实例的请求流量的变化,快速发现故障实例和高压实例
1线——流量上升和下降趋势

总结:

技术源于生活。

随着我们划分的微服务越来越多,各种配置我们就要统一管理了,分布式配置中心Config,您应该想了解的,请看下篇博客!

感谢您的阅读!

发表评论

表情:
评论列表 (有 0 条评论,401人围观)

还没有评论,来说两句吧...

相关阅读

    相关 服务之Hystrix降级熔断

    前言 分布式系统面临的问题-----服务雪崩 多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。

    相关 服务熔断降级简介

    背景   很多网站背后都是一个庞大的分布式系统,多个子系统之间的调用大多是远程调用,要么HTTP要么RPC,这种远程调用其实是不可控的,当调用链越长,风险也就越大。

    相关 服务熔断服务降级

    1 服务雪崩 现象:在一个时刻微服务系统中所有微服务均不可用的这种现象称为服务雪崩 引发:在调用链路中某个服务执行时间过长,导致自生服务