作者介绍:万霁春,陆金所数据架构 DBA 团队经理。
金融行业该如何在线替换金融核心场景数据库?在 TUG 陆金所企业行活动中,来自陆金所的数据架构 DBA 团队经理万霁春老师分享了陆金所的去 O 之路,以下内容整理自当天活动分享实录。
陆金所全站去 O 成果
金融核心系统全站去 O 的挑战
在金融核心系统持续对外提供服务的情况下,实现更换全套数据库是极具挑战性的架构改造工作。
金融系统去 O 的主要工作
金融系统去 O 分为以下四个步骤:
第一,应用层的服务化改造;
第二,从 Oracle 数据库到开源数据库的数据字典的转换,包括数据的迁移,以及迁移后云端和目标端数据一致性的校验;
第三,从 Oracle 到开源数据库的 SQL 代码语法适配改造和存储过程改造;
第四,怎样在不停机的情况下把原来在 Oracle 上面的读写流量以非常快、非常稳妥的方式切换到新的数据库上面,并且在切换之后,出现问题可以随时回滚。
其中提到的第一点就是服务化改造。在传统的架构上 Oracle 数据库会用得特别大、特别重,数据量动辄十几个 T、几十个 T,这些数据可能囊括陆金所所有业务线数据,因此一个数据库会被上层几十个、上百个应用同时连接、访问,进行读写操作。
金融数据库流水线式的开源改造
基于这套方法论,我们总结出一套流水线式的开源数据库的改造方案。
第一,高效数据库异构迁移,可以一键全自动化地把原来 Oracle 上的数据库表对象直接做完数据字典的转换,把数据迁移到新的数据库上面; 第二,为了便于应用代码的 SQL 改造而做了一个 SQL 智能转换的工具; 第三,存储过程转换工具,可以输入你的存储过程, 帮你输出,可以直接在 Java 上运行一段代码; 第四,在线换库框架,即在做完应用和数据迁移改造之后,把流量从旧的数据库切到新的数据库。
这个工作主要为了方便开发快速对应用代码进行基于数据库替换的改造工作。
存储过程转换工具总体和 SQL 转换相似,也是把存储过程本身的开发语言语法解析成 AST 的语法树,然后根据这个树上的每个节点,它的元素类型和含义,转换成 Java 代码里面所操作的对象。
最后是一个流量的切换的工具。这里会有一个总开关,通过一个应用层的开关去控制当前要使用哪个版本的 SQL map,而且总开关除了控制 SQL map,还可以控制底层数据的同步流向。
在生产流量切换的时间点,我们会对底层数据库先同步切换,切换之后我们会进行最后一次数据的增量比对,数据比对没问题的情况下,会把应用的开关流量直接切到新的 MySQL 数据库上面,这时候 MySQL 进来的数据会马上同步回 Oracle,如果发生一些意外状况,比如 MySQL 的执行效率突然发生大的波动或迁移过程中代码改造有 bug,我们可以马上通过开关切回 Oracle 模式。
流水线式去 O 改造效率提升效果
因为我们去 O 是根据表维度进行迁移,所以一般会针对某一个库,根据业务模块的分工确立好批次,然后有计划地进行改造,按批次推进到线上,再进行每一批次的开关切换,这样可以减少整个数据库流量切换的风险,保证每次切换控制都是某个业务线或者某一个功能模块的变更操作。
去 O 前后数据库运营成本比较
去 O 之前会用比较好的设备,用 Oracle 数据库整体来支撑网站上层大部分的业务。去 O 之后,我们主要用 X86 服务器,非常便宜,数据库是用开源的或者是国产的。
去 O 之后我们数据库整个的服务器数量和实例数也大规模增长,底层用了自己研发的 DataBus 数据同步工具,它会把业务线写入的数据实时同步到我们后端分析型数据库存储引擎上面,像 ES、TiDB、Hbase、Clickhouse 都会有。因为原来在 Oracle 的一个大库下面做些关联查询、统计计算比较方便,但去 O 之后这么多数据分散在那么多实例里面,要做这方面的关联查询就需要借助智能架构。
金融核心系统 100% 去 O 的收益
关于去 O 的收益总结如下:
降低运营成本;
核心技术自主研发,摆脱技术绑架;
提高整个陆金所研发部门的研发能力,在传统架构上更多依赖数据库本身的特性和它特有的一些功能去支持业务的正常拓展,但现在我们可以借助更多、更好的中间件,包括用开源的技术去支撑业务更好的运行;
以上就是陆金所数据库的去 O 之路,希望能对大家有所帮助。
关于 TUG
扫码加入 TUG