Hystrix服务容错

1.Hystrix简介

    Hystrix是一个库，可以通过添加等待时间容限和容错逻辑来帮助你控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体稳定性。     

2.雪崩效应

2.1 什么是雪崩效应？

        在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

一个服务不可用，导致一系列服务的不可用

造成雪崩的原因总结：

• 服务提供者不可用（硬件故障，程序 BUG，缓存击穿，用户大量请求等）

• 重试加大流量（用户重试，代码逻辑重试）

• 服务消费者不可用（同步等待造成的资源耗尽

2.2 雪崩效应的解决方案

        雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估做好服务容错。解决方案大概可以分为以下几种：

• 请求缓存：支持将一个请求与返回结果做缓存处理；

• 请求合并：将相同的请求进行合并然后调用批处理接口；

• 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其他服务调用；

• 服务熔断：牺牲局部服务，保全整体系统稳定性的措施；

• 服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值。

（1）请求缓存

        Hystrix 为了降低访问服务的频率，支持将一个请求与返回结果做缓存处理。如果再次请求的 URL 没有变化，那么 Hystrix 不会请求服务，而是直接从缓存中将结果返回。这样可以大大降低访问服务的压力。

  (2) 请求合并

         在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相配合工作，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加，同时，线程池的资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解 Hystrix 的请求合并。

 请求合并的缺点：设置请求合并之后，本来一个请求可能 5ms 就搞定了，但是现在必须再等 10ms 看看还有没有其他的请求一起，这样一个请求的耗时就从 5ms 增加到 15ms 了。

（适用场景：如果我们要发起的命令本身就是一个高延迟的命令，那么这个时候就可以使用请求合并了，因为这个时候时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景，例如准时准点抢票。

（3）服务隔离

   （3.1）线程池隔离

隔离前：

         没有线程池隔离的项目所有接口都运行在一个 ThreadPool 中，当某一个接口压力过大或者出现故障时，会导致资源耗尽从而影响到其他接口的调用而引发服务雪崩效应。

  隔离后：

         通过每次都开启一个单独线程运行。它的隔离是通过线程池，即每个隔离粒度都是线程池，互相不干扰。线程池隔离方式，等于多了一层的保护措施，可以通过 hytrix 直接设置超时，超时后直接返回。

 优点：

• 使用线程池隔离可以安全隔离依赖的服务（例如图中 A、C、D 服务），减少所依赖服务发生故障时的影响面。比如 A 服务发生异常，导致请求大量超时，对应的线程池被打满，这时并不影响 C、D 服务的调用。

• 当失败的服务再次变得可用时，线程池将清理并立即恢复，而不需要一个长时间的恢复。

• 独立的线程池提高了并发性。

缺点：

• 请求在线程池中执行，肯定会带来任务调度、排队和上下文切换带来的 CPU 开销。

• 因为涉及到跨线程，那么就存在 ThreadLocal 数据的传递问题，比如在主线程初始化的 ThreadLocal 变量，在线程池线程中无法获取。

---

  （3.2）信号量隔离       

         每次调用线程，当前请求通过计数信号量进行限制，当信号量大于了最大请求数 maxConcurrentRequests 时，进行限制，调用 fallback 接口快速返回。信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）。

（3.3）线程池隔离与信号隔离的比较

      总结：

        （1）请求并发大，耗时短（计算小，或操作缓存），采用信号量隔离策略，因为这类服务的返回通常会非常的快，不会占用线程太长时间，而且也减少了线程切换的开销，提高了缓存服务的效率。还有就是适合访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问，像这种访问系统内部的代码，不涉及任何的网络请求，做信号量的普通限流就可以了，因为不需要去捕获 timeout 类似的问题，并发量突然太高，稍微耗时一些导致很多线程卡在这里，所以进行一个基本的资源隔离和访问，避免内部复杂的低效率的代码，导致大量的线程被夯住。

        （2）请求并发大，耗时长（计算大，或操作关系型数据库），采用线程隔离策略。这样可以保证大量的线程可用，不会由于服务原因一直处于阻塞或等待状态，快速失败返回。还有就是对依赖服务的网络请求的调用和访问，会涉及 timeout 这种问题的都使用线程池隔离。

（4）服务断融

        服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。

 （5）服务降级

        例如女生旅行，大号的旅行箱是必备物，平常走走近处绰绰有余，但一旦出个远门，再大的箱子都白搭了，怎么办呢？常见的情景就是把物品拿出来分分堆，比了又比，最后一些非必需品的就忍痛放下了，等到下次箱子够用了，再带上用一用。而服务降级，就是这么回事，整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

 触发条件：    

• 方法抛出非 HystrixBadRequestException 异常；

• 方法调用超时；

• 熔断器开启拦截调用；

• 线程池/队列/信号量跑满。