Dubbo3.0 全新服务发现模型

应用粒度的服务发现

在 2.x 版本中，Provider 在服务启动时会将本地的接口暴露到注册中心，Consumer 则在服务启动时以接口粒度去订阅服务，同时监听服务列表的变化并获取最新的服务列表。3.x 引入了全新的基于应用粒度的服务发现机制，Consumer 会以应用粒度去监听订阅应用的实例变化。 新模型带来两方面的巨大优势：

• 进一步提升了 Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%）， Dubbo 可支持集群规模步入百万实例层次。
• 打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等，在地址发现层面的互通， 为连通 Dubbo 与其他微服务体系提供可行方案。

元数据注册

在 DubboBootstrap 类的 doStart 启动方法中，会先调用 exportServices 方法把当前应用定义和系统内置的 RPC 服务 依次注册到元数据中心，然后调用 registerServiceInstance 方法将服务实例注册到注册中心

元数据中心是复用 2.7 版本中引入的元数据中心，Provider 实例启动后，会尝试将内部的 RPC 服务组织成元数据的格式注册到元数据中心，而 Consumer 则在每次收到注册中心推送更新后，主动查询元数据中心

当指定的元数据中心为 Nacos 时，会调用 NacosMetadataReport.storeProviderMetadata 将 RPC 服务元数据注册到元数据中心

元数据是存储在Nacos配置中心，dataId 格式为：

{serviceInterface}:{version}:{group}:{side}:{application}

服务发现注册

当指定的注册中心为 Nacos 时，在会调用 NacosServiceDiscovery.doRegister 将应用信息注册到Nacos注册中心，注册中心类型可以通过 RegistryConfig 指定：

RegistryConfig registryConfig = new RegistryConfig("nacos://nacos.dev.office:8848");

注册的服务实例仅仅包含了应用粒度的相关字段，服务名称为应用的名称 dubbo-local-test，注册详细数据如下：

服务自省映射 - Service Name Mapping 

在3.x中注册中心只存储了应用级的信息，而不包含具体的 RPC 服务信息，Consumer 引用一个RPC 服务的配置示例如下：

<dubbo:reference interface="DemoService" provided-by="dubbo-local-test"/>

相比2.x版本，在引用服务时需要通过 provided-by 额外指定 RPC 服务所在的应用名称，原因是注册中心不知道任何 RPC 服务的具体信息，以上的服务引用方式会带来几个问题：

• 从2.x升级到3.x需要大量的改造完善 provided-by 配置
• 当一个 RPC 服务从应用A迁移到应用B时，需要所有的 Consumer 方更改 provided-by 配置

为了解决这些问题，dubbo 在3.x中设计了一套 RPC 服务到应用名的映射关系，以尝试在 Consumer 自动完成 RPC 服务到 provider 应用名的转换

具体的做法是配置中心会存储一份 RPC服务 <-> 应用的映射关系，Provider 向配置中心注册 RPC服务 <-> 应用的映射关系，Consumer 从配置中心读取应用对应的 RPC 服务列表。

映射关系的注册动作发生在 RPC 服务完成向元数据中心注册之后，通过调用 ServiceNameMapping.map 方法完成 url 和服务的映射关系注册

当元数据中心为 Nacos 时，存储映射数据的 dataId 为 RPC 服务名称，内容为应用名称：

在 AbstractServiceNameMapping 中 getServices 方法提供了根据 URL 获取应用列表的方法，优先根据手动指定的 provided-by 参数上获取应用名称，其次从缓存中获取，最后通过元数据中心获取

当元数据中心为 Nacos 时，会从配置中心获取应用列表，dataId 为 RPC 服务名，group 为 mapping