SpringCloud微服务的熔断机制以及相关概念介绍

1、什么是服务的熔断机制？

熔断机制是对系统的防护，比如受到一些恶意攻击，那么需要熔断机制来保护系统的微服务，做出响应，避免资源被耗尽。既要能响应，又要能防护，当我们的请求达到一个负载阈值，就启用熔断，把真实接口关掉，给客户端请求一个响应，这个响应，我们可以设置。服务熔断就是对该服务的调用执行熔断，对应后续请求，不在继续调用该目标服务，而是直接返回，从而可以快速释放资源，或者服务出现故障，会把故障信息返回给客户端

服务熔断的几种方式：

断路器，这是一个硬件设施，比如保险丝或者电子设备等等

断路器模式，可以进行故障检测，断路器状态一般包括Closed关闭，Open打开，Half-Open半打开

2、熔断的意义？

本质上是为了保护系统，让系统保持稳定；

减少性能损耗；

及时响应；

熔断器的功能：异常处理、日志记录、测试失败的操作、手动复位、并发、加速断路、重试失败请求

3、熔断与降级的区别？

相似性：目的一致、表现类似、粒度一致

区别：触发条件不同，熔断一般是故障引起，降级一般是整体性能。管理目标层次不同。

4、使用Hystrix，实现熔断机制，springboot结合Hystrix

pom.xml

<!-- 集成hystrix -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
            <version>${spring.cloud.version}</version>
        </dependency>

application.class，这是在原来的Feign实例上，加上熔断器

@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrix
@EnableFeignClients(clients=CityClient.class)
@ComponentScan(basePackages={"com.example.*"})
public class WeaterApiApplication {

    public static void main(String[] args) {
        SpringApplication.run(WeaterApiApplication.class, args);
    }

}

HttpController.class

@RestController
@RequestMapping("/http")
public class HttpController {

    @Autowired
    CityClient cityClient;
    
    /**
     * 熔断器的应用场景是有进行服务之间的调用。这里使用feign调用weather服务，所以这里如果无法访问
     * weather的getDataParam服务的时候，就启动熔断器，调用反馈方法fallback
     * @param city
     * @return
     */
    @HystrixCommand(fallbackMethod="fallback")
    @RequestMapping("/getDataParam/{city}")
    public String getDataParam(@PathVariable("city")String city){
        return cityClient.getDataParam(city);
    }
    
   public String fallback(String city){
        return "services is not running! parameters city is:"+city;
    }
}

测试，getDataParam服务正常能访问

关闭服务

===================================================================================== 

另外一种是使用类来创建熔断器，类要实现Feign定义的接口，每个服务方法对应一个熔断器方法
@FeignClient(name="weather",fallback=CityClientFallBack.class)
public interface CityClient {

    @GetMapping("/getCityWeather")
    public String listCity();
    
    //http://localhost:8766/weath/weather/getData
    //使用zuul,@GetMapping("/weath/weather/getData")
    @GetMapping("/getData")
    public String getData();
    
    @GetMapping("/getDataParam/{city}")
    public String getDataParam(@PathVariable("city")String city);
}

CityClientFallBack.class(这里我们使用的是接口实现，还可以直接在方法上使用注解@HystrixCommand，或者controller类使用@DefaultProperties注解)

@Component
public class CityClientFallBack implements CityClient{

    @Override
    public String listCity() {
        /**
         * 比如这里是访问城市列表的，这个时候这个服务不能访问。
         * 就要返回默认城市列表，这里就不具体写实现代码
         */
        return null;
    }

    @Override
    public String getData() {
        return "getData service is not running!";
    }

    @Override
    public String getDataParam(String city) {
        return "getData service is not running!";
    }
}

关闭getDataParam服务，测试访问，出现正确的反馈测试

雪崩效应

在微服务架构中，可能因为某一个基础服务故障，而导致多个服务之间的调用，出现阻塞，无法调用，一环扣一环，导致所有服务不可用，我们称这效应为雪崩效应。

断路器机制

断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

Fallback

Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存。

服务降级的应用场景很多，比如我们使用app的时候，服务请求失败，会提示服务器开小差了这种提示，就是一种服务降级的应用场景，等服务恢复正常了，就不会提示。再如双十一、秒杀活动，查询不到商品详情，提示找不到商品等等类似的场景。

还有服务的访问时间，也就是请求超时的问题，这些在Hystrix的注解里，都有配置参数，具体自查，点击注解进去，都能看得到。

限流机制--nignx 使用网关 

限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

docker通过仓壁模式，实现进程隔离，使得容器之间互不影响。而Hystrix实现线程池隔离，会为每个HystrixCommand，创建独立的线程池，这样就算某个在HystrixCommand下包装的依赖服务，出现延迟过高的情况，也只是对该依赖的服务产生影响，不会影响其他服务的调用。所以使用HystrixCommand包装的方法，Hystrix自动实现了依赖隔离、服务降级。

微服务和分布式中，容错是必须要做的，一种是重试机制，对于预期短暂的故障，可以使用重试，是可以解决的。对于更长时间，解决的的故障问题，你不断尝试，也是没有太大意义的。这个时候可以使用断路器模式，断路器模式是将一个受保护的服务封装在一个断路器对象里，当故障达到一定的值，断路器将会跳闸，断路器对象，返回错误。

断路器模式

hystrix超时设置
controller下使用hystrix

Feign使用hystrix 

使用配置项，在application.ym或者bootstrap.yml里配置

#熔断器启用
feign.hystrix.enabled=true
hystrix.command.default.execution.timeout.enabled=true
#断路器的超时时间,下级服务返回超出熔断器时间，即便成功，消费端消息也是TIMEOUT,所以一般断路器的超时时间需要大于ribbon的超时时间，ribbon是真正去调用下级服务
#当服务的返回时间大于ribbon的超时时间，会触发重试
#断路器的超时时间默认为1000ms，太小了
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=60000

#断路器详细设置
#当在配置时间窗口内达到此数量的失败后，进行短路。默认20个）
#hystrix.command.default.circuitBreaker.requestVolumeThreshold=20
#短路多久以后开始尝试是否恢复，默认5s）
#hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=5
#出错百分比阈值，当达到此阈值后，开始短路。默认50%）
#hystrix.command.default.circuitBreaker.errorThresholdPercentage=50%
————————————————
版权声明：本文为CSDN博主「金麟十三少」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012373281/article/details/89761656

原文：https://www.cnblogs.com/yuerugou54/p/11632579.html