从永远到永远-Spring Cloud（四）-Hystrix处理雪崩（有问题，没找到，需要再处理！）

想象一个场景：
一个用户请求来了，它需要调用几个服务，但是这几个服务中有一个或者几个挂掉了。如果没有处理机制，这个请求就卡住了（实际业务一般叫阻断性问题）。tomcat默认连接数是200，如果两百个请求都涉及到挂掉的那个服务。那么这两百个线程都会处在阻塞状态，其他用户的请求就不会再被接收处理。这也就是传说中的雪崩问题。
这就要介绍今天的主角：Hystrix。这个东西，有点眼熟！

豪猪的“绅士风度”之可贵，尚不在那一身的钢针似的刺毛。它是矮胖胖的，一张方正而持重的面孔，老是踱着方步，不慌不忙。它的潇洒悠闲，实在也到了殊堪〔殊堪〕特别值得。钦佩的地步：可以在一些滋味不坏的灌木丛中玩上一个整天，很有教养似地边走边哼，逍遥自得，无所用心，宛然是一位乐天派。它不喜群的生活，但也并非完全孤独，由此可见它在“待人接物”上多么有分寸。我是狗。——鲁教版六年级下册《森林中的绅士》

Hystrix主要通过两种方式提供保护：
1）线程隔离，服务降级
2）服务熔断

1.线程降级：每个服务分配一部分的线程（线程池的形式）提供服务。如果某个服务挂了，只会阻断部分的线程。当然也不能一直让其卡住，通过设置响应时长，超时会返回信息，给出友好提示。也就是服务降级。（服务降级大约可以理解为，原来一共是十个服务，有一个gg了，不就降级成九个了。不太准确，不过好理解。。。）
触发服务降级：1）请求超时2）线程满了

1）加依赖（注意是加到哪个pom中，加到consumer的pom，防止因user-service出现问题影响自身访问。）

<!--引入Hystrix依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>

2）启动类加注解@EnableCircuitBreaker
换另一个注解代替注释掉的三个注解也可以。因为一个正常的Springlcoud程序基本都需要这三个注解。

/*@EnableDiscoveryClient
@SpringBootApplication
@EnableCircuitBreaker*/
@SpringCloudApplication
public class ConsumerApplication {
	@Bean
	@LoadBalanced
	public RestTemplate restTemplate(){
		return new RestTemplate();
	}

	public static void main(String[] args) {
		SpringApplication.run(ConsumerApplication.class,args);
	}
}

3）控制层加注解并添加访问超时返回方法
1》给单个controller添加

因为本身有默认超时时长（1000ms），为了看到测试失败效果，我们给userservice方法加五秒睡眠时间。

启动个服务成功后，进行测试：

---

以下作废！！！！！！！！！！！！！！！！！！！！！！在类体添加DefaultProperties注解之后，无论是否超时都只走该注解指定的方法，正常请求方法没走过。没有找到问题，心态爆炸。

---

2》一个controller可能有很多方法，而且参数类型也不一致。如果每一个都要单独设置fallback方法，简直不要太麻烦。所以，可以对其统一处理。

启动服务，做测试：

---

对于特定的业务，超时时长也可以单独配置。尴尬的是，我这里没有测试出来。。。据说我用的是老版视频。。。不应该吧，向下兼容吧。。。

---

---

3》也可以配置文件处理，配置完也是跟上边一个问题。。。

---