【摘要】本文作者分享了某银行多套业务系统数据库国产化替代的案例，分析了信创数据库国产化适配遇到的问题和应对措施，详述具体实践过程，并提出了其中观察到的问题。其经验值得大家参考借鉴。
建设背景
党的二十大报告提出，“加快实现高水平科技自立自强”。对于金融行业来说，数据库是金融信息系统建设的核心基础设施，承载了核心的交易业务和关键的业务数据，在信息系统的软硬件之间也起到了承上启下的核心作用。
年初，人民银行发布《金融科技发展规划（2022-2025年）》指出：加快制定并组织实施金融业关键软硬信息基础设施安全规划，切实提高金融业关键软硬信息基础设施安全保障能力；银保监会印发《关于银行业保险业数字化转型的指导意见》强调，“提高新技术应用和自主可控能力，坚持关键技术自主可控原则”。
数据库建设是IT基础建设的重要组成部分之一，数据库产品将直接对应用系统的效率及实现的效果产生影响，关系到整个信息系统建设的安全、可靠、可持续。
一方面，从产品技术角度，我们需选择真正自主可控、国内厂商掌握核心源代码的数据库产品。另一方面，从业务角度，为了确保业务高效稳定的开展，降低数据库产品更换可能对业务造成的风险，我们需选择稳定可靠，功能完善的数据库产品。
结合国家的信创要求、在人行的信创工作指导下，作为第三批信创试点单位重点针对办公系统、金融机具、一般业务系统、关键业务系统开展信创替代相关工作。
信创数据库国产化适配遇到的问题和应对措施
遇到的问题
在国产数据库适配改造过程中，我们主要遇到了以下几个问题：
1）选型适配问题
构建信创基础环境，涉及到网络设备、存储设备、服务器设备、操作系统、数据库、备份厂商等技术领域，如何进行选型适配才能满足我行业务系统的对数据库的可靠性、稳定性及性能等要求。
2）容灾架构问题
根据业务连续性管理和系统业务影响分析报告要求，要求信创改造的系统，在异地数据中心实现数据级或应用级灾备建设，相关系统需要具备数据级或应用级灾备恢复能力。如何进行数据库容灾架构设计，才能满足我行金融数据高可靠的灾备要求。
同时，每年会进行数据中心级真实切换演练，以验证灾备中心基础设施的可靠性，如何实现各系统的灾备自动切换演练也是需要考虑的问题。
3）资源争用问题
为节约建设成本，我们计划将多套业务系统的数据库部署于一套资源上以验证信创产品多系统支撑能力。但业务高峰期可能会引起资源争用，影响各业务正常运行。如何解决多系统共用资源导致的资源争用是亟待解决的问题。
4）应用兼容性问题
SQL 兼容性是业务迁移到国产数据库绕不开的议题，SQL 兼容度高意味着更低的业务逻辑改造成本和更稳定持续的业务服务保障。对原有应用系统升级的改造成本较高。企业已经建设的应用代码和架构可能与分布式数据库并不兼容，需要进行相关改造，两者兼容性越低，改造的工作量和成本越大。
应对措施
目前银行实施信创数据库架构选型的应对措施：
1）选型适配问题
针对存储设备、服务器设备、操作系统、数据库、备份厂商，我们根据中小银行自身的特点，优先选择架构同X86类似的海光平台和同CentOS类似的麒麟操作系统。在这样的环境下，软件厂商的适配兼容性会比较好，在底层环境上，采用海光CPU平台和定制化的国产服务器，搭载Kylin V10操作系统。网络层采用全国产交换机，确保了全平台细粒度的国产化。
存储设备，使用了国产集中存储存放集中式的数据库。使用集中存储可以有更好的IO吞吐量，备份厂商选择了国产排在前列的备份厂商。
2）容灾架构问题
对于银行的灾备环境的建设，着重考虑数据库的主备本地切换和数据库的本地和异地双中心之间的切换。国产数据库根据不同技术栈可以分为分布式数据库和集中式数据库，分布式数据库使用了两地三中心架构。集中式数据库使用了一主+一实时备+异地备的架构。
这里说下实际使用集中数据库在切换过程的经验。我们发现集中类型数据库在本地中心一主+一实时备架构下，可以做到平滑切换。但是在本地和异地中心进行数据库切换，可能需要做大量准备工作，才能实施切换。这种问题，也已经反馈给数据库开发商，希望后继版本可以通过更好的工具进行优化。
3）资源争用问题
资源争用也是需要考虑的一个问题，信创化过程中，我们发现国产产商对软件的授权要求都非常高，因此如何有效的使用现在的国产信创设备也是摆在我们目前需要考虑的问题。
目前最理想的情况：在不构造虚拟化平台，最大化发挥硬件性能、同时多系统部署的情况下，要解决不同进程间资源争用问题，要做到资源的合理分配以及权限的独立划分。针对这个问题。我们当前的做法采用单个服务器部署多个数据库实例的做法。通过不同的用户和不同的实例之间的一一对应关系，可以有效的利用服务器的资源。
另外在数据库参数方面做了大量的优化工作，尽量避免在在业务高峰期，出现资源争抢的问题。
4）应用兼容性问题
一是建立专班组织架构。以行长为组长成立数字化转型领导小组，组建境内外核心下移推进办公室组牵头项目专班管理工作，下设相关组共同推进，从而确保能够全面规划实施节奏、统一项目调度，实施工程化管理。
一方面针对不同的业务属主和重要性级别，逐步从周边系统开始改造，适度积累经验，实现从0到1的然后进展到更大范围的改造。
同时针对某些系统的级别要求，可以保持双轨运行一段时间，确保业务跑在国产数据库上，同时原有的库作为备份库进行运行。
另一方面形成详尽的改造工程方案规划，通过压力测式，专项测试、数据库比对、迁移演练、双活切换、网络备份等，确保出现异常时能够快速形成兜底机制，保证系统平稳运行。
具体实践
在对数据库信创改造思考之后，依托数据库信创项目开始了新一轮实践。
信创数据库的功能测试
在传统功能测试中充分考虑到各个业务模块对信创数据库的兼容性。明确该系统是Oracle类型还是MySQL类型的库。
根据类型选择改造后存放在集中数据库（Oracle兼容模式）还是分布式数据库（MySQL兼容模式），梳理当前数据库享有对象的类型，分级为表、索引、序列，存储过程，触发器进行分类处理，针对基本的表和数据和索引、序列，目前国产集中式数据库都是可以顺利迁移。
复杂的存储过程和触发器，需要在迁移过程中，对部分应用逻辑进行更改.
部分旧的Oracle系统自带函数在新的国产数据库可能存在不兼容和不适配的地方，需要一一根据实际情况进行修改，并且在测试环境进行完整的测试，确保每个应用场景都可以覆盖，每个接口都可以顺利运行。
信创数据库的性能测试
信创数据库的性能测试也是需要重点考虑的地方，因为传统的oracle数据库在性能优化和sql优化分析器上已经做的比较完善了，通常来说，笔者认为国产的集中数据库如果能在性能上达到国外的厂商的8成左右就是可以接受了。
当然某些场景下，国产数据库的表现更加好。实践路线如下：分别基于传统资源环境下和信创环境下的不同业务场景做了压测对比分析。结果表明，在基于国产数据库的信创环境下的业务系统性能不低于传统环境下的业务系统性能，可以满足业务系统性能要求。
测试结论分析：
（1）交易A：总体对比可以得出，信创改造版本性能略高于非信创版本，平均性能提升估算值约5%左右。
（2）交易B：总体对比可以得出，信创改造版本性能低于非信创版本，平均性能下降估算值约10%。
信创数据库迁移测试
以下是某国产集中数据库的在数据迁移方面的经验，根据数据库迁移的总体体量作为一个重要的考虑方向，如果数据库本身体量不大，比如在100G以内，可以优先考虑采取停止应用。
然后整理一次性迁移数据库的过程，这个过程同传统Oracle逻辑备份，导出导入数据库类似。可以有效的完成数据库的全量迁移，同时保障数据库的完整性和一致性。如果数据库体量过大，超出了200G以上，这个时候使用传统的导入导出，可能会导致迁移的时间过长，影响业务的范围更广，因此，这个时候，可以考虑使用厂商的全量+增量工具。
需要注意的是如果使用厂商的全量+增量工具，需要使用脚本工具对迁移前和迁移后的数据对象总量以及表的具体数据做比对，比对迁移前后的报文和结果差异，开展移植数据功能测试，投产后由业务人员开展业务验证，业务验证要进行全面的验证，查询和交易都要进行验证，全面确保移植数据的正确性。
数据库切换测试
在初步调研后，发现国产库集中数据库的双机管理方式与传统的Oracle数据库不一样，Oracle数据库的双机管理方式使用了专门的第三方厂商的 VCS 厂商工具，实现主备机的双机冷备切换。
国产集中数据库的生态链并没有做到那么完善，因此国产集中数据库厂商给出的解决方案，是使用数据库主库加备库的管理模式，实现主备数据库的切换。如果是本地同城切换，使用一主加一备的解决方案，如果两地之间的切换，则使用一主加一备加一远程备库的方案。
在实际实践过程中，发现集中类型数据库在本地中心一主+一实时备架构下，可以做到平滑切换。但是在本地和异地中心进行数据库切换，需要做大量准备工作，才能实施切换。这种问题，也已经反馈给数据库开发商，希望后继版本可以通过更好的工具进行优化。
技术栈学习
通过实践发现，新的技术栈学习，对每个开发和运维人员都是不得不面对的事情，以下是集中数据库的技术栈学习的过程。
- 在初期阶段，我们参加了原厂组织的培训，通过培训，取得了原厂的认证证书，初步对数据库的架构和基本概念和实操有了初步概念。
- 在后继测试运维阶段，通过对国产数据库的实践深入，同原厂厂商一起沟通商量，分别完成测试环境的数据库版本统一规划，并且统一规划了连接应用连接的jar包，并且根据项目组遇到的oracle到国产数据库迁移的案例。
- 整理了多个案例，通过这些案例，初步建立开发对该国产数据库的使用概念。在后继深入阶段，通过请原厂工程师来给开发和运维现场讲课和分享案例ppt交流模式，使得开发对该数据库有了更加深入的了解。
同时我们对比当前的Oracle数据库，发现目前国产数据库对生态建设普遍存在投入力度不够的问题。
Oracle的强项在完善丰富的文档体系和活跃的技术社区。借助文档和社区，能对Oracle进行体系化的学习和针对性的问题讨论，就此培养出大量熟悉Oracle的开发者和数据库管理员，也由此推动了Oracle自身产品的不断成熟。
目前，不少国产数据库厂商对产品文档和社区建设还缺少足够的投入，例如产品文档中存在不少错漏或前后不一致的表述，这些都是各厂商后续仍需改进的地方。
性能问题处理
性能问题通常是比较需要重视的地方。在和国产数据库厂商交流后，发现目前的国产数据库在优化解释器可能还有些需要改善的方向。
开发有时会告诉我们这样的信息。一条同样的语句，在Oracle可以执行的效率比较好，在该国产数据库上执行的效率比较慢，这个时候，我们通常需要联合国产厂商的数据库优化高手，一起完成问题分析，定位，优化。
在优化的方法论上，国产厂商的总结和工具并不是特别的完善。比如：执行计划，执行计划信息之所以更受关注，我们分析是因为SQL是研发人员使用数据库的基础语言，而SQL的执行效率和性能会直接影响数据库整体性能；如作为特性化SQL的分析定位，这是现有的开源生态方案难以适配的，需要通过数据库厂商提供一体化的运维工具方案能否及时发现慢sql并且告知执行计划需要优化的方向。
遗留问题
通过对信创数据库项目在我行的研究和试行，在部分系统重构项目中收获了一定的成功经验，但仍有部分难题还有待进一步思考研究。以下是基于某国产集中数据库的观察，提出如下问题，希望后期可以改善：
- 如基于信创数据库的集群自动化部署实施，在一主一备一异步备库，如何实施自动化部署，才能确保较优的投入产出。
- 如基于信创数据库的监控可视化的监控工具需求，虽然各个厂商都有自己的监控工具，但要有基于业界通用的Zabbix和普罗米修斯的可视化监控插件，才能增加数据库可观察性。
- 如异构数据在线同步工具的搭建难度和推广，各个厂商有自己的迁移工具，是否能将这些工具做得更简单，更符合业务需求，而不是要求客户改造现有的数据库，以满足迁移需求。
- 如基本的数据库管理，比如更加简化管理难度，能否将归档日志和慢日志都集成到同一个参数文件，而不是做成每个配置一个文件的模式。
以上问题希望能在行业深入推进信创改造的过程中进一步摸索探讨，最终取得最优解，从而形成行之有效的实施经验、配套机制，让信创数据库工作真正做到安全可控，坚定行业发展信创战略的决心。我们相信银行业核心技术自主可控的明天即将到来，我国关键核心技术攻坚战也终将取得胜利。
添加评论