028-86261949

当前位置:首页 > 技术交流 > 微服务注册中心 ZooKeeper、Eureka、Consul 、Nacos 对比

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

2021/04/19 15:59 分类: 技术交流 浏览:0

前言:

     随着系统服务技术变迁,越来越多的系统采用微服务架构,将原本的系统拆分为多个独立运行部署运维的服务。因此引入专用的组件,用来管理存储服务信息,譬如提供者 url 串、路由信息等,类似于目录服务的作用,提供服务的注册,发现,续约等功能。

    服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的。

更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。

CAP理论:

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

  • 一致性(Consistency) (所有节点在同一时间具有相同的数据)
  • 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
  • 分隔容错(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

CAP理论的核心是:一个分布式系统不可能很好的满足一致性,可用性和分区容错性这三个需求。

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

 

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

 

如果满足一致性C和可用性A,那么分区容错就很难保证了,也就是单点,也是分布式的基本核心。

 

原则三大类:

CA:单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。

CP:满足一致性,分区容错性系统,通常性能不是特别高。(Zookeeper、Consul)

AP:满足可用性,分区容错性的系统,通常可能对一致性要求低一些。(Eureka)

 

 主流注册中心:

 

Apache Zookeeper -> CP

在zookeeper中,进行服务注册,实际上就是在zookeeper中创建了一个znode节点,该节点存储了该服务的IP、端口、调用方式(协议、序列化方式)等。该节点承担着最重要的职责,它由服务提供者(发布服务时)创建,以供服务消费者获取节点中的信息,从而定位到服务提供者真正网络拓扑位置以及得知如何调用。

存在问题:

   在使用 Zookeeper 获取服务列表时,如果此时的 Zookeeper 集群中的 Leader 宕机了,该集群就要进行 Leader 的选举,又或者 Zookeeper 集群中半数以上服务器节点不可用(如三个节点,其他两个节点检测到另一个节点已经挂掉,此时需要重新选举leader节点),那么将无法处理该请求。在选举未完成的情况下无法提供服务,因此zookeeper适用于对数据性有强烈要求的系统。一般情况下,系统的可用性需求比重较大。于消费者而言,能够正常使用会带来更好的用户体验。

Spring Cloud Eureka -> AP

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则,Eureka Server可通过多实例的集群,解决单点问题,同时集群中各实例互相注册提高可用性,每个实例节点添加一个或多个有效节点指向其他节点,相互之间可进行数据同步,每个节点都可视为其他节点的副本,这是一种去中心话的设计思想,从而提高分区容错性与高可用性。

默认情况下,如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳(默认周期为30秒),Eureka Server 将会注销该实例(默认为90秒, eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置)。

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

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

 

  1. Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务;
  2. Eureka仍然能够接受新服务注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用);因此可在服务注册时,注册到所有的eureka服务,即便其他服务出现问题,也可保证当前可用的eureka服务拥有完整最新的列表。
  3. 当网络稳定时,当前实例新注册的信息会被同步到其它节点中;

 

Consul:

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

Consul Template

Consul,默认服务调用者需要依赖Consul SDK来发现服务,这就无法保证对应用的零侵入性。

所幸通过Consul Template,可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置(比如nginx的upstream),这样对于服务调用者而言,只需要配置一个统一的服务调用地址即可。

 

Consul强一致性(C)带来的是:

服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功

Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

Eureka保证高可用(A)和最终一致性:

服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功

当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。

Nacos:

  Nacos是阿里开源的,Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos,只需要先下载 Nacos 并启动 Nacos server,Nacos只需要简单的配置就可以完成服务的注册发现。

 

Nacos除了服务的注册发现之外,还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。

 

Nacos = Spring Cloud eureka + Spring Cloud config。

#标签:ZooKeeper,Eureka,Consul,Nacos,Java