教程:一块儿学习Hystrix--服务（依赖）失败场景的表象

目录

• Hystrix本系列博文
• 依赖失败的表象
• 依赖失败触发回退的表象
• 级联失败的表象
• 服务本身失败而不是依赖失败的表象
• 声明

Hystrix本系列博文

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

     点击查看 Hystrix入门

    点击查看 Hystrix命令执行

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

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

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

    点击查看 Hystrix请求处理

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

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

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

依赖失败的表象

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

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

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

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

    

依赖失败触发回退的表象

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

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

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

级联失败的表象

    下面的屏幕截图表明了一个系统的失败（高延迟状况），这个系统很大程度上依赖于许多其余系统，所以故障也会在它们之间发生。Netflix的API系统必须可以抵御延迟和失败，不单单由于单一的根本缘由，而是全部受到它影响的系统。

     下面的截图显示了6个电路，表明了三个不一样的系统：

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

服务本身失败而不是依赖失败的表象

     若是全部的电路看起来都很糟糕（仪表板都被点亮了），那么颇有可能问题是本身系统，而不是全部的依赖项同时发生。

致使这种问题的两个案例以下：

• 系统过载（高负载，CPU使用率等）。

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

• 内存泄漏最终会致使GC抖动，从而窃取CPU并致使暂停，从而致使电路超时、备份和拒绝            

声明

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