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

【InfoQ去Oracle实录：如何在线更换金融核心场景中的数据库？】同时因为批次的粒度细，在做去 O 变更切换流量时，对整个金融核心系统的影响也可控。基于这种思路，就可以实现“小步快跑”的高速迭代方式来改造应用、上线版本以及切换流量。即每次只改动核心系统的一小部分，改动完成后快速测试、快速发版上线、并且风险可控的把这部分流量切换到 MySQL 运行，如果有问题依靠强大的流量切换框架，快速把流量回切回 Oracle 。
从图中大家可以看到一个庞大的金融核心系统去 O 改造中，应用改造、上线版本和流量切换这 3 件事情实在并行落地的。
最开始是应用改造，改造完了上线发版，发版后就有了这个批次 O 和 M 的流量开关，并具备了切换条件，之后在某个变更日把流量从 O 切换到 M ，如果遇到任何问题可以快速切回来。应用版本在不断上线迭代，流量在分批次不断切换，一个庞大的金融核心系统就在多次高速迭代中一点点的从 O 切换到了 M 。
整个过程对核心业务不影响、不感知，且对参与去 O 的开发、测试和运维开展去 O 工作非常友好，让他们可控的去落地各项工作。
在这个过程中，从第 1 张表从 Oracle 切换到 MySQL ，到最后一张表关闭 Oracle 流量，在非常长的一段时间内，整个应用是由 Oracle 和 MySQL 在同时提供服务。其中某些表已经完成去 O ，读写的流量在 MySQL 上，由 MySQL 同步到 Oracle ，部分表还未完成去 O ，读写流量在 Oracle 上，由 Oracle 同步至 MySQL 。这就非常考验运维的能力，要确保在这个架构下每天高频的各种发版和数据库变更都非常准确。
基于此，陆金所是有研发一整套配套去 O 变更工具，来确保整个去 O 过程中大量变更准确实施和落地。以陆金所交易、主账户、资产中心、基金、账务等核心库为例，从第一张表流量切换到 MySQL 到最后一张表切换到 MySQL ，历时 12 个月以上。按照上述方案一点一点的替换掉 Oracle 数据库，整个过程完全不做服务降级，对陆金所的 4500 多万用户无感知。
4
陆金所去 Oracle 方案的落地
在 PPT 中画出去 Oracle 的架构图是很简单的事情，但是架构改造的难点和重点在于落地。要在生产环境落地是非常庞大且复杂的系统工程，尤其是对一个 7*24 小时的金融核心系统来说，进行重大架构改造本身就是一件高风险的工作，既要做到规避风险，确保各种工程实现细节有效落地，同时又要保证系统的业务连续性，甚至是对外部用户不感知。
去 Oracle 架构改造的本质是什么？我觉得有两方面，一是细节规则，二是上生产前发现和上生产后兜底。
去 O 的重点不仅仅是方案本身，更重要的是组成方案的数百条细节规则，能在一个参与去 O 的、庞大的研发团队里每个开发所写的每一行代码都有效遵守规则，同时在每个运维设计的生产变更方案里每一条命令都有效遵守规则。方案通过从边缘系统往核心系统逐步推进过程中，会逐步趋于完善，方案中的规则也会被逐步积累和完善起来，那么把这些规则落地到研发团队的每个人上，是关键和重点。
上生产前发现是指如果规则在某个微小的细节实施时没有被遵守，如何尽可能的在上生产环境之间发现隐患。上生产后兜底如果问题突破了所有检测环节上了生产，如何设计一个兜底方案可以有效控制风险，把影响尽可能降低。
去 Oracle 落地工作都应该围绕有效解决这两个本质问题展开，并提升这两个问题的解决效率，降低人力成本。
陆金所的做法是建立“人员——规则——工具”的闭环。
陆金所通过“人员制定规则——规则通过工具落地——工具确保所有人员的代码和变更符合规则”的方式来确保各种细节工作落实到位，整套工具最终沉淀为陆金所数据库升级平台。