微服务知识架构：1、服务容错 2、服务监控 3、服务的框架 4、运行时期的支撑 5、服务部署 6、 服务的安全

1、服务容错Hystrix

Why用容错？

如果一个底层服务出现问题，故障会被向上传播给用户。我们需要一种机制，当底层服务不可用时，可以阻断故障的传播。这就是断路器的作用。他是系统服务稳定性的最后一重保障。

本文主要讲解Hystrix的 超时、熔断、隔离、                

 如何实现及原理；

默认是10秒之内调用20次（有一个失败率50%），也就是说10秒中，掉了10次都是失败，5秒就返回FallBack；

可以使用hystrix-dashboard 和 turbine来检测熔断的信息；

注意：断路器是安装在服务消费者上的；

Netflix的开源组件Hystrix的流程：

图中流程的说明:

1. 将远程服务调用逻辑封装进一个HystrixCommand。

2. 对于每次服务调用可以使用同步或异步机制，对应执行execute()或queue()。

3. 判断熔断器(circuit-breaker)是否打开或者半打开状态，如果打开跳到步骤8，进行回退策略，如果关闭进入步骤4。

4.判断线程池/队列/信号量（使用了舱壁隔离模式）是否跑满，如果跑满进入回退步骤8，否则继续后续步骤5。

5.run方法中执行了实际的服务调用。a. 服务调用发生超时时，进入步骤8。

6. 判断run方法中的代码是否执行成功。a. 执行成功返回结果。b. 执行中出现错误则进入步骤8。

7. 所有的运行状态(成功，失败，拒绝，超时)上报给熔断器，用于统计从而影响熔断器状态。

8. 进入getFallback()回退逻辑。a. 没有实现getFallback()回退逻辑的调用将直接抛出异常。b. 回退逻辑调用成功直接返回。c. 回退逻辑调用失败抛出异常。

9. 返回执行成功结果。

注意：熔断是否开启熔断器主要由依赖调用的错误比率决定的，依赖调用的错误比率=请求失败数/请求总数。Hystrix中断路器打开的默认请求错误比率为50%（

1.1超时

本质上：Hystrix的超时检测本质上通过启动单独线程去检测的，线程的启动的时间刚好就是任务超时的时间，本质上就是这么个简单的逻辑。 Hystrix超时后会抛出一个HystrixTimeoutException的异常。

超时检测逻辑

 Hystrix的超时包括注册过程和执行过程两个，注册过程如下：

执行lift(new HystrixObservableTimeoutOperator(_cmd))关联超时检测任务。

在HystrixObservableTimeoutOperator类中，new TimerListener()负责创建检测任务，HystrixTimer.getInstance().addTimerListener(listener)负责关联定时任务。

在HystrixObservableTimeoutOperator类中，addTimerListener通过java的定时任务服务scheduleAtFixedRate在延迟超时时间后执行。

 Hystrix的超时执行过程如下：

在超时后执行listener.tick()方法后执行类TimerListener的tick方法

在TimerListener类的tick方法中执行timeoutRunnable.run()后执行HystrixContextRunnable的run方法

在HystrixContextRunnable类run方法中执行child.onError(new HystrixTimeoutException())实现超时。

1.2熔断

Fallback，超时是熔断的一种原因，熔断可能是线程池满、信号拒绝、熔断打开；

1.3 隔离

Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.

1.4 限流

熔断：这个模式是需要系统在设计之初，就要把熔断措施考虑进去。当系统出现问题时，如果短时间内无法修复，系统要自动做出判断，开启熔断开关，拒绝流量访问，避免大流量对后端的过载请求。系统也应该能够动态监测后端程序的修复情况，当程序已恢复稳定时，可以关闭熔断开关，恢复正常服务。

服务降级：将系统的所有功能服务进行一个分级，当系统出现问题，需要紧急限流时，可将不是那么重要的功能进行降级处理，停止服务，这样可以释放出更多的资源供给核心功能的去用。

延迟处理：（削峰）这个模式需要在系统的前端设置一个流量缓冲池，将所有的请求全部缓冲进这个池子，不立即处理。然后后端真正的业务处理程序从这个池子中取出请求依次处理，常见的可以用队列模式来实现。

特权处理：这个模式需要将用户进行分类，通过预设的分类，让系统优先处理需要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理。

1.5 降级

1、超时降级，会有异步线程检测

2、故障降级，直接降级

3、api不稳定，错误率太高降级，会有异步线程检测

调用的时候，比如出现线程池满了，拒绝访问，执行fallback方法执行降级逻辑；

在调用错误率达到50%（默认），熔断器会打开一段时间，实现限流；