Spring Cloud 七：服务容错保护（Hystrix服务降级 和 ）【Dalston版】
前言
在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过服务注册与订阅的方式互相依赖。
由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，
而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。
如果这样的架构存在如此严重的隐患，那么相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器等一系列的服务保护机制。
** 为了解决服务间调用出现延迟的问题
动手试一试
eureka-server工程：服务注册中心，端口：1001eureka-client工程：服务提供者，两个实例启动端口分别为2001
下面我们可以复制一下之前实现的一个服务消费者：eureka-consumer-ribbon，命名为eureka-consumer-ribbon-hystrix。
下面我们开始对其进行改在：
第一步：pom.xml的dependencies节点中引入spring-cloud-starter-hystrix依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
第二步：在应用主类中使用 @EnableCircuitBreaker 或 @EnableHystrix注解开启Hystrix的使用：
@EnableCircuitBreaker @EnableDiscoveryClient @SpringBootApplication public class Application { @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } public static void main(String[] args) { new SpringApplicationBuilder(Application.class).web(true).run(args); } }
第三步：改造服务消费方式，新增ConsumerService类，然后将在Controller中的逻辑迁移过去。
最后，在为具体执行逻辑的函数上增加 @HystrixCommand 注解来指定服务降级方法，比如：
@RestController public class DcController { @Autowired ConsumerService consumerService; @GetMapping("/consumer") public String dc() { return consumerService.consumer(); } class ConsumerService { @Autowired RestTemplate restTemplate; @HystrixCommand(fallbackMethod = "fallback") public String consumer() { return restTemplate.getForObject("http://eureka-client/dc", String.class); } public String fallback() { return "fallback"; } } }
下面我们来验证一下上面Hystrix带来的一些基础功能。我们先把涉及的服务都启动起来，
然后访问localhost:2101/consumer，此时可以获取正常的返回，比如：Services: [eureka-consumer-ribbon-hystrix, eureka-client]。
为了触发服务降级逻辑，我们可以将服务提供者eureka-client的逻辑加一些延迟，比如：
@GetMapping("/dc")
public String dc() throws InterruptedException {
Thread.sleep(5000L);
String services = "Services: " + discoveryClient.getServices();
System.out.println(services);
return services;
}
重启eureka-client之后，再尝试访问localhost:2101/consumer，此时我们将获得的返回结果为：fallback。
我们从eureka-client的控制台中，可以看到服务提供方输出了原本要返回的结果，但是由于返回前延迟了5秒，
而服务消费方触发了服务请求超时异常，服务消费者就通过HystrixCommand注解中指定的降级逻辑进行执行，
因此该请求的结果返回了fallback。这样的机制，对自身服务起到了基础的保护，同时还为异常情况提供了自动的服务降级切换机制。
思路：
eureka-client 是服务提供方
Thread.sleep(5000L); 方法里睡眠5秒，
然后再去访问我们的消费方 spring-cloud-starter-hystrix
按理说应该是返回back，但是我测试时 并没有
二、依赖隔离
它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，
也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。
通过对依赖服务的线程池隔离实现，可以带来如下优势：
- 应用自身得到完全的保护，不会受不可控的依赖服务影响。即便给依赖服务分配的线程池被填满，也不会影响应用自身的额其余部分。
- 可以有效的降低接入新服务的风险。如果新服务接入后运行不稳定或存在问题，完全不会影响到应用其他的请求。
- 当依赖的服务从失效恢复正常后，它的线程池会被清理并且能够马上恢复健康的服务，相比之下容器级别的清理恢复速度要慢得多。
- 当依赖的服务出现配置错误的时候，线程池会快速的反应出此问题（通过失败次数、延迟、超时、拒绝等指标的增加情况）。同时，我们可以在不影响应用功能的情况下通过实时的动态属性刷新（后续会通过Spring Cloud Config与Spring Cloud Bus的联合使用来介绍）来处理它。
在上一篇的示例中，我们使用了@HystrixCommand来将某个函数包装成了Hystrix命令，这里除了定义服务降级之外，
Hystrix框架就会自动的为这个函数实现调用的隔离。
所以，依赖隔离、服务降级在使用时候都是一体化实现的，这样利用Hystrix来实现服务容错保护在编程模型上就非常方便的，并且考虑更为全面
