大型金融核心系统国产化迁移升级实战

林春 2024-01-12 11:04:39

本文根据林春老师在〖2023 XCOPS智能运维管理人年会-广州站〗现场演讲内容整理而成。（文末有PPT获取方式，不要错过）

去年这个时候，我们还在核心系统的攻坚状态，当时是“欲上太行雪满山”，但是现在已经是“绿叶成荫果满枝”了，这里将我们的经验跟大家做一个交流。

一、数据库转型改造背景与成果

1、国产数据库产品现状及核心攻坚思考

首先先讲我们对国产数据库产品的现状及核心攻坚的思考。

在稳定性前提下，数据库数字化转型当中，改造成本，这是一个战略问题。

国产数据库需要考虑对源库功能性能的兼容，实现平滑的迁移。金融企业需要数据库国产化既快又省，同时兼顾远期的业务发展的底座支撑，攻坚迁移、改造前置、架构优化、工具创新、知识沉淀，是降低数据库数字化转型成本，尤其是应用改造成本的有效手段，应用改造成本在整个成本当中占较大比例。

2、分布式数据库选型考量

数据库选型的考量，我们需要考虑的首先是稳定性、可靠性，然后是兼容性、功能性、可扩展性，还有性能及维护性、易用性等等。

3、核心系统数据库转型改造中的降本增效

在改造中，降本策略其实是非常重要的。我们需要考虑应用改造是非常核心的环节。太保自研的一个工具叫“指南针”，可以针对源库进行扫描，然后识别出来目标数据库要改造的点，以及相应的改造的工作量，这样的好处是可以预先识别这些点，这些点就可以在源库侧预做改造；也可以帮助我们去估算了改造的整体的成本，便于起预算，合理的规划人力投入；工具提高了问题识别环节的效率，然后另外在SQL优化侧我们也研发了优化的辅助工具，结合SQL审核、调优培训及开发规范，降低了优化环节的人工成本。

此外把一些改造放在源库前置做优化，最主要的是侧重于高逻辑读的SQL优化，以及实现数据库的瘦身。首先，在我们迁移改造当中把迁移的数据集尽可能小，这是非常必要的，可以缩短迁移的时间；第二，迁移工作就像是搬家，搬家的时候提前把瓶瓶罐罐做一个梳理，这个也是非常有必要。这样到目标库以后可以降低数据量，大致的1TB的存储成本约4500元，可以很大程度节省存储以及应用维护的成本。

另外架构设计也需要改变，原来在源库承载了很多非数据库该承载的功能。我们在对应到国产数据库以后，实际上也考虑把大对象字段从数据库里面做一个拆离。我们有一个电子保单系统，原来库是22T，把大对象拆离出来以后，数据库大小减少到2~3T，迁移到目标数据库以后就非常稳定，而且大大减少了成本。此外，一些综合应用场景也可以拆离到数据中台。

4、国产数据库转型成果

我们太保数字化转型的一些成果：

第一，实现存储成本的节约，数字化转型的经济效益明显；第二，拿出最核心的系统进行攻坚试点，并成功上线，起到了一个良好的示范效应；第三，自主研发数据库应用改造与评估工具指南针，包括近20个大类，近200多个检查项目，评估项目全面高效，极大提高了项目组问题排查效率，缩短了项目周期，降低了业务改造成本。另外，我们之前沉淀了相应的数据库知识库，知识库沉淀问题超过1000条，并且形成了相应的一个知识体系。此外，我们还推广了国产数据库，全集团获得国产数据库认证人数超过1125人。

目前我们数据库国产化的项目非常多，最大的单个实例是45个TB，同时也有核心系统，并且也经受住了23年双11的峰值的考验。我们也有非常高并发的系统，高并发系统的最大QPS也接近了单体 12万QPS这个体量，还有很多重负载的系统。

在这么多系统改造过程当中，我们整理出了非常多的案例，并且在全集团做培训，并形成了相应的一个体系。

这个过程中我有个非常深刻的体会：很多用户认为做国产数据库改造，兜底的是数据库厂商，我认为这个是不全面的，数据库选型需要选择真正能掌控数据库内核研发能力的厂商。

但是很多情况下，厂商碰到的有些问题，它从数据库产品侧是无解的，这个时候你要在问题无解的情况下，要有相应的解决方案，需要用户进行兜底解决；同时，数据库产品有的时候它有些解法未必是最优的，你要判断出最优的一个解法。那就基于两个原则，第一个是稳定性原则，第二个就是成本的原则。

太保的相应的解决方案也在工信部赛宝的信创解决方案当中获奖，太保相应数据库数字化转型的特点就是攻坚牵引、知识沉淀、工具创新、育才多优。我们是先做试点，拿出了一些系统来做试点，试点基础上做了选型，做了选型以后，我们拿最难的系统做攻坚，在这个过程中碰到的问题非常多，一下子就快速沉淀出了一个知识库，在知识库基础上面，我们又创新研发了相应的应用改造评估工具，大幅降低了应用改造的成本。

二、某核心系统攻坚实践历程

我司就是根据业务场景，还有数据库的特性，因地制宜开展数据库选型工作，从最为复杂的核心系统着手，重点的突破关键共性技术，淬炼了本地化知识体系，实现数据库的一个最佳应用。

这里是我们一个核心攻坚的系统的介绍，是核心客服系统，它为超过2500个坐席提供系统服务，并且对接周边系统超过200个。保险业的核心客服系统，跟银行的客服是不一样的，它承载报案的业务，一旦像灾害天气发生，这个时候它报案量会急剧增加，如果系统出现任何性能问题，那就会造成重大的舆情事件。

我们这个系统特点：第一，存储过程数量庞大，代码量近百万行，而且对源库的产品特性使用非常深入，从自定义锁、自制事物、索引组织表，还有大量的DBMS的包；第二，配套了DS、cognos等产品，对商业数据库的深度依赖，适配改造的复杂度非常高；第三，涉及到上下游接口众多，本身是24×7的服务平台，对高并发、高可用特性要求很高，除此之外它有大量的实时报表，还有很重的批量报表。

太保集团和分布式数据库厂商组成了采用联合攻坚组，共同协作进行技术攻坚，克服了疫情的影响，最终实现了客服系统成功上线。从2022年底上线，目前的运行300多天，大幅提升了太保集团对数据库国产化的信心。

1、系统项目历程

下图是系统项目历程。我们是在22年5月底之前完成数据库选型的调研，当时我们整理出10个核心攻坚场景，让数据库厂商给出方案，然后我们选择了最适合的厂商，在8月31号完成了数据库功能的开发；在22年12月18号，第一个子系统成功迁移上线，23年5月6号是报表库上线，5月13号的是核心交易库上线。

2、升级项目收益

这个系统我们和数据库厂商对产品也做了很多的打磨，光这个项目修复的bug有20个，然后做的优化有95个。

做了这个迁移项目以后，我们收益就是服务于数千名柜面人员、百万业务人员，还有亿级的外部用户，通过数据库产品的高级压缩技术，并结合我们自身的数据瘦身，大幅度节省了存储成本。

除此之外，我们还实现了实时分析型数据加工性能提升了10倍，监管报送的性能提升了约有3倍，当然这个不光是数据库产品实现的，我们也做很多应用优化的工作。太保自己的指南针工具，在这个项目当中起到的作用非常大，我们可以对存储过程代码进行扫描，给出问题原因、代码位置，大幅降低了成本。下面是源代码扫描大致的一个示意图。

3、核心攻坚优化案例

下面，我们来讲解核心攻坚里面遇到的一个问题。当时在8月底攻坚时候，遇到了一个hibernate的框架，用的是3.3.2.GA版本，调用spring-data-jpa进行update和query时报访问v$session出错，当时数据库监控工具无法定位问题，而且应用侧也没办法在应用代码和框架代码当中发现这个问题SQL的位置。我们SQL跟踪，抓取了这个问题SQL，但抓取问题SQL给了项目组反馈后，也没能把这个代码位置抓取出来，当时其实是碰到一个很大的阻点，后来我们是根据这个SQL，分析它的目的，大致来讲是获取用户的名字，还有IP信息，大概率是用做审计用途。

v$session的报错，其实是一个语义级报错，它语法没有错对吧？只是找不到v$session。后面我这边推测，其实就是说我们知道在SQL引进层面其实是有两个异常，一个是too_many_rows异常，还有一个是NO_DATA_FOUND异常。如果他作为审计，要做插入的话，他把这个结果暂存到一个变量的时候，实际上如果没有数据，它就会触发一个NO_DATA_FOUND异常，同时抛出问题模块的名字。

所以我的思路就是构造了两个伪表，还有伪视图，想办法骗过了数据库的优化器，触发SQL语义层面抛出了一个NO_DATA_FOUND异常，同时提供出了这个问题模块的名字，这个问题模块它是一个trg开头，其实就是一个触发器，根据触发器模块定位了位置，我们改写了逻辑，并摸索出来了相应的一个解决方案，像这种问题其实非常的多。

三、其他重要系统近期攻坚情况

在国产化过程中，我们也碰到在海光服务器一些CPU的性能限制，厂商优化以后还是存在一个重大的卡点。当时我们一个费控系统是重负载系统，在源库执行是13小时，国产英特尔优化以后是16小时，但是海光上面没跑出结果。

最后我们结合了应用的优化，把它优化到了1小时40分钟，在服务器较差的情况下，比费控性能还提升了7.8倍。还有全成本文件下发模块，我们优化以后是在服务器较差的情况下，性能是跟源库相当，这样子其实解决了重负载系统的在海光服务器是否能用的问题，然后形成了可推广的优化范式，通过应用侧极致优化提升以后，是可以补偿硬件性能不足的。

国产服务器CPU性能其实是一个重大的卡点，这个里面大致我们可以把它分成两类：一类是重负载系统，做报表加工的；还有一类是高并发的SQL。

重负载加工的，我们是一般来讲是要结合应用逻辑、索引设计，还有SQL语句的优化，去做整体的一个优化。在这个过程当中，我们需要关注到的是源库侧给我们的优化的痕迹太重了，但是到国产数据库以后，实际上我们需要注意，我们的优化方法论是需要重大创新，甚至是颠覆性改变的。

同时对于重负载系统，我们当时在源库侧优化外连接，其实有一种方法，就是通过标量子查询来做优化。所谓标量就是返回单行单列，在源库引入标量子查询，并且可以有效作为很多外连接的一些优化方法。

但是到国产数据库以后，它虽然支持了标量查询，但是性能普遍来讲是弱于外连接的，所以优化方法就得反向了，看到源库侧迁移过来前的代码，需要反向把它从标准查询的优化为外连接，这是一个比较有效的优化方法。

此外我们还有一个销管的实施模块，加工逻辑非常复杂，我们发现有个存储过程性能虽然满足要求，但是造成了海量内存的挤占。它相当于是存储过程a调了b再调了c，三个存储过程加起来总共有5000多行。我们在处理这个问题的时候，先定位到了问题具体是在哪个模块，实际上是在c层的某个FOR循环，总共的FOR循环a加b加c一共是7层，改造逻辑是非常复杂，定位到这个问题位置以后，实际上我们是可以完成优化的，把它用Java改写，但是要考虑到成本的问题，如果在Java里改写了，我们要改的地方有几百处，这个成本是无法接受的，我们想的还是在存储过程侧去做优化。

存储过程侧优化的一般思路，要么是FOR把它去拆解、避免，要么把FOR里面的东西拆出来，要么是把FOR里面的东西优化到极致。但是这个问题很难有着手点，当时也是灵光一闪，我们推测厂商在设计的时候，在针对FOR，它实际上是用了一块内存来hold住循环里面的数据，而FOR循环，它是一个数据密集型循环，而WHILE部循环它是一个数据稀疏型循环，我这里就是合理推测对于数据稀疏型循环，数据库厂商设计的时候，就大概率不会用一般内存去hold住这个数据。所以后来尝试把其中的一个FOR循环改成了WHILE，内存一下子下降了一半，这个方法成功以很小改造成本，让我们把内存挤占下降了有7.71倍。当然这个优化也有个条件，就是FOR循环里SELECT查询遍历的数量比较少，所以我们改造成WHILE循环，不会造成很大的性能的下降。

在大库改造过程中，我们在原生的分布数据库上面，也自己设计了有冷热分离的方案，冷热分离里面要考虑的内容还是比较复杂的，它解决的是存储节点存储资源扩展遇到瓶颈这样的问题。同时要注意冷热分离方案它是有对CPU有额外开销的，所以它解决的是CPU不成为瓶颈，但是存储成为瓶颈这样的问题；然后，还要解决新建表、TRUNCATE表，它有可能在冷节点、热节点上随机会漂移，我们后面也有特定的技术方案解决了这个问题，再之后就要保证它稳定运行。冷节点上的这些表，我们相应还有一个维护的策略，也有相应的方案去解决。

我们也注意到，国产数据库替代后，要避免滥加并行，加并行以后它会造成CPU很大的开销，所以这里会有个问题，就是说原来源库侧19秒跑出来的，国产数据库没跑出结果，加了并行以后3分钟跑出结果，但这不是一个合理的解决方案，因为这个场景是一个交易场景，所以我们不能允许加并行，否则它会造成了系统层面CPU的一个急剧飙升。

最后解决方案其实很简单，我们是把他带着的这个函数把它改了，改成BETWEEN AND，最后我们原来在源库侧19秒跑出来的，后来我们在国产数据库3秒跑出来了，所以说优化方法是很多的，要避免并行滥用。

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

点击此处链接获取PPT

大型金融核心系统国产化迁移升级实战

降本的Kubernetes何时成了“成本刺客”？

YouTube如何利用MySQL支撑24.9亿用户？

人肉运维100次后，年底出了P0级故障……

关于国产数据库我不得不说

分库分表，可能真的要退出历史舞台了！