微服务：Eureka，Ribbon，Hystrix( 八 ) _微服务

@Configuration 标识当前类为配置类
@ConditionalOnClass(RestTemplate.class) 表示只有存在 RestTemplate 类时该配置才会装配生效。
@ConditionalOnBean(LoadBalancerClient.class) 表示只有存在 LoadBalancerClient 类时改配置才生效。
restTemplates 集合会自动注入添加了 @LoadBalanced 注解的 RestTemplate 对象。
LoadBalancerInterceptorConfig 的 restTemplateCustomizer 为 restTemplates 集合添加了拦截器；该拦截器就是后续拦截请求进行负载处理的。

Hystrix 熔断器Hystrix 熔断器属于一种容错机制。

微服务中的雪崩效应微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。
服务雪崩效应：是一种因“服务提供者的不可用”导致“服务调用者不可用”，并将不可用逐渐放大的现象。

[MQ 微服务，MQ 微服务，MQ 微服务] ----> 静态化微服务 ----> 商品微服务站在静态化微服务角度来看：扇入 - 上游服务对该服务的调用扇出 - 该服务对下游服务的调用

扇入：代表着该微服务被调用的次数，扇入大，说明该模块复用性好。
扇出：该微服务调用其他微服务的个数，扇出大，说明业务逻辑复杂。

扇入大是一个好事，扇出大不一定是好事。
在微服务架构中，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务 A 调用微服务 B 和微服务 C，微服务 B 和微服务 C 又调用其它的微服务，这就是所谓的“扇出” 。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务 A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应” 。
最下游商品微服务响应时间过长，大量请求阻塞，大量线程不会释放，会导致服务器资源耗尽，最终导致上游服务甚至整个系统瘫痪。
形成原因 - 服务雪崩的过程可以分为三个阶段：

服务提供者不可用。
重试加大请求流量。
服务调用者不可用。

服务雪崩的每个阶段都可能由不同的原因造成：

服务提供者不可用：硬件故障、程序 Bug、缓存击穿、用户大量请求 。重试加大请求流量：用户重试、代码逻辑重试 。服务调用者不可用：同步等待造成的资源耗尽 。

雪崩效应解决方案从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段。
介绍三种技术手段应对微服务中的雪崩效应，这三种手段都是从系统可用性、可靠性角度出发，尽量防止系统整体缓慢甚至瘫痪。
服务熔断熔断机制是应对雪崩效应的一种微服务链路保护机制。在各种场景下都会接触到熔断。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，熔断该节点微服务的调用，进行服务的降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
注意：
1）服务熔断重点在“断”，切断对下游服务的调用。
2）服务熔断和服务降级往往是一起使用的，Hystrix 就是这样。
服务降级通俗讲就是整体资源不够用了，先将一些不关紧的服务停掉（调用的时候，返回一个预留的值，也叫做兜底数据），待渡过难关高峰过去，再把那些服务打开。
服务降级一般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调用，此刻客户端可以自己准备一个本地的 Fallback 回调，返回一个默认值，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。
服务限流服务出问题或者影响到核心流程的性能时，暂时将服务屏蔽掉，待高峰或者问题解决后再打开；但是有些场景并不能用服务降级来解决，比如秒杀业务这样的核心功能，这个时候可以结合服务限流来限制这些场景的并发 / 请求量。
限流措施：