“GotoOracle”是近10年来描述系统架构转型最常用的词之一。虽然“上Oracle”被很多工程师和技术从业者挂在嘴边，但是业界能把所有系统都上Oracle的案例并不多，尤其是金融场景的核心系统。那么去Oracle有什么难的呢？为了回答这个问题，我们首先需要了解Oracle架构转型的本质是什么？去Oracle架构改造的本质之一就是让系统架构具备在线替换数据库的能力。不管去Oracle的目标数据库是MySQL还是其他关系型数据库，最终都要解决这样的问题。在线改库的难点在哪里，会遇到什么问题？1、如何无感知迁移实时动态数据？首先，数据库并不是交易系统的核心组件之一，评价数据库的重要性一点也不为过。目前大部分知名网站和系统对外提供7x24小时的服务，数据库也7*24小时不间断地处理着大量的读写服务。要实现Oracle意味着你必须在一个Oracle库中，并且仍然对外开放。在提供服务时，让一个MySQL库在某个时间点快速替代Oracle库，顺利接管所有Oracle服务。不同于无状态的系统组件切换，切换工作是通过切断流量来完成的。作为一个有状态的系统组件，如何设计一套安全的Oracle解决方案，从应用改造，到数据同步，再到数据库流量切换，都可以将对外提供服务的Oracle数据库上的数据进行无缝迁移，这是非常谨慎的并且数据是实时变化的状态到MySQL。2.如何管理和协调高频迭代的去预言机改造和功能改造？其次，Oracle架构改造的主要工作是重构应用层代码，尤其是DAO（DataAccessLayer）重构。对于一些复杂的系统，重构的时间会持续几个月甚至更长。在Oracle转型的这个漫长的时间窗口中，不仅Oracle库的数据在动态变化，而且对于一个正在高速迭代的网站和系统来说，应用的功能代码也在不断变化。如果A团队正在为应用改造Oracle架构，而B团队在此期间不断为应用开发新功能，那么如何拆分去除Oracle的工作才能有效地管理和协调两个开发团队的编码和上线What关于节奏？3、如何安全实现数据库流量的在线切换？当某库的应用改造到Oracle上线后，生产环境的流量会从Oracle切换到MySQL。在这个切换过程中，如何保证Oracle上的最后一个事务成功提交并同步到MySQL完成数据一致性校验，并且对这个Oracle库的所有写操作都可以快速完全切换到MySQL，而不会有一些写Oracle流量，部分MySQL写入流量，出现两个数据库双写的异常状态。流量切换到MySQLa后，如果出现之前压测或准备工作没有涉及到的应用错误或bug、MySQL性能问题等突发情况，如何快速将流量切换回Oracle，保证写入数据也可以完全一致的回传给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的部分计算和存储能力。场景中使用ES、HBase、TiDB、Impala+kudu等存储引擎，甚至应用层的代码来承接和替代Oracle，整体收益优于使用Oracle。以上是陆金所全站上甲骨文过程中遇到的五大类实际问题。整站去O的过程中还有很多细节问题需要解决。结构改造本身就需要技术团队在每一个细节上处理各种细节。
