Hystrix熔断器

雪崩 

        当山坡积雪内部的内聚力抗拒不了它所受到的重力拉引时,积雪便向下滑动,引起⼤量雪体崩塌,人们把这种自然现象称作雪崩
        微服务中,一个请求可能需要多个微服务接口才能实现,会形成复杂的调用链路
        服务雪崩效应,是一种因“服务提供者的不可用”(原因)导致“服务调用者不可用”(结果),并将不可用逐渐放大的现象
                扇入:代表着该微服务被调用的次数,扇人大,说明该模块复用性好
                扇出:该微服务调用其他微服务的个数,扇出大,说明业务逻辑复杂
                扇入大是一个好事,扇出大不一定是好事
        服务雪崩效应形成原因
                1. 服务提供者不可用(硬件故障,程序BUG,缓存击穿,用户大量请求)
                2. 重试加大请求流量(用户重试,代码逻辑重试)
                3. 服务调用者不可用(同步等待造成的资源耗尽)
        服务雪崩效应解决方案
              1.  服务熔断:当扇出链路的某个微服务不可用或者响应时间太长时,熔断该节点微服务的调用,进行服务的降级,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后,恢复调用链路(和服务降级一起使用,重点在"断",切断对下游服务的调用)
              2. 服务降级:把无关紧要的服务关掉,留给目前处于高峰的服务,每个服务都要在关停掉后能给用户返回一个默认值
              3.服务限流:在一次性有大多数用户涌入时,限制用户的数量,均速的放行用户
                        1).限制总并发数(如数据库连接池、线程池)
                        2).限制瞬时并发数(如Nginx限制瞬时并发连接数)
                        3).限制时间窗口内的平均速率(如Guava的RateLimiter、Nginx的limit_req模块,限制每秒的平均速率)
                        4).限制远程接口调用速率、限制MQ的消费速率等

Hystrix

        Hystrix:由Netfix开源的一个延迟和容错库,用于隔离访问远程系统,服务或者第三方库,防止级联失败,从而提升系统的可用性和容错性
        包裹请求:使用HystrixCommand包裹对依赖的调用逻辑。页面静态化微服务方法(@HystrixCommand添加Hystrix控制)。
        跳闸机制:当某服务的错误率超过一定的阈值时,Hystrix可以跳闸,停止请求该服务一段时间。 
        资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(舱壁模式)。如果该线程池已满,发往该依赖的请求就被立即拒绝,而不是排队等待,从而加速失败判定。
        监控:Hystrix可以近乎实时地监控运行指标和配置的变化,例如成功、失败、超时、以及被拒绝的请求等
        回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑由开发人员自行提供,例如返回一个缺省值。
        自我修复:断路器打开一段时间后,会自动进入“半开”状态(探测服务是否可用,如还是不可用, 再次退回打开状态) .

Hystrix应用

          1.在page微服务中导图熔断器的依赖

        
        
            org.springframework.cloud
            spring-cloud-starter-netflix-hystrix
        

        2.在page的启动类上启动熔断器

@EnableCircuitBreaker//开启Hystrix熔断器功能

Hystrix熔断器_第1张图片

         3.在page控制层,设置获取端口接口的熔断

    //如果服务提供者请求等待时间过长,服务消费方通过Hytrix来控制
    @HystrixCommand(
            threadPoolKey = "queryById",//线程池标识配置,默认情况下所有的请求共同维护一个线程池
            threadPoolProperties = {//配置线程的详细内容
                    @HystrixProperty(name = "coreSize",value = "2"),//核心线程为2
                    @HystrixProperty(name = "maxQueueSize",value = "20")//等待队列的最大长度
            },
            commandProperties = {//配置熔断器的属性信息
                    @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value = "2000")//设置请求的超时时间(ms),一旦超过配置的时间会触发Hystrix的处理机制
            }
    )
    //获取服务的端口号
    @RequestMapping("queryPort")
    public String queryProductServerPort(){
       String url="http://leq-service-product/server/getPort";
      return restTemplate.getForObject(url,String.class);
    }

Hystrix熔断器_第2张图片        4.为了演示熔断我们需要手动创建一个错误,在product900中的获取端口的接口中让线程睡眠5秒

import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("server")
public class ServerConfigController {
    @Value("${server.port}")
    private String serverprot;

    @RequestMapping("getPort")
    public String findServerPort(){
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return serverprot;
    }
}

Hystrix熔断器_第3张图片

        5.重启page和product的项目,eureka集群之后启动,重启后在浏览器访问该接口

http://localhost:9100/page/queryPort

Hystrix熔断器_第4张图片

 Hystrix熔断器_第5张图片

         可以看到一个正常一个又queryProductServerPort timed-out这个错误,说明我们的熔断配置成功,接下来就将该错误改为一个返回值就好

        6自定义服务不可用时返回默认数据(降级处理)        

                fallbackMethod = "" 如果对应的服务提供者出现问题,则会调用fallbackMethod属性指向的方法,将该方法的返回值作为最终响应给客户端的数据,该方法和目标方法的格式(返回值,参数)一致    

public String fallbackMethodgetPort(){
        return "-1";
    }

Hystrix熔断器_第6张图片

         7.重启page的微服务项目,重新访问上面的端口

Hystrix熔断器_第7张图片

Hystrix熔断器_第8张图片

         可以看到异常已经改为我们自定义的返回值

 

Hystrix舱壁模式:

        如果不进行任何设置,所有熔断方法使用一个Hystrix线程池(10个线程),那么这样的话会导致问题,这个问题并不是扇出链路微服务不可用导致的,而是我们的线程机制导致的,如果方法A的请求把10个线程都用了,方法B请求处理的时候压根都没法被访问,因为没有线程可用,并不是方法B服务不可用。为了避免服务请求过多导致正常服务无法访问的问题,Hystrix不是采用增加线程数,而是单独的为每一个控制方法创建一个线程池的方式,这种模式叫做“舱壁模式”,也是线程隔离的手段

Hystrix工作流程与高级应用

        Hystrix的工作流程图:

Hystrix熔断器_第9张图片

             1.在调用出现问题时,开启一个时间窗
             2.在这个时间窗内,统计调用次数是否达到最小请求数
             如 果没有达到,则重置统计信息,回到第1步。
             如果达到了,则统计失败的请求数占所有请求数的百分比,是否达到阈值。
                     (1)如果达到,则跳闸(不再请求对应服务)。
                     (2)如果没有达到,则重置统计信息,回到第1步。
             3.如果跳闸,则会开启一个活动窗口(默认5S),每隔5秒,Hystrix会让一个请求通过,到达那个问题服务,看是否调用成功?如果成功,重置断路器回到第1步;如果失败,回到第3步

        高级应用

                1.注解在@HystrixCommand下的commandProperties里面进行配置

 


             //Hystrix高级配置,定制工作过程细节
  @HystrixProperty(name="metrics.rollingStats.timeInMilliseconds",value = "8000"),//时间窗口的时长
  @HystrixProperty(name="circuitBreaker.requestVolumeThreshold",value = "2"),//时间窗口内的最小请求数
  @HystrixProperty(name="circuitBreaker.errorThresholdPercentage",value = "50"),//错误数量的百分比阈值
  @HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds",value = "3000")//自我修复时的活动窗口长度

Hystrix熔断器_第10张图片           配置完成后重启,只要我们之前的业务没影响就证明配置成功Hystrix熔断器_第11张图片Hystrix熔断器_第12张图片

 

         

         2.将注解注释掉,确保是配置文件生效Hystrix熔断器_第13张图片        在核心配置文件中配置(熔断器)

#时间窗口的时长
hystrix.command.default.metrics.rollingStats.timeInMilliseconds=8000
#强制打开熔断器
hystrix.command.default.circuitBreaker.forceOpen= false
#触发熔断错误比例阈值,默认值50%
hystrix.command.default.circuitBreaker.errorThresholdPercentage= 50
#熔断后休眠时间,默认值5秒
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds= 3000
#熔断触发最大请求次数,默认值是20
hystrix.command.default.circuitBreaker.requestVolumeThreshold= 2
#熔断超时设置,默认为1秒
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds= 2000

        在核心配置文件中配置(暴露接口)application.properties

#SpringBoot中暴露健康检查等断点接口
#management.endpoints.web.exposure.include="*"
#暴露健康接口的细节
management.endpoint.health.show-details=always

        不知道为什么我的SpringBoot中暴露健康检查等断点接口在application.properties中无法使用,只能在yml文件中生效

# Spring Boot中暴露健康检查等断点接口
management:
  endpoints:
    web:
      exposure:
        include: "*"

Hystrix熔断器_第14张图片Hystrix熔断器_第15张图片          在核心配置文件中配置(配置线程池)application.properties

#配置线程池队列
#并发执行的最大线程数
hystrix.threadpool.default.coreSize=10
#队列的最大存储数量
hystrix.threadpool.default.maxQueueSize=1500
#队列的最大请求数量
hystrix.threadpool.default.queueSizeRejectionThreshold=800

        配置完成后重启page的微服务项目,访问原来的接口也都有使用,然后我们配置了暴露接口,可以通过autuator/health来访问,通过这个接口来监控服务中心的健康状况

http://localhost:9100/actuator/health

Hystrix熔断器_第16张图片

 Hystrix熔断器_第17张图片

 Hystrix熔断器_第18张图片

 

你可能感兴趣的:(hystrix,spring,cloud)