make mapping key unique by add group and version to it

[zrlw]

What is the purpose of the change

fixed #14200

Brief changelog

add group and version to mapping key

Verifying this change

Checklist

• Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Add some description to dubbo-website project if you are requesting to add a feature.
• GitHub Actions works fine on your own branch.
• If this contribution is large, please follow the Software Donation Guide.

[chickenlj]

Hi, woule you like to leave a e-mail here, we would like to invite you to become an Apache Dubbo Committer.

[chickenlj]

I understand the issue in you case in #14200, but I don't think we can change the mapping key directly by adding group and version to it. This is by design (only include service interfice) and change the key would bring breaking change to applications using older versions.

[chickenlj]

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,
Consumer C only invokes com.test.InterfaceXXX of service A, the connection between C and A is allowable, but the connection between C and B is forbidden by firework.
When consumer C created dubbo reference of service A, it will get mapping metadata which mapping key is com.test.InterfaceXXX, of course the result from metadata center has both A and B
Consumer C will try to connect to both A and B to building reference of A (their metadata-type are both local), but it will be always failure because the firework will break down the connection from C to B.

Was Consumer C consuming services of all versions and groups with group="*" and version="*"? Can we just change Cosumer C and tell it to only consume service instances of certain group and version, this can make it simple.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[zrlw]

Hi, woule you like to leave a e-mail here, we would like to invite you to become an Apache Dubbo Committer.

[email protected]

[zrlw]

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,
Consumer C only invokes com.test.InterfaceXXX of service A, the connection between C and A is allowable, but the connection between C and B is forbidden by firework.
When consumer C created dubbo reference of service A, it will get mapping metadata which mapping key is com.test.InterfaceXXX, of course the result from metadata center has both A and B
Consumer C will try to connect to both A and B to building reference of A (their metadata-type are both local), but it will be always failure because the firework will break down the connection from C to B.

Was Consumer C consuming services of all versions and groups with group="*" and version="*"? Can we just change Cosumer C and tell it to only consume service instances of certain group and version, this can make it simple.

Consumer C only consume service A by @DubboReference(group="nameOfServiceA", version="1.0.0")

[zrlw]

I understand the issue in you case in #14200, but I don't think we can change the mapping key directly by adding group and version to it. This is by design (only include service interfice) and change the key would bring breaking change to applications using older versions.

the issue might be alleviated if we catch the RemotingException during the while statement of method ServiceDiscoveryRegistry#subscribeURLs, but it will introduce other issues if parameter timeout might be too long or there are too many services that have the same interface name but the consumer C could not be build connection to them .

[zrlw]

To be compatible with old applications using old version, adding group names for each interface to the metadata of the instance and filtering out mismatched service instances from ServiceDiscoveryRegistry#subscribeURLs is another alternative solution, but it violates the design intention of the application level registration pattern to reduce metadata information.

[chickenlj]

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,
Consumer C only invokes com.test.InterfaceXXX of service A, the connection between C and A is allowable, but the connection between C and B is forbidden by firework.
When consumer C created dubbo reference of service A, it will get mapping metadata which mapping key is com.test.InterfaceXXX, of course the result from metadata center has both A and B
Consumer C will try to connect to both A and B to building reference of A (their metadata-type are both local), but it will be always failure because the firework will break down the connection from C to B.

Was Consumer C consuming services of all versions and groups with group="*" and version="*"? Can we just change Cosumer C and tell it to only consume service instances of certain group and version, this can make it simple.

Consumer C only consume service A by @DubboReference(group="nameOfServiceA", version="1.0.0")

If Consumer C consumes only @DubboReference(group="nameOfServiceA", version="1.0.0") and Service A and Service B have different group or version,

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,

then Consumer C would only call either A or B, depending on which one matches @DubboReference(group="nameOfServiceA", version="1.0.0"), C would not call both A and B.

[zrlw]

The process of creating dubboReference of serivce A:

1. Obtain all application names corresponding to conditions (for nacos: dataId="com.test.InterfaceXXX", group="mapping") from the metadata center.
2. Query all instances under all application names obtained by step 1 from registry center.
3. Loop through all the instances obtained by step 2, if metadata type is local, then connect to the corresponding service to retrieve the metadata. At here, it will try to build connection to service B, after 3 seconds, the reference creation will be failed by RemotingException.

[zrlw]

For each service instance that consumer C has not network access privileges, the method AbstractServiceDiscovery#getRemoteMetadata always try calling getRemoteMetadata 3 times and wait 1 second from each time.

[chickenlj]

3. Loop through all the instances obtained by step 2, if metadata type is local, then connect to the corresponding service to retrieve the metadata. At here, it will try to build connection to service B, after 3 seconds, the reference creation will be failed by RemotingException.

I see the problem in your case here.