陆金所如何在线更换金融核心场景Oracle数据库-王英杰

彭小阳

作者简介：王英杰，陆金所数据库团队负责人。主导和见证了陆金所数据库和大数据平台全程的建设和演进过程。

2018年开始负责陆金所的全站去O项目，通过上百次迭代和变更在完全不做服务降级的情况下，把陆金所所有金融场景数据库在线完成去Oracle化，全程0故障0风险，并打造了一整套支持金融核心场景数据库开源国产化升级换代的方案和产品。

本文会分享陆金所在线换库的全过程，详细剖析陆金所设计的在线换数据库方案，整套方案又是如何在一个复杂庞大的金融系统里，通过多团队紧密配合稳妥落地。

陆金所全站去O成果

首先跟大家介绍下陆金所全站去O的成果，整个去O过程启动差不多是2年时间，对于全站100%的数据库完成去O，就在上个月，陆金所全站最后一台 Oracle 数据库完整下线，整个陆金所全站数据库全部完成替换。

整个项目历时2年左右，做到0故障、0风险。在整个换库过程中，做到了不做服务降级，在金融核心系统在线提供服务的情况下，替换了 Oracle 数据库。陆金所的去O，覆盖了陆金所的所有产品，包括基金、网贷、信托等产品。

在这个过程中，实际上有很多金融公司，包括银行去O，更多集中在外围系统，可能对整个核心系统真正去O，在业界案例较少。陆金所在去O过程中，真正把跟钱相关的账务、资金、支付、交易和资产数据库，也完成了去O。

陆金所去 Oracle 实践有四个特点：

• 一是不做服务降级的在线换库。让去O这类重大架构改造实施落地的时候对全站用户影响最小，同时也最考验去O的架构改造的技术实现能力。
• 二是把生产环境所有数据库替换掉，0故障，0风险。对于高频上线了上百次的去O变更，全程0故障、0风险。这一点非常考验陆金所去O的变更工具水平。
• 三是全站数据库去O在短短2年时间完成，去O的整体落地效率非常快。
• 四是全站去O，我们有一套自己的方案和工具，依靠这套方案和工具，非常有效地管理了参与去O的数百个研发人员，并行推进去O，包括代码产出，包括生产变更的质量都是非常高。

去O双写和切换方案

这个是整个去O过程中怎样实现核心业务不断提供服务过程，做到在线把商业数据库给替换掉，那么是双写，包括做流量切换的方案。

首先会对应用做进一步改造，把整个跟业务逻辑相关的代码从SQL包括代码层给剥离出去，因为在金融核心产品上面有些应用功能是比较庞大的，对于这种功能比较庞大的应用，如果是在一个晚上所有流量全部切换出来，其实对于生产环境风险是比较大。

所以在整个去O过程中做非常细粒度的批次拆分，每次变更过程当中，做版本改造的时候只会涉及到其中的某个批次，这样可以做到单次变更，单次去O的改造风险可控。

第三，在去O架构体系里批次是相对独立的流量开关，会不同的互相切换，那么在这个过程当中读写出来，那么这样的问题如果不达标，会把流量快速的切换出来，并且切换出来可以拆分很多非常小的批次，最终会有开关控制，这样可以做到批次的切分。

应用流量在O和M之间快速切换

当应用改造完发到生产环境时，最终上线过程中怎样做到在切换对业务生产影响做到最小，达到快速切换。

在这个过程中其实整个步骤流程会比较长，总结三个状态:

• 首先是初始状态，这个时候还是Oracle对外提供写服务，之后会进入中间状态，中间状态即这个切换过程中的核心状态，这个中间状态会经历不到10秒，在这个过程中会确保 Oracle 的最后一笔数据提交成功。

然后最后一笔数据同步到 MySQL，完成最后一次增量比对。这一点非常重要，确保Oracle和MySQL数据的绝对一致。

做完最后一次比对，确保2个数据的数据是完全一致的，然后把相关流量从 Oracle 往 MySQL 上切，切到 MySQL后，这个时候全站是以 MySQL 来对外提供服务。双向同步策略，流量一旦到 MySQL，会解析 MySQL 的binlog，最后反向往 MySQL 上同步，确保 Oracle 和 MySQL 数据是完全一致。这样做的好处是万一在 MySQL 有问题，那些写入的数据 可以快速往 Oracle 回流。

适用于金融核心系统的稳妥去O推进方案

这个过程基于架构快速版本迭代上线的方案，首先是刚才有提到我们会把大应用拆分多个批次，像非常重要资产中心，会拆分成很多，跨度可能会跨半年或一年以上。那么会对批次进行改造，快速进行生产上面上线，快速切流量，如果在 MySQL 上面表现非常好，以 MySQL 提供服务。

每次切换当中只切一点点，这个核心思路确保单个批次改造难度可控、上线进度可控、切换风险可控。不会对相对复杂的，像交易系统、账务系统这种在去O改造过程当中持续时间会比较长的核心系统。如果把批次上所有的应用代码改造了，首先上线风险会非常大，另外一个整个改造难度和周期也会很大，包括在改造过程中其实这些应用本身一些业务功能在不断上线。如果按批次切分高速迭代的方式去上线，那么在整个推进去O过程中，去O节奏与进度可以做到完全可控。

那么后续去O框架，在生产环境，交易主账户，包括账务系统核心应用我们会差不多持续半年到一年的改造，第一张表去O到最后一张表去O完成会横跨半年到一年左右。其实在框架下会同时会有 Oracle 和 MySQL 提供读写服务，只是流量会一点点从 Oracle 往 MySQL 上搬。

在这个过程中，我们实现了一个稳妥的方法把数据库一点点换掉，对陆金所的4500万注册用户完全不感知。

如何对复杂金融系统的细粒度批次拆分

对于一些传统金融系统可能会呈现出左图的状态，一个重要账务库，生产环境的很多应用都要使用它的数据。如果之前没做过服务化改造，这些应用可能会直接访问账务库的数据；如果账户库去O，那么去O改造将和所有直接访问账户库的系统都有关，这些系统后续都需要参与到账务库的去O改造，如果后续做完服务化改造，把整个账务系统封装成一个服务，每个服务会有它自己的应用和数据库，这些数据库只在服务内部调用，其他系统只是通过一些接口访问，调用的话访问账务库，这样账务库的去O改造可以做到只在账务库内部推进。

基于服务化架构下多批次并行去O改造

这个是我们做全站去O的架构图，包括生产环境的核心服务，账务、用户、交易、资产、基金服务等等，他们都通过同步和异步调用把服务提供出来，在这个过程当中每个研发团队，他们会有自己开发进度来稳妥推动去O，各个研发团队之间对于去O的节奏把控包括上线的把控是由研发团队自己确定的，这样可以大范围推广去O在陆金所全系统的推进。

在去O过程中，像 Oracle 是功能非常强大数据库，我们会引入一些其他的数据库和存储引擎，把它引入到更合适的场景。把 Oracle 所有流量给承接下来。如果使用 MySQL 把 Oracle 全部的流量承接下来是不太现实的，比如在 Oracle 里面有比较多的关联，包括子查询在 MySQL 里面查询性能包括响应时间、优化这块不是特别好。

但是去O完了之后其实对 MySQL 做非常细粒度的拆分，这个过程中可能会有之前在 Oracle 没有做拆分，那么在 MySQL 拆分之后会有跨分片包括跨库的查询，去O就是非常好的架构改造机会，如果可以使用各种新型的存储引擎，当中产生的效果，执行速度会比 Oracle 要快，成本比 Oracle 更低。

我们使用 MySQL 承接金融级事务细分，那么里面会有消息中间件会通过DATABUS数据总线进行秒级同步。

对于这张图就是整站去O完成之后的架构。大家可以看到，在整个应用层，做了非常多细粒度的按域和服务化拆分，我们使用 MySQL 来承接金融级别事务的写入，陆金所内部研发一套叫数据总线的中间件，支持解析 MySQL 的 binlog，把 MySQL 的 binlog 往底层的各种 DB 存储引擎同步，会在不同的存储引擎里把之前跨库查询，进行相关的支持。相对来说，包括我们的查询效率比在 Oracle 表现更好。

这张架构图可以看做陆金所去O完成看成一个整体，把 MySQL 看成写入第一份数据的事务库，这是按用户为粒度的查询，包括一些金融数据提交，都是在 MySQL 提交和持久化。我们可以把后面的使用各种存储引擎（ES、TiDB等）认为是支持不同查询场景的特殊索引结构，在 MySQL 提交完成的瞬间，解析 MySQL 的 binlog，通过数据总线来实现同步后端的各种索引结构。

针对不同场景的查询数据结构，通过不同数据模块把数据当中 MySQL 提交管理一瞬间，通过自动化后端进行同步，这个时候在后端我有不同查询流量，可以看使用 MySQL 引擎是非常适合。

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

首先是 IT 运营成本有非常大幅的降低。

让我们摆脱相关技术绑架。现在陆金所对数据库特性的依赖非常小。去O完成，数据库对于整个金融系统的角色是支持最底层存储引擎的增删改查。

另外一块，对陆金所整个研发团队的能力的提升。去O不仅仅是更换数据库，其实是对金融级系统的架构进行重构，重构有很多架构拆分，包括服务化改造。

这些工作在两年时间里，整个网站不断对外提供服务，在新功能、新版本不断上线的情况下，我们把架构做完对研发人员的提升，内部的自动化运维工具、研发平台工具、研发管理工具是一个非常好的提升和建立。

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

2015年至2016年两年时间，陆金所的业务增长比较迅猛。在IOE设备上的投入也是比较大的。去O完成后，在整个数据库的相关成本上，除了买非常便宜6万块钱PC之外，其他就没有什么费用了。无论是 MySQL 还是一些其他的数据库，在这个过程中都是免费开源的，只要我们有这个技术实力hold住。在生产环境更多把复杂业务逻辑放在应用层而不是放在数据库层，对有一个比较好的架构规范。相对来说，对生产环境的成本有一个比较好的提升。

陆金所去O方案的落地

刚才说了这么多方案架构，大家听了这么多方案架构，我们是怎样在两年之内在生产环境包括开发、运维、测试、架构进行团队之间是怎样配合，让去O稳妥落地，接下来给大家讲一下。

陆金所的做法是建立“人员——规则——工具”的闭环。

我们自己理解，首先去O是非常精细化研发管理工作，核心思路是会不断总结出通用的规范和规则，而难度挑战在于怎么把大量确定的规范和规则让数百个参与去O改造的研发、测试和运维人员都在每行代码、每次变更中把规范有效落地。

对于陆金所来说，整合出一套人员-规则-工具的闭环，来不断地告诉迭代优化这个方案。

首先我们会有一些非常资深的工程师，对 MySQL 的理解，包括对于整个去O研发方案、包括整个研发方向会制定一些规则，通过这些规则会有专门研发团队会把这些规则开发成工具。过去，最终在去O过程当中主要是通过工具来管理整个研发流程，通过工具去确保各种复杂的代码和变更有效落地。而这个过程中规则也在快速迭代和优化，规则优化完成后反馈到工具中，工具再协助去O研发落地规则，形成一个有效的闭环。

我们通过这套高效的闭环体系在两年内完成稳妥的去O落地。去O工具平台除了把人员和规则有效整合其他外，还有两件非常重要的事情。去O改造团队非常多，去O持续两年，本身供应在不停产生改变，要解决架构改造和功能改造之间功能冲突问题，那么里面会有很多工作，整个去O平台需要把这些工作进行有效协调，然后确保跨团队的配合，可以非常有效完成并落地到生产。

陆金所去O落地节奏

这个是陆金所所有落地节奏，前面三个阶段都是在方案，要把方案形成，然后通过方案，我们按照方案把相关去O工具研发出来，然后进入到第三个阶段，我们开发、测试、运维，对于工具使用体验会有反馈。

最后对工具和方案进行优化，人员跟工具之间完全进行磨合，花了1年时间，那等到前三个阶段过完之后，那么进入第四个阶段人员工具，去O工作推进是非常快速，包括整个去O效率都提升。在前面四个阶段做完之后，人员工具磨合等等非常好的情况下花了半年时间完成了去O。

陆金所去O人员投入

这个是去O人员投入成本，这个项目有24个月，那么有400位研发人员参与，我们真正在这个项目当中全程参与的人不到10个人，之后是整个工具研发，包括工具研发和中间件的研发，分别是6个月左右的时间。

那么400人研发团队在前面方案规则上面去做去O工作，他们的效果非常快，不是特别重要核心应用他们开发差不多在2周左右，差不多5%核心服务持续时间3个月以上，400研发人员参与改造时间为3周左右的时间，如果前期把这套规范体系建立起来，那么后续推动去O的效率也是非常快的。

大家看到这块，我们在去O改造过程当中，开发那边差不多有 40% 时间对于底层的SQL代码进行重构，如果让研发人员逐行改造代码，效率非常低，在研发人员不涉及对关联查询进行拆分的情况下，我们研发了SQL转化工具会自动完成Oracle to MySQL的SQL转化工作（转化工具官网https://www.lufaxholding.com/zh-cn/solution/detail/solution/luDBGate/sqlmapo2m/）。

所有代码转换完了之后，在陆金所提交压力测试之前会对所有版本做性能评估参考。

第三块，在去O过程中，从Oracle 往 MySQL 上迁移，上万张表的迁移只有两个人来完成。他们通过自动化运维平台，每张表的表结构转换，按照配置的各种策略，全量增量迁移，包括逐行的数据校验、双写建立这套工作都通过一套自动化平台来完成。去O过程当中，陆金所所有上万张表从0迁移到M，每张表格都需要经历表结构化到最后双写建立全流程变更。

最后这块在整个去O过程当中，这个时候 Oracle 跟 MySQL 以这套数据库建立双写机制，在这个过程中需要对生产环境某张表的索引策略和表结构进行，业务开发人员变更表结构不太需要关心底层数据库是否有做过去O同步，平台会自动把 MySQL 变更语句，包括在 MySQL 里怎么变更一张大表不会锁表，在后台都会处理得很完善。