陆金所金融核心场景数据库的去 O 之路

做者介绍:万霁春，陆金所数据架构 DBA 团队经理。

金融行业该如何在线替换金融核心场景数据库？在 TUG 陆金所企业行活动中，来自陆金所的数据架构 DBA 团队经理万霁春老师分享了陆金所的去 O 之路，如下内容整理自当天活动分享实录。

陆金所全站去 O  成果

陆金所全站去 O 项目从 2018 年中开始，整个项目迁移过程当中没有作任何的服务降级，在不影响线上业务的状况下，把全站 100% 的数据库从 Oracle 无缝迁移到开源和国产数据库上，其中包括：MySQL、 TiDB 及其余开源数据库。

整个迁移过程零故障、零风险，对用户来讲彻底没有感知。陆金所去 O 数据库覆盖基金、网贷、信托、资管等全金融场景，同时也包括金融系统最核心的帐务、资金、支付、交易和资产系统，目前都已经运行在国产开源数据库上面。

金融核心系统全站去 O 的挑战

在金融核心系统持续对外提供服务的状况下，实现更换全套数据库是极具挑战性的架构改造工做。

去 O 项目咱们把它称之为 CTO 项目，这个项目听上去是由纯运维或 DBA 团队来主导实施的项目，但实际上替换一个异构数据库在本质上是彻底不一样的，它涉及到业务系统、应用系统里全部的 SQL 代码，换一个数据库就要根据新的数据库语法进行逻辑重构，因此这个项目的进展中不但有 DBA，有应用开发，还有整个架构团队。引入一个新的数据库系统会涉及到架构规范、开发规范、中间件引入等问题，须要架构团队进行支持，一些 SQL 语句跟原来的使用方法彻底不同，其上层的业务逻辑须要进行修改，包括测试、开发、产品经理、业务方，在某些状况下也须要介入。

在这样一个多团队参与的项目中，去 O 过程须要有严格的标准，而且要有严格的流程去监控这些规则是否有效落实到每一行代码的改造和变动上，不然任何一个环节出现失误均可能致使数据迁移过程当中不一致，或者业务逻辑在迁移过程当中发生变化。

金融系统去 O 的主要工做

金融系统去 O 分为如下四个步骤：

• 第一，应用层的服务化改造；
• 第二，从 Oracle 数据库到开源数据库的数据字典的转换，包括数据的迁移，以及迁移后云端和目标端数据一致性的校验；
• 第三，从 Oracle 到开源数据库的 SQL 代码语法适配改造和存储过程改造；
• 第四，怎样在不停机的状况下把原来在 Oracle 上面的读写流量以很是快、很是稳妥的方式切换到新的数据库上面，而且在切换以后，出现问题能够随时回滚。

其中提到的第一点就是服务化改造。在传统的架构上 Oracle 数据库会用得特别大、特别重，数据量动辄十几个 T、几十个 T，这些数据可能囊括陆金所全部业务线数据，所以一个数据库会被上层几十个、上百个应用同时链接、访问，进行读写操做。

在这种架构中，去 O 工做很难有效推动，由于若是要迁移一张表，可能上层有不少关联的应用要同时进行改造，应用间的相互依赖、相互耦合会制约项目的进展。因此咱们第一步是把这些数据库对象的上层应用进行服务化，规定某一个库，某一个 Schema 的某些表只能由某一个特定应用来访问，这样其余要访问这些数据的关联应用就调用他的属主应用进行数据的读写操做的访问。这样的话，咱们在去 O 的改造过程当中只要对这一个属主应用进行改造，其余相关联调动应用就不须要关心底层用的是什么数据库。

服务化改造以后，咱们为了去 O 项目的快速迭代，能够在多个拆分后的业务域的属主应用下面进行去 O 改造，由于相互的耦合性已经解开了，因此整个代码改造能够并行开始。

金融数据库流水线式的开源改造

基于这套方法论，咱们总结出一套流水线式的开源数据库的改造方案。

• 第一，高效数据库异构迁移，能够一键全自动化地把原来 Oracle 上的数据库表对象直接作完数据字典的转换，把数据迁移到新的数据库上面；
• 第二，为了便于应用代码的 SQL 改造而作了一个 SQL 智能转换的工具；
• 第三，存储过程转换工具，能够输入你的存储过程， 帮你输出，能够直接在 Java 上运行一段代码；
• 第四，在线换库框架，即在作完应用和数据迁移改造以后，把流量从旧的数据库切到新的数据库。

首先是一键全自动化的数据库底层迁移工具，它实现了从数据库的字典转换到全量同步、增量同步。增量同步这一步作完就能够理解为咱们已经作了一个异构的实时同步的数据库，每当 Oracle 里面有数据变化，MySQL 立刻就会获得实时更新好的数据，保持实时同步的状态。以后咱们会进行全量的 Oracle 和 MySQL 的数据校验。数据校验咱们会校验到总体数据库表的行数，包括每一行、每一个记录、每一个字段里面的值，包括它的精度、小数点，每一位数字都要保证严格一致的状况下才知足咱们切换的条件。

整个迁移的过程当中咱们也支持数据库的迁移改造。原来是一个库的，咱们能够在去 O 过程当中从原来的 Oracle 迁到多个 MySQL 或者多个 TiDB 库上面，也能够在一个大表的状况下拆分红支持多库的分库分表的形式，一样也是能够和上面的双向同步的架构混合使用的。

第二个工具是咱们从 Oracle 到开源数据库，目前是 TiDB 和 MySQL 的 SQL 语法兼容的智能化适配转化器，如今能够基于 Java 代码的 Mybatis 的 SQLMap 文件，咱们会分析它的文件的结构，根据里面 XML 的标签提取出 SQL 语句，经过 SQL 语句把它拆解成词素流  ，把每一个词素进行分析，根据 Oracle 到  MySQL 特定的转换的规则去把它转换成 MySQL 的语句，而后再填充回 Mybatis 的文件。

这个工做主要为了方便开发快速对应用代码进行基于数据库替换的改造工做。

存储过程转换工具整体和 SQL 转换类似，也是把存储过程自己的开发语言语法解析成 AST 的语法树，而后根据这个树上的每一个节点，它的元素类型和含义，转换成 Java 代码里面所操做的对象。

最后是一个流量的切换的工具。这里会有一个总开关，经过一个应用层的开关去控制当前要使用哪一个版本的 SQL map，并且总开关除了控制 SQL map，还能够控制底层数据的同步流向。

在生产流量切换的时间点，咱们会对底层数据库先同步切换，切换以后咱们会进行最后一次数据的增量比对，数据比对没问题的状况下，会把应用的开关流量直接切到新的 MySQL 数据库上面，这时候 MySQL 进来的数据会立刻同步回 Oracle，若是发生一些意外情况，好比 MySQL 的执行效率忽然发生大的波动或迁移过程当中代码改造有 bug，咱们能够立刻经过开关切回 Oracle 模式。

流水线式去 O 改造效率提高效果

咱们能够看到去 O 过程当中大部分工做集中在数据库的迁移，还有开发人员的 SQL 应用改造和存储过程的重构，咱们在这方面进行了相应研发，如今有两个工具能够支持咱们快速转化，这也是整个去 O 过程当中效率提高最大的一部分。

有了这套方案，只须要作好计划，制定好每个去 O 的业务批次。

由于咱们去 O 是根据表维度进行迁移，因此通常会针对某一个库，根据业务模块的分工确立好批次，而后有计划地进行改造，按批次推动到线上，再进行每一批次的开关切换，这样能够减小整个数据库流量切换的风险，保证每次切换控制都是某个业务线或者某一个功能模块的变动操做。

去 O 先后数据库运营成本比较

去 O 以前会用比较好的设备，用 Oracle 数据库总体来支撑网站上层大部分的业务。去 O 以后，咱们主要用 X86 服务器，很是便宜，数据库是用开源的或者是国产的。

去 O 以后咱们数据库整个的服务器数量和实例数也大规模增加，底层用了本身研发的 DataBus 数据同步工具，它会把业务线写入的数据实时同步到咱们后端分析型数据库存储引擎上面，像 ES、TiDB、Hbase、Clickhouse 都会有。由于原来在 Oracle 的一个大库下面作些关联查询、统计计算比较方便，但去 O 以后这么多数据分散在那么多实例里面，要作这方面的关联查询就须要借助智能架构。

金融核心系统 100% 去 O 的收益

关于去 O 的收益总结以下：

• 下降运营成本；
• 核心技术自主研发，摆脱技术绑架；
• 提升整个陆金所研发部门的研发能力，在传统架构上更多依赖数据库自己的特性和它特有的一些功能去支持业务的正常拓展，但如今咱们能够借助更多、更好的中间件，包括用开源的技术去支撑业务更好的运行；

以上就是陆金所数据库的去 O 之路，但愿能对你们有所帮助。