两大注册中心比较（Zookeeper,Eureka）

简介

Eureka是一款由Netflix提供的开源的服务注册和发现的产品，并能够提供相应的Java封装。在实现的时候，节点之间相互平等，部分注册中心的节点挂掉或者没有及时的被注册中心发现，也不会影响集群的正常的运转，即使集群只剩下一个节点存活，也可以提供正常的服务发现功能。哪怕是所有的服务注册点都挂了，Eureka Clients(客户端）上也会缓存服务调用的信息。这就保证了微服务之间的互相调用足够的健壮。

Zookeeper（以下简称ZK）主要是为大型的分布式计算提供开源的分布式配置服务，同步服务和命名注册。是hadoop项目中的一个子项目，用来控制集群的数据。同时部分场景下也会用它作为Service发现解决方案。

对比

从两大注册中心的应用场景上看，都是为大型的分布式场景提供服务注册和发现，还有部分数据的功能。提到分布式系统，我们就肯定要说一下著名的CAP(C-数据一致性，A-服务可用性，P-服务对网络分区故障的容错性）定理。在任何的分布式系统中都不可能同时满足，最多只能同时满足两个。

Zookeeper

ZK是基于CP模式设计的，任何时刻对ZK的访问请求得到一致的数据结果，同时系统需要对网络分区故障有一定的容错性，但是他不会保证每次服务请求的可用性。而且，我们从实际的应用场景中，可以看到使用ZK获取服务列表的时候，如果Zookeeper正在选择主节点，或者ZK集群中半数以上的机器不可用的时候，ZK不在提供服务发现和注册功能。所以说，ZK不能保证服务可用性。

但是，我们也在这个过程中找到ZK的有点，就是在大部分的分布式环境周宁，尤其是涉及到数据存储的场景，数据的一致性应该是首要位置，而这恰恰是ZK设计成CP的主要原因。但是对于服务发现的场景来说，情况就不一样了：针对于同一个服务，即使注册中心的不同节点保存的服务提供着的信息不同，但是并不能影响服务之间的调用和发现的功能，因此，在服务发现而言，服务的可用性就相对于数据的一致性就更加重要了，所以一定要设计成AP模式。

Eureka

在Netflix涉及Eureka时，就是遵循的AP原则，采取C/S模式，Eureka Server可以运行多个实例来构建集群，解决集群的淡点问题，但不同于ZK的选举机制，Eureka Server更多采取的是一种Peer to Peer对等通信。这是一种去中心的结构，无Master/Slave区分，每一节点都是对等的，并不限制哪个节点必须作为客户端和服务端。所以，在这种架构中，通过节点之间的互相注册提供了高可用性。

如果某台Server宕机，Client的请求会自动切换到新的Server节点，当宕机的服务器重新恢复之后，Eureka会再次将其纳入到服务器的集群管理中。当节点开始请求的时候时，所有的操作都会进行replicateToPeer（节点间复制）操作，将请求复制到其他Eureka server当前所知的所有节点上。

一个新的Server节点启动后，会首先尝试从邻近节点获取所有实例注册表信息，完成初始化。Server通过getEurekaServiceUrls()方法获取所有的节点，并且会通过心跳续约的方式定期更新。默认配置下，如果Server在一定时间内没有接收到某个服务实例的心跳，Eureka Server将会注销该实例（默认为90秒，通过eureka.instance.lease-expiration-duration-in-seconds配置）。当Server节点在短时间内丢失过多的心跳时（比如发生了网络分区故障），那么这个节点就会进入自我保护模式。

总结

ZK基于CP，不保证高可用性，如果ZK正在选主，或者ZK集群半数以上的机器 不可用，那么分布式系统中其他节点的数据会暂时无法获取到数据。

Eureka基于AP，能保证高可用，即使所有机器都挂掉，也能够拿到本地的缓存数据，进行服务之间的尝试沟通，作为注册中心，其实配置是不经常变动的，只有发版和机器出现故障的时候才会变。对于不经常改动配置的来说，CP模式的Eureka就不太合适了，而AP遇到的问题是，可以牺牲一定程度的一致性来保证可用性，即返回旧数据，缓存数据。

所以理论上Eureka是更适合注册中心。而现实环境中大部分项目也可能使用ZK，因为集群规模程度并未达到CP模式的需求，同时基本上也不会出现遇到作为注册中心的机器一半以上都挂掉的情况。

本文地址：https://blog.csdn.net/qq_33363716/article/details/107554090