瓜子二手车在 Dubbo 版本升级、多机房方案方面的思考和实践

  • 时间:
  • 浏览:0

  接下来,我会从这次线上事故刚开使,讲讲大家 这段时间所做的 Dubbo 版本升级的历程以及大家 规划的 Dubbo 后续多机房的方案。

  kafka这类问题图片issues:https://issues.apache.org/jira/browse/KAFKA-1387

  dubbo注册恢复问题图片issues:https://github.com/apache/dubbo/issues/5125

  在排查问题图片的过程中,大家 发现kafka的旧版本在使用zookeeper时也遇到过这类的问题图片,并参考kafka关于此问题图片的修复方案,选着了dubbo的修复方案。在创建Ephemeral节点捕获到NodeExistsException时进行判断,若Ephemeral节点的SessionId与当前客户端的SessionId不同,则删除并重建Ephemeral节点。在实物修复并验证通就让,大家 向社区提交了issues及pr。

  在继续排查问题图片前,大家 先普及下哪此概念:dubbo默认使用curator作为zookeeper的客户端,curator与zookeeper是通过session维持连接的。当curator重连zookeeper时,若session未过期,则继续使用原session进行连接;若session已过期,则创建新session重新连接。而ephemeral节点与session是绑定的关系,在session过期后,会删除此session下的ephemeral节点。

  在推动升级dubbo2.7.3版本的过程整体上比较顺利,当然也遇到了一点兼容性问题图片:

  定位到问题图片就让,大家 便刚开使尝试本地复现。有就让zookeeper的Session过期但Ephemeral节点未被删除的场景直接模拟比较困难,大家 通过修改zookeeper源码,在Session过期与删除Ephemeral节点的逻辑中增加了一段休眠时间,间接模拟出这人 极端场景,并在本地复现了此问题图片。

curator版本兼容性问题图片

  大家 在向dubbo社区的同学咨询了版本升级方面的相关经验后,于9月下旬刚开使了dubbo版本的升级工作。

dubbo的ServiceBean监听spring的ContextRefreshedEvent,进行服务暴露。openFeign提前触发了ContextRefreshedEvent,此时ServiceBean还未完成初始化,于是就愿因了应用启动异常。

参考社区的pr,大家 在实物版本修复了此问题图片。

  此时,问题图片的根源已被定位。定位问题图片就让,经大家 与 Dubbo 社区交流,发现考拉的同学也遇到过同样的问题图片,更选着了这人 愿因。

  dubbo同机房优先调用的实现比较简单,相关逻辑如下:

参考社区的pr,大家 在实物版本进行了修复。

  基于社区dubbo2.7.3版本开发的dubbo实物版本属于过渡性质的版本,目的是为了修复线上provider不还可以 恢复注册的问题图片,以及一点社区dubbo2.7.3的兼容性问题图片。瓜子的dubbo最终还是要跟随社区的版本,而都在开发自已的实物功能。有就让大家 在dubbo实物版本中修复的所有问题图片均与社区保持了同步,以保证后续还可以 兼容升级到社区dubbo的更高版本。

  首先,大家 统计了出现这人 问题图片的dubbo服务的版本分布请况,发现在大多数的dubbo版本中都处于这人 问题图片,且处于问题图片的服务比例相对较低,在github中大家 也未找到相关问题图片的issues。有就让,推断这是一一十几次 尚未修复的且在网络波动请况的场景下偶现的问题图片。

  大家 咨询了dubbo社区的建议,并结合瓜子云平台的现状,初步选着了dubbo多机房的方案。

  接着,大家 便将出现问题图片的应用日志、zookeeper日志与dubbo代码逻辑进行相互印证。在应用日志中,应用重连zookeeper成功后provider立刻进行了重新注册,就让便不还可以 任何日志打印。而在zookeeper日志中,注册节点被删除后,并不还可以 重新创建注册节点。对应到dubbo的代码中,不还可以 在FailbackRegistry.register(url)doRegister(url)执行成功或线程池被挂起的请况下,要能与日志中的请况相吻合。

  在生产环境,瓜子实物各业务线共用一套zookeeper集群作为dubbo的注册中心。2019年9月份,机房的一台交换机处于故障,愿因zookeeper集群出现了几分钟的网络波动。在zookeeper集群恢复后,正常请况下dubbo的provider应该会太快了 重新注册到zookeeper上,但有一小累积的provider很长一段时间不还可以 重新注册到zookeeper上,直到手动重启应用后才恢复注册。

创建zookeeper节点时提示不还可以 权限

dubbo配置文件所含就让配置了zookeeper的用户名密码,但在创建zookeeper节点时却抛出KeeperErrorCode = NoAuth的异常,这人 请况分别对应一一十几次 兼容性问题图片:

  继续对doRegister(url)的代码进行进一步排查,大家 发现在CuratorZookeeperClient.createEphemeral(path)辦法 所含不还可以 一段逻辑:在createEphemeral(path)捕获了NodeExistsException,创建ephemeral节点时,若此节点已处于,则认为ephemeral节点创建成功。这段逻辑初看起来并不还可以 哪此问题图片,且在以下一种生活生活常见的场景下表现正常:

本文作者:李锦涛,任职于瓜子二手车基础架构部门,负责瓜子微服务架构相关工作。目前主要负责公司内 Dubbo 版本升级与推广、 Skywalking 推广工作。

  有就让实际上还有一种生活生活极端场景,zookeeper的Session过期与删除Ephemeral节点都在原子性的,也可是 说客户端在得到Session过期的消息时,Session对应的Ephemeral节点有就让还未被zookeeper删除。此时dubbo去创建Ephemeral节点,发现原节点仍处于,故不重新创建。待Ephemeral节点被zookeeper删除后,便会出现dubbo认为重新注册成功,但实际未成功的请况,也可是 大家 在生产环境遇到的问题图片。

  上文中的问题图片修复方案有就让选着,但大家 显然不有就让在每一一十几次 dubbo版本上都进行修复。在咨询了社区dubbo的推荐版本后,大家 决定在dubbo2.7.3版本的基础上,开发实物版本修复来这人 问题图片。并借这人 有就让,刚开使推动公司dubbo版本的统一升级工作。

  随着瓜子业务的不断发展,系统规模在逐渐扩大,目前在瓜子的私有云上有就让运行着数百个 Dubbo 应用,上千个 Dubbo 实例。瓜子各部门业务太快了 发展,版本不还可以 来得及统一,各个部门都在另一方的用法。随着第二机房的建设,Dubbo 版本统一的需求变得越发迫切。十几次 月前,公司处于了一次与 Dubbo 相关的生产事故,成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。

  瓜子目前正在进行第二机房的建设工作,dubbo多机房是第二机房建设中比较重要的一一十几次 话题。在dubbo版本统一的前提下,大家 就要能更顺利的开展dubbo多机房相关的调研与开发工作。

  针对以上逻辑,大家 简单实现了dubbo通过环境变量进行路由的功能,并向社区提交了pr。

  dubbo通过环境变量路由pr: https://github.com/apache/dubbo/pull/5348