dubbo理论之服务降级

降级目的

降级的目的是为了保证核心服务可用。

降级方式

降级可以有几个层面的分类： 自动降级和人工降级。按照功能可以分为：读服务降级和写服务降级。
1、对一些非核心服务进行人工降级
在大促销之前通过降级开关关闭那些推荐内容、评价等对主流程没有影响的功能。大促销完毕后，再进行恢复。
2、故障降级
比如调用的远程服务挂了，网络故障、或者RPC服务返回异常。 那么可以直接降级，降级的方案比如设置默认值、采用兜底数据（系统推荐的行为广告挂了，可以提前准备静态页面做返回）等等。
3、限流降级
在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能会导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阀值时，后续的请求被降级，比如进入排队页面，比如跳转到错误页（活动太火爆，稍后重试等）。

系统实现

1、在client端创建一个TestMock类，实现对应IDemoService的接口（需要对哪个接口进行mock，就实现哪个），名称必须以Mock结尾。

public class TestMock implements IDemoService{
    @Override
    public String startDemo(String s) {
        return "系统异常："+s;
    }
}

2、在client端的xml配置文件中，添加如下配置，增加一个mock属性指向创建的TestMock。

<!--配置接口以及协议地址-->
        <dubbo:reference interface="com.ft.dubbo.IDemoService" id="demoService" protocol="dubbo"
        mock="com.ft.dubbo.TestMock" timeout="5"/>

3、模拟错误（设置timeout），模拟超时异常，运行测试代码即可访问到TestMock这个类。当服务端故障解除以后，调用过程将恢复正常。
当timeout太小时（意味着请求超时），会走TestMock里面的方法。
当timeout合理时（正常调用），会正常调用服务端方法。

配置优先级别

总的来说，客户端配置优先于服务端。
以timeout为例，显示了配置的查找顺序，其它retries, loadbalance等类似。
1.方法级优先，接口级次之，全局配置再次之。
2.如果级别一样，则消费方优先，提供方次之。
其中，服务提供方配置，通过URL经由注册中心传递给消费方。
建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。