基于 Dubbo 分布式服务框架的一种 MOCK 方式

首先简单说一下Dubbo是什么呢?不懂的同学百度一下去吧!

Dubbo目前的应用已经越来越广泛、或者基于Dubbo二次开发的也越来越多,那么应用到Dubbo的系统基本也是采用微服务架构设计的系统、或者多个系统、多个应用之间的接口是有依赖关系的,所以就会出现需要MOCK的应用场景。具体什么是MOCK,不懂的同学也百度一下吧!

在Dubbo里面有两个概念:
1:Provider暴露服务的服务提供方(接口提供方)
2:Consumer调用远程服务的服务消费方(接口调用方)


下面是应用A依赖应用B的UserService接口,在工程里面代码的配置
Dubbo的应用是以spring注入服务,首先应用B要发布一个接口
一、应用B发布一个UserService接口
1.首先有一个UserServce接口类

package com.test.service;
public interface UserService{
  public User getUser(User user);
}

2.来一个DTO的User类

public class User{
    private int id;
    private String name;
    public int getId() {
        return id;
    }
    public void setId(int id) {
        this.id = id;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

3.接口类和参数类创建好之后,通过spring发布接口,接口发布到zookeeper里面,我这里没有写接口的实现,这里用不到

<!-- 提供方应用名称信息,这个相当于起一个名字,我们dubbo管理页面比较清晰是哪个应用暴露出来的 -->
 <dubbo:application name="dubbo_provider"></dubbo:application>
 <!-- 使用zookeeper注册中心暴露服务地址 -->  
 <dubbo:registry address="zookeeper://127.0.0.1:2181" check="false" subscribe="false" register=""></dubbo:registry>
<!-- 要暴露的服务接口 -->  
<dubbo:service interface="com.test.service.UserService" ref="userService" />      

二、应用A引用应用B发布的UserService接口
1.dubbo服务框架要求接口调用方和接口提供方的java接口文件和参数类型保持一直,所以我们需要服务端提供发布的接口类和参数类,通常服务端会通过Maven发布接口的Jar包共服务调用方(这里的应用A)使用,并且参数类要进行序列化可以,入参通过序列化之后到服务端在反序列化,序列化这块大家百度不细说
2.假设我们的应用A引入的应用A提供的jar包
3.通过spring注册接口引用的接口

<dubbo:application name="dubbo_consumer"></dubbo:application>
  <!-- 使用zookeeper注册中心暴露服务地址 -->  
  <dubbo:registry address="zookeeper://192.168.74.129:2181" check="false"></dubbo:registry> 
    <!-- 要引用的服务 -->  
  <dubbo:reference interface="com.test.service.UserService" id="userService"></dubbo:reference>

两个应用都完事了,那么我们的应用场景是MOCK应用B(接口提供方),通常的MOCK方式是,测试人员自己发布一个一样的接口(应用C),然后把应用A的调用指向(应用C),这种方式可以解决MOCK

这种方式的弊端:

1.需要开发MOCK代码

2.对人员要求技能高

3.需要接口提供方的依赖jar

4.需要容器发布应用C

5.接口变更需要更新MOCK代码

6.发布时间长,需要编码发布


那么我们采取另外一个方式,filter过滤器,filter是放在客户端的(应用A),通过拦截请求,如何配置filter参考http://blog.csdn.net/mj158518/article/details/47379799
配置filter之后呢应用A的请求首先会到filter里面

public class CustomConsumerFilter implements Filter {
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
      Result result = null; //首先定义一个返回对象;
      String interfaceName = invoker.getUrl().getPath();     //获取接口名称
      String methodName = invocation.getMethodName(); //获取方法名称
      Object[] arguments =invocation.getArguments();        //获取参数,我举的例子是一个参数,实际可能有多个参数,多种类型,
      String paramJson =JSON.toJSONString(arguments, SerializerFeature.WriteClassName);//这里面可能有泛型,所以入参在序列化时要上json
      List<String> paramTypes = reflectTools.getMethodParameterType(interfaceName, methodName);     //获取所有的入参类型,这块要自己写反射处理
      String methodReturnType = reflectTools.getMethodTypeReturnString(interfaceName, methodName);  //获取被调用方法返回类型,这块要自己写反射处理
      //上面两行可以拿到入参类型和返回值的类型,是因为我们在客户端只用里面有参数类

      //下面定义一个httpclient,用于发送Http请求,首先我们发送一个请求,确认这个接口的这个方法是否在我们测试平台存在了
       Map paramMap = new HashMap();
       paramMap.put("interfaceName", interfaceName);
       paramMap.put("methodName", methodName);
       String r = requestClient.send(paramMap, "getInterfaceInfo");     
      //如果不存在,调用真实的接口获取返回值,
      result = invoker.invoke(invocation);   //调用真实接口
      //然后把接口信息存在我们的测试平台

  }
}

具体的代码我就不写了,下面弄个逻辑图吧,里面各种类型处理,用户选择匹配MOCK返回数据等,太多了代码


测试平台,用户选择匹配

测试平台,用户配置MOCK返回数据,这里面的关键字,决定用户需要什么样的返回数据,MOCK数据不是死的是可以配置的


这样做的好处:

1.测试人员不需要编写测试代码

2.人员要求低

3.不需要依赖jar

4.无需部署发布

5.不需要维护接口信息

6.用户配置秒级生效


那么大家用这种方式会发现,需要把我们的filter包放到应用A里面,并且配置spring的接口文件,相信大家都有自动部署,可以在部署过程中,直接扫描spring.xml找出接口,默认全部加上filter,同时把我们的filter包也放到应用的lib下,做到用户不感知,达到自动MOCK的生态


上面细节的东西不是很多,主要是讲一种思路,这个文章懂dubbo的人可能更容易理解,欢迎大家讨论