概述
前言:微服务架构的应用系统通常包含多个服务层,微服务之间通过网络进行通信,从而支撑起整个系统,因此,服务之间难免存在依赖关系。但是,任何微服务都并非100%有用,网络通常很脆弱,难免有请求会失败。
雪崩效应:服务提供者不可用导致服务消费者不可用,并将不可用逐渐放大的过程。
如何容错
要想防止雪崩效应,必须有一个强大的容错机制。该容错机制需实现如下两点:
(1)为网络请求设置超时:正常情况下,一个远程调用一般在几十毫秒内就能得到响应,如果依赖的服务不可用或者网络有问题,那么响应的时间就会变长。而通常情况下,一次远程调用对应一个线程/进程,如果响应太慢,线程/进程所占用的系统资源得不到释放,线程/进程越积越多,资源逐渐被耗尽,最终导致服务不可用。因此,必须为每个网络请求设置超时,最终导致服务的不可用。
(2)使用断路器模式:类似于电路的保险丝,当电流过载时,电路不断升温,当达到一定的阀值时,保险丝就会熔断以保护电路的安全。同理,当大量服务请求某一服务,而这一服务又请求数据库(数据库已不可用)的操作时,可能会引起雪崩,所以,断路器的存在是很有必要的。
集群容错框架Hystrix
Hystrix是Netflix下的一个Java库,SpringCloud将Hystrix整合到Netflix项目中,Hystrix通过添加延迟阀值以及容错的逻辑,来帮助我们控制分布式系统间组件的交互。Hystrix通过隔离服务间的访问点、停止它们之间的级联故障、提供可回退操作来实现容错。
执行逻辑:当前基础服务模块或者数据库不可用时,服务A将对其进行“熔断”,在一定的时间内,服务A都不会再调用基础服务,以维持本身的稳定。
Hystrix主要通过以下几点实现延迟和容错:
- 包裹请求:使用HystrixCommand(或HystrixObservableCommand)包裹对依赖的调用逻辑,每个命令在独立线程中执行。
- 跳闸机制:当某个服务的错误率超过一定阀值时,Hystrix可以自动或手动跳闸,停止该服务一段时间
- 资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(或信号量),如果该线程池已满,发往该依赖的请求就被立即拒绝而不是排队等待。
- 监控:Hystrix可以近乎实时地监控指标和配置的变化,例如成功、失败、超时和被拒绝的请求等
- 回退机制:当请求失败、超时、被拒绝或当断路器打开时,执行回退逻辑。回退逻辑可由开发人员自己提供,例如返回一个缺省值。
- 自我修复:断路器打开一段时间后,会自动进入“半开”状态。断路器打开、关闭、半开的逻辑转换如下:
1)正常情况下,断路器关闭,可正常请求依赖的服务
2)在一段时间内,请求失败率达到一定阀值(例如错误率达到50%,或100次每分钟),断路器就会打开。此时,不会再去请求依赖的服务
3)断路器打开一段时间后,会自动进入“半开”状态。此时,断路器可允许一个请求访问依赖的服务。如果请求能调用成功,则关闭断路器;否则继续保持打开状态。
整合Hystrix
第一步:添加依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
第二步:在启动类上添加注解@EnableCircuitBreaker或@EnableHystrix,为项目启用断路器支持
第三步:修改Controller,让其方法具有容错能力
@HystrixCommand(fallbackMethod = "findByIdFallBack")
@GetMapping("/user/{id}")
public User findById(@PathVariable Long id)
{
return this.restTemplate.getForObject("http://microservice-provider/"+id,User.calss);
}
public User findByIdFallBack(Long id)
{
User user = new User();
return user;
}
最后
以上就是明理哑铃为你收集整理的微服务之集群保护容错(Hystrix)集群容错框架Hystrix的全部内容,希望文章能够帮你解决微服务之集群保护容错(Hystrix)集群容错框架Hystrix所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复