三、服务容错保护：Spring Cloud – Hystrix

介绍

在微服务架构中，我们将系统系统拆分成了很多服务单位，各单元的应用间通过服务注册与订阅的方式相互依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络的原因或者是依赖服务自身问题出现调用故障或者延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会因等待出现故障的依赖方响应形式形成任务积压，最终导致自身服务的瘫痪。为了解决这样的问题，产生了断路器等一系列的服务保护机制。
在分布式架构中，断路器模式的作用是：当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。针对上诉问题，Spring Cloud Hystrix实现了断路器，线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的，该框架的目的在于通过控制那些访问远程系统，服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。

Hystrix设计原则
防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑。
用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复。
提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求。
将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待。

Hystrix功能特性
请求熔断：当Hystrix Command请求后端服务失败数量超过一定比例(默认比例50%)，断路器晦气换到开路状态(Open)，这时所有的请求会直接失败而不会发送请求到后端服务器。断路器保持在开路状态一段时间后(默认5秒)，自动切换到半开路状态(HALF-OPEN)。这时会判断下一次请求的返回情况，如果请求成功，断路器切回闭路状态(CLOSED)，否则重新切换到开路状态(OPEN。Hystrix的断路器就像家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效的请求影响系统的吞吐量，并且短路器有自我检测并恢复能力。
服务降级：Fallback相当于是降级操作，对于查询操作，我们可以实现一个fallback方法，当请求后端服务器出现异常的时候，可以使用fallback方法返回的值。fallback方法的返回值一般是设置的默认值或者来自缓存，告知后面的请求服务不可用了，不要再来了。
依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中，主要通过线程池来实现资源隔离，通常在使用的时候我们会根据远程服务来划分出多个线程池。比如说，一个服务调用两外两个服务，你如果调用两个服务用一个线程池，那么如果一个服务卡在那里，资源没被释放，后面的请求又来了，导致后面的请求都卡在那里等待；导致我们依赖的A服务把我们卡在那里，耗尽了资源，也导致了我们另外一个B服务不可用了。这是如果依赖隔离，某一个服务调用A B两个服务，如果我们有100个线程可用，给A服务分配50个，给B服务分配50个，这样就算A服务挂了，B服务依然可用。
请求缓存：比如一个请求过来请求我们的userId=1的数据，后面的请求也过来请求同样的数据，这时我们不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。
请求合并：我们依赖于某一个服务，我们需要调用N次，比如说查数据库的时候，我发了N次请求发了N条SQL然后拿到一堆数据，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，我们只需要查询一次数据库，提升了效率。

Hystrix工作流程

1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.