1.Hystrix的概述
在分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。
Hystrix可以让我们在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。
Hystrix通过将依赖服务进行资源隔离，进而组织某个依赖服务出现故障的时候，这种故障在整个系统所有的依赖服务调用中进行蔓延，同时Hystrix还提供故障时的fallback降级机制
总而言之，Hystrix通过这些方法帮助我们提升分布式系统的可用性和稳定性
2.Hystrix的功能
hystrix，就是一种高可用保障的一个框架，类似于spring（ioc，mvc），mybatis，activiti，lucene，框架，预先封装好的为了解决某个特定领域的特定问题的一套代码库
高可用性保障的一个框架
3.Hystrix的设计原则是什么？
（1）对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
（2）在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了，服务A故障了，整套分布式系统全部故障，整体宕机
（3）提供fail-fast（快速失败）和快速恢复的支持
（4）提供fallback优雅降级的支持
（5）支持近实时的监控、报警以及运维操作
调用延迟+失败，提供容错
阻止故障蔓延
快速失败+快速恢复
降级
监控+报警+运维
完全描述了hystrix的功能，提供整个分布式系统的高可用的架构
4、Hystrix要解决的问题是什么？
（1）在复杂的分布式系统架构中，每个服务都有很多的依赖服务，而每个依赖服务都可能会故障
（2）如果服务没有和自己的依赖服务进行隔离，那么可能某一个依赖服务的故障就会拖垮当前这个服务
举例来说，某个服务有30个依赖服务，每个依赖服务的可用性非常高，已经达到了99.99%的高可用性，那么该服务的可用性就是99.99%的30次方，也就是99.7%的可用性，
99.7%的可用性就意味着3%的请求可能会失败，因为3%的时间内系统可能出现了故障不可用了，对于1亿次访问来说，3%的请求失败，也就意味着300万次请求会失败，也意味着每个月有2个小时的时间系统是不可用的，在真实生产环境中，可能更加糟糕，上面也就是说，即使你每个依赖服务都是99.99%高可用性，但是一旦你有几十个依赖服务，还是会导致你每个月都有几个小时是不可用的
5、再看Hystrix的更加细节的设计原则是什么？
（1）阻止任何一个依赖服务耗尽所有的资源，比如tomcat中的所有线程资源
（2）避免请求排队和积压，采用限流和fail fast来控制故障
（3）提供fallback降级机制来应对故障
（4）使用资源隔离技术，比如bulkhead（舱壁隔离技术），swimlane（泳道技术），circuit breaker（短路技术），来限制任何一个依赖服务的故障的影响
（5）通过近实时的统计/监控/报警功能，来提高故障发现的速度
（6）通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度
（7）保护依赖服务调用的所有故障情况，而不仅仅只是网络故障情况，调用这个依赖服务的时候，client调用包有bug，阻塞，等等，依赖服务的各种各样的调用的故障，都可以处理
6、Hystrix是如何实现它的目标的？
（1）通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离
（2）对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间，但是一般我们可以自己设置一下
（3）为每一个依赖服务维护一个独立的线程池，或者是semaphore，当线程池已满时，直接拒绝对这个服务的调用
（4）对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计
（5）如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复
（6）当一个服务调用出现失败，被拒绝，超时，短路等异常情况时，自动调用fallback降级机制
（7）对属性和配置的修改提供近实时的支持
7、简单案例
（1）引入依赖
<!-- hystrix断路器 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
（2）相关配置
# 配置开启
feign:
hystrix:
enabled: true
# hystrix禁止服务超时，默认为1s就会走服务降级，导致业务逻辑正常走了，只是因为没及时返回导致走了服务降级的操作
hystrix:
command:
default:
execution:
timeout:
enabled: false
生产环境不要写false，最好是设置超时时间，默认为1s
（3） 代码块
@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
@EnableHystrix
public class AppOrder{
publicstaticvoidmain(String[]args){
SpringApplication.run(AppOrder.class,args);
}
}
//服务降级demo
@HystrixCommand(fallbackMethod ="orderToUserInfoFallback")
@GetMapping("/orderToUserInfo")
public ResponseBaseorderToUserInfoHystrix() {
System.out.println("orderToUserInfo:" +"当前线程池名称:" + Thread.currentThread().getName());
return memberServiceFeigin.getUserInfo();
}
@RequestMapping("/orderToUserInfoFallback")
public ResponseBaseorderToUserInfoFallback() {
return setResultError("系统错误!!!!");
}
（4）Fallback方法独立模块
使用@HystrixCommand会很复杂，尤其是把fallbackMethod写在每个具体的类里。
可以把fallbackMethod写到独立的模块，继承Feign客户端，然后在feignClient里加上fallback对应的类即可。
@FeignClient(name=””,fallbackMethod=A1.class)
public Aextends Interfaces{};
public A1extends A{
@Override
public method1(){
//fallback具体内容
}
}
（5）Fallback与blockHandler的区别
fallback是服务熔断或者业务逻辑出现异常执行的方法（1.6版本以上）
blockHandler 限流出现错误执行的方法。
《什么是分布式系统以及其中的故障和Hystrix》
