云时代架构阅读笔记十六——Hystrix理解

背景

分布式系统环境下，服务间相似依赖很是常见，一个业务调用一般依赖多个基础服务。以下图，对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能致使整个商品服务资源耗尽，没法继续对外提供服务。而且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。

雪崩效应应对策略

针对形成雪崩效应的不一样场景，可使用不一样的应对策略，没有一种通用全部场景的策略，参考以下：

• 硬件故障：多机房容灾、异地多活等。
• 流量激增：服务自动扩容、流量控制（限流、关闭重试）等。
• 缓存穿透：缓存预加载、缓存异步加载等。
• 程序BUG：修改程序bug、及时释放资源等。
• 同步等待：资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离一般指不一样服务调用采用不一样的线程池；不可用服务调用快速失败通常经过熔断器模式结合超时机制实现。

综上所述，若是一个应用不能对来自依赖的故障进行隔离，那该应用自己就处在被拖垮的风险中。 所以，为了构建稳定、可靠的分布式系统，咱们的服务应当具备自我保护能力，当依赖服务不可用时，当前服务启动自我保护功能，从而避免发生雪崩效应。本文将重点介绍使用Hystrix解决同步等待的雪崩问题。

初探Hystrix

Hystrix [hɪst'rɪks]，中文含义是豪猪，因其背上长满棘刺，从而拥有了自我保护的能力。本文所说的Hystrix是Netflix开源的一款容错框架，一样具备自我保护能力。为了实现容错和自我保护，下面咱们看看Hystrix如何设计和实现的。

Hystrix设计目标：

• 对来自依赖的延迟和故障进行防御和控制——这些依赖一般都是经过网络访问的
• 阻止故障的连锁反应
• 快速失败并迅速恢复
• 回退并优雅降级
• 提供近实时的监控与告警

Hystrix遵循的设计原则：

• 防止任何单独的依赖耗尽资源（线程）
• 过载当即切断并快速失败，防止排队
• 尽量提供回退以保护用户免受故障
• 使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖的影响
• 经过近实时的指标，监控和告警，确保故障被及时发现
• 经过动态修改配置属性，确保故障及时恢复
• 防止整个依赖客户端执行失败，而不单单是网络通讯

Hystrix如何实现这些设计目标？

• 使用命令模式将全部对外部服务（或依赖关系）的调用包装在HystrixCommand或HystrixObservableCommand对象中，并将该对象放在单独的线程中执行；
• 每一个依赖都维护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让请求排队）。
• 记录请求成功，失败，超时和线程拒绝。
• 服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内中止对该服务的全部请求。
• 请求失败，被拒绝，超时或熔断时执行降级逻辑。
• 近实时地监控指标和配置的修改。