精华内容
下载资源
问答
  • Eureka本身是Netflix开源的一款提供服务注册发现的产品,并且提供了相应的Java封装。在它的实现中,节点之间相互平等,部分注册中心的节点挂掉也不会对集群造成影响,即使集群只剩一个节点存活,也可以正常提供...

    简介

    Eureka本身是Netflix开源的一款提供服务注册和发现的产品,并且提供了相应的Java封装。在它的实现中,节点之间相互平等,部分注册中心的节点挂掉也不会对集群造成影响,即使集群只剩一个节点存活,也可以正常提供发现服务。哪怕是所有的服务注册节点都挂了,Eureka Clients(客户端)上也会缓存服务调用的信息。这就保证了我们微服务之间的互相调用足够健壮。

    Zookeeper主要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。曾经是Hadoop项目中的一个子项目,用来控制集群中的数据,目前已升级为独立的顶级项目。很多场景下也用它作为Service发现服务解决方案。

    对比

    在分布式系统中有个著名的CAP定理(C-数据一致性;A-服务可用性;P-服务对网络分区故障的容错性,这三个特性在任何分布式系统中不能同时满足,最多同时满足两个);

    Zookeeper

    Zookeeper是基于CP来设计的,即任何时刻对Zookeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是它不能保证每次服务请求的可用性。从实际情况来分析,在使用Zookeeper获取服务列表时,如果zookeeper正在选主,或者Zookeeper集群中半数以上机器不可用,那么将无法获得数据。所以说,Zookeeper不能保证服务可用性。

    诚然,在大多数分布式环境中,尤其是涉及到数据存储的场景,数据一致性应该是首先被保证的,这也是zookeeper设计成CP的原因。但是对于服务发现场景来说,情况就不太一样了:针对同一个服务,即使注册中心的不同节点保存的服务提供者信息不尽相同,也并不会造成灾难性的后果。因为对于服务消费者来说,能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下,也好过因为无法获取实例信息而不去消费。(尝试一下可以快速失败,之后可以更新配置并重试)所以,对于服务发现而言,可用性比数据一致性更加重要——AP胜过CP。

    Eureka

    而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。Eureka Server也可以运行多个实例来构建集群,解决单点问题,但不同于ZooKeeper的选举leader的过程,Eureka Server采用的是Peer to Peer对等通信。这是一种去中心化的架构,无master/slave区分,每一个Peer都是对等的。在这种架构中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都可被视为其他节点的副本。

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

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

    什么是自我保护模式?默认配置下,如果Eureka Server每分钟收到心跳续约的数量低于一个阈值(instance的数量(60/每个instance的心跳间隔秒数)自我保护系数),并且持续15分钟,就会触发自我保护。在自我保护模式中,Eureka Server会保护服务注册表中的信息,不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时,该Eureka Server节点就会自动退出自我保护模式。它的设计哲学前面提到过,那就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例。该模式可以通过eureka.server.enable-self-preservation = false来禁用,同时eureka.instance.lease-renewal-interval-in-seconds可以用来更改心跳间隔,eureka.server.renewal-percent-threshold可以用来修改自我保护系数(默认0.85)。

    总结

    ZooKeeper基于CP,不保证高可用,如果zookeeper正在选主,或者Zookeeper集群中半数以上机器不可用,那么将无法获得数据。Eureka基于AP,能保证高可用,即使所有机器都挂了,也能拿到本地缓存的数据。作为注册中心,其实配置是不经常变动的,只有发版和机器出故障时会变。对于不经常变动的配置来说,CP是不合适的,而AP在遇到问题时可以用牺牲一致性来保证可用性,既返回旧数据,缓存数据。

    所以理论上Eureka是更适合做注册中心。而现实环境中大部分项目可能会使用ZooKeeper,那是因为集群不够大,并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。

    展开全文
  • 对于CAP不太熟悉的可以查看下面博客 分布式CAP原则与BASE理论 接下来我们从ZK和Eureka 设计实现上一步步分析 ZK服务注册原理(CP) zookeeper可以作为注册中心,也可用于服务治理(zookeeper还有其他用途,例如:...

     

    著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

    对于CAP不太熟悉的可以查看下面博客

    分布式CAP原则与BASE理论

    接下来我们从ZK和Eureka 设计实现上一步步分析

    ZK服务注册原理(CP)

    zookeeper可以作为注册中心,也可用于服务治理(zookeeper还有其他用途,例如:分布式事务锁等)   

    消费端启动时候会去zookeeper上订阅path(例如:/dubbo/com.test.demo.api/providers)下面的信息,也就是服务提供者列表信息,那么我们就可以基于这个原理来获取某一个服务提供者列表,然后对信息进行过滤加工,并且注册一个监听器,当服务提供者机器增减后,动态更新保存的地址列表。

     

    1.每启动一个微服务,就会去zk中注册一个临时子节点(ZK集群完成一致性确认,保存数据)

    2.服务订阅,拉取服务列表,并注册一个监听(zk的watch机制,不熟悉的可以简单去百度了解下)

    3.每当有一个服务down机或者新的微服务注册进来,由于是临时接点,此节点会立即被删除或者添加一个,并通知订阅该服务(2中注册了监听的服务)的微服务更新服务列表(zk的watch机制,每当有节点更新,都会通知订阅该服务的微服务更新服务列表)

    注:服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复

    ZK为什么是CP?

    当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性(但是也会存在一点点延迟,毕竟需要网络传输和数据拉取处理,一般可能就几十毫秒,很短的时间)。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的(这也就是ZK的缺点之一,牺牲部分的可用性)。

     

    Eureka服务注册原理(AP)

    Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,就算全部挂掉,服务还能通过读取本地缓存的服务列表信息来进行调用,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)(注:前提是服务提供者的ip:port信息没有发生变化)

    除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况: 
    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
    2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用) 
    3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

    因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

     

    1.服务B进行服务注册,并定时发送心跳(根据配置的规则 进行不达标节点下线)

    2.Eureka接收注册信息后, 一是本地注册信息更新(同步);二是将消息广播给其它服务器(异步)

    由此也可以看出 Eureka 是 AP 模型的,优先保障了可用性,事实上大多数注册中心的实现方案都是 AP 模型,只有 ZK 是 CP 模型。事实上,ZK 是分布式协调服务,并不是专门用来进行服务治理的。

    3.服务A定时拉取最新的服务信息并缓存在本地

    基于eureka的实现原理,可以看出它优先保证了可用性,牺牲了数据一致性,但并不是说集群中的数据是不一致的,集群中每个节点的数据同步延迟时间比较长而已,如果使用Eureka默认的配置信息,数据服务A要获取到最新的服务列表信息 延迟可能是几十秒甚至几分钟,因此,线上生产环境往往会对Eureka 进行调优,使发送心跳,拉取服务,定时检查等定时服务间隔时间调短,来达到服务信息延迟降低的目的。 

    总结:

    基于CAP理论来说,很多人说  Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”,因为注册服务更重要的是可用性,我们可以接受短期内达不到一致性的状况。但其实呢,个人认为技术不分优劣,更多的在于适不适合你的项目技术架构,你的服务是需要保证AP还是需要保证CP,能否容忍技术带来的不便之处,综合比较,选取最合适的技术才是最关键的

    展开全文
  • zk和eureka区别

    万次阅读 2019-02-12 17:24:27
    参考资料:https://www.cnblogs.com/snowjeblog/p/8821325.html ... 首先,一项技术被发布出来,被广泛应用,肯定是有道理的,一定有它适合的场景,zk保证的是一致性分区容错性,eureka保证的...

    参考资料:https://www.cnblogs.com/snowjeblog/p/8821325.html
                   https://blog.csdn.net/w1028556865/article/details/81127885

            首先,一项技术被发布出来,被广泛应用,肯定是有道理的,一定有它适合的场景,zk保证的是一致性和分区容错性,eureka保证的是可用性和分区容错性.
            先来分析一下zk做注册中心的场景
                1.zk在生产环境中,如果master宕机,需要时间进行选举(据说30s~120s以上,未求证),在此期间是不能提供服务的注册和发现的(但是好像可以走dubbo的本地缓存,做到服务之间的通讯,也未求证),这一点是忍不了吧,毕竟你干的就是服务发现的活啊.
                2.出现网络分隔的问题,各个zk节点彼此都不能发现对方,zk集群就会GG了,还是忍不了吧
            然后分析一下Eureka
                1.eureka的模式是client和server,各个server之间是相互独立的,不存在leader.不用选举,这一点完胜zk,就算其中一个server宕机了,只要还有一个server或者,client都会把服务注册到这个活着的server上面,等宕机的活过来,就会把最新的一份信息同步给它.
                2.至于网络分隔问题,对Eureka根本没影响
                Eureka在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况: 
                1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
                2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用) 
                3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中
            在默认配置中,Eureka Server在默认90s没有得到客户端的心跳,则注销该实例,但是往往因为微服务跨进程调用,网络通信往往会面临着各种问题,比如微服务状态正常,但是因为网络分区故障时,Eureka Server注销服务实例则会让大部分微服务不可用,这很危险,因为服务明明没有问题。
            为了解决这个问题,Eureka 有自我保护机制,通过在Eureka Server配置如下参数,可启动保护机制
            eureka.server.enable-self-preservation=true
            它的原理是,当Eureka Server节点在短时间内丢失过多的客户端时(可能发送了网络故障),那么这个节点将进入自我保护模式,不再注销任何微服务,当网络故障回复后,该节点会自动退出自我保护模式。
            自我保护模式的架构哲学是宁可放过一千,决不可错杀一个.
            
            参考资料:https://www.cnblogs.com/snowjeblog/p/8821325.html
                            https://blog.csdn.net/w1028556865/article/details/81127885

    展开全文
  • 首先,一项技术被发布出来,被广泛应用,肯定是有道理的,一定有它适合的场景,zk保证的是一致性分区容错性,eureka保证的是可用性分区容错性. 分析一下zk做注册中心的场景 zk在生产环境中,如果master宕机,需要时间...

    首先,一项技术被发布出来,被广泛应用,肯定是有道理的,一定有它适合的场景,zk保证的是一致性和分区容错性,eureka保证的是可用性和分区容错性.

    分析一下zk做注册中心的场景

    • zk在生产环境中,如果master宕机,需要时间进行选举(据说30s~120s以上),在此期间是不能提供服务的注册和发现的(但是好像可以走dubbo的本地缓存,做到服务之间的通讯),这一点是忍不了吧,毕竟你干的就是服务发现的活啊.
    • 出现网络分隔的问题,各个zk节点彼此都不能发现对方,zk集群就会GG了,还是忍不了吧
    • Zab 一致性协议
      ZooKeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab(ZooKeeper Atomic Broadcast,ZooKeeper 原子广播协议)支持崩溃恢复,基于该协议,ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。

    分析一下Eureka

    • eureka的模式是client和server,各个server之间是相互独立的,不存在leader.不用选举,这一点完胜zk,就算其中一个server宕机了,只要还有一个server或者,client都会把服务注册到这个活着的server上面,等宕机的活过来,就会把最新的一份信息同步给它
    • 至于网络分隔问题,对Eureka根本没影响

    Eureka在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

    • Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
    • Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
    • 当网络稳定时,当前实例新的注册信息会被同步到其它节点中
    • 在默认配置中,Eureka Server在默认90s没有得到客户端的心跳,则注销该实例,但是往往因为微服务跨进程调用,网络通信往往会面临着各种问题,比如微服务状态正常,但是因为网络分区故障时,Eureka Server注销服务实例则会让大部分微服务不可用,这很危险,因为服务明明没有问题。为了解决这个问题,Eureka 有自我保护机制,通过在Eureka Server配置如下参数,可启动保护机制,eureka.server.enable-self-preservation=true
    • 它的原理是,当Eureka Server节点在短时间内丢失过多的客户端时(可能发送了网络故障),那么这个节点将进入自我保护模式,不再注销任何微服务,当网络故障回复后,该节点会自动退出自我保护模式。
    • 自我保护模式的架构哲学是宁可放过一千,决不可错杀一个.
    展开全文
  • 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在AC之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP...
  • ZK和EureKa区别(CAP理论)

    万次阅读 2018-07-20 10:35:04
    本文作者通过ZooKeeper与Eureka作为 Service发现服务(注:WebServices 体系中的UDDI就是个发现服务)的优劣对比,分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激,但是看得出Knewton在云平台方 面是...
  • Zookeeper Eureka 区别

    2020-11-26 15:13:34
    主要区别 zookeeper的目标是一个分布式的协调系统,用于进行资源的统一管理,为了满足CP而进行设计。 eureka的目标是一个服务注册发现系统,专门用于微服务的服务发现注册,按照满足AP而进行设计。 Zookeeper ...
  • java Quene区别与底层实现 zookeeperspringcloud eureka区别
  • zookeeper和eureka区别

    2020-05-16 21:14:00
    zookeeper和eureka区别 首先,一项技术被发布出来,被广泛应用,肯定是有道理的,一定有它适合的场景,zk保证的是一致性和分区容错性,eureka保证的是可用性和分区容错性. 先来分析一下zk做注册中心的场景 1.zk在生产...
  • eureka的工作原理以及与zk区别

    千次阅读 2019-05-30 16:26:36
    一、CAP定理介绍 著名的CAP理论指出,一个分布式系统不可能同时满足C(数据一致性)、A(服务可用性)...eureka包含两个组件,eureka serve 和eureka client,eureka client是一个Java程序客户端,用于简化和eureka se...
  • ZooKeeper和Eureka区别

    2019-09-02 22:24:58
    (1)CAP理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)P(分区容错性)。Zookeeper保证的是CP, 而Eureka则是AP。 (2)Zookeeper保证CP 当注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟...
  • 区别不多,主要是理念不一样 根据互联网架构的CAP原则,最多满足2个,或者AP、CP或者AC。 Eureka选择了AP作为出发点,而zk选择了CP作为出发点。 其他区别细节基本都是围绕这两点展开。 ...
  • Zookeeper基于ZAP协议实现保证每个节点数据同步的问题,中心化思想集群模式,分为领导跟随者角色。当我们的zk领导因为某种原因宕机的情况下,会自动触发重新选一个新的领导角色,整个选举的过程为了保证数据的一致...
  • eureka zookeeper(zk) 是我经常接触到的两个常见的注册中心中间件。一般情况,springcloud 项目都会用eureka做为注册中心,kafka用zk做为数据元数据管理注册中心。 二、对比 集群结构: zk是leader ...
  • Eureka 服务治理强调的是CAP的AP(可用性和可靠性),而ZK和Consul强调的CP(一致性和可靠性)。 Eureka为了实现服务的更高的可用性牺牲了一定的一致性,在某种情况下接受故障实际无法维持心跳,也不会丢掉实例具体...
  • Eureka、Zookeeper、Nacos的区别

    千次阅读 2020-10-10 14:35:36
    Eureka和Zookeeper还有Consul的区别: 答:Eureka遵从AP原则,追求可用性;Zookeeper遵从CP原则,追求一致性; 体现在获取服务注册列表上,当ZK的master挂掉后,会触发选举,选举期间无法从ZK获取服务列表信息,这...
  • 一致性保障-CAP原理 ...容量 zookeeper 集群中分为1个leader其他的机器为follower,只有leader能够进行写...保证CP,即一致性,当zk集群中的leader挂掉,会重新进行leader的选举,在此期间整个集群处于不可用状态,...
  • zookeeper和Eureka区别

    2020-03-27 18:37:03
    CAP理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)P(分区容错性)。Zookeeper保证的是CP, 而Eureka则是AP。 zk那个选举机制中当leader宕机剩下的节点就会重新选举leader。一旦选举时间长的话在选举期间...
  • Zookeeper和Eureka的比较

    2020-05-22 16:16:38
    前提:已经对Zookeeper和Eureka的架构特点有所了解 1、为什么将两者进行比较: 两者都可以作为服务注册中心使用,即都可以用于服务发现 (服务治理) 2、两者主要区别: Zookeeper保证CP 当向注册中心查询服务...
  • Eureka和zookeeper都可以提供服务注册与发现的功能,请说说两个的区别? Zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用) 1.当向注册中心查询服务列表时,我们可以容忍注册中心返回的...
  • Zookeeper 保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用) 【1】当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的信息,但不能容忍直接 down 掉不可用。也就是说,...
  • Eureka和Zookeeper的比较

    2020-09-29 16:10:00
    2、两者主要区别: Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。...
  • 由于分区容错性P在分布式系统中事必须要保证的,因我们只能在AC之间进行权衡。 (1)Zookeeper保证的是CP; (2)Eureka保证的是AP; Zookeeper保证的是CP 当想注册中心查询服务列表时,我们可以容忍注册中心返回...
  • 面试总结--20190218

    2019-02-18 20:03:26
    面试总结 上午 问题: 1. spring 使用到的设计模式 2. springboot和spring 区别 3. JVM 类加载原理,怎么加载一个冲突的jar...8. CAP原则(分布式)–zk和eureka区别 9. Lnux操作系统常用命令,(CPU使用量查询)...
  • eureka与zookeeper异同

    2020-08-05 11:34:03
    1.Eureakzookeeper都可以提供服务注册与发现的功能,请说说两个的区别? Zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用), (1)当向注册中心查询服务列表时,我们可以容忍注册中心返回几...

空空如也

空空如也

1 2
收藏数 35
精华内容 14
关键字:

zk和eureka区别