全方位对比Zookeeper、Eureka、Nacos、Consul和Etcd

本文介绍了五个常用的招生中心，并比较了它们的流程和原理。对于面试和技术选拔都非常有用。

关于招生中心，在写这篇文章之前我对ETCD有比较深入的了解，但是我对Zookeeper和其他招生中心的了解很少，我想知道ETCD和Zookeeper是否适合作为招生中心我什至没有想到。关于它。

经过大约两周的研究，我发现除了ETCD和Zookeeper之外，常用的注册中心还有Eureka、Nacos、Consul。

下面，我们简单讨论一下这些常用招生中心的异同，以方便您后续的技术选择。

注册中心基本概念

| 什么是注册中心？

招生中心具有三个主要作用。

服务提供者（RPC服务器）：启动时向注册中心注册自己的服务，并定期向注册中心发送心跳报告，报告其生存状态。

服务消费者（RPC客户端）：启动时，从注册中心订阅服务，并将注册中心返回的服务节点列表缓存在本地内存中，并与RPC服务器建立连接。

服务注册中心（Registry）：用于存储RPC服务器的注册信息。当RPC服务器节点发生变化时，注册表同步变化，RPC客户端更新本地内存中缓存的服务节点列表。

最后，RPC客户端根据负载均衡算法从本地缓存的服务节点列表中选择RPC服务器并发起调用。

| 注册中心需要实现功能

根据招生中心原则说明，招生中心必须实现以下功能：如果有问题，请直接发布图片。

注册中心基础扫盲

如果您已经了解这些知识，请随意跳过它，因为它主要用于阅读和写作。

CAP 理论

CAP理论是分布式架构中的一个重要理论。

一致性：所有节点同时拥有相同的数据。

可用性：确保所有请求都得到答复，无论成功还是失败。

分区容错性：系统中信息的丢失或故障不影响系统的继续运行。

关于你对P的理解，我认为如果整个系统的某个特定部分挂了或者宕机了，并不会影响整个系统的运行或者使用，但是当特定系统的某个特定节点的时候，可用性就是一个问题了。意思是挂起来。不影响系统接受或发出请求的能力。

获得所有CAP 是不可能的。这就是为什么你只得到两个：

如果C是第一个需求，那么它会影响A的性能，因为它需要数据同步。否则，请求的结果将会不同，但数据同步需要更长的时间，从而降低了这段时间内的可用性。

如果A是第一个需求，只要服务存在，请求就会被成功接受，但不保证返回的结果。这是因为数据完整性流程无法在分布式部署中快速运行。线。

当一致性和可用性同时满足时，作为分布式的单点和基础核心的分区的容错性就变得很难保证。

分布式系统协议

完整性协议算法主要有Paxos、Raft、ZAB。

Paxos算法是Leslie Lamport于1990年提出的一种消息传递完整性算法。基于Paxos协议的数据同步与传统主备方式最大的区别在于，Paxos需要的数据不到一半。成功的通信可确保持续的服务可用性而不会丢失数据。

Raft 是斯坦福大学的Diego Ongaro 和John Ousterhout 设计的一种易于理解的共识算法。 Raft 算法已经有十几种语言的实现框架，其中比较出名的一种，Google 的Kubernetes 也使用了etcd。作为他的服务发现框架。

与Paxos 相比，Raft 侧重于易于理解和实现。如果至少有一半的节点是健康的，Raft 就可以提供服务。

ZooKeeper原子广播（ZAB，ZooKeeper原子消息广播协议）是ZooKeeper实现分布式数据一致性的核心算法。

ZAB利用了Paxos算法，与Paxos算法不同，Paxos算法是专门为ZooKeeper设计的原子广播协议，用于支持崩溃恢复。

常用注册中心

这里主要介绍五个常用的注册中心：Zookeeper、Eureka、Nacos、Consul、ETCD。

| Zookeeper

这其中有趣的是，国内很多Dubbo场景都使用Zookeeper来完成注册中心的功能，尽管官方并没有说是注册中心。

当然，这有很多历史原因，但我们不会再回到这里。 ZooKeeper是一个非常经典的服务注册中心中间件。在国内环境中，由于Dubbo框架的影响，大多数情况下Zookeeper被认为是最合适的基于RPC服务框架的注册中心。

随着Dubbo框架的不断发展和优化，以及包括RPC框架在内的各种招生中心组件的诞生，现代招生中心已经逐渐放弃了ZooKeeper。

ZooKeeper在常用的开发集群环境中仍然发挥着非常重要的作用。在Java系统上，大多数集群环境都依赖ZooKeeper来管理服务的每个节点。

Zookeeper 如何实现注册中心

Zookeeper充当服务注册中心，允许多个服务提供者组成集群，并允许服务消费者通过服务注册中心获取特定的服务访问地址（IP+端口），为你的提供者提供访问权限。

如下所示：

每当部署服务提供者时，都必须将其服务注册到Zookeeper : /{service}/{version}/{ip:port} 中的特定路径。

例如，如果HelloWorldService部署在两台机器上，那么Zookeeper上会创建两个目录。

/HelloWorldService/1.0.0/100.19.20.01:16888

/HelloWorldService/1.0.0/100.19.20.02:16888

这个解释有点令人困惑，但是下面的图片更容易理解。

在Zookeeper中，注册一个服务实际上会创建一个Zookeeper znode节点，其中存储了服务的IP、端口、调用方法（协议、序列化方法）等。

这个节点是由服务提供者（发布服务时）创建的，以便服务消费者能够获取该节点内的信息，从而定位服务提供者的实际网络拓扑并知道如何调用它，它起着最重要的作用。

下面简要描述RPC服务注册/发现过程。

当服务提供者启动时，其服务名称和IP地址会向配置中心注册。

当您第一次调用Service时，会通过注册中心查找对应Service的IP地址列表，并缓存在本地以供后续使用。

当消费者调用服务时，不再请求注册中心，而是直接使用负载均衡算法从IP列表中选择服务提供者的服务器来调用服务。

当其中一台服务提供商的服务器出现故障或离线时，相应的IP 将从服务提供商的IP 列表中删除。同时，注册中心将新的服务IP地址列表发送至服务消费者机器，并缓存在消费者机器上。

如果某个服务的所有服务器都离线，则该服务也会离线。

同样，当服务提供者的服务器上线时，注册中心将新的服务IP地址列表发送到服务消费者机器，并缓存在消费者本地机器上。

服务提供者可以将服务消费者的数量作为线下服务的依据。

Zookeeper提供了“心跳检测”功能。定期向各个服务提供者发送请求（实际上是建立长套接字连接）。如果长时间没有响应，服务中心就判定该服务商被“挂掉”。删除”。

例如，如果机器100.100.0.237 宕机，Zookeeper 上的唯一路径将是/HelloWorldService/1.0.0/100.100.0.238:16888。

Zookeeper的Watch机制实际上是一种组合推拉模型。

服务消费者监听相应的路径（/HelloWorldService/1.0.0）。当路径上的数据发生任务变化（增加或减少）时，Zookeeper仅将事件类型和节点信息发送给相关客户端。如果包含特定的更改，事件本身就会变得轻量级，这就是推送部分。

收到变更通知的客户端必须自行拉取变更数据。这是拉动部分。

Zookeeper 不适合作为注册中心

ZooKeeper作为分布式协作服务非常好，但不适合作为服务发现服务。对于服务发现服务，即使结果包含虚假信息也比没有好。

因此，如果你向注册中心查询服务列表，注册中心返回几分钟前的注册信息是可以接受的，但服务直接宕机不可用是不可接受的。

然而，使用zk 时，会出现主节点由于网络故障而失去与其他节点的连接的情况。其余节点重新选举领导者。

问题是leader选举耗时太长（30-120秒），选举期间整个zk集群变得不可用，导致选举期间注册服务瘫痪。

在云部署中，zk集群很有可能因为网络问题而失去主节点。不过，虽然服务最终可以恢复，但选举时间过长造成的长期不登记现象却令人难以容忍。

因此，作为招生中心，可用性要求比一致性更重要。

在CAP模型中，Zookeeper遵循整体一致性（CP）原则。这意味着访问Zookeeper的请求总是会产生一致的数据结果，但如果机器离线或崩溃，则无法保证服务可用性。

那么Zookeeper为什么不使用最终一致性（AP）模型呢？Zookeeper依赖的核心算法是ZAB，所以一切都是为了实现强一致性。

虽然这在分布式协调系统中是没问题的，但当在注册中心或服务发现场景中使用Zookeeper 为分布式协调服务提供的一致性保证时，实际上是不合适的。

| Eureka

Eureka 架构图：

上面的照片看起来很复杂吗？这是一个简化版本。

Eureka 特点：

可用性（AP原则）：Eureka的设计遵循AP原则，这意味着只要有一个Eureka仍然可用，就保证一个Eureka集群有注册的服务可用，但提供的信息可能不是最新的。不保证强一致性）（性别）。

分布式架构：Eureka Server可以运行多个实例来构建集群。与ZooKeeper 的领导者选举过程不同，Eureka Server 使用点对点通信。

它是一个分布式架构，没有主/从区别，所有对等点都是平等的。为了提高可用性，节点必须相互注册。每个节点必须添加一个或多个指向其他节点的有效serviceUrl。每个节点都可以被认为是其他节点的副本。

自动请求切换：如果集群环境中某个特定的Eureka服务器宕机，一旦宕机的服务器恢复正常，Eureka客户端请求会自动切换到新的Eureka服务器节点。

节点间操作复制：当一个节点开始接受客户端请求时，所有操作都会在节点之间进行复制，并将请求复制到Eureka Server当前已知的所有其他节点上。

自动注册心跳：当一个新的Eureka Server节点启动时，它首先尝试从邻居节点获取所有注册列表信息并完成初始化。

Eureka Server 通过getEurekaServiceUrls() 方法检索所有节点，并通过心跳合约定期更新它们。

自动下线：默认情况下，如果Eureka Server在一定时间内（默认30秒）没有收到某个服务实例的心跳，Eureka Server会从该实例注销（默认90秒，eureka.instance.custom配置租约到期持续时间（以秒为单位）。

保护模式：如果Eureka Server节点在短时间内丢失大量心跳，则该节点进入自我保护模式。

除了上述特点外，Eureka还具有自我保护机制。如果15分钟内85%以上的节点没有心跳成功，则Eureka判定客户端与注册中心之间存在网络故障。

此时，会出现以下情况：

Eureka 不再从注册表中删除因长时间未收到心跳而过期的服务。

Eureka仍然可以接受新的服务注册和查询请求，但它不与其他节点同步（即保证当前节点保持可用）。

一旦网络稳定，当前实例的新注册信息将同步到其他节点。

了解了Eureka的核心概念、自我保护机制以及集群内的工作原理之后，我们来梳理一下Eureka的整个工作流程。

Eureka Server已启动成功，正在等待服务器注册。当集群在启动过程中进行配置时，集群之间通过复制的方式定期同步注册中心，每个Eureka Server都拥有完整且独立的服务注册中心信息。

Eureka Client启动时，会访问注册中心，根据配置的Eureka Server地址注册服务。

Eureka Client每隔30秒向Eureka Server发送一次心跳请求，以证明客户端服务是健康的。

如果Eureka Server在90秒内没有收到Eureka Client心跳，注册中心会认为该节点失效，并下线该实例。

当Eureka Server统计到单位时间内有大量不发送心跳的Eureka客户端时，判断网络可能出现异常，进入自我保护机制。这可以确保不发送心跳的客户端不会被排除在外。

当Eureka Client心跳请求恢复正常时，Eureka Server自动退出自我保护模式。

Eureka Client定期从注册中心全量或增量地检索服务注册中心，并将检索到的信息缓存在本地。

当调用服务时，Eureka客户端首先从其本地缓存中查找被调用的服务。如果您无法获取它，请首先从注册中心更新您的注册表，然后将其与本地缓存同步。

Eureka Client获取目标服务器信息并发起服务调用。

当Eureka Client程序终止时，会向Eureka Server发送取消请求，Eureka Server会从注册表中删除该实例。

分析Eureka的工作原理，可以明显感受到Eureka设计的巧妙，完美地解决了注册中心的稳定性和高可用性。

为了保证招生中心的高可用性，Eureka容忍数据的非强一致性。服务节点之间的数据可能不一致，客户端和服务器之间的数据可能不一致。适合跨多个机房、对招生中心服务可用性要求高的使用场景。

| Nacos

Nacos 致力于帮助您发现、配置和管理微服务。 Nacos 提供简单易用的功能集，帮助您快速实现动态服务发现、服务配置、服务元数据和流量管理。

Nacos 帮助您更敏捷、更轻松地构建、交付和管理微服务平台。 Nacos 是一个服务基础设施，用于构建以“服务”为中心的现代应用架构（例如微服务范式、云原生范式等）。

Nacos 主要特点如下：

服务发现和服务健康监控：

Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI或独立代理TODO注册服务后，服务消费者可以使用DNS TODO或HTTPAPI搜索和发现服务。

Nacos 为您的服务提供实时健康检查，并阻止来自不健康主机或服务实例的请求。 Nacos支持传输层（PING或TCP）和应用层（HTTP、MySQL、用户自定义等）的健康检查。

针对复杂云和网络拓扑环境（VPC、边缘网络等）的服务健康检查，Nacos 提供两种健康检查模式：代理上报模式和服务器端主动检测模式。 Nacos 还提供集成的健康检查仪表板，帮助您根据健康状况管理服务可用性和流量。

动态配置服务：

动态配置服务允许您从外部集中、动态地管理所有环境的应用程序和服务配置。

动态配置消除了配置更改时重新部署应用程序和服务的需要，使配置管理更加高效和敏捷。

集中配置管理可以轻松实现无状态服务，并让您能够灵活地按需扩展服务。

Nacos 提供了简单易用的UI（控制台示例演示）来帮助您管理所有服务和应用程序的配置。

Nacos还提供了一套开箱即用的配置管理功能，包括配置版本跟踪、金丝雀发布、一键回滚配置、客户端配置更新状态跟踪等，让您可以更安全地管理生产环境中的配置。降低与配置更改相关的风险。

动态DNS服务：

动态DNS服务支持加权路由，可以更轻松地为数据中心内网实现中间层负载均衡、更灵活的路由策略、流量控制以及简单的DNS解析服务。

动态DNS 服务还使得通过DNS 协议实现服务发现变得更加容易，从而消除了与供应商专有服务发现API 耦合的风险。

Nacos 提供了一些简单的DNS API TODO 来帮助您管理关联域名和可用服务的IP:PORT 列表。

总结一下：

Nacos由阿里巴巴开源，支持基于DNS和基于RPC的服务发现。

Nacos的招生中心同时支持CP和AP，您可以根据需要将不同的招生中心迁移到Nacos。想。

除了服务注册发现之外，Nacos还支持服务的动态配置。简而言之，Nacos=Spring Cloud 注册中心+ Spring Cloud 配置中心。

| Consul

Consul是HashiCorp发起的一个开源工具，用于实现分布式系统的服务发现和配置。

与其他分布式服务注册和发现解决方案相比，Consul 的解决方案具有内置的服务注册和发现框架、分布式一致性协议实现、健康检查、键/值存储和多数据中心解决方案，更多的是“”。一站式”解决方案。必须依赖其他工具（例如ZooKeeper）。

Consul是用Go语言编写的，这使得它相对容易使用。因此，它天生就是可移植的（支持Linux、Windows和Mac OS Seam Fit）。

Consul 的调用过程：

Producer启动时，会向Consul发送POST请求，告诉Consul它的IP和端口。

当Consul收到生产者的注册后，它会每隔10秒（默认）向生产者发送一次健康检查请求，以检查生产者是否健康。

当消费者向生产者发送GET 方法请求/api/address 时，它首先从Consul 中检索存储服务IP 和端口的临时表，从该表中检索生产者的IP 和端口，然后发送GET 方法请求。去做。 /api/地址。

该临时表每10 秒更新一次，并且仅包含通过健康检查的生产者。

Consul 主要特征：

CP模型使用Raft算法保证强一致性，但不保证可用性。

支持服务注册与发现、健康检查、KV存储功能。

支持多个数据中心可以避免单个数据中心出现单点故障。它的部署必须考虑网络延迟、分片等。

Consul支持安全服务通信，可以为服务生成和分发TLS证书，以建立相互的TLS连接。

支持http和DNS协议接口。

提供官方Web管理界面。

多数据中心：这是为了了解Consul的多数据中心是如何实现的。

Consul 支持开箱即用的多个数据中心。这意味着用户不必担心构建额外的抽象层来将其业务扩展到多个区域。

在上图中，有两个通过互联网互连的数据中心。需要注意的是，为了提高通信效率，只有服务器节点参与数据中心间的通信。

在单个数据中心中，Consul 被分为两个节点：客户端和服务器（所有节点也称为代理）。服务器节点存储数据，客户端负责健康检查并向服务器转发数据请求。

一个服务器节点有一个leader和多个follower，leader节点向follower同步数据。建议服务器数量为3 或5。当Leader断开连接时，会启动选举机制，产生新的Leader。

集群中的Consul 节点通过八卦协议维护成员关系。这意味着节点知道集群中当前有哪些节点以及这些节点是客户端还是服务器。

单数据中心谣言协议同时使用TCP 和UDP 通信，两者均使用端口8301。跨数据中心八卦协议还使用TCP 和UDP 通信（使用端口8302）。

集群内数据读写的请求可以直接发送到服务器，也可以通过客户端使用RPC转发到服务器。如果允许数据延迟，读请求最终也会到达领导节点。当在常规服务器节点上完成时，集群内的所有数据读取、写入和复制都通过TCP 端口8300 完成。

| ETCD

etcd 是一个用Go 编写的分布式、高可用、一致的键/值存储系统，用于提供可靠的分布式键/值存储、配置共享、服务发现等功能。

ETCD 特点：

易于使用：基于HTTP+JSON的API使得与curl一起使用变得很容易。

易于部署：采用Go语言编写，跨平台，易于部署和维护。

强一致性：Raft算法的使用充分保证了分布式系统数据的强一致性。

高可用性：容错。假设您的集群有n 个节点。即使(n-1)/2 个节点发生故障，服务也会继续。

持久化：数据更新后，通过WAL格式保存到磁盘，支持快照。

快速：每个实例支持每秒1000次写入操作，最终写入性能达到10000QPS。

安全性：可选的SSL 客户端身份验证机制

ETCD 3.0：除了上述功能外，还支持gRPC通信和监控机制。

ETCD 框架主要分为四个部分：

HTTP服务器：用于处理用户提交的API请求，以及来自其他etcd节点的同步和心跳信息请求。

Store：用于处理etcd支持的各种功能，例如索引数据、改变节点状态、监控和反馈、事件处理等。

理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。
Raft：Raft 强一致性算法的具体实现，是 etcd 的核心。
WAL：Write Ahead Log（预写式日志），是 etcd 的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd 就通过 WAL 进行持久化存储。
WAL 中，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。

通常，一个用户的请求发送过来，会经由 HTTP Server 转发给 Store 进行具体的事务处理，如果涉及到节点的修改，则交给 Raft 模块进行状态的变更、日志的记录，然后再同步给别的 etcd 节点以确认数据提交，最后进行数据的提交，再次同步。

注册中心对比&选型

| 注册中心对比

如下图：

服务健康检查：Euraka 使用时需要显式配置健康检查支持；Zookeeper、Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。

多数据中心：Consul 和 Nacos 都支持，其他的产品则需要额外的开发工作来实现。

KV 存储服务：除了 Eureka，其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。

CAP 理论的取舍：

Eureka 是典型的 AP，Nacos 可以配置为 AP，作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。
而 Zookeeper、Etcd、Consul 则是 CP 类型牺牲可用性，在服务发现场景并没太大优势。

Watch 的支持：Zookeeper 支持服务器端推送变化，其它都通过长轮询的方式来实现变化的感知。

自身集群的监控：除了 Zookeeper 和 Nacos，其它几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的。

Spring Cloud的集成：目前都有相对应的 boot starter，提供了集成能力。

| 注册中心选型

关于注册中心的对比和选型，其实上面已经讲的非常清楚了，我给出一些个人理解：

关于 CP 还是 AP 的选择：选择 AP，因为可用性高于一致性，所以更倾向 Eureka 和 Nacos；关于 Eureka、Nacos 如何选择，哪个让我做的事少，我就选择哪个，显然 Nacos 帮我们做了更多的事。
技术体系：Etcd 和 Consul 都是 Go 开发的，Eureka、Nacos、Zookeeper 和 Zookeeper 都是 Java 开发的，可能项目属于不同的技术栈，会偏向选择对应的技术体系。
高可用：这几款开源产品都已经考虑如何搭建高可用集群，有些差别而已；
产品的活跃度：这几款开源产品整体上都比较活跃。

尽信书则不如无书，因个人能力有限，难免有疏漏和错误之处，如发现bug或者有更好的建议，欢迎批评指正，不吝感激。

作者及来源：楼仔 石杉的架构笔记
#以上关于全方位对比Zookeeper、Eureka、Nacos、Consul和Etcd的相关内容来源网络仅供参考，相关信息请以官方公告为准！