不同注册中心之间的差异

Nacos & Eureka & Zookeeper

Nacos、Eureka 和 Zookeeper 都可以实现分布式注册中心框架。

Eureka 与 Nacos 底层通过 Raft 协议实现集群产生领导角色。

差异

Zookeeper 采用 CP 保证数据的一致性的问题，原理是采用 ZAB 原子广播协议。当我们 ZK 领导者宕机或出现了故障，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题，整个微服务无法实现通讯（本地有缓存除外）。还有可运行的节点必须满足过半机制，整个 ZK 才可以使用，要不然会奔溃。

Eureka 采用 AP 设计理念架构注册中心，相互注册（你中有我，我中有你），完全去中心化，也就是没有主从之分，只要有一台 Eureka 节点存在整个微服务就可以实现通讯。

Nacos 从 1.0 版本选择 AP 和 CP 混合形式实现注册中心，默认情况下采用 AP 保证服务可用性，CP 形式底层采用 Raft 协议保证数据的一致性问题。如果选择为 AP 模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例。选择 CP 模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。

• 也就是说 Nacos 集群默认采用 AP 方式，当集群中存在非临时实例时，采用 CP 模式。
• Nacos 同时支持服务列表变更的消息推送模式，服务列表更新更加及时