[Bug] When subscribing to the same service from multiple registry centers in Dubbo 3.3.4, subscription relationships are not handled correctly.

[IiiinSea]

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

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

3.3.4

Steps to reproduce this issue

For example: There's a service called com.a.b.QuotaService available in both registry centers "registrySt" and "registryOnline". Now I subscribe to them in my service like this:

@Reference(group = "", registry = "registrySt", interfaceClass = QuotaService.class, check = false, retries = 0, timeout = 3000) private QuotaService quotaServiceSt;

@Reference(group = "", registry = "registryOnline", interfaceClass = QuotaService.class, check = false, retries = 0, timeout = 5000) private QuotaService quotaServiceOnline;

During project initialization and subscription, it goes through a cache logic where the key obtained is "com.a.b.QuotaService" in both cases. This means the first one can initialize properly, but the second one reuses what's in the cache because the key is the same.

What you expected to happen

However, for my use case, these two References should be independent and shouldn't be reused.

Anything else

No response

Are you willing to submit a pull request to fix on your own?

• [ ] 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

[zrlw]

As for me, Dubbo does not yet support multiple registries.

[RainYuY]

I don't understand what you mean. In fact, if two interfaces' group, version, and service name are all the same, they are the same interface. The registry will not treat them as different services.

[IiiinSea]

To give a business scenario example: I may have the same service deployed in both Singapore and Europe, which are registered in different service registries. When I subscribe to them, I want to be able to distinguish between the Singapore service and the European service. When actual business requests come in, the request should either go to Singapore or Europe specifically, rather than being unable to distinguish between them and randomly selecting an IP address.