瓜子二手车在 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版本的过程整体上比较顺利,当然也遇到了一些兼容性问题:

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

dubbo在建立与zookeeper的连接时会根据zookeeper的address复用之前已建立的连接。当多个注册中心使用同一个address,但权限不同时,就会出现NoAuth的问题。

参考社区的pr,我们在内部版本进行了修复。

  • curator版本兼容性问题

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

dubbo的ServiceBean监听spring的ContextRefreshedEvent,进行服务暴露。openFeign提前触发了ContextRefreshedEvent,此时ServiceBean还未完成初始化,于是就导致了应用启动异常。
参考社区的pr,我们在内部版本修复了此问题。

  • 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
  • qos端口占用
    dubbo2.7.3默认开启qos功能,导致一些混部在物理机的dubbo服务升级时出现qos端口占用问题。关闭qos功能后恢复。
  • 自定义扩展兼容性问题
    业务线对于dubbo的自定义扩展比较少,因此在自定义扩展的兼容性方面暂时还没有遇到比较难处理的问题,基本上都是变更package导致的问题,由业务线自行修复。
  • 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 推广工作。


本文作者:李锦涛

阅读原文

本文为阿里云内容,未经允许不得转载。

Image placeholder
alexlis
未设置
  94人点赞

没有讨论,发表一下自己的看法吧

推荐文章
Dubbo 在 K8s 下的思考

作者|曹胜利  ApacheDubboPMC导读:Dubbo作为高性能JavaRPC框架的刻板印象早已深入人心,在CloudNative的架构选型上,SpringCloud或许才是业界的优先选择。实际

一个多业务、多状态、多操作的交易链路?闲鱼架构这样演进

前言双十一刚刚结束,成交额2684亿震惊全世界,每秒订单峰值达54.4W笔。在闲鱼2000万DAU,交易数额同样增长迅速的今天,我们如何保障交易链路的稳定与快速支撑业务?这篇文章从客户端开发的角度,介

SpringBoot 整合 Dubbo

1.整合dubbo 有的人或许会说已经有spring-cloud了,你整合dubbo干什么,其实没啥意图,主要就是想整合一下,毕竟dubbo在国内使用的还是很多的,你会一点点总不至于让你显得那么尴尬。

美团BERT的探索和实践

他山之石,可以攻玉。美团点评NLP团队一直紧跟业界前沿技术,开展了基于美团点评业务数据的预训练研究工作,训练了更适配美团点评业务场景的MT-BERT模型,通过微调将MT-BERT落地到多个业务场景中,

看!闲鱼在ServiceMesh的探索和实践

背景在阿里服务端开发以Java为主的大背景下,其他异构语言业务如何调用现有Java服务,如何与集团中间件打通,就成为使用非Java语言团队必须要解决的首要问题。现状在ServiceMesh方案成熟之前

税务信息化跨入大数据云计算时代的思考

现状,目前据了解国税总局执行征收管理、行政管理、决策支持和外部信息等四大类应用系统在全国的推广部署,实施大数据开放与共享的建设与开发,已经完成2个国家级税务处理中心的扩容,包括计算存储资源、系统软件及

分布式场景下Kafka消息顺序性的思考

在业务中使用kafka发送消息异步消费的场景,并且需要实现在消费时实现顺序消费,利用kafka在partition内消息有序的特点,实现消息消费时的有序性。1、在发送消息时,通过指定partition

Dubbo 毕业,成为 Apache 基金会顶级项目

Dubbo发展史一览2011年10月27日,阿里巴巴开源了自己服务化治理方案的核心框架Dubbo,服务治理的设计理念开始逐渐在国内软件行业中落地,并被广泛应用。自开源后,许多非阿里系公司选择使用Dub

Dubbo 稳定性案例:Nacos 注册中心可用性问题复盘

问题描述上周四晚刚回到家,就接到了软负载同学的电话,说是客户线上出了故障,我一听”故障“两个字,立马追问是什么情况,经过整理,还原出线上问题的原貌:客户使用了Dubbo,注册中心使用的是Nacos,在

eBay邓明:dubbo-go 中 metrics 的设计

最近因为要在Apache/dubbo-go(以下简称dubbo-go)里面实现类似的这个metrics功能,于是花了很多时间去了解现在Dubbo里面的metrics是怎么实现的。该部分,实际上是被放在

Python 来算算一线城市的二手房价格指数相关性

Python中有很多方法计算相关性,scipy中有自带的分析工具,pandas里也有非常方便的多变量相关性分析。我们今天就讲讲这两个工具的用法。1.数据收集本文北上广深的数据采集自东方财富网,以二手房

低代码平台在移动开发方面的缺陷

本文由公众号EAWorld翻译发表,转载需注明出处。作者:TimoRailo 译者:白小白 原题:Whymostlow-codeplatformsfallshortonmobiledevelopmen

Flink流式计算在节省资源方面的简单分析

关于Flink流式计算节省资源方面你必须知道的技巧小米在流式计算方面经历了Storm、SparkStreaming和Flink的发展历程;从2019年1月接触Flink到现在,已经过去了大半年的时间了

实践和思考的重要意义(论软件代码设计)

感触 最近这段时间,包括以前,经常听到,程序员们大谈设计模式,这个话题并不陌生,面试必问的问题,活了这么多年,我就一直没搞清楚,为啥面试官喜欢问这个问题。如果一个面试官喜欢问这种问题,我觉得也没啥意思

实践和思考的重要意义(论软件代码设计)

感触最近这段时间,包括以前,经常听到,程序员们大谈设计模式,这个话题并不陌生,面试必问的问题,活了这么多年,我就一直没搞清楚,为啥面试官喜欢问这个问题。如果一个面试官喜欢问这种问题,我觉得也没啥意思。

redis实践及思考

导语:当面临存储选型时是选择关系型还是非关系型数据库?如果选择了非关系型的redis,redis常用数据类型占用内存大小如何估算的?redis的性能瓶颈又在哪里?背景前段时间接手了一个业务,响应时间达

SACC 2019:达梦数据库推进实践与思考

2019年10月31日~11月2日,由IT168旗下ITPUB企业社区平台主办的第十一届中国系统架构师大会(SACC2019)在北京成功召开。本届大会继续沿用四大主线并行的演讲模式,设置业务系统架构设

算法题:设计和实现一个 LRU Cache 缓存机制

理论基础 LRU算法、Cache 实现LRUCache缓存机制 题目描述 设计和实现一个LRUCache缓存机制 解题思路 leastrecentlyused最近最少使用(被淘汰) Doubl

算法题:设计和实现一个 LRU Cache 缓存机制

题目来源于力扣 理论基础 LRU算法、Cache 实现LRUCache缓存机制题目描述 设计和实现一个LRUCache缓存机制 解题思路leastrecentlyused最近最少使用(被淘汰) Do

HDFS3.2升级在滴滴的实践

桔妹导读:Hadoop 3的第一个稳定版本在2017年底就已经发布了,有了很多重大的改进。在HDFS方面,支持了ErasureCoding、Morethan2NameNodes、Router-Base

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对

三个方面告诉你,为什么说传统安全托管服务已过时

随着组织发展其安全程序,其安全环境的复杂性也在增长。复杂性和变化要求采用一种全新的方式来应对现代安全运营中心(SOC)。根据Gartner的数据现实,到2022年,50%的SOC将转变为具有集体事件响

SpringBoot个人应用开发框架(SpringBoot版本2.1)+IDEA

前言: 此笔记为本人首个SpringBoot项目框架学习实践记录,期间参考了许多大神的笔记和心得。 参考文档如下: 项目git地址: 一、创建SpringBoot工程 1.1创建父POM工程结

UI2CODE再进化!结合Redux的框架升级!

背景UI2CODE的目标是通过分析视觉稿得到对应的代码,让AI提高开发效率。然而过去静态化页面的产出,不能得到业务场景的需求。针对于此,我们以UI2CODE自动化开发为基底,结合Redux的消息机制,

Onvif/RTSP海康大华网络安防摄像机网页无插件直播方案EasyNVR中直播页面和视频列表页面的区别介绍

背景分析随着平安城市、智慧城市、雪亮工程、智能交通等各项建设的持续开展,安防逐渐得到普及,面对如此广阔的市场,对安防企业来说不仅仅是机遇更多的是挑战。现今大多数摄像头一直没能摆脱人工监控的传统监控方式