Open qixiaobo opened 5 years ago
I agree with you. 一、对与原来设计的请求格式
{application Name}/{Interface name}?version={version}&group={group}
我觉得可以把version和group放到request header里面去,这样就可以不干扰普通的get请求。
二、 对与原来设计的请求参数
{ "methodName" : "sayHello", "paramTypes" : ["org.apache.dubbo.demo.model.User"], "paramValues": [ { "id": 23, "username": "testUser" } ] }
为了实现上面说的效果,不使用类似于过滤器的东西,好像是没有办法实现的吧
I agree with you. 一、对与原来设计的请求格式
{application Name}/{Interface name}?version={version}&group={group}
我觉得可以把version和group放到request header里面去,这样就可以不干扰普通的get请求。
二、 对与原来设计的请求参数
{ "methodName" : "sayHello", "paramTypes" : ["org.apache.dubbo.demo.model.User"], "paramValues": [ { "id": 23, "username": "testUser" } ] }
- 把methodName也放到请求路径上去;
- 把paramTypes去掉,没有必要,json是松散的,解析后能对应上,就作为参数处理,对应不上,就为空; 在请求头 增加参数解析与接口实际参数的匹配方式,可以做成3种等级:严格(每一个参数的名称和类型都要对应上)、较松散(参数的名称可以不完全一致,但类型必须一致)、松散(参数的名称和类型都可以不一致,全部对应不上,就全是空)
- 最后,就只剩下真正的参数了,完全符合网关的要求了。
为了实现上面说的效果,不使用类似于过滤器的东西,好像是没有办法实现的吧
From me , I just want make it compatible with the old format. So I just add code like this
private Splitter queryStringSplitter = Splitter.on(",").trimResults().omitEmptyStrings();
if (params.containsKey("methodName")) {
methodName = params.get("methodName").get(0);
}
if (params.containsKey("paramTypes")) {
@SuppressWarnings("UnstableApiUsage") List<String> paramTypesList = queryStringSplitter.splitToList(params.get("paramTypes").get(0));
if (!paramTypesList.isEmpty()) {
paramTypes = paramTypesList.toArray(new String[]{});
}
}
if (methodName != null && serviceDefinition.getMethodName() == null) {
serviceDefinition.setMethodName(methodName);
}
if (paramTypes != null && serviceDefinition.getParamTypes() == null) {
serviceDefinition.setParamTypes(paramTypes);
}
paramTypes also need just because dubbo 2.6.x can not know the type
@hbwhypw 如果必须用dubbo本身提供的泛化处理,其实这个是没办法处理的,但是如果要传递 xxx.xxx.bean, 这样其实是不友好的,除非我们不使用她的dubbo泛化,直接跳过这部分,到目标机器上
举个例子 正常的dubbo处理.
user ---> nginx ---> toncat#controller ----> 调用dubbo ---> dubbo#service处理
调用dubbo
这一步是tcp的,如果可以转化成 http
的就可以达到你这个效果了,其实就是直接将dubbo请求转化成http请求了,只是不经过controller,直接让service对她进行处理,这个是可以做到的,这样一来,前端直接发送所需要的参数即可,其他的全都不需要了.
@hbwhypw 如果必须用dubbo本身提供的泛化处理,其实这个是没办法处理的,但是如果要传递 xxx.xxx.bean, 这样其实是不友好的,除非我们不使用她的dubbo泛化,直接跳过这部分,到目标机器上
举个例子 正常的dubbo处理.
user ---> nginx ---> toncat#controller ----> 调用dubbo ---> dubbo#service处理
调用dubbo
这一步是tcp的,如果可以转化成http
的就可以达到你这个效果了,其实就是直接将dubbo请求转化成http请求了,只是不经过controller,直接让service对她进行处理,这个是可以做到的,这样一来,前端直接发送所需要的参数即可,其他的全都不需要了.
可以做网关录入啊 不需要手动写这个controller 目前我们会就是把这个部分通过录入固定参数的方式实现了
@qixiaobo 一般dubbo转http主要是网关用的,也不是录入固定参数吧,我的实现就是类似与 Zuul
, 提供一个Servlet来处理. 然后借助Spring,直接invoke service,不经过controller。 可以这么说,对于业务其实都是无感知的。
录入固定参数的意思把service这些名称录入进去 可以屏蔽这些 只需要关注参数和返回值
可以试试,grpc-dubbo-proxy 直接封装为grpc服务,调用路径可以做到 nginx-> grpc-dubbo-proxy-> dubbo。
dubbo-proxy should consider about how to be a gateway~ If only json is accepted , we should pass through the json string from user. It's not user-friendly.