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

以陆金所的去 O 落地经验来看，一个不起眼的细节问题如果未进行有效管控，都有可能引发严重的生产故障。所以我们可以把陆金所数据库升级平台理解成为一套强大的去 O 风控系统。这套风控系统覆盖 SQL 重构、表结构转化、数据迁移、数据校验、分布式事务构建、流量切换等横跨从开发到运维在去 O 架构改造方方面面会遇到的问题。通过这套工具平台，有效确保参与去 O 的研发团队在每个细节上都处理的非常规范，从而实现历时 24 个月的全站去 O ，无风险平稳落地。

本文插图
除了确保各种规则精准落地外，金融核心系统去 O 改造需要多个研发团队协同作战、有效配合、共同推进。其中涉及到大量工程实现细节工作需要多团队有条不紊、事无巨细的协同配合好。任何疏漏都有可能会引发严重的生产故障。
5
经验总结：谈谈企业去 Oracle 的目标
去 Oracle 的口号喊了很久了，但是为什么要去 Oracle ，去 Oracle 想要达到什么样的目标...... 有些企业可能没有想得很清楚，所以我也想从自己的角度和经历来谈谈去 Oracle 的目标。
目标一：省钱
去 O 完成后，使用“免费的开源数据库 + X86 架构的 PC Server”来搭建金融核心系统，真的很省钱。因为搭建金融核心系统从昂贵的高端服务器、高端存储和 Oracle 一体机，以及昂贵的 Oracle 软件授权变成只需要 6 万一台的 X86 服务器，花在数据库上的运营成本降为之前的 10% 不到。

本文插图
在整个去 Oracle 的过程中，陆金所架构从一个传统金融的超大型数据库支持各种核心业务的架构变成了以微服务化驱动的分布式架构，这种架构具备以下特点：
每个服务有自己独立的应用和数据库。
每个库只提供给服务内的应用直接访问，即服务内的应用可以通过 SQL 访问。
服务之外的应用访问数据库需要走应用层的服务接口，避免跨服务访问数据库。
服务分为同步调用和异步消息。
在服务内实现数据库的水平扩展。
对于类似用户、交易、资金等公共类基础服务，逐步迭代为中台服务。
通过微服务化拆分，几套集中式的 IOE 大库就变成了微服务小库，同时对于访问量和数据量较大的中台服务，又会进一步细粒度水平拆分。
目标二：架构升级和改造
除了降低成本，我认为更重要的是通过去 O 实现传统金融系统全方位的架构升级和改造。

本文插图
对于一个传统金融系统来说，借助去 O 来实施和落地全系统的架构改造和升级，应该是一个再好不过的机会。以陆金所为例，通过去 O 实现了以下的升级和改造：
数据库底层计算和 IO 能力的水平扩展，并且这种水平扩展完全基于 6 万一台的 X86 服务器，扩容成本极低。
同时实现了应用访问数据库的规范化，应用和应用之间的服务化。全站的调用链会非常清晰，应用和数据库之间不合理的依赖将大幅降低。
另外实现数据库层去中心化，单个数据库的可用率对全局可用率影响有限，消除中心化的单点隐患
最后借助去 O 实现的分布式架构，可以把各个分片的数据库部署在不同的机房，从而实现真正意义上的机房多活。
目标三：引入更合适的存储引擎
提到去 Oracle ，可能很多人在第一时间就想到了 MySQL 。其实， MySQL 是承接 Oracle 主要流量的数据库，但 MySQL 无法承接 Oracle 的全部流量，例如以下几类经典场景：