Hystrix,英文意思是豪猪,全身是刺,刺是一种保护机制。Hystrix也是Netflix公司的一款组件。
实现服务熔断降级处理,保护微服务,防止雪崩效应发生,以增强系统的稳定性和弹性。
以下功能会在下面后续举例讲解:
隔离依赖:Hystrix 可以通过将每个依赖服务放在单独的线程池中来隔离依赖操作,防止某个依赖的故障或延迟影响到整个系统。
服务降级:Hystrix 可以根据配置的降级策略,在被依赖服务不可用或被依赖服务响应时间过长时,快速返回一个备选的响应结果,从而避免用户长时间等待或系统崩溃的情况。
快速失败:当调用依赖服务出现错误时,Hystrix 可以快速失败并立即返回错误,而不是等待超时。
断路器模式【熔断】:Hystrix 实现了断路器模式,可以监控依赖服务的状态,当错误率超过阈值时,会打开断路器,后续请求将被快速失败,而不会继续尝试调用依赖服务,从而减少对故障服务的访问。
资源限制:Hystrix 可以对依赖服务的调用进行限流和并发控制,防止系统因为过多的请求导致资源耗尽。
实时监控和指标收集:Hystrix 提供了丰富的实时监控和指标收集功能,可以通过 Hystrix 仪表板来查看依赖服务的健康状况、错误率、响应时间等指标,从而帮助开发人员及时发现和解决问题。
总的来说,Hystrix 可以提高分布式系统的容错性和弹性,通过隔离、降级、快速失败、断路器等机制,保护系统免受故障和延迟的影响,并提供实时监控和指标收集功能,方便开发人员进行故障诊断和性能优化。
当单个服务出现问题,调用这个服务的请求就出现线程阻塞,此时若有大量的请求涌入,容器的线程资源就会被消耗完毕导致服务瘫痪。
预防、解决服务雪崩有三种方法:
服务调用方调用服务提供方方法,服务方法内部出现异常时返回一个响应(fallback)给调用方,而不是长时间等待或者直接抛出无法处理的异常。例如:“服务器忙,请稍后再试!”
服务降级的触发条件是人为规定的,触发条件如下:
直接拒绝访问,快速返回一个开发者自定义的“异常信息”。
限制一个时间段内能够通行的请求数量。
降级和熔断的区别
熔断:熔断后请求不会再进调用服务的方法体,直接将链路断开,此后的每次请求都会直接被抛给fallback。
降级:降级后请求依然会进调用服务的方法体,每次请求都会先试图去调用服务,只是服务自己察觉到自己可能出问题了从而拒绝服务,然后再将请求转给fallback。直接转发到即当服务的调用出现超时、异常等情况时,返回一个响应(fallback)。降级可以用在服务调用的全链路上的任意位置,不过为了使用规范,一般建议用在提供方(让服务自己管好自己)。
使用hystrix时,版本一定要选还在Netflix时的版本号,本文选择Hoxton版本
以及其对应的spring boot 2.2.X或2.3.X
。
为了方便,项目在我们之前的zuul或者搭建eureka章节搭建的项目框架上进行开发。在之前的项目上开发并不意味着Hystrix要依赖于Eureka或者zuul,Hystrix可以独立应用。
在userservice服务中写一个错误,验证服务降低策略。
@RestController
@RequestMapping("/user")
public class UserController {
@GetMapping("/login")
public String login(){
int res = 1/0;
return "8080 login success";
}
}
此时我们重启服务,访问orderservice服务,这个服务会调用userservice服务,有两个userservice服务,其中8080服务是有异常的。当订单服务调用到部署在8080端口的服务时就会报500错误。
现在我们来看下如何实现服务降低,在userservice服务异常时,快速返回一个备选的响应结果,从而避免用户长时间等待或系统崩溃的情况。
在orderservice服务中引入依赖。
<!--熔断器-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
适用:该方法是核心业务需要针对该方法设置一个单独的fallback。
@RestController
@RequestMapping("order")
public class OrderController {
@Bean
@LoadBalanced
public RestTemplate getRestTemplate(){
return new RestTemplate();
}
@Autowired
private RestTemplate restTemplate;
@GetMapping("/info")
@HystrixCommand(fallbackMethod = "orderHandleException")
public String getOrderInfo(){
String url = "http://userservice/user/login";
String info = restTemplate.getForObject(url, String.class);
return "订单滴滴:" + info;
}
public String orderHandleException(){
return "订单服务调用失败";
}
}
添加@HystrixCommand(fallbackMethod = "orderHandleException")
,指定了异常发生时的备选方案,异常发生会去调用orderHandleException
方法。我们这里使用了fallabck为单点响应,即每个服务接口单独定义异常响应。目前我们没有进行任何配置文件的配置,但hystrix有默认的配置规则,不配置的情况下,默认配置规则也会生效,配置文件中的配置是全局的,我们也可以在方法上指定该方法的熔断策略。
@GetMapping("/info")
@HystrixCommand(fallbackMethod = "orderHandleException", commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000")
})
public String getOrderInfo(){
String url = "http://userservice/user/login";
String info = restTemplate.getForObject(url, String.class);
return "订单滴滴:" + info;
}
我们上面的配置是针对单个方法的响应,也可以定义一个类中所有方法的默认fallback,来统一处理服务降级。
@RestController
@RequestMapping("order")
@DefaultProperties(defaultFallback = "globalFallback")
public class OrderController {
@Bean
@LoadBalanced
public RestTemplate getRestTemplate(){
return new RestTemplate();
}
@Autowired
private RestTemplate restTemplate;
@GetMapping("/info")
@HystrixCommand(fallbackMethod = "orderHandleException", commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000")
})
public String getOrderInfo(){
String url = "http://userservice/user/login";
String info = restTemplate.getForObject(url, String.class);
return "订单滴滴:" + info;
}
@GetMapping("/didi")
@HystrixCommand
public String getOrderInfo2(){
int res = 1/0;
return "订单didi";
}
public String globalFallback(){
return "订单服务调用失败_gloabl";
}
public String orderHandleException(){
return "订单服务调用失败";
}
}
无论是单点响应还是默认响应,响应代码和业务代码都耦合在一起,全局响应将响应放在OpenFeign调用侧,使得业务代码和响应代码解耦。
依赖:OpenFeign的依赖中包含了hystrix,导入OpenFeign后不用单独导入hystrix。
在需要降级的服务上进行下面配置:orderservice
pom.xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
application.yml
feign:
hystrix:
enabled: true
orderservice服务改造:
@RestController
@RequestMapping("order")
public class OrderController {
@Resource
private UserServiceClient userServiceClient;
@GetMapping("/info")
public String getOrderInfo() {
String info = userServiceClient.login();
return "订单滴滴:" + info;
}
}
新增feign包
,创建 UserServiceClient
类:
@FeignClient(name = "userservice", fallback = UserServiceFallback.class)
public interface UserServiceClient {
@GetMapping("/user/login")
String login();
}
这个类实现了服务远程调用,fallback指定了远程调用服务时异常触发服务降级。
新增fallback
包,创建UserServiceFallback
方法进行服务降级处理。
@Component
public class UserServiceFallback implements UserServiceClient {
@Override
public String login() {
return "用户服务调用失败";
}
}
启动类开启服务远程调用:@EnableFeignClients
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
@EnableFeignClients
public class ConsumerServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerServerApplication.class, args);
}
}
重启服务,orderservice服务调用会轮询调用8080和8081端口的userservice服务,如果8081端口抛异常,会直接进行服务降级处理,返回用户服务调用失败
给用户,如果8081端口超时则不会立马进行服务降级处理,而是会报504,直到满足默认的熔断配置规则才会触发服务熔断,才会直接返回用户服务调用失败
给用户。
在启动类上添加开启熔断和降级注解
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class ConsumerServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerServerApplication.class, args);
}
}
启动服务,再次访问orderservice服务。订单服务还是有可能成功的,因为8081端口的服务没有问题,异常是我们人为制造的。
目前的操作中并不需要进行配置文件配置,默认的熔断策略是5秒内20次调用失败熔断器开启5秒,在这5秒内所有请求直接返回fallback。
在orderservice服务的配置文件中进行配置熔断策略:
在application.yml中,注释可能会导致错误,报错将错误删除即可。
# 配置熔断策略:
hystrix:
command:
default:
circuitBreaker:
# 强制打开熔断器 默认false关闭的。测试配置是否生效
# forceOpen: false
# 触发熔断错误比例阈值,默认值50% 10个请求有5个被拒绝访问,则开启熔断
errorThresholdPercentage: 50
# 熔断后休眠时长,默认值5秒 熔断器开启5s后,再关闭
sleepWindowInMilliseconds: 10000
# 熔断触发最小请求次数,默认值是20 累计请求20次无响应,开启熔断
requestVolumeThreshold: 10
上面的配置就是10个请求有5个失败进行服务降级就会开启熔断器,熔断器开启10秒,如果在这个时间段内有新的请求发生,它们将不会被直接转发到服务,而是由 fallback 方法来处理,从而达到服务降级的目的。配置文件的配置是全局生效,配置也可以在对应的方法上,针对该方法配置对应的降级熔断的策略,上面已经介绍过了。
将1/0
从8080端口的userservice删去,使服务正常。
在8081端口的userservice中进行一个休眠操作,休眠3秒:
@RestController
@RequestMapping("/user")
public class UserController {
@GetMapping("/login")
public String login(){
//演示熔断超时,服务降级
try {
System.out.println("8081服务睡了3秒");
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "8081 login success";
}
}
此时重启服务,访问orderservice会发现,会发现报504错误,也就是网关超时。我们虽然使用了网关zuul,但504错误并不是因为配置了网关才会报504错误,即使不配置网关,客户端直接请求上游服务器,而上游服务器的响应时间过长,也可能导致 HTTP 504 错误。此外,还有一些其他的因素,比如网络连接问题、DNS 问题等,也可能导致 HTTP 504 错误。
# 配置熔断策略:
hystrix:
command:
default:
circuitBreaker:
# 触发熔断错误比例阈值,默认值50% 10个请求有5个被拒绝访问,则开启熔断
errorThresholdPercentage: 50
# 熔断后休眠时长,默认值5秒 熔断器开启5s后,在关闭
sleepWindowInMilliseconds: 10000
# 熔断触发最小请求次数,默认值是20 累计请求20次无响应,开启熔断
requestVolumeThreshold: 10
execution:
isolation:
thread:
# 熔断超时设置,默认为1秒 过了超时时间后,做服务降级,给用户的请求返回设置的默认值
timeoutInMilliseconds: 2000
修改服务提供者方法,休眠3秒钟,这时超时时间是2s,过了超时时间仍调用不到服务,(满足熔断策略配置规则)此时触发熔断。如果休眠时间小于超时时间,那么不会触发熔断,而是一直报504异常。即使不设置熔断超时时间,默认的熔断时间就是1秒了,所以一般来说都会触发熔断。