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