opened
YoungHu
username_0
when using dubbo in production env, we found that in specific scenes(register same interface with multiplay group or version)  service register will cause zookeeper output huge data for a long time. the reason is when service export, it will notice all consumers who described the interface but **NOT interface&group or version**. the root reason is dubbo store all of the services or consumers under interfacde node and not split them with group or version. now we forked dubbo source code then did the split operation, want to know if official have any good idea.  

BTW, I did a test and record it in my [CSDN Blog](https://blog.csdn.net/huyong1990/article/details/79988177)
[Design bug] unreasonable design for register dubbo service
issue
created
EdwardLee03
username_1
Good! 👍 
@username_0 你们的解决方案：“修复的方法就是注册和查找服务的时候，有分组的加上一个分组zk节点，这样就能准确找到具体的服务而不是找这个接口下面所有服务。” 如果使用场景改变一下，服务版本有60个，你们的方案是否合理呢。同时，ZK数据结构至少增加一层分组zk节点层，应该需要调整`RegistryDirectory`和`ZookeeperRegistry`实现。

Maybe use the service key (`[group/]interface[:version]`) of service layer of ZooKeeper, not use service instead. So simple adjust the `ZookeeperRegistry.toServicePath(URL)` implementation. @username_4
comment
created
YoungHu
username_0
@username_1 Yeah, our solution is to change the ZookeeperRegistry.toServicePath(URL) implementation, for our company use  `group` more frequent than `version`, so our zk path like this(`interface:group`). for community version, I have two suggestion. the first, change the zk path to `interface:group:version`; the second, don't change zk path, just filter the zk item under `interface` path
comment
created
YoungHu
username_0
But that is not a fully solution, I just resolved the group problem not the version. In my onion, we should a discussion, because this change will affect dubbo service registry and discovery directly.
comment
created
tswstarplanet
username_2
Have this bug been fixed ?
comment
created
beiwei30
username_3
I believe we should visit this issue as early as possible.
comment
created
chickenlj
username_4
I personally don't agree with isolating services with different groups or versions in service discovery level. Currently, Dubbo consumers can only interact with those providers with identically the same group and version, but we may change this behavior soon. For example, let consumer consume providers with version v1 and v2 at the same time, to enable canary deployment or A/B test.
comment
created
beiwei30
username_3
should we postpone this issue?
comment
closed
chickenlj
username_4
issue