Hystrix学习笔记

前言

本文主要介绍Hystrix的基本功能，原理。Hystrix协调分布式系统中各个服务高可用的框架，SpringCloud体系重要的一员。Hystrix主要解决了服务雪崩问题、服务监控问题等。

Hystrix功能介绍

资源隔离与限流

作用

• 主要在于预防依赖服务崩溃影响到自己服务资源被耗光，使用隔离的方式限制调用依赖服务所能使用的最大线程资源。如果一个服务崩溃，不控制好资源隔离的话，会引发服务雪崩，众多上游服务集体崩溃。
• 另外在并发量很大的情况下，也可以降低对依赖服务请求的流量，避免依赖服务过度负载。

原理

• Hystrix将对外部服务的调用和一系列处理封装为一个Commond对象，具体分为HystrixCommand（直接调用命令），HystrixObservableCommand（观察者订阅命令），后者可以注册回调事件。两者都可以以异步或同步的方式调用（异步返回Future，后续可以调用get阻塞获取结果）。

• Commond对象对资源隔离进行隔离有两种方式，一种是使用线程池（常用），第二种是使用信号量。两者都是对Commond被调用的线程并发数量进行限制，区别在于信号量只是对command被调用并发许可的一个线程，不能记录超时信息等等。

配置项

• 选择Commond资源隔离的策略，线程池（常用）或信号量
• 指定command名称、组。名称默认为类名（一个command通常对应一个依赖服务的接口调用），group下的所有command默认情况下共用一个线程池或用一个信号量隔离（group一般对应一个依赖服务）。
• 指定command线程池,HystrixThreadPool的key默认为组名称，也可以手动指定使用的HystrixThreadPool。
• 指定线程池核心线程数大小，默认为10。
• 指定线程池队列长度，默认-1 无界队列，设置值之后超过则拒绝请求。
• 指定线程池拒绝阀值，默认5，超过就拒绝请求。
• 信号量隔离下可设置最大并发访问量，默认10。

requestCache-请求缓存

原理

在一个web调用主线程中，为该主线程调用服务的command建立缓存，使得调用依赖服务相同参数的情况下直接从内存中获取结果，由于本人认为其作用不是很大，所以就不多介绍了，主要是在拦截器中初始化HytrixRequestContext（这个缓存数据目测应该是在线程本地变量里面），然后Command中实现getCacheKey方法返回cache的key，当key一样时，直接尝试获取之前调用后返回相同key的结果。

fallback-服务降级

原理

通过Command实现getFallBack方法（HystrixCommand）或resumeWithFallback方法(HystrixObservableCommand),实现降级逻辑，本地返回降级之后的结果。

降级的条件

• 线程池或信号量拒绝
• 调用超时
• 执行报错
• 断路器被开启

降级的通常逻辑

• 取本地缓存中较老的数据
• 返回默认值

注：降级逻辑可以设置参数限制并发线程数量（基于信号量）

circuit breaker-断路器

原理

打开条件

• 调用超时达到一定比例
• 执行报错达到一定比例
• 线程池或信号量拒绝达到一定比例

半开状态

一定时间之后会切换到半开状态，让1个请求通过，看是否能够正常返回

开启状态

如果半开状态允许通过的请求成功了，就关闭断路器

相关可配置项

• 是否打开断路器（默认打开）
• 断路器时间滚动窗中最小的请求数（默认20）
• 多少异常（包括超时、报错、拒绝）比例（默认50%）打开断路器
• 多长时间进入半开状态（默认5000毫秒）
• 是否强制打开断路器
• 是否强制关闭断路器
• 超时时长配置（默认1000毫秒）
• 是否打开超时机制（默认打开）

小结

在实践中，通常用了hystrix，一般的架构体系都是SpringCloud那一套，因为feign组件封装了hystrix可以实现熔断、服务隔离。本文是在学习原生Hystrix所总结的，涉及到的使用和配置方法可能会与当前实践相偏离，但是看官着重hystrix的功能原理就好，具体应用时可以再查阅相关资料。

转载于:https://my.oschina.net/u/4101481/blog/3099890