《Apache Dubbo微服务开发从入门到精通》——迁移到 Dubbo3——二、 迁移到应用级服务发现（2） https://developer.aliyun.com/article/1223589
a) 双订阅带来的资源消耗
双订阅不可避免的会增加消费端的内存消耗，但由于应用级地址发现在地址总量方面的优势，这个过程通常是可接受的，我们从两个方面进行分析：
• 双订阅带来的地址推送数据量增长。这点我们在“双注册资源消耗”一节中做过介绍，应用级服务发现带来的注册中心数据量增长非常有限。
• 双订阅带来的消费端内存增长。要注意双订阅只存在于启动瞬态，在ClusterInvoker选址决策之后其中一份地址就会被完全销毁；对单个服务来说，启动阶段双订阅带来的内存增长大概能控制在原内存量的30%~40%，随后就会下降到单订阅水平，如果切到应用级地址，能实现内存50%的下降。
b) 消费端更细粒度的控制
除了全局的迁移策略之外，Dubbo在消费端提供了更细粒度的迁移策略支持。控制单位可以是某一个消费者应用，它消费的服务A、服务B可以有各自独立的迁移策略，具体是用方式是在消费端配置迁移规则：
使用这种方式能做到比较精细迁移控制，但是当下及后续的改造成本会比较高，除了一些特别场景，我们不太推荐启用这种配置方式。
迁移指南官方推荐使用的全局的开关式的迁移策略，让消费端实例在启动阶段自行决策使用哪份可用的地址列表。
4) 迁移状态的收敛
为了同时兼容2.x版本，升级到3.x版本的应用在一段时间内要么处在双注册状态，要么处在双订阅状态。
解决这个问题，我们还是从Provider视角来看，当所有的Provider都切换到应用级地址注册之后，也就不存在双订阅的问题了。
a) 不同的升级策略影响很大
毫无疑问越早越彻底的升级，就能尽快摆脱这个局面。设想，如果可以将组织内所有的应用都升级到3.x版本，则版本收敛就变的非常简单：升级过程中Provider始终保持双注册，当所有的应用都升级到3.x之后，就可以调整全局默认行为，让Provider都变成应用级地址单注册了，这个过程并不会给Consumer应用带来困扰，因为它们已经是可以识别应用级地址的3.x版本了。
如果没有办法做到应用的全量升级，甚至在相当长的时间内只能升级一部分应用，则不可避免的迁移状态要持续比较长的时间。
在这种情况下，我们追求的只能是尽量保持已升级应用的上下游实现版本及功能收敛。推动某些Provider的上游消费者都升级到Dubbo3，这样就可以解除这部分Provider的双注册，要做到这一点，可能需要一些辅助统计工具的支持。
• 要能分析出应用间的依赖关系，比如一个Provdier应用被哪些消费端应用消费，这可以通过Dubbo提供的服务元数据上报能力来实现。
• 要能知道每个应用当前使用的Dubbo版本，可以通过扫描或者主动上报手段。
《Apache Dubbo微服务开发从入门到精通》——迁移到 Dubbo3——二、 迁移到应用级服务发现（4） https://developer.aliyun.com/article/1223586
