本文来自2024 OceanBase开发者大会，OceanBase 金融与政企事业部解决方案总监李楠的演讲实录 ——《关键业务系统分布式数据库升级路线选择和技术演进之路》。完整视频回看，请点击这里＞>
大家好，我是 OceanBase 金融与政企事业部解决方案总监李楠。感谢各位嘉宾来到 OceanBase 开发者大会，今天我分享的主题是《关键业务系统分布式数据库升级路线选择和技术演进之路》。
一、数据库升级路线选择
说到数据库，近几年我们经常会听到一个词：“替换”。这一次我们没有提“替换”，而是叫升级。因为这一次的数据库“替换”对于每个客户来说，都会有大量的人力、物力的投入，如果只是为了“替换”，如何有效支撑未来 5-10 年的业务发展？未来几年业务发展受限于技术，是否需要再次投入进行数据库升级？所以我们建议在数据库“替换”的同时，要考虑进行数据库架构和技术的升级。
众所周知，OceanBase 同时支持两种数据库：Oracle 和 MySQL，并且是“纯净”的支持。为什么是纯净的支持呢？在使用 OceanBase 时，首先要创建租户，并且选择租户类型是 Oracle 或 MySQL，后续的开发和运维，和原生的 Oracle 或 MySQL 都是类似的。记得大概三四年前，客户关心的是数据库是否支持某个数据库类型。随着认知的转变。现在客户更关心的是数据类型的精度是否和 Oracle、MySQL 一致，是否会带来运行结果的变化。所以，这里的“纯净”指的是OceanBase 没有将两种类型的数据库混合在一起。而基于 MySQL 数据库开发了 Oracle 兼容性，会带来包括精度在内的很多问题。
在金融、政企、运营商等领域，核心系统数据库升级实践总结起来有 4 条路线：
第一条是「 Oracle 路线」，大家都希望用最少的资源实现从 Oracle 到 OceanBase 的迁移。第二条是「DB2 路线」，DB2 里有两类，一类是大型机 DB2 下移，另一类是基于 Power 小型机的 DB2 下移。这里也分两种情况，有的客户之前使用 DB2 的 Oracle 兼容模式，这时迁移到 OB-Oracle 是代价最小的；有的客户替换 DB2 之后，希望改为 MySQL 路线，OceanBase 也支持这种升级路径。第四条是「 MySQL 路线」，直接将 MySQL 迁移至 OB-MySQL，这是最简单的一条升级路径。
之前大家在使用 Oracle、DB2 或者 MySQL 时，都会遇到一些挑战，而升级到OceanBase 后，目前存在的这些问题会得到解决：
○ 第一，数据库的使用和运维成本。大型机和传统数据库的运维成本相对较高。
○ 第二，数据库的峰值动态处理能力。现在很多业务都会有间断性峰值，比如在红包、秒杀场景下，传统集中式数据库都会面临性能瓶颈和扩展性的挑战。
○ 第三，多基础设施。越来越多的客户不希望数据库只跑在一朵云上，因此会选择两朵云或三朵云，做数据库跨云部署。
○ 第四，高可用性。分布式数据库相比传统集中式可以应对更多的的高可用场景，比如：两地三中心、三地五中心等。
对应 4 条升级路线，这里也举 4 个典型的数据库升级案例。
1. 中国移动：BOSS/CRM 核心系统 Oracle 数据库平滑升级
中国移动的 BOSS、CRM 核心系统之前大多使用 Oracle 数据库。运营商和金融客户不一样的地方在于，金融客户大多有专门的数字科技公司，有独立开发能力，可以把 Oracle 数据库改造为 MySQL，甚至数据库对他们来说只是查询和储存数据的工具，对数据库本身能力的要求不高。而运营商更多的是希望平滑替换，尽可能在改造小的情况下完成数据库升级。
OceanBase 在 2020 年开始做中国移动的数据库升级，去年完成某个省公司所有核心系统的数据库升级，现在多个省份的项目也都在实施中。
在中国移动，OceanBase 能实现 10 倍压缩率，可节省 90% 存储成本，并且提供业务方面的性能提升。部署架构上，某省份选择同城三中心部署，而华东某省选择两地三中心部署，其他省份也根据自身实际情况选择不一样的架构。可以支撑各种类型的部署架构也是中国移动选择 OceanBase 的一个原因，不会因为某个省份的应用独特性而需要选择多个数据库产品。
2. 交通银行：大型机 DB2 一步到位迁移至原生分布式数据库
交通银行的数据库升级路径是大型机 DB2 下移。在数据库升级之前，大型机的运维成本很高，升级至 OceanBase 后，合计总成本节约 7 亿元， TPS（每秒处理事务数）提升 6 倍，跑批效率提升超过 7 倍。
这里提到性能提升 6 倍，并不代表 OceanBase 的性能比 Oracle或 DB2 快 6 倍。无论是 Oracle 还是 DB2，传统单机数据库的单机性能都是很强的，这里的提升一方面是分布式数据库本身的优势带来的，另一方面是在项目实施过程中，我们会和客户、应用开发商一起，探讨现有架构是否有优化的可能性，为客户的业务带来整体的提升。
3. 云南红塔银行：微改动实现核心系统 DB2 数据库升级
这是一个小型机 DB2 下移的案例，和大型机下移不同，我们叫微改动。云南红塔银行之前采用小型机加 DB2 的架构，升级至 OceanBase 后，处理能力比原核心系统提升超过 30 倍。与交通银行类似，在数据库升级的过程中，OceanBase 帮助云南红塔银行重新设计了数据库和应用架构，在数据库升级的同时，为业务带来了更多的价值。
4. 中国联通：MySQL 数据库的平滑升级和自我演进
和中国移动的业务分省集中不同，中国联通业务是全国大集中。中国联通的 Oracle 、核心 MySQL 选择升级至商业版 OceanBase，非核心 MySQL 选择使用开源版 OceanBase。中国联通在 MySQL 数据库升级时，走了一条“平滑迁移和自我演进”的路线，基于 OceanBase 研发了 CUDB，即 China Unicom DB，在深度使用 OceanBase 开源版的同时，也对 OceanBase 的能力进行了扩展，比如联通实现了基于业务压力的租户自动扩缩容。
二、数据库升级的技术演进
关于核心系统数据库升级历程，有如下思考：
第一，业务价值是基线。数据库升级，不是为了升级而升级，而是基于企业自身业务价值的提升做出的选择。
第二，架构先行。如果只做单独几个数据库的升级，那么只需针对性地做数据迁移和应用适配工作。而现在越来越多的客户选择对企业整体业务的所有数据库做全面升级，这种情况下，需要要先设计整体的升级架构体系，这里的架构不仅仅是数据库层面，也可能涉及应用和底层基础设施。
第三，兼容性评估。数据库升级的成本需要预先评估，这里的成本包括软件成本、硬件成本、人员成本等等，评估可以让客户更好地了解项目的整体投入和时间周期。
第四，还需要评估升级风险。稳定第一，评估包括核心或关键业务系统的升级风险以及制定相应的规避方法。
（一）具体流程
经过 OceanBase 多年在核心系统数据库升级方面的沉淀，我们总结出四步走的具体流程：
1. 现状梳理
以 Oracle 升级至 OceanBase 为例，我们先通过 OMA 工具在数据库层面进行兼容性评估，另外还会分析 Oracle AWR 报告，AWR 报告能提供很多有价值的信息，如：业务压力、资源使用、可能的性能瓶颈点等。此外，还会通过调研的方式，梳理数据库和应用的现有架构和未来需求、上下游链路等信息，以获得现有数据库的全貌。
2. 初步验证
在现状梳理完成后，基于搭建的 OceanBase 测试环境进行应用的初步验证，这个阶段也包括后续应用和数据库架构的整体设计。在测试环境下，基于回放和应用功能测试进一步进行兼容性和性能验证。其中，回放指通过 OMA 工具捕获源端数据库的真实负载，并在OceanBas测试环境进行回放，目前支持回放的源端数据库包括 Oracle、MySQL，实现了在没有搭建应用环境的情况下，在数据库层面对系统性能进行整体评估。
3. 整体验证
除了进行可能的应用改造，如果涉及到架构升级，如之前是单中心部署，后续计划提升为两地三中心、三地五中心等部署架构，在整体验证里也会对后续架构进行验证和测试。另外在整体验证阶段还会进行基于全量生产数据的性能压测，以及与周边系统的联调测试。
4. 生产上线
最后的生产上线的流程，是从提前进行存量数据的全量抽取，到转为增量同步和数据校验，再到切流的应用验证的整体工具化流程。
（二）团队和资源规划
数据库升级项目需要双方甚至多方的配合，如果涉及到企业整体数据库的升级规划，建议成立项目管理委员会，委员会由项目各方的高层组成。数据库升级过程中重要事项由项目管理委员会来决策，比如项目的重要时间节点、应用的升级规划、各方资源调用等，实际实施可以交给项目组具体执行。其中甲方也可以分为三个大角色：
第一是应用开发，有些项目应用是客户自研，有些项目会涉及到第三方应用开发商；第二是数据库运维，在项目实施的过程中，我们之前遇到过转运维的问题，如上线之后运维厂商不清楚后续具体的项目情况，因此我们建议运维团队在项目的中期就开始介入；第三是基础环境的支持，包括服务器、网络等。
OceanBase 团队的架构，由项目经理、架构师、实施交付、研发、运维组成。具体职责可见下图。
三、核心系统数据库升级，主要风险的识别与应对
核心系统数据库升级是一项攻坚战，在此过程中可能面临各种风险，这些风险需要我们提前识别，并有效应对。
（一）应用兼容性风险应对
应用兼容性是客户比较关心的问题，这涉及到需要改造多少应用，以及需要改造到什么程度等。
通过 OMA 工具进行兼容性分析和性能回放，并配合现状梳理阶段的调研信息，可以有效回答以下两个问题，第一，兼容性问题，即迁移后应用能不能跑；第二，性能问题，即迁移后应用跑得好不好。
OceanBase 是一个标准化数据库产品，功能和性能在不断地迭代，比如：OceanBase 的 Oracle 和 MySQL 兼容性都在不断提升，并且因为 OceanBase 数据库的 Oracle 和 MySQL 租户在底层是同源的，所以可以将一些 Oracle 租户的功能方便地移植到 MySQL 租户，提升MySQL租户的使用便利性，如：DBLink、dbms_stats 包等Oracle特性，同样在OceanBase的MySQL租户上使用到。
针对客户提出的需求，OceanBase 也会按排期进行开发，并跟随后续的版本提供至客户使用，所以 OceanBase 提供至客户的版本，都是经过蚂蚁内部和其他客户打磨过的版本，不会把数据库软件像业务应用软件一样，直接提供给客户一个独立的定制化版本，这种方式虽然看上去比较容易满足客户需求，但是每个客户现场存在的可能都是孤版，这在后续的数据库升级维护或者 BUG 修复中都是灾难性的。
（二）架构风险应对
OceanBase 是单机一体化架构，数据库选型时在架构层面不用考虑是选择集中式还是分布式产品、产品是否可以支持两地三中心、三地五中心等各种部署架构。对于 OceanBase 数据库，各种使用场景和部署架构都可以支持。OceanBase 目前在 4C8G 的服务器环境就可以单机运行，如果后续需要提升高可用级别，在线添加两台服务器就可以将单机数据库升级为分布式数据库。
我们在项目实践过程中还会经常遇到一个架构层面的风险点：耦合。
随着微服务的增加，应用和数据可能会出现多对多的关系。这种情况下，需要提前梳理清楚应用和数据库之间的关系，以及业务与数据库之间的关联点。比如一个应用访问 5 个数据库，一种方案是同时进行 5 个数据库的切换。如果应用只切换了其中一个数据库后，实际上原有的 4 个数据库和切换后的数据库是异构的，这就需要应用可以具备同时访问异构数据库的能力。
（三）资源和性能风险应对
OceanBase 的性能随着版本的迭代在不断提升，DB2、 MySQL 迁移至 OceanBase 都可以保证很好的数据库运行效率。此外。在迁移过程中，我们也会和客户一起探讨架构、应用、数据库等各个层面的性能优化点并执行。
OceanBase 还有一个特性是多租户。对很多客户来说，大规模应用或核心应用可以通过单租户搞定，但很多小应用，是否可以用多租户的方式整合？答案是肯定的。
那么，在多个小系统升级场景下，该如何选择方案？是选择 OceanBase 的单机化部署方案，还是使用多租户整合方案？我们建议优先选多租户方案。因为单机化部署方案只是 1：1 替换，运维和管理成本依然很高。通过租户整合多套应用的数据库，可以大幅提升资源使用率，降低运维成本。
那单机化部署适合哪些场景？目前一些企业的总部会用分布式数据库，而分支机构因为对于高可用和性能的要求较低，可以部署单机数据库。这是目前常见的单机版场景，我们也一直和客户探讨更多的单机分布式的适用场景。
业务系统进行大量的分布式数据库升级时，我们不建议直接根据业务自身需求申请 1C4G、1C8G 或者 3C8G，而是应该基于租户规格的整体规划。举个例子，我们把租户规格分为小、中、大三类，每一类有固定的配额，如：小系统 8C32G、大系统 40C128G。通过分类可以使资源管理更加规范。当然，在实际操作时，分类可以更加细致，比如划分为 5 类或 6 类。
此外，还有人员资源风险。
在这里我们需要评估在整个数据库升级过程中，需要哪几个工作角色，以及每个工作角色所投入的工作量。比如：OceanBase 需要投入多少人员，以及投入什么样的人员资源，如实施、架构等；客户需要投入多少开发、DBA 以及辅助角色的资源。我们建议根据系统的规模类型进行分类，并建立工作量评估模型，这样每个系统都可以根据归类，容易的评估出所需要投入的资源。
（四）高可用风险应对
OceanBase 是一款具有全场景高可用能力的分布式数据库，4.x 版本实现了 RPO=0，RTO＜8 秒。在高可用架构方面，可以实现单机房、三机房、两地三中心、三地五中心等多种形式部署。
此外，OceanBase 还具备机房级容灾能力。比如客户的主机房在北京，只有一个备机房在贵州，北京和贵州之间的网络延迟至少在 30 毫秒左右，如果单集群跨域部署对应用是有感的。这种情况下，可以通过主备库实现，类似 Oracle ADG 或者 MySQL 的主备架构。
之前有客户提到，OceanBase的备集群是只读的，只能做查询，如果主备 1：1 部署有较大的资源浪费。在 4.x 版本中，OceanBase实现了租户级的主备库。即主机房运行一部分业务，对这部分业务来说，主租户在主机房，对应的备租户在备机房；备机房也运行一部分业务，对这部分业务来说，主租户在备机房，备租户在主机房。通过交叉互备，将备机房的资源真正使用起来。
在 3.x 版本，两地三中心或者三地五中心会有一个日志副本或全副本放在远端，因为需要做所有日志的同步，这对网络的消耗比较大。在 4.x 版本，OceanBase 实现了仲裁副本，仲裁副本监控整个业务集群的运行，如果仲裁副本自身出现故障，业务集群可以继续运行；如果仲裁副本发现集群出现问题，会对集群发起降级或升级操作。OceanBase 的仲裁副本与主集群之间的最大延迟可以到 800 毫秒，所以基本上可以部署在全国各个地点。
（五）上线割接风险应对
在关系型数据库的迁移方面，OceanBase 支持数据库结构和数据的全量迁移、增量迁移。OMS 是 OceanBase 自研的数据库迁移工具，生态伙伴方面，迪斯杰、英方软件等也都可以支持 OceanBase 数据库的迁移。
OceanBase 现在提升了多模、OLAP 方面的能力，现在也有客户希望把非关系型数据库如 HBase、Hive、ES 的数据迁移到 OceanBase，这种情况下可以使用 DataX，也可以使用合作伙伴提供的方案实现这些数据源到 OceanBase 的数据迁移。
（六）运维和技能风险应对
很多公司都有自己的运维团队，虽然 OceanBase 可以复用很多DBA在之前 Oracle 和 MySQL 的经验，但是从 Oracle 和 MySQL 的 DBA 转到 OceanBase，还是存在一定的过渡期。针对运维风险，OceanBase 提供运维知识体系搭建方案，包括架构、交付、性能、运维等，每个阶段都有相应的内容输出，通过培训、文档等方式，帮助企业搭建适合自己的运维体系，有效应对运维和技能风险。
OceanBase深耕金融14载，携手百家金融客户沉淀实践，近期推出了金融行业数据库升级的4条数据库升级路径，6大核心场景实践的万字总结——《金融核心系统数据库升级路径与场景实践》。感兴趣的朋友，可以点击这里下载 >>
《金融核心系统数据库升级路径与场景实践》
