全球要闻：金融信创 | 神州信息：浅析银行核心业务国产改造方案

随着过去两年对银行金融信创的探索，我们开始了对银行的核心业务系统即通常意义的存贷或业务系统，进行国产化改造升级。今天分享的内容主要是：第一，当前整体金融行业在核心替代方面的要求和我们的理解；第二，结合神州信息过去二十年的核心业务系统经验和近三年深度参与的金融信创尤其是金融核心改造，分享一些想法和典型案例。

▌政策要求及解读

从政策要求角度看，核心业务系统改造和原有的一般业务系统（关键业务系统、OA业务系统）改造有着非常大的差别。今年我们信创的一批、二批乃至三批用户在进行核心业务系统的信创改造过程中，包括大行、城商行、保险、基金、证券在内客户的核心业务系统改造遇到的难度超出过往。

【资料图】

▌整体核心业务系统的难点

第一个层面是基础软硬件方面，核心业务系统对无论国产服务器、国产操作系统、国产中间件和国产数据库，在整体稳定性、高性能方面有了更高要求。尤其是大量银行原有的核心业务系统构建在国外小型机、操作系统、存储乃至数据库的环境下，客户对核心业务系统配置到全国产化环境缺乏信心。

第二个层面是监管要求方面，对信创的核心系统改造提出了不同路径，包括生产环境、灾备环境和测试环境。今年我们看到，绝大部分用户开始针对核心业务系统替代方案进行规划设计，乃至在年底时上报整体可实现路径，在2023年初步实现上述三路径中的一个环境。同时在核心业务系统改造过程中，需要针对开源、第三方组件做相关管理。因为核心业务系统的业务等级和对于业务粘性的要求非常高，需要根据一些核心业务过程使用开源的情况做有效管理，甚至要及时修复使用中的漏洞。

▌三个需要特别关注的重点

在核心业务系统的替代过程中，无论单轨还是双轨模式的改造，都存在非常多的难点和重点。

第一点，在核心业务系统的构建过程中，一定存在信创云平台，对它需要做整体信创资源的聚合复用，包括后续相关组件的迁移管理以及整个资源环境的运维运营管理。

第二点，未来的核心业务系统一定构建在分布式技术平台上，把分布式技术平台引入信创核心改造过程十分重要，包括多活数据中心需要、大量服务组件如何实现服务化，以及对核心业务系统中大量分布式事务的管理。

第三点，绝大部分金融行业的核心业务系统数据库都需要根据类型、核心改造模式、规模和需求，合理选择集中式和分布式，但很多金融业务都选择采用分布式、微服务的方式实现数据库的改造替换。数据库是影响核心性能的重要资源，购买大量物理服务器，运行大量SSD和一些高端计算、存储资源，并不意味着能够保障核心性能快速稳定运行。数据库的选择和合理配置、运行维护都是影响核心性能的重要要素。

▌建议改造方案

最近的三四个月中我参与了多家银行针对核心业务系统改造的方案，在此简要介绍。

目前的主流环境有三种场景：并行环境、测试环境、灾备环境，各有一定的优缺点。

并行环境与现有生产环境组成AB角，区分业务场景或采用双写方式共同组成核心系统。优势是对于现有生产的异样影响较少，劣势是投资、维护成本相对较高。

测试环境是通过搭建信创的核心测试开发环境，新上的业务系统经过验证后再上线，最近很多客户为快速推进核心信创进行了选择。优势是投资较小、不影响现有政策，劣势是没有承载真正的生产，对未来监管的进一步要求存在一些不确定性。

灾备环境是在不改变现有生产环境的前提下，构建信创灾备的核心系统，能够实现对主中心的容灾。优势和并行环境一样，不影响现有生产；劣势是数据同步的RTO、RPO需要做仔细考量，对很多技术实现尤其是数据库的同步，可能存在一些技术上的难点或风险。

不管选择哪种环境，相关的架构设计以及数据库选型，都是关注重点。从信创改造的最佳实践也可以看到，结合过去一般业务系统、关键业务系统选型，神州信息在终端、服务器、操作系统，服务数据库、分布式平台、云平台方面积累了很多经验。包括服务器端的主流相关厂商，国内目前以鲲鹏、海光为主；操作系统方面，服务器端麒麟更多，终端方面可能是统信；数据库方面，尤其是分布数据库百花齐放，包括 TDSQL、OceanBase、GaussDB等，它们各有优缺点，最终还是要结合实际情况，通过PoC结合改造验证以及后续运维的掌握来评估。当然也有一些传统集中式数据库存在，但核心业务系统替代一定引入了分布式的技术平台，因其能够实现应用和数据库的结合，更好地构建一个面向未来的分布式和微服务的核心业务系统。

总体而言，核心业务系统的现状改造，涉及到整个操作系统、服务器、数据库、中间件、分布式平台、云平台的一系列完整过程，核心业务系统的替代时间可能长达3年甚至5年。

关键词： 核心业务 业务系统 操作系统