跟着小程学微服务-Mock自动化系统的原理及实现-阿里云开发者社区

一、前言

今天我将和大家一起探讨我们的“自动化Mock系统1.0版本”。

二、测试人员面临的测试问题

我公司目前用的是基于Dubbo的微服务改造，服务之间的调用链路冗长，每个服务又是单独的团队在维护，每个团队又在不断的演进和维护各个服务，那么对测试人员将是非常大的挑战。

测试人员每次进行功能测试的时候，测试用例每次都需要重新写一遍，无法将测试用例的数据沉淀，尤其是做自动化测试的时候，测试人员准备测试数据就需要很长时间，效率非常低。

目前接口自动化测试框架也多种多样，testng，junit，Fitnesse等，但都需要测试人员具备测试代码编写能力，如果要做好和手工接口测试一样效果的自动化测试更是需要大量的代码堆积，后期维护代码成本非常大。因此做成简单配置用例流，无需编写测试代码的系统是更贴合实际工作要求。

举个例子：拿互联网支付系统来说，某个团队新增了支付交易的需求，这时候要进行测试，测试人员除了要测试支付交易需求本身是否正确，同时也要结合上下游的服务整体进行回归测试，这时候开发人员往往在支付交易系统中采用“硬编码”的方式对上下游的系统进行“挡板”，如果测试人员对测试数据有所调整那么“挡板”也要跟着调整，同时在项目正式上线的时候，如果开发人员没有将“挡板”程序去除干净，将面临严重的线上问题。

三、Dubbo的Mock功能

1、Dubbo的Mock使用

Dubbo自带的Mock功能首先是为了做服务降级，比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过Mock数据返回授权失败。

我们从官网上举一个例子来说明：

<dubbo:reference interface="com.foo.BarService" mock="force" />

我们可以在期望的reference标签上加一个mock="force"，就可以将当前服务设置为mock。但是设置完mock属性后还没有结束，需要有一个Mock类对应我们的服务接口类。

规则如下：
接口名 + Mock后缀，服务接口调用失败Mock实现类，该Mock类必须有一个无参构造函数。

对应到com.foo.BarService的话，则创建BarServiceMock类。

public class BarServiceMock implements BarService {    

public String sayHello(String name) {        

   // 你可以伪造容错数据，此方法只在出现RpcException时被执行
   return "容错数据";
    }
}

经过以上设置后，当调用BarService进行远程调用的话，直接请求到BarServiceMock类上面进行模拟测试。

2、Dubbo Mock的原理解析

在dubbo的配置文件中
classpath:/META-INF/dubbo/internal/com.alibaba.dubbo.rpc.cluster.Cluster
可以看到如下配置列表：

mock=com.alibaba.dubbo.rpc.cluster.support.wrapper.MockClusterWrapper  

failover=com.alibaba.dubbo.rpc.cluster.support.FailoverCluster  

failfast=com.alibaba.dubbo.rpc.cluster.support.FailfastCluster  

failsafe=com.alibaba.dubbo.rpc.cluster.support.FailsafeCluster  

failback=com.alibaba.dubbo.rpc.cluster.support.FailbackCluster  

forking=com.alibaba.dubbo.rpc.cluster.support.ForkingCluster  

available=com.alibaba.dubbo.rpc.cluster.support.AvailableCluster  

switch=com.alibaba.dubbo.rpc.cluster.support.SwitchCluster  

mergeable=com.alibaba.dubbo.rpc.cluster.support.MergeableCluster  

broadcast=com.alibaba.dubbo.rpc.cluster.support.BroadcastCluster

我们可以看到配置文件中实际上有五大路由策略：

AvailableCluster: 获取可用的调用。遍历所有Invokers判断Invoker.isAvalible,只要一个有为true直接调用返回，不管成不成功。
BroadcastCluster: 广播调用。遍历所有Invokers, 逐个调用每个调用catch住异常不影响其他invoker调用。
FailbackCluster: 失败自动恢复，对于invoker调用失败，后台记录失败请求，任务定时重发, 通常用于通知。
FailfastCluster: 快速失败，只发起一次调用，失败立即保错，通常用于非幂等性操作。
FailoverCluster: 失败转移，当出现失败，重试其它服务器，通常用于读操作，但重试会带来更长延迟。

Dubbo中默认使用的是FailoverCluster策略，而在实际执行的过程中是FailoverCluster会被先被注入到MockClusterWrapper中，过程就是：

Cluster$Adaptive -> 定位到内部key为failover的对象 ->FailoverCluster->注入到MockClusterWrapper

MockClusterWrapper内部会创建一个MockClusterInvoker对象。实际创建是封装了FailoverClusterInvoker的MockClusterInvoker，这样就成功地在Invoker之中植入了Mock机制。

我们来看MockClusterInvoker的内部实现：

如果在没有配置之中没有设置mock，那么直接把方法调用转发给实际的Invoker(也就是FailoverClusterInvoker)。

String mockValue = directory.getUrl().getMethodParameter(  
      invocation.getMethodName(), Constants.MOCK_KEY, Boolean.FALSE.toString()).trim();   
  if (mockValue.length() == 0 || mockValue.equalsIgnoreCase("false"))  
  {  
      //no mock  
      result = this.invoker.invoke(invocation);  
  }

如果配置了强制执行Mock，比如发生服务降级，那么直接按照配置执行mock之后返回。

else if (mockValue.startsWith("force"))  
{  
    if (logger.isWarnEnabled())  
    {  
       logger.info("force-mock: " + invocation.getMethodName() + " force-mock enabled , url: " +  directory.getUrl());  
     }  
    //force:direct mock  
     result = doMockInvoke(invocation, null);  
}

如果是其它的情况，比如只是配置的是mock=fail:return null，那么就是在正常的调用出现异常的时候按照配置执行mock。

try   {  
  result = this.invoker.invoke(invocation);  
}  catch (RpcException rpcException)  {  
   if (rpcException.isBiz())  {  
       throw rpcException;  
   }   
   else  
   {  
   if (logger.isWarnEnabled())  {  
      logger.info("fail-mock: " + invocation.getMethodName() + " fail-mock enabled , url : "   
   +  directory.getUrl(), rpcException);  
   }  
      result = doMockInvoke(invocation, rpcException);  
   }  
}

3、Dubbo Mock的适用场景

Dubbo的Mock功能主要是为了做服务降级而使用的，服务提供方在客户端执行容错逻辑，在出现RpcException(比如网络失败，超时等)时进行容错，然后执行降级Mock逻辑。自身并不适合做Mock测试系统。

四、自动化Mock系统的实现

1、Mock系统的简单用例图

2、Mock系统的架构图

为了基于Dubbo实现Mock功能，需要对Dubbo源码进行一些必要的修改，通过上面的架构图我们可以看到，实际上我们正是利用了Dubbo的Filter chain过滤器链这一机制实现的，为了方便大家更好的理解，下面将简单介绍一下Dubbo的Filter机制。

2.1、Dubbo的Filter原理分析

Filter：是一种递归的链式调用，用来在远程调用真正执行的前后加入一些逻辑，跟aop的拦截器servlet中filter概念一样的。

Filter接口定义：

@SPIpublic interface Filter {   

  Result invoke(Invoker<?> invoker,Invocation invocation) 

  throws RpcException;
}

Filter的实现类需要打上@Activate注解, @Activate的group属性是个string数组，我们可以通过这个属性来指定这个filter是在consumer, provider还是两者情况下激活，所谓激活就是能够被获取，组成filter链。

List<Filter> filters =ExtensionLoader.getExtensionLoader(Filter.class).getAct ivateExtension(invoker.getUrl(),key, group);

Key就是SERVICE_FILTER_KEY还是REFERENCE_FILTER_KEYGroup就是consumer或者provider

关于SPI的详细介绍请大家参考我之前写的另一篇文章http://www.jianshu.com/p/46aa69643c97

ProtocolFilterWrapper：在服务的暴露与引用的过程中根据KEY是PROVIDER还是CONSUMER来构建服务提供者与消费者的调用过滤器链，Filter最终都要被封装到Wrapper中的。

public <T> Exporter<T> export(Invoker<T>invoker)throws RpcException {

return protocol.export(buildInvokerChain(invoker, Constants.SERVICE_FILTER_KEY, Constants.PROVIDER));
}

   public <T> Invoker<T> refer(Class<T> type,URL url)

  throws RpcException {     

     return buildInvokerChain(protocol.refer(type, url),Constants.REFERENCE_FILTER_KEY, Constants.CONSUMER);
}

构建filter链，当我们获取激活的filter集合后就通过ProtocolFilterWrapper类中的buildInvokerChain方法来构建。

for (int i = filters.size() - 1; i >= 0; i --) {      

   final Filter filter = filters.get(i);      

   final Invoker<T> next = last;
   last = new Invoker<T>() {            

     public Result invoke(Invocation invocation)throws RpcException {

      return filter.invoke(next, invocation);
     }
           //。。。。。。。 

//其他方法
       };
 }

2.2、Mock流程介绍

注：我们在<dubbo:application name>中新加了自定义的“env=test”这样的属性配置用来标明当前环境是测试的还是正式的，用户每次通过Dubbo请求的远程服务的时候，都会首先经过我们自定义的Filter，我们自定义的Filter会首先判断当前的环境是test还是正式，如果是test的环境则直接访问Mock配置中心获取提前配置好的Mock数据并封装成用户定义的Response对象返回。