Hystrix 学习使用
说明:
- 每次调用创建一个新的HystrixCommand，把依赖调用封装在run()方法中
- 执行execute()/queue做同步或异步调用
- 请求接收后，会先看是否存在缓存数据，如果存在，则不会继续请求服务，直接返回缓存数据。如果不存在缓存数据，则继续进行第4步。
- 将判断熔断器是否为开启状态，如果开启(已经熔断)，则调用第8步FallBack（降级）处理。如果未开启，则继续调用第5步。
- 检测当前依赖的线程池是否已满，如果已满，也会调用第8步FallBack（降级）处理，同时进行第7步将结果上报给熔断器，此时上报的状态为【拒绝】。如果未满，则继续进行第6步。
- 执行的是run方法。run方法执行过程中如果发生HystrixBadRequestException以外的异常，也将调用第8步FallBack（降级）处理，同时进行第7步将结果上报给熔断器，此时上报的状态为【失败】。如果run方法执行没有异常但是超过预设的时限也将调用第8步FallBack（降级）处理，同时进行第7步将结果上报给熔断器，此时上报的状态为【超时】。
如果没有异常也未超时，则进行第9步返回结果，同时进行第7步将结果上报给熔断器，此时上报的状态为【成功】。
在第8步的降级处理中，如果没有实现getFallback的将直接抛出异常，如果降级逻辑调用，成功直接返回
，如果降级逻辑调用，失败抛出异常。
执行过程中位于熔断器之后的处理，都会将结果上报给熔断器，熔断器根据结果计算是否进行熔断。
当服务无法正常访问时，就会进行降级处理，调用fallBack降级策略：
共有5种情况会触发降级处理:
1.run()方法抛出非HystrixBadRequestException异常。
2.run()方法调用超时。
3.熔断器开启。
4.线程池已满。
5.显示调用fallback逻辑（用于特殊业务处理）
当阻塞发生时（异常，超时等），由于采用了服务降级的处理，可以保证访问可以继续进行。
作者：酱油和醋
链接：https://www.jianshu.com/p/9de4452a1aa9
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
hystrix实战
1，由于hystrix的设计是命令模式，命令模式可以将请求发送者和接收者完全解耦，所以每次使用的时候，只需讲一个请求封装为一个对象发送过去即可
2，service层的代理ServiceInterceptor的invoke里面，每次都需要一个命令对象
HystrixCommandCallWrapper hystrixCommandCallWrapper = null;
3，从元数据获得他的uri，通过fallbackManager里面拿他是否 有降级方法
4，继承关系，
HystrixCommandCallAndFallbackWrapper （多了服务降级方法，run继承父类）------》
HystrixCommandCallWrapper（重写父类run方法） ——》
HystrixCommand<Object>
5，HystrixCommandCallWrapper构造函数分析，调用了一个单例的HystrixConfigurationCurator的对象，由他来完成每次hystrixCommand调用的基本配置
粒度标识，groupKdy : （具体平台） ins-xxx-platform ， commandKey : （具体服务） IUserService/getUserRole
6，HystrixConfigurationCurator构造函数分析，
syncDefaultSetter（），加载默认配置，超时时间，并发数。。。。。
createListenerForDefaultSetter();，监听zk上/config/public/rpc/limit的配置，也重新生成已加载的Setter配置，这里有个根据对方项目有自定义配置的逻辑看不懂
this.myselfLimitCustom = readCustomConfig(ClientUtil.getProjectName()); 加载自身/config/public/rpc/limit/${自己项目}的配置(如果有的话
createListenerForCustomSetter 监听/config/public/rpc/limit的子节点的变化，更新项目自定义限流熔断配置
7，调用 Object execute = hystrixCommandCallWrapper.execute();
执行重写的run方法，真正执行语句 pr = rpcHandle.invoke(uri, data, serviceMetadata.getTimeout(method),
