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

时间: 2024-10-02 21:12:59

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

【微服务】之四:轻松搞定SpringCloud微服务-负载均衡Ribbon

对于任何一个高可用高负载的系统来说,负载均衡是一个必不可少的名称.在大型分布式计算体系中,某个服务在单例的情况下,很难应对各种突发情况.因此,负载均衡是为了让系统在性能出现瓶颈或者其中一些出现状态下可以进行分发业务量的解决方案.在SpringCloud 体系当中,加入了Netflix公司的很多优秀产品,其中一个就是针对于服务端进行负载均衡的Ribbon. 本系列博文目录 [微服务]之三:轻松搞定SpringCloud微服务目录 本系列为连载文章,阅读本文之前强烈建议您先阅读前面几篇. 相关简介

基于SpringCloud 微服务架构下 广告系统设计与实现

第1章 课程简介本章对这门课程进行说明,包括:广告系统的介绍.课程使用的技术介绍.课程的学习规划等. 第2章 广告系统概览与准备工作本章会介绍广告系统的思想.广告系统的技术实现架构.学习本课程之前的准备工作和广告系统的代码目录结构. 第3章 广告系统骨架开发广告系统使用SpringCloud微服务框架开发,并使用Maven做多模块管理.这一章完成项目骨架的开发,包括搭建注册中心和服务网关,同时也会对Maven的重要特性做介绍. 第4章 微服务通用模块开发本章实现广告系统微服务通用的功能,例如:统

springcloud微服务实战:Eureka+Zuul+Ribbon+Hystrix+SpringConfig

原文地址:http://blog.csdn.net/yp090416/article/details/78017552 springcloud微服务实战:Eureka+Zuul+Ribbon+Hystrix+SpringConfig 相信现在已经有很多小伙伴已经或者准备使用springcloud微服务了,接下来为大家搭建一个微服务框架,后期可以自己进行扩展.会提供一个小案例: 服务提供者和服务消费者 ,消费者会调用提供者的服务,新建的项目都是用springboot,附源码下载. coding仓库

从零开始,轻松搞定SpringCloud微服务系列

本系列博文目录 [微服务]之一:从零开始,轻松搞定SpringCloud微服务系列–开山篇(spring boot 小demo) [微服务]之二:从零开始,轻松搞定SpringCloud微服务系列–注册中心(一) [微服务]之三:从零开始,轻松搞定SpringCloud微服务-配置中心

【微服务】之五:轻松搞定SpringCloud微服务-调用远程组件Feign

上一篇文章讲到了负载均衡在Spring Cloud体系中的体现,其实Spring Cloud是提供了多种客户端调用的组件,各个微服务都是以HTTP接口的形式暴露自身服务的,因此在调用远程服务时就必须使用HTTP客户端.我们可以使用JDK原生的URLConnection.Apache的Http Client.Netty的异步HTTP Client, Spring的RestTemplate.但是,用起来最方便.最优雅的还是要属Feign了.今天这一篇文章是系列教程中第五篇,也是对负载均衡的第二篇,主

springcloud微服务实战:Eureka+Zuul+Feign/Ribbon+Hystrix Turbine+SpringConfig+sleuth+zipkin

参考:springcloud微服务实战:Eureka+Zuul+Feign/Ribbon+Hystrix Turbine+SpringConfig+sleuth+zipkin 原创 2017年09月18日 11:46:28 标签: 微服务架构 / 微服务组件 / eureka / ribbon / zuul 26459 springcloud微服务实战:Eureka+Zuul+Feign/Ribbon+Hystrix Turbine+SpringConfig+sleuth+zipkin 相信现在

springcloud微服务系列之服务注册与发现组件Eureka

一.Eurake的简介二.使用Eureka进行服务的注册消费1.创建一个服务注册中心2.创建服务的提供者3.创建服务的消费者总结 一.Eurake的简介 今天我们来介绍下springcloud的核心组件Eureka,Eurake是负责微服务架构中服务治理的功能,负责各个服务实例的注册与发现. Eureka包含了服务器端和客户端组件.服务器端,也被称作是服务注册中心,用于提供服务的注册与发现. 客户端组件包含服务消费者与服务生产者.在应用程序运行时,服务生产者向注册中心注册自己的服务实例,当消费者

SpringCloud微服务负载均衡与网关

1.使用ribbon实现负载均衡ribbon是一个负载均衡客户端 类似nginx反向代理,可以很好的控制htt和tcp的一些行为.Feign默认集成了ribbon. 启动两个会员服务工程,端口号分别为8762.8763,订单服务使用负载均衡策略轮训到会员服务接口. 在上一篇SpringCloud微服务基础上修改Service_Menber项目代码区分端口项目 package com.zhang.controller; import org.springframework.beans.factor

SpringCloud微服务之跨服务调用后端接口

SpringCloud微服务系列博客: SpringCloud微服务之快速搭建EurekaServer:https://blog.csdn.net/egg1996911/article/details/78787540 SpringCloud微服务之注册服务至EurekaServer:https://blog.csdn.net/egg1996911/article/details/78859200 SpringCloud微服务之集成thymeleaf访问html页面/静态页面&热部署:https