Hystrix本系列博文

以下为博主写Hystrix系列的文章列表如下:

点击查看 Hystrix入门

点击查看 Hystrix命令执行

点击查看 Hystrix处理异常机制(降级方法)

点击查看 Hystrix命令名称、分组、线程池

点击查看 Hystrix命令名称、Hystrix请求处理

点击查看 Hystrix请求处理

点击查看 Hystrix常用场景--失败

点击查看 Hystrix常用场景--降级(回退)

点击查看 Hystrix断路器配置及使用场景

依赖失败的表象

在分布式系统中，最典型的失败类型是单个依赖失败或休眠，而其他所有的都保持健康。在这些情况下，度量和指示板非常明显地显示正在发生的事情：

扫描二维码关注公众号，回复： 1076965 查看本文章

上面的截图显示了一个带有20%错误率的单电路：高到足以产生影响，但还不足以启动断路器。其他三个电路不受影响。

在这个特定的例子中，是实际的错误，而不是延迟，这导致了问题——就像红色数字而不是橙色显示的那样。

在同一事件中，捕捉到了以下图表，以下图标显示这条线路的历史趋势，以及在故障和降级中是如何急剧上升的。

这个图表是另一个单电路故障的屏幕截图，注意有99.5%的延迟非常高。这是底层工作线程要完成的时间，这将使线程池饱和，并导致调用线程超时。

在集群中，除了一台机器之外，所有的机器都有断路器被熔断，这就导致了大多数流量被短路（蓝色），而在一台仍然尝试大多数请求的机器上被超时了（橙色）。

注意，其他的电路是健康的，左边的线图显示的是返回时长500s没有增加，因为这个电路正在返回一个回退操作，这样用户就会收到一个降级但仍然有用的体验。

下面的屏幕截图代表了一个系统的失败（高延迟情况），这个系统很大程度上依赖于许多其他系统，因此故障也会在它们之间发生。Netflix的API系统必须能够抵御延迟和失败，不仅仅因为单一的根本原因，而是所有受到它影响的系统。

下面的截图显示了6个电路，代表了三个不同的系统：

在这一事件发生时，Hystrix仍然主要是一个“netflix-api”的东西。随着Hystrix在越来越多的团队中运转，这进一步限制了级联失败的影响，如下图所示：

如果所有的电路看起来都很糟糕（仪表板都被点亮了），那么很有可能问题是自己系统，而不是所有的依赖项同时发生。

导致这种问题的两个案例如下：

这可能发生的一个例子是，如果自动伸缩策略失败了，或者在流量激增的情况下无法快速伸缩，机器接收的流量超出了它们的处理能力。

转帖请注明原贴地址： https://my.oschina.net/u/2342969/blog/1820306