金融系统去 Oracle 实践，到底需要解决哪些问题？

“去 O”一直是最近 10 年描述系统架构改造中最常出现的词之一。虽然“去 O”被很多工程师和技术从业者津津乐道，但业界真正能实现把系统全部去 O，特别是金融场景的核心系统全部去 O 的案例并不多。那么去 O 到底难在哪里呢。

为了解答这个问题，首先我们要理解去 O 架构改造的本质是什么？去 O 架构改造的本质其一是让系统架构具备在线更换数据库的能力，无论去 O 的目标库是 MySQL，或是其他的关系型数据库，最终都是要解决这样一个问题。

在线更换数据库到底难在哪里，会遇到哪些问题呢？

问题一：如何无感知的实时动态数据的迁移？

首先数据库作为交易型系统最核心的组件没有之一，这一点对于数据库的重要性评价一点都不夸张。当前大部分知名的网站和系统都是 7x24 小时对外提供服务，数据库也是 7*24 小时无时不刻处理着大量的读写服务，要实现去 O 就意味着你要在一个 Oracle 库还在对外提供服务的时候，在某个时间点让一个 MySQL 库快速替换掉 Oracle 库，并平稳的接管 Oracle 的所有服务。

不同于无状态的系统组件切换把流量切走即完成切换工作，而数据库作为有状态的系统组件，如何设计一套从应用改造、到数据同步、再到数据库流量切换的稳妥去 O 方案，可以非常谨慎的把一个正在对外提供服务，数据处在实时变化状态的 Oracle 库上的数据无缝的方式迁移至 MySQL 中。

为了有效解决这个问题，陆金所研发的去 O 工具包含一整套完善的在线数据迁移功能。在工具中勾选需要去 O 的 Oracle 表，工具会自动完成 O to M 的全量同步、增量同步，并通过解析 Oracle redolog 来追增量日志，最终形成一个 Oracle 为主库，MySQL 为备库的异构实时备库。

问题二：如何管理和协调好高频迭代的去 O 改造和功能改造？

其次去 O 架构改造的主体工作是对应用层代码的重构，特别对 DAO（数据访问层）的重构，对于某些复杂的系统来说，重构的时间会持续数月甚至更久。在这段漫长的去 O 改造时间窗口里，不但 Oracle 库的数据在动态发生变化，对于一个处在高速迭代中的网站和系统来说，应用的功能代码也在不断发生变化。如果 A 团队在为应用做去 O 架构改造，而这个期间 B 团队在不断的给应用开发新的功能，如何进行去 O 的工作拆分可以有效的管理和协调好两个开发团队的编码和上线节奏呢。

为了有效应对这个场景，陆金所研发的去 O 工具会在去 O 架构改造和应用业务改造之前进行有效协调，并向业务开发尽可能屏蔽去 O 架构改造的影响。比如业务改造需要在处于 O 和 M 并行双写的库上修改表结构并发布新的数据库访问接口，大量的工作会由去 O 工具来自动化完成。

问题三：如何稳妥落地数据库流量的在线切换？

当某个库的应用去 O 改造完成并上线后，会实施生产环境 Oracle 的流量切换到 MySQL 上。在这个切换过程中，如何确保 Oracle 上的最后一笔事务提交成功，并同步到 MySQL 后完成数据一致性校验，且针对这个 Oracle 库的所有写操作能在快速、全部切换到 MySQL 上，不会出现部分写流量 Oracle，部分写流量 MySQL，两库双写的异常状态。

当流量切换到 MySQL 后 a，如果出现应用报错或 bug、MySQL 性能问题等在前期压测或准备工作中未覆盖到的突发情况，如何实现流量快速回切到 Oracle 上，且确保在 MySQL 中写入的数据也能完全一致的回到 Oracle 中。

解决好这个问题，是控制好去 O 落地风险的核心所在。陆金所设计了一整套在线切换数据库的架构框架来确保在瞬间把流量从 Oracle 切走到 MySQL 中，同时也可以瞬间把流量切回到 Oracle，并确保两边的数据完全一致。

问题四：如何有效拆分去 O 的任务，从而实现对全站业务单次影响小、迭代频度快的去 O 上线？

要实现全站去 O，必然面临着对一些复杂、庞大的核心系统进行去 O 改造。以陆金所为例，在全站中像用户中心、资产中心、资金账户等这种给全站所有金融产品线都提供基础服务的子系统就是这类复杂和庞大的核心系统，同时包括基金、主账户等专属金融产品线的业务逻辑复杂，所以子系统也非常庞大。

所以对于这类子系统，如果需要在一个大版本里全部去 O 改造完成，并在一个晚上业务低峰期一次性全部从 O 切换到 M，无论是当晚的切换风险，还是切换完成后，在第二天业务高峰期出现问题和 bug 的风险，包括开发团队短时间内去 O 改造的工作量和出现重大 bug 的机率都是非常大且不可控的。

如何把一个庞大且重要的复杂子系统拆分成多个去 O 的版本按批次上线和切换流量，且做到单个批次影响可控，也是全站去 O 中需要谨慎设计的方案。

而这也是整个去 O 过程中架构设计最有趣的部分。

上面提到了去 O 中在架构层实现在线换库需要解决的四大问题。除了在线换库外，去 O 架构改造的本质其二是引入更多的存储引擎在合适的场景来承接 Oracle 数据库的计算和存储能力。这就引出了第五个问题。

问题五：如何在各种场景下使用合适的开源存储引擎来去 O，并且在架构上进行融合。

首先 Oracle 是个非常强大的关系型数据库，无论在 OLTP 和 OLAP 场景表现都很出色，且具备一整套完善、好用的运维和监控工具。但于此同时 Oracle 虽然对各种场景支持较为全面，但在各个特定场景下，一些开源的数据库或存储引擎在性能或成本投入的综合考量上胜过 Oracle，都会是比 Oracle 更合适的选择方案。

所以全站去 O 不仅仅是去 O 到 MySQL 中，MySQL 能承接的只是 Oracle 的部分计算和存储能力，在整个陆金所的全站去 O 落地过程中，除了 MySQL 外，我们还在不同的场景下使用 ES、HBase、TiDB、Impala+kudu 等存储引擎，甚至是应用层的代码来承接和替换 Oracle，并且整体收益比使用 Oracle 更好。

在完成去 O 后，陆金所的生产环境出现了大量开源的存储引擎来支撑各种合适的业务场景。同时我们也研发了数据总线平台来实现数据在一个地方写入和提交，秒级同步到其他存储引擎的架构。

上述是陆金所在全站去 O 过程中遇到的 5 个实战问题大类，整个全站去 O 过程中需要解决细节问题还有很多，这里无法一一列举，因为去 O 作为一个复杂的系统架构改造本身就要求技术团队事无巨细的处理好各种细节问题。

基于此，陆金所优化和开发了一整套方案和工具来，有效推进去 O 改造稳妥落地且保障风险可控。后续会推出一个系列的去 O 专题和大家分享，希望给有去 O 改造计划的技术团队和公司带来一些参考和借鉴价值，敬请期待。

作者介绍：

王英杰，陆金所数据架构团队负责人，负责陆金所全站存储引擎运营和智能化工具研发。