河南移动，作为电信全业务运营企业，不仅拥有庞大的客户群体和业务规模，还引领着业务产品与服务体系的创新发展。河南移动的原有核心营业系统承载着超过6000万的庞大用户量，管理着超过80TB的海量数据，因此也面临着数据规模急剧扩张与业务连续性要求高的双重挑战，对数据库的分布式升级显得尤为迫切。在全方位综合评估后，河南移动选择了OceanBase作为其核心系统的分布式数据库。
在 2024 外滩大会的 OceanBase 见解论坛上，河南移动高级专家彭庆军作为嘉宾受邀分享了河南移动营业系统核心数据库分布式改造升级经验。他表示：基于自研轩辕数据总线替换方案，河南移动在两个月内完成了一套承载 1500 万用户的核心系统，从传统数据库到 OceanBase 的平滑升级，并取得运维效率显著提升、7×24 小时稳定运行的卓越成效。
1. 建设背景:新一代干架构需要新一代数据库
河南移动的现网即核心营业系统 CRM 呈数据容量大、业务并发高、连续性要求高、数据安全性高四大业务特征：
-
数据容量大。伴随着业务发展，河南移动用户数量现已突破 6000 万，其营业核心系统数据量已超过 80TB。相当于每个库拥有 1500 万用户，大约 20TB 数据。
-
业务并发高。单库日 SQL 数量超 40 亿次，日订单量 3 千万笔（含查询工单），逢月末、月初业务量峰值更加持续增长。
-
业务连续性要求高。众所周知，移动行业是涉及民生的基础通信服务，需要为用户提供 7*24h 电信级服务保障，业务中断三个小时即为重大故障。
-
数据安全性高。核心营业系统数据库存储着超 1500 万用户的敏感信息和数据，数据不能错、不能丢，且存储和访问安全要求高。
彭庆军介绍，河南移动新一代 IT 架构对数据库有七大需求：高兼容、高可靠、高性能、高扩展、高容量、高安全、高运维。
对于当时的河南移动来说，数据库改造面临成本高、访问性能低、割接风险大、替换周期长四大难题。传统的数据库替换方案主要围绕功能、性能、运维，涉及数据库和应用系统两方面，一般存在两种替换方案：一，从 Oracle 迁移到国产数据库，需要该国产数据库完全适配应用和兼容 Oracle；二，应用适配国产数据库，这是目前数据库替换采用的主流方案。
因为数据库的替换历来高风险低收益，而通过应用进行大量适配改造的换库方式等于是单程车票，不仅并行期应用存在两个版本，且上线后难以回切，一旦替换后的新库不满足要求，再次替换的难度和风险更高。有没有第三种替换方案？
基于此，河南移动开始为核心系统探寻新的数据库。根据河南移动的经验，数据库选型可以分为两个方面：一是如何评估一家数据库企业；二是如何评估一款数据库产品。
在彭庆军看来，第一要看企业的综合实力，其次是企业的研发实力，最后需要关注这个企业做的产品是“长期主义”还是“短期的功利主义”。
2. 两个月完成割接上线成效显著
河南移动从选型到上线整体周期历经 7 个月。2023 年 5 月，河南移动开启国产数据库选型，并重点关注几大国产分布式数据库；6 月，河南移动选型集团公招标中标的 OceanBase；9 月，双方团队一起确认升级改造方案；10 月，召开国产升级启动会；12 月，核心系统成功割接上线。截止 2024 年 9 月底，河南移动核心营业系统数据库已稳定运行 300 余天。
彭庆军介绍：在确认升级改造方案时，团队一直比较犹豫，因为核心系统升级至国产数据库的动作很大，担心分布式数据库上线后运行不稳，害怕没有给业务带来任何效益。基于此，河南移动调研了已经上线 OceanBase 的山东移动和江苏移动。在听取了两地的实践经验后，整个团队心里底气大增。10 月份，正式启动了核心营业系统数据库的分布式产升级之路。最终仅用两个月，当年 12 月份即完成系统上线。”
完成迁移升级之后，河南移动建设成效显著，基本总结为“一少、二快、三稳、四超”。
-
投入少。应用不改，人力、资源、成本投入少，极大降低了国产数据库替换成本。河南移动营业核心库的分布式改造和以往数据库的替换方式不同，不仅自有人员和应用开发商投入特别少，而且核心营业库的替换所需测试资源只有 OceanBase 数据库的资源，先将 OceanBase 生产库的资源做测试库，做完适配验证、性能压测觉得可行后再转为生产库，就不需要搭建一套完整的测试环境；
-
替换快。生态不变，脚本不变，免学习，替换快，大库两个月、小库一个月。河南移动有 1500 万的营业核心大库，两个月就替换完毕；
-
割接稳。风险不升，应用适配、性能测试 360 度全覆盖，生产上线后性能和上线前压测一致；
-
性能超。实现性能不降，缓存提效，连接增效，最佳配置模型，硬件加速，数据压缩比高。
营业系统核心数据库上线 OceanBase后，河南移动运行效果也比较亮眼。下图为割接前后对比，主要分为 SQL 执行性能对比和数据库性能对比。
SQL 执行性能对比显示，通过跟踪业务整体运行、高峰时段运行，对比 Oracle 与 OceanBase SQL 平均执行时长，割接上线由平均 2.515 毫秒降低为 1.626 毫秒，性能整体提升 35.35%；通过跟踪核心 CBOSS 业务运行情况，对比多天 Oracle 与 OceanBase SQL 执行时长，割接上线后由原来平均 116 毫秒降低为 114 毫秒，平均节省 2 毫秒。
数据库性能对比显示，通过总线连接收敛能力，业务连接数 10760+ 不变的情况下，使用 OceanBase 进一步将数据库活跃连接数由原来的 4765 压降至 2140 ，数据库连接收敛比提升 45.4%。替换完成后，经历多个账期测试发现，整体业务运行稳定，数据库集群的平均资源利用率从 7%-10% 提升至 12%-20%，资源利用率大大提升。
从 2023 年 12 月份至今，河南移动核心营业系统稳定运行，平稳支撑多次月初、月末的流量高峰；与此同时，数据库集群平均的资源利用率也非常稳定，较原有集中式数据库的 CPU 利用率提升 8%-9%。
3. 自研轩辕数据总线中间件产品助力数据库升级
此前，河南移动 CRM 系统数据库现网的部署架构为集中式，各个应用系统通过数据总线连到后端 Oracle，该架构共 6 个 Proxy 节点，中间通过 SAN 路由交换机连接后端的全闪存阵列，这种配置较此前 Oracle 小型机+集中的高端存储性能提升明显。
原集中式数据库共 6 个 RAC 节点，共享存储 40TB，实际使用 15TB 左右，新分布式架构将 9 个计算存储合并为一个节点，总存储量 57TB。得益于 OceanBase 的数据压缩功能，三副本架构最终实际使用 15TB 左右，总占用容量和原库基本持平。
新架构前端应用先连接轩辕数据总线，再连到后端 OceanBase，共有 12 个节点，分为三个部分，每个部分有 3 个计算与存储一体的节点，和 3 个 OCP 管理节点，从新架构可以看出将路由器和比较昂贵的高端存储进行优化后，硬件成本得到一定下降，其数据库容量也有了显著提升。通过性价比高的本地存储代替昂贵集中存储，OceanBase 全库数据压缩成效显著，告别容量焦虑。在数据库软件许可成本层面，单台 x86 主机的 License 费用仅为此前 1/50，成本也实现了大幅下降。
新分布式架构中的轩辕数据总线，作为河南移动自主研发的一款助力数据库国产升级的数据库中间件产品，以应用不改、性能不降、风险不升、生态不变为目标，通过在业务应用与数据库之间增加一层“数据总线”抽象层，将国产数据库升级中的四大难题上移至轩辕数据总线层解决，以此助力大规模高并发场景 OLTP 数据库平滑国产升级，具有“投入少、替换快、割接稳、性能超”四大优势。
-
应用不改：不仅仅 JAVA 应用不改，C、C++应用，sqlplus、sqlldr、python 脚本及配置全部不改，经过 1.5 万个以上的生产程序检验以及真实生产割接验证，实现了国产数据库无感知平滑上线的重大突破；
-
性能不降：将性能调优的关注点从关注数据库单次访问性能上升到关注业务办理每笔交易的整体性能，针对性地创造了高效缓存技术和连接收敛技术两项创新点，使交易中访问次数下降 50%，连接数减少 80%，从而实现了国产库性能下降 40%的前提下，交易性能整体不降的重大突破。
-
生态不变：针对国产库替换后开发、运维人员整体转型学习成本巨大的问题，打造了异构数据库混合组网能力和透明的数据库运维工具两项功能，新库可异构组网替换且完全继承 Oracle 技术生态，从维护脚本、告警报错、维护工具，全部访问如初，无需改变，开发、运维人员无需改变技术栈，实现了数据库升级过程中选择权提升和替换后生态不变的可持续性突破。
总的来说，基于轩辕数据总线架构，河南移动国产数据库上线分 4 个步骤：
第一步，应用接入数据总线，实现应用和数据库解耦，从总线侧获取全量生产应用 SQL；
第二步，部署国产数据库，作为生产测试库；
第三步，流量回放及测试，将 Oracle 流量引入对应国产数据库，进行兼容性和性能的适配测试；
第四步，一键切换，通过总线一键切换功能实现国产数据库的生产上线。
轩辕数据总线为河南移动节省了数千万应用改造费用，同时为数据库国产升级探索出了一条全新且可行的道路。
4. 实践经验应用适配与性能提升
当下，对于新建系统的国产数据库升级改造往往会选择基于新的数据库进行开发，以避免适配迁移等问题，包括河南移动在内的众多企业数据库系统国产升级往往是指存量系统的国产升级。
虽然很多国产数据库的兼容性都可以达到 90%以上，但不同应用因这些不兼容的差异改造工作量不同，应用改造费用评估标准很模糊，所以对于存量系统有升级改造需求的企业如何选型一款性价比高的数据库是一个避不开的难题。以河南移动为例，彭庆军介绍了其所在数据库团队的应用适配和评估流程。
第一步，识别改造工作量。传统方式是通过数据库厂商提供的评估能力确认数据库中有哪些不兼容的语句，然后让应用花费大量人力通过排查代码进行评估；河南移动评估方式是基于河南数据库中间件的评估方案，记录应用到后端数据库每个 SQL 的访问情况，先将整个 SQL 进行回放以筛选不兼容的 SQL，同时根据 SQL 的访问记录去反查每个不兼容 SQL 下有问题的应用进程，统计出每个应用进程有多少处不兼容点，初步确认迁移改造的工作量；
第二步，对不兼容或不适配的 SQL 语句进行中间件改写，使其符合目标国产数据库并且能够在该数据库顺利运行。在这个过程中，河南移动自研了一套中间件产品轩辕数据总线，助力此次国产数据库平稳高效升级；
第三步，性能测试。传统的性能压测无法面面俱到，往往是通过主要业务根据日常配比去做测试。而河南移动采用的是真实全仿真的测试，将包括营业系统在内的每一天的全量 SQL 语句，以 200、300 的高并发，分别在国产数据库上进行压力测试，并将测试出来的较慢的 SQL 与该数据库一起进行优化，通过评估后确认具备上线条件。
在河南移动营业系统应用适配和性能提升过程中，由于营业 A 库数据量及每日归档量较大，原传统集中式存储空间紧张，归档过早清理导致 OMS 增量同步任务经常中断。在迁移演练阶段，OMS 产品通过多次及时发版提升了同步效率，最终在正式割接期间平稳迁移完成，数据校验 100%一致。在特定统计场景营业日报业务内，河南移动对递归查询进行了优化，进一步适配了 OceanBase，性能获得了明显提升，目前的性能基本可以保证在 40 多秒内进行查询。
此外，河南移动还利用自研轩辕数据总线产品承担了主要适配改造工作，解决了兼容性相对比较弱的一些问题代码。比如面对高 CPU 利用率的函数切换到国产数据库经常会出现的一些难题，针对性地对 OceanBase 进行了一定程度的性能优化。
可以说对比上面所提到的“单程车票”改造方法，基于轩辕数据总线架构的国产数据库升级方式是一张“往返车票”，支持无感切换回原数据库。
5.写在最后
未来，河南移动将持续推进 B（业务支撑系统）/M（管理支撑系统）/O（网管支撑系统）全业务域升级改造，并结合特有轩辕数据总线产品，推进 OceanBase 生态构建。
彭庆军表示：OceanBase 经过了十年的内部打磨，又经过五年的外部推广，作为一款顶天立地的产品，其未来发展大有可为。此次河南移动自研的轩辕数据总线可以帮助千行百业解决场景差异的 SQL 适配问题。相信在轩辕数据总线的加持下，会让整个 OceanBase 分布式生态如虎添翼，为企业节省大量的改造费用，同时加快分布式数据库改造推广的进度，实现多赢！