apache
[Feature] Include the cluster information and the corresponding SOCKS5 proxy address in the URL
Pre-check
- [X] I am sure that all the content I provide is in English.
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
Apache Dubbo Component
Java SDK (apache/dubbo)
Descriptions
Some of our Dubbo projects have to be deployed in two different clusters for certain reasons. To enable mutual calls between these clusters, I want to include the cluster information and the corresponding SOCKS5 proxy address in the URL. This way, when a Dubbo consumer detects a call to a different cluster, it can route the request through the proxy.
Related issues
No response
Are you willing to submit a pull request to fix on your own?
- [X] Yes I am willing to submit a pull request on my own!
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Are the existing Dubbo routing rules inadequate for your scenario? https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/tasks/traffic-management/ Can you give me an example ？
Are the existing Dubbo routing rules inadequate for your scenario? https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/tasks/traffic-management/ Can you give me an example ？
I believe the existing solution cannot meet my requirements. The services registered with the registry should use intranet addresses within the cluster. This causes network issues when making cross-cluster requests. We need SOCKS5 for forwarding. Currently, Dubbo's NettyClient supports SOCKS5 configuration, but it is global. However, I only want my cross-cluster services to use SOCKS5. @wcy666103
@ShenFeng312 I think a potential solution can be : Reads a custom flag (e.g., is_remote_cluster_call=true) from the service URL on the consumer side. When this flag is present, it dynamically sets the SOCKS5 proxy configuration for that specific RPC request. This approach bypasses the global configuration and ensures only your cross-cluster services use the SOCKS5 proxy, keeping your local cluster traffic untouched.
is_remote_cluster_call=true
I think what we can do better is to identify it through some additional markers, such as a cluster ID (this cluster ID is a physical identifier representing differences at the network layer). If the consumer and provider use the same cluster ID, we can access directly. Otherwise, we may need to obtain the corresponding cluster’s SOCKS5 server address from the URL for access. Of course, since the SOCKS5 address could be a list, we can also delegate this to the user to extend, for example, by retrieving it from any configuration center. @ArjunDixit1
That's a much better approach. Using a clusterId is a much more efficient way to handle this in a scalable multi-cluster architecture now that I think of it. Ill be happy to work on it @ShenFeng312
Glad to see you’re interested in this! I’m not a member of this community, so I can’t assign the issue to you directly. You may want to CC the relevant maintainers so they can assign it. I had actually worked on this feature before, but couldn’t contribute the code due to work reasons. If you have any questions while working on it, I’ll be happy to help.@ArjunDixit1 I’ve mentioned @zrlw here to loop them in