提振自主创新 强化科技风险防控——交通银行支付清算类系统信创改造.pdf

Cover Story/封面专题提振自主创新强化科技风险防控交通银行支付清算类系统信创改造文交通银行软件开发中心周密交通银行认真学习贯彻总体国家安全观战略思想，积极落实习近平总书记“实现高水平科技自立自强”部署要求，深入践行人民银行“支付为民”理念，依托交通银行“十四五”规划，聚焦在数字化转型过程中提升自主创新能力和科技风险防控能力，全面推进支付清算体系的信创改造，现以交通银行超级网银系统改造为例，分享支付清算类系统信创实践经验。交通银行超级网银系统概况交通银行超级网银系统负责对接人民银行网上支付跨行清算系统，是交通银行跨行转账的主要支付清算基础设施之一。交行超级网银系统于2 0 10 年投产，原先采用的技术栈为国外供应商的集中式数据库、消息中间件、小型机设备等，部署在单一站点上。系统7 2 4小时对广大客户提供跨行转账服务，日均交易量在千万级，具有小额快速、实时支付结算的特征，月末、季末遇到特定公司客户或特定产品的代发代收转账时，如年金代发、工资代发、保费代发等，具有高并发瞬时冲击的特点。面临的问题和挑战一是关键技术栈自主可控能力薄弱。数据库、操作系统、消息中间件、应用服务器等关键软硬件技术均使用了国外供应商的技术栈，不具备自主可控能力。二是系统单一部署，不具备双活能力。原集中式设计的应用部署架构弹性不足，集中式数据库存在单机性能瓶颈，数据库部署层面不具备高可用性。三是缺乏敏捷响应能力、运维成本高。每逢月末、季末遇到大规模瞬时代收付交易，均需要进行特别的人力保障，缺乏快速扩容、敏捷应对支付业务场景需要的能力。技术路线选择为提升自主可控水平，交通银行全力推进信创改造，按照主机、支付清算类系统、一般业务系统、渠道类系统分门别类推进信创重构。按照交通银行信创改造的统一技术标准和规范，支付清算类系统采用“上云+分布式+同城双活”高可用的技术路线，实现全技术栈的改造。根据超级网银系统支付清算类交易运行特点，并解决原集中式架构性能瓶颈、难以应对潮汐式冲击等痛点，我们在应用层面、中间件层面、数据库层面和底层云计算基础设施都进行了针对性选型。一是应用层面改造。应用层采用同城双活云化部署，使用了交通银行自研的云管服务平台。项目采用自研的分布式微服务开发框架（JUMPCLOUD）研发，以云原生架构方式部署，托管在交行自研的容器平台（DCPP），应用在同城两个机房云站点分别部署，通过同站点优先访问配置，实现应用层的双活高可用。二是中间件层面改造。采用了国产消息中间件和开源消息中间件Kafka、缓存中间件Redis。项目经选型比对，使用了MQ替换了原国外MQ消息中间件产品。在改造过程中，项目团队一起调优了中间件产品，解决了替换过程中高并发下配置调优问题、消费者数量过大引起的同步传输遍历问题、节点启停智能监控等问题。除了使用MQ中间件进行跨系统实时双向同步交互外，超级网银系统结合自身特点也采用了Kafka消息中间件，与外系统进行准实时数据同步，如转账交易流水数据在交易发生时，可通过Kafka实时同步给数据加工分析系统，实现跨系统间数据的高效互通。此外，非久化数据等保存在Redis缓存集群中，确保业务层面的高效响应。三是数据库层面改造。针对原集中式数据库运行痛点，选型了交行自研的分布式数据库CBASE。C B A S E采用先进的分布式数据复制算法、高可靠性的数据一致性算法，消除了传统关系型数据库主从复制技术下从节点给主节点带来的风险。在技术实现上，多台服务器协同工作，完成高并发数据量处理任务，通过网络技术将物理上分开的数据库连接在一起，具有逻辑共享性一一对超级网银业务逻辑数据分布式存储但共享式管理；业务透明性超级网银云上微应用无需关心数据存储在哪台数据库服务器；复制高效性一一单台数据库服务器故障不影响整体复制和自动重新选举；事务可靠性一一数据存储和使用采用高可靠性的一致性算法。该数据库系统吞吐支持线性扩展，灾难恢复时间为23封面专题CoverStory秒级，十分契合超级网银系统的实时转账月末、季末潮汐式高并发应用特征。超级网银交易分为联机交易和批量交易，联机交易主要是人行往来账等账务实时处理交易，批量交易主要包括统计、对账、数据导入导出等。批量交易的执行往往对系统资源占用较多，如果与实时交易在同一个数据库处理，可能会影响实时交易，导致其响应时间增加。因此，我们搭建两个独立数据库集群，分别处理联机交易和批量交易，两者通过自研CDC工具进行数据单向同步，方便对账数据的批量处理。联机库和批量库都采用三机房多活部署，实现机房级高可用（如图所示）。四是硬件和操作系统层面。云平台底层均按照统一标准选型了服务器和操作系统搭建，实现双站点或多站点高速组网，支持应用层面灵活的高可用部署方式和机房级容灾。实施推广路径在上线推广过程中，考虑到项目采用了交通银行自研产品、第三方信创中间App1App2(JDBC/ODBC)(JDBC/ODBC)中间件层（负载均衡）SQL处理节点SQL处理节点事务处理节点（备）事务处理节点（备）事务处理节点（备）事务处理节点（备）事务处理节点（主）事务处理节点（主）数据分片1数据分片1数据分片1图图CBASE数据库采用多活部署，实现了高可用件、开源中间件等，为确保支付清算系统的7 2 4小时运转和稳步推广，项目组实施过程中采用双轨模式逐步向单轨模式切换的举措，以“可监控、可灰度、可回滚”的方式，有效降低了上线风险。一是先完成技术投产。择机进行技术验证，主要验证部署方案、监控方案和各项产品组件联通性、可靠性。二是挑选试点客户进行白名单验证。超级网银系统的请求方设置账号和分行白名单，白名单内的交易发送到超级网银信创新系统，非白名单内的交易发送到超级网银老系统。老系统设置账号和付款银行白名单，白名单内的他行来账交易由老系统转发到超级网银新系统。三是分批进行切流推广。在完成白名单内试点客户验证，证实了交易的正确性后，每月逐批增加切换分行，验证信创系统的性能容量。待运行稳定后，逐步逐批增加切量分行、对手行，以达到稳定加量、验证瞬时冲击的效果。四是在人民银行网上支付跨行清算系统运维窗口期间，实施双轨转单轨操作，AppN(JDBC/ODBC)SQL处理节点SQL处理节点事务处理节点（备）事务处理节点（备）事务处理节点（主）数据分片2数据分片N数据分片2数据分片N数据分片2数据分片N并进行数据移植。超级网银系统的转账交易流水数据量大，特点是批量对账后不会再修改。账户查询协议，授权支付协议和参与机构等其他数据量每日改动量相对较小。故基于数据特点，项目的数据迁移策略是转账交易流水数据每日迁移至新系统，其他数据双轨转单轨时迁移。五是在整个切换过程中，通过自研的数据实时同步工具JUMPCDC，实现了新分布式数据库到老集中式数据库的数据准实时同步。确保并行期期间，始终具有一套完整的准实时业务数据，具备应对系统级灾难故障时的数据应急保障条件。上游请求方系统、老超级网银系统均设置新老系统切换参数开关，确保应急情况下的应用回退措施快速、有效。总结与展望交通银行超级网银系统于2 0 2 2 年完成改造和双活部署上线后，相关技术路线经过实践检验，解决了原有痛点，目前生产运行良好，有效支撑了交通银行跨行转账业务，与人民银行网上支付跨行清算系统互联互通且支付清算稳定、高效，每月均获得人行清算总中心运行报告5星好评。交通银行在后继的支付清算系统信创改造中，如大小额支付系统、跨境人民币SQL处理节点支付系统、境内外币支付系统等，均借鉴了分布式数据库、分布式云平台的开发部管理节点（备）署经验，包括“可监控、可灰度、可回滚”管理节点（备）管理节点（主）数据存储层数据流控制流的分批次上线推广经验，确保系统7 2 4小时稳定运行、推广切换稳步可控。下一步，交通银行将继续加快推进数字化转型，围绕交行“一四五”战略，充分运用科技手段提升“服务实体经济、防控金融风险、深化金融改革”的能力和水平，以高质量的金融科技发展，助力中国式现代化。24