背景

为了提升减轻测试回归压力，提高项目开发交付质量，我们开发和测试团队合作在部分项目内执行自动化测试。

为了更好的理解，我们对mock的需要，先来看下wiki上对自动化测试的解释。

在软件测试中， 自动化测试指的是使用独立于待测软件的其他软件来自动执行测试、比较实际结果与预期并生成测试报告这一过程。

我们的自动化测试是按照我们预设的流程执行的，我们不希望受到第三方服务的影响(上下线，接口返回错误数据),所以在调用三方接口的时候，我们会采取mock，返回我们预期的数据。

在自动化测试中，我们针对http，dubbo，mq消息这三种接口进行了mock，本文讲解的是我们对dubbo接口进行mock的解决方案。

Dubbo目前提供方案

首先我们来看下dubbo框架本身提供的mock特性。

dubbo mock特性的核心代码如下

//from MockClusterInvoker
public Result invoke(Invocation invocation) throws RpcException {
        Result result = null;

        //获取方法级别mock配置
        String value = directory.getUrl().getMethodParameter(invocation.getMethodName(), Constants.MOCK_KEY, Boolean.FALSE.toString()).trim();
        //没有配置 或者 =false
        if (value.length() == 0 || value.equalsIgnoreCase("false")) {
            //no mock
            result = this.invoker.invoke(invocation);
        } else if (value.startsWith("force")) {
            // force 开头 强制进行mock
            if (logger.isWarnEnabled()) {
                logger.warn("force-mock: " + invocation.getMethodName() + " force-mock enabled , url : " + directory.getUrl());
            }
            //force:direct mock
            result = doMockInvoke(invocation, null);
        } else {
            //不是force的话 是失败了再进行mock
            //fail-mock
            try {
                result = this.invoker.invoke(invocation);
            } catch (RpcException e) {
                //如果是业务异常不进行mock
                if (e.isBiz()) {
                    throw e;
                }
                
                if (logger.isWarnEnabled()) {
                    logger.warn("fail-mock: " + invocation.getMethodName() + " fail-mock enabled , url : " + directory.getUrl(), e);
                }
                result = doMockInvoke(invocation, e);
            }
        }
        return result;
    }

针对url中key=mock对应value的不同，分别对应3种逻辑

1. value = null 不走mock
2. value = force xxx 强制走mock逻辑
3. value = xxx 调用服务失败后走mock逻辑

看第三个逻辑，有没有感觉到这其实是一个降级，失败降级，而第二个逻辑，就称为强制降级了。

dubbo提供的官方文档，也将这个mock定义为降级

想了解Dubbo Mock表达式具体如何配置，可以看Dubbo之降级Mock源码分析

是否满足我们需求

我们的需求是

1. 第三方是否在线不影响我们的mock
2. 配置灵活简单

经过测试，在设置check=false之后，给接口配置mock=force:return null之后，如果提供者不在线，会抛出没有提供者异常，不满足需求1

测试方式，对dubbo官方demo 增加如下配置

//from DemoServiceComponent
@Reference(mock = "force:return null",check = false)
private DemoService demoService;

对于需求2，也存在以下问题

1. 我们不可能去动原有项目中的dubbo配置，所以我们只能通过往dubbo的注册中心增加override配置来触发强制mock，使用上不方便
2. 从第1点也可以看到，mock功能依赖注册中心，我们的mock环境和测试环境都是使用同一个注册中心，不可行
3. mock value文档不够详细，针对复杂类型的返回，构造费劲

所以结论是，实现上和使用上都不能满足我们需求，Dubbo的mock功能还是专注于生产级别的降级需求，我们需要开发方便我们使用的mock方案。

我们开发的扩展方案

我们开发针对dubbo框架的mock方案设计要点如下

1. 同样的使用对Cluster扩展点包装类来植入mock逻辑，保证服务下线不影响我们自动化测试运行
2. 使用properties配置文件来管理接口的mock开关，配置可以托管到apollo，无代码侵入
3. 转发请求到我司的EsayMock服务器，配置接口返回类型的Json数据即可

image.png

能不能用Filter来做

之前在网上看到过类似的方案是使用Filter来实现的，其实我们第一版也是通过Filter来做，但是存在一个问题，我们mock的接口的提供者必须在线。

下面从源码的角度来解释为何出现这个问题

在使用zookeeper为注册中心，以及check=false的前提下

Filter逻辑的植入是通过Protocol的包装类ProtocolFilterWrapper，ProtocolFilterWrapper会对除了RegistryProtocol的其他Protocol植入Filter调用链逻辑。

//from ProtocolFilterWrapper
public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
    if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) {
        return protocol.refer(type, url);
    }
    return buildInvokerChain(protocol.refer(type, url), Constants.REFERENCE_FILTER_KEY, Constants.CONSUMER);
}

问题就出在RegistryProtocol，RegistryProtocol通过Cluster,Directory模块间接依赖了DubboProtocl,而在Directory模块中,也就是RegistryDirectory中会对提供者数量进行检查，如果为0，会抛出异常。这一切都发生在对DubboProtocl生成的invoker调用之前。

DubboProtocol生成的invoker，封装了filter逻辑以及对远端服务调用逻辑

RegistryProtcol生成的invoekr，在DubboProtocol基础上封装了集群调用，负载均衡等服务治理功能

//from RegistryDirectory

private void refreshInvoker(List<URL> invokerUrls) {
        Assert.notNull(invokerUrls, "invokerUrls should not be null");
        //这边为什么是一个，针对没有提供者目录，dubbo框架会自动返回一个empty的url
        if (invokerUrls.size() == 1
                && invokerUrls.get(0) != null
                && Constants.EMPTY_PROTOCOL.equals(invokerUrls.get(0).getProtocol())) {
            this.forbidden = true; // Forbid to access
            this.invokers = Collections.emptyList();
            routerChain.setInvokers(this.invokers);
            destroyAllInvokers(); // Close all invokers
        }
        //...
}

public List<Invoker<T>> doList(Invocation invocation) {
        if (forbidden) {
            // 1. No service provider 2. Service providers are disabled
            throw new RpcException(RpcException.FORBIDDEN_EXCEPTION, "No provider available from registry " +
                    getUrl().getAddress() + " for service " + getConsumerUrl().getServiceKey() + " on consumer " +
                    NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion() +
                    ", please check status of providers(disabled, not registered or in blacklist).");
        }
        //...
}

没看过dubbo源码的朋友可能看不懂，你可以看了dubbo refer原理之后再来品味

不足

mock服务器中的json和dubbo接口不是强关联，不过问题不大，我们跑的都是预设流程。

开源项目

讲了这么多，都是原理性的内容，下面贴上链接，欢迎大家使用以及提建议。

dubbo-easy-mock 项目地址

参考

Dubbo文档-服务降级