ZooKeeper、Eureka、Consul 、Nacos微服务注册中心对比

注册中心

前言

服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。

CAP理论

CAP理论是分布式架构中重要理论

关于
P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，

而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP不可能都取，只能取其中2个

原因是
如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。

如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。

再如果，同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了

服务注册中心解决方案

设计或者选型一个服务注册中心，首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案，大致可归为三类：

注1：对于第一类注册方式，除了Eureka这种一站式解决方案，还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制，这在大公司比较常见，但对于小公司而言显然性价比太低。

注2：由于DNS固有的缓存缺陷，本文不对第三类注册方式作深入探讨。

除了基本的服务注册与发现机制，从开发和运维角度，至少还要考虑如下五个方面：

主流注册中心产品

对比项目NacosEurekaConsulCoreDNSZookeeper一致性协议CP+APAPCP—CP健康检查TCP/HTTP/MYSQL/ClientBeatClientBeatTCP/HTTP/gRPC/Cmd—KeepAlive负载均衡策略权重/metadata/SelectorRibbonFabioRoundRobin—雪崩保护有有无无无自动注销实例支持支持不支持不支持支持访问协议HTTP/DNSHTTPHTTP/DNSDNSTCP监听支持支持支持支持不支持支持多数据中心支持支持支持不支持不支持跨注册中心同步支持不支持支持不支持不支持SpringCloud集成支持支持支持不支持不支持Dubbo集成支持不支持不支持不支持支持K8S集成支持不支持支持支持不支持

ApacheZookeeper-CP

与Eureka有所不同，ApacheZookeeper在设计时就紧遵CP原则，即任何时候对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是Zookeeper不能保证每次服务请求都是可达的。

从Zookeeper的实际应用情况来看，在使用Zookeeper获取服务列表时，如果此时的Zookeeper集群中的Leader宕机了，该集群就要进行Leader的选举，又或者Zookeeper集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是Zookeeper设计紧遵CP原则的另一个原因。

但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。

因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的618就是紧遵AP的最好参照）。

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署环境下，因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

SpringCloudEureka-AP

image

SpringCloudNetflix在设计Eureka时就紧遵AP原则（尽管现在2.0发布了，但是由于其闭源的原因，但是目前任然是比较活跃的）。

EurekaServer也可以运行多个实例来构建集群，解决单点问题，但不同于ZooKeeper的选举leader的过程，EurekaServer采用的是PeertoPeer对等通信。这是一种去中心化的架构，无master/slave之分，每一个Peer都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台EurekaServer宕机，EurekaClient的请求会自动切换到新的EurekaServer节点上，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicateToPeer）操作，将请求复制到该EurekaServer当前所知的其它所有节点中。

当一个新的EurekaServer节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。EurekaServer通过getEurekaServiceUrls()方法获取所有的节点，并且会通过心跳契约的方式定期更新。

默认情况下，如果EurekaServer在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），EurekaServer将会注销该实例（默认为90秒，进行自定义配置）。

当EurekaServer节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
当网络稳定时，当前实例新注册的信息会被同步到其它节点中；
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。

Consul：

Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul使用Go语言编写，因此具有天然可移植性（支持Linux、windows和MacOSX）。

Consul内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等），使用起来也较为简单。

Consul遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功；在leader挂掉了之后，重新选举出leader之前会导致Consul服务不可用。