“去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改造计划的技术团队和公司带来一些参考和借鉴价值，敬请期待。

作者介绍：

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

创作场景

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