使用dubbo-go搭建dubbo接口测试平台

捉虫大师 等级 511 0 0

背景

http接口测试只需要一个curl命令,但dubbo协议没有这样的现成接口测试工具。通常公司内的dubbo控制台或其他平台会集成一个dubbo接口测试工具。

调用一个dubbo接口,需要知道服务名service、方法名method和参数args

正常的调用,调用方需引入服务提供方定义的接口jar包。

作为接口测试平台,没办法引入所有提供方定义的接口jar包,可以有以下方案来解决:

  1. dubbo支持telnet协议调用dubbo接口
  2. dubbo的泛化调用可以在不引入提供方接口定义jar包的情况下对接口进行调用

对于方案1,实现成本很低,甚至可以在服务器上直接用telnet测试

使用dubbo-go搭建dubbo接口测试平台

它也有缺点

  • 调用无法经过filter
  • 无法携带隐式参数attachment

刚好我们把方案1的优缺点都踩了,我们的dubbo控制台是go语言编写,短时间快速实现,就采用了telnet的方式。

随着业务的发展,流量染色,或标签路由等需要携带隐式参数。

没有走自定义filter,导致业务接口执行不符合预期等都迫使我们升级为泛化调用。

dubbo接口泛化调用在控制台是go编写的情况下也有两个方案可选:

  1. 单独起一个java进程,暴露http端口,与go进程进行交互,泛化调用使用dubbo的java sdk进行编写
  2. 控制台引入dubbo-go,使用dubbo-go进行泛化调用

出于对dubbo java版本的了解,方案1肯定可行,只是架构变得复杂。

而方案2由于dubbo-go还是比较新的项目,并不是很了解,所以不确定其可行性和兼容性,但如果能实现,会大大降低架构的复杂度。

dubbo-go介绍

dubbo-go是dubbo的golang实现版本,它出现的初衷是为了让golang和java的dubbo生态互通。

如今dubbo-go支持provider和consumer端,可以作为一个独立的rpc框架使用,同时社区也是dubbo生态中最火的一个。

如果要说它的意义,我觉得除了和java互通外还有一点非常重要,那就是它能发挥golang协程的巨大作用,这一点可以用在dubbo网关上,如果用dubbo-go实现dubbo网关,就无需纠结线程池、异步等问题。

泛化调用的使用

首先provider端提供一个接口,这个不再赘述,非常简单,接口定义如下

package org.newboo.basic.api;

import org.newboo.basic.model.RpcResult;
import org.newboo.basic.model.User;

public interface MyDemoService {
    RpcResult<String> call(User user);
}
package org.newboo.basic.model;

import java.io.Serializable;

public class User implements Serializable {
    private String uid;
    private String name;
    private String remoteServiceTag;
    ...
}

再来编写java版的泛化调用代码,不引入provider方的jar包:

ReferenceConfig<GenericService> reference = new ReferenceConfig<>();
// ①引用服务名
reference.setInterface("org.newboo.basic.api.MyDemoService");
// ②设置泛化调用标志
reference.setGeneric("true");

DubboBootstrap bootstrap = DubboBootstrap.getInstance();
bootstrap.application(new ApplicationConfig("dubbo-demo-api-consumer"))
        .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
        .reference(reference)
        .start();

GenericService genericService = ReferenceConfigCache.getCache().get(reference);
String[] ps = new String[1];
// ③参数类型
ps[0] = "org.newboo.basic.model.User";
Object[] ags = new Object[1];
// ④pojo参数使用map构造
Map<String, String> user = new HashMap<>();
user.put("uid", "1");
user.put("name", "roshi");
user.put("remoteServiceTag", "tag");
ags[0] = user;
// ⑤发起调用
Object res = genericService.$invoke("call", ps, ags);
System.out.println(res);

关键的步骤已在代码注释中标明

golang版本

直接修改的dubbo-go-samples代码,参考https://github.com/apache/dubbo-go-samples 启动时需要设置配置文件路径ENV

var (
    appName         = "UserConsumer"
    referenceConfig = config.ReferenceConfig{
        InterfaceName: "org.newboo.basic.api.MyDemoService",
        Cluster:       "failover",
    // registry需要配置文件
        Registry:      "demoZk",
        Protocol:      dubbo.DUBBO,
        Generic:       true,
    }
)

func init() {
    referenceConfig.GenericLoad(appName) //appName is the unique identification of RPCService
    time.Sleep(1 * time.Second)
}

// need to setup environment variable "CONF_CONSUMER_FILE_PATH" to "conf/client.yml" before run
func main() {
    call()
}

func call() {
  // 设置attachment
    ctx := context.WithValue(context.TODO(), constant.AttachmentKey, map[string]string{"tag":"test"})

    resp, err := referenceConfig.GetRPCService().(*config.GenericService).Invoke(
        ctx,
        []interface{}{
            "call",
            []string{"org.newboo.basic.model.User"},
            []interface{}{map[string]string{"uid":"111","name":"roshi","remoteServiceTag":"hello"}},
        },
    )
    if err != nil {
        panic(err)
    }
    gxlog.CInfo("success called res: %+v\n", resp)
}

这里我设置了一个attachment,也能正常被provider识别

使用dubbo-go搭建dubbo接口测试平台

泛化调用原理

泛化调用GenericService是dubbo默认提供的一个服务。

其提供了一个名为$invoke的方法,该方法参数有三个,第一个参数是真实要调用的方法名,第二个是参数类型数组,第三个是真实的参数数组,其定义为

public interface GenericService {
    Object $invoke(String method, String[] parameterTypes, Object[] args) throws GenericException;
    ...
}

有了这三个参数,利用反射就能调用到真实的接口了。

java版实现细节

实现这种泛化调用主要涉及到两个filter:

  • consumer端的GenericImplFilter
  • provider端的GenericFilter

consumer端的filter将generic标志设置到attachment中,并封装调用为GenericService.$invoke

provider端filter判断请求是generic时进行拦截,获取调用方法名、参数、参数值,先序列化为pojo对象,再进行反射调用真实接口。

dubbo-go版细节

与java实现基本一致,其中generic_filter充当consumer端的filter,也是将调用封装为GenericService.$invoke,其中还涉及到一个参数类型的转换,将map转换为dubbo-go-hessian2.Object,这样provider端就可以将其反序列化为Object对象。

与其相关的版本变更如下

  • v1.3.0开始支持泛化调用
  • v1.4.0开始支持用户设置attachement
  • v.15.1开始支持动态tag路由
  • v1.5.7-rc1修复了直连provider时无法走filter的bug

踩坑:v1.5.7-rc1 之前如果使用直连provider的方式,不会走filter,导致参数序列化出错,provider端会报类型转换异常

结论

dubbo-go的泛化调用推荐使用>=v1.5.7-rc1版本,其功能几乎已和java版打平,甚至其实现都与java类似。

使用dubbo-go构建网关、接口测试平台、或者打通golang与java技术生态,不失为一个好的选择。


搜索关注微信公众号"捉虫大师",后端技术分享,架构设计、性能优化、源码阅读、问题排查、踩坑实践。

使用dubbo-go搭建dubbo接口测试平台

收藏
评论区

相关推荐

升级dubbo,小心default.version
上周遇到个关于升级dubbo 2.6 到2.7的兼容性问题,差点造成线上故障,这里记录下,也给大家提个醒。 问题回放有一个接口的提供方(dubbo 2.6.6)这么配置接口的版本号xml<dubbo:provider version"1.0.0"/消费方(也是dubbo 2.6.6)的reference这么配置xml<dubbo:
几个你不知道的dubbo注册中心细节
你会正确配置backup地址吗?在配置dubbo注册中心时,一般会这样写dubbo.registry.protocolzookeeperdubbo.registry.address127.0.0.1:2181也会简单地写成dubbo.registry.addresszookeeper://127.0.0.1:2181当z
聊聊dubbo协议
协议协议通俗易懂地解释就是通信双方需要遵循的约定。我们了解的常见的网络传输协议有tcp、udp、http等。再到我们常用的基础组件,一般来说client端与server端也有相应的协议,如redis、mysql、zookeeper等都是各自约定的私有协议,同样今天标题中的dubbo协议也是一种私有协议,他们都是应用层协议,基于tcp或udp设计。
聊聊dubbo协议2
在中介绍了attachments在consumer和provider间的传递情况,有个疑问没有给出答案。为什么2.7.x版本的dubbo不支持provider端向consumer端回传隐式参数呢?今天的续集将揭晓答案。 抓包确定是provider没发还是consumer丢掉 以下测试基于dubbo 2.7.6版本在provider端加入下面的代码
Dubbo 源码分析 - 服务调用过程
Dubbo 源码分析 服务调用过程注: 本系列文章已捐赠给 Dubbo 社区,你也可以在 Dubbo 中阅读本系列文章。1\. 简介在前面的文章中,我们分析了 Dubbo SPI、服务导出与引入、以及集群容错方面的代码。经过前
Dubbo 源码分析 - 集群容错之 LoadBalance
Dubbo 源码分析 集群容错之 LoadBalance注: 本系列文章已捐赠给 Dubbo 社区,你也可以在 Dubbo 中阅读本系列文章。1.简介LoadBalance 中文意思为负载均衡,它的职责是将网络
Dubbo 源码分析 - 集群容错之 Router
注: 本系列文章已捐赠给 Dubbo 社区,你也可以在 Dubbo 中阅读本系列文章。1\. 简介上一篇文章分析了集群容错的第一部分 – 服务目录 Directory。服务目录在刷新 Invoker 列表的过程中,会通过 Router 进行服务路由。上一篇文章关于服务路由相关逻辑没有细致分析,一笔带过了,本篇文章将对此进行详细的分析。首先,先来介绍一下服务目
Dubbo 源码分析 - 集群容错之Directory
注: 本系列文章已捐赠给 Dubbo 社区,你也可以在 Dubbo 中阅读本系列文章。1\. 简介前面文章分析了服务的导出与引用过程,从本篇文章开始,我将开始分析 Dubbo 集群容错方面的源码。这部分源码包含四个部分,分别是服务目录 Directory、服务路由 Router、集群 Cluster 和负载均衡 LoadBalance。这几个部分的源码逻辑比
dubbo应用级服务发现初体验
dubbo应用级服务发现介绍了解dubbo的朋友知道,dubbo的provider启动时向注册中心注册,consumer从注册中心消费。目前dubbo往注册中心上注册的数据是接口级,而应用级服务发现是往注册中心上注册实例(ip+port),两者的区别只是注册的粒度不同。至于为什么会出现应用级服务发现,有如下几点原因 与业界主流微服务模型对齐,比如 Sprin
dubbo的前世今生
背景在很久以前,网站应用是单体应用的架构,流量小,所有功能、代码都部署在一起,成本低。此时数据库访问框架ORM是关键。后来流量逐渐增大,单体应用被拆分为互不相干的多个应用,这就是垂直架构,此时加速前端页面开发的Web框架MVC是关键。再后来,垂直应用越来越大,应用间的交互不可避免,分布式服务框架RPC变成了关键。 dubboRPC,全称Remote Proc
redis在微服务领域的贡献
本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎star。 前言说到redis,可能大家的脑海中蹦出的关键词是:NoSQL、KV、高性能、缓存等。但今天的文章从另一个角度——微服务来展开。这篇文章的起因也是源自一次面试经历,在面试一位来自陌陌的候选人(就是那个交友的陌陌)时,他提到一点让我觉得很有意思,他说red
给dubbo贡献源码,做梦都在修bug
本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎star。 一在之前的文章《redis在微服务领域的贡献》中,从一次面试经历中了解了redis可以在微服务中玩的这么溜,同时也从源码角度分析了dubbo的redis注册中心。最后得出了dubbo的redis注册中心不能用于生产的结论,其中原因有如下两点: 使用了ke
dubbo网关演进之路
本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎star。 背景随着公司业务的飞速发展,基于php的模块化架构难以支持未来业务的发展: php模块化架远远落后于行业主流架构(微服务–云原生),而php生态的服务治理开源组件匮乏,研发投入过大 杭州php人才匮乏,导致新鲜血液招聘困难 基于php的多进程架构难以支撑
dubbo 2.7应用级服务发现踩坑小记
本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎star。 背景本文记录最近一位读者反馈的dubbo 2.7.x中应用级服务发现的问题,关于dubbo应用级服务发现的相关介绍可以参考之前的文章,这里不再赘述。读者反馈他们在基于dubbo 2.7应用级服务发现开发dubbo网关,根据文章《dubbo应用级服务发现初
使用dubbo-go搭建dubbo接口测试平台
背景http接口测试只需要一个curl命令,但dubbo协议没有这样的现成接口测试工具。通常公司内的dubbo控制台或其他平台会集成一个dubbo接口测试工具。调用一个dubbo接口,需要知道服务名service、方法名method和参数args。正常的调用,调用方需引入服务提供方定义的接口jar包。作为接口测试平台,没办法引入所有提供方定义的接口jar包,