2020 Google开发者大会重磅开幕 了解详情

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

2020 年 1 月 07 日

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

前言


随着瓜子业务的不断发展,系统规模在逐渐扩大,目前在瓜子的私有云上已经运行着数百个 Apache Dubbo ( 下文简称 Dubbo )应用,上千个 Dubbo 实例。瓜子各部门业务迅速发展,版本没有来得及统一,各个部门都有自己的用法。随着第二机房的建设,Dubbo 版本统一的需求变得越发迫切。几个月前,公司发生了一次与 Dubbo 相关的生产事故,成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。


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


一、Ephermal 节点未及时删除导致 provider 不能恢复注册的问题修复


事故背景


在生产环境,瓜子内部各业务线共用一套 ZooKeeper 集群作为 Dubbo 的注册中心。2019 年 9 月份,机房的一台交换机发生故障,导致 ZooKeeper 集群出现了几分钟的网络波动。在 ZooKeeper 集群恢复后,正常情况下 Dubbo 的 provider 应该会很快重新注册到 ZooKeeper 上,但有一小部分的 provider 很长一段时间没有重新注册到 ZooKeeper 上,直到手动重启应用后才恢复注册。


排查过程


首先,我们统计了出现这种现象的 Dubbo 服务的版本分布情况,发现在大多数的 Dubbo 版本中都存在这种问题,且发生问题的服务比例相对较低,在 GitHub 中我们也未找到相关问题的 issues 。因此,推断这是一个尚未修复的且在网络波动情况的场景下偶现的问题。


接着,我们便将出现问题的应用日志、ZooKeeper 日志与 Dubbo 代码逻辑进行相互印证。在应用日志中,应用重连 ZooKeeper 成功后 provider 立刻进行了重新注册,之后便没有任何日志打印。而在 ZooKeeper 日志中,注册节点被删除后,并没有重新创建注册节点。对应到 Dubbo 的代码中,只有在 FailbackRegistry.register(url)的 doRegister(url) 执行成功或线程被挂起的情况下,才能与日志中的情况相吻合。


public void register(URL url) {
super.register(url);
failedRegistered.remove(url);
failedUnregistered.remove(url);
try {
// Sending a registration request to the server side
doRegister(url);
} catch (Exception e) {
Throwable t = e;
// If the startup detection is opened, the Exception is thrown directly.
boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
&& url.getParameter(Constants.CHECK_KEY, true)
&& !Constants.CONSUMER_PROTOCOL.equals(url.getProtocol());
boolean skipFailback = t instanceof SkipFailbackWrapperException;
if (check || skipFailback) {
if (skipFailback) {
t = t.getCause();
}
throw new IllegalStateException("Failed to register " + url + " to registry " + getUrl().getAddress() + ", cause: " + t.getMessage(), t);
} else {
logger.error("Failed to register " + url + ", waiting for retry, cause: " + t.getMessage(), t);
}
// Record a failed registration request to a failed list, retry regularly
failedRegistered.add(url);
}
}

复制代码


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


继续对 doRegister(url) 的代码进行进一步排查,我们发现在 CuratorZookeeperClient.createEphemeral(path) 方法中有这么一段逻辑:在 createEphemeral(path) 捕获了 NodeExistsException ,创建 Ephemeral 节点时,若此节点已存在,则认为 Ephemeral 节点创建成功。这段逻辑初看起来并没有什么问题,且在以下两种常见的场景下表现正常:


1、 Session 未过期,创建 Ephemeral 节点时原节点仍存在,不需要重新创建。


2、 Session 已过期,创建 Ephemeral 节点时原节点已被 ZooKeeper 删除,创建成功。


public void createEphemeral(String path) {
try {
client.create().withMode(CreateMode.EPHEMERAL).forPath(path);
} catch (NodeExistsException e) {
} catch (Exception e) {
throw new IllegalStateException(e.getMessage(), e);
}
}

复制代码


但是实际上还有一种极端场景,ZooKeeper 的 Session 过期与删除 Ephemeral 节点不是原子性的,也就是说客户端在得到 Session 过期的消息时, Session 对应的 Ephemeral 节点可能还未被 ZooKeeper 删除。此时 Dubbo 去创建 Ephemeral 节点,发现原节点仍存在,故不重新创建。待 Ephemeral 节点被 ZooKeeper 删除后,便会出现 Dubbo 认为重新注册成功,但实际未成功的情况,也就是我们在生产环境遇到的问题。


此时,问题的根源已被定位。定位问题之后,经我们与 Dubbo 社区交流,发现考拉的同学也遇到过同样的问题,更确定了这个原因。


问题的复现与修复


定位到问题之后,我们便开始尝试本地复现。由于 ZooKeeper 的 Session 过期但 Ephemeral 节点未被删除的场景直接模拟比较困难,我们通过修改 zookeeper 源码,在 Session 过期与删除 Ephemeral 节点的逻辑中增加了一段休眠时间,间接模拟出这种极端场景,并在本地复现了此问题。


在排查问题的过程中,我们发现 kafka 的旧版本在使用 ZooKeeper 时也遇到过类似的问题,并参考 Kafka 关于此问题的修复方案,确定了 Dubbo 的修复方案。在创建 Ephemeral 节点捕获到 NodeExistsException 时进行判断,若 Ephemeral 节点的 SessionId 与当前客户端的 SessionId 不同,则删除并重建 Ephemeral 节点。在内部修复并验证通过后,我们向社区提交了 issues 及 pr 。


Kafka 类似问题 issues :


https://issues.apache.org/jira/browse/KAFKA-1387


Dubbo 注册恢复问题 issues:


https://github.com/apache/dubbo/issues/5125


二、瓜子的 dubbo 升级历程


上文中的问题修复方案已经确定,但我们显然不可能在每一个 Dubbo 版本上都进行修复。在咨询了社区 Dubbo 的推荐版本后,我们决定在 Dubbo2.7.3 版本的基础上,开发内部版本修复来这个问题。并借这个机会,开始推动公司 Dubbo 版本的统一升级工作。


为什么要统一 Dubbo 版本


1、统一 Dubbo 版本后,我们可以在此版本上内部紧急修复一些 Dubbo 问题(如上文的 Dubbo 注册故障恢复失效问题)。


2、瓜子目前正在进行第二机房的建设,部分 Dubbo 服务也在逐渐往第二机房迁移。统一 Dubbo 版本,也是为 Dubbo 的多机房做铺垫。


3、有利于我们后续对 Dubbo 服务的统一管控。


4、Dubbo 社区目前的发展方向与我们公司现阶段对 Dubbo 的一些诉求相吻合,如支持 gRPC 、云原生等。


为什么选择 Dubbo2.7.3


1、我们了解到,在我们之前携程已经与 Dubbo 社区合作进行了深度合作,携程内部已全量升级为 2.7.3 的社区版本,并在协助社区修复了 2.7.3 版本的一些兼容性问题。感谢携程的同学帮我们踩坑~


2、Dubbo2.7.3 版本在当时虽然是最新的版本,但已经发布了 2 个月的时间,从社区 issues 反馈来看,Dubbo2.7.3 相对 Dubbo2.7 之前的几个版本,在兼容性方面要好很多。


3、我们也咨询了 Dubbo 社区的同学,推荐升级版本为 2.7.3 。


内部版本定位


基于社区 Dubbo2.7.3 版本开发的 Dubbo 内部版本属于过渡性质的版本,目的是为了修复线上 provider 不能恢复注册的问题,以及一些社区 Dubbo2.7.3 的兼容性问题。瓜子的 Dubbo 最终还是要跟随社区的版本,而不是开发自已的内部功能。因此我们在 Dubbo 内部版本中修复的所有问题均与社区保持了同步,以保证后续可以兼容升级到社区 Dubbo 的更高版本。


兼容性验证与升级过程


我们在向 Dubbo 社区的同学咨询了版本升级方面的相关经验后,于 9 月下旬开始了 Dubbo 版本的升级工作。


1、初步兼容性验证


首先,我们梳理了一些需要验证的兼容性 case ,针对公司内部使用较多的 dubbo 版本,与 Dubbo2.7.3 一一进行了兼容性验证。经验证,除 DubboX 外, Dubbo2.7.3 与其他 Dubbo 版本均兼容。DubboX 由于对 Dubbo 协议进行了更改,与 Dubbo2.7.3 不兼容。


2、生产环境兼容性验证


在初步验证兼容性通过后,我们与业务线合作,挑选了一些重要程度较低的项目,在生产环境对 Dubbo2.7.3 与其他版本的兼容性进行了进一步验证。并在内部版本修复了一些兼容性问题。


3、推动公司 Dubbo 版本升级


在 10 月初,完成了 Dubbo 兼容性验证后,我们开始在各个业务线推动 Dubbo 的升级工作。截止到 12 月初,已经有 30% 的 Dubbo 服务的完成了版本升级。按照排期,预计于 2020 年 3 月底前完成公司 Dubbo 版本的统一升级。


兼容性问题汇总


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


1、创建 ZooKeeper 节点时提示没有权限


Dubbo 配置文件中已经配置了 ZooKeeper 的用户名密码,但在创建 ZooKeeper 节点时却抛出 KeeperErrorCode = NoAuth 的异常,这种情况分别对应两个兼容性问题:


a. issues:


https://github.com/apache/dubbo/issues/5076


dubbo 在未配置配置中心时,默认使用注册中心作为配置中心。通过注册中心的配置信息初始化配置中心配置时,由于遗漏了用户名密码,导致此问题。


b. issues:


https://github.com/apache/dubbo/issues/4991


Dubbo 在建立与 ZooKeeper 的连接时会根据 ZooKeeper 的 address 复用之前已建立的连接。当多个注册中心使用同一个 address ,但权限不同时,就会出现 NoAuth 的问题。参考社区的 PR ,我们在内部版本进行了修复。


2、curator 版本兼容性问题


a. Dubbo2.7.3 与低版本的 curator 不兼容,因此我们默认将 curator 版本升级至 4.2.0


<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>4.2.0</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>4.2.0</version>
</dependency>

复制代码


b. 分布式调度框架 elastic-job-lite 强依赖低版本的 curator ,与 Dubbo2.7.3 使用的 curator 版本不兼容,这给 Dubbo 版本升级工作带来了一定阻塞。考虑到 elastic-job-lite 已经很久没有人进行维护,目前一些业务线计划将 elastic-job-lite 替换为其他的调度框架。


3、 OpenFeign 与 Dubbo 兼容性问题


issues:


https://github.com/apache/dubbo/issues/3990


Dubbo 的 ServiceBean 监听 Spring 的 ContextRefreshedEvent ,进行服务暴露。OpenFeign 提前触发了 ContextRefreshedEvent ,此时 ServiceBean 还未完成初始化,于是就导致了应用启动异常。


参考社区的 pr,我们在内部版本修复了此问题。


4、RpcException 兼容性问题


Dubbo 低版本 consumer 不能识别 dubbo2.7 版本 provider 抛出的 org.apache.dubbo.rpc.RpcException。因此,在 consumer 全部升级到 2.7 之前,不建议将 provider 的 com.alibaba.dubbo.rpc.RpcException 改为 org.apache.dubbo.rpc.RpcException


5、QoS 端口占用


Dubbo2.7.3 默认开启 QoS 功能,导致一些混部在物理机的 Dubbo 服务升级时出现 qos 端口占用问题。关闭 QoS 功能后恢复。


6、自定义扩展兼容性问题


业务线对于 Dubbo 的自定义扩展比较少,因此在自定义扩展的兼容性方面暂时还没有遇到比较难处理的问题,基本上都是变更 package 导致的问题,由业务线自行修复。


7、Skywalking agent 兼容性问题


我们项目中一般使 Skywalking 进行链路追踪,由于 Skywalking agent6.0 的 plugin 不支持 Dubbo2.7 ,因此统一升级 Skywalking agent 到 6.1 。


三、Dubbo 多机房方案


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


初步方案


我们咨询了 Dubbo 社区的建议,并结合瓜子云平台的现状,初步确定了 Dubbo 多机房的方案。


1、在每个机房内,部署一套独立的 ZooKeeper 集群。集群间信息不同步。这样就没有了 ZooKeeper 集群跨机房延迟与数据不同步的问题。


2、Dubbo 服务注册时,仅注册到本机房的 ZooKeeper 集群;订阅时,同时订阅两个机房的 ZooKeeper 集群。


3、实现同机房优先调用的路由逻辑。以减少跨机房调用导致的不必要网络延迟。


同机房优先调用


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


1、瓜子云平台默认将机房的标志信息注入容器的环境变量中。


2、 provider 暴露服务时,读取环境变量中的机房标志信息,追加到待暴露服务的 url 中。


3、 consumer 调用 provider 时,读取环境变量中的机房标志信息,根据路由策略优先调用具有相同标志信息的 provider 。


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


Dubbo 通过环境变量路由 PR :


https://github.com/apache/dubbo/pull/5348


作者介绍


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


本文转载自公众号阿里巴巴中间件(ID:Aliware_2018)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247488596&idx=1&sn=12f562bd0d1c2fe6b8630edd48748606&chksm=fdeb2634ca9caf22ef9296c1682bcf5867875e576e3d64a7ecfcb7dfabfe67a8f8afb5f8fc4f&scene=27#wechat_redirect、


2020 年 1 月 07 日 09:30 2147

评论

发布
暂无评论
发现更多内容

当代程序员必备技能(算法)之:递归详解

Java架构师迁哥

腾讯云直播全解析,双11怎么买才不亏?

腾讯云视频云

腾讯云 阿里云 云直播 直播 视频

浅谈程序员的“内卷化”

数据社

阿里P8整理出SQL笔记:收获不止SOL优化抓住SQL的本质

马士兵老师

MySQL 阿里 sql查询 SQL优化 SQL光标

践行新基建,共建城市智能体,为数字经济发展提供新动能

CECBC区块链专委会

云计算 大数据

双十一背后的技术

anyRTC开发者

大数据 AI 音视频 WebRTC RTC

【活动回顾】Flutter实时音视频应用场景实践

ZEGO即构

flutter RTC

聚焦高交会:感受“区块链+”科技创新浪潮

WX13823153201

与第三方系统打通的N种进阶方式

棒锤🐮

架构

奈学教育荣获“中关村高新技术企业”认证

奈学教育

奈学教育

详解快速开发平台与工作流通用组件的设计规范

Marilyn

敏捷开发 企业应用

实时音视频面视必备:快速掌握11个视频技术相关的基础概念

JackJiang

即时通讯 视频 实时音视频

第七周作业

Geek_4c1353

架构师训练营第 1 期 「架构师训练营第 1 期」

11.11 程序员的 1111 种死法

京东智联云开发者

程序员 程序人生

奈学教育荣获“中关村高新技术企业”认证

古月木易

教育 IT

重拳出击!平台经济反垄断,互联网巨头市值蒸发千亿

CECBC区块链专委会

小额贷款 反垄断

apipost如何设置断言

测试人生路

接口测试

快速了解阿里微服务热门开源分布式事务框架——Seata

比伯

Java 架构 微服务 seata

Linux一切皆文件,如果你没做到这一步,那这就是句话而已

小Q

Java Linux 学习 架构 面试

深入解析 Flink 的算子链机制

Apache Flink

flink 流计算

第八周作业

Geek_4c1353

架构师训练营第 1 期 「架构师训练营第 1 期」

CloudQuery v1.2.1 版本发布

CloudQuery社区

数据库 开发者 运维 工具 开发工具

我终于拥有自己的独立博客了。

彭宏豪95

GitHub 写作 博客 IT

【涂鸦物联网足迹】涂鸦云平台接口列表—万能红外遥控器

IoT云工坊

人工智能 云计算 物联网 API 红外遥控器

从应用开发角度认识K8S

LorraineLiu

云原生 容器技术 k8s入门

科技助力餐饮,普渡送餐机器人在餐博会上被众人围观!

DT极客

当Nginx遇上Tomcat集群,又是一场负载均衡的爱恨情仇

小Q

nginx tomcat 学习 架构 面试

堪称完美!11月华为官方首发Spring响应式微服务,Spring+SpringBoot+SpringCloud三管齐下

Java架构追梦

Java 架构 微服务 springboot SpringCloud

对比一下,你的简历是不是也写成了这样,能拿高薪才怪了

小Q

Java 学习 架构 面试 简历

年末十家手机银行数字化升级大盘点:谁家开发更全面?谁家建设更到位?

CECBC区块链专委会

疫情 银行 手机银行

《我想进大厂》之Java基础夺命连环16问

艾小仙

Java 面试 编程语言 面试技巧

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