《Apache Dubbo微服务开发从入门到精通》——迁移到 Dubbo3——二、 迁移到应用级服务发现（1） https://developer.aliyun.com/article/1223591
3) Consumer端升级过程
对于2.x的消费者实例，它们看到的自然都是2.x版本的提供者地址列表。
对于3.x的消费者，它具备同时发现2.x与3.x提供者地址列表的能力。在默认情况下，如果集群中存在可以消费的3.x的地址，将自动消费3.x的地址，如果不存在新地址则自动消费2.x的地址。Dubbo3提供了开关来控制这个行为：
dubbo.application.service-discovery.migration支持通过-D以及全局配置中心两种方式进行配置。
接下来，我们就具体看一下，如何通过双订阅模式（APPLICATION_FIRST）让升级到3.x的消费端迁移到应用级别的地址。在具体展开之前，先明确一条消费端的选址行为：对于双订阅的场景，消费端虽然可同时持有2.x地址与3.x地址，但选址过程中两份地址是完全隔离的：要么用2.x地址，要么用3.x地址，不存在两份地址混合调用的情况，这个决策过程是在收到第一次地址通知后就完成了的。
下面，我们看一个APPLICATION_FIRST策略的具体操作过程。
首先，提前在全局配置中心Nacos配置一条配置项（所有消费端都将默认执行这个选址策略）：
紧接着，升级消费端到3.x版本并启动，这时消费端读取到APPLICATION_FIRST配置后，执行双订阅逻辑（订阅2.x接口级地址与3.x应用级地址）
至此，升级操作就完成了，剩下的就是框架内部的执行了。在调用发生前，框架在消费端会有一个“选址过程”，注意这里的选址和之前2.x版本是有区别的，选址过程包含了两层筛选：
• 先进行地址列表（ClusterInvoker）筛选（接口级地址or应用级地址）
• 再进行实际的provider地址（Invoker）筛选。
ClusterInvoker筛选的依据，可以通过MigrationAddressComparator SPI自行定义，目前官方提供了一个简单的地址数量比对策略，即当应用级地址数量==接口级地址数量满足时则进行迁移。
注：
其实FORCE_INTERFACE、APPLICATION_FIRST、FORCE_APPLICATION控制的都是这里的ClusterInvoker类型的筛选策略。
