码迷,mamicode.com
首页 > 编程语言 > 详细

[Java复习] 分布式高可用-Hystrix

时间:2019-12-20 11:58:05      阅读:76      评论:0      收藏:0      [点我收藏+]

标签:访问量   笔记   需要   bean   cut   hci   工作原理   故障恢复   boot   

什么是Hystrix?

Hystrix 可以让我们在分布式系统中对服务间的调用进行控制,加入一些调用延迟或者依赖故障容错机制

Hystrix 的设计原则

  • 对依赖服务调用时出现的调用延迟和调用失败进行控制容错保护
  • 在复杂的分布式系统中,阻止某一个依赖服务的故障在整个系统中蔓延。比如某一个服务故障了,导致其它服务也跟着故障。
  • 提供 fail-fast(快速失败)和快速恢复的支持。
  • 提供 fallback 优雅降级的支持。
  • 支持近实时的监控、报警以及运维操作。

Hystrix 更加细节的设计原则

  • 阻止任何一个依赖服务耗尽所有的资源,比如 tomcat 中的所有线程资源。
  • 避免请求排队和积压,采用限流和 fail fast 来控制故障。
  • 提供 fallback 降级机制来应对故障。
  • 使用资源隔离技术,比如 bulkhead(舱壁隔离技术)、swim lane(泳道技术)、circuit breaker(断路技术)来限制任何一个依赖服务的故障的影响。
  • 通过近实时的统计/监控/报警功能,来提高故障发现的速度。
  • 通过近实时的属性和配置热修改功能,来提高故障处理和恢复的速度。
  • 保护依赖服务调用的所有故障情况,而不仅仅只是网络故障情况。

资源隔离 

  要把对某一个依赖服务的所有调用请求,全部隔离在同一份资源池内,不会去用其它资源了,这就叫资源隔离

  哪怕对这个依赖服务,比如说商品服务,现在同时发起的调用量已经到了 1000,但是线程池内就 10 个线程,最多就只会用这 10 个线程去执行。

  不会对商品服务的请求,因为接口调用延时,将 tomcat 内部所有的线程资源全部耗尽。

 

  Hystrix进行资源隔离,其实是提供一个抽象,叫Command。

  把对某一个依赖服务的所有调用请求,全部隔离在同一份资源池内,对这个依赖服务的所有调用请求,全部走这个资源池内的资源,不会去用其他的资源。

  Hystrix最基本的资源隔离技术,就是线程池隔离技术

  • 利用 HystrixCommand 获取单条数据
  • 利用 HystrixObservableCommand 批量获取数据

       技术图片

 

 

   

  从 Nginx 开始,缓存都失效了,那么 Nginx 通过缓存服务去调用商品服务。缓存服务默认的线程大小是 10 个,最多就只有 10 个线程去调用商品服务的接口。

  即使商品服务接口故障了,最多就只有 10 个线程会 hang 死在调用商品服务接口的路上,缓存服务的 tomcat 内其它的线程还是可以用来调用其它的服务。

  Hystrix 实现资源隔离,主要有两种技术:

  • 线程池
  • 信号量

   默认情况下,Hystrix 使用线程池模式。

 

线程池机制:

  HystrixCommand主要用于仅仅返回一个结果的调用

  HystrixObservableCommand主要用于可能会返回多条结果的调用

  HystrixCommand command = new HystrixCommand(arg1, arg2);
  HystrixObservableCommand command = new HystrixObservableCommand(arg1, arg2);

  调用command执行方法:

    执行command要从4个方法选一个:execute(), queue(), observe(), toObservable()

    execute(), queue() 仅对HystrixCommand适用

    execute():同步调用,调用后block,直到依赖服务返回单条结果或异常

    queue():异步调用,返回一个Future,后面可以通过future获取结果

    observe():订阅一个Observable对象,Observable代表是依赖服务的返回结果,获取一个代表结果的Observable对象的拷贝对象。

                       是立即执行construct方法,拿到多行结果。

    toObservable():返回一个Observab对象,没有执行construct方法,延迟调用。如果订阅这个对象subscribe方法时,才会执行command获取返回结果。

 

  信号量机制:

    信号量的资源隔离只是起到一个开关的作用。

    比如,服务 A 的信号量大小为 10,那么就是说它同时只允许有 10 个 tomcat 线程来访问服务 A,其它的请求都会被拒绝,从而达到资源隔离和限流保护的作用。

 线程池与信号量区别

    线程池隔离技术,是用 Hystrix 自己的线程去执行调用;而信号量隔离技术,是直接让 tomcat 线程去调用依赖服务。

    信号量隔离,只是一道关卡,信号量有多少,就允许多少个 tomcat 线程通过它,然后去执行。

      技术图片

 

   适用场景:

      线程池技术,适合绝大多数场景,比如说我们对依赖服务的网络请求的调用和访问、需要对调用的 timeout 进行控制(捕捉 timeout 超时异常)。

      信号量技术,适合说你的访问不是对外部依赖的访问,而是对内部的一些比较复杂的业务逻辑的访问,并且系统内部的代码,其实不涉及任何的网络请求,那么只要做信号量的普通限流就可以了,因为不需要去捕获 timeout 类似的问题。

    技术图片

 

 

Hystrix执行流程:

1. Hystrix请求缓存(request cache)

    如果command开启了请求缓存,而且这个调用结果在缓存中存在,就直接从缓存返回结果

2. 短路器

 检测command对应的依赖服务是否打开短路器,如果打开,hystrix不执行command,执行fallback降级机制

3. 检测线程池/队列/semaphore是否满

    如果以上已满,不会执行command,直接执行fallback降级机制

4. 执行command

     如果基于线程池,有一个timeout机制。

     即HystrixCommand.run()或HystrixObservableCommand.construct()的执行,超过了timeout时长的话,那么command所在线程会抛出一个TimeoutException

timeout也会执行fallback降级机制,不会管run()或construct()返回值。

注意点:不可能终止Hystrix管理线程池中一个调用依赖服务timeout的线程,只能给外部抛出一个TimeoutException,由主线程来捕获再降级处理。

4种调用fallback的降级机制的时机:

 1. run()或construct()抛异常 2. 短路器打开 3. 线程池/队列/信号量满了 4. command执行超时

 

Hystrix的8大执行流程

1. 构建一个HystrixCommand或HystrixObservableCommand

   HystrixCommand主要用于仅仅返回一个结果的调用

   HystrixObservableCommand主要用于可能会返回多条结果的调用

 

2. 调用Command的执行方法

  执行Command发起一次对依赖服务的调用

  执行command要从4个方法选一个:execute(), queue(), observe(), toObservable()

  execute(), queue() 仅对HystrixCommand适用

  execute():同步调用,调用后block,直到依赖服务返回单条结果或异常

  queue():异步调用,返回一个Future,后面可以通过future获取结果

  observe():订阅一个Observable对象,Observable代表是依赖服务的返回结果,获取一个代表结果的Observable对象的拷贝对象。

                    是立即执行construct方法,拿到多行结果。

  toObservable():返回一个Observab对象,没有执行construct方法,延迟调用。如果订阅这个对象subscribe方法时,才会执行command获取返回结果。

 

3. 检查是否开启请求缓存

    如果开启request cache, 而这个调用结果在缓存中存在,那么直接从缓存中返回

 

4. 检查是否开启短路器

    如果短路器打开,那么hystrix就不会执行command,直接执行fallback降级机制

 

5. 检测线程池/队列/semaphore是否已满

   如果已满,不会执行command,而直接走fallback降级机制

 

6. 执行command

  调用HystrixObservableCommand.construct()或HystrixCommand.run()来实际执行这个command。

  HystrixCommand.run()返回一个单条结果,或者抛出一个异常

  HystrixObservableCommand.construct()返回一个Observable对象,可以获取多条结果

  如果command执行超时,那么改线程会抛出TimeoutException,会执行fallback降级机制,不会管run()或construct()的返回值。

 

7.  短路健康检查

  Hystrix会将每一个依赖服务的调用成功,失败,拒绝,超时等事件,都会发送给circuit breaker断路器。

  短路器就会对调用成功/失败/拒绝/超时等事件的次数进行统计

 

8. 调用fallback降级机制

  4种情况下:run()或construct()抛出一个异常,短路器打开,线程池/队列/信息量满,Command超时,Hystrix会调用fallback降级机制。

  降级机制设置一些默认返回值。

    技术图片

 

  

Hystrix核心技术 之 请求缓存

   检测是否开启请求缓存(request cache),是否由请求缓存,如果有,直接取缓存返回结果

    请求缓存:有一个概念,请求上下文,每个web应用中, Hystrix在一个filter中,对每个请求增加一个请求上下文。

                      Tomcat中每次请求,就是一个请求上下文。一个请求上下文中会执行N多代码,调用N多个依赖服务。

     在一个请求上下文中,如果有多个command(假设参数一样,调用结构一样,返回结果也就一样),

     可以让第一次的command执行返回的结果,缓存在内存中,然后这个请求上下文中,后续对这个command的执行都从内存中取缓存结果。

    好处:不用在一次请求上下文中反复多次执行一样的 command,避免重复执行网络请求,提升整个请求的性能。

    技术图片

 

 

  具体使用:

    1. 实现 Hystrix 请求上下文过滤器并注册

        1.1. 定义 HystrixRequestContextFilter 类,实现 Filter 接口

public class HystrixRequestContextFilter implements Filter{
    ...
}

        1.2. 然后将该 filter 对象注册到 SpringBoot Application 中

@Bean
    public FilterRegistrationBean filterRegistrationBean() {
        FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean(new HystrixRequestContextFilter());
        filterRegistrationBean.addUrlPatterns("/*");
        return filterRegistrationBean;
    }

     2. command 重写 getCacheKey() 方法

      

public class GetProductInfoCommand extends HystrixCommand<ProductInfo> {

private static final HystrixCommandKey KEY = HystrixCommandKey.Factory.asKey("GetProductInfoCommand");
...

    /**
     * 每次请求的结果,都会放在Hystrix绑定的请求上下文上
     *
     * @return cacheKey 缓存key
     */
    @Override
    public String getCacheKey() {
        return "product_info_" + productId;
    }

    /**
     * 将某个商品id的缓存清空
     *
     * @param productId 商品id
     */
    public static void flushCache(Long productId) {
        HystrixRequestCache.getInstance(KEY,
                HystrixConcurrencyStrategyDefault.getInstance()).clear("product_info_" + productId);
    }
}
}

 

基于本地缓存的fallback降级

Hystrix 出现以下四种情况,都会去调用 fallback 降级机制:

  • 断路器处于打开的状态。
  • 资源池已满(线程池+队列 / 信号量)。
  • Hystrix 调用各种接口,或者访问外部依赖,比如 MySQL、Redis、Zookeeper、Kafka 等等,出现了任何异常的情况。
  • 访问外部依赖的时候,访问时间过长,报了 TimeoutException 异常。

  两种典型降级机制:

  1. 纯内存数据

        内存中维护一个 ehcache,作为一个纯内存的基于 LRU 自动清理的缓存,让数据放在缓存内,fallback从ehcache中获取数据

  2. 默认值

    fallback直接返回一个默认值

    在 HystrixCommand,降级逻辑的书写,是通过实现 getFallback() 接口;而在 HystrixObservableCommand 中,则是实现 resumeWithFallback() 方法。

 

Hystrix 断路器执行原理

  1. RequestVolumeThreshold  请求数

HystrixCommandProperties.Setter()
    .withCircuitBreakerRequestVolumeThreshold(int)             

    表示在滑动窗口中,至少有多少个请求,才可能触发断路

    Hystrix 经过断路器的流量超过了一定的阈值,才有可能触发断路。

  2.  ErrorThresholdPercentage 异常比例

HystrixCommandProperties.Setter()
    .withCircuitBreakerErrorThresholdPercentage(int)

     表示异常比例达到多少,才会触发断路,默认值是 50(%)。

     如果断路器统计到的异常调用的占比超过了一定的阈值,比如说在 10s 内,经过断路器的流量达到了 30 个,同时其中异常访问的数量也达到了一定的比例,

     比如 60% 的请求都是异常(报错 / 超时 / reject),就会开启断路。

   3. SleepWindowInMilliseconds 断路休息时间

HystrixCommandProperties.Setter()
.withCircuitBreakerSleepWindowInMilliseconds(int)

    断路开启,也就是由 close 转换到 open 状态(close -> open)。

    那么之后在 SleepWindowInMilliseconds 时间内,所有经过该断路器的请求全部都会被断路,不调用后端服务,直接走 fallback 降级机制。

    而在该参数时间过后,断路器会变为 half-open 半开闭状态,尝试让一条请求经过断路器,看能不能正常调用。

    如果调用成功了,那么就自动恢复,断路器转为 close 状态。 

   4. Enabled 断路器开关

HystrixCommandProperties.Setter()
    .withCircuitBreakerEnabled(boolean)

    控制是否允许断路器工作,包括跟踪依赖服务调用的健康状况,以及对异常情况过多时是否允许触发断路。默认值是 true。

    5. ForceOpen 手动断路开关:开

HystrixCommandProperties.Setter()
    .withCircuitBreakerForceOpen(boolean)

      如果设置为 true 的话,直接强迫打开断路器,相当于是手动断路了,手动降级,默认值是 false。

  6. ForceClosed 手动断路开关:关

HystrixCommandProperties.Setter()
    .withCircuitBreakerForceClosed(boolean)

    如果设置为 true,直接强迫关闭断路器,相当于手动停止断路了,手动升级,默认值是 false。

 

Hystrix线程池隔离与接口限流

技术图片

 

 

  Hystrix 通过判断线程池或者信号量是否已满,超出容量的请求,直接 Reject 走降级,从而达到限流的作用。

   限流是限制对后端的服务的访问量,比如说你对 MySQL、Redis、Zookeeper 以及其它各种后端中间件的资源的访问的限制,

    其实是为了避免过大的流量直接打死后端的服务。

 

线程隔离技术:

  Hystrix 对每个外部依赖用一个单独的线程池,这样的话,如果对那个外部依赖调用延迟很严重,最多就是耗尽那个依赖自己的线程池而已,不会影响其他的依赖调用。

  

线程池机制的优点:

  1. 隔离服务。任何一个依赖服务被隔离在线程池内,即使自己线程池资源满了,也不会影响其他服务调用。

  2. 方便引入新的依赖服务。即使新的依赖服务有问题,也不影响其他服务调用。

  3. 故障恢复。当一个有故障的服务变好后,可以通过清空线程池,快速恢复该服务调用。

  4. 健康报告。线程池的健康状态随时报告,比如成功、失败、拒绝、超时的次数统计,然后接近实时的热修改调用配置,不用停机。

  5. 基于线程池的异步本质,在同步调用之上,构建一层异步调用层。

线程池机制的缺点:

  1. 增加CPU开销。

  2. 每个command的执行依托独立线程,会进行排队,调度,上下文切换。

  Hystrix官方统计过额外开销,相比于可用性和稳定性的提升,是可以接受的。

  

  Hystrix semaphore 技术可以用来限流和削峰,但是不能用来对调研延迟的服务进行 timeout 和隔离。

 

基于 timeout 机制为服务接口调用超时提供安全保护

  如果你不对各种依赖服务接口的调用做超时控制,来给你的服务提供安全保护措施,那么很可能你的服务就被各种垃圾的依赖服务的性能给拖死了。

 

Hystrix核心总结:

1. Hystrix内部工作原理,8大执行步骤和流程

2. 资源隔离:多个依赖服务,做资源隔离,避免任何一个依赖服务故障导致服务资源耗尽而崩溃,高可用。

3. 请求缓存:对同一个request内多个相同command,使用request cache,提供性能。

4. 熔断:基于断路器,采集异常情况,如报错,超时,拒绝,短路,一段时间不能访问,直接降级。

5. 降级:服务提供的容错机制,fallback逻辑。

6. 限流:通过线程池,或信号量,限制对某个后端服务或资源的访问量,直接降级。

7.超时:避免因某个依赖服务性能太差,导致大量线程卡住在这个依赖服务。

 

高级知识:

1. 请求合并技术

2. fail-fast和fail- silent容错技术

3. static fallback和stubbed fallback高价降级模式

4. 嵌套command实现的发生网络请求和降级模式

5. 基于façade command的多级降级模式

6. request cache的手动清理

7. 生产环境中的线程池大小以及timeout配置优化经验

8. 线程池的自动化动态扩容与缩容技术

9. hystrix的metric高阶配置

10. 基于hystrix dashboard的可视化分布式系统监控

11. 生产环境中hystrix的工厂维护经验

 

参考资料:

  《互联网Java进阶面试训练营》的笔记 -- 中华石杉

[Java复习] 分布式高可用-Hystrix

标签:访问量   笔记   需要   bean   cut   hci   工作原理   故障恢复   boot   

原文地址:https://www.cnblogs.com/fyql/p/12072161.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!