教程:一块儿学习Hystrix--Hystrix初识

目录

•  Hystrix是什么
• Hystrix用来作什么
• Hystrix解决什么问题
• Hystrix设计原则
• Hystrix如何实现目标

Hystrix是什么

    在分布式环境下，不免出现许多服务之间调用失败的场景， Hystrix是一个经过添加延迟容忍和容错逻辑帮助您控制这些分布式服务之间交互的库。 Hystrix经过隔离服务之间的访问点来实现应用之间连锁故障（因下游服务失败，致使上游服务不可用），出现故障提供备选方案来提升应用总体的可用性。

    举例：抢购活动中，因为库存服务超时或者崩掉，能够经过提示抢购失败，请稍后重试等预防抢购应用不可用

Hystrix用来作什么

    Hystrix能够作一些事情：

1. 经过第三方客户端库，为控制延迟和依赖之间调用失败提供保护。
2. 在复杂的分布式系统中阻止连锁故障
3. 快速故障恢复
4. 在可能的状况下，作到服务隔离和优雅降级
5. 尽量的实时监控、报警、运维控制

Hystrix解决什么问题

    复杂的分布式应用有许多依赖调用，在某一时刻它们之间必然会出现失败，这就是致使应用总体故障的风险。

     例如，对于一个依赖于30个服务的应用程序，每一个服务的正常运行时间为99.99%，下面是您能够预期的结果。

     99.99 的30次方=  99.7% （意味着有0.3%的失败）

     10亿*0.3% = 300万（10亿次请求会有300万次请求失败）

      即便每月在很好的正常运行的时间，也会有2个小时的停机。一般状况会被这个更糟糕。

当全部请求都很正常的状况下，请求流就会像下图同样：

当不少后端系统有一个不稳定时，就会阻塞整个请求，以下图：

    

在大量请求下，一个后端不理想的依赖都会成为阻塞整个应用请求的潜在风险

应用中任何一个经过网络或者客户端发出的请求都有可能成为网络请求失败的潜在风险，比请求失败更糟糕的是，应用调用依赖之间的延迟增长，更甚应用中的队列、线程池、其余系统资源形成的连锁故障

    当经过第三方客户端进行网络访问，就是一个不清楚实现细节以及随时可能发生改变的黑盒执行，对于每一个客户端，网络和资源配置都是不同的，因此很难监控和更改。

    更糟糕的是，依赖调用之间，在不被应用显示调用的状况下，执行昂贵和容易出错的网络调用

    网络链接失败或者降级、服务与服务之间调用失败或者延迟，新库或服务部署改变方式或者性能特性

全部这些失败和延迟的状况都须要被隔离或者管理，这样就不会由于单个依赖的失败摧毁整个应用和系统。

Hystrix设计原则

1.  防止单个应用耗尽服务器（好比 tomcat）全部可用线程
2. 丢弃重负载、快速失败代替排队
3. 为任何状况失败提供保护
4. 使用隔离技术(如隔板、泳道和断路器模式)来限制任何一个依赖的影响
5. 经过接近实时的度量、监视和警报来优化快速发现故障
6. Hystrix在大部分方面依靠低延迟配置和动态配置优化恢复时间， 容许使用快速返回结果进行实时操做调整
7. 保护整个依赖客户端执行中的失败，不只仅是 网络流量中

Hystrix如何实现目标

• 在HystrixCommand或HystrixObservableCommand对象中封装全部对外部系统(或“依赖项”)的调用，该对象一般在单独的线程中执行(这是命令模式的示例)
• Hystrix有一个默认值，若是调用时长超过这个默认值，认定为超时调用，大部分依赖能够经过配置自定义这个值，所以他们略高于依赖项的99.5%的性能
• 为每一个依赖维护一个小的线程池(或信号量);若是它已满，将当即拒绝为该依赖指定的请求，而不是排队。
• 衡量成功、失败(客户抛出的异常)、超时和线程拒绝
• 触发断路器，在一段时间内中止全部对某个服务的请求，若是服务的错误百分比超过阈值，则手动或自动中止
• 当一个请求失败、被拒绝、超时或短路时，执行备选逻辑
• 近实时的监控度量和配置的变化

    当您使用Hystrix来包装每一个基础依赖项时，图中所示的架构会发生变化，以下图所示。每一个依赖项都是相互隔离的，当延迟发生时，它可能会被限制在资源中，而且在熔断器中覆盖，当任何类型的故障发生在依赖项中时，它决定了要作出什么响应