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

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

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