1.3.1 Hystrix 简单介绍
hystrix 是netfix 公司开发的防止服务雪崩的短路装置，增加我们服务的容错能力，
服务雪崩：在微服务的系统中，大部分服务被拆分为多个单元，然后通过RPC或者HTTP进行调用，假如其中某个服务出现故障，同时我们设置了对应的服务超时和重试机制会导致请求堆积，假如不能及时处理可能会使得整个系统崩溃，所以我们需要一种装置能在服务不可用的时候能将该服务隔离，并且能在一段时间后重试，假如服务可用，则短路器断开，该服务节点重新提供服务。
如图是Hystrix的整体流程图
image.png
- CommondKey
Hystrix使用命令模式 HystrixCommand(Command) 包装依赖调用逻辑，每个命令在单独线程中/信号授权下执行。CommondKey 有下面4个方法。
- excute 阻塞等待返回结果或者抛错。
- queue 返回一个future ，通过future 拿结果。
- observe 返回一个observable对象 （soul 就是使用这种方式）observable对象源于RxJava ，我们可以通过observable 监听到完成事件，错误事件和成功事件。
- toObservable 返回一个Observable，当监听该Observable后hystrix命令将会执行并返回结果。
- cache 查看是否命中缓存，在Hystrix 中我们可以设置缓存，让相同的commandKey直接返回上一次结果。
- HystrixCircuitBreaker
整个是整个 Hystrix 的核心功能，其状态图如图所示，有三个状态，OPEN 即处于熔断打开状态，CLOSE 处于关闭状态，HALF_OPEN 半开状态，HALF_OPEN 和 OPEN 这两个状态存在着相互转换的关系，比如soul中设置跳闸休眠时间，在超过该时间后就会触发OPEN状态向HALF_OPEN 转移，但HALF_OPEN 还没达到关闭跳闸的条件又会重新转为 OPNE 状态。
image.png
- semaphore OR ThreadPool
Hystrix 对服务的隔离有两种方式一种是线程池，一种是信号量。
- 线程池：线程池是 Hystrix 默认的隔离模式，Hystrix为不同的服务都创建独立的线程池。
- 信号量：使用信号量标志不同服务的状态。
1.3.2 修改服务设置故障
我们先将之前准备的SpringCloud工程进行修改，随机睡眠10s。
/**
* Find by id order dto.
*
* @param id the id
* @return the order dto
*/
@GetMapping("/findById")
@SoulSpringCloudClient(path = "/findById")
public OrderDTO findById(@RequestParam("id") final String id) throws InterruptedException {
OrderDTO orderDTO = new OrderDTO();
orderDTO.setId(id);
orderDTO.setName("hello world spring cloud findById");
Random random = new Random();
if (random.nextInt(10) > 2) {
Thread.sleep(10 * 1000);
}
return orderDTO;
}
1.3.3 soul 相关配置
我们需要在soul-admin启动Hystrix 插件，并定义它的selector 和 selector的规则。
image.png
这里我们先配置selector ，设置路径为/Springcloud/**。
image.png
然后设置具体规则，我们这里定义/springcloud/order/findById 为匹配规则路径，Hystrix 的使用信号量的方式进行服务熔断，Hystrix的comondGroup 使用Context-path，Hystrix的CommondKey 使用我们匹配的路径，Hystrix的跳闸休眠时间为5s，即5s后重试，这里没有设置降级的策略，可以自定义一个Mock result 返回，还有这里定义错误率超过20%触发熔断。
image.png
接着我们请求服务结果如下：
mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById timed-out and fallback failed."}% mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById short-circuited and fallback failed."}% mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById short-circuited and fallback failed."}% mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById short-circuited and fallback failed."}% mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById short-circuited and fallback failed."}% mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById short-circuited and fallback failed."}% mac@AndydeMacBook-Pro ~ curl http://localhost:9195/springcloud/order/findById\?id\=1
{"code":500,"message":"Internal Server Error","data":"/springcloud/order/findById timed-out and fallback failed."}% mac@AndydeMacBook-Pro ~
我们先看第一次请求，这里直接请求到SpringCloud服务，然后time-out，这是我们预期的结果，接着请求就触发了熔断 short-circuited（我们没有配置follback，所以不会降级服务而是直接熔断）。我们连续请求，看最后一次请求结果，又发生了超时，这代表我们的请求又到了后面SpringCloud的服务。
