[apache/dubbo]3.2.x处理protobuf包名异常

2023-12-12 582 views
2
Environment
  • Dubbo version: 3.2.3(org.apache.dubbo)
  • Operating System version: macOS Monterey
  • Java version: 1.8
Steps to reproduce this issue
  1. 定义protobuf,package xxx,java_package = yyy
  2. 使用reflection,获得的方法名字是xxx.method1 xxx.method2 ....
  3. 原生GRPC调用xxx.method1,返回12 UNIMPLEMENTED Service not found

3.1.X没有这个问题

Expected Behavior

原生GRPC调用xxx.method1,执行method1方法。

回答

7

Provider使用tri协议启动

7

@EarthChen @icodening PTAL

5

使用reflection拿到的全路径是 java_package ,而 grpc 标准的全路径是 package,这是合理的

3

误会了。reflection拿到的是package,但是客户端(不一定是Java,还可能是Postman或者grpcurl)用grpc和package调用不通tri。

4

贴一下 Idl 把 ,然后再说明一下用的是 stub 还是 reflection模式,方便的话提个 demo 的链接上来看看

1

Provider用的是stub,tri的。序列化方式是protobuf。 Consumer有tri-stub、原生grpc-stub(Java和Golang),也有reflection(Postman和grpcurl)

idl和demo,我整理一下。

3

demo在这里,复现方式写到了README.md https://github.com/luckybins/dubbo-proto/tree/master

IDL也写在了里面 dubbo-proto-service/src/main/proto/Greet.proto

另外,发现3.1.x,使用了java_package,tri-stub tri-stub之间也是不通的。

既然是全面兼容GRPC和protobuf,还是希望能够支持package与java_pacakge、go_package之类。

8

猜测,问题的关键在于,对于protobuf,生产者与消费者的进程间桥梁是package,各自进程stub的xxx_package与package相互衔接。如果是golang调用java项目,需要历经go_package -> package -> package -> java_package。而dubbo注册到nacos上的不是package,而是java_package,就使得这个桥梁没有接上。

3

对于 pb 来说, 实际的请求path 是 package,在java 测 stub模式下所支持的 path 也是 package,虽然包路径是 java_package,go 侧同理,但是对于服务发现来说,这个可能得考虑一下到底注册 java_package 还是 package

8

是的,对于3.1.x来说是这样的。而3.2.x,使用grpcurl 127.0.0.1的方式也不行,说明这个版本从package -> java_package这个桥梁也没有接上。

0

3.2x 默认关闭了内置服务,需要按需打开内置的反射服务,grpcurl 需要通过反射拿到 metadata 才可以访问

9

请问,目前服务能够自己声明按照package做服务注册和发现么?