服务熔断——Hystrix

  1、什么是Hystrix？

    在分布式的环境或者微服务中，不可避免的会出现一些错误，一个服务的失败或许会导致整个项目的失败。而Hystrix是一个库，它可以通过添加容错逻辑来保护或者控制你的分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供后备选项来实现这一目标，所有这些都可以提高系统的整体弹性。

  2、Hystrix出现的目的？

        Hystrix出现的目的包括以下几个方面：

        （1）通过第三方客户端库访问依赖关系，以防止和控制延迟或故障；

        （2）在复杂的分布式系统中，快速的故障并及时的修复，防止级联故障；

        （3）在可能的情况下，后退并优雅的降级；

        （4）实现近实时监控、警报或者控制；

  3、分布式系统的简单模型？

        在一切正常的情况下，分布式系统的请求流如下图所示：（来自Hystrix的官网wiki）

正常情况下、分布式系统请求流

        但是，如果其中的任何一条服务不可用的时候，都有可能会导致整个用户请求被阻塞。

服务异常

        应用程序中通过网络或者可能导致网络请求进入客户端库的每个点都有可能会发生故障。比故障更可怕的是，这些应用程序可能会导致服务之间的延迟增加，从而备份队列、线程或其他系统故障，最后可能导致主线程池被沾满，导致整个服务不可用。这类似于雪崩效应。

服务异常

  4、雪崩效应产生的原因？

        服务提供者不可用，是产生雪崩效应的重要原因之一。还有以下几个原因，会产生此效应：

服务调用者自身流量激增，导致系统负载升高。比如异常流量、用户重试、代码逻辑重复

缓存到期刷新，使得请求都流向数据库

重试机制，比如我们rpc框架的retry次数，每次重试都可能会进一步恶化服务提供者

硬件故障，比如机房断电，电缆被挖了….

  5、Ribbon整合Hystrix

        首先在配置文件中添加响应的依赖：

依赖

        在启动类中加入注解：@EnableHystrix

        在需要做熔断的类上添加一下注解。其中fallbackMethod属性表示：当方法发生错误时，会跳到我们自己定义的findBasicDataByTypeFallBack方法中进行处理。这样的话当服务发生错误时，就会去执行我们自己定义的方法，返回一个结果，不会导致整个服务不可用。

注解