Hystrix 是什么

Hystrix 的历史

Hystrix 是2011 从Netflix API 团队发展而来。 2012 Hystrix持续发展并且成熟，并且有非常多的团队开始采用Hystrix.现在在Netflix每天有数十万的线程，数百万的独立信号量通过Hystrix执行，这几大增强了服务的弹性和服务时间。

Hystrix 是干嘛的

• 保护系统间的调用延时以及错误，特别是通过第三方的工具的网络调用
• 阻止错误在分布式系统之前的传播
• 快速失败和迅速恢复
• 错误回退和优雅的服务降级
• 提供近乎实时的系统监控，报警和动态操控

Hystrix 解决了什么问题

举个例子, 一个服务依赖30个不同的服务，每个服务的服务成功率为99.99%，这个服务的成功率就可以这样计算:

99.99*99.99。。。。。30 = 99.7 这样算来 1000个请求中就有3个是失败的, 这样一来 每个月基本上会有差不多2个小时的停机时间

这只是一个计算值，现实情况可以比这个更糟糕

尽管我们我们可以将每个服务的成功率再往上提升，比如现在没1万个请求才会失败一个，但是还是任然每个月了数小时的停机，

当其中的某一个服务变得延时较大时，这个服务将成为系统的瓶颈:

当有大量的网络流量依赖于一个后端的服务时，瞬间就会导致整个系统的资源都受到影响.

在应用程序中，每一个通过网络或者使用第三方客户端发送出去的请求都有可能会失败，比失败更糟糕的是，这会增加服务间的调用延时。

上面的这些问题会变得更加的严重，当我们通过第三方客户端发送网络请求，因为第三方客户端对于我们而言是“黑盒”，并且它的实现是随时可能改变的。并且每一个客户端的资源配置都是不同的，这样就非常的难监控和改变。

。。。。。。

网络连接失败或者降级，服务或者服务机器停机或者变慢，新的客户端或者部署的新的服务改变了原有的行为，亦或者客户端有bugs。

上面的所有错误形式都需要被单独隔离出来，这样不至于一个简单的错误导致整个系统的失败。

Hystrix 的设计原则是什么

• 阻止一个单独的依赖耗尽系统的所有线程,比如(tomcat)
• 使用快速失败代替将这个请求排队
• 在任何可能失败的地方提供后退机制来确保用户不会看到错误
• 使用隔离技术(比如:隔板，泳道，环路切断 模式)降低一个依赖的失败对整个系统的影响
• 优化使得系统可以近乎实时的收集，监控，报警
• 优化使得系统可以近乎实时的修改，并且可以近乎实时生效
• 保护系统不仅仅在网络层面，也包括客户端层面的依赖执行的失败

Hystrix 是怎样的实现这些目标

Hystrix 通过如下的方式实现了这些目标:

• 通过使用命令模式包装所有的调用外部系统的请求，这些个请求都单独的运行在不同的线程中，在Hystrix中主要通过 "HystirxCommand","HystixObservableCommand"实现
• 调用超时比我们自定义的超时时间更久，所以我们在使用的过程中最好自定义网络调用的超时时间，在Hystrix中，提供了配置可以修改默认的超时时间，那么超时间到底应该定义为多少？ 就一般经验值而言,设置为服务成功率为99.5%时的平均时间
• 每一个服务都维护着一个小的线程池或者信号量，一旦线程池或者信号量饱和了，那么采取的策略是拒绝请求而不是将请求排队
• 记录成功，失败，超时，线程拒绝数据
• 提供一个回调接口，当一个请求失败，或者被拒绝，超时亦或者因为短路而拒绝
• 监控系统运行数据并且可以近乎实时的修改系统配置
• 一段时间内当短路发生时，拒绝所有的请求，或者当错误率超过了阀值

当你使用Hystrix包装所有的依赖时，系统的整体架构和上面的那张图差不多一致的，每一个依赖之间都是相互隔离的，这样可以为每一服务提供失败回滚逻辑等等。