【观察】OMS 发布，产品化加速 OceanBase 商业落地！

经常看笔者文章的朋友，对 OceanBase 应该不会陌生，源自蚂蚁金服和阿里巴巴业务，且完全自主研发的一款金融级分布式关系数据库。

作为数据库领域的观察者，笔者见过不少号称自主研发或基于开源软件二次开发的商业数据库产品，OceanBase 是其中为数不多，让笔者觉得靠谱的数据库产品，因为它来自于业务的真实需求，更为重要的是接受了业务的检验。

试问，一个连自己都不敢用或从未在真实业务中采用的数据库产品，让客户去当小白鼠，客户又如何能放心去使用？ 这些年，数据库技术领域风起云涌，引发了百花齐放的盛局，但细数众多的新兴数据库产品，真正能做到这点的却很少，稳定性、性能都无法让市场信服。

全球最大的云计算公司，亚马逊 AWS 的技术实力毋庸置疑，自研数据库产品很多，从关系数据库、数据仓库到 NoSQL 数据库一个不缺，但即便如此，亚马逊自家核心业务系统却依旧跑在 Oracle 之上。

而 OceanBase 早在商业化之前，就已经在支付宝的核心业务上落地。据了解，目前支付宝全部核心业务：交易、支付、会员、账务系统均运行在 OceanBase 数据库上。

每年的“双十一”则是对 OceanBase 的一次大规模压力测试。2017 年更是创造了 4200 万次/秒处理峰值的纪录，这在全球也是绝无仅有的。

不过，作为新兴数据库产品，OceanBase 虽然风光无限，但也同样面临挑战，那就是产品化不足。因为，不是每家金融企业都有着阿里般强大的技术能力，这势必导致对产品化依赖程度很高。

蚂蚁金服资深总监冯柯对笔者说，OceanBase 在商业化输出过程中，一开始，的确遇到不少这方面的问题。同一个组件，在阿里内部用的很好，但跑在外面就会出现各种各样的问题。因此，在过去的一年里，OceanBase 团队在产品化上做了很多。

2018 年 9 月，OceanBase2.0 发布，在产品化之路上又迈出一大步。同时，还对 OCP（OceanBase 云平台）做了大规模版本升级，最核心的变化是把平台原来依赖的所有外部组件全部去掉，从而使得 OCP 进化成可以在外部独立部署的通用型产品。

在 2.0 发布不到 4 个月，2019 年 1 月 4 日，蚂蚁金服 ATEC 城市峰会上，又正式发布了一站式 OceanBase 迁移服务 OMS（OceanBase Migration Service），该服务目前支持的数据库包括 Oracle、MySQL、OceanBase。

实际上，OMS 并不是凭空出现，而是做了很多年。蚂蚁金服资深技术专家师文汇告诉笔者，在过去的十多年时间里，蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代的 IOE 架构，第二代的 OE+分布式中间件架构，第三代架构是 OceanBase+分布式中间件。架构的迭代，涉及到大量的数据库迁移工作。到了第三代，更是涉及核心业务全面从 Oracle 往 OceanBase 迁移，非核心业务从 MySQL 向 OceanBase 迁移。

据蚂蚁金服技术专家韩谷悦介绍，OMS 方案调研于 2015 年启动，基于此前大量迁移积累的经验和踩过的坑，到 2016 年 OMS 已经有了平台化的架构，与此同时，OceanBase 从 0.5 升级到 1.0。2017 年，OMS 在技术功能和任务编排方面已日趋完善，并完成长尾 Oracle 库的迁移，2018 年完成 MySQL 迁移到 OceanBase。与此同时，在商业银行也实现了 OceanBase 一键迁移。

通常在数据库迁移中，企业最关注 3 个方面的问题，其一、如何平滑迁移已有的数据和应用？众所周知，企业应用绝大多数都是围绕数据库来开发，因此，在决定采用新数据库之前，如果无法准确掌握业务改造的工作量，就无法有效控制项目进度风险。如果无法对新系统进行准确的容量评估，就无法提前识别和规避切换后系统可能出现的性能问题。

其次，如何最大化的降低数据迁移的成本？如果无法保证关键数据迁移过程中的迁移效果和数据质量，长时间的业务停机将是不可避免的。这对绝大多数企业尤其是金融企业来说，是无法接受的。如果切换后一旦新系统发生不可预期的稳定性问题，没有整体可回滚能力，那业务就将严重受损。

最后是如何将时间压缩到最短？带着这 3 个问题，我们看看 OMS 的迁移能力与优势。

以蚂蚁商户平台数据库迁移为例，蚂蚁商户平台主要承载商户档案，订购关系、签约等数据和相关服务能力，在迁移到 OceanBase 之前，业务有部分跑在 MySQL 之上，也有部分跑在 Oracle 之上。

随着商户不断增加及线上线下业务场景的不断丰富，商户平台的整体数据规模已经非常庞大，并且还在呈现不断上涨势头，性能瓶颈和风险日趋明显。但迁移到 OceanBase 不可避免的要面临风险和挑战。

首先面临的问题就是，异构数据库兼容性如何？其次是海量数据库迁移数据质量如何保证？最为重要的是，商户平台直接对接支付系统，在蚂蚁核心业务和交易链路中都承担着非常重要的职责，如何做数据库迁移才能让业务无感知，实现平滑的切换和回滚？

据韩谷悦介绍，在业务评估与改造方面，此前迁移一个业务最少需要花费一到两个月时间，进行业务改造和适配，但基于 OMS 自动化的兼容性评估报告以及负载回放能力，蚂蚁商户平台业务前期改造只用了一周。

数据迁移和校验方面，虽然迁移时长与数据量及网络资源密切相关，但在提升迁移质量方面，OMS 可以将增量迁移的延迟控制在毫秒级，即便跨城的情况下，最多也只需要三秒钟，而对于验证出所有不一致的数据，OMS 还提供修正的结果方案，从而极大提升迁移和校验的整体效率。

在业务切换方面，通常切换前需要制定比较严密的方案，并且切换之前和过程中需要检查和校验环节非常繁琐，因为一步差错就可能会导致数据不一致，OMS 通过引入大规模编排能力把所有繁琐环节都落到了平台中，OMS 还提供了集成部分中间件的能力，无论在迁移还是校验过程中都用时很少。

在业务回滚方面，回滚之前需要承担重大的决策风险，商户平台业务进行切换整体迁移过程中也发过抖动，但从登陆系统到完成回滚只用了几分钟。

韩谷悦说，蚂蚁商户平台整个迁移时间在 3 个多星期，不足一个月。因此无论是从人力成本还是时间成本上看，基于 OMS 都得到了极大提升。

总的来看，OMS 亮点无论是多类型数据库支持，分钟级即时回滚，负载回放验证，秒级数据验证，亦或是一键完成迁移等等，最终的结果都是降低业务向 OceanBase 数据库迁移的门槛，从而加速 OceanBase 商业化落地。

对金融企业而言，系统架构从集中式转向分布式是大势所趋。在数据库层面，要从单机数据库转向分布式数据库虽极具诱惑，但更换数据库，企业决策依然会非常谨慎，因为涉及到巨大的风险和成本，其中就包含数据库迁移过程中的风险和成本。而 OMS 的出现至少一定程度上消除了这一阻碍。

而截止到今天，OceanBase 已经在南京银行、浙商银行、人保健康险、常熟农商行、苏州银行、广东农信、网商银行等多家商业银行和保险机构上线。全球前三名的支付平台，两家的核心系统都在使用 OceanBase 数据库。

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/bPJTIHvhIVKheRi7-dlEmA