自文章 易鲸捷QianBase与Oracle，完全不同的两种技术架构 发出后，关注度挺高，相信大家对易鲸捷到底是否贴牌甲骨文有了清晰的答案。今天笔者想结合自身的实际经验，具体谈一谈银行核心交易系统国产化替换的艰辛历程，并为易鲸捷这样能够坚持为国产替代而不懈努力的数据库企业感到欣慰。在此之前，先介绍一点相关行业背景知识。
数据库根据业务场景可以分为在线交易处理（OLTP）和在线分析处理（OLAP）。OLTP和OLAP两者的本质区别在于T（Transactional，即交易/事务）和A（Analytical，即分析/统计）。拿银行场景举例来说：小明在柜台给小王转账10万元，这就是在线交易OLTP；银行统计近三年贷款不良率，这就是在线分析OLAP。
 |
OLTP业务系统有很多种，以处理银行最基本的存款、贷款业务为主的IT系统称为核心系统（简称CORE Banking）。银行的核心系统好比是一个银行的心脏，系统的稳定性、可靠性、数据一致性、响应延迟等都有严格的要求，用于支撑核心系统底层的数据库更是要求极其严苛。直到今日，国内主要金融机构的核心系统仍然是以国外的IOE架构为主。然而，伴随信创脚步的加速，以及俄乌战争米国各种制裁事件引发我们深思，只有把数据库这样的核心技术掌握在自己手里，才谈得上是真正的信息安全。
当然，说替换，哪有那么容易？拿当前国内市场来看，有几家国内数据库真正上线了银行核心系统？我们不妨看一下墨天轮中公布的国内数据库针对金融机构上线案例国产数据库核心业务系统典型案例
- 墨天轮 (modb.pro)，可以发现，很多所谓的核心系统替换其实是一些边缘业务系统而并非核心系统。
以上简单介绍核心系统的基本概念以及当前核心系统替换的现状，下面笔者重点从一个数据库技术人员的角度分享一些在银行核心系统国产化替换项目实施中的感受。
（1）功能适配。跟Oracle不兼容？那是你数据库的问题。
项目初期的主要工作是兼容适配，就是首先得保证业务能正常跑通。由于应用的代码一直是基于Oracle数据库开发出来的，适配兼容有2条途径，应用适配国产数据库 或者 国产数据库兼容Oracle。长远角度看，当然是国产数据库能够兼容绝大多数的Oracle特性，这对以后的去O项目是一劳永逸的；但从中短期项目交付的角度来看，由于数据库代码的耦合度比较高，修改一部分代码可能会影响其他的功能，必须要经过多轮严格的测试才能保证功能的可用性和稳定性。举个例子，应用代码使用了Oracle的rownum来进行分页，而数据库却只支持limit语法，如果数据库去兼容rownum，开发周期必定不短，如果是分布式数据库，实现起来要更复杂一些。针对此类场景，应用厂商可能也不想改，其理由是：我们整个应用里面有上百处代码逻辑使用到rownum，修改影响面太大。
这样的例子在项目过程中是十分常见的，对于没有什么名气的国产数据库来说可能会遇到不公平对待！！！这种不公平，来自于Oracle数据库在国内大部分应用开发人员脑海中已经根深蒂固，每每遇到和Oracle不一样的地方，人们总是认为Oracle是对的，毕竟Oracle是数据库圈子里的No.1，即使Oracle是错的，人们也会认为它是对的！迫于种种压力，数据库产品经理终于缴械投降了！于是，数据库实现了rowid、rownum、dual伪表、存储过程、触发器、自定义函数等等。懂数据库开发的人都知道，光是上述这些功能项做到产品化，就需要1-2年。
（2）满足性能。这个交易平均500ms？还要再快一倍才行。
银行核心系统主要由日间交易以及夜间跑批构成。对于夜间跑批，只要不是时间特别长，基本问题都不大，而保证数据库在高并发情况下还能满足单笔交易的响应耗时（通常在百毫秒级别）则更为重要。要知道，核心业务里面的一个账务类交易，比如转账，事务内部可能会包含几百条数据库SQL调用，也就是说，平均每条语句的耗时大约在1毫秒以内。可见交易系统对数据库性能的要求是极高的，而如果是分布式数据库，还涉及到到多节点间的网络交互成本。所以如果你听到别人忽悠你说，分布式数据库一定比传统数据库快，别信！！！
除了单笔交易的耗时要满足业务的需要，还要保证整体的交易成功率，一般至少要达到4个9（代表1万笔交易里面只能有一笔超时或报错）。这就要求数据库对于高并发冲突、锁机制实现等方面需要有较好的处理方式。
（3）高可用性。最多能挂两个节点？再搞坏一台试试看。
高可用能力是必须具备的，尤其是在这种核心系统中。高可用就是要保证在任何意想不到的情况下，数据库的数据都能够恢复，并能够在短时间内恢复业务继续运行。容灾是实现高可用的一种方式，金融行业IT系统依据金融机构自身规模需要满足相应的容灾标准。
除了容灾标准必须满足以外，项目过程中针对无数种异常故障场景进行几十轮的测试验证。这些高可用场景包括网络故障、硬件损坏、节点断电等，对于分布式数据库的测试，还需要考虑单节点故障、双节点故障甚至是多节点故障，真可谓是一个耗时、耗力还耗机器的测试。不过为了充分验证数据库的高可用能力，这些测试确实是不可避免的。
（4）数据一致。测出数据不一致？必须得给说法，还要多测三个月。
如果在功能、性能、易用性、高可用、数据一致性当中选择一个数据库最重要的特性，那肯定是数据一致性。数据一致性从细节上包含多个维度的一致性，如主备（从）库的数据一致性、（迁移后）源库和目标库的数据一致性、表和索引的一致性、备份恢复的一致性等等。笔者在项目实施的过程中，遇到过多种数据不一致的情况，这些情况大多是代码的BUG导致。对于数据一致性的问题，绝对是零容忍，不仅要找到问题的原因并修复代码，还要追根究底，排查所有相关可能的代码，尽一切可能杜绝隐患。
除了上面提供的几个点以外，在国产化替换的过程中还有很多内容需要充分考虑，如数据迁移方式与效率、异构数据库准实时同步方案、可视化运维监控与告警推送等等。算下来，从数据库开始兼容Oracle开发到能够正式上线，没有个几年的时间是不可能做到的。
最后，笔者想再补充一下，核心系统国产化的道路是坎坷的，但国产化未来一定会成功，易鲸捷这样的企业值得我们去学习，针对网上有针对性恶意诽谤攻击并吹嘘甲骨文的我们需要有自己的判断力，坚决不听谣不信谣！！！
 |
