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

Comment From: wcy666103

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 ？

Comment From: ShenFeng312

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

Comment From: ShenFeng312

@AlbumenJ @chickenlj

Comment From: ArjunDixit1

@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.

Comment From: ShenFeng312

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