dubbo
dubbo copied to clipboard
apache
protobuf package question
- [*] I have searched the issues of this repository and believe that this is not a duplicate.
Environment
- Dubbo version: 3.2.3（org.apache.dubbo）
- Operating System version: macOS Monterey
- Java version: 1.8
Steps to reproduce this issue
- 定义protobuf，package xxx，java_package = yyy
- 使用reflection，获得的方法名字是xxx.method1 xxx.method2 ....
- 原生GRPC调用xxx.method1，返回12 UNIMPLEMENTED Service not found
3.1.X没有这个问题
Pls. provide [GitHub address] to reproduce this issue.
Expected Behavior
原生GRPC调用xxx.method1，执行method1方法。
If there is an exception, please attach the exception trace:
Just put your stack trace here!
使用reflection拿到的全路径是 java_package ,而 grpc 标准的全路径是 package,这是合理的
误会了。reflection拿到的是package，但是客户端（不一定是Java，还可能是Postman或者grpcurl）用grpc和package调用不通tri。
贴一下 Idl 把 ，然后再说明一下用的是 stub 还是 reflection模式，方便的话提个 demo 的链接上来看看
Provider用的是stub，tri的。序列化方式是protobuf。 Consumer有tri-stub、原生grpc-stub（Java和Golang），也有reflection（Postman和grpcurl）
idl和demo，我整理一下。
贴一下 Idl 把 ，然后再说明一下用的是 stub 还是 reflection模式，方便的话提个 demo 的链接上来看看
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之类。
猜测，问题的关键在于，对于protobuf，生产者与消费者的进程间桥梁是package，各自进程stub的xxx_package与package相互衔接。如果是golang调用java项目，需要历经go_package -> package -> package -> java_package。而dubbo注册到nacos上的不是package，而是java_package，就使得这个桥梁没有接上。
猜测，问题的关键在于，对于protobuf，生产者与消费者的进程间桥梁是package，各自进程stub的xxx_package与package相互衔接。如果是golang调用java项目，需要历经go_package -> package -> package -> java_package。而dubbo注册到nacos上的不是package，而是java_package，就使得这个桥梁没有接上。
对于 pb 来说, 实际的请求path 是 package，在java 测 stub模式下所支持的 path 也是 package，虽然包路径是 java_package，go 侧同理，但是对于服务发现来说，这个可能得考虑一下到底注册 java_package 还是 package
是的，对于3.1.x来说是这样的。而3.2.x，使用grpcurl 127.0.0.1的方式也不行，说明这个版本从package -> java_package这个桥梁也没有接上。
是的，对于3.1.x来说是这样的。而3.2.x，使用grpcurl 127.0.0.1的方式也不行，说明这个版本从package -> java_package这个桥梁也没有接上。
3.2x 默认关闭了内置服务，需要按需打开内置的反射服务，grpcurl 需要通过反射拿到 metadata 才可以访问
猜测，问题的关键在于，对于protobuf，生产者与消费者的进程间桥梁是package，各自进程stub的xxx_package与package相互衔接。如果是golang调用java项目，需要历经go_package -> package -> package -> java_package。而dubbo注册到nacos上的不是package，而是java_package，就使得这个桥梁没有接上。
对于 pb 来说, 实际的请求path 是 package，在java 测 stub模式下所支持的 path 也是 package，虽然包路径是 java_package，go 侧同理，但是对于服务发现来说，这个可能得考虑一下到底注册 java_package 还是 package
请问，目前服务能够自己声明按照package做服务注册和发现么？