【Hystrix系列】三、适用的熔断降级场景

前面两篇文章分析了【Hystrix系列】一、配置加载过程分析、以及【Hystrix系列】二、RxJava的调用栈分析，本文讲讲Hystrix适用的场景。

        关于Netflix的Hystrix供分布式系统使用，提供延迟和容错功能，隔离远程系统、访问和第三方程序库的访问点，防止级联失败，保证复杂的分布系统在面临不可避免的失败时，仍能有其弹性。更多的介绍就不再重复，可以看这个（https://github.com/Netflix/Hystrix/wiki）。

       作为API Gateway，通常都会使用Hystrix作为后端服务可用性的隔离手段。一旦发现后端某个服务的质量下降，为了保证服务质量就会自动进行降级。

      作为典型的场景，Hystrix进行了如下描述：

      在一个复杂分布式架构中的宿主应用程序具有数十个依赖关系，每个依赖关系在某些时候不可避免地会失败。 如果宿主应用程序没有与这些外部故障隔离，则可能会出现宿主应用程序请求失败的情况。
       例如，对于依赖30个服务的应用程序，每个服务的正常运行时间为99.99％，您可以预期的是：

• 99.9930 = 99.7％正常运行时间
• 10亿次请求中有0.3％= 3,000,000次失败
• 2小时停机时间/月，即使所有的依赖关系都有很好的正常运行时间。

       现实情况会更加糟糕，即使所有依赖关系表现良好，然而0.01％的停机时间对数十个服务中的每一个服务的总体影响等同于每月停机的潜在时间。

       从上面的描述中可以看到Hystrix倾向于在服务聚合场景中控制后台健康情况。

二、Hystrix做的事情

         Hystrix具体逻辑

• 将通常在单独的线程中执行的HystrixCommand或HystrixObservableCommand对象中的外部系统（或“依赖关系”）的所有调用包装起来（这是命令模式的示例）。
• 超时调用需要比您定义的阈值更长的时间。需要有一个默认值，但是对于大多数依赖关系，您可以通过“属性”定制这些超时，以便它们比每个依赖关系的99.5百分位数性能略高。
• 为每个依赖关系维护一个小的线程池（或信号量），如果它变满了，那么依赖关系的请求将立即被拒绝，而不是排队等待。
• 对成功，失败（由客户端抛出的异常），超时和线程拒绝进行度量。
• 如果服务的错误百分比通过阈值，手动或自动停止让断路器可以在一段时间内停止对特定服务的所有请求。
• 当请求失败时，执行回退逻辑，拒绝，超时或短路。
• 准实时监控指标和配置变化。

三现实场景

   3.1依赖之间的强弱关系

        现实场景是什么样的呢？如果你要做个产品详情页面，里面有商品的介绍、图片、价格、库存、还有评论等等，这些内容都是相互独立的，在加载这个页面时就可以用Hystrix进行控制。

       如果你要查询后台10几家供应商（比如酒店供应商），通过一个页面展示给用户，可以使用Hystrix进行控制。

       如果你要做的事情是，先查询航班的舱位信息，然后是查询每个舱位等级对应的价格，然后把两者的数据拼在一起形成一个展示页面，就不能用Hystrix了，因为他们两者之间是不可分割的，缺少其一，用户都用不了。

   3.2超时逻辑设定

       按照Hystrix的设计，Fail Fast，超时是确保系统正常的关键指标，前提是你的服务是稳定的，非业务性的。如果是电影票的售卖系统，一次预订三个人和一次预订20人的出票时间肯定是不同的，这种情况下，时间的定义是业务强相关的，Hystrix控制起来就不行了。

   3.3交易类的操作

       还是上一个电影票的例子，一个请求到后台了，正在进行一个慢操作，然后Hystrix定义了超时，强行进行后处理，那么用户拿到的就是出票失败的报文，但是后台可能已经出票成功了，和实际相背离。

四、总结

       总结一下：如果是多个弱依赖的孤立信息的聚合，使用Hystrix比较合适。如果是强依赖的上下文信息，就不适合适合Hystrix。如果是业务交易类的，不要使用Hystrix。因此，架构设计和选型必须要依托于业务模式，否则就是空谈。

       落到API上来，如果你的API是聚合查询类型的，使用Hystrix比较合适，如果是串行的、业务操作相关的、交易类的在使用Hystrix的时候就要慎重。