hystrix语义为“豪猪”，具有自我保护的能力。
hystrix的出现即为解决雪崩效应，它通过四个方面的机制来解决这个问题:

• 隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
• 优雅的降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。
• 融断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。
• 缓存：提供了请求缓存、请求合并实现。
• 支持实时监控、报警、控制（修改配置）

mrpc中以插件的形式将其引入，使用也非常简单。

降级

可能大家会混淆“融断”和“降级”两个概念。
在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。
相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，
从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。

大家都见过女生旅行吧，大号的旅行箱是必备物，平常走走近处绰绰有余，但一旦出个远门，
再大的箱子都白搭了，怎么办呢？常见的情景就是把物品拿出来分分堆，比了又比，
最后一些非必需品的就忍痛放下了，等到下次箱子够用了，再带上用一用。
而服务降级，就是这么回事，整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。
二者的目标是一致的，目的都是保证上游服务的稳定性。
但其关注的重点并不一样，融断对下层依赖的服务并不级（或者说孰轻孰重），一旦产生故障就断掉；
而降级需要对下层依赖的业务分级，把产生故障的丢了，换一个轻量级的方案，是一种退而求其次的方法。

根据业务场景的不同，一般采用以下两种模式：
第一种（最常用）如果服务失败，则我们通过fallback进行降级，返回静态值。

第二种采用服务级联的模式，如果第一个服务失败，则调用备用服务，例如失败重试或者访问缓存失败再去取数据库。
服务级联的目的则是尽最大努力保证返回数据的成功性，但如果考虑不充分，则有可能导致级联的服务崩溃（比如，缓存失败了，把全部流量打到数据库，瞬间导致数据库挂掉）。因此级联模式，也要慎用，增加了管理的难度。

开始使用

在RPC客户端加入如下依赖

<dependency>
    <groupId>com.kongzhong.mrpc</groupId>
    <artifactId>mrpc-hystrix</artifactId>
    <version>[最新版本]</version>
</dependency>

配置降级

默认情况下所有的服务都不具备降级特性，服务降级的粒度是方法级别，
需要单独在方法上进行配置。

@Command(fallbackType = "com.kongzhong.mrpc.client.UserServiceFallback")

mrpc 提供一个名为@Command的注解，您可以在接口定义的方法上配置当服务降级后
调用的类和方法，不配置fallbackMethod则调用和接口方法相同，同时该方法的参数列表也必须一致。

客户端处理

在客户端实现一个 UserServiceFallback

@Component
public class UserServiceFallback {
    public String testHystrix(int errorNum) {
        return "默认返回22";
    }
    public String fall(int errorNum) {
        return "这是一个神奇的BUG";
    }
}

服务端

public String testHystrix(int num) {
    if (num != 20) {
        throw new RuntimeException("运行时异常");
    }
    return "ok";
}

至于当服务调用出现异常后会调用UserServiceFallback中的哪个方法看你的API方法是如何定义的。

参考资料：

• hystrix 原理与应用
• Hystrix文档翻译