Dubbo3 应用级服务发现设计的疑问

[412165137lzh]

参考文章：https://cn.dubbo.apache.org/zh-cn/blog/2023/01/30/dubbo3-%E5%BA%94%E7%94%A8%E7%BA%A7%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%E8%AE%BE%E8%AE%A1/

前言：看这篇文章的时候，有一些疑问，想和各位各位大佬一起讨论讨论 （1）这篇文章中描述了dubbo2在注册实例的时候，每个service都会注册一条实例信息，注册信息太多导致性能问题 （2）dubbo3给出了解决方案，就是类似springcloud，每个提供者实例只会注册一次（不论有实现了多少service接口），并且每个实例只会保存精简数据（ip+port），地址以应用名为粒度做聚合

我有两个问题： （1）dubbo3的优化方案令人费解，消费者在消费的时候，是通过@DubboReference注解来进行RPC调用的（参考代码如下），也就是说消费者只知道service接口定义，不知道提供者的应用名，那么消费者是怎么去注册中心找到指定应用名？我连应用名都找不到，还怎么获得生产者的IP端口呢？

@DubboReference
private DemoService demoService;

@RequestMapping("/test")
@ResponseBody
public String test() throws Exception {
    String result = demoService.sayHello("hello!!!!!!!!!!!!!!!!");
    return result;
}

（2）我写了个demo，版本是dubbo-spring-boot-starter:3.1.8，为什么我的提供者在注册到nacos的时候，sevice接口还是会注册到nacos，不是说dubbo3是优化版本吗，怎么我看还是dubbo2的注册模式呢？

服务名	分组名称	集群数目	实例数	健康实例数	触发保护阈值	操作
providers:com.lzh.dubbo.dubbodemolzh.dubbo.api.DemoService::	DEFAULT_GROUP	1	1	1	false	详情|示例代码|订阅者|删除
providers:com.lzh.dubbo.dubbodemolzh.dubbo.api.DemoService2::	DEFAULT_GROUP	1	2	2	false	详情|示例代码|订阅者|删除
DubboDemoLzhApplication	DEFAULT_GROUP	1	1	1	false	详情|示例代码|订阅者|删除

[AlbumenJ]

1. 基于服务自省，走 Metadata 存储获取 interface 到 appname 的映射
2. 目前 3.x 的版本都是双注册双订阅的模式，保证最高的兼容性