注册中心ZooKeeper、Eureka、Consul 、Nacos对比

一、前言

在微服务的架构中自然少不了注册中心，刚好最近公司新项目架构中在注册中心的选型也进行了激烈的研讨，所以写一篇关于它们之间差异，以便我们日后选择注册中心时有个参考。目前市面上主流的注册中心有ZooKeeper、Eureka、Consul 、Nacos等，所以本文简单讲解各注册中心的差异对比。

注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。也就是我们常说的服务注册与发现

二、CAP原理

在分布式架构中CAP原理是非常重要的理论。

• C-Consistency（一致性） ：某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
• A - Availability（可用性）：非故障的节点在合理的时间内返回合理的响应。
• P - Partition（分区容忍性）：当出现网络分区后，系统能够继续“履行职责”。

理论说明：虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。因此，分布式系统理论上不可能选择 CA （一致性 + 可用性）架构，只能选择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中选择。

三、各注册中心对比

	Zookeeper	Eureka	Nacos	Consul
一致性协议	CP	AP	CP+AP	CP
健康检查	Keep Alive	Client Beat	TCP/HTTP/MYSQL/Client Beat	TCP/HTTP/gRPC/Cmd
负载均衡策略	-	Ribbon	权重/metadata/Selector	Fabio
雪崩保护	无	有	有	无
自动注销实例	支持	支持	支持	不支持
访问协议	TCP	HTTP	HTTP/DNS	HTTP/DNS
监听支持	支持	支持	支持	支持
多数据中心	不支持	支持	支持	支持
跨注册中心同步	不支持	不支持	支持	支持
SpringCloud集成	支持	支持	支持	支持
Dubbo集成	支持	不支持	支持	不支持
K8S集成	不支持	不支持	支持	支持

Zookeeper（CP）

Zookeeper 主要遵循CP原则，即对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

在我们实际应用中，Zookeeper 集群中的 Leader 宕机，那么集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用，那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

Eureka （AP）

Eureka主要遵循AP原则，不过Eureka目前已闭源，但是1.x版本依然很活跃。

Eureka不同于 ZooKeeper，没有Master/Slave之分，采用的是对等通信，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

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

• 心跳通信
  客户端通过每30秒发送一次心跳，通知服务端该实例仍在运行；如果服务器再90秒内未收到续订，则会将实例从其注册表中删除；客户端每30秒可以查找注册服务。
• 自我保护模式
  如果Eureka服务器检测到数量超过预期的注册客户端已以不正当的方式终止了他们的连接，并且同时正等待逐出，则它们将进入自我保存模式。这样做是为了确保灾难性的网络事件不会清除eureka注册表数据，并将其传播到下游的所有客户端。
  任何连续3次心跳续订失败的客户端将被视为不正常的终止，并且将由后台驱逐过程逐出。只有当当前注册表的15％处于此更高状态时，才会启用自我保存。
• Eureka节点网络中断
  1、对等方之间的心跳复制可能会失败，并且服务器会检测到这种情况，并进入自我保护模式以保护当前状态。
  2、注册可能发生在孤立的服务器上，有些客户端可能会反映新的注册，而其他客户端则可能没有。
  3、网络连接恢复到稳定状态后，情况会自动更正。当对等方能够正常通信时，注册信息会自动传输到不具有它们的服务器。

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况。

Nacos（CP+AP）

Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。

在1.0.0正式支持AP和CP两种一致性协议并存。1.0.0重构了数据的读写和同步逻辑，将与业务相关的CRUD与底层的一致性同步逻辑进行了分层隔离。然后将业务的读写（主要是写，因为读会直接使用业务层的缓存）抽象为Nacos定义的数据类型，调用一致性服务进行数据同步。在决定使用CP还是AP一致性时，使用一个代理，通过可控制的规则进行转发。

目前的一致性协议实现，一个是基于简化的Raft的CP一致性，一个是基于自研协议Distro的AP一致性。

参考文章：https://developer.aliyun.com/article/698930

Consul（CP）

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

Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，使用起来也较为简单。

Consul 遵循CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，Raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

注：如果本博文有任何错误和建议，欢迎留言，共同学习，共同进步！