精华内容
下载资源
问答
  • 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节点在短时间内丢失过多的客户端时(可能发送了网络故障),那么这个节点将进入自我保护模式,不再注销任何微服务,当网络故障回复后,该节点会自动退出自我保护模式。
    • 自我保护模式的架构哲学是宁可放过一千,决不可错杀一个.
    展开全文
  • eureka的工作原理以及与zk的区别

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

    一、CAP定理介绍

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

    一、eureka的工作原理

    eureka包含两个组件,eureka serve 和eureka client,eureka client是一个Java程序客户端,用于简化和eureka serve的交互。

    • Eureka Server提供服务发现的能力,各个微服务启动时,会通过Eureka Client向Eureka Server进行注册自己的信息(例如网络信息),Eureka Server会存储该服务的信息;
    • 微服务启动后,会周期性地向Eureka Server发送心跳(默认周期为30秒)以续约自己的信息。如果Eureka Server在一定时间内没有接收到某个微服务节点的心跳,Eureka Server将会注销该微服务节点(默认90秒);
    • 每个Eureka Server同时也是Eureka Client(),多个Eureka Server之间通过复制的方式完成服务注册表的同步;
    • Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉,服务消费者依然可以使用缓存中的信息找到服务提供者。

    三、区别

    从eureka工作原理可以看出,eureka client有缓存功能,即使eureka所有的serve都宕掉,仍然能给服务消费者发送服务信息,所以eureka保证了服务可用性,不能保证数据一致性,是一个AP。

    而zk,每当master宕机后,都会进行重新选举,重新选举这个过程(一般几十秒),是不能提供服务的,所以zk不能保证服务一直可用,是CP。

     

    而且,zk在多于一半服务挂掉时会停止提供服务,而 Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪(只要有一台在就可以提供服务)。

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

    作为服务注册中心,Eureka比Zookeeper好在哪里

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

    1 Zookeeper保证CP

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

    zookeeper原理

    zookeeper也可以作为注册中心,用于服务治理(zookeeper还有其他用途,例如:分布式事务锁等)   
    每启动一个微服务,就会去zk中注册一个临时子节点,
    例如:5台订单服务,4台商品服务
    (5台订单服务在zk中的订单目录下创建的5个临时节点)
    (4台商品服务在zk中的商品目录下创建的4个临时接点)
    
    每当有一个服务down机,由于是临时接点,此节点会立即被删除,并通知订阅该服务的微服务更新服务列表
    (zk上有watch,每当有节点更新,都会通知订阅该服务的微服务更新服务列表)
    
    每当有一个新的微服务注册进来,就会在对应的目录下创建临时子节点,并通知订阅该服务的微服务更新服务列表
    (zk上有watch,每当有节点更新,都会通知订阅该服务的微服务更新服务列表)
    
    每个微服务30s向zk获取新的服务列表

     

    2 Eureka保证AP

    Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况: 
    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
    2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用) 
    3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

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

    eureka原理

    每一个微服务中都有eureka client,用于服务的注册于发现 (服务的注册:把自己注册到eureka server) (服务的发现:从eureka server获取自己需要的服务列表) 每一个微服务启动的时候,都需要去eureka server注册 当A服务需要调用B服务时,需要从eureka服务端获取B服务的服务列表,然后把列表缓存到本地,然后根据ribbon的客户端负载均衡规则,从服务列表中取到一个B服务,然后去调用此B服务 当A服务下次再此调用B服务时,如果发现本地已经存储了B的服务列表,就不需要再从eureka服务端获取B服务列表,直接根据ribbon的客户端负载均衡规则,从服务列表中取到一个B服务,然后去调用B服务 微服务,默认每30秒,就会从eureka服务端获取一次最新的服务列表 如果某台微服务down机,或者添加了几台机器, 此时eureka server会通知订阅他的客户端,并让客户端更新服务列表, 而且还会通知其他eureka server更新此信息 心跳检测,微服务每30秒向eureka server发送心跳, eureka server若90s之内都没有收到某个客户端的心跳,则认为此服务出了问题, 会从注册的服务列表中将其删除,并通知订阅它的客户端更新服务列表, 而且还会通知其他eureka server更新此信息 eureka server保护机制,通过打卡开关,可以让eureka server处于保护状态,主要是用于某eureka server由于网络或其他原因,导致接收不到其他微服务的心跳,此时不能盲目的将其他微服务从服务列表中删除。 具体规则:如果一段时间内,85%的服务都没有发送心跳,则此server进入保护状态,此状态下,可以正常接受注册,可以正常提供查询服务,但是不与其他server同步信息,也不会通知订阅它的客户端,这样就不会误杀其他微服务

    3. 总结

    Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”,因为注册服务更重要的是可用性,我们可以接受短期内达不到一致性的状况。不过Eureka目前1.X版本的实现是基于servlet的java web应用,它的极限性能肯定会受到影响。期待正在开发之中的2.X版本能够从servlet中独立出来成为单独可部署执行的服务。

     

    转载于:https://www.cnblogs.com/chihirotan/p/11366394.html

    展开全文
  • 1.本文作者通过ZooKeeper与Eureka作为 Service发现服务(注:WebServices 体系中UDDI就是个发现服务)优劣对比,分享了Knewton在云计算平台部署服务经验。本文虽然略显偏激,但是看得出Knewton在云平台方 面是...
  • Eureka本身是Netflix开源一款提供服务注册发现产品,并且提供了相应Java封装。在它实现中,节点之间相互平等,部分注册中心节点挂掉也不会对集群造成影响,即使集群只剩一个节点存活,也可以正常提供...
  • zookeeper和eureka的区别

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

    2019-09-02 22:24:58
    Zookeeper保证是CP, 而Eureka则是AP。 (2)Zookeeper保证CP 当注册中心查询服务列表时,我们可以容忍注册中心返回是几分钟以前注册信息,但是不能接受服务直接DOWN掉不可用。也就是说,服务注册功能对可用性...
  • Zookeeper Eureka 区别

    2020-11-26 15:13:34
    Zookeeper 是将数据一致性作为设计目标是 CP ,不保证服务可用性,当节点 Crash 宕机之后,需要进行 leader 选举,选举过程中,ZK 服务不可用。 对服务注册发现来说, 对数据一致性要求没那么高,但是对可用性...
  • Eureka和Zookeeper Consul的治理机制的区别? Eureka 服务治理强调的是CAP的AP(可用性和可靠性),而ZK和Consul强调的CP(一致性和可靠性)。 Eureka为了实现服务的更高的可用性牺牲了一定的一致性,在某种情况下...
  • 区别不多,主要是理念不一样 根据互联网架构CAP原则,最多满足2个,或者AP、CP或者AC。 Eureka选择了AP作为出发点,而zk选择了CP作为出发点。 其他区别细节基本都是围绕这两点展开。 ...
  • 由于分区容错性P在分布式系统中事必须要保证,因我们只能在AC之间进行权衡。 (1)Zookeeper保证是CP; (2)Eureka保证是AP; Zookeeper保证是CP 当想注册中心查询服务列表时,我们可以容忍注册中心返回...
  • 当我们的zk领导因为某种原因宕机情况下,会自动触发重新选一个新领导角色,整个选举过程为了保证数据一致性问题,在选举过程中整个zk环境是不可使用可短暂可能无法使用到zk。意味着微服务采用该模式情况...
  • Eureka、Zookeeper、Nacos的区别

    千次阅读 2020-10-10 14:35:36
    Eureka和Zookeeper还有Consul的区别: 答:Eureka遵从AP原则,追求可用性;Zookeeper遵从CP原则,追求一致性; 体现在获取服务注册列表上,当ZK的master挂掉后,会触发选举,选举期间无法从ZK获取服务列表信息,这...
  • eureka zookeeper(zk) 是我经常接触到两个常见注册中心中间件。一般情况,springcloud 项目都会用eureka做为注册中心,kafka用zk做为数据元数据管理注册中心。 二、对比 集群结构: zk是leader ...
  • 一致性保障-CAP原理 服务注册发现时效性 容量 zookeeper 集群中分为1个leader其他机器为follower...保证CP,即一致性,当zk集群中leader挂掉,会重新进行leader选举,在此期间整个集群处于不可用状态,...
  • 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
    前提: 1、为什么将两者进行比较 ... 2、两者主要区别: ...也就是说,服务注册功能对可用性要求要高于一致性。但是zk会出现这样一种情况,当...问题在于,选举leader时间太长,30 ~ 120s, 且选举期间整个zk集...
  • Zookeeper和Eureka的比较

    2020-05-22 16:16:38
    前提:已经对Zookeeper和Eureka的架构特点有所了解 1、为什么将两者进行比较: 两者都可以作为服务注册中心使用,即都可以用于服务发现 (服务治理) 2、两者主要区别: Zookeeper保证CP 当向注册中心查询服务...
  • zookeeper和Eureka的区别

    2020-03-27 18:37:03
    Zookeeper保证是CP, 而Eureka则是AP。 zk那个选举机制中当leader宕机剩下节点就会重新选举leader。一旦选举时间长话在选举期间整个zk集群是不可用,这就导致了在选举期间注册服务瘫痪。 由于网络问题使得zk...
  • dubbo由于是二进制传输,占用带宽会更少 ...dubbo开发难度较大,原因是dubbojar包依赖问题很多大型工程无法解决 ...dubbo注册中心可以选择zk,redis等多种,springcloud注册中心只能用eureka或者自研 ...
  • 一.Spring Cloud Eureka和Zookeeper的区别? CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时...
  • eureka与zookeeper异同

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

    千次阅读 2018-11-23 13:50:29
    当在ZooKeeper节点宕机个数超过一半时和zk集群在选举时,zk是不推荐使用。Zk有心跳机制。 2) Eureka侧重AP设计,强调可用性。Eureka结构peer to peer 点对点,每个节点互为主从,即主节点,又是从节点。每个节点...

空空如也

空空如也

1 2
收藏数 33
精华内容 13
关键字:

eureka和zk的区别