Hystrix介绍
在分布式系统中往往存在着大量的服务依赖关系，其中不可避免的会出现部分服务因为发生故障而无法正常提供服务。这时候调用方如果没有对被依赖服务的故障进行有效的隔离，那么可能将当前服务所在容器的资源消耗殆尽，进而引发上一级的服务出现问题，最后有可能导致整个系统发生雪崩效应。为了应对这种情况，我们需要对依赖服务进行降级处理，同时对被依赖服务故障进行隔离。
Hystrix是Netflix开源的服务故障隔离、恢复、监控和报警的组件。Hystrix通过添加对被依赖服务延迟和故障处理逻辑控制服务间的交互，进而提高整个系统的稳定性。
Hystrix的作用
在复杂的分布式系统中往往有大量的服务依赖，在这众多的服务中不可避免得会发生部分服务出现故障的问题。这时候如果主服务没有对被依赖的服务故障进行隔离，那么可能会因为被依赖服务出现的故障拖垮主服务自身。
系统中所有服务都运行良好时，整个依赖关系可以使用下图进行描述：
系统中只要出现一个服务访问延迟，都可能阻塞住整个用户访问请求。
在一个高负载的系统中，一个服务访问延迟可以在短时间内将整个系统的资源消耗殆尽。在程序中无论是直接的网络访问，还是调用第三方的库都是潜在的故障发生点。这些潜在点的故障甚至调用延迟都可能使系统中的队列被塞满消息，容器的线程被大量消耗，进而影响到系统中其他服务的稳定。
总的来说，hystrix提供了以下这些功能帮组我们应对这种情况：
- 包裹请求：使用HystrixCommand（或者HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
- 跳闸机制：当某服务的错误率超过一定阀值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。
- 资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判断
- 监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
- 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员自行提供，例如返回一个缺省值。
- 自我修复：断路器打开一段时间后，会自动进入“半开”状态。
Hystrix的设计理念
设计理念的先进与否直接决定了开源组件的生命周期长短。在了解了hystrix的众多优秀功能后，我们有必要深入了解一下hystrix背后的设计理念。正是这些优秀的设计理念奠定了hystrix在服务熔断开源解决方案中的霸主地位。
hystrix设计理念概要：
- 控制单一依赖对容器线程资源的消耗
- 消峰和快速失败返回而不是进行排队操作
- 在故障发生时提供默认值的返回
- 使用故障（延迟）隔离技术手段防止对其他服务产生重大影响
- 通过实时的统计、监控和报警优化故障恢复
Hystrix的基本实现
总体看来整个hystrix通过以下这些具体的实现细节完成服务故障、服务延迟的隔离、实时搜集和统计。
- 使用HystrixCommand或则HystrixObservableCommand将所有对被依赖服务的调用包装在独立的线程中执行
- 在被依赖服务调用耗时超过配置的超时时长时直接进行超时处理
- 为每个依赖调用维护一个线程池（信号量），在队列满时直接丢弃调用
- 维护依赖调用成功、失败、超时和丢弃的统计信息
- 当被依赖服务调用出错比率超过配置的值时触发熔断器，在配置的时间段内中断对被依赖服务的调用
- 在依赖调用失败、超时、被丢弃或则启动熔断器时提供恢复逻辑
- 实时监控配置和统计数据的变化
