《Apache Dubbo微服务开发从入门到精通》——服务发现与负载均衡——二、 应用级服务发现机制详解（上） https://developer.aliyun.com/article/1224476
3. Proposal
面对这个问题，在Dubbo3架构下，我们不得不重新思考两个问题：
• 如何在保留易用性、功能性的同时，重新组织URL地址数据，避免冗余数据的出现，让Dubbo3能支撑更大规模集群水平扩容？
• 如何在地址发现层面与其他的微服务体系如Kubernetes、Spring Cloud打通？
Dubbo3的应用级服务发现方案设计本质上就是围绕以上两个问题展开。其基本思路是：地址发现链路上的聚合元素也就是我们之前提到的Key由服务调整为应用，这也是其名称叫做应用级服务发现的由来；另外，通过注册中心同步的数据内容上做了大幅精简，只保留最核心的IP、port地址数据。
这是升级之后应用级地址发现的内部数据结构进行详细分析。
对比之前接口级的地址发现模型，我们主要关注橙色部分的变化。
• 首先，在provider实例这一侧，相比于之前每个RPC Service注册一条地址数据，一个provider实例只会注册一条地址到注册中心。
• 其次，在注册中心这一侧，地址以应用名为粒度做聚合，应用名节点下是精简过后的provider实例地址。
应用级服务发现的上述调整，同时实现了地址单条数据大小和总数量的下降，但同时也带来了新的挑战：我们之前Dubbo2强调的易用性和功能性的基础损失了，因为元数据的传输被精简掉了，如何精细的控制单个服务的行为变得无法实现。
针对这个问题，Dubbo3的解法是引入一个内置的MetadataService元数据服务，由中心化推送转为Consumer到Provider的点对点拉取，在这个模式下，元数据传输的数据量将不在是一个问题，因此可以在元数据中扩展出更多的参数、暴露更多的治理数据。
这里我们个重点看消费端Consumer的地址订阅行为，消费端从分两步读取地址数据，首先是从注册中心收到精简后的地址，随后通过调用MetadataService元数据服务，读取对端的元数据信息。在收到这两部分数据之后，消费端会完成地址数据的聚合，最终在运行态还原出类似Dubbo2的URL地址格式。因此从最终结果而言，应用级地址模型同时兼顾了地址传输层面的性能与运行层面的功能性。
以上就是的应用级服务发现背景、工作原理部分的所有内容。
