【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 2020-01-07
  • 本文字数:5551 字

    阅读完需:约 18 分钟

瓜子二手车在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-01-07 09:302898

评论

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

TIDB升级发生故障时,快速强行回退方案

TiDB 社区干货传送门

实践案例

面向状态机编程:复杂业务逻辑应对之道

京东科技开发者

接口 istio 灰度发布 状态机 企业号 3 月 PK 榜

【信创小知识】国产化和信创是一回事吗?怎么理解?

行云管家

信创 国产化

软件测试/测试开发丨后端Web开发框架(Java)

测试人

软件测试 springboot 测试开发

又一个开源第一!飞桨联合百舸,Stable Diffusion推理速度遥遥领先

百度Geek说

人工智能 开源 PaddlePaddle 企业号 3 月 PK 榜

基于 Istio 的灰度发布架构方案实践之路

京东科技开发者

微服务 istio 灰度发布 企业号 3 月 PK 榜

PCB焊盘设计应掌握哪些要素?

华秋电子

通过Chaos-Mesh打造更稳定TiDB数据库高可用架构(二)

TiDB 社区干货传送门

实践案例 集群管理 管理与运维 故障排查/诊断 安装 & 部署

Spring Boot或Spring Cloud快速实现文件上传

做梦都在改BUG

Java Spring Cloud Spring Boot

BSN-DDC基础网络详解(五):接入DDC网络(1)

BSN研习社

【征文大赛】TiDB 社区第二届征文大赛,一次性带走社区全部新周边,还有bose 降噪耳机、倍轻松按摩仪等你拿!

TiDB 社区干货传送门

手把手教你改 sysbench 代码

TiDB 社区干货传送门

开发语言 管理与运维

58个实例+2个项目,带你深入技术原理,彻底搞懂Spring Boot

做梦都在改BUG

Java spring 微服务 Spring Boot 框架

NebulaGraph:打造灵活弹性的云原生图数据库,与阿里云计算巢共同拥抱开放生态

云布道师

数据库 阿里云

「 项目管理 」项目立项前需要思考的9个问题

小刘学编程

项目管理 pmp 项目经理

GitHub险崩盘,竟是因网易大牛「Redis应用与深度实践笔记」泄露

做梦都在改BUG

Java 数据库 redis 缓存 面试

坚如磐石:TiDB 基于时间点的恢复(PiTR)特性优化之路丨6.5 新特性解析

TiDB 社区干货传送门

新版本/特性解读

对TiDB监控方式的一点点研究

TiDB 社区干货传送门

监控 TiDB 源码解读

通过TiDB Operator为已有TiDB集群部署异构集群

TiDB 社区干货传送门

集群管理 管理与运维 故障排查/诊断 安装 & 部署 扩/缩容

怎样判断led显示屏防火性能的好坏

Dylan

行业 LED显示屏 市场

手把手教你基于luatos的4G(LTE Cat.1)模组接入华为云物联网平台

华为云开发者联盟

物联网 华为云 华为云开发者联盟 企业号 3 月 PK 榜 4G

脚本调用工具:FastScripts 直装版

真大的脸盆

Mac 脚本 Mac 软件 Mac 系统

Spring源码分析-BeanFactoryPostProcessor

做梦都在改BUG

Java spring spring源码

增强认证--MQTT 5.0新特性

EMQ映云科技

物联网 IoT mqtt 企业号 3 月 PK 榜 增强认证

FinOps首次超越安全成为企业头等大事|云计算趋势报告

SEAL安全

云计算 云成本 FinOps 企业号 3 月 PK 榜

通过Chaos-Mesh打造更稳定TiDB数据库高可用架构(一)

TiDB 社区干货传送门

实践案例 集群管理 管理与运维 扩/缩容 数据库架构设计

数据库国产替代涌入千军万马 亚信科技CEO高念书:非头部企业将难以生存

亚信AntDB数据库

数据库 AntDB 国产数据库 AntDB数据库

坏了!面试官问我垃圾回收机制

做梦都在改BUG

Java JVM 垃圾回收

阿里三面被面试官狂问Redis,简历上再也不敢写"精通"了

做梦都在改BUG

Java 数据库 redis 缓存 面试

买了等保安全设备就一定安全吗?就一定能抵御网络风险呢?

行云管家

网络安全 等保 等级保护

国家基础学科公共科学数据中心与和鲸科技共建数据社区

ModelWhale

数据 科学分析 社区 合作

瓜子二手车在Dubbo版本升级,多机房方案方面的思考和实践_云原生_李锦涛_InfoQ精选文章