在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可以，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。
如下图所示A服务要调用B，而B服务在调用C时失败了，B会不断发起重试，因为同步等待，导致耗尽资源，B也不可用了，接着A也在不断重试B服务，导致A也不可用了，这就是雪崩效应
在spring cloud组件中 spring cloud Hystrix是防雪崩的利器，它也是基于Netflix提供的Hystrix进行封装的。
spring cloud Hystrix具有服务降级、依赖隔离、服务熔断、监控（Hystrix Dashboard）等功能。
服务降级
服务降级就是我们在秒杀活动中经常看到的，排队、网络出小差等情况
在实际应用当中，要注意优先核心服务，非核心服务不可用或弱可用的原则
比如当我们平台突然有大量人进来秒杀、下单，这个时候想采用服务降级来保护系统。应该考虑到商品查询、订单、支付是核心业务，而积分、广告等服务是非核心的。或者卖家查询是非核心，买家查询是核心
实现思路：
1.通过HystrixCommand注解指定
2.fallbackMethod中具体实现降级逻辑
具体代码演示
在order项目中加入spring-cloud-starter-netflix-hystrix的依赖
在启动类加上EnableCircuitBreaker注解，这时候发现这里的注解很多了，可以用SpringCloudApplication注解代替这里面的注解
因为如下图所示、SpringCloudApplication注解已经包含上面那几个注解。
现在使用两个简单的接口模拟真实的服务调用，在product服务里面有个msg的接口
在order项目里面写个testHystrixCommand1接口，在里面用RestTemplate调用product服务的msg接口
直接在浏览器调用product的msg接口，测试接口访问正常
直接在浏览器调用order的testHystrixCommand1接口，测试接口访问正常，调用product服务正常
现在在product服务关掉，再次调用order的testHystrixCommand1接口，发现报500异常
现在采用熔断机制来处理这种情况，在order的testHystrixCommand1方法上加上HystrixCommand注解
它里面的fallbackMethod就是指，当里面的服务不可用时，采用这里指定的fallback方法里面的去处理
现在product不可用，这里不会报500异常了，而是根据我们指定的熔断处理方法
修改一下代码，不再调用product服务，而是抛出一个运行时异常
发现还是采用了fallbackMethod里面指定的方法去处理这种运行时异常
针对大量的接口做fallbackMethod
有时候需要对一个controller里面的很多方法做熔断保护，像上面一个个这样写，太麻烦了，可以采用下面这种方式
在controller上加上DefaultProperties注解，defaultFallback ="defaultFallback"指定默认的处理方法，采用这种默认处理的方法上加上HystrixCommand注解即可，有个性化的就单独指定方法。
调用testHystrixCommand2接口，根据默认提示返回信息
超时设置
在product项目里面增加一个msg2方法的接口，在里面先睡眠2秒
在order项目里面增加testHystrixCommand3方法，调用这个msg2的方法
启动这两个服务，但是发现还是无法使用，但是product明明已经是启动了，这里就涉及到设置超时时间了
查看源码HystrixCommandProperties（Ctrl+ shift+ R搜索这个类）里面有这个默认的超时时间设置，这里默认的超时时间是1秒，而我们刚才的请求明显超过了这个时间，所以要修改这时间
点上面的default_executionTimeoutInMilliseconds进去，看到execution.isolation.thread.timeoutInMilliseconds，这就是我们要的配置
修改成如下配置超时时间
重启服务，这时候发现调用正常了
order代码在： https://github.com/hmilyos/springCloud-order.git hystrixBase分支
product代码在： https://github.com/hmilyos/springCloud-product.git hystrixBase分支
