dubbo2.7.11自定义负载loadBalance，使用provider中parameters参数标签，发现consumer中Directory拿到List<Invoker<T>>与nacos注册中心不一致

[caofei88]

背景：provider起两个服务，使用parameters参数，consumer中去订阅，发现在Directory拿到List<Invoker>与nacos注册中心不一致
问题定位代码在类DubboCloudRegistry 154行 方法subscribeURLs里面调用
172的这行代码有问题：
List subscribedURLs = this.cloneExportedURLs(subscribedURL, serviceInstances);
拿到的url对象跟nacos中metadata信息不一致， 多次debug执行会产生不一样的结果 （dubbo 2.7.6 2.7.8同样存在）

demo地址见：git@github.com:caofei88/dubbo-spring-cloud-demo.git

这个包里面类  DubboCloudRegistry  
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-dubbo</artifactId>
    <version>2.2.5.RELEASE</version> 
</dependency>

部分provider配置
provider:
filter: tracing
parameters:
dcCode: "dcCode1"

provider:
filter: tracing
parameters:
dcCode: "dcCode2"

[caofei88]

这个bug还是比较严重，希望社区有同学尽快跟踪验证并完成修复

[AlbumenJ]

DubboCloudRegistry is in SCA.
If you use ServiceDiscovery, it is true that parameters not the same in Nacos. ServiceDiscovery will use MetadataService to fetch real URLs.

[caofei88]

DubboCloudRegistry is in SCA.
If you use ServiceDiscovery, it is true that parameters not the same in Nacos. ServiceDiscovery will use MetadataService to fetch real URLs.

`

`上面是nacos注册元数据和代码debug截图，请看下

[theonefx]

你好，我是 sca 这边的同学，你反馈的这个问题之前确实是存在的。
之前的逻辑，是为了提升效率，直接使用clone的方式来创建新的 URL。
在之前的实现中，认为同一个应用的同一个接口，除了ip和端口其他都应该是一致的。这就导致了你现在碰到的这个问题。

最新的实现，参照了 dubbo3 的 revision 机制，会对所有提供的服务计算一个版本号，不再单独使用应用名做分组。应该是能解决这个问题的。

最新的代码已经包含了这部分逻辑，正式版本最近会发布，目前你可以使用 2.2.6-bugfix5-SNAPSHOT 试一下。
期待你的答复。

[CrazyHZM]

See the above reply has been resolved, temporarily close this issue
@caofei88