信创改造和适配实践如何落地？
【栏目主编】邓毓 江西农信运维技术经理：本议题由利安人寿资深工程师陈萍春、某省农信资深技术经理雷智、江西农信运维技术工程师万宏宇几位专家发表议题下的关键主张，几位专家的主张在秦皇岛银行信息科技部总经理王登峰、某农商银行架构师胡海光及我本人等多位专家的复议后，形成了一定的共识，希望可以对同行有一定的参考。
陈萍春 利安人寿资深工程师：
迅速发展的技术生态意味着技术应用尚未进入成熟期，技术发展的方向也趋于多元；再加之对于如何应用信创技术栈，大多数技术人员缺乏经验，这也给信创改造落地工作增添了更多的困难。
科技已成为大国博弈的重要利器，信创是我国IT产业发展升级采取的长久之计，具有重要战略价值。对于金融行业来说，坚持关键技术自主可控原则，降低外部依赖、避免单一依赖，也具有重要意义。
信创产业生态链发展迅速，国产基础软硬件也逐步从可用成长为好用。不可否认的是，迅速发展的技术生态意味着技术应用尚未进入成熟期，技术发展方向也趋于多元；再加之对于如何应用信创技术栈，大多数技术人员缺乏经验，这也给信创改造落地工作增添了更多的困难。
下文将聚焦分析信创改造落地过程中的各种难点，做一些经验分享：
项目落地要点一：项目进度的把控
首先从逻辑维度看，需要先确定项目的目标，再详细分析项目需要的资源，并制定好项目实施计划。在项目实践中，难点在于项目资源的合理估算，分拆成多个子项目再汇总计算。
其次从时间维度看，项目需要划分不同阶段，其中项目的关键节点时间需要重点把控。在项目实践中，基础技术路线需要尽快确定选型，项目的采购进度与基础资源到货时间也需要加快推进，这样才能为应用系统的信创改造争取更多时间。
最后从技术角度看，由于信创改造涉及到多种技术方案，因此要根据项目资源情况控制技术方案的复杂度。在项目资源不足或时间进度较紧的情况下，应适当避免多种技术方案的集成，实施方案的复杂度也要循序渐进。
项目落地要点二：信创改造系统的选择
从系统改造的技术难度来看，办公管理类系统的信创改造相对成熟，但由于办公管理类系统涉及到公司日常工作的方方面面，新系统需要照顾到用户的一些使用习惯；一般类业务系统种类繁多，可以选择一些使用范围较小、关联度低、技术自主度高的系统，这类系统的改造难度不高；核心类系统往往跟其他业务系统关联度高，且涉及到公司的关键业务，信创迁移改造的难度较高，可以先选择实施部分较为独立的模块。
项目落地要点三：技术路线的选型
信创改造技术路线选项的最基础的原则是需要符合信创技术标准，满足信创工作要求。总结来看，如果技术储备不足，可以多借鉴行业成功经验、采用主流技术路线与可靠的技术架构，保证项目实施不会影响到系统的稳定运行。
首先是基础硬件方面要有多种备选方案，考虑部分硬件不能到货或技术连续性的风险。例如考虑供应链与技术的可持续性，选择多芯的策略已成为一种共识，技术路线可参考图1：
图1：金融机构国产芯片技术路线选型统计占比
其次是基础软件方面可以同类型的软件多做适配测试，但考虑到落地实施时的标准化，最终方案的选择肯定要收敛。建议从多个维度去评估选择，大多数情况是只选择一种或者两种。
项目落地要点三：系统集成实施
系统集成实施重点需要考察的厂商，厂商的信创落地实践经验非常重要。如果项目没有总集成商，那可以重点评估两类厂商：云厂商和应用系统厂商。
借助云厂商的实施经验，基础硬件和操作系统层可以更容易规划落地，是硬件方面的集成；借助应用系统厂商的实施经验，基础软件和应用系统也能更轻松的实现对接，是软件方面的集成。
项目落地要点四：基础资源的规划与架构
信创改造项目也要考虑成本收益平衡，计算资源方面考虑虚拟化服务器与物理服务器的组合使用，存储资源方面需要考虑提供块、文件以及对象存储接口的需求。信创改造系统也更要重视高可用架构设计，确保系统的稳定运行。
在计算资源方面，系统负载较高的应用和数据库可采用物理服务器部署，其他一般系统负载的采用虚拟化服务器。考虑到国产芯片的性能略有不足，在资源规划时，要适当降低信创服务器CPU超分比，并可适当增加一些内存，以满足信创改造系统性能的需求。
在存储资源方面，主要区分高性能存储和普通存储，通过全闪存存储提供高性能的块存储和文件存储服务，通过分布式云存储提供更大容量的普通存储服务。
项目落地要点五：软硬件的兼容性
前期的技术调研可以有效减少软硬件的兼容性问题，但信创落地改造中，软硬件的兼容性问题也还是很难避免。主要是硬件层与软件层的不兼容和软件层间的不兼容两类问题，硬件层之间的不兼容问题相对较少。
硬件与软件的不兼容：这类问题一般是由于硬件层面有更新，而操作系统或云平台这类软件并不能很好地适配这些硬件。在落地实践中，我们就遇到了服务器Raid卡较新导致操作系统、云平台软件安装失败的问题。如果软件层不能迅速通过补丁方式去兼容新的硬件，那就只能更换硬件部件。
软件层间的不兼容：由于操作系统软件的基础性作用，这类问题要重点考察操作系统软件与其他软件的兼容性。云平台软件的基座使用的哪种操作系统，又能提供哪些版本操作系统的虚拟机，都有一些限制；其他基础软件，特别是一些开源组件的安装，往往需要自行重新编译。
雷智某省农信资深技术经理：
“应用尽用，使用信创是常态、不使用信创是非常态”。信创化显然已成为我国信息科技发展中必须考虑的关键因素。
一、引言
“应用尽用，使用信创是常态、不使用信创是非常态”。信创化显然已成为我国信息科技发展中必须考虑的关键因素。如何开展信创改造和适配落地是各行业各机构均需面临的普遍问题。
本文以银行业一般类业务系统“存贷款服务平台”的信创改造和适配落地实践为例，介绍应用系统在信创改造和适配中的需求分析、建设方案及改造实践，以供同业参考。
二、需求分析
为满足全行互联网金融发展需求，解决目前存贷款传统系统压力过大、承接更多面向互联网渠道、直接对客的线上存贷款业务等问题，计划参照“云技术”选型，使用国产化软件和硬件搭建省联社云架构微服务治理平台。拟在华为全栈信创云部署新外联平台、内联平台、服务整合平台以及微服务架构集群，底层服务器计划采用鲲鹏芯片服务器。服务器操作系统支持麒麟等国产操作系统。数据库支持国产数据库，可部署于达梦、海量、南大通用等数据库。
2.1系统改造需求
平台整体技术路线。实现信创需求目标：①采用国产化芯片服务器，ARM架构鲲鹏服务器、X86架构海光服务器；②采用国产化操作系统，麒麟KOS、统信UOS；③使用国产数据库，海量、达梦；④平台应用软件使用国产化微服务平台。
2.2业务功能需求
支持线上自有渠道客户贷款申请、放款、还款等业务的自助办理。
一期实现贷款产品的优化，主要功能包括：村民信息增删改查、评议结果查询、影像接收、合同接收、提醒服务、影像信息查询。
后期逐步整合微贷线上线下产品，支持自有多渠道线上客户服务、外部多渠道客户服务引流，实现客户线上申贷、客户经理线下APP办贷、银行线上审贷和客户线上签约放款的“线上线下一体化”相结合，全面提升全行小微金融服务水平。
2.3性能及非功能需求
平台总体设计需要要遵循组件化、模块化、参数化设计原则，保持软件系统架构的易于改造和扩展，满足新业务功能的不断扩充，不影响应用系统的各种原有功能。具体要求如下：
1）安全可控要求：整个系统的各种软件、硬件均应符合相关的安全可控标准。
2）开放性：开放服务体系为服务供应者提供统一的服务开发规范、服务注册和发布模式，为服务消费者提供统一的服务接口、服务使用模式，为渠道平台和产品平台提供开放的系统级服务。
3）架构先进性：具有先进的理念和技术架构，符合银行业发展的趋势，能够支撑全行现有及未来业务的开展。
4）稳定性要求：提供的产品成熟稳定，具备国内大型银行成功的实施案例，可以对外提供7*24不间断服务。
5）高可用要求：支持高并发量的系统请求处理，能够支持100的TPS要求。能承受用户峰值时间段压力，能够满足自身业务处理的要求。用户进行业务功能操作时，排除网络延迟的干扰，端到端响应时间小于3秒。
6）易管理性：在实际运行过程中，系统能很方便地对系统的运行状态进行监控，查看业务服务质量情况。
7）安全性：提供加密、解密完整性检验、人员管理权限等功能满足安全规范。
8）经济性和实用性：在系统建设中应充分考虑经济性，采用成熟、先进和适用的技术，在系统设计时必须遵循保护我行投资的原则，充分利用我行提供的软硬件资源，尽量减少开发成本、实施成本和维护成本，设计系统规模、软件功能和业务功能相应用的系统。
9）健壮性：在一些特殊情况发生时，依靠架构的有效设计，仍然能保证系统的正常运行。
三、建设方案
3.1总体目标
本项目设计的总体目标是通过存贷款服务平台为省联社未来应用信贷业务系统建设、业务开发、业务创新提供能力和资源整合的平台。最终改造后可以承载机构约100万用户，日均交易约700000笔，高峰交易并发数约190笔/秒，改造后满足系统运行指标要求。
在本期项目建设中，利用信创备份产品，实现对操作系统、数据库和应用系统的灾备备份。在后续的项目建设中，再逐渐对灾备架构进行完善，增加存储双活、双数据中心应用级灾备和双活数据中心应用双活等灾备方式。
3.2整体安排
本次信创改造针对新建平台提出了采用信创芯片服务器、操作系统和数据库。整体计划划分为：需求分析、方案设计、适配测试、业务测试、版本投产和运维保障。对应阶段工作内容如下：
需求分析：针对本次改造提出的信创需求和业务功能需求。完成需求分析和可行性分析。方案制定：针对需求制定实施方案，制定具体进度计划。
适配测试：在行方测试环境中与其他关联系统进行系统联调测试，保证之前的相关软件接口功能可正常运行。进行压力测试，确保信创改造后系统性能可以满足目前应用要求。
版本投产：安排时间进行版本投产，正式投入使用。
运维保障：安排厂商相关人员执行投产后软件版本的运维保障工作。
3.3迁移方案
上线前数据迁移：上线开始时停止业务，信贷管理应用停机，省农信微信小程序前端暂时停止服务，确保不会在数据迁移中产生生产数据。方案将信贷系统的用户信息表、机构信息表、村民信息表、村民家庭信息表、三方评议表、合同表等信息移植全量导出。以竖线分隔符的格式导出UTF-8编码的数据文件。文件FTP转入新平台，全量导入新建数据库。
数据回退：从新平台中将三方评议表、村民信息表、村民家庭信息表全量导出供给信贷系统，另外信贷系统根据实际产生的数据生成待提醒表。
数据备份：项目上线后会将现有单机MySQL数据库调整为两台主备数据库，根据数据库适配测试情况，制定相应的数据备份机制。若在适配验证中，信创数据库同步机制满足应用实时性、准确性要求，则采用两台数据库实时同步，增强了应用可用性。否则采用主备模式，通过自动任务定期将主数据库备份至从数据库，保证数据安全。
3.4测试方案
1)功能测试
本次需求功能测试采用标准测试流程进行实施，包括测试准备、计划、需求分析、设计、执行和总结6个主要测试阶段和过程进行实施，测试实施过程中的产出物，包括测试需求、测试案例、测试执行结果、测试缺陷，进行统一管理，并实现各测试之间的关联。
2)性能测试
本次性能测试会在上线前执行测试，并配合开发以及相关工程师进行系统的调优与复测，大体分为三个阶段：
第一阶段：基于测试环境进行测试准备(脚本、场景等)；
第二阶段：基于测试环境进行第一轮正式测试，以及验证在测试环境上的系统处理能力以及验证系统异常表现情况；
第三阶段：基于第一轮正式测试优化后复测；
本次性能测试主要采用测试工具LoadRunner分别模拟发送交易报文的方式，按照各测试场景中的交易配比/用户配比向被测系统发送请求数据包，对被测系统施加压力，并在测试执行过程中针对各服务器、重要部件和关键节点进行监控，以此获取系统的性能表现。
四、实施情况
4.1部署架构
1)网络架构图如(图2)：
图2：某银行存贷款服务平台信创改造网络架构图
2)物理架构
图3：某银行存贷款服务平台信创改造物理架构图
4.2软硬件配置
基于华为全栈信创云平台，22台服务器作为计算节点，使用云平台存储资源。
表1：信创产品配置信息表
4.3运行情况
系统投产上线后运行正常，承载机构约100万用户，日均交易约600000笔，高峰交易并发数约150笔/秒，改造后满足系统运行指标要求。
五、结语
信创改造和适配是信创在各行业落地的必经之路。本位以某银行存贷款服务平台的信创改造和适配为例，重点介绍了系统改造需求、业务功能需求和性能及肺功能需求，建设方案的总体目标、整体安排、迁移方案、测试方案以及部署架构等信创改造及适配的重点内容，希望能抛砖引玉，为行业的信创发展提供有益的参考。
万宏宇 江西农信运维技术工程师：
信息技术应用创新发展是国家目前的一项战略重点，也是当今形势下国家经济发展的新动能。发展信创是为了解决本质安全的问题，作为其中的重要组成部分，服务器可以说是至关重要的。由于历史原因，小机下移是无法规避的问题，如何选择一条模块化的标准路径是十分值得探究的问题。
根据信创工作总体安排，经过自查，发现我行小机保有量较高。为铸牢信息化“底座”，统一标准，统筹衔接“存量”和“增量”，全方位打穿应用之间、数据之间的信息化壁垒，并融入前端科学技术，进行了小机下移的攻坚研究。主要内容如下，以供同行参考：
一、主要研究方向
通过对行内小机应用部署情况的排查，发现小机上所部署的产品，主要集中于IBM的WAS中间件和Db2数据库，WAS与Db2与小机的兼容性较好，性能稳定。针对此种情形，为形成格式化、模块化的标准流程，便尝试将WAS和Db2迁移至信创服务器上，并使用行内正在运行的电子验印系统进行挡板压测，通过对比性能，得出迁移可行性结果。
二、环境准备
2.1硬件环境准备
本次迁移测试，使用了两台海光X86服务器，其中应用服务器使用的是物理机架构，数据库服务器采用了单机VMware，虚拟出了一台CPU：16C、64G和1.2T的虚拟机用于部署数据库。
表2：硬件环境配置图
2.2软件环境准备
1)WAS部署
WAS服务器安装了Red Hat Enterprise Linux7.4操作系统，考虑到与传统环境一致性，采用了IBM WebSphere Application Server 8.0.0.5。接着完成了用户准备、应用服务器目录准备等相关准备工作。
2)数据库部署
数据库服务器采用了Db2 11.1.4.4版本，在完成用户、目录及实例等准备工作之后，下一步就是数据库搭建工作。
3)数据库搭建
由于环境的差异性，Db2因从AIX环境迁移至Linux环境，无法进行整体迁库，只能通过建表导数的方式进行数据的迁移。我们首先导出传统AIX环境下的数据库建库语句，接着修改环境变量之后，最后通过手动的方式完成Linux环境下建库、建表与数据导入相关工作。
2.3应用部署
本次进行迁移测试的系统是电子验印系统，该系统利用扫描设备提取票据等业务凭证影像，通过与已存入的印鉴图像信息进行数据比对，判断图像信息中的印鉴图像信息的真伪，实现印鉴验印电子化过程，解决纸质印鉴管理问题及扩大支付结算业务范围，降低支付风险、保障银行和企业资金安全。通过WAS将应用部署至信创服务器。
三、测试过程
本次测试旨在完成小机下移至信创环境的可行性验证，性能测试拓扑图（如图4）主要从获取系统整体最大处理能力与验证系统是否能够长期稳定运行两个角度开展测试工作。测试过程较为顺利，测试结果符合预期。
图4：性能测试拓扑图
3.1测试范围
压力发起策略为：通过LoadRunner模拟发压，到单台应用服务器，再到数据库；部分交易走核心挡板。
3.2测试需求
1)业务模型
表3：业务模型表
2)测试功能点
表4：业务流测试功能点
3)性能需求指标
系统在多用户并发下的性能指标，主要包括：
交易成功率：
是指交易成功的数量占发出总交易量的百分比，通常选取99.9%或者99.99%；
资源使用：
CPU：各场景测试过程中不高于85%，稳定性测试过程中不高于75%；
内存：各场景测试过程中不高于85%，稳定性测试过程中不高于75%，或测试过程中内存使用率波动值不超过5%；
3.3测试过程
本次测试分为三种模式进行：
1）混合测试
采用30-150梯度并发用户按照业务模型交易占比执行混合测试，每组用户数执行3分钟，获取信创环境电子验印系统综合处理能力。
30并发用户数时对应TPS为系统最优处理能力，此时TPS为45.613笔/秒，对应各交易响应时间小于2秒，各服务器资源使用率在安全范围内；该TPS可满足生产日交易量约324000笔。
2）C环境对比测试
将系统切换至行内C环境，采用30-150梯度并发用户按照业务模型交易占比执行混合测试，每组用户数执行3分钟，获取C环境下电子验印系统综合处理能力。
传统环境与信创环境相比较，TPS、响应时间及CPU等性能指标差异不大，均在业务可以接受的范围之内。
3）稳定测试
采用20并发用户数按照业务模型交易占比单独对纯信创环境执行连续12小时稳定性测试，以验证系统是否能够长期稳定运行。
压测过程中共执行事务1461879笔，交易成功率100%，除关联交易响应时间有缓慢增长以外，其余交易系统处理能力基本稳定；除数据库内存使用率上升约10%外，各服务器其他资源使用率基本稳定，均在性能需求指标范围内。
3.4测试结论
在目前信创环境配置下，电子验印系统最佳处理能力为45.613笔/秒，对应并发用户数为30，对应各交易响应时间小于2秒，各服务器资源使用率在安全范围内；该TPS可满足生产日交易量约324000笔。系统具备稳定运行能力。
四、结论
首先，通过此次探索，软件层面IBM Db2及IBM WebSphere Application Server均可从小机下移至信创环境，只是Db2无法完成从AIX到Linux环境下的整库迁移，手动方式对数据量较大的系统不友好，工作量较大，这方面还需要持续探索。
其次，通地对比信创环境下和传统环境下的运行情况，可知信创环境下的应用在一定范围内可以达到传统小机的性能，但在高并发高TPS的情况下，信创环境还难以与小机环境比肩。
因此，可以得出结论。能够将部分业务量不大的系统从小机下移至信创环境，完成小机下移的部分工作。
结束语
本议题从聚焦信创改造落地过程中的难点问题入手，分享了项目落地五大经验要点，即项目进度的把控、信创改造系统的选择、技术路线的选型、系统集成实施、基础资源的规划与架构以及软硬件的兼容性。同时重点介绍了两个典型信创改造案例，分享了银行业一般类业务系统“存贷款服务平台”的信创改造和适配落地实践案例，以及银行小型机操作系统、WAS中间件和Db2数据库下移至信创服务器的测试案例。为企业信创决策提供了宝贵的经验和实践干货。
