精华内容
下载资源
问答
  • 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...

    作为服务注册中心,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在云平台方 面是...
    本文作者通过ZooKeeper与Eureka作为 Service发现服务(注:WebServices 体系中的UDDI就是个发现服务)的优劣对比,分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激,但是看得出Knewton在云平台方 面是非常有经验的,这篇文章从实践角度出发分别从云平台特点、CAP原理以及运维三个方面对比了ZooKeeper与Eureka两个系统作为发布服务的 优劣,并提出了在云平台构建发现服务的方法论。

    背景

    很多公司选择使用 ZooKeeper作为Service发现服务(Service Discovery),但是在构建 Knewton(Knewton 是一个提供个性化教育平台的公司、学校和出版商可以通过Knewton平台为学生提供自适应的学习材料)平台时,我们发现这是个根本性的错误。在这边文章 中,我们将用我们在实践中遇到的问题来说明,为什么使用ZooKeeper做Service发现服务是个错误。

    请留意服务部署环境

    让我们从头开始梳理。我们在部署服务的时候,应该首先考虑服务部署的平台(平台环境),然后才能考虑平台上跑的软件 系统或者如何在选定的平台上自己构建一套系统。例如,对于云部署平台来说,平台在硬件层面的伸缩(注:作者应该指的是系统的冗余性设计,即系统遇到单点失 效问题,能够快速切换到其他节点完成任务)与如何应对网络故障是首先要考虑的。当你的服务运行在大量服务器构建的集群之上时(注:原话为大量可替换设 备),则肯定会出现单点故障的问题。对于knewton来说,我们虽然是部署在AWS上的,但是在过往的运维中,我们也遇到过形形色色的故障;所以,你应 该把系统设计成“故障开放型”(expecting failure)的。其实有很多同样使用AWS的 公司跟我们遇到了(同时有很多 是介绍这方面的)相似的问题。你必须能够提前预料到平台可能会出现的问题如:意外故障(注:原文为box failure,只能意会到作者指的是意外弹出的错误提示框),高延迟与 网络分割问题(注:原文为network partitions。意思是当网络交换机出故障会导致不同子网间通讯中断)——同时我们要能构建足够弹性的系统来应对它们的发生。

    永远不要期望你部署服务的平台跟其他人是一样的!当然,如果你在独自运维一个数据中心,你可能会花很多时间与钱来避免硬件故障与网络分割问题,这 是另一种情况了;但是在云计算平台中,如AWS,会产生不同的问题以及不同的解决方式。当你实际使用时你就会明白,但是,你最好提前应对它们(注:指的是 上一节说的意外故障、高延迟与网络分割问题)的发生。

    ZooKeeper作为发现服务的问题

    ZooKeeper(注:ZooKeeper是著名Hadoop的一个子项目,旨在解决大规模分 布式应用场景下,服务协调同步(Coordinate Service)的问题;它可以为同在一个分布式系统中的其他服务提供:统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目,它 很成熟,有相当大的社区来支持它的发展,而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。

    在分布式系统领域有个著名的 CAP定理(C- 数据一致性;A-服务可用性;P-服务对网络分区故障的容错性,这三个特性在任何分布式系统中不能同时满足,最多同时满足两个);ZooKeeper是个 CP的,即任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就 是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。但是别忘了,ZooKeeper是分布式协调服务,它的 职责是保证数据(注:配置数据,状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性 的了,如果是AP的,那么将会带来恐怖的后果(注:ZooKeeper就像交叉路口的信号灯一样,你能想象在交通要道突然信号灯失灵的情况吗?)。而且, 作为ZooKeeper的核心实现算法 Zab,就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

    作为一个分布式协同服务,ZooKeeper非常好,但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算是 返回了包含不实的信息的结果也比什么都不返回要好;再者,对于Service发现服务而言,宁可返回某服务5分钟之前在哪几个服务器上可用的信息,也不能 因为暂时的网络故障而找不到可用的服务器,而不返回任何结果。所以说,用ZooKeeper来做Service发现服务是肯定错误的,如果你这么用就惨 了!

    而且更何况,如果被用作Service发现服务,ZooKeeper本身并没有正确的处理网络分割的问题;而在云端,网络分割问题跟其他类型的故障一样的确会发生;所以最好提前对这个问题做好100%的准备。就像 Jepsen在 ZooKeeper网站上发布的博客中所说:在ZooKeeper中,如果在同一个网络分区(partition)的节点数(nodes)数达不到 ZooKeeper选取Leader节点的“法定人数”时,它们就会从ZooKeeper中断开,当然同时也就不能提供Service发现服务了。

    如果给ZooKeeper加上客户端缓存(注:给ZooKeeper节点配上本地缓存)或者其他类似技术的话可以缓解ZooKeeper因为网络故障造成节点同步信息错误的问题。 Pinterest Airbnb公 司就使用了这个方法来防止ZooKeeper故障发生。这种方式可以从表面上解决这个问题,具体地说,当部分或者所有节点跟ZooKeeper断开的情况 下,每个节点还可以从本地缓存中获取到数据;但是,即便如此,ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果 ZooKeeper下所有节点都断开了,或者集群中出现了网络分割的故障(注:由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper 会将它们都从自己管理范围中剔除出去,外界就不能访问到这些节点了,即便这些节点本身是“健康”的,可以正常提供服务的;所以导致到达这些节点的服务请求 被丢失了。(注:这也是为什么ZooKeeper不满足CAP中A的原因)

    更深层次的原因是,ZooKeeper是按照CP原则构建的,也就是说它能保证每个节点的数据保持一致,而为ZooKeeper加上缓存的做法的 目的是为了让ZooKeeper变得更加可靠(available);但是,ZooKeeper设计的本意是保持节点的数据一致,也就是CP。所以,这样 一来,你可能既得不到一个数据一致的(CP)也得不到一个高可用的(AP)的Service发现服务了;因为,这相当于你在一个已有的CP系统上强制栓了 一个AP的系统,这在本质上就行不通的!一个Service发现服务应该从一开始就被设计成高可用的才行!

    如果抛开CAP原理不管,正确的设置与维护ZooKeeper服务就非常的困难;错误会 经常发生, 导致很多工程被建立只是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。Knewton平台 很多故障就是由于ZooKeeper使用不当而导致的。那些看似简单的操作,如:正确的重建观察者(reestablishing watcher)、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时,我们确实也遇到过 ZooKeeper的一些经典bug: ZooKeeper-1159 ZooKeeper-1576; 我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现,在于ZooKeeper需要管理与保障所管辖服务 群的Session与网络连接资源(注:这些资源的管理在分布式系统环境下是极其困难的);但是它不负责管理服务的发现,所以使用ZooKeeper当 Service发现服务得不偿失。

    做出正确的选择:Eureka的成功

    我们把Service发现服务从ZooKeeper切换到了Eureka平台,它是一个开 源的服务发现解决方案,由Netflix公司开发。(注:Eureka由两个组件组成:Eureka服务器和Eureka客户端。Eureka服务器用作 服务注册服务器。Eureka客户端是一个java客户端,用来简化与服务器的交互、作为轮询负载均衡器,并提供服务的故障切换支持。)Eureka一开 始就被设计成高可用与可伸缩的Service发现服务,这两个特点也是Netflix公司开发所有平台的两个特色。( 他们都在讨论Eureka)。自从切换工作开始到现在,我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过,在云平台做服务迁移注定要遇到失败;但是我们从这个例子中得到的经验是,一个优秀的Service发现服务在其中发挥了至关重要的作用!

    首先,在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切换 到新的Eureka节点;当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中;而对于它来说,所有要做的无非是同步一些新的服务 注册信息而已。所以,再也不用担心有“掉队”的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障,并实现“0”宕机维护需求。当网络分割故障发生时,每个Eureka节点,会持续的对外提供服务(注:ZooKeeper不会):接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来,就可以实现在同一个子网中(same side of partition),新发布的服务仍然可以被发现与访问。

    但是,Eureka做到的不止这些。正常配置下,Eureka内置了心跳服务,用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服务, 它的“心跳”变得迟缓时,Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能,但是当网络分割故障发生时, 这也是非常危险的;因为,那些因为网络问题(注:心跳慢被剔除了)而被剔除出去的服务器本身是很”健康“的,只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。

    幸运的是,Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注:可能发生了网络故障),那么这个 Eureka节点会进入”自我保护模式“,同时保留那些“心跳死亡“的服务注册信息不过期。此时,这个Eureka节点对于新的服务还能提供注册服务,对 于”死亡“的仍然保留,以防还有客户端向其发起请求。当网络故障恢复后,这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是,同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好,所以这种模式在实践中非常有效。

    最后,Eureka还有客户端缓存功能(注:Eureka分为客户端程序与服务器端程序两个部分,客户端程序负责向外提供注册与发现服务接口)。 所以即便Eureka集群中所有节点都失效,或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下,所有正常的Eureka节点都不对请求产生相应,也没有更好的服务器解决方案来解 决这种问题时;得益于Eureka的客户端缓存技术,消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息,这点很重要。

    Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制,这 样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的,它有独立的客户端程序库,同时提供心 跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是,如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源 的,所有人都能看到与使用这些源代码,这比那些只有一两个人能看或者维护的客户端库要好。

    维护Eureka服务器也非常的简单,比如,切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一个 web-based的图形化的运维界面,在这个界面中可以查看Eureka所管理的注册服务的运行状态信息:是否健康,运行日志等。Eureka甚至提供 了Restful-API接口,方便第三方程序集成Eureka的功能。

    结论

    关于Service发现服务通过本文我们想说明两点:1、留意服务运行的硬件平台;2、时刻关注你要解决的问题,然后决定 使用什么平台。Knewton就是从这两个方面考虑使用Eureka替换ZooKeeper来作为service发现服务的。云部署平台是充满不可靠性 的,Eureka可以应对这些缺陷;同时Service发现服务必须同时具备高可靠性与高弹性,Eureke就是我们想要的!

    补充阅读


    原文链接:Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery
                </div>
    
    展开全文
  • 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掉不可用。也就是说,服务注册功能对可用性...
  • 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-11-26 15:13:34
    主要区别 zookeeper的目标是一个分布式的协调系统,用于进行资源的统一管理,为了满足CP而进行设计。 eureka的目标是一个服务注册发现系统,专门用于微服务的服务发现注册,按照满足AP而进行设计。 Zookeeper ...
  • zookeeper和Eureka的区别

    2020-03-27 18:37:03
    Zookeeper保证是CP, 而Eureka则是AP。 zk那个选举机制中当leader宕机剩下节点就会重新选举leader。一旦选举时间长话在选举期间整个zk集群是不可用,这就导致了在选举期间注册服务瘫痪。 由于网络问题使得zk...
  • 当我们的zk领导因为某种原因宕机情况下,会自动触发重新选一个新领导角色,整个选举过程为了保证数据一致性问题,在选举过程中整个zk环境是不可使用可短暂可能无法使用到zk。意味着微服务采用该模式情况...
  • Eureka 服务治理强调是CAPAP(可用性和可靠性),而ZK和Consul强调CP(一致性和可靠性)。 Eureka为了实现服务更高可用性牺牲了一定一致性,在某种情况下接受故障实际无法维持心跳,也不会丢掉实例具体...
  • eureka zookeeper(zk) 是我经常接触到两个常见注册中心中间件。一般情况,springcloud 项目都会用eureka做为注册中心,kafka用zk做为数据元数据管理注册中心。 二、对比 集群结构: zk是leader ...
  • Eureka、Zookeeper、Nacos的区别

    千次阅读 2020-10-10 14:35:36
    Eureka和Zookeeper还有Consul的区别: 答:Eureka遵从AP原则,追求可用性;Zookeeper遵从CP原则,追求一致性; 体现在获取服务注册列表上,当ZK的master挂掉后,会触发选举,选举期间无法从ZK获取服务列表信息,这...
  • 区别不多,主要是理念不一样 根据互联网架构CAP原则,最多满足2个,或者AP、CP或者AC。 Eureka选择了AP作为出发点,而zk选择了CP作为出发点。 其他区别细节基本都是围绕这两点展开。 ...
  • 一致性保障-CAP原理 服务注册发现时效性 容量 zookeeper 集群中分为1个leader其他机器为follower...保证CP,即一致性,当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
    前提: 1、为什么将两者进行比较 ... 2、两者主要区别: ...也就是说,服务注册功能对可用性要求要高于一致性。但是zk会出现这样一种情况,当...问题在于,选举leader时间太长,30 ~ 120s, 且选举期间整个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 点对点,每个节点互为主从,即主节点,又是从节点。每个节点...
  • 面试总结--20190218

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

空空如也

空空如也

1 2
收藏数 32
精华内容 12
关键字:

zk和eureka的区别