微服务注册中心，Nacos、Eureka与Zookeeper区别

都可以实现分布式注册中心框架

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

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

Nacos从1.0版本选择AP和CP混合形式实现注册中心，默认情况下采用Ap保证服务可用性，CP形式底层采用Raft协议保证数据的一致性问题。

如果选择为AP模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例。

选择CP模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。

nacos和eureka都是注册中心，都具有各自的负载均衡策略，eureka分为Eureka Server（Eureka服务）和Eureka Client（Eureka客户端），所有Eureka Server 通过Replicate进行数据同步。无论Eureka Client向哪个Eureka Server中注册信息，最终所有Eureka Server中都会存储注册的信息，这些信息都缓存到Eureka Server的本地。
nacos和eureka的范围不同，Nacos的阈值是针对某个具体Service的，而不是针对所有服务的；但Eureka的自我保护阈值是针对所有服务的。nacos支持CP和AP两种；eureka只支持AP。nacos使用netty,是长连接;eureka是短连接，定时发送。
Nacos 致力于发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，以便快速实现动态服务发现、服务配置、服务元数据及流量管理。