原文地址 : https://github.com/Netflix/Hystrix/wiki
如果存在翻译错误的地方 , 请留言告知 , 我会及时勘误 , 多谢
1. Hystrix 是什么 ?
2. Hystrix 是为什么准备的 ?
3. Hystrix 解决了什么问题 ?
4. Hystrix 的基础设计原则是什么 ?
5. Hystrix 如何实现它的目标 ?
Hystrix 是什么 ?
在分布式环境中 , 无法避免的会出现所依赖的服务失败的情况 ,
而Hytrix 可以通过添加 延迟容错 和 故障容错 来帮助你控制这些分布式服务中的交互 .
Hystrix 通过 隔离 服务之间的访问点 ,阻止它们之间的 级联故障 , 提供 后备选项 , 来提高系统的整体弹性 , 从而实现了这一点 .
Hystrix 的历史
Hystrix 是 Netflix API 团队 , 在 2011 年 ~ 2012 年之间 , 在实现弹性计算工程的时候演化出来的 .
Hystrix 不断的发展和成熟 , Netflix 里的很多团队都采用了它 .
在Netflix , 每天通过Hystrix执行数百亿的线程隔离和数千亿的信号量隔离呼叫 . 这使得 系统正常运行的时间 和 弹性得到了显著的改善 .
下面的这些链接 提供了更多关于Hystrix的内容 以及 它试图解决的挑战 :
“Making Netflix API More Resilient”
“Fault Tolerance in a High Volume, Distributed System”
“Performance and Fault Tolerance for the Netflix API”
“Application Resilience in a Service-oriented Architecture”
“Application Resilience Engineering & Operations at Netflix”
Hystrix 是为什么准备的 ?
Hystrix 是为以下这些情况而设计的 :
- 通过控制延迟和故障来为,需要使用第三方客户端访问(通常通过网络)的依赖,提供保护.
- 在复杂的分布式系统中 , 阻止级联的故障
- 故障快速恢复
- 回退 并且在可能的情况下优雅降级
- 启动接近实时的监控 , 警报 和 操作控制
Hystrix 解决了什么问题 ?
处于复杂分布式架构中的应用程序可能拥有数十个依赖关系 , 在某些时候 , 每个依赖关系都不可避免的会出现故障 . 如果主机应用没有和这些外部的故障隔离 , 则可能会和外部依赖一起出现故障 .
例如 , 某个应用依赖于30个服务应用 , 每个依赖具有99.99%的正常运行时间, 你可以预期 :
99.99 ^ 30 = 99.7％的正常运行时间
10亿个请求中的0.3％= 3,000,000个失败
2小时停机/月，即使所有依赖都有很好的正常运行时间
而现实通常更糟糕 .
如果你不设计整个系统的恢复能力 , 即使所有的依赖表现良好 , 即使 0.01%的停机时间 , 对于每个服务的整体也可能等于每个月的停机时间 .
当一切正常的时候 , 请求流可以像下面这样 :
当其中一个后台系统不可用的时候, 它可以阻塞全部用户的请求
在大流量到来的时候 , 单个后端依赖的不可用 , 可能会导致所有的资源在所有的服务器上饱和 .
应用中 , 跨网络访问或者客户端库中可能导致网络请求的每一个点都是潜在的故障的根源 . 更糟糕的是 , 这些应用也可能导致服务之间的延迟增加 , 阻塞 队列, 线程 , 和其他的系统资源 , 从而引起更多的级联故障.
当通过第三方客户端进行网络访问的时候 , 这些问题会被加剧 , -- 这是一个"黑箱" , 它的实现细节是被隐藏并随时可以更改 , 网络或者资源配置对于每个客户端都是不同的 , 通常难以监控和改变 .
甚至更糟糕的是 , 相关的依赖 在执行 潜在的 , 昂贵的 , 或者是易出错的网络请求时 , 并不是应用显示调用的 .
网络连接失败或降级 . 服务或者服务器 故障 或者变得缓慢时 . 新的库或者服务部署改变了行为或者是性能特征时 . 客户端库存在BUG时 .
所有这些故障和延迟都需要被隔离和管理起来 , 以便单个依赖出现的故障不能影响整个应用或系统 .
Hystrix 的基础设计原则是什么 ?
- 预防任何单个依赖耗光所有容器(比如 tomcat)中的用户线程 .
- 减轻负载 并 快速失败 而不是排队 .
- 在可行的情况下提供回退以保护用户免受故障影响 .
- 使用隔离技术(类似隔板 , 泳道 和断路器模式) 来限制任何一个依赖的影响 .
- 通过近乎于实时的指标 , 监控 和 警报 来优化发现问题的时间 .
- 通过配置来优化恢复时间 , Hystrix大多数属性都允许动态变更 , 从而允许您实时操作修改.
- 保护整个依赖客户端中执行时出现的故障 , 而不仅仅是在网络流量中 .
Hystrix 如何实现它的目标 ?
- 将所有对外部系统(或"依赖关系")的调用 包装在
HystrixCommand或HystrixObservableCommand对象中 (通常在单独的线程中)(这是命令模式的示例) . - 超时调用的时间长于您所定义的法制 , 这里有一个默认值 , 但是的对于大多数依赖 , 您可以通过"属性"定制这些超时 , 以使它们略高于每个依赖99.5%的性能
- 为每个依赖维护一个线程池(或信号量) , 如果它满了那么依赖关系的请求将立刻被拒绝而不是排队 .
- 如果服务出错的百分比超过阀值 , 则断路器可以在一段时间内 , 手动或者自动停止对指定服务的所有请求 .
- 当请求失败时执行回退逻辑 , 包括 请求被拒绝 , 超时 , 或短路 .
- 近实时的指标监控和配置修改 .
当你使用Hystrix包装每一个底层依赖的时候 , 上面描述的体系架构如下图所示 . 每个依赖都是相互隔离的 , 当延迟发生并且资源饱和的时候 , 它可以被回退逻辑覆盖 , 回退逻辑决定了在依赖关系中发生任何类型的故障时将作出什么响应 .
