前面讲过 Spring cloud 之多种方式限流(实战)来处理请求频繁的压力。大家都知道,多个微服务之间调用的时候,假设微服务 A 调用微服务 B 和微服务 C,微服务 B 和微服务 C 有调用其他的微服务,这就是所谓的 扇出,若扇出的链路上某个微服务的请求时间过长或者不可用,对微服务 A 的调用就会占用越来越多的时间以及更多资源,进而引起系统雪崩,即”雪崩效应”。
这个时候,需要一个机制来保证当某个微服务出现异常时(请求反应慢或宕机),其整个流程还是阔以友好滴进行下去。即向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就可以保证调用方的线程不会被长时间、无厘头滴占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。我们把这个机制,或者这种处理方式叫作“熔断器”。
熔断机制是应对雪崩效应的一种微服务链路保护机制,当整个链路的某个微服务异常时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回“合理”的响应信息。当检测到该节点微服务正常后恢复调用链路,在Spring cloud 框架机制通过 Hystrix 实现,Hystrix 会监控微服务见调用的状况,当失败的调用到一个阈值,默认是5秒内20次调用失败就会启动熔断机制,熔断机制的注解是 @HystrixCommand。
最近研究了一下 Spring cloud 的熔断机制,特分享一些代码,以及实战中的坑。
在Spring cloud 中,假设有几个微服务:用户管理服务、订单服务、鉴权中心、物流服务等。这时,订单服务中,某个接口请求用户管理服务,这个时候如果需要熔断机制,该怎么处理呢?
首先,订单服务引入依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
这个时候,订单服务启动类中需要引用熔断注解 @EnableCircuitBreaker,使其生效:
/**
* @author Damon
* @date 2020年1月13日 下午3:23:06
*
*/
@EnableOAuth2Sso
@Configuration
@EnableAutoConfiguration
@ComponentScan(basePackages = {"com.damon"})
@EnableDiscoveryClient
@EnableCircuitBreaker
public class OrderApp {
public static void main(String[] args) {