开启服务注册模式
Dubbo3 服务发现平滑迁移步骤与原理
https://cn.dubbo.apache.org/zh-cn/blog/2024/05/13/如果从接口级服务发现平滑迁移到应用级服务发现/
全局开关
应用配置（可以通过配置文件或者 -D 指定）dubbo.application.register-mode 为 instance（只注册应用级）、all（接口级+应用级均注册）开启全局的注册开关，配置此开关后，默认会向所有的注册中心中注册应用级的地址，供消费端服务发现使用。
可选值 interface、instance、all，默认是 all，即接口级地址、应用级地址都注册
# 双注册
dubbo.application.register-mode=all
# 仅应用级注册
dubbo.application.register-mode=instance
双注册带来的资源消耗
双注册不可避免的会带来额外的注册中心存储压力，但考虑到应用级地址发现模型的数据量在存储方面的极大优势，即使对于一些超大规模集群的用户而言，新增的数据量也并不会带来存储问题。总体来说，对于一个普通集群而言，数据增长可控制在之前数据总量的 1/100 ~ 1/1000
以一个中等规模的集群实例来说： 2000 实例、50个应用（500 个 Dubbo 接口，平均每个应用 10 个接口）。
假设每个接口级 URL 地址平均大小为 5kb，每个应用级 URL 平均大小为 0.5kb
老的接口级地址量：2000 * 500 * 5kb ≈ 4.8G
新的应用级地址量：2000 * 50 * 0.5kb ≈ 48M
双注册后仅仅增加了 48M 的数据量。
应用级服务发现工作原理
服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP 监听端口。
启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者启动完成。
服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知）。
消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息。
至此，消费者可以接收外部流量，并对提供者发起 Dubbo RPC 调用
服务自省中的关键机制
元数据同步机制
Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对元数据同步有两种具体的可选方案，分别是：
- 内建 MetadataService。（dubbo3）
- 独立的元数据中心，通过中心化的元数据集群协调数据。(dubbo2)
-
内建 MetadataService MetadataService 通过标准的 Dubbo 协议暴露，根据查询条件，会将内存中符合条件的“普通服务”配置返回给消费者。这一步发生在消费端选址和调用前。
-
元数据中心 复用 2.7 版本中引入的元数据中心，provider 实例启动后，会尝试将内部的 RPC 服务组织成元数据的格式同步到元数据中心，而 consumer 则在每次收到注册中心推送更新后，主动查询元数据中心。
注意 consumer 端查询元数据中心的时机，是等到注册中心的地址更新通知之后。也就是通过注册中心下发的数据，我们能明确的知道何时某个实例的元数据被更新了，此时才需要去查元数据中心。
RPC 服务 < - > 应用映射关系
Dubbo 之所以选择建立一套“接口-应用”的映射关系，主要是考虑到 service - app 映射关系的不确定性。一个典型的场景即是应用/服务拆分，如上面提到的配置<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x" />，PC Service 2 是定义于 provider-app-x 中的一个服务，未来它随时可能会被开发者分拆到另外一个新的应用如 provider-app-x-1 中，这个拆分要被所有的 PC Service 2 消费方感知到，并对应用进行修改升级，如改为<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x-1" />，这样的升级成本不可否认还是挺高的。 到底是 Dubbo 框架帮助开发者透明的解决这个问题，还是交由开发者自己去解决，当然这只是个策略选择问题，并且 Dubbo 2.7.5+ 版本目前是都提供了的。其实我个人更倾向于交由业务开发者通过组织上的约束来做，这样也可进一步降低 Dubbo 框架的复杂度，提升运行态的稳定性。