1.案件阐述

如图：dubbo注册的服务，分组名称一直是【DEFAULT_GROUP】

2. 福尔摩斯附身，查找真凶

有强迫症的我总想让这个group 参数在nacos中生效，于是顺藤摸瓜，似乎找到了真正的“凶手”。

找到Dubbo服务注册相关的类,根据控制台日志，找到了o.a.dubbo.registry.nacos.NacosRegistry 通过debug可以看到，请求参数只有一个url对象，他包含了一个group参数，但是它注册的服务的分组名称，并不是这个group的值。 继续深挖，这个void registerInstance(String var1, Instance var2)方法又是怎么回事。我们看到了什么，没有任何取值和判断，直接传参Constants.DEFAULT_GROUP,一个枚举 接下来我们看到的是registerInstance方法的重载，它对groupName也没有做任何修饰 既然如此，我们做个大胆的操作，把这个groupName的值改了 结果我们得到了什么，这不就是我们想要的结果吗✌

3. 总结

dubbo也算是成熟的RPC框架了，我想这肯定不是BUG，那为什么会这样设计呢？从配置来看，dubbo的group参数有很多，那是否因为使用group的场景和含义不同，所以需要区分开来，就把nacos设计的group忽略掉了呢？希望知道的同学能不吝赐教，多谢！虽然nacos设计的groupName没有生效，但是在serviceName上却出现了参数中的group,难道真的是dubbo改变了分组的设计？

精彩链接

评论可见，请评论后查看内容，谢谢！！！
 您阅读本篇文章共花了：