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

参考文章：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 | 详情\|示例代码\|订阅者\|删除

Start with the linked Dubbo3 application-level service discovery article and the @DubboReference example. Compare its described registration and lookup flow with the reported dubbo-spring-boot-starter 3.1.8 and Nacos results. Done means the article or related documentation clearly explains how the provider application is located and why the DemoService entries still appear.

Written by the indexing model from the issue text.