银行如何抉择“信创分布式数据库+虚拟化+专业SAN存储”架构技术堆栈替换路径？

　　（来源：twt企业IT社区）

　　 摘要 

　　银行在推进信贷等重要系统信创改造中，“信创分布式数据库+虚拟化+专业SAN存储架构”的技术堆栈替换路径设计、实施风险控制及各层兼容性保障，是金融机构面临的核心挑战。当前，多数银行倾向于采用一次性全栈替换方式以实现快速架构升级，成为行业主流选择。为降低改造风险，普遍采用并行运行与灰度切换的过渡方案，在保障业务连续性的前提下稳步推进。在兼容性保障方面，分阶段逐步验证被视为稳妥策略，有助于系统性问题早发现、早解决，从而确保系统稳定与业务可靠。

　　导语

　　在金融行业数字化转型的背景下，为有效兼顾信息技术应用创新与AI数据治理的双重要求，银行信贷类混合负载系统在技术架构选型上面临重大抉择。当前同行主流倾向于采用“信创分布式数据库+虚拟化技术+专业SAN存储”的架构方案，以替代传统的“Oracle数据库+VMware虚拟化平台+x86服务器+EMC/HDS/IBM高端集中式存储”的成熟技术栈。

　　然而，在这一架构转型过程中，金融机构普遍面临着信创替换的实施决策困境：一方面，若采取激进的一次性全栈替换策略，将“Oracle数据库+VMware虚拟化+x86服务器+集中式存储”整体替换，虽然能够实现技术架构的快速转型，但担心实施过程带来的业务连续性和系统稳定性风险；另一方面，若采用渐进式的分组件替换方案，虽然可以降低单次变更风险，但又必须充分考虑和验证各技术组件之间的兼容性问题，例如新型信创分布式数据库对既有虚拟化环境的适配性，以及新引入的SAN存储系统与传统虚拟化平台的协同工作能力。

　　因此，如何科学设计既确保系统安全稳定，又具备实际可操作性的替换策略和过渡实施方案，成为银行机构在此类系统信创化改造过程中亟待解决的关键性技术挑战。这一挑战不仅关系到系统架构的平滑演进，更直接影响银行业务的连续性和金融服务的稳定性。基于此背景，twt社区组织金融同行通过投票、深入研讨等多元化的方式，展开全面探讨，为银行重要系统信创改造中“信创分布式数据库+虚拟化+专业SAN存储架构”技术堆栈替换、如何降低实施风险及确保各层兼容性提供清晰的思路和具有重要参考价值的依据。本文将同行共识和探讨精华总结于此，供读者参考。

　　一

　　替换路径共识：多数银行倾向采用一次性全栈替换

　　同行投票，地址：https://www.talkwithtrend.com/Poll/476217)

　　根据投票调研结果统计，当前得票最多的为一次性全栈替换，根据银行机构用户的投票和反馈进行分析得出如下行业共识：

　　为平衡业务连续性与替换风险，约50%的用户更倾向于选择一次性全栈替换作为银行信贷系统技术堆栈的替换路径。其核心逻辑在于：服务器、存储、虚拟化及数据库同属基础设施层，分步替换需多次实施变更，不仅周期延长、操作风险累积，兼容性风险亦未必降低。而一次性全栈替换能够以业务整体表现为导向，统筹考虑服务器选型与应用、数据库、中间件等软硬件配置，避免局部优化而整体失控，同时减少后续二次适配的可能性。此外，一次性替换也有助于集中处理兼容性问题，将业务连续性风险压缩至单次变更窗口内。

　　尽管一次性替换具备上述优势，但在实际信创建设过程中，部分业务系统因条件限制无法实现全栈替换。因此，部分银行也会结合实际情况，选择分步骤替换服务器、存储、数据库与虚拟化等组件。

　　无论采用何种替换实施策略，所有替换工作均需提前完成产品的适配验证。服务器、存储、虚拟化，属于基础设施层，必须要提前建设完成国产集中式存储，因存储交换机的原因，一般走iscsi协议进行数据分配，所以存储替换要做功能、性能或架构的调整和验证虚拟化和服务器也同样存在与新的软硬件适配验证的问题存储及虚拟化建设的过程也包括了服务器和操作系统替换的过程完成了基础设施的建设后，才考虑数据库和应用软件的替换问题，信创改造的第一步就是基础平台的改造，第二步是数据库的替换测试，同时进行的还有应用的改造。

　　为平衡业务连续性与替换风险，技术堆栈的替换需遵循“基础设施先行、分层递进”的策略，优先选择技术成熟度高、对业务影响低的底层组件，逐步向核心层推进。基础设施（服务器、存储、虚拟化）可以先行。原因一是基础设施是上层应用的运行底座，其稳定性直接影响全栈性能；原因二是基础设施替换可通过虚拟化实现资源隔离，新旧系统并行运行，降低业务中断风险；原因三是基础设施已通过金融行业大规模验证，比较稳定。

　　二

　　针对“信创分布式数据库+虚拟化+专业SAN存储”架构，若实际情况需要一次性全栈替换，如何将风险降到最低？

　　同行建议采用“并行运行、灰度切换”的过渡方案。

　　第一阶段：并行运行：在完成预生产验证后，将新全栈系统（信创数据库+虚拟化+SAN）正式部署上线，与旧系统（Oracle+VMware+集中式存储）并行运行。

　　第二阶段：将生产流量复制一份（或使用特定时间段的日志）导入新系统。对比新旧两套系统的处理结果（如数据库账务结果），确保100%一致。此阶段可充分暴露只有在真实流量下才会出现的问题。

　　第三阶段：确认无误后，开始灰度切换。先选择非核心业务（如某个信贷产品的查询功能、或某个分行的部分业务）切换到新系统。稳定运行一段时间（如一个业务周期或一个月）。

　　第四阶段：核心业务切换，制定极其详尽的秒级回滚预案。确保旧系统全程待机，数据通过同步工具（如Oracle GoldenGate或其他数据同步工具）保持准实时同步。一旦新系统在切换后任何时间点出现不可预见的严重问题，立即执行回滚方案，切回旧系统，保障业务连续性。

　　首先做好各类基础软硬件产品的选型，选择市面上成熟且使用案例较多的产品。包括信创服务器、云平台、虚拟化、操作系统、数据库、中间件等。应用系统改造，选择一家业内案例多，且公司知名度较大的公司。替换的过程中，提前做好规划，考虑周全，做好测试验证。

　　制订应急与回退机制。一是“分级回滚策略”比如数据库层：保留旧库完整备份，通过动态路由配置（如Nacos）快速切换回旧库；虚拟化层：预留VMware临时集群，支持虚拟机回滚；存储层：配置快照回滚（每小时一次）和异步复制容灾。二是7×24小时监控：部署全链路监控工具，实时检测虚拟化损耗、存储IOPS等指标，设置阈值告警（如延迟>100ms触发）。

　　如果要求一次性全栈替换，按组件替换，可能会涉及多次验证测试及兼容性问题，增加替换的复杂度。可以考虑按业务功能拆分后，实现微服务化的同时，逐步替换。如果是能拆分业务逐步迁移最好，传统“Oracle+VMware+集中式存储”架构信创分布式数据库虚拟化资源池架构并行，运行下来没问题则传统架构下线。如果不能，则选择并行期观察稳定再进行单轨切换，并保留回退逃生环境。

　　三

　　若采用“数据库+存储优先”策略，如何规避其与尚未替换的VMware虚拟化/x86服务器之间的兼容性问题？

　　从目前的信创改造经验来看，主流品牌的信创数据库基本都有提供部署在x86服务器上的版本。至于VMware 虚拟化，只要它提供的虚拟机能够支持安装部署信创数据库所需要的操作系统，也基本是可行的。

　　为有效识别与规避兼容性问题，建议构建与生产环境拓扑一致的仿真过渡环境。执行重点验证：

　　1.I/O路径兼容性：在VMware中为信创数据库虚拟机配置多路径策略，测试其对后端新SAN存储的识别、故障切换和负载均衡能力。

　　2.性能基线比对：使用相同负载，对比新（信创数据库+新SAN）旧（Oracle+旧存储）两套栈的关键指标（如TPS、读写延迟、IOPS吞吐）。特别关注虚拟化层引入的性能开销是否在可接受范围内。

　　采用分阶段、逐步验证的策略能有效规避兼容性问题：

　　一是非核心业务试点，首先在开发测试环境，或选择个别非核心业务系统进行试点迁移，验证技术栈的兼容性和稳定性。

　　二是并行运行与灰度发布，在条件允许的情况下，让新旧系统并行运行一段时间。逐步将部分读流量或特定业务模块切换到新系统，即采用灰度发布模式。

　　三是全面评估与最终切换，在试点和并行阶段全面评估性能、稳定性及运维流程，充分磨合后再择机进行最终切换。

　　有同行分享：在业务系统不具备全栈替换的情况下，可以选择先替换数据库和存储，后续迭代不再担忧数据迁移问题；专业存储向下兼容性强，支持对接旧虚拟化和服务器；数据库故障域独立，能够避免因虚拟化或服务器层面变更引发的连锁风险。

　　四

　　同行共识总结

　　在银行信贷等混合负载重要系统信创改造中“信创分布式数据库+虚拟化+专业SAN存储架构”技术堆栈替换路径、如何降低风险及确保各层兼容性，专家探讨为此提供了参考。

　　1.技术堆栈替换路径：一次性全栈替换为同行主流选择

　　在银行信贷类重要系统信创改造中，为平衡业务连续性与替换风险，50%的用户倾向选择一次性全栈替换技术堆栈。原因在于服务器、存储、虚拟化、数据库均属基础设施，分次替换需多次变更，时间长、操作风险高且兼容性风险未必降低；而一次性全栈替换可统筹软硬件考量，规避局部表现好但整体不可控及二次适配问题，能提升兼容性并将业务连续性风险集中处理，降低多次变更带来的风险。

　　2.如何降低风险：并行运行、灰度切换的过渡方案

　　并行运行阶段，新全栈系统与旧系统同时上线，完成预生产验证后正式部署，确保双系统并行运作。流量复制对比阶段，将生产流量或日志导入新系统，对比新旧系统处理结果，确保100%一致性，暴露潜在问题。灰度切换阶段，选择非核心业务（如特定信贷产品或分行部分业务）切换到新系统，稳定运行一个周期或一个月。核心业务切换阶段，制定秒级回滚预案，旧系统全程待机并通过同步工具保持准实时数据同步，保障业务连续性。回滚保障机制，一旦新系统出现问题，立即切回旧系统，确保业务不受影响。

　　3.确保各层兼容性：分阶段、逐步验证的策略较为稳妥

　　非核心业务试点迁移首先在开发测试环境或个别非核心系统（如历史数据查询、OA系统）进行，验证技术栈的兼容性与稳定性。并行运行与灰度发布通过新旧系统并行运行，逐步切换部分流量或特定模块到新系统，降低切换风险。全面评估与最终切换在试点和并行阶段全面评估性能、稳定性及运维流程，确保充分磨合后择机完成信贷系统的最终切换。

　　 本期课题核心协作参与用户 

　　研讨贡献者（积极参与研讨、分享实践心得）：

　　朱正珊 某银行 数据库架构师

　　赵子翊 某城商行 技术经理

　　闫俊洋 某城商行 系统工程师

　　杨磊 某证券 数据库架构师

　　郭惠斌 某银行 技术经理

　　王博 某城商行 系统架构师

　　郑伟 某金融机构 系统架构师

　　罗巧兰 某农商行 系统工程师

　　李小鹏 某银行 项目经理

　　陈超 某农信 系统工程师

　　共识文章主笔人（组稿、撰写共识文章）：

　　王博 某城商行 系统工程师

　　关键问题贡献者（提出关键问题、开启探索）：

　　slj18560622862、jumpp、Dongxin、jillme

　　共识议题审核专家（审核共识议题，把控专业与质量）：

　　gjjs2、slj18560622862

　　共识共建参与者（参与投票、共塑共识决议）：

　　koolkite、tozf、lql2000、zzy3620、yjytianti、lmspring、liaobin429、lxpeng163、hnnx123456789、cornea、daocaoren0352、bankhp、lvzhilin2013、xqhqq011、wjf102、yuanly、myy10146、henry8898、xjwangbo100、smtpclient、menglunyang、chiyang、风语ch、mornsky、JasonChang、slj18560622862、actor168、Mr_yyy、anikikong

　　参与投票共识来自的企业单位：

　　海峡银行、杭州联合银行、广州农商行、广西北部湾银行、中原银行、兰州银行、北京农商银行、邮储银行、甘肃农信、辽宁振兴银行、安徽省农村信用联社、龙江银行、江西银行、山西银行、重庆三峡银行、广东华兴银行、吉林银行、哈密市商业银行、中国银行、浙江泰隆商业银行、湖南银行、自贡市商业银行、浙商银行、民生银行、福建海峡银行、北部湾银行、中信建投证券、申万宏源证券、国泰君安证券

　　致谢如上社区专家：在AI+行业浪潮中，企业IT人正站在时代的前沿。正是这样一群应用创新者，勇于探索“无人区”，用智慧与经验为行业标注前行的坐标，凝聚产业共识。你们是AI+落地实践中当之无愧的中流砥柱与引领者。在共识共建的历程中，你们展现出一种现代“骑士精神”——乐于分享、勇于攀登，以开放之心传递知识，以坚韧之志应对挑战，将点点星火汇聚成照亮未来的灯塔。征程已在脚下，未来因你们的卓越贡献而更加清晰。在此，我们向每一位贡献者致以最诚挚的敬意与感谢！我们诚挚期望更多有识之士加入企业IT应用趋势项目创新联盟和课题组，与同行携手，共同推动AI+行业应用落地与创新！

　　···

　　感谢华为存储在社区联盟“数据治理与幻觉控制"课题方向下，对子课题《金融重要系统“分布式数据库+虚拟化+专业SAN存储"存算分离架构战略必要性与可行性研究》的支持。