精华内容
下载资源
问答
  • 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本身是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理论指出,一个分布式系统不可能同时满足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

    展开全文
  • ZK和EureKa的区别(CAP理论)

    万次阅读 2018-07-20 10:35:04
    本文作者通过ZooKeeper与Eureka作为 Service发现服务(注:WebServices 体系中的UDDI就是个发现服务)的优劣对比,分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激,但是看得出Knewton在云平台方 面是...
  • 对于CAP不太熟悉的可以查看下面博客 分布式CAP原则与BASE理论 接下来我们从ZK和Eureka 设计实现上一步步分析 ZK服务注册原理(CP) zookeeper可以作为注册中心,也可用于服务治理(zookeeper还有其他用途,例如:...
  • CAP理论&ZK&Eureka

    2018-09-01 17:57:43
    如果我们期待实现一套严格满足ACID(Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性)的分布式事务,很可能的情况就是系统的可用性严格一致性出现冲突。在可用性一致性之间永远无法存在...
  • 写在前面最开始服务之间的调用借助的是域名,域名其实是个好东西,使用起来很方便,但所有调用请求都得走域名解析负载均衡,相对来说性能就差一点,而且这些夹在中间的零部件会演变成性能瓶颈潜在的单点风险。...
  • java Quene区别与底层实现 zookeeperspringcloud eureka区别?
  • 注册中心框架,我们可以选择其中之一,现在面临一个特殊的需求,我们同时存在Eureka和ZK,但是有时候会使用 Eureka,有时候使用ZK,怎么办?首先一点需要明确的是,不管使用哪一个,肯定只能选择其一,不存在说同时...
  • zk,一般来说还好,服务注册发现,都是很快的 eureka,必须优化参数 如果完全按上面默认的时间,整个响应时间会很慢,超过几十秒或两三分钟。 1 在eureka服务增加如下配置,让写缓存同步时间减短 ...
  • 【微服务】EurekaZk

    2018-07-31 17:00:30
    它包括两个组件:Eureka Server和Eureka Client。 一、Server端注册中心 1、引入jar: <!--eureka-server服务端 --> <dependency&amp...
  • Zookeeper Eureka 区别

    2020-11-26 15:13:34
    Zookeeper 是将数据一致性作为设计目标是 CP 的,不保证服务的可用性,当节点 Crash 宕机之后,需要进行 leader 选举,选举过程中,ZK 服务不可用。 对服务注册发现来说, 对数据一致性要求没那么高,但是对可用性...
  • 待补充
  • eureka 注重可用性大于一致性,属于CP zk 相反,注重一致性大于可用性,属于AP 评论
  • 1.Eureka是netflix的一个子模块,也是核心模块之一,Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现故障转移。服务注册与发现对于微服务架构来说是非常重要的,有了服务发现注册,只需要...
  • eureka的工作原理以及与zk的区别

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

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

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

    2019-09-02 22:24:58
    (1)CAP理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)P(分区容错性)。Zookeeper保证的是CP, 而Eureka则是AP。 (2)Zookeeper保证CP 当注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟...
  • Eureka和zookeeper

    2019-09-16 20:46:25
    zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用) 1.当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的信息,但不能容忍直接down掉不可用。也就是说,服务注册...
  • Eureka

    2019-07-30 08:28:07
    也是核心模块之一.Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现故障转移,服务注册与发现对于微服务家规来说非常重要,只要使用服务的标识符,就可以访问到服务,不需要修改配置文件,功能类似...
  • Zookeeper基于ZAP协议实现保证每个节点数据同步的问题,中心化思想集群模式,分为领导跟随者角色。当我们的zk领导因为某种原因宕机的情况下,会自动触发重新选一个新的领导角色,整个选举的过程为了保证数据的一致...
  • eureka和zookeeper对比

    2021-03-24 12:53:03
    Eureka比ZooKeeper相比优势是什么 Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于...
  • 二:为什么要用eureka来做服务注册发现,dubbo对比有什么优势? eureka.png 要说这两者,不得不提一下分布式架构中的CAP理论,即一个分布式框架,只能同时满足C一致性、A可用性、P网络分区容错性这三者中的...

空空如也

空空如也

1 2 3 4 5 ... 8
收藏数 160
精华内容 64
关键字:

zk和eureka