zookeeper到nacos的迁移实践

本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎star。

技术选型

公司的RPC框架是dubbo，配合使用的服务发现组件一直是zookeeper，长久以来也没什么大问题。至于为什么要考虑换掉zookeeper，并不是因为它的性能瓶颈，而是考虑往云原生方向演进。

云原生计算基金会（CNCF）对云原生的定义是：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

想要落地云原生，关键步骤就是mesh化，当前主要讨论service mesh（服务网格），一句话形象描述service mesh

service mesh是微服务时代的TCP协议

服务网格相对于当前的微服务最明显的优势是下沉基础设置，让服务治理和业务开发分离。

举个简单的例子，如果在微服务架构中想要做好服务治理，不得不引入大量的第三方组件，如限流、熔断，监控，服务发现，负载均衡、链路追踪等等一系列组件，而这些组件大概率需要以jar包的形式被业务代码依赖，甚至不同的开发语言还得维护不同的组件，业务和基础设施耦合让服务治理变得异常困难。

service mesh处理服务间的通信，通常由一系列网格代理组成，对应用程序透明。服务治理中的一切（包括但不限于上述的限流、熔断、监控、服务发现等）都可以下沉到网格代理中。

说了这么多，跟替换zookeeper有什么关系呢？

dubbo的设计中有三大组件：服务提供者（provider），服务消费者（consumer），注册中心（registry）。

provider启动后往registry注册它提供的ip、端口、服务名、方法名等信息，consumer发起调用时通过服务名、方法名从registry查找到对应的ip和端口发起远程调用。

而在云原生体系下的服务注册与发现机制与dubbo的服务注册发现机制有很大区别，云原生是基于容器编排，主流的k8s服务注册发现是基于DNS，也就是通过一个域名查找到一个对应的ip。

这样一来，如果要迁移dubbo服务到云原生体系中就很艰难，有没有一款兼容两种服务注册发现的组件？经过调研nacos就是。

首先nacos和zookeeper一样，提供了传统微服务的注册与发现方式，其次nacos还提供了基于coreDNS的插件DNS-F（DNS filter），DNS-F作为一个代理拦截主机上的DNS请求，如果该服务在nacos上能找到则直接返回注册的ip，否则继续查找DNS。

完成后，我们的service mesh架构大致如下

网格内外的访问策略如下：

• 网格外dubbo -> 网格内dubbo：注册中心
• 网格外dubbo ->