微服务容错限流框架Hystrix

69 阅读 0 评论 46 点赞

我是靠谱客的博主幸福花瓣，最近开发中收集的这篇文章主要介绍微服务容错限流框架Hystrix，觉得挺不错的，现在分享给大家，希望可以做个参考。

1、Hystrix是什么?
2、Hystrix能做什么?
3、Hystrix解决什么问题？
4、Hystrix的设计原则是什么？
5、Hystrix如何实现其目标？

在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。 Hystrix是一个库，可通过添加延迟公差和容错逻辑来帮助您控制这些分布式服务之间的交互。 Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性。

Hystrix源自Netflix API团队于2011年开始的弹性工程工作。2012年，Hystrix不断发展和成熟，Netflix内部的许多团队都采用了它。如今，每天在Netflix上通过Hystrix执行数以千亿计的线程隔离和数以千计的信号隔离调用。这大大提高了正常运行时间和弹性。

超时、隔离、限流、熔断、降级，以及监控

Hystrix旨在执行以下操作：

复杂分布式体系结构中的应用程序具有数十种依赖关系，每种依赖关系不可避免地会在某个时刻失败。如果主机应用程序未与这些外部故障隔离开来，则可能会被淘汰。

例如，对于依赖30个服务的应用程序，其中每个服务的正常运行时间为99.99％，您可以期望：

99.99^30 = 99.7％的正常运行时间
10亿个请求中的0.3％= 3,000,000个失败
即使所有依赖项都具有出色的正常运行时间，每月也会有2个小时以上的停机时间，现实通常更糟。

即使您没有对整个系统进行永续性设计，即使所有依赖项都能很好地执行，即使宕机0.01％，对数十种服务中的每一项的总体影响也等于一个月可能会有数小时的宕机。

当一切正常时，请求流如下所示：
在这里插入图片描述
当许多后端系统之一变得潜在时，它可以阻止整个用户请求：

随着高流量，单个后端依赖关系变得潜在，这可能导致所有服务器上的所有资源在几秒钟内变得饱和。

应用程序中可能会导致网络请求的，通过网络或客户端库延伸的每个点都是潜在故障的根源。比故障更糟糕的是，这些应用程序还会导致服务之间的等待时间增加，从而备份队列，线程和其他系统资源，从而导致整个系统出现更多级联故障。

在这里插入图片描述
当通过第三方客户端进行网络访问时，这些问题会更加严重。“第三方”是一个隐藏了实施细节的“黑匣子”，可以随时更改，并且每个客户端库的网络或资源配置都不相同，通常难以监控和更改。

更糟糕的是，传递依赖项会执行潜在的昂贵或易出错的网络调用，而不会被应用程序明确调用。

网络连接失败或降级。服务和服务器出现故障或变慢。新的库或服务部署会更改行为或性能特征。客户端库有错误。

所有这些都代表需要隔离和管理的故障和延迟，以使单个故障依赖项无法关闭整个应用程序或系统。

#####/4、Hystrix的设计原则是什么？
Hystrix的工作原理：

Hystrix通过以下方式做到这一点：

将对外部系统（或“依赖关系”）的所有调用包装在通常在单独线程中执行的HystrixCommand或HystrixObservableCommand对象中（这是命令模式的示例）。
超时呼叫花费的时间超过您定义的阈值。有一个默认值，但是对于大多数依赖项，您可以通过“属性”自定义设置这些超时，以使它们略高于针对每个依赖项测得的99.5％的性能。
为每个依赖项维护一个小的线程池（或信号灯）；如果已满，发往该依赖项的请求将立即被拒绝，而不是排队。
测量成功，失败（客户端抛出的异常），超时和线程拒绝。
如果某个服务的错误百分比超过阈值，则使断路器跳闸，以在一段时间内手动或自动停止所有对特定服务的请求。
当请求失败，被拒绝，超时或短路时执行回退逻辑。
几乎实时监控指标和配置更改。
当您使用Hystrix封装每个基础依赖项时，如上图所示的体系结构将更改为类似于下图。每个依赖项都是相互隔离的，受到延迟时发生饱和的资源的限制，并由后备逻辑覆盖，该逻辑决定了在依赖项中发生任何类型的故障时做出什么响应：

在这里插入图片描述