eureka和ZooKeeper的区别

背景

在这边文章 中,我们将用我们在实践中遇到的问题来说明,为什么使用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就是我们想要的!

原文地址:https://www.cnblogs.com/u013533289/p/11629059.html

时间: 2024-10-18 13:42:40

eureka和ZooKeeper的区别的相关文章

Eureka与Zookeeper的区别

作为服务注册中心,Eureka比Zookeeper好在哪里 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性P是在分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡. 因此 Zookeeper保证的是CP Eureka则是AP. Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是zk

eureka 和zookeeper 区别 优势【转】

作为服务注册中心,Eureka比Zookeeper好在哪里 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡.在此Zookeeper保证的是CP, 而Eureka则是AP. 4.1 Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但

Eureka的工作原理以及它与ZooKeeper的区别

1.Eureka 简介: Eureka 是 Netflix 出品的用于实现服务注册和发现的工具. Spring Cloud 集成了 Eureka,并提供了开箱即用的支持.其中, Eureka 又可细分为 Eureka Server 和 Eureka Client. 1.基本原理 上图是来自eureka的官方架构图,这是基于集群配置的eureka: - 处于不同节点的eureka通过Replicate进行数据同步 - Application Service为服务提供者 - Application

Eureka对比Zookeeper、CAP定理

eureka对比Zookeeper: Zookeeper在设计的时候遵循的是CP原则,即一致性,Zookeeper会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举,问题在于,选举leader的时间太长:30~120s,且选举期间整个Zookeeper集群是不可用的,这就导致在选举期间注册服务处于瘫痪状态,在云部署的环境下,因网络环境使Zookeeper集群失去master节点是较大概率发生的事情,虽然服务能够最终恢复,但是漫长的选举时间导致

Eureka与zookeeper

Eureka的优势 1.在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程:客户端请求会自动切换到新的Eureka节点:当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中:而对于它来说,所有要做的无非是同步一些新的服务注册信息而已.所以,再也不用担心有"掉队"的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了.Eureka甚至被设计用来应付范围更广的网络分割故障,并实现"0"

Springcloud 的Eureka和ZooKeeper比较

关于CAP理论,可以去看看阮一峰的文章[http://www.ruanyifeng.com/blog/2018/07/cap.html] C(一致性)A(可用性)P(分区容错性) ZooKeeper: zookeeper保证了cp(一致性.分区容错性),但是作为服务注册中心,我们可以容忍注册中心返回的是几分钟以前的注册信息.但是服务中心却必须保证可用性, 即服务注册中心对于高可用性的需求高于一致性.对于可用性,zookeeper有一个leader选举方案.当master主节点宕机与其他节点失去联

Eureka 与 ZooKeeper(一)

CAP理论:c 强一致性 a 可用性 p 分区容错性 ZooKeeper遵循的是CP,  Eureka  则是AP. Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举.问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个

Eureka比Zookeeper好在哪里?

Eureka遵守AP,Zookeeper遵守CP RDBMS(oracle/mysql.sqlServer) ====> ACID, 关系型数据库遵循ACID原则: NoSQL(redis/mongodb)====> CAP 一.ACID的介绍 ACID分别为: 原子性(Automicity):事务里面的所有操作,要么全部做完,要么全不做:事务成功的条件是事务里面的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚: 一致性(Consistency):数据库要一直处于一致的状态,事务

【Eureka篇三】Eureka比Zookeeper好在哪里?(8)

Eureka遵守AP,Zookeeper遵守CP RDBMS(oracle/mysql.sqlServer) ====> ACID, 关系型数据库遵循ACID原则 NoSQL(redis/mongodb)====> CAP 一.ACID的介绍 原子性(Automicity):事务里面的所有操作,要么全部做完,要么全不做:事务成功的条件是事务里面的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚: 一致性(Consistency):数据库要一直处于一致的状态,事务的运行不会改变数据库