Spring Cloud Eureka与Zookeeper作为注册中心的取舍

       近日刷微信看到了一篇被大量转载的文案——《京东面试官让你谈谈 zookeeper 和 eureka 哪个更好使》。说实话,近几年我并未全心全意地参与过Java开发项目,一直以底层平台运维和提供解决方案的角色出现,暂且从运维人的角度来回答一下这个问题。

       从文案的材料看,这是一个微服务方向的分布式系统考题,假设情景很可能采用了 Spring Cloud Eureka 的组件套装。尽管过去的一年里我都在于大数据平台周边的开源软件打交道,但我不得不承认Eureka这个组件我是第一次碰到,这很可能是因为京东在某个项目里部署的分布式节点已经超过了2000个,但也有可能仅仅是面试官有这个组件选型的技术选择偏好。因为我经历过的单一项目中很少有超过500个节点的,一般来说200~300个节点标准服务器组成的底层平台就已经可以支撑起一个中型企业的业务运行了。

        经过查阅Eureka的发行文档及特性说明(参见 https://github.com/Netflix/eureka/wiki 和  https://github.com/spring-cloud/spring-cloud-netflix/tree/v1.2.2.RELEASE),发现 Eureka本质上是一个服务注册管理中心,核心功能在于实现微服务实例的自动注册与发现,也可以组成高可用注册集群使用。当Eureka Server恰巧处于宕机状态时,Application Client也会因缓存过Application Service地址而实现一次调用,尽管这种调用的结果可能是错误的。因此它不会因为Eureka Server宕机而使得整个注册服务瘫痪。从这点上讲,Eureka是一个优秀的专职服务注册管理者。

        而 ZooKeeper 在分布式微服务架构中的定位则是“协调”,主要职责是保证数据在其管辖下的所有服务之间保持一致,确保任何时刻对ZooKeeper的访问都能得到一致的结果。如果ZooKeeper管辖下的节点断开了,就会将它们剔除出去,外界就不能访问到这些节点了,到达这些节点的服务请求也就被丢失了。这也说明  ZooKeeper 不保证管辖下的节点任何时候都能缓存所有的服务注册信息,也就是不保证服务注册管理的高可用。【关于分布式架构及微服务分层的深层论述,可参见《大型网站系统与Java中间件实践》(曾宪杰)、《大型网站技术架构-核心原理与案例分析》(李智慧)、《分布式数据库架构及企业实践-基于Mycat中间件》(周继峰等)】

       从产品设计原则上讲,这是因为ZooKeeper是按照CP原则构建的,而Eureka则是按照AP原则构建的。

       了解了这些之后,再从运维的角度看在平台组件选型时应如何取舍Eureka与Zookeeper。

        首先是这个分布式平台的部署环境是什么:

        如果该平台部署在裸金属物理服务器集群上,我们就必选考虑到硬件损坏与更换的问题和网络故障问题,因为这两种问题极易导致单点故障现象。此时我们就得考虑规避这个缺陷,或是给 ZooKeeper集群添加缓存,或是采用规避了单点故障的Eureka。

         如果该平台部署在由专业团队维护的 Like OpenStack 云计算平台上,则可以借助弹性计算的冗余伸缩进行故障节点的快速切换来规避ZooKeeper的单点故障风险。此时选择Eureka与Zookeeper中的哪一个,在200个节点以内的环境中取决于运维团队的技术能力和架构设计团队的技术选型偏好博弈,在大于200个节点的环境中,保守起见,仍应将 ZooKeeper 作为首选。

          其次,运维团队的技术支撑是否满足复杂环境的业务需求。

          如果存在一支专业而有完整运维文档和运维日志的运维团队,则可以考虑使用 ZooKeeper,一是因为 ZooKeeper本身提供了丰富的功能(如统一命名服务、配置管理、分布式锁服务、集群管理、负载均衡、高可用等功能)供我们使用,这的确很诱人;二是因为正确的设置与维护ZooKeeper服务非常的困难,错误会经常发生,这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。

           如果运维能力薄弱,则应首选功能专注而维保难度较小的Eureka。

           再次,关注业务需求、了解业务场景。

           如果业务运行过程中不允许出现服务不可用的情况、但可容忍较短时间内1~2次的非正确回应,例如强调可用性的首页展示业务,则选择坚持展示“坏数据”好过无数据可展示的Eureka;如果业务运行过程中不允许出现不准确的回应、但可以容忍片刻服务中断的一致性业务,例如账号密码问题,则应选用ZooKeeper。

           最后,时刻关注业务痛点、关注本次项目是否很在意运维成本、关注平台扩张后的伸缩调整、关注平台组件的安全风险。

 

                                                                                                            孟伯,20200301

                                                                                           交流联系:微信 1807479153 ,QQ 1807479153

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值