Dubbo实战：四步实现注册中心平滑迁移

 写在前面

如题，这是一个真实存在的业务场景。在微服务体系的迭代过程中，会存在注册中心的切换，典型如从zookeeper迁移到nacos。最近面试中，经常会用该场景来考察候选人（涉及RPC、分布式、场景也足够开放），结果能完整描述出来的人寥寥无几，于是整理一篇文章分享下。遇到这类场景应该如何思考

首先要先弄清楚这道题要考的是什么？捋清楚思路。可以从几个角度来思考：

• 搞清楚Dubbo是什么。它是RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题。大部分人都能答出来。
  
• 搞清楚RPC是什么，以及它的核心框架是怎样的。应熟练掌握其核心的架构（如下图，甚至都没把心跳机制画出来），绝大多数人也能答上来。
  

接下来才是考虑注册中心的迁移。可重点从业务角度考虑：

• 迁移过程中是否可以停机？也即服务的可用性要求是怎样的。
  
• 服务体量有多大？比如提供者和服务消费者的数量分别有多少，是否需要分批迁移。
  
• 是否有第三方服务依赖？若有，第三方是否可以支持新的注册中心，若不能，应该怎么办？
  

以上疑问，最好在回答前先确认清楚，因为在不同的业务背景下，技术方案的设计可能大相径庭。实际面试过程中发现大家很容易忽略这一点，尤其要注意。另外，如果能够考虑到更细节的技术问题，比如“新旧注册中心支持的协议是否一致、元数据格式是否一致、新注册中心的容量是否充足、如何做监控维护”等问题，则会更加亮眼。从业务角度谈谈如何迁移

如果迁移过程中允许停机，而且服务体量比较小，可以考虑“一把梭”，直接在停机期间把所有服务提供者和消费者的注册中心改为新的，比如游戏行业中经常遇到的停机维护。多提一句，现在游戏行业的复杂度基本转移到了客户端，服务端的架构往往比较简单，常见的“分区”等策略都是为了降低架构的复杂度。但如果不允许停机，并且服务体量比较大，那就要考虑平滑迁移的方案了，互联网行业基本都是这一类。常用也稳妥的方案其实很简单，就4个步骤（建议先思考一下，再看答案）： 1. 双注册（服务提供者同时注册到新旧注册中心）：

 2. 双消费（服务消费者同时拉取新旧注册中心的服务提供者元数据，做负载均衡调用，常用RoundRobin轮询策略）：

 3. 单消费（服务消费者不再连接旧注册中心，仅从新注册中心获取服务提供者元数据，并加以调用）

 4. 单注册（服务提供者不再向旧注册中心注册服务。在做这一步前，必须确保旧注册中心中的服务消费者都不存在了）

 通过这种方式，便可以在服务可用性不受影响的前提下切换注册中心（也就是平滑迁移），是不是很简单？还有很多其他的方案，比如nacos-sync方案，其实本质也是类似的，不同的地方在于新旧注册中心本身做了元信息的同步，业务操作的负担更小些，这种方式在基础建设成熟的互联网企业中更为常用。最后，如果还有第三方服务依赖，且对方的服务提供者不支持新注册中心，那么这个第三方服务要继续使用旧的注册中心（其他我们可以控制的服务，使用新的注册中心），一般会在大型公司中出现，这种情况下要考虑跨团队的协作和推动了。扩展信息

Dubbo服务的多注册中心配置方式，可以参见https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/registry/multiple-registry/：

后记

好的架构一般都是简单的，大家遇到问题千万不要想得太复杂。如果一下子看不明白，就顺着最为本质的原理一步步捋，最终会豁然开朗，发现“不过如此”而已。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！