第五章 服务容错保护： Spring Cloud Hystrix

　　在微服务架构中， 存在着那么多的服务单元， 若一个单元出现故障， 就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。为了解决这样的问题， 产生了断路器等一系列的服务保护机制

　　Spring Cloud Hystrix实现了断路器、 线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的， 该框架的目标在于通过控制那些访问远程系统、 服务和第三方库的节点， 从而对延迟和故障提供更强大的容错能力。Hystrix具备服务降级、 服务熔断、 线程和信号隔离、 请求缓存、 请求合并以及服务监控等强大功能

快速入门

先部署按照以上架构图一些服务：

• eureka-server工程： 服务注册中心， 端口为1111
• hello-service工程： HELLO-SERVICE的服务单元， 两个实例启动端口分别为8081和 8082
• ribbon-consume工程：使用Ribbon 实现的服务消费者， 端口为9000

在未加入断路器之前， 关闭8081的实例， 发送GET请求到http://localhost:9000/ribbon-consumer, 可以获得输出，接下来开始引入Spring Cloud Hystrix

在ribbon-consumer工程的pom.xml的dependency节点中引入springcloud-starter-hystrix依赖：

 <dependency>
 　　<groupid>org.springframework.cloud</groupid>
 　　<artifactid>spring-cloud-starter-hystrix</artifactid>
 </dependency> 

在ribbon-consumer工程的主类ConsumerApplication中使用@Enable­-CircuitBreaker注解开启断路器功能：

  @EnableCircuitBreaker
  @EnableDiscoveryClient
  @SpringBootApplication
 4  public class ConsumerApplication { 
  @Bean
 6  @LoadBalanced
 7  RestTemplate restTemplate() {
 8  　　return new RestTemplate();
 9  }
10  public static void main(String[) args) {
11 　　SpringApplication.run(ConsumerApplication.class, args)
12  }
13  }

注意：这里还可以使用 Spring Cloud 应用中的@SpringCloudApplication 注解来修饰应用主类， 该注解的具体定义如下所示。 可以看到， 该注解中包含了上述我们所引用的三个注解， 这也意味着—个 Spring Cloud 标准应用应包含服务发现以及断路器

 @Target ({ ElementType.TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 @Inherited
 @SpringBootApplication
 @EnableDiscoveryClient
 @EnableCircuitBreaker
 public interface SpringCloudApplication {
 }

改造服务消费方式， 新增 HelloService 类， 注入 RestTemplate 实例。 然后，将在 ConsumerController中对 RestTemplate 的使用迁移到 helloService函数中， 最后， 在 helloService 函数上增加@HystrixCornrnand 注解来指定回调方法：

 @Service
 2 public class HelloService { 
 3 　　@Autowired
 4 　　RestTemplate restTemplate; 
 5 　　@HystrixCommand(fallbackMethod = "helloFallback")
 6 　　public String helloService() {
 7 　　　　return restTemplate.getForEntity("http://HELLO-SERVICE/hello", String.class).getBody();
 9 　　｝ 
10 　　public String helloFallback () (
11 　　　　return "error";
12 　　}
13 }

修改 ConsumerController 类， 注入上面实现的 HelloService 实例， 并在helloConsumer 中进行调用：

1 @RestController
2 public class ConsumerController { 
3 　　@Autowired
4 　　HelloService helloService; 
5 　　@RequestMapping(value = "/ribbon-consumer", method= RequestMethod.GET)
6 　　public String helloConsumer () {
7 　　　　return helloService.helloService();
8　　　}
9 }

重新启动之前关闭的 8081 端口的 Hello-Service, 确保此时服务注册中心、 两个 Hello-Service 以及 RIBBONCONSUMER 均已启动，访问 http://localhost:9000/ribbon-consumer 可以轮询两个 HELLO-SERV工CE 并返回一些文字信息。 此时我们继续断开 8081 的 HELLO-SERVICE,然后访问 http://localhost:9000/ribbon-consumer, 当轮询到 8081 服务端时，输出内容为 error, 不再是之前的错误内容，Hystrix 的服务回调生效。除了通过断开具体的服务实例来模拟某个节点无法访问的情况之外， 我们还可以模拟一下服务阻塞（长时间未响应）的情况。 我们对 HELLO-SERVICE 的/hello 接口做一些修改

 1 @RequestMapping(value = "/hello", method= RequestMethod.GET)
 2 public String hello() throws Exception {
 3 　　Serviceinstance instance= client.getLocalServiceinstance();
 4 　　／／让处理线程等待几秒钟
 5 　　int sleepTime = new Random() . nextint (3000);
 6 　　logger.info("sleepTime:" + sleepTime);
 7 　　Thread.sleep{sleepTime);
 8 　　logger.info("/hello, host:" + instance.getHost() + ", service id:" +
 9 　　instance.getServiceid());
10 　　return "Hello World";
11 }
}

通过 Thread. sleep ()函数可让/hello 接口的处理线程不是马上返回内容，而是在阻塞几秒之后才返回内容。 由于 Hystrix 默认超时时间为 2000 毫秒， 所以这里采用了 0至3000 的随机数以让处理过程有一定概率发生超时来触发断路器。为了更精准地观察断路器
的触发，在消费者调用函数中做一些时间记录，具体如下：

 @HystrixCommand(fallbackMethod = "helloFallback", commandKey = "helloKey")
2 public spring hello() {
3 long start = System.currentTimeMillis();
4     ／／消费服务的逻辑
5     ···
6     long end= System.currentTimeMillis();
7     logger.info("Spend time : "+ (end - start));
8     return result.toString();
9 }

重新启动HELLO-SERVICE和RIBBON-CONSUMER的实例，连续访问http://localhost:9000/ribbon-consumer几次，我们可以观察到，当RIBBON-CONSUMER的控制台中输出的Spend time大于2000的时候，就会返回error, 即 服务消费者因调用的服务超时从而触发熔断请求， 并调用回调逻辑返回结果