乱弹琴，从zookeeper想到云原生

本文逻辑混乱基本属于想到哪就到那。

zk是我在工作中经常接触的技术框架，做一些技术中间件的时候经常会把它列入选型中。

但是这两年一直火热的云原生，zk显得落寞起来。

云原生技术意在在公有云、私有云和混合云等环境中构建和运行可弹性扩展的应用。云原生包括容器、服务网格、微服务、不可变基础设施和声明式API等。

想要落地云原生，关键步骤就是 mesh化，核心就是service mesh （服务网格）

服务网格：服务间通信的基础设施层

怎么理解服务网格呢？

通俗的比方可以把service mesh当作微服务间的TCP协议

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

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

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

而在云原生体系下的服务注册与发现机制与dubbo的服务注册发现机制有很大区别，云原生是基于容器编排，主流的 k8s 服务注册发现是基于 DNS ，也就是通过一个域名查找到一个对应的ip。由于zookeeper基于ip提供服务注册和发现，面对云原生zk显得招架不住了。

nacos闪亮登场

有关nacos的介绍不多说了网上很齐全，现在思考的是假设一个使用zk很多年的产品项目如何从zookeeper平滑地迁移到nacos上，跟上云原生的浪潮。

网上找了一些方案供参考

方案一双注册模式

将服务注册改为双注册（同时注册到zookeeper与nacos），等所有应用改造完成后再统一切换到nacos

评价：实现简单，但是不全面，一些无人维护的老系统需要去改动可能会导致bug

方案二nacos sync同步方案

Nacos-Sync是一个跨注册中心服务同步组件，支持Zookeeper/Eureka/Consul/Nacos等注册中心间服务同步和迁移。