使用Hystrix实现微服务的容错处理
容错机制
如果服务提供者相应非常缓慢，那么消费者对提供者的请求就会被强制等待，知道提供者相应超时。在高负载场景下，如果不作任何处理，此类问题可能会导致服务消费者的资源耗尽甚至整个系统崩溃。
雪崩效应
微服务架构的应用系统通常包含多个服务层，微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。我们常把“基础服务故障”导致“级联故障”的现象成为雪崩效应。雪崩效应描述的是提供者不可用导致消费者不可用，并将不可用逐步扩大的过程。
如何容错
为了防止雪崩效应，必须有一个强大的容错机制。该容错机制需实现以下两点：
1、为网络请求设置超时
必须为网络请求设置超时。正常情况下，一个远程调用一般在及时毫秒内就能得到响应了。如果依赖的服务不可用或者网络有问题，那么响应时间就会变得特别长。
通常情况下，一次远程调用对应着一个线程/进程。如果响应太慢，这个线程/进程就得不到释放。而线程/进程又对应着系统资源，如果得不到释放的线程/进程约积越多，资源就会逐渐被耗尽，最终导致服务的不可用。
2、使用断路器模式
如果对某个微服务的请求有大量超时（常常说明该微服务不可用），再去让新的请求访问该服务已经没有任何意义，只会无所谓消耗资源。例如，设置了超时时间为1秒，如果短时间内有大量的请求无法在1秒内得到响应，就没有必要再去请求依赖的服务了。
断路器可理解为对容易导致错误的操作的代理。这种代理能够统计一段时间内调用失败的次数，并决定是正常请求依赖的服务还是直接返回。
断路器可以实现快速失败，如果它在一段时间内检测到许多类似的错误（例如超时），就会在之后的一段时间内，强迫对该服务的调用快速失败，即不再请求所依赖的服务。这样，应用程序就无需再浪费cpu时间去等待长时间的超时。
断路器也可自动诊断是否已经恢复正常。如果发现依赖的服务已经恢复正常，那么就会恢复请求该服务。使用这种方式，就可以实现微服务的“自我修复”——当依赖的服务不正常打开断路器时快速失败，从而防止雪崩效应；当发现依赖的服务恢复正常时，又会恢复请求。
断路器状态转换逻辑：
- 正常情况下，断路器关闭，可正常请求依赖的服务
- 当一段时间内，请求失败率达到一定阀值（例如错误率达到50%，或100次/分钟等），断路器就会打开。此时，不会再去请求依赖的服务。
- 断路器打开一段时间后，会自动进入“半开”状态。此时，断路器可允许一个请求访问依赖的服务。如果该请求能够调用成功，则关闭断路器；否则继续保持打开状态。
使用Hystrix实现容错
Hystrix简介
Hystrix是一个实现了超时机制和断路器模式的工具类库。是由Netfix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。
包裹请求：使用HystrixCommand（或者HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
跳闸机制：当某服务的错误率超过一定阀值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。
资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判断
监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员自行提供，例如返回一个缺省值。
自我修复：断路器打开一段时间后，会自动进入“半开”状态。
项目整合Hystrix
1.pom.xml添加依赖
1
2
3
4
< dependency >
< groupId >org.springframework.cloud</ groupId >
< artifactId >spring-cloud-starter-hystrix</ artifactId >
</ dependency >
2.在启动类上加注解@EnableCircuitBreaker或@EnableHystrix，从而为项目启用短路器支持。
3.修改controller，让其中的findById方法具备容错能力。
为findById方法编写了一个回退方法findByIdFallback，该方法与findById方法具有相同的参数和返回值，返回一个默认的user；在findById方法上，使用注解@HystrixCommand的findbackMethod属性，指定回退方法。
Htstrix线程隔离策略与传播上下文
Hystrix的隔离策略有两种：分别是线程隔离和信号量隔离。
THREAD（线程隔离）：使用该方式，HystrixCommand将会在单独的线程上执行，并发请求受线程池中的线程数量的限制。
SEMAPHONRE（信号量隔离）：使用该方式，HystrixCommand将会在调用线程上执行，开销相对较小，并发请求受到信号量个数的限制。
Hystrix中默认并且推荐使用线程隔离（THREAD），因为这种方式有一个除网络超时以外的额外保护层。
一般来说，只有当调用负载非常高时（例如每个实例每秒调用数百次）才需要使用信号量隔离，因为这种场景下使用THREAD开销会比较高。信号量隔离一般仅适用于非网络调用的隔离。
