OceanBase迁移服务：向分布式架构升级的直接路径_架构_Geek_cb7643

如何用AI技术降噪？ QCon 广州“音视频架构实践”专场给你答案！了解详情 



 写点什么

2019 年 1 月 4 日，OceanBase 迁移服务解决方案在 ATEC 城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了 OceanBase 迁移服务的重要特性和业务实践。

蚂蚁数据库架构的三代升级史

在过去的十多年时间里，蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代数据架构是构建在 IOE 的基础之上——IBM 的小型机、Oracle 的商业数据库，还有 EMC 的共享存储。基于第一代 IOE 架构的运维成本是非常高的，同时稳定性的挑战也是非常大的。随着业务的快速发展，这套架构已经完全没有办法适应业务发展的增速。

随之诞生的是第二代架构，第二代架构的主体是 OE——也就是 Oracle 和 EMC，加上蚂蚁自身的分布式中间件，解决了业务的水平和垂直的弹性能力。这一代架构其实伴随着蚂蚁走了很多年。

随着 4G、5G 时代的到来和金融的普及化，人们的生活越来越离不开移动支付，业务井喷式的发展给底层的数据库提出了更高的要求。这些要求包括更高的稳定性，快速恢复能力和极致的弹性能力等。

于是最终演进到了我们如今的第三代架构。第三代架构是由 OceanBase 为代表的金融级云数据库和分布式中间件所构成。

数据库架构升级的挑战

伴随着整个蚂蚁的发展，整个数据库的架构也仅仅演进了三代。这其中一个很重要的原因就是对于任何企业而言，整个数据库的架构升级都是一件非常有挑战的事情。

蚂蚁金服资深技术专家师文汇说道，“用一个我们内部经常说的比喻，就是数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。”

更换引擎的目的是为了拥有更好的动力，做更多技术上的创新。但是横亘在眼前的问题是，如何才能做到稳妥创新，保证驾驶中的飞机平稳顺利的运行，这其实是有非常大的挑战。

在过去三代架构的演进中我们可以看到，本质上每一代架构的迭代基本上都是以两到三年为周期，这其中会有非常高的人力投入和成本开销。

第二个挑战就是从传统的商业数据库迁移到 OceanBase 数据库之上，我们如何保证迁移过程中以及迁移以后的稳定性。

另外一个非常大的挑战就是数据质量，在金融企业里，数据承载的不仅只是钱，更承载了数以亿计用户的信任。所以数据一条不能丢，一条不能错，这是我们做数据库的底线。

当然，包括兼容性问题和性能风险也给数据库的架构升级带来重重挑战。

OceanBase 迁移服务：向分布式架构升级的直接路径

基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案——OceanBase 迁移服务（OceanBaseMigration Service，简称 OMS）。

OMS 的发展演进

OMS 的演进是以业务为驱动，并且与 OceanBase 的架构升级和不断发展密不可分。

早在 2014-2015 年期间，蚂蚁主站上的一些核心业务，包括大家熟知的交易业务，支付业务和会员业务等，需要从 Oracle 迁移到 OceanBase 上。当时的 OMS 还是以一个工具类、模块化的形态支撑着这些项目。

所以在 2015 年我们开始对 OMS 的方案进行全面的调研，力求沉淀出通用的系统化的解决方案。

在 2016 年，OMS 已经有了平台化的架构，引入了大规模编排的思想，将整个迁移特别是切换过程中繁琐易错的环节全部集成到平台。这一时期，OceanBase 也完成了从 0.5 版本到 1.0 版本的架构升级，这一年 OMS 还支撑了网商银行、印度 PayTM 以及主站的核心业务升级到 OceanBase 1.0 版本。

到了 2018 年的时候，无论在基础功能层面还是任务编排层面，OMS 都已经被打磨得日趋完善。今年 OMS 已经支持了蚂蚁森林，蚂蚁商户平台以及众多大量核心及非核心的业务从 MySQL 迁移到 OceanBase 之上。与此同时，在外部业务包括很多已经上线 OceanBase 的商业银行，也已经验证了使用 OMS 一键迁移到 OceanBase 的能力。

OMS 的方案优势

OceanBase 迁移服务其实主要解决了五个重要的问题。

1.负载回放验证：其中第一个核心的问题就是负载回放验证，通过采集源端数据库的 SQL 流量，在目标库 OceanBase 上回放，可以验证其在 OceanBase 上的功能是否兼容、性能是否出现问题等。同时基于蚂蚁 DBA 十多年的经验沉淀，OMS 会为客户提供性能等方面的调优建议。

2.秒级数据校验：第二点就是数据校验，OMS 有三层数据校验，可以做到秒级的延迟。举一个例子，比如说我们想把传统商业数据库替换成 OceanBase，如果在迁移过程中任何一条数据出现了错误，在一秒钟内就可以快速发现。校验的延迟可以完全保证在一秒以内，根据蚂蚁线上的经验，大概在 100-200 毫秒之间。

3.分钟级即时回滚：第三点也是最重要的一点，就是 OMS 有随时回滚的能力，而且回滚是无损的。这也是我们前面所强调的稳妥创新的基石。

4.多种数据库类型支持：目前 OMS 支持源端数据库类型有 Oracle、MySQL、OceanBase 等等，支持全量迁移和增量数据同步。

5.一键完成迁移：整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成，使用简便。

OMS 的技术架构

OMS 的核心方案其实非常简单，我们把 OceanBase 变成 Oracle/MySQL 的一个备库。

传统的商业数据库一般都是有主库和备库的：主库承担写的流量，如果主库出现问题，我们会把数据切到备库，然后通过 OMS 提供的一整套虚拟主备库的解决方案完成切换。比如原来 Oracle 有一个主库一个备库，然后 OceanBase 其实变成了一个虚拟的备库。

整个数据库架构的升级也会变得异常简单，简单到只是做了一个主备切换。回滚也会变得非常简单，其实也是做了一次主备切换。

从 OMS 的整体架构来看，其实一个非常关键的点就是，我们在传统的商业数据库和 OceanBase 之间建立了一套虚拟的主备链路，整个 OMS 里用到的所有组件，其实都是在蚂蚁和阿里有很多年技术沉淀的，也都是基于真实场景所产生的。

OMS 的迁移流程

OceanBase 迁移服务的整体迁移流程其实只有七步。

1.评估：首先第一步是通过负载回放工具做兼容性分析;

2.PoC：接下来 OceanBase 云平台可以帮助客户部署一套 PoC 集群;

3.预迁移：然后 OMS 把线上的 Oracle 的数据预迁移到一个测试库里；

4.验证：在这个测试库里用负载回放工具去回放这些 SQL，然后找到 SQL 里不兼容，性能或者数据质量不满足预期的部分，并提供优化建议；

5.正式迁移：前四步做完了以后，业务需要调整或者需要优化的 SQL 已经完成优化，然后就可以正式迁移了。首先把原有的全量数据迁过来，然后再把增量变化的那部分数据实时同步过来；

6.校验：等到所有的数据准备好以后，然后我们继续完成三级校验；

7.切换和回滚：等到所有的校验都完成以后，可以一键完成切换和回滚功能。

通过这七步就可以轻松完成从传统商业数据库到分布式数据库的完整迁移。

蚂蚁商户平台基于 OMS 的业务实践

蚂蚁商户平台承载着商户档案数据信息，订购关系、签约信息的数据和相应的服务能力。其中一部分业务使用的是 MySQL 数据库，还有一部分核心业务使用的是 Oracle 数据库。

随着商户的快速增长以及业务场景的不断丰富，商户平台数据增长迅速，数据规模相当庞大。尤其是 MySQL 的单表瓶颈日益明显，DDL 变更、DML 更新的性能与风险已经无法承担。

蚂蚁金服技术专家韩谷悦介绍道，“OceanBase 能够支持数据的无限扩展，满足商户业务的容量与性能需求。那么如果我们换一种数据库底盘，其实所要面对的性能、稳定性和数据质量的风险同样不可避免。”

从蚂蚁商户平台的业务实践来看，使用 OMS 迁移与传统迁移进行对比，我们可以看到：

业务评估和改造

过去通常一个业务少则花费 1-2 个月的时间去做改造和适配；那么基于 OMS 自动化的 SQL 兼容性评估和负载回放的能力，蚂蚁商务平台业务的改造大概只用了一个星期的时间。

数据迁移和校验

客观来讲，迁移的总时长主要取决于业务数据模型，数据量和网络环境。在提高迁移效率方面，OMS 目前增量迁移的延迟仅为毫秒级，跨城情况下最长只需要 3 秒。并且针对校验出的数据差异提供补齐的 SQL 和订正方案，使得迁移和校验的整体效率有了大幅度的提升。

业务切换

其实在切换之前，往往需要制定严密的切流方案和 Failover 方案，整个切换过程中需要检查与校验的细节非常繁琐，任何一步疏忽都有可能造成数据不一致的问题。那么 OMS 通过引入大规模编排的思想把所有繁琐复杂的环节通通落到平台当中。所以从原来业务切换需要用时 1-2 周时间，使用 OMS 后蚂蚁商户平台业务无论是切读还是切写的过程中都只用了几分钟的时间。