金融系统去Oracle实践，到底需要解决哪些问题？
发布时间：2020-03-13 10:39:07 所属栏目：资源 来源：站长网
导读：“去 Oracle ”一直是最近 10 年描述系统架构改造中最常出现的词之一。虽然“去 Oracle”被很多工程师和 技术 从业者津津乐道，但业界真正能实现把系统全部去Oracle，特别是金融场景的核心系统全部去 Oracle 的案例并不多。那么去Oracle到底难在哪里呢。
“去 Oracle”一直是最近 10 年描述系统架构改造中最常出现的词之一。虽然“去 Oracle”被很多工程师和技术从业者津津乐道，但业界真正能实现把系统全部去Oracle，特别是金融场景的核心系统全部去 Oracle 的案例并不多。那么去Oracle到底难在哪里呢。 为了解答这个问题，首先我们要理解去 Oracle 架构改造的本质是什么？去 Oracle 架构改造的本质其一是让系统架构具备在线更换数据库的能力，无论去 Oracle 的目标库是 MySQL，或是其他的关系型数据库，最终都是要解决这样一个问题。 在线更换数据库到底难在哪里，会遇到哪些问题呢？ 1.如何无感知的实时动态数据的迁移？ 首先数据库作为交易型系统最核心的组件没有之一，这一点对于数据库的重要性评价一点都不夸张。当前大部分知名的网站和系统都是 7x24 小时对外提供服务，数据库也是 7*24 小时无时不刻处理着大量的读写服务，要实现去Oracle 就意味着你要在一个 Oracle 库还在对外提供服务的时候，在某个时间点让一个 MySQL 库快速替换掉 Oracle 库，并平稳的接管 Oracle 的所有服务。 不同于无状态的系统组件切换把流量切走即完成切换工作，而数据库作为有状态的系统组件，如何设计一套从应用改造、到数据同步、再到数据库流量切换的稳妥去 Oracle 方案，可以非常谨慎的把一个正在对外提供服务，数据处在实时变化状态的 Oracle 库上的数据无缝的方式迁移至 MySQL 中。 2.如何管理和协调好高频迭代的去 Oracle 改造和功能改造？ 其次去Oracle 架构改造的主体工作是对应用层代码的重构，特别对 DAO（数据访问层）的重构，对于某些复杂的系统来说，重构的时间会持续数月甚至更久。在这段漫长的去Oracle 改造时间窗口里，不但 Oracle 库的数据在动态发生变化，对于一个处在高速迭代中的网站和系统来说，应用的功能代码也在不断发生变化。如果 A 团队在为应用做去 Oracle架构改造，而这个期间 B 团队在不断的给应用开发新的功能，如何进行去 Oracle 的工作拆分可以有效的管理和协调好两个开发团队的编码和上线节奏呢。 3.如何稳妥落地数据库流量的在线切换？ 当某个库的应用去Oracle 改造完成并上线后，会实施生产环境 Oracle 的流量切换到 MySQL 上。在这个切换过程中，如何确保 Oracle 上的最后一笔事务提交成功，并同步到 MySQL 后完成数据一致性校验，且针对这个 Oracle 库的所有写操作能在快速、全部切换到 MySQL 上，不会出现部分写流量 Oracle，部分写流量 MySQL，两库双写的异常状态。 当流量切换到 MySQL 后 a，如果出现应用报错或 bug、MySQL 性能问题等在前期压测或准备工作中未覆盖到的突发情况，如何实现流量快速回切到 Oracle 上，且确保在 MySQL 中写入的数据也能完全一致的回到 Oracle 中。 4.如何有效拆分去Oracle 的任务？ 要实现全站去 Oracle，必然面临着对一些复杂、庞大的核心系统进行去 Oracle 改造。以陆金所为例，在全站中像用户中心、资产中心、资金账户等这种给全站所有金融产品线都提供基础服务的子系统就是这类复杂和庞大的核心系统，同时包括基金、主账户等专属金融产品线的业务逻辑复杂，所以子系统也非常庞大。 所以对于这类子系统，如果需要在一个大版本里全部去 Oracle 改造完成，并在一个晚上业务低峰期一次性全部从 Oracle 切换到 M，无论是当晚的切换风险，还是切换完成后，在第二天业务高峰期出现问题和 bug 的风险，包括开发团队短时间内去 Oracle 改造的工作量和出现重大 bug 的机率都是非常大且不可控的。 如何把一个庞大且重要的复杂子系统拆分成多个去 Oracle 的版本按批次上线和切换流量，且做到单个批次影响可控，也是全站去 Oracle 中需要谨慎设计的方案。 上面提到了去 Oracle中在架构层实现在线换库需要解决的四大问题。除了在线换库外，去 Oracle 架构改造的本质其二是引入更多的存储引擎在合适的场景来承接 Oracle 数据库的计算和存储能力。这就引出了第五个问题。 5.如何使用合适的开源存储引擎去Oracle，并在架构上进行融合 首先 Oracle 是个非常强大的关系型数据库，无论在 OLTP 和 OLAP 场景表现都很出色，且具备一整套完善、好用的运维和监控工具。但于此同时 Oracle 虽然对各种场景支持较为全面，但在各个特定场景下，一些开源的数据库或存储引擎在性能或成本投入的综合考量上胜过 Oracle，都会是比 Oracle 更合适的选择方案。 所以全站去 Oracle 不仅仅是去 Oracle 到 MySQL 中，MySQL 能承接的只是 Oracle 的部分计算和存储能力，在整个陆金所的全站去 Oracle 落地过程中，除了 MySQL 外，我们还在不同的场景下使用 ES、HBase、TiDB、Impala+kudu 等存储引擎，甚至是应用层的代码来承接和替换 Oracle，并且整体收益比使用 Oracle 更好。 上述是陆金所在全站去 Oracle 过程中遇到的 5 个实战问题大类，整个全站去 O 过程中需要解决细节问题还有很多，这里无法一一列举，因为去 Oracle 作为一个复杂的系统架构改造本身就要求技术团队事无巨细的处理好各种细节问题。（编辑：92站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |