InfoQ去Oracle实录：如何在线更换金融核心场景中的数据库？

作者 | 王英杰
策划 | 田晓旭
本文会分享陆金所在线换库的全过程，详细剖析陆金所设计的在线换数据库方案，整套方案又是如何在一个复杂庞大的金融系统里，通过多团队紧密配合稳妥落地。希望阅读本文之后，能够让大家深入了解金融核心系统去 Oracle 的难点和风险，并给想去 Oracle 但是不敢落地实施的同学提供真正的实战案例解决思路。
陆金所从 2018 年启动全站去 O 项目以来，在不做任何服务降级的情况下，历时 2 年通过上百次变更，把全站 98% 的 Oracle 数据库无缝切换到 MySQL 上。其中，这 98% 的数据库覆盖了陆金所的账务、资金、资产中心、支付、交易、用户、基金、主账户、网贷、资管、银行理财等全金融场景。整个去 O 的全程 0 故障、0 风险、对用户几乎不感知。

本文插图
陆金所去 Oracle 实践有四大特点：
一是在线更换数据库，不做服务降级。让去 O 这类重大架构改造实施落地的时候对全站用户影响最小，同时也最考验去 O 的架构改造的技术实现能力。
二是对于高频上线了上百次的去 O 变更，全程 0 故障、0 风险，这一点非常考验陆金所去 O 的变更工具水平。
三是在短短 24 个月的时间完成全站 98% 的数据库去 O 改造，并且涉及陆金所全部最核心的业务，去 O 的整体落地效率非常快。
四是在去 O 各个环节实现了从开发、测试到运维各种自研智能工具来把控去 O 各个核心环节的质量，这也是把一个庞大、复杂、高风险的金融核心系统，在非常短的时间内 0 风险、0 故障，稳妥落地去 O 的关键。
1
陆金所为什么要全站去 Oracle？
陆金所为什么需要启动去全站去 O ，并且是 100% 全部去 O 。

本文插图
在去 O 项目立项之初，我们希望通过去 O 来实现三个方面的提升。
首先是降低昂贵的金融系统数据库运营成本。 2013 年至 2018 年期间，陆金所的业务成长了上百倍。业务量增长带来的数据库运营成本暴增。无论是传统的 IOE 架构还是去 IE 后的 X86+Oracle 分布式架构都是如此。 IOE 架构下，高端服务器和高端存储的价格随着提供的计算和 IO 能力呈现指数型增长。 X86+Oracle 架构下，分布式改造和数据库细粒度水平拆分后虽然没有 I 和 E 的成本，但数据库节点暴增后导致 Oracle 软件授权费用暴增。
其次是希望通过去 O 来打造一个不依赖特定数据库特性的金融交易系统，彻底摆脱被商业数据库厂商技术绑架的风险。传统金融交易系统使用数据库特性承担了大量的业务逻辑和架构属性，造成系统对某个数据库特性的强依赖，也大大增加了被技术绑架的风险。陆金所通过全站去 O 实现了把金融交易系统里数据库的角色转化为只支持基本增、删、改、查的存储引擎，全站系统架构弱依赖数据库特性。
最后一点也是最重要的一点，我们希望通过全站去 O 这样一个涉及到开发、测试、架构、DBA 等全部研发团队都参与的重大架构改造项目，来锻炼研发队伍、提升研发能力，并把历史上一些架构设计不完善的地方，通过全站去 O 进行重构。因为去 O 不仅仅是更换数据库，更重要的是落地架构拆分、微服务化、分布式事务等配套的大量架构改造工作。这些工作需要开发、架构、测试、运维高度协同配合，并稳妥落地。所以去 O 是非常考验研发团队技术水平的架构改造项目。通过，我们也希望通过去 O 打造“研发规范——研发工具——研发人员”的研发管理体系闭环。这一块我们在后面会详细展开，并向大家进行介绍。