二、 迁移到应用级服务发现

1. 总体升级方案

总体上来说，在地址注册与发现环节，3.x是完全兼容2.x版本的，这意味着，用户可以选择将集群内任意数量的应用或机器升级到3.x，同时在这个过程中保持与2.x版本的互操作性。

如关心迁移背后工作原理，请参考迁移规则详情与工作原理。

1) 快速升级步骤

简单的修改pom.xml到最新版本就可以完成升级，如果要迁移到应用级地址，只需要调整开关控制3.x版本的默认行为。

升级Provider应用到最新3.x版本依赖，配置双注册开关dubbo.application.register-mode=all（建议通过全局配置中心设置，默认已自动开启），完成应用发布。

升级Consumer应用到最新3.x版本依赖，配置双订阅开关dubbo.application.service-discovery.migration=APPLICATION_FIRST（建议通过全局配置中心设置，默认已自动开启），完成应用发布。

在确认Provider的上有Consumer全部完成应用级地址迁移后，Provider切到应用级地址单注册。完成升级。

以下是关于迁移流程的详细描述。

2) Provider端升级过程详解

在不改变任何Dubbo配置的情况下，可以将一个应用或实例升级到3.x版本，升级后的Dubbo实例会默保保证与2.x版本的兼容性，即会正常注册2.x格式的地址到注册中心，因此升级后的实例仍会对整个集群仍保持可见状态。

同时新的地址发现模型（注册应用级别的地址）也将会自动注册。

通过-D参数，可以指定provider启动时的注册行为

另外，可以在配置中心修改全局默认行为，来控制所有3.x实例注册行为。其中，全局性开关的优先级低于-D参数。

为了保证平滑迁移，即升级到3.x的实例能同时被2.x与3.x的消费者实例发现，3.x实例需要开启双注册；当所有上游的消费端都迁移到3.x的地址模型后，提供端就可以切换到instance模式（只注册应用级地址）。对于如何升级消费端到3.x请参见下一小节。

a) 双注册带来的资源消耗

双注册不可避免的会带来额外的注册中心存储压力，但考虑到应用级地址发现模型的数据量在存储方面的极大优势，即使对于一些超大规模集群的用户而言，新增的数据量也并不会带来存储问题。总体来说，对于一个普通集群而言，数据增长可控制在之前数据总量的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的数据量。

《Apache Dubbo微服务开发从入门到精通》——迁移到 Dubbo3——二、 迁移到应用级服务发现（2） https://developer.aliyun.com/article/1223589