第四篇：SpringCloud之熔断器Hystrix

熔断器

雪崩效应

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

如果下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。在这里插入图片描述

熔断器（CircuitBreaker）

熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。

熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。熔断器开关相互转换的逻辑如下图：
在这里插入图片描述
熔断器就是保护服务高可用的最后一道防线。

Hystrix特性

1.断路器机制

断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。

2.Fallback

Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.

3.资源隔离

在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.

服务提供

这一篇文章基于上一篇文章的工程，启动sso-server，端口为8088; 启动serviceA两次，端口分别为8089、8090。

在ribbon使用断路器

改造sso-ribbon 工程的代码，首先在父工程pom.xml文件中加入spring-cloud-starter-hystrix的起步依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

在程序的启动类ServiceRibbonApplication 加@EnableHystrix注解开启Hystrix：

@SpringBootApplication
@EnableEurekaClient
@EnableHystrix
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

改造HelloService类，在hiService方法上加上@HystrixCommand注解。该注解对该方法创建了熔断器的功能，并指定了fallbackMethod熔断方法，熔断方法直接返回了一个字符串，字符串为"hello,"+name+",sorry,error!"，代码如下：

@Service
public class HelloService {

    @Autowired
    RestTemplate restTemplate;

    @HystrixCommand(fallbackMethod = "helloError")
    public String helloService(String name) {
        return restTemplate.getForObject("http://SERVICEA/hello?name="+name,String.class);
    }
    
    public String helloError(String name) {
        return "hello," + name + ",sorry,error!";
    }
}

启动：service-ribbon 工程，当我们访问http://localhost:8091/hello?name=chenjay,浏览器显示：
在这里插入图片描述
此时关闭 serviceA 工程，当我们再访问http://localhost:8091/hello?name=chenjay，浏览器会显示：

这就说明当 serviceA 工程不可用的时候，service-ribbon调用 serviceA的API接口时，会执行快速失败，直接返回一组字符串，而不是等待响应超时，这很好的控制了容器的线程阻塞。

Feign中使用断路器

Feign是自带断路器的，在D版本的Sprin Cloud之后，它没有默认打开。需要在配置文件中配置打开它，在配置文件加以下代码：

feign:
  hystrix:
    enabled: true

基于sso-feign工程进行改造，只需要在FeignClient的SchedualServiceHello 接口的注解中加上fallback的指定类就行了：

@FeignClient(value = "serviceA",fallback = SchedualServiceHelloHystric.class)
public interface SchedualServiceHello {
    @GetMapping(value = "/hello")
    String sayHiFromClientOne(@RequestParam(value = "name") String name);
}

SchedualServiceHelloHystric需要实现SchedualServiceHello接口，并注入到Ioc容器中，代码如下：

@Component
public class SchedualServiceHelloHystric implements SchedualServiceHello {
    @Override
    public String sayHiFromClientOne(String name) {
        return "sorry "+name;
    }
}

启动：service-feign工程，当我们访问http://localhost:8092/hello?name=chenjay,浏览器显示：
在这里插入图片描述
此时关闭 serviceA 工程，当我们再访问http://localhost:8092/hello?name=chenjay，浏览器会显示：

这证明断路器起到作用了。

源码下载：https://github.com/chenjary/SpringCloud/tree/master/springcloud-hystrix