开篇陈词
正如标题所言，这是一个真实存在的业务场景。在微服务体系的发展迭代进程中，会出现注册中心切换的状况，典型的例子就是从zookeeper迁移到nacos。
最近在面试时，经常用这个场景来考察候选人（涉及RPC、分布式，场景比较开放），但能完整描述出来的人很少，于是整理一篇文章分享。
面对这类场景的思考方式
首先得弄清楚这道题要考察什么，理清楚思路。可以从几个方面去思考：
- 明确Dubbo是什么。它是一个RPC服务开发框架，用于解决微服务架构下的服务治理与通信问题。大部分人都能说出来。
- 弄清楚RPC是什么，以及它的核心框架是怎样的。应该熟练掌握其核心架构（如下图，甚至都没把心跳机制画出来），绝大多数人也能回答上来。
Dubbo注册中心迁移：四步实现平稳过渡" />
接下来才是考虑注册中心的迁移。可以重点从业务方面去考虑：
- 迁移过程中能不能停机？也就是服务的可用性要求是怎样的。
- 服务的规模有多大？比如提供者和服务消费者的数量分别是多少，需不需要分批迁移。
- 是否有第三方服务依赖？如果有的话，第三方是否能支持新的注册中心，如果不能，该怎么办？
以上这些疑问，最好在回答之前确认清楚，因为在不同的业务背景下，技术方案的设计可能大不相同。实际面试中发现大家很容易忽略这一点，一定要留意。
另外，如果能考虑到更细节的技术问题，比如“新旧注册中心支持的协议是否一致、元数据格式是否一致、新注册中心的容量是否充足、如何进行监控维护”等问题，会更加出彩。
从业务视角探讨如何迁移
要是迁移过程中允许停机，而且服务规模比较小，可以考虑“一口气干完”，直接在停机期间把所有服务提供者和消费者的注册中心换成新的，比如游戏行业中经常遇到的停机维护。多说一句，现在游戏行业的复杂度基本转移到客户端了，服务端的架构往往比较简单，常见的“分区”等策略都是为了降低架构的复杂度。
但要是不允许停机，而且服务规模比较大，那就得考虑平滑迁移的方案了，互联网行业基本都是这类情况。常用且稳妥的方案其实很简单，就四个步骤（建议先思考一下，再看答案）：
- 双注册（服务提供者同时向新旧注册中心注册）：
Dubbo注册中心迁移：四步实现平稳过渡" />
- 双消费（服务消费者同时拉取新旧注册中心的服务提供者元数据，采用负载均衡调用，常用RoundRobin轮询策略）：
Dubbo注册中心迁移：四步实现平稳过渡" />
- 单消费（服务消费者不再连接旧注册中心，只从新注册中心获取服务提供者元数据并进行调用）
Dubbo注册中心迁移：四步实现平稳过渡" />
- 单注册（服务提供者不再向旧注册中心注册服务。在做这一步之前，必须确保旧注册中心中的服务消费者都不存在了）
Dubbo注册中心迁移：四步实现平稳过渡" />
通过这种方式，就能在服务可用性不受影响的前提下切换注册中心（也就是平滑迁移），是不是很简单？
还有很多其他方案，比如nacos - sync方案，其实本质上是类似的，不同之处在于新旧注册中心本身做了元信息的同步，业务操作的负担更小些，这种方式在基础建设成熟的互联网企业中更常用。
最后，如果有第三方服务依赖，而且对方的服务提供者不支持新注册中心，那么这个第三方服务要继续使用旧的注册中心（其他我们能控制的服务，使用新的注册中心），这种情况一般出现在大型公司中，这时候要考虑跨团队的协作和推动。
扩展信息
Dubbo服务的多注册中心配置方式，可以参考https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/registry/multiple-registry/：
Dubbo注册中心迁移：四步实现平稳过渡" />
后记
好的架构通常都是简单的，大家遇到问题千万别想得太复杂。要是一下子看不明白，就顺着最本质的原理一步步梳理，最终会豁然开朗，发现“不过如此”罢了。
相关文章
