Hystrix

Hystrix熔断机制

为了防止微服务出现雪崩效应，可以在微服务之中设置熔断机制，这样当某一个微服务出现问题之后，可以直接直接通过服务的降级机制进行保护，这样就不会影响到其他的微服务执行，同时也便于开发者进行错误的排查，而这样的熔断机制在SpringCloud中就可以通过Hystrix来实现，该组件是由Netflix公司开源的一款容错框架，具有多种

功能:

1 断路器:当服务访问量过大，并且超过了预先配置的访问阈值时，Hystrix 会直接开启断路器
2 资源隔离:在Hystrix之中采用了舱壁隔离模式对资源进行隔离，使多个资源彼此之间不会产生影响
3 降级回退:在某些服务节点出现故障后依然可以正常的返回处理结果
4 请求结果缓存:Hystrix实现了一个内部缓存机制，可以将请求结果进行缓存，那么对于相同的请求则会直接走缓存而不用请求后端服务。
5 请求合并:可以实现将一段时间内的请求合并，然后只对后端服务发送一次请求。

1、断路器:

当服务访问量过大，并且超过了预先配置的访问阈值时，Hystrix会直接开启断路器，同时会拒绝后续所有的请求，在一段时间之后断路器会进入到半打开状态，此时会允许一部分请求通过并进行调用尝试，如果尝试依然存在问题，则继续保持打开状态,如果尝试没有问题,则会进入关闭状态。

2、资源隔离

在Hystrix之中采用了舱壁隔离模式对资源进行隔离，使多个资源彼此之间不会产生影响，而在Hystrix之中资源隔离形式分为线程池隔离与信号量隔离。
1 线程池隔离（ThreadPool Rejection):
在 Hystrix中会为每一个资源创建一个线程池，这若干个线程池彼此之间相互隔离，即便某一个服务资源出现问题，导致线程池资源耗尽，也不会影响到其它线程池的正常工作，所以该模式适合耗时较长的接口(接口处理逻辑负载）调用场景。同时为了进一步提升处理性能，线程池之中的所有的线程并不参与实际的服务调用，真正的服务调用由转发线程处理，这样就保证容器有足够的线程来处理新的请求。使用线程池隔离模式虽然会有一定的线程调度开销，但是在并发访问量大的情况下可以基于延迟队列实现调度处理（例如:等待超时、异步调用)，带来较好的并发处理性能。

2 信号量隔离（Semaphore Rejection):
采用访问统计计数的形式来进行服务调度，如果当前访问的用户量小于系统规定的最大值则可以进行调度，否则将无法进行调度，此种隔离机制由于只是一个简单的计数器操作，所以没有任何的调度开销，属于轻量化的实现，所以无法进行有效的队列管理。由于用户的请求线程与转发线程为同一个线程，所以该隔离模式适合于接口响应速度快的应用场景。

3、降级回退

为了保证整体业务的稳定性，在某些服务节点出现故障后依然可以正常的返回处理结果，就需要通过降级回退机制进行实现，一般以下几种情况会启用降级回退处理:
1 断路器打开:所有的客户端请求无法发送到服务端，所以直接返回既定的降级回退数据;
2 线程池/信号量资源不足:当前服务调度资源过大已经无法保证正常的服务提供;
3 服务调用超时:服务处理逻辑复杂，或者与该服务有关的其它服务调度时间过长所产生的超时情况;.
4 服务调用异常:目标服务主机停电或者网络故障。

由于实际项目运行中的服务调用的复杂性，所以对于服务降级回退的方式也有多种实现

1 快速失败(Fall Fast):最普通的执行方式，不需要重写任何的降级逻辑，如果出现故障直接抛出异常;.
2 无声失败(Fall Fast):在服务降级时返回一些特定的数据，例如: null、空集合或其它类似响应;.
3 静态值(Static):由开发者预先配置的数据内容，例如:部门增加微服务调用失败时直接返回false;
4 复合数据(Stubbed):由开发者定义的复合对象内容;
5 网络缓存(Cache):如果服务调用失败，可以通过缓存服务中查询旧数据版本;
6 主次策略(Primary + Secondary):将失败回退分为主要故障（网络）与次要故障（业务）两种处理模式;.

4、请求结果缓存:

Hystrix内部提供了一个内置的缓存机制，可以将一些没有太大变化的响应通过缓存进行存储（定期的更新问题了)，以避免重复的服务端请求，提高响应的处理特点

5、请求合并:

当多个用户在某一段时间之内请求的内容相同，那么没有必要重复发出，而是一起处理。

Hystrix基本使用

HystrixDashBoard

Truebine聚合监控