熔断_熔断机制 - CSDN
精华内容
参与话题
  • 什么是服务熔断

    千次阅读 2019-02-26 22:54:02
    一、什么是服务熔断?  考试过程中当断则断的方式,正好符合微服务架构中的一种安全机制:【熔断】  熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。  在互联网系统中,当下游服务因访问压力过大...

    一、什么是服务熔断?

              考试过程中当断则断的方式,正好符合微服务架构中的一种安全机制:【熔断】

             熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。

             在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,可以暂时切断对下游服务的调用。

             这种牺牲局部,保全整体的措施就叫做熔断。

      如果不采取熔断措施,我们的系统会怎样呢?

        我们来看一个栗子。

           当前系统中有A,B,C三个服务,服务A是上游,服务B是中游,服务C是下游。

            它们的调用链如下:

                

         一旦下游服务C因某些原因变得不可用,积压了大量请求,服务B的请求线程也随之阻塞。线程资源逐渐耗尽,使得服务B也变得不可用。紧接着,服务      A也变为不可用,整个调用链路被拖垮。

         

         像这种调用链路的连锁故障,叫做雪崩

    在这种时候,就需要我们的熔断机制来挽救整个系统。
    熔断机制的大体流程和刚才所讲的考试策略如出一辙:

    这里需要解释两点:

          1. 开启熔断

               在固定时间窗口内,接口调用超时比率达到一个阈值,会开启熔断。

               进入熔断状态后,后续对该服务接口的调用不再经过网络,直接执行本地的默认方法,达到服务降级的效果。

          2. 熔断恢复

               熔断不可能是永久的。

               当经过了规定时间之后,服务将从熔断状态回复过来,再次接受调用方的远程调用。

     

    二、Spring Cloud Hystrix很好的实现了熔断机制

               服务熔断的实际应用

               Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现,该框架实现了服务熔断线程隔离等一系列服务保护功能。

               对于熔断机制的实现,Hystrix设计了三种状态:

                    1.熔断关闭状态(Closed)

                           服务没有故障时,熔断器所处的状态,对调用方的调用不做任何限制。

                    2.熔断开启状态(Open)

                           在固定时间内(Hystrix默认是10秒),接口调用出错比率达到一个阈值(Hystrix默认为50%),会进入熔断开                                  启状态。

                           进入熔断状态后,  后续对该服务接口的调用不再经过网络,直接执行本地的fallback方法

                    3.半熔断状态(Half-Open)

                            在进入熔断开启状态一段时间之后(Hystrix默认是5秒),熔断器会进入半熔断状态。

                            所谓半熔断就是尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。

                            如果成功率达到预期,则说明服务已恢复,进入熔断关闭状态;如果成功率仍旧很低,则重新进入熔断开启                                     状态。

             三个状态的转化关系如下图:

                   

     

    展开全文
  • 服务熔断与降级(Hystrix)

    万次阅读 多人点赞 2019-03-30 09:42:34
    服务熔断 服务降级 熔断VS降级 Hystrix简介 使用Hystrix 引入Hystrix依赖 修改启动类 修改Controller Feign结合Hystrix 修改Feign客户端 创建Fallback处理类 修改配置 监控Hystrix 启用健康监控 启用...

    目录

    服务熔断

    服务降级

    熔断VS降级

    Hystrix简介

    使用Hystrix

    引入Hystrix依赖

    修改启动类

    修改Controller

    Feign结合Hystrix

    修改Feign客户端

    创建Fallback处理类

    修改配置

    监控Hystrix 

    启用健康监控

    启用Hystrix-Dashboard

    引入Hystrix-Dashboard依赖

    修改启动类

    仪表盘界面

    参考文章


    服务熔断

    服务熔断的作用类似于我们家用的保险丝,当某服务出现不可用或响应超时的情况时,为了防止整个系统出现雪崩,暂时停止对该服务的调用。

    服务降级

    服务降级是从整个系统的负荷情况出发和考虑的,对某些负荷会比较高的情况,为了预防某些功能(业务场景)出现负荷过载或者响应慢的情况,在其内部暂时舍弃对一些非核心的接口和数据的请求,而直接返回一个提前准备好的fallback(退路)错误处理信息。这样,虽然提供的是一个有损的服务,但却保证了整个系统的稳定性和可用性。

    熔断VS降级

    相同点:

    目标一致 都是从可用性和可靠性出发,为了防止系统崩溃;

    用户体验类似 最终都让用户体验到的是某些功能暂时不可用;

    不同点:

    触发原因不同 服务熔断一般是某个服务(下游服务)故障引起,而服务降级一般是从整体负荷考虑; 

    Hystrix简介

    Hystrix:英 [hɪst'rɪks] 美 [hɪst'rɪks] ,翻译过来是“豪猪”的意思。 在分布式环境中,不可避免地会出现某些依赖的服务发生故障的情况。Hystrix是这样的一个库,它通过添加容许时延和容错逻辑来帮助你控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点,阻止跨服务的级联故障,并提供了退路选项,所有这些都可以提高系统的整体弹性。

    Hystrix的设计目的:

    通过第三方客户端的库来为访问依赖服务时的潜在故障提供保护和控制;

    防止在复杂分布式系统中出现级联故障;

    快速失败和迅速恢复;

    在允许的情况下,提供退路对服务进行优雅降级;

    提供近实时的监控、报警和操作控制;

    接下来我们将通过对《模拟RPC调用(Feign)》一章中的 message-center 项目进行改造,演示如何使用Hystrix,eureka服务注册中心以及message-service服务提供者无需更改。

    使用Hystrix

    引入Hystrix依赖

    在 pom.xml 文件中引入Hystrix依赖:

    <parent>
    		<groupId>org.springframework.boot</groupId>
    		<artifactId>spring-boot-starter-parent</artifactId>
    		<version>2.0.6.RELEASE</version>
    	</parent>
    
    	<properties>
    		<spring-cloud.version>Finchley.SR2</spring-cloud.version>
    	</properties>
    
    	<dependencies>
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-web</artifactId>
    		</dependency>
    		<!-- Eureka-Client 依赖 -->
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    		</dependency>
    		<!-- Feign 依赖 -->
    		<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>
    	</dependencies>
    
    	<dependencyManagement>
    		<dependencies>
    			<!-- SpringCloud 版本控制依赖 -->
    			<dependency>
    				<groupId>org.springframework.cloud</groupId>
    				<artifactId>spring-cloud-dependencies</artifactId>
    				<version>${spring-cloud.version}</version>
    				<type>pom</type>
    				<scope>import</scope>
    			</dependency>
    		</dependencies>
    	</dependencyManagement>

    修改启动类

    在MessageCenterApplication启动类上增加@EnableCircuitBreaker注解:

    @SpringBootApplication
    @EnableFeignClients
    @EnableCircuitBreaker
    public class MessageCenterApplication {
    
    	public static void main(String[] args) {
    		new SpringApplicationBuilder(MessageCenterApplication.class).web(WebApplicationType.SERVLET).run(args);
    	}
    
    }

    这里我们在启动类中又增加了@EnableCircuitBreaker注解,用来开启断路器功能。如果你觉得启动类上的注解个数有点多的话,可以使用一个@SpringCloudApplication 注解来代替@SpringBootApplication(或者@EnableEurekaServer)、@EnableDiscoveryClient、@EnableCircuitBreaker这三个注解。

     

    @Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    @Documented
    @Inherited
    @SpringBootApplication
    @EnableDiscoveryClient
    @EnableCircuitBreaker
    public @interface SpringCloudApplication {
    }

    修改Controller

    接下来,我们为MessageCenterController中的getMsg()接口增加断路器功能,修改部分代码如下:

    	@GetMapping("/msg/get")
    	@HystrixCommand(fallbackMethod = "getMsgFallback")
    	public Object getMsg() {
    		String msg = messageService.getMsg();
    		return msg;
    	}
    
    	public Object getMsgFallback() {
    		return "祝您 2019 猪年大吉,'猪'事如意!";
    	}

    先启动Eureka,再启动一个8771端口的message-service服务,最后启动message-center。待启动完成之后,Eureka注册中心实例注册信息如下:

    此时,访问 http://localhost:8781/api/v1/center/msg/get ,返回如下结果表明服务调用成功:

    然后,停掉message-service服务,再次请求 http://localhost:8781/api/v1/center/msg/get ,返回结果如下:

     可以看出fallback中的信息被直接返回了,表明Hystrix断路器调用成功。

    注意:fallback方法的签名需要和原方法保持一致。

    	/**
    	 * 获取消息详情
    	 */
    	@GetMapping("/api/v1/msg/detail/{id}")
    	@HystrixCommand(fallbackMethod = "getDetailFallback")
    	public MessageEntity getDetail(@PathVariable(name = "id") Long id) {
    		return messageService.getById(id);
    	}
    
    	/**
    	 * 获取消息详情退路
    	 */
    	public MessageEntity getDetailFallback(Long id){
    		return null;
    	}

    Feign结合Hystrix

    以MessageService的Feign客户端为例,为其添加Hystrix断路器功能。

    修改Feign客户端

    通过配置@FeignClient注解的fallback属性来位MessageServiceClient指定一个自定义的fallback处理类(MessageServiceFallback)。

    @FeignClient(name = "message-service", fallback = MessageServiceFallback.class)
    public interface MessageServiceClient {
    
    	@GetMapping("/api/v1/msg/get")
    	public String getMsg();
    
    }

    创建Fallback处理类

    MessageServiceFallback需要实现MessageServiceClient接口,并且在Spring容器中必须存在一个该类型的有效Bean。在这里,我们使用@Component注解将其注入到Spring容器中。

    @Component
    public class MessageServiceFallback implements MessageServiceClient {
    
    	@Override
    	public String getMsg() {
    		System.out.println("调用消息接口失败,对其进行降级处理!");
    		return "消息接口繁忙,请稍后重试!";
    	}
    
    }

    修改配置

    在新版本的Springcloud中,Feign默认关闭了对Hystrix的支持,需要在application.yml进行配置:

    feign:
      hystrix:
        enabled: true

    当message-service服务不可用时,请求 http://localhost:8781/api/v1/center/msg/get,返回结果如下:

    查看后台日志,打印如下内容,表明fallback方法被成功调用了:

    监控Hystrix 

    启用健康监控

    Actuator是Springboot提供的用来对应用系统进行自省和监控的功能模块,借助于Actuator开发者可以很方便地对应用系统某些监控指标进行查看、统计等。

    若要使用Actuator对Hystrix 流进行监控,除了需在工程POM文件中引入spring-boot-starter-actuator依赖:

    		<!-- Actuator 依赖 -->
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-actuator</artifactId>
    		</dependency>

    还需要在application.yml 中添加如下配置:

    management:
      endpoints:
        web:
          exposure:
            include: hystrix.stream

    启用Hystrix-Dashboard

    使用Hystrix一个最大的好处就是它会为我们自动收集每一个HystrixCommand的信息,并利用Hystrix-Dashboard通过一种高效的方式对每一个断路器的健康状态进行展示。

    值得注意的是,在使用HystrixCommand对RibbonClient进行包装的时候,你需要确保你配置的Hystrix超时时间要比Ribbon的超时时间长,包括由它们引起的重试时间,举个例子:如果你的Ribbon连接超时时间是1秒,并且Ribbon会连续重试请求3次,那么你的Hystrix连接超时时间需要配置成稍大于3秒。

    引入Hystrix-Dashboard依赖

    在 pom.xml 文件中引入Hystrix-Dashboard依赖:

    		<!-- Hystrix Dashboard 依赖 -->
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
    		</dependency>

    修改启动类

    在MessageCenterApplication启动类上增加@EnableHystrixDashboard注解:

    @EnableFeignClients
    @SpringCloudApplication
    @EnableHystrixDashboard
    public class MessageCenterApplication {
    
    	public static void main(String[] args) {
    		new SpringApplicationBuilder(MessageCenterApplication.class).web(WebApplicationType.SERVLET).run(args);
    	}
    
    }

    仪表盘界面

    启动应用,访问 http://localhost:8781/hystrix ,打开Hystrix-Dashboard监控首页。

     

    在这里配置好需要监控的Hystrix流地址 http://localhost:8781/actuator/hystrix.stream ,开始监控。

    参考文章

    https://github.com/netflix/hystrix/wiki

    https://github.com/netflix/hystrix

    https://cloud.spring.io/spring-cloud-netflix/single/spring-cloud-netflix.html 

    展开全文
  • 【微服务】服务熔断与降级(二)

    千次阅读 2018-08-26 15:52:34
    服务熔断: @RequestMapping(value = &quot;/dept/get/{id}&quot;, method = RequestMethod.GET) //一旦调用服务方法失败并抛出错误信息后,会自动调用@HystrixCommand标注的fallbackMethod,调用类中的...

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

    Hystrix断路器

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

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

    服务熔断:

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

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

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

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

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

    服务降级:

    降级是在客户端。

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

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

    controller代码:

    @Autowired
    private DeptClientService service;
    
    @RequestMapping(value = "/consumer/dept/get/{id}")
    public Dept get(@PathVariable("id") Long id)
    {
        return this.service.get(id);
    }

    api层定义:DeptClientService

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

    定义DeptClientServiceFallbackFactory类:

    @Component // 不要忘记添加
    public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService>
    {
        @Override
        public DeptClientService create(Throwable throwable)
        {
            return new DeptClientService() {
                @Override
                public Dept get(long id)
                {
                    return new Dept().setDeptno(id).setDname("该ID:" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
                            .setDb_source("no this database in MySQL");
                }
    
                @Override
                public List<Dept> list()
                {
                    return null;
                }
    
                @Override
                public boolean add(Dept dept)
                {
                    return false;
                }
            };
        }
    }

    Dashboard

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

    监控窗口怎么看?

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

    总结:

    技术源于生活。

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

    感谢您的阅读!

    展开全文
  • Spring Cloud - 熔断(Hystrix)

    万次阅读 多人点赞 2020-06-14 21:19:11
    熔断 小铭同学最近正在学Spring Cloud,最近学到熔断这块的知识点,不是很理解,于是请教了公司的大佬老王。 小铭趁空闲时间找到老王:“王哥,我最近在学习Spring Cloud,看到所有书上都说熔断是微服务必须的,可我...
    熔断

    小铭同学最近正在学Spring Cloud,最近学到熔断这块的知识点,不是很理解,于是请教了公司的大佬老王。

    小铭趁空闲时间找到老王:“王哥,我最近在学习Spring Cloud,看到所有书上都说熔断是微服务必须的,可我不用熔断,系统好像也能正常工作。那为什么说它是必须的呢?”

    “正常工作是没问题,那发生异常了呢?某个服务挂了或者网络不通的时候会发生什么?”老王反问小铭。

    “让我思考一下,如果一个微服务不可用了,那调用它的微服务这个服务就会抛异常,一直到最上层。可这跟熔断又有什么关系?”小铭心中还是有一些疑惑。

    老王笑了笑,解释道:“可不只是抛异常怎么简单。在Java中,每一个HTTP请求都会开启一个新线程。而下游服务挂了或者网络不可达,通常线程会阻塞住,直到Timeout。你想想看,如果并发量多一点,这些阻塞的线程就会占用大量的资源,很有可能把自己本身这个微服务所在的机器资源耗尽,导致自己也挂掉。”

    小铭有些明白了,追问道:“那是不是最终所有上游微服务都有可能挂掉?”

    “是的,这也是称为‘雪崩效应’。最开始是一个微服务挂掉了。随着时间地推移,可能会导致整个系统都不可用。”老王一边回答,一边快速地在电脑上搜出了下面这个图:
    在这里插入图片描述
    “那熔断具体是怎么解决这个问题的?”小铭点点头,然后继续追问。

    老王见小铭似乎有些明悟,但知识点还没有串联起来,便一步一步地引导他:“那你知道Spring Cloud断路器的三种状态吗?”

    似乎终于到了小铭自己比较熟悉的知识点,自信地说到:“这个我知道,Spring Cloud一般使用Hystrix来做断路器。就跟电路上的闸差不多。它有三种状态:关闭,开启和半开。最开始是关闭状态的,这个时候所有请求都可以通过;如果错误请求达到一定的阈值,就会变成开启状态,就会让所有请求短路,直接返回失败的响应;一段时间后,断路器会变成半开状态,如果下一个请求成功了,就关闭断路器,反之就开启断路器。”

    “那这个阈值具体是什么?”

    “这里主要就要用到三个属性了:”小铭快速答道

    1. hystrix.command.default.circuitBreaker.requestVolumeThreshold(当在配置时间窗口内达到此数量的失败后,进行短路。默认20个)简言之,10s内请求失败数量达到20个,断路器就会变成打开状态。
    2. hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds(短路多久以后开始尝试是否恢复,默认5s)
    3. hystrix.command.default.circuitBreaker.errorThresholdPercentage(出错百分比阈值,当达到此阈值后,开始短路。默认50%)
    资源隔离

    “非常正确!你知道Hystrix的底层原理吗?”

    于是小铭祭出了官方的图:
    在这里插入图片描述
    Hystrix整个工作流如下:

    1. 构造一个 HystrixCommand或HystrixObservableCommand对象,用于封装请求,并在构造方法 配置请求被执行需要的参数;
    2. 执行命令,Hystrix提供了4种执行命令的方法,后面详述;
    3. 判断是否使用缓存响应请求,若启用了缓存,且缓存可用,直接使用缓存响应请求。Hystrix支持
      请求缓存,但需要用户自定义启动;
    4. 判断熔断器是否打开,如果打开,跳到第8步;
    5. 判断线程池/队列/信号量是否已满,已满则跳到第8步;
    6. 执行HystrixObservableCommand.construct()或HystrixCommand.run(),如果执行失败或者超
      时,跳到第8步;否则,跳到第9步;
    7. 统计熔断器监控指标;
    8. 走Fallback备用逻辑
    9. 返回请求响应
      从流程图上可知道,第5步线程池/队列/信号量已满时,还会执行第7步逻辑,更新熔断器统计信息,而 第6步无论成功与否,都会更新熔断器统计信息。

    “Hystrix主要使用的是RxJava来做异步请求,RxJava是一个异步框架,是对观察者模式的一个应用。Hystrix会把对每个微服务的请求放到线程池里面,具体分配到哪个线程池可以使用HystrixThreadPoolKey来指定”:

    @HystrixCommand(threadPoolKey = "user-hello")
    String getUserHello();
    

    老王继续问:“那你知道为什么要有这个key吗?它是用来干嘛的?”小铭摇了摇头,表示自己还不知道。

    “你看源码就知道了,Hystrix使用了一个ConcurrentHashMap来保存线程池。”

    ConcurrentHashMap<String, HystrixThreadPool> threadPools
    

    小铭心中出现了一个新的问题:那为什么我们需要多个线程池呢?

    此时老王继续说道:“这个其实叫资源隔离。应用程序会被完全保护起来,即使依赖的一个服务出问题了,也不会影响到应用程序的其他部分。使用多个线程池就是一种资源隔离方式,也是默认的隔离方式。而且Hystrix底层是使用的RxJava,使用线程池可以让你很方便地实现异步操作。”

    “那除了线程池隔离,还有其它隔离方式吗?”

    “有的,Hystrix提供了两种隔离方式:线程池隔离和信号量(Semaphore)隔离。”

    “是的,线程池隔离就是上面说的那样。信号量主要起一个限流的作用。如果信号量耗尽了,它就直接走fallback流程所以也能防止雪崩。但大多数情况,我们更倾向于使用线程池。”

    线程池隔离优缺点
    • 优点:
      • 保护应用程序以免受来自依赖故障的影响,指定依赖线程池饱和不会影响应用程序的其余部分。
      • 当引入新客户端lib时,即使发生问题,也是在本lib中,并不会影响到其他内容。
      • 当依赖从故障恢复正常时,应用程序会立即恢复正常的性能。
      • 当应用程序一些配置参数错误时,线程池的运行状况会很快检测到这一点(通过增加错误,延迟, 超时,拒绝等),同时可以通过动态属性进行实时纠正错误的参数配置。
      • 如果服务的性能有变化,需要实时调整,比如增加或者减少超时时间,更改重试次数,可以通过线 程池指标动态属性修改,而且不会影响到其他调用请求。
      • 除了隔离优势外,hystrix拥有专门的线程池可提供内置的并发功能,使得可以在同步调用之上构 建异步门面(外观模式),为异步编程提供了支持(Hystrix引入了Rxjava异步框架)。

    注意:尽管线程池提供了线程隔离,我们的客户端底层代码也必须要有超时设置或响应线程中断,不能 无限制的阻塞以致线程池一直饱和。

    • 缺点:
      • 线程池的主要缺点是增加了计算开销。每个命令的执行都在单独的线程完成,增加了排队、调度和上下文切换的开销。因此,要使用Hystrix,就必须接受它带来的开销,以换取它所提供的好处。
      • 通常情况下,线程池引入的开销足够小,不会有重大的成本或性能影响。但对于一些访问延迟极低的服 务,如只依赖内存缓存,线程池引入的开销就比较明显了,这时候使用线程池隔离技术就不适合了,我 们需要考虑更轻量级的方式,如信号量隔离。
    fallback

    “刚刚你提到了一个词叫‘fallback流程’?”

    “是的,fallback翻译过来是‘回退’的意思,有时候我们也会称它‘服务降级’。”

    “那什么时候会触发fallback呢?”

    “其实你应该已经可以总结出来了,主要这五种情况会触发fallback:”

    • 执行超时
    • 执行过程抛出异常
    • 断路器打开状态
    • 线程池拒绝(池满后的拒绝策略)
    • 信号量拒绝(信号量耗完)

    “那触发fallback后会发生什么?”

    老王熟练的打开源码,并快速敲下了一个Demo。“这个你得看HystrixCommand这个类的源码和使用方式。”

    class AuthCommand extends HystrixCommand<Boolean> {
      public Boolean run() {
        return authService.authenticate(user);
      }
      
      protected Boolean getFallback() {
        return true;
      }
    }
    

    “我们在使用Hystrix的时候,一般是继承HystrixCommand这个类,重写rungetFallback这两个方法。正常情况它是走run方法的。如果发生了fallback,它就会调用getFallback方法。”

    小铭看着这段代码,问到:“这看起来有点麻烦,在Spring Cloud中,有更简单的使用方式吗?”

    “当然。在Spring Cloud中,Hystrix可以和OpenFeign无缝集成。OpenFeign接口上的每个方法都会被Hystrix断路器包裹(这也是一种典型的AOP实现)。你可以在注解上配置fallback方法:”

    @HystrixCommand(fallbackMethod = "getByIdFallback")
    public String getById(String id) {...}
    
    private String getByIdFallback(String id) {...}
    

    感觉熔断这一块的知识点差不多理通了,小铭认真道谢,回到自己的位置继续撸代码……

    Feign中使用断路器

    Feign是自带断路器的,在D版本的Spring Cloud之后,它没有默认打开。需要在配置文件中配置打开它,在配置文件加以下代码:

    feign:
        hystrix:
            enabled: true
    

    基于service-feign工程进行改造

    • 实现UserClient 接口,并注入到Ioc容器中,代码如下:
    @Component
    public class UserClientHystrix implements UserClient {
    
        @Override
        public String sayHello(String name) {
            return "sorry " + name + " 上游服务断开, 服务降级";
        }
    
        @Override
        public String timeOut() throws InterruptedException {
            return "链接超时,服务降级";
        }
    
        @Override
        public String exception() throws Exception {
            return "发生异常,服务降级";
        }
    }
    
    • 在FeignClient的UserClient接口的注解中加上fallback的指定类
    @FeignClient(value = "service-client", fallback = UserClientHystrix.class)
    public interface UserClient {
    
        @GetMapping("/client")
        String sayHello(@RequestParam(value = "name") String name);
    
        @GetMapping("/timeOut")
        String timeOut() throws InterruptedException;
    
        @GetMapping("/exception")
        String exception() throws Exception;
    }
    
    • 启动eureka-server,然后再启动service-client,最后启动service-feign,在浏览器输入http://localhost:8765/sayHello?name=Beck Wang,会看如下效果
      在这里插入图片描述
    • 接下来我关掉service-client,就会看到如下效果:浏览器上显示了sorry Beck Wang,上游服务断开, 服务降级,就证明我们的熔断器起作用了,否则就会报500。

    在这里插入图片描述

    • 比较常见的还有timeout,如果上游服务timeout,hystrix也是可以做出处理,首先要配置超时时间
    # 设置超时时间
    feign:
        httpclient:
            connection-timeout: 5000
    

    在这里插入图片描述

    • 还有就是上游服务抛出exception,hystrix也是可以处理
      在这里插入图片描述
    • 那么熔断之后,到底要怎么做呢?
      • 检查日志,修好它。
      • fallback就写你业务上可以返回的默认值

    源码地址

    展开全文
  • 熔断机制hystrix

    千次阅读 2018-06-12 09:13:56
    熔断机制hystrix一、问题产生雪崩效应:是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程 正常情况下的服务:某一服务出现异常,拖垮整个服务链路,消耗整个线程队列,造成服务不可用,...
  • 服务熔断设计

    2019-06-11 09:19:45
    一、熔断的目的 系统微服务化后,分布式部署,系统之间通过RPC框架进行通信,系统发生故障的概率随着系统规模的增长而加大; 在调用服务时,一些非关键路径发生问题,不能影响整个系统的服务。 二、熔断系统...
  • 服务熔断

    万次阅读 2016-12-06 20:20:51
    服务熔断的理解服务熔断也称服务隔离,来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式。服务熔断是服务降级的措施。服务熔断对服务提供了proxy,防止服务不可能时,出现串联故障(cascading ...
  • 熔断

    千次阅读 2019-01-11 18:19:39
    雪崩: 雪崩效应:是一种因 服务提供者 的不可用导致 服务调用者 的不可用,并将不可用逐渐放大的过程  正常情况下的服务: 某一服务如:DependcyI 出现异常,拖垮整个服务链路,消耗整个线程队列,造成服务不...
  • 今天介绍熔断部分,即开源产品 Sentinel 的核心能力。 问题定义 在一个常见的分布式应用中,一个请求先通过终端到达 Gateway,再经过防火墙和网络负载均衡,其中还包括调用下游的其它服务和第三方应用,才能到达...
  • 转载CSDN作者:zzzgd_666 比较全的各超时时间配置!很NICE。
  • feign 实现熔断

    千次阅读 2019-02-26 23:08:59
    1、配置文件。 2、创建一个实现了伪接口的熔断时调用的类,并且注册组件。   3、在伪接口中,配置熔断类。   4、效果  正常:    熔断
  • 什么是服务熔断,什么是服务降级?

    千次阅读 2018-10-08 12:08:18
    什么是服务熔断?   熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,可以暂时切断对下游服务的调用...
  • 有没有方法,统一处理熔断。fallback 要写太多的额外的实现类,和处理方法,太过繁琐。
  • Hystrix学习(4)熔断

    千次阅读 2016-04-23 14:48:37
    熔断模式该模式借鉴了电路熔断的理念,如果一条线路电压过高,保险丝会熔断,防止火灾。如果某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速...
  • feign转发直接进入熔断

    千次阅读 2019-06-24 14:04:04
    搞了老子一下午 https://blog.csdn.net/weixin_42844971/article/details/88890051 谢谢大佬
  • 微服务实战中如何理解服务熔断和降级的区别

    万次阅读 热门讨论 2020-07-27 23:47:30
    熔断: 举个例子解释,生活中每家每户都在用电,小明家的电线因为故障导致了小明家停电了。而小李、小张家的电是正常使用的。电力公司没有因为小明家有故障线路而停掉其他人家的电,同时小明家没有使用有故障的电路...
  • 【微服务】服务熔断与降级(一)

    千次阅读 2018-08-26 13:04:59
    服务熔断、服务降级,好高大上的样子,以前望尘莫及,今日终于揭开它神秘面纱,好好应用一把了。 了解这两者之前,我们首先要了解是产生什么问题了,才需要熔断、降级。 服务雪崩 分布式系统面临的问题是,复杂...
  • SpringBoot -- 熔断机制 Circuit Breaker

    万次阅读 2017-01-29 20:51:25
    熔断:半熔断熔断打开、熔断关闭 熔断关闭: 熔断关闭不会对服务进行熔断,当请求服务失败次数符合设定的规则则进入熔断机制 半熔断: 部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前...
  • 漫画:什么是服务熔断

    千次阅读 2018-05-07 10:36:05
    转载自 漫画:什么是服务熔断什么是服务熔断熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,可以...
  • 什么是服务熔断?什么是服务降级? 熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回“错误”的响应信息...
1 2 3 4 5 ... 20
收藏数 31,825
精华内容 12,730
关键字:

熔断