作者:吕彦峰
在工作中我们经常遇到关于接口测试的问题,无论是对于QA同学还是开发同学都会有远程接口调用的需求。针对这种问题我研发了一个工具包,专门用于远程Dubbo调用,下面就让我们一起来学习一下。
主要解决的问题
- 针对QA同学来讲,如果对应的开发只是在某个任务中提供了接口,自己要怎么测试?如何保证该接口在测试环境和预发布环境都能测试通过?如果测试边界值?
- 针对开发同学来讲,其他的业务方反馈说自己的接口在stabel_master上没有返回数据或者少了字段?stable_pre环境下数据返回不正确?线上数据不正确?开发要如何验证自己的数据是否有问题呢?
remote-debug-util介绍
1.将工具jar包引入到本地pom文件中,目前稳定版本问1.1.0
<dependency>
<groupId>com.netease.kaola</groupId>
<artifactId>remote-debug-util</artifactId>
<version>1.1.0</version>
</dependency>
2.通过工具类边写具体的远程调用逻辑
AppGoodsServiceFacade appGoodsServiceFacade = InvokerFactory.getInstance("hst_test7", AppGoodsServiceFacade.class, EnvEnum.TEST_ENV);
通过以上调用,我们就拿到了hst_test7环境下的AppGoodsServiceFacade接口,具体要对接口进行怎么样的测试,就需要具体的开发自己确定了。
需要说明的一点是这样子的:以上接口虽然指定了group和interface,但是没有质指定version,version默认取的1.0版本。如果又其他版本的接口可以这么调用:
AppGoodsServiceFacade appGoodsServiceFacade = InvokerFactory.getInstance("hst_test7", AppGoodsServiceFacade.class,"2.0", EnvEnum.TEST_ENV);
通过以上的调用我们就指定了version为2.0。 因为考拉的环境基本分为3个,TEST环境,PRE环境和ONLINE环境,所以通过最后的参数表示该环境为测试环境。如果接口调用的为PRE环境的话需要指定最后的环境参数为EnvEnum.PRE_ENV,Online环境的话指定为EnvEnum.ONLNIE_ENV。
但是上面的方式在工作环境中会遇到如下问题:
- 预发布环境和线上环境因为服务器注册服务时候是将自己的机房IP注册到zk上的,我们及时拿到了具体服务的URL信息,也无法掉的通。
- 如果同一个服务器上同时暴露了两个服务,但是两个服务的接口内容不一定,我们怎么样掉到我们指定的那一个接口。
针对第一个问题的解决方式:
因为机房IP我们无法ping的通所以接口掉不通,因为我们可以才作用Dubbo的url直连模式进行调用,这样调用会相对于上面的情况稍微复杂一点:
RemoteInvoker<GoodsFrontInventoryService> remoteInvoker = new RemoteInvoker("10.171.165.2:20880", "online","1.0", GoodsFrontInventoryService.class);
GoodsFrontInventoryService goodsFrontInventoryService = remoteInvoker.getInvoker();
通过这两行代码我们就拿到线上环境的GoodsFrontInventoryService接口,具体需要如何进行测试,对应的开发自己解决。
参数说明:
/**
* @param address 远程服务的地址(host:port)
* @param group 远程服务的分组信息 例如:stable_pre,online,hst_test1
* @param version 接口的版本,默认为1.0
* @param invokerClass 需要测试的接口
*/
public RemoteInvoker(String address, String group, String version, Class invokerClass);
针对address的说明:adderss的host部分需要是本地可以ping通的ip地址,端口号可以不指定,如果不指定的话会默认填充为20880,如果具体的服务端口不是20880的话,会默认从20880重试至20890。这样的话我们可以基本不同考虑服务端口的问题,除非端口号比较特殊的话需要自己在address中指定一下。
我在自己的使用过程中发现一个问题:IP地址和端口号比较多,不同环境都有不用的地址记忆起来非常繁琐,因此希望可以只写一次,以后都可以方便的调用,因此开发了alias配置模式,方式如下:
NewGoodsFacade newGoodsFacade = InvokerFactory.getInstance("goods.front.base-service2", NewGoodsFacade.class);
通过以上的调用方式就可以获得goods-front工程的base-service2环境下的NewGoodsFacade接口。
需要说明解析规则:这种方式使用的前提工作是自己配置好前缀与对应地址的匹配规则,配置方式如下:
在自己的resource或者resource/config或者reource/config/locol目录下创建remote-debug.properties配置文件,文件的内容大致如下:
goods.front=com.netease.kaola.goods.constant.GoodsFrontConstant
goods.compose=com.netease.kaola.goods.constant.GoodsComposeConstant
通过以上的规则可以确定:由goods.front前缀可以找到GoodsFrontConstant这个配置文件,该文件的内容如下:
public static final String GOODS_FRONT_ONLINE = "10.171.168.28:20880"; public static final String GOODS_FRONT_BETA = "10.164.104.66:20880"; public static final String GOODS_FRONT_BASE_SERVICE2 = "10.165.124.192:20880"; public static final String GOODS_FRONT_STABLE_DEV = "10.165.125.200:20880"; public static final String GOODS_FRONT_STABLE_PRE = "10.171.164.238:20881"; public static final String GOODS_FRONT_PRE5 = "10.171.160.28:20882";
解析规则:
例如:goods.front.base-service2 将所有的小写变为大写,.(英文点号)和-(中划线)都替换为_(下划线),因此goods.front.base-service2可以替换为GOODS_FRONT_BASE_SERVICE2。然后就可以找到对应的服务地址。
解析规则比较固定,目前不支持自定义解析规则,基本只要在首次使用的时候引入配置文件,然后每次需要新增环境的时候把对应环境的地址信息加上就好,端口如果配置错了也没有问题,工具会进行一定的容错(在首次出错之后再次从20880重试到20890,直到有可用的接口返回为止)。
基于自己的经验对于工具类的使用作出以下建议:
1.测试环境下还是使用最简便的方式,直接配置group和interface调用
2.常用工程下的接口测试建议配置alias模式,以方便自己以后对于其他接口的测试
3.不常用的接口直接配置地址和版本信息直接调用
有时候为了不想在自己的工程内添加多余的垃圾代码(因为远程接口调用的代码实际上既不属于业务代码,也不属于单元测试,在工程中存在意义有点奇怪),因此也可以将工具类clone到本地,然后直接在工具类本地工程中边写测试代码。
工具类对于所有的模式都是支持,而且对于alias模式有更方便的支持,那就是可以直接在constant目录下配置指定的地址文件,不需要再次创建remote-debug.properties工具类。
实现方式解读
- 对于remote-debug工具类的定位就是一个纯粹的工具类,不需要启动Spring来加载dubbo的配置信息,就跟调用自己本地写的简单方法一样,基本上点击run之后就立马会有结果响应。
- 除了dubbo和zk之外没有任何依赖,做到足够小,足够精。
工具实现的核心来时Dubbo中ReferenceConfig提供的直连模式,基本的运行原理如下:
如果是注册中心模式的情况下:
- 通过提供的group和version,interface信息构造consumer端的直连URL。
- 根据提供的环境信息连接到对应的zk集群
- 根据URL信息从Registry中找到与其匹配的提供者URL列表
- 遍历所有的URL信息直到拿到可用的provider为止。
如果是alias或者基本配置模式:
- 解析alias信息,找到对应的地址(如果需要)
- 根据配置信息构造基本的URL
- 通过Echo来测试接口的可用性,并负责重试。
- 如果有异常的话将异常转换为可读的异常并返回/返回代理结果。
下面对于核心的处理逻辑进行介绍:
/**
* 获得可用的RemoteInvoker对象
* @param referenceConfig 这里已经将对应的配置信息转换为ReferenceConfig对象
* @return
*/
private T getAvaiableRemoteInvoker(ReferenceConfig<T> referenceConfig) {
T result = null;
EchoService echoService = null; try {
result = referenceConfig.get(); //回响测试
echoService = (EchoService)result;
echoService.$echo("OK");
} catch (Exception e) { //this.invoker主要为自定义的配置类
String host = this.invokerConfig.getAddress().split(":")[0]; for (int i = defaultPort; i < endPort; i++) {
invokerConfig.setAddress(host + ":" + i);
referenceConfig = initRefConfig(invokerConfig, false); try {
result = referenceConfig.get();
echoService = (EchoService)result;
echoService.$echo("OK"); break;
} catch (Exception e1){ continue;
}
}
} if (result == null) { throw new RuntimeException("Get remote invoker error, please check your network(host,port,VPN) by ping "
+ invokerConfig.getHost() + "or telnet host ip");
} return result;
}
/**
* 根据key读取配置的host:port 规则:goods.front.stable_master -> GOODS_FRONT_STABLE_MASTER
* @param key
* @return
*/
public static String getAddress(String key) {
checkKeyNotNull(key);
String[] keyGroup = key.split("\\.");
StringBuilder sb = new StringBuilder();
sb.append("."); //读取数据直到最后一个点号为止
for (int i = 0; i < keyGroup.length - 1; i++) {
sb.append(keyGroup[i].substring(0, 1).toUpperCase());
sb.append(keyGroup[i].substring(1));
}
sb.append("Constant");
String className = constantDir + sb.toString(); //先从工程constant目录下读取数据,如果读不到就从remote-debug.properties指定的配置文件中读数据
try {
String result = loadAddress(key, className); return result;
} catch (Exception e) { return getAddressByDefinedProp(key);
}
}
/**
* 根据配置信息拿到最红的接口代理
* @param group
* @param version
* @param interfaceClass
* @param env 环境
* @return
*/
public static <T> T getInstance(String group, String version, Class interfaceClass, EnvEnum env) {
URL url = URLUtil.valueOf(group, version, interfaceClass);
String registryAddress = null; if (env == null || env.getType() == EnvEnum.TEST_ENV.getType()) {
registryAddress = ZkAddressEnum.TEST_ZK_ADDRESS.getAddress();
} else if (env.getType() == EnvEnum.PRE_ENV.getType()) {
registryAddress = ZkAddressEnum.PRE_ZK_ADDRESS.getAddress();
} else {
registryAddress = ZkAddressEnum.ONLINE_ZK_ADDRESS.getAddress();
} if (registryAddress == null) { throw new RuntimeException("can not find registry address");
}
URL registryUrl = URL.valueOf(registryAddress);
Registry registry = registryFactory.getRegistry(registryUrl); if (registry == null) { throw new RuntimeException("can not find registry, registryUrl is " + url.toFullString());
}
List<URL> providerUrls = registry.lookup(url); //可用的provider可能有多个,因此会逐渐尝试直到有可用的为止
if (providerUrls != null && providerUrls.size() > 0) {
T result = getInvoker(providerUrls); if (result == null) { throw new RuntimeException("can not find class " + interfaceClass.getName() + "in registry");
} return result;
} throw new RuntimeException("can not find matched url in registry");
}
对于源码也只是设计了一些重要的流程,因为篇幅有限所有不能把所有的内容都讲解清楚。
基本上通过remote-debug的调用,文章开头提出的两个问题都可以得到完美的解决,作为商品前台的开发,我经常需要向其他业务方证明我或者他人的接口是没有问题的,基本上我都是通过工具类调用接口,然后返回数据给他们看。尤其是当我遇到线上问题的时候,你会发现这种方式查看接口返回数据是有多么优雅~~~~
如果,你曾被telnet拼参数时候的蛋疼气到过;
如果,你曾经在SOA上调用某个参数复杂的接口并且心情错乱过;
如果,你是一个以简为美的技术哥哥或者QA姐姐;
请速速转移到remote-debug工具包,开启远程调用的新生活吧。