注册中心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能够及时感应到。

分布式锁

加锁就是在Zookeeper上添加临时顺序节点，判断是否是最小节点，如果是最小节点，则无需排队。如果不是最小的，则往后加一个顺序节点，并且向前一个节点添加一个watch监听，线程等待排队，当上一个节点删除后，会通知唤醒这个线程。

通过watch机制唤醒线程的方式比较优雅，避免了羊群效应。

K