logo
咨询企业版

技术分享

图数据库系统重构之路:从 OrientDB 迁移到 NebulaGraph 真实案例分享

以下文章来源于浅谈架构 ,作者阿七 图数据库系统重构之路

“本文由社区用户 @阿七从第一视角讲述其团队重构图数据库的过程,首发于阿七公众号「浅谈架构」”

读过我公众号文章的同学都知道,我做过很多次重构,可以说是“重构钉子户”,但是这次,重构图数据库 OrientDB 为 NebulaGraph https://www.nebula-graph.com.cn/,可以说是我做过最艰难的一次重构。

而这篇文章就来聊聊,图数据库重构之路。

Part 01. 难点在哪里

  • 历史包袱重,原来使用 OrientDB 系统是 2016 年开始开发的,逻辑很复杂,历史背景完全不清楚。
  • 业务不了解,我们是临时接的大数据需求,之前没有参与过这块业务,完全不了解。
  • 技术栈不了解,图数据库是第一次接触(团队中也没有人了解),OrientDB 和 NebulaGraph 之前都没有接触过,原来老系统大部分代码是 Scala 语言写的,系统中使用的 HBase、Spark、Kafka,对于我们也比较陌生。
  • 时间紧迫

总结来说: 业务不了解,技术栈不熟悉。

这里想和大家交流下:在业务和技术栈都不熟的情况下,如何做重构呢?

Part 02. 技术方案

下面介绍一下本次重构技术方案

1. 迁移背景 WHY

猎户座的图数据库 OrientDB 存在性能瓶颈和单点问题,需升级为 NebulaGraph。

老系统使用技术栈无法支持弹性伸缩,监控报警设施也不够完善。

具体的使用痛点后续我将会写一篇文章具体讲述下,本篇就不详细展开了。

2. 调研事项 SEARCH

既然业务都不熟悉,那我们都调研了哪些东西呢?

  • 对外接口梳理:梳理系统所有对外接口,包括接口名、接口用途、请求量 QPS、平均耗时,调用方(服务和 IP);
  • 老系统核心流程梳理:输出老系统整理架构图,重要的接口(大概 10 个)输出流程图;
  • 环境梳理:涉及到的需要改造的项目有哪些,应用部署、MySQL、Redis、HBase 集群 IP,及目前线上部署分支整理;
  • 触发场景:接口都是如何触发的,从业务使用场景出发,每个接口至少一个场景覆盖到,方便后期功能验证;
  • 改造方案:可行性分析,针对每一个接口,如何改造(OrientDB 语句改为 NebulaGraph 查询语句),入图(写流程)如何改造;
  • 新系统设计方案: 输出整理架构图,核心流程图。

3. 项目目标 TARGET

完成图数据库数据源 OrientDB 改造为 NebulaGraph,重构老系统统一技术栈为 Java,支持服务水平扩展。

4. 整体方案 SOLUTION

我们采用了比较激进的方案:

  • 从调用接口入口出发,直接重写底层老系统,影响面可控;
  • 一劳永逸,方便后期维护;
  • 统一 Java 技术栈、接入公司统一服务框架,更利于监控及维护;
  • 基础图数据库应用边界清晰,后续上层应用接入图数据库更简单。

注:这里就贴调研阶段画的图,图涉及业务,我这里就不列举了。

5. 灰度方案 A/B TEST

图数据库 灰度方案

灰度方案

  • 写请求:采用同步双写
  • 读请求:按流量从小到大陆续迁移、平滑过渡

灰度计划

图数据库 灰度计划

注:

  • 配置中心开关控制,有问题随时切换,秒级恢复。
  • 读接口遗漏无影响, 只有改到的才会影响。
  • 使用参数 hash 值作为 key,确保同一参数多次请求结果一致、满足 abs(key) % 1000 < X ( 0< X < 1000, X 为动态配置 ) 即为命中灰度。

题外话:其实重构,最重要的就是灰度方案,这个我在之前文章《浅谈这些年做过的千万级系统重构项目》也提到过。本次灰度方案设计比较完善,大家重点看阶段一、在灰度放量之前,我们用线上真实的流量去异步做数据对比,对比完全通过之后,再放量,本次对比阶段比预期长了很多(实际上用了 2 周时间,发现了很多问题)。

6. 数据对比方案 WHICH ONE

未命中灰度

未命中灰度流程如下:

先调用老系统,再根据是否命中采样(采样比例配置 0% ~ 100%),命中采样会发送 MQ,再在新系统消费 MQ,请求新系统接口,于老系统接口返回数据进行 JSON 对比。对比不一致,发送企业微信通知,实时感知数据不一致,发现并解决问题。

图数据库 数据对比方案

反之亦然!!

7. 数据迁移方案 READY?GO!

  • 全量(历史数据):写脚本全量迁移,上线期间产生不一致从 MQ 消费近 3 天数据
  • 增量:同步双写(写的接口很少,写请求 QPS 不高)

8. 改造案例 - 以子图查询为例 AWOW

改造前:

@Override
    public MSubGraphReceive getSubGraph(MSubGraphSend subGraphSend) {
        logger.info("-----start getSubGraph------(" + subGraphSend.toString() + ")");
        MSubGraphReceive r = (MSubGraphReceive) akkaClient.sendMessage(subGraphSend, 30);
        logger.info("-----end getSubGraph:");
        return r;
    }

改造后:

定义灰度模块接口

public interface IGrayService {
    /**
     * 是否命中灰度 配置值 0 ~ 1000  true: 命中  false:未命中
     *
     * @param hashCode
     * @return
     */
    public boolean hit(Integer hashCode);

    /**
     * 是否取样 配置值 0 ~ 100
     *
     * @return
     */
    public boolean hitSample();

    /**
     * 发送请求-响应数据
     * @param requestDTO
     */
    public void sendReqMsg(MessageRequestDTO requestDTO);

    /**
     * 根据
     * @param methodKeyEnum
     * @return
     */
    public boolean hitSample(MethodKeyEnum methodKeyEnum);
}

接口改造如下,kgpCoreService 请求到 kgp-core 新服务,接口业务逻辑和 orion-x 保持一致、底层图数据库改为查询 NebulaGraph:

@Override
    public MSubGraphReceive getSubGraph(MSubGraphSend subGraphSend) {
        logger.info("-----start getSubGraph------(" + subGraphSend.toString() + ")");
        long start = System.currentTimeMillis();
        //1. 请求灰度
        boolean hit = grayService.hit(HashUtils.getHashCode(subGraphSend));
        MSubGraphReceive r;
        if (hit) {
            //2、命中灰度 走新流程
            r = kgpCoreService.getSubGraph(subGraphSend); // 使用Dubbo调用新服务
        } else {
            //这里是原来的流程 使用的akka通信
            r = (MSubGraphReceive) akkaClient.sendMessage(subGraphSend, 30);
        }
        long requestTime = System.currentTimeMillis() - start;

        //3.采样命中了发送数据对比MQ 
        if (grayService.hitSample(MethodKeyEnum.getSubGraph_subGraphSend)) {
            MessageRequestDTO requestDTO = new MessageRequestDTO.Builder()
                    .req(JSON.toJSONString(subGraphSend))
                    .res(JSON.toJSONString(r))
                    .requestTime(requestTime)
                    .methodKey(MethodKeyEnum.getSubGraph_subGraphSend)
                    .isGray(hit).build();
            grayService.sendReqMsg(requestDTO);
        }
        logger.info("-----end getSubGraph: {} ms", requestTime);
        return r;
    }

9. 项目排期计划 DEADLINE

投入人力: 开发 4 人,测试 1 人

主要事项及耗时如下:

图数据库 项目排期计划

Part 03. 重构收益

经过团队 2 个月奋斗,目前已完成灰度阶段,收益如下

  • NebulaGraph 本身支持分布式扩展,新系统服务支持弹性伸缩,整体支持性能水平扩展;
  • 从压测结果看,接口性能提升很明显,可支撑请求远超预期;
  • 接入公司统一监控、告警,更利于后期维护。

Part 04. 总结

本次重构顺利完成,感谢本次一起重构的小伙伴,以及大数据、风控同学支持。同时,也感谢 NebulaGraph 社区 https://discuss.nebula-graph.com.cn/,我们遇到一些问题提问,也很快帮忙解答。


谢谢你读完本文(///▽///)

如果你想尝鲜图数据库 NebulaGraph,记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> GitHub;如果你有更高的性能、易用性、运维实施等方面的需求,你也可以随时 联系我们,获取进一步的帮助哦~