hystrix 页面_微服务 | 使用Hystrix实现Spring Cloud的熔断机制

1. 熔断机制介绍

在介绍熔断机制之前，我们需要了解微服务的雪崩效应。在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。

如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

扇出

熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand，Hystrix会找有这个注解的方法，并将这类方法关联到和熔断器连在一起的代理上。当前，@HystrixCommand仅当类的注解为@Service或@Component时才会发挥作用。

上一节中，我们提到，微服务之间的调用可以通过两种方式，一个是RestTemplate，另一个是Feign。相对应，在这两种调用方式下，都有Hystrix调用方法。

2. 代码实现及验证

本次代码实现对RestTemplate和Feign两种微服务调用场景下，使用Hystrix验证Spring Cloud的熔断机制。

2.1 RestTemplate的微服务调用场景

在第五节负载均衡，我们使用了RestTemplate实现了服务之间的调用。我们基于这一部分的代码，增加Hystrix，实现熔断机制。

1）启动Eureka-Server及LOADBALANCE-SERVICE，不要启动Bookingcar-Service

点击"LOADBALANCE-SERVICE"后面链接，进入负载均衡验证页面，输入请求参数/v1/lb/testport?name=bookingcar-service，我们会在页面上得到以下的错误提示：

2）在pom.xml里，添加对Hystrix的依赖

3）在ribbon-service入口程序RibbonServiceApplication.java处添加注解@EnableCircuitBreaker，开启熔断器功能，如下所示：

4）在LoadBalanceService.java里，使用了@Service注解声明了LoadBalanceService类。我们在LoadBalanceService类里通过@HystrixCommand注解引入对TestPort调用的熔断机制，@HystrixCommand注解里可以添加回调函数，如@HystrixCommand(callbackCommand = "XXX“），当无法调用TestPort服务时，熔断机制的回调函数就会发生作用，对错误进行快速处理。