eureka跨服务_Spring Cloud（四）：公司内部，关于Eureka和zookeeper的一场辩论赛

点击蓝字关注我们

大家好，我是杰哥 ，最近，公司将要为一个新项目选择一款合适的注册中心，用于分布式服务间的协调工作。由于，部门内部针对选择Eureka还是Zookeeper出现了分歧。于是乎，项目经理组织了一场Eureka和Zookeeper的辩论赛！ 听说还蛮激烈的，一起来看看吧~

一 赛前

领导讲话

项目经理： Zookeeper和Eureka，我们部门都有使用过，但现在我们要为这个新项目选择一个最为合适的注册中心，今天还是得好好“讨论讨论” 这个项目我先不告诉大家具体是什么需求，什么业务，大家就先纯粹的站在自己认为更好的一方进行辩论就好。我们的辩论双方分为 Zookeeper方 和 Eureka方 。希望大家本着 技术第一，比赛第二 的心态来比赛，避免发生任何”口角“哈。先来介绍一下我们的参赛选手，共有4位，他们分别是： zookeeper方：

一辩：沃尔德

二辩：雷斯特

Eureka方：

一辩：吴霸格

二辩：玫文

好，接下来，比赛即将开始，首先由 沃尔德 来发表一下开篇立论

二 开始

正式辩论

Zookeeper方一辩(沃尔德)： 大家好，我是zookeeper方的一辩，沃尔德。对，基本上所有程序员 都对我说过 hello (观众哗然~)

Zookeeper采用了 leader+follower+observer 的集群模式，Zookeeper的实现着重于高性能、高可用性和严格的顺序访问。ZooKeeper的性能方面意味着它可以用于大型分布式系统。可靠性方面使它不会造成单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。 所以，就注册中心这一角色而言，我方认为，Zookeeper更适合 Eureka方一辩(吴霸格)： 大家好，我是Eureka方的一辩，我就厉害了，我的名字是所有程序员的愿望，我叫 吴霸格 (观众哗然~诸程序猿们相视，哈哈大笑)

哈哈，在分布式服务中，网络故障总是不可避免的。而网络故障导致的结果也必然是十分严重的

zookeeper的这种集群模式，需要保证过半可用机制，也就是说必须有超过半数的集群节点是可用状态，整个集群服务才是可用的。

这样的话，对于3集群的zookeeper服务，如果有两台节点发生故障，整个服务将不可用。而Eureka则可以使用自我保护模式来解决网络故障问题：

一旦进入该模式，Eureka Server仍能接收新服务的注册和查询请求，但是不会同步到其他节点上；同时也会保护服务注册表中的信息，不再移除注册列表中因为长时间没收到心跳而应该过期的服务。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。Eureka的这种自我保护机制，极大地保证了Eureka的高可用特性

总结1：Eureka具有雪崩保护,而zookeeper没有

因此，我方认为，Eureka更适合做注册中心

01.CAP理论支持篇

Eureka方二辩(玫文)：大家好，我叫玫文， 就是大家经常使用的那个maven (观众大笑~人群中不知谁说了一句：注定是个程序员啊！) Eureka Server采用P2P的去中心化结构，也就是说各个集群节点之间都是平级关系，这样相比于Zookeeper，集群不需要保证至少几台Server存活才能正常工作，增强了可用性。 总结2： Eureka集群模式为平级结构，而Zookeeper为leader+follower+observer的集群模式 Zookeeper方二辩(雷斯特)：但是这种结构注定了Eureka不可能有zookeeper那样的一致性保证，而且client缓存更新不及时、Server间同步失败等场景，都会导致Client访问不到新注册的服务或者访问到过期的服务。 噢，对了，忘记介绍我自己，大家好，我叫 雷斯特 ，无巧不成书，我跟list也重名了(摊手~) (观众大笑：天哪，这些人的名字都是怎么取的？！！！确定不是绰号？)

Eureka方二辩(玫文)：(哈哈，这个太形象了！但及时收住大笑的表情) 这一点，我们认为通过调整更新缓存的参数来进行优化的。 缓存更新不及时，主要是为了保证可用性而产生的一个小缺点。但没有问题，我们可以分别通过 调整参数 来优化 。比如说，针对新服务上线，Eureka Client获取不及时的问题，可以适当提高Client端拉取Server注册信息的频率，例如下面将默认的30秒改为15秒：

eureka.client.registry-fetch-interval-seconds=5

那请问，zookeeper的这种leader+followe+observer的集群模式，当leader发生故障 、刚刚启动、或者故障恢后使用选举算法进行选举的过程中或者超过半数集群节点发生故障的时候， 岂不是会导致部分请求丢失了？ 总结3： Eureka可以通过调整配置参数，来优化解决找不到最新注册的服务或者访问不到最新服务的情况 Zookeeper方一辩(沃尔德)：这些故障情况毕竟是少数。即使出现这种情况，因也可以通过以下方式避免 首先，zookeeper具有 监听机制 ，针对某个服务节点的变化，它都能够实时接收到消息，从而提醒运维人员及时作出响应； 然后，也可以通过 设置超时以及重试参数 来尽可能地避免掉这种情况。 最后，就算发生了故障，通过官网的实验，zookeeper也 能够快速恢复 。以下是官网给出的关于zookeeper节leder或者follower节点的宕机与恢复情况：

1)follower的宕机和恢复

2)不同follower宕机和恢复

3)leader的宕机

4)两个follower的宕机和恢复

5)另一位leader宕机

通过该图，我们可以有一些重要的观察结果。

1)首先，如果follower失败并迅速恢复，则ZooKeeper能够在失败的情况下维持高吞吐量；

2)当然更重要的是，leader选举算法允许系统恢复得足够快，以防止吞吐量大幅下降。根据我们的观察，ZooKeeper只需不到200毫秒即可选出新的领导者:

3)第三，随着follower的恢复，ZooKeeper能够在开始处理请求后再次提高吞吐量。

总结4： zookeeper会出现请求丢失的情况，但可以通过一些机制进行避免。 Eureka方一辩(吴霸格)： 好的，即使有方案来保护，那双方都还是有弊端的，这一点不能百分之百避免掉。 总会出现一些对于有些对于缓存和实效性这一点要求比较高的需求场景，两者都不能说完全满足，只是相对比来说某一个更优而已 Zookeeper是一个CP系统，它虽然保证了数据一致性，但是对于注册中心来讲的话，似乎一致性并不是很必要。 但是 我们知道，Eureka是一个AP的系统，具备高可用性和分区容错性。每个Eureka Client本地都会 缓存 一份最新获取到的注册中心中的的缓存信息，即使所有的Eureka Server都挂掉了，依然可以根据本地缓存的服务信息正常工作

总结5：zookeeper和Eureka都可以通过集群的方式保证服务的分区容错性。此外，zookeeper保证一致性，而Eureka保证服务的可用性。

Zookeeper方二辩(雷斯特)： 的确是这样，对于 CAP理论 ，Eureka保证了数据的高可用，但这种高可用性，对于金融项目可能就不那么适合了。金融项目需要保证扣账与记账的一致性，否则会出现账务不一致的问题。而Zookeeper通过 Zab协议 就可以实现一致性这个关键特性 然后，针对你说的 Eureka Client会有本地缓存，但这恰恰导致了Eureka的实效性太差，当有微服务实例发生变化时，它并不能够及时感知到。而Zookeeper则会因为它本身存在的 监听机制 ，实时感应到服务实例的变化，从而保证服务的实效性 (比赛进入了白热化~~~) Eureka方二辩(玫文)：那照你这么说，我们在分布式架构中，都不用考虑高可用性了，在我们看来，可用性远远应该优于一致性来考虑吧，服务都不可用了，还谈什么一致性？比如说，电商平台呢，对于一些访问太大的情况，可能很容易出现服务宕机的情况哦，这种情况当然是可用性更重要了。 Zookeeper方二辩(雷斯特)：可用性当然需要考虑，只是说哪个更重要而已，zookeeper在保持一致性的基础上，进行一些避免措施就可以了。比如跨宿主机、跨机房部署，对于服务器和机房进行定期检查维护，就可以很大程度上保证服务是高可用的了。那Eureka可以尽可能地实现一致性吗？ Eureka方二辩(玫文)：当然可以！首先， Eureka Server 启动后，会通过 Eureka Client 请求其他 Eureka Server节点中的一个节点，获取注册的服务信息，然后复制到其他节点；每当Client 向自己发起注册、续约、注销请求， 都会把自己的最新信息通知给其他 Eureka Server，保持数据同步

1)如果一定要在可用性的基础上，实现一致性的话，我们可以把这个同步的间隔时间适当调整小一点。对于Eureka的缓存机制，我们也可以通过结合实际情况，进行适当参数调整

2)同时还可以通过客户端自己使用监控健康端点，来实现Eureka服务节点宕机之后实时推送通知的机制；

3)最后，对于服务，如果可以的话，进行适当的限流，避免服务因为交易量太大而宕机。这样就可以在高可用的基础上来保证数据的一致性

Zookeeper方一辩(沃尔德)： 这些方式 虽然可行，但是你不觉得， 这个 会 使得Eurek a本身的 高可用性又打了折扣了吗？ Eureka方二辩(玫文)：那你刚才说的通过跨宿主机、跨机房部署，这些措施来保证高可用性，不也需要耗费大量的成本吗？ Zookeeper方一辩(沃尔德)：但是...... 总结6： 不同的应用场景，会侧重不同功能。可以根据实际业务需求场景来选择，然后在其基础上，再通过其他外在措施来完善其不足之处 项目经理： (打断了沃尔德的发言) 好了，非常好，关于一致性和可用性，大家都说的特别好。还有其他方面的特点呢？比如说 易用性。包括多方面的工作，例如API和客户端的接入是否简单，文档是否齐全易懂，控制台界面是否完善等。对于开源产品来说，还有一块是社区是否活跃

02.易用性篇

Eureka方二辩(玫文)：Zookeeper的易用性是比较差的。 对多语言的支持也不太好，同时没有比较好用的控制台进行运维管理， Eureka具有现成的管理端 。Eureka有 基于SpringCloud体系的starter，帮助用户以非常低的成本无感知的做到服务注册与发现。同时还暴露标准的HTTP接口，支持多语言和跨平台访问 Zookeeper方二辩(雷斯特)： Spring Cloud也已经支持Zookeeper了啊， zookeeper也有基于Spring Cloud的starter依赖。而且zookeeper虽然没有现成的控制台查询服务，但客户端也可以根据提供的API，很容易自己实现一个也控制台，比如 zkui就是其中一个比较好用的管理端

而且呢，还有一点值得一提，就是Eureka2.0现在官方已经不支持维护了，而Zookeeper的社区还依旧比较活跃。所以对于要做一个新项目时，选择Eureka还是有很大的风险的 总结7： Eureka有现成的管理端，zookeeper没有，但当前已有类似于zkui等好用的管理端；Eureka2.0已停止维护，Zookeeper依旧在持续维护 项目经理：是的，关于 易用性这块，双方都说到点子上了。由于时间有限，我们今天的比赛就先到这里吧

三 结束

领导总结

项目经理： 看来大家对于Zookeeper和Eureka都了解得很清楚了啊。观众们对于其中一些术语、概念之类的，如果不太理解，暂时跟不上辩论赛进度的话，可以参考青梅主码的微信公众号的关于Eureka和Zookeeper的系列文章。看完之后，再回来回放这场辩论赛，你会谢谢我的！这里面最重要的一点就是它们对于 CAP理论的实现 zookeeper顾及到了 一致性 ，但它由于不能保证每次请求都是可达的，如当leader节点挂了，zk要重新进行选举leader，此时服务是不可用的。当leader选举完毕，才接着进行服务 Eureka则主要保证 可用性 ，也就是说只要有一个服务在，甚至所有的Eureka集群全部挂了，都能正常接受请求。但是对与返回结果是否是最新的，不能保证，因为，在分布式部署的时候，数据一致的过程不可能想切线路那么快 实际上，世界上的任何一件东西，都不可能是完美的，任何一项伟大的发明也不可能是十全十美的，没有最好，只有更适合。 只有针对不同的需求，进行不同的取舍，选择最合适的那个才是最好的这次辩论很精彩，通过大家的辩论，我们可以得出如下结论：

序号	比较项	Eureka	Zookeeper	说明
1	传输方式	经常与rest搭配，以http文本方式传输	经常与rpc搭配，使用二进制方式传输	rpc效率明显会更高
2	是否可以及时知道服务状态变化	不能及时知道	会及时知道	zk具有watch机制
3	一致性协议	注重可用性(AP)	注重一致性(CP)	模式不同
4	雪崩保护	有	没有
5	社区是否活跃	Eureka2.0不再维护了	持续维护
6	管理端	有现成的eureka管理端	没有现成的管理端
7	负载均衡策略	使用ribbon 实现	一般可以直接采用RPC的负载均衡
8	安全	无	使用ACL实现节点权限控制

那么，作为观众的你，更倾向于选择哪个注册中心呢？或者你们目前的项目使用的是哪个注册中心呢？欢迎留言、加微信或者进群讨论！技术就是在交流中得到提升的。

这种形式很棒，让大家在讨论中加深对某个技术的深入理解，锻炼思维等等，所以，我们以后还会多次举行的

那么到现在为止，我们的注册中心章节之Zookeeper篇和Eureka篇到这里就结束啦~ 接下来将会继续出品console篇和nacos篇，敬请期待哦~

嗯，就这样。每天学习一点，时间会见证你的强大~ 下期预告： Spring Cloud(五)：注册中心-nacos

往期精彩回顾

Spring Cloud(三)：注册中心zookeeper-站在客户端角度 Spring Cloud(二)：在实战中深入zookeeper服务端机制 Spring Cloud(一)：我与导师的对话：你真的了解zookeeper吗？ Spring Boot(十)：注册中心Eureka-客户端视角 Spring Boot(九)：注册中心Eureka-服务端视角 Spring Boot(八)：Spring Boot的监控法宝：Actuator Spring Boot(七)：你不能不知道的Mybatis缓存机制！ Spring Boot(六)：那些好用的数据库连接池们 Spring Boot(五)：春眠不觉晓，Mybatis知多少 Spring Boot(四)：让人又爱又恨的JPA Spring Boot(三)：操作数据库-Spring JDBC SpringBoot(二)：第一个Spring Boot项目 SpringBoot(一)：特性概览 个人微信，欢迎添加交流~ 也欢迎大家关注们的公众号，一起持续性学习吧~ 关注公众号，回复进群，可获得群名片，进入技术交流群~热爱IT的人都在这里了，你还在等什么