dubbo降级 容错

dubbo降级

mock类型

dubbo自身是支持mock服务的，在reference标签里，有一个参数mock，该参数有四个值，false,default,true,或者Mock类的类名。
分别代表如下含义:
false，不调用mock服务。
true，当服务调用失败时，使用mock服务。
default，当服务调用失败时，使用mock服务。
force，强制使用Mock服务(不管服务能否调用成功)。(使用xml配置不生效,使用ReferenceConfigAPI可以生效)

使用方法:
将mock参数启用，在dubbo:reference中添加参数项mock=true

实现方式

一、直接返回一个固定的字符串

调用方xml配置： 增加 mock=“true” ：

<dubbo:reference id="userService" interface="com.demo.dubbo.api.UserService" timeout="10" check="false"
                     mock="true"> </dubbo:reference>

提供方xml配置 设置mock固定值：

<dubbo:service interface="com.demo.dubbo.api.UserService" ref="userService" timeout="10" version="1.0.0" mock="return 12356" 

提供方xml配置 也可设置返回null

<dubbo:service interface="com.demo.dubbo.api.UserService" ref="userService" timeout="10" version="1.0.0" mock="return 12356" 

二、根据自定义mock业务处理类进行返回 mock值设置为boolean 类型
具体配置：
在调用方配置xml 增加 mock=true：

<dubbo:reference id="userService" interface="com.demo.dubbo.api.UserService" timeout="10" check="false"
                     mock="true"> </dubbo:reference>

提供方xml配置 设置mock处理类

<dubbo:service interface="com.demo.dubbo.api.UserService" ref="userService" timeout="10" version="1.0.0" mock="com.demo.dubbo.api.UserServiceMock" />

配置了mock参数之后，假设在调用服务的时候，远程服务没有启动，或者各种网络异常了，那远程服务会去寻找自定义的mock业务处理类进行业务处理。

因此还需配置一个自定义mock业务处理类
在接口服务xxxxService的目录下创建相应的mock业务处理类，同时实现业务接口xxxxService()，接口名要注意命名规范：接口名+Mock后缀，mock实现需要保证有无参的构造方法。

public class UserServiceMock implements UserService {

    public UserServiceMock() {
    }

    @Override

    public String SayHello(String content) {
        return "say hello fail";
    }
}

Dubbo 常用的容错机制

常见容错机制：failover ，failsafe，failfase ，failback，forking，来源于阿里的定义。

Failover 失败自动切换
当出现失败，重试其它服务器，通常用于读操作（推荐使用）。 重试会带来更长延迟。

Failfast 快速失败
只发起一次调用，失败立即报错,通常用于非幂等性的写操作。 如果有机器正在重启，可能会出现调用失败 。

Failsafe 失败安全
出现异常时，直接忽略，通常用于写入审计日志等操作。 调用信息丢失 可用于生产环境 Monitor。

Failback 失败自动恢复
后台记录失败请求，定时重发。通常用于消息通知操作 不可靠，重启丢失。 可用于生产环境 Registry。

Forking 并行调用多个服务器
只要一个成功即返回，通常用于实时性要求较高的读操作。 需要浪费更多服务资源 。

Broadcast
广播调用，所有提供逐个调用，任意一台报错则报错。通常用于更新提供方本地状态 速度慢，任意一台报错则报错 。

dubbo中提供了5种容错机制，用于微服务调用出错了进行重试或者忽略

1、Failover Cluster

这是Dubbo中默认的容错机制，这种方式比较常用。这种方式可以进行失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过retries="2"来设置重试次数(不含第一次)。

 <dubbo:service retries="2" />
  或：
 <dubbo:reference retries="2" />
    或：
 <dubbo:reference>
         <dubbo:method name="SayHello" retries="2" />
  </dubbo:reference>

2、Failfast Cluster（常用）

这种是 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

<dubbo:service cluster="failfast" />
          或：
<dubbo:reference cluster="failfast" />

3、Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

  <dubbo:service cluster="failsafe" />
          或：
 <dubbo:reference cluster="failsafe" />

4、Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

<dubbo:service cluster="failback" />
          或：
<dubbo:reference cluster="failback" />

5、Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过forks="2"来设置最大并行数。

<dubbo:service cluster=“forking" />
          或：
 <dubbo:reference cluster=“forking" />

Dubbo内置负载均衡策略

Dubbo内置了4种负载均衡策略:

1、Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

Random的权重可以使用@Service(weight=10)注解来设置

@Service(weight=10) 

2、RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
解决办法 :结合权重，把第二台机(性能低的)的权重设置低一点

3、LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

4、ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。

切换Dubbo的复制均含策略（默认是随机Random LoadBalance）

loadbalance值为负载的策略（注意小写）

<dubbo:service interface=".." loadbalance="roundrobin"></dubbo:service>   

或

<dubbo:reference interface="..."loadbalance="roundrobin"/>

或

<dubbo:service interface="...">

    <dubbo:method name="..."loadbalance="roundrobin"/>

</dubbo:service>

或

<dubbo:reference interface="...">
    <dubbo:method name="..."loadbalance="roundrobin"/>
</dubbo:reference>

一般在实际项目配置权重或负载均衡时不在代码中写死，动态使用默认配置，需要调节时通过dubbo管控台上进行配置