本文主要是介绍注册中心ZK、nameServer、eureka、Nacos介绍与对比，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前言
注册中心的由来
微服务架构是存在着很多跨服务调用，每个服务都存在着多个节点，如果有多个提供者和消费者，当提供者增加/减少或者消费者增加/减少，双方都需要感知发现。所以诞生了注册中心这个中间件。
市面上有很多注册中心，如 Zookeeper、NameServer、Eureka、Nacos，下面我来讲一下它们的特点、应用和区别。
Zookeeper
Zookeeper的存储结构是树形结构，它有四种节点，分别是：
- 持久节点：除非自己删除，否则一直存在。
- 持久顺序节点：加了编号，按添加时间排序。
- 临时节点：Zookeeper会维护一个跟客户端的session，通过心跳存续，如果客户端失去心跳，一段时间后节点的session到期，就会删除节点。
- 临时顺序节点。
特点
- Watch监听器：当客户端向某个节点添加监听，当节点发生变化，Zookeeper会实时通知客户端。
- 节点的名字唯一，不允许重复创建。
强一致性
Zookeeper多节点部署，只要集群中存在超过一半的节点能够正常工作，那么整个集群就能够正常对外服务。
Zookeeper围绕着ZAB协议保障数据的一致性。
ZAB协议里规定，Zookeeper集群中只有一个主节点，其余都是从节点。
所有的写请求都必须先走主节点，主节点写入后，同步给从节点，超过半数的节点返回成功，则返回客户端成功，没有超过一半，则返回客户端失败。
为了提升读的性能，读请求不要求必须请求主节点，从节点也可以读。
如果主节点挂了，那么会进行主节点选举，ZAB协议为了保障一致性，选举期间服务是不可用的，牺牲了一些可用性（CP）。
当主节点挂了，就会开始选举，持有消息最新的节点有资格参加竞选，当最终投票超过半数就会被选为主节点，并通知其他节点。
应用
利用上述这些特点，Zookeeper有用广泛的应用。
Dubbo中的注册中心
当Dubbo provider启动时，会在Zookeeper上的 /dubbo/{serviceName}/providers 节点上添加一个临时节点。
当consumer启动时，会在Zookeeper上的 /dubbo/{serviceName}/consumers 节点下添加一个临时节点，同时添加watcher监听providers节点。
当新增provider节点，consumer通过watcher机制能够马上会收到并本地缓存。
当provider挂了，心跳断开连接时，等临时节点的会话到期会触发节点删除，consumer会收到并本地缓存。
通过watcher机制，当consumer发生了变化，provider能够及时感应到。
这篇关于注册中心ZK、nameServer、eureka、Nacos介绍与对比的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
