针对Dubbo接口Mock的解决方案详解
作者:土豆肉丝盖浇饭
背景
为了提升减轻测试回归压力,提高项目开发交付质量,我们开发和测试团队合作在部分项目内执行自动化测试。
为了更好的理解,我们对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种逻辑
- value = null 不走mock
- value = force xxx 强制走mock逻辑
- value = xxx 调用服务失败后走mock逻辑
看第三个逻辑,有没有感觉到这其实是一个降级,失败降级,而第二个逻辑,就称为强制降级了。
dubbo提供的官方文档,也将这个mock定义为降级
想了解Dubbo Mock表达式具体如何配置,可以看 Dubbo之降级Mock源码分析
是否满足我们需求
我们的需求是
- 第三方是否在线不影响我们的mock
- 配置灵活简单
经过测试,在设置check=false之后,给接口配置mock=force:return null之后,如果提供者不在线,会抛出没有提供者异常,不满足需求1
测试方式,对dubbo官方demo 增加如下配置
//from DemoServiceComponent @Reference(mock = "force:return null",check = false) private DemoService demoService;
对于需求2,也存在以下问题
- 我们不可能去动原有项目中的dubbo配置,所以我们只能通过往dubbo的注册中心增加override配置来触发强制mock,使用上不方便
- 从第1点也可以看到,mock功能依赖注册中心,我们的mock环境和测试环境都是使用同一个注册中心,不可行
- mock value文档不够详细,针对复杂类型的返回,构造费劲
所以结论是,实现上和使用上都不能满足我们需求,Dubbo的mock功能还是专注于生产级别的降级需求,我们需要开发方便我们使用的mock方案。
我们开发的扩展方案
我们开发针对dubbo框架的mock方案设计要点如下
- 同样的使用对Cluster扩展点包装类来植入mock逻辑,保证服务下线不影响我们自动化测试运行
- 使用properties配置文件来管理接口的mock开关,配置可以托管到apollo,无代码侵入
- 转发请求到我司的EsayMock服务器,配置接口返回类型的Json数据即可
能不能用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接口Mock的解决方案详解的详细内容,更多关于Dubbo接口Mock解决的资料请关注脚本之家其它相关文章!