随着金融信创建设持续深入，银行基础设施国产化正在从办公、协同等外围场景，进一步进入存款、贷款、支付清算、手机银行、国际结算、交易、风险管理等关键业务领域。

银行业务具有强交易、高并发、7×24连续运行和严格业务连续性要求。与此同时，大量银行长期采用 VMware、集中式存储以及多代服务器构建基础设施，业务系统数量多、依赖关系复杂，既有运维体系也已经高度成熟。因此，银行信创建设并不是简单更换服务器或虚拟化软件，而是要在自主可控的同时继续回答几个更关键的问题：核心业务能否稳定承载、业务高峰性能能否保持、VMware能否平滑替代、多芯多架构能否统一演进，以及大规模资源池能否继续保持原有运维效率。

从浙商银行以及多家大型区域银行的实践来看，国产虚拟化与信创超融合已经开始从办公类系统逐步进入交易、支付、风险、大数据等重要业务领域，银行信创基础设施正在从“满足合规”走向“承载核心业务”。

 

一、银行核心业务信创面临的五类关键挑战

 

1、核心业务进入信创后，可靠性和业务连续性不能降级

银行生产系统对基础设施故障极为敏感。存款、贷款、手机银行、支付清算、跨境支付、风险报送等系统一旦中断，可能直接影响客户交易和银行日常运营。

真实数据中心中的风险又不只是服务器彻底宕机。RAID卡异常、磁盘卡慢、SSD寿命下降、网络时延和丢包、资源过载等亚健康问题，都可能在硬件完全失效之前先表现为业务卡顿和响应抖动。因此，银行需要的不只是故障后的HA，而是从异常发现、故障隔离、虚拟机恢复到数据保护和容灾切换的一整套可靠性体系。

同时，银行普遍采用应用双活、数据库主备、两地三中心等架构。基础设施国产化以后，新平台必须能够继续融入已有高可用体系，而不是让原来成熟的业务连续性能力重新降级。

 

2、国产化以后，性能需要经受真实交易和业务高峰

银行不同业务的负载差异明显。交易和支付系统关注低时延和持续响应，数据库关注随机I/O与事务处理能力，大数据和风控平台又会产生较大的计算和吞吐压力。

因此，信创平台不能只完成CPU、操作系统和虚拟化层面的兼容，也不能只通过某一项基准测试判断是否适合生产。CPU调度、NUMA、内存访问、存储I/O以及网络数据路径都需要围绕真实银行业务进行优化，并在高峰负载、资源竞争和故障场景下持续保持稳定。

 

3、X86、C86、ARM和多种软件生态将长期共存

银行信创改造通常无法一步到位。部分历史系统仍依赖原有X86环境、Windows、商业数据库和既有中间件；新建系统则逐步采用C86、ARM、国产操作系统、数据库和中间件。

不同业务系统的改造节奏并不一致，银行还会根据系统重要等级、应用认证情况和技术路线选择不同处理器架构。因此，未来较长一段时间内，多芯、多架构、国产与非国产资源并存将是常态。

平台需要在尊重不同架构技术边界的同时，为C86、ARM及存量X86环境提供统一管理和一致运维能力，使银行可以分阶段推进信创，而不是因为底层芯片变化重新形成新的基础设施孤岛。

 

4、VMware替代的难点，不只是把虚拟机搬过去

银行大量业务已经运行在VMware环境多年，资源申请、虚拟机交付、监控告警、运维脚本和日常操作都已经围绕原平台形成成熟流程。

因此，国产虚拟化替代需要同时解决两个问题：一是业务能否低风险迁移，二是迁移后运维体验是否明显退化。

除了虚拟机迁移本身，还需要处理网络、IP、应用接口、数据库一致性、反亲和策略、灾备布局和回退机制。对于拥有数百甚至数千台服务器、数千到数万台虚拟机的大型银行，只有把迁移流程、自动化交付和监控体系一起接住，替代才真正具备规模化条件。

 

5、多数据中心、大规模资源池需要继续保持自动化运维效率

大型银行往往同时建设生产、灾备、DMZ、运维和开发等多个资源区域，并分布在多个数据中心。随着信创资源池逐步扩大，单纯依赖人工配置和分散管理很难支撑大规模投产。

新平台需要具备多集群统一纳管、自动化资源发放、批量配置、镜像管理、监控告警以及开放API能力，并能够与银行现有资源管理、CMDB和监控体系衔接。

对银行而言，信创平台不仅要“替得掉”，还要做到规模上得去、运维接得住、业务投产效率不下降。

 

二、深信服信创超融合：面向银行核心业务承载的五项核心能力

 

1、高可靠：从亚健康识别到故障恢复，构建生产级可靠性体系

深信服信创超融合面向银行核心生产业务构建覆盖风险识别、故障隔离、业务恢复、数据保护和业务连续性的可靠性体系。

在故障发生之前，平台可以从主机、网络、磁盘和存储等多个维度持续感知运行状态，对主机假死、RAID卡异常、磁盘卡慢、SSD寿命下降、网络时延和丢包等亚健康问题进行识别和预警，尽量避免底层异常持续放大并最终传导到上层业务。

当硬件真正发生故障时，HA、资源预留、虚拟机优先级、反亲和/互斥调度以及分布式存储多副本等能力共同承担业务恢复职责。对于数据库主备、应用集群等关键业务，可以通过调度策略将不同成员分散到不同物理节点或集群，降低单点故障同时影响多个业务副本的风险。

银行高可用通常还需要与应用双活、数据库主备和两地三中心体系结合。深信服平台可以作为底层资源承载和恢复基础，通过备份、CDP以及容灾能力进一步构建数据保护体系，使虚拟化平台高可用与应用、数据库自身的业务连续性机制相互配合。

真正的高可靠并不是“虚拟机能重新启动”，而是单点故障可隔离、关键业务有接管资源、数据有保护、业务能够持续恢复。

 

2、生产级性能：围绕交易、数据库和大数据负载进行深度优化

银行核心业务对性能的要求并不统一。交易、支付和客户服务系统关注响应时间，数据库关注事务吞吐和随机I/O，大数据及风险管理业务则更加关注计算能力和持续吞吐。

深信服基于多年虚拟化和超融合生产实践，围绕国产CPU多核、多NUMA特性，对CPU调度、NUMA亲和、内存访问、网络数据路径和存储I/O进行持续优化，使不同负载在虚拟化环境中获得更稳定的资源供给。

对于数据库等性能敏感业务，可以结合NUMA优化、大页内存、重要虚拟机调度和高性能存储策略，降低跨NUMA访问以及资源争用带来的抖动。存储侧可根据业务特征选择全闪、混闪或存算分离模式，兼顾低时延、大吞吐和容量需求。

银行业务还存在集中投产、营销活动、交易高峰等明显峰谷变化。平台需要在资源规划阶段保留合理冗余，并支持受控弹性扩展和动态调度，使性能能力不仅体现在单次测试数据上，更能够转化为高峰交易稳定、数据库响应可控、关键业务长期运行不抖动。

 

3、开放兼容：双栈一致、一云多芯，支撑银行分阶段国产化

银行信创建设往往同时存在X86、C86和ARM路线。深信服通过双栈一致架构和多芯支持，为不同处理器架构提供统一的虚拟化、资源管理和运维体系，使银行能够根据业务重要等级、应用适配情况和建设阶段选择不同技术路线。

对于兼容条件成熟的业务，可以优先在C86等环境中完成基础设施替换，尽量保留原有操作系统和应用运行方式；对于ARM等路线，则结合操作系统、数据库、中间件和应用版本进行全栈适配。不同资源池可统一纳管，减少多架构并存形成新的管理孤岛。

在上层生态方面，平台需要同时面对银行既有Windows/Linux环境、商业数据库和中间件，也要持续适配国产操作系统、数据库、中间件以及容器、大数据等新技术栈。

因此，开放兼容并不是简单“支持某种CPU”或者“拿到兼容认证”，而是明确不同技术路线的适用边界，并通过真实业务、压力负载和长期运行验证，把兼容能力真正转化成可迁移、可运行、可持续演进。

 

4、平滑迁移与替代：尽量保持VM一致性，降低VMware替换成本

银行VMware替代的关键，是在底层平台变化的同时尽量保持上层业务和运维方式稳定。

深信服通过虚拟机纳管、迁移工具和多种迁移方式，支持银行按照业务重要程度分批推进存量虚拟机迁移。在正式切换之前，可先完成兼容性检查、业务依赖梳理、性能基线采集和非关键业务验证；验证通过后再逐步进入重要和核心业务。

对于银行已有的反亲和、虚拟机优先级、资源预留等策略，国产平台需要尽可能提供一致的核心能力，降低架构迁移后重新设计高可用逻辑的成本。同时，迁移过程应明确源端停写、增量同步、目标启动、业务验收和回退条件，尤其需要保证数据库和关键交易系统的数据一致性。

这种方式让VMware替代从一次高风险“大割接”，逐步转化为分阶段迁移、双轨并行、业务可验证、异常可回退的演进过程。

 

5、大规模运维：开放API与统一云管支撑多中心自动化运营

银行信创规模扩大以后，运维能力必须同步升级。

深信服SCP提供多数据中心、多集群和异构资源统一管理，并通过开放API与银行既有资源管理、监控告警、CMDB等平台进行集成。资源申请、审批、创建、配置、回收等流程可以继续纳入银行原有IT管理体系，而不是建设一套孤立的“信创运维平台”。

在资源交付层面，平台支持虚拟机批量创建、批量配置、启停管理和操作系统初始化，也可对物理服务器的虚拟化平台部署进行自动化处理，满足银行集中投产和快速扩容需求。

在监控层面，可对宿主机、虚拟机、网络和存储等关键指标统一采集，并通过标准化接口推送至银行既有告警体系。镜像、资源和多集群统一管理，则进一步降低不同数据中心重复运维的工作量。

对于大型银行而言，国产虚拟化真正规模化的标志，不只是平台能够承载业务，而是数千台虚拟机、多个数据中心和不同芯片资源仍然可以按照原有生产节奏持续交付和运营。

 

三、四项典型银行实践

 

1、浙商银行：6000+虚拟机稳定承载，大规模国产虚拟化进入一类核心业务

浙商银行是十二家全国性股份制商业银行之一。随着VMware政策变化和金融信创持续推进，浙商银行逐步建设国产虚拟化平台，既承接新上线信创业务，也面向原有大规模VMware环境持续推进替代。

截至2026年8月，深信服虚拟化平台已累计上线590+台服务器，覆盖生产、互联网DMZ、外联DMZ、运维管理和开发测试等环境，资源分布于杭州、上海等多个数据中心，当前合计承载6000+台虚拟机实例。

更重要的是，国产虚拟化已经不再只承载外围系统。当前平台已上线大量银行生产业务，其中一类业务系统40+个，包括存款、贷款、手机银行、国际结算和贵金属交易等；二类业务系统50+个，包括跨境支付交易、银保通等；三类业务系统90+个，包括征信查询、移动云支付等。

从具体业务来看，平台已经承载存款中心、贷款中心、个人网银、企业网银、手机银行后台、国际结算、境内外币支付清算、三方存管、数字人民币、银联前置、网联支付清算、贵金属自营交易、新核心分布式技术平台及新核心实时数据服务等多类关键系统。这意味着国产虚拟化已经从满足信创合规，真正进入银行交易、支付、渠道和核心技术平台等重要生产场景。

在大规模运维方面，SCP通过API与行内资源管理系统衔接，实现资源申请、自动创建、批量管理和操作系统初始化，并与既有监控告警体系打通。在集中投产场景下，平台能够支撑每小时不少于100台虚拟机的批量发放需求，使国产虚拟化在扩大业务承载范围的同时，继续保持银行原有大规模自动化运维节奏。

浙商银行的实践说明：国产虚拟化不仅可以替代VMware基础能力，还可以在数千虚拟机规模下稳定承载一类核心业务，并融入银行已有自动化运维体系。

 

2、某大型农村商业银行：100+C信创虚拟化构建两地三中心，承载核心交易、客户服务与风险管理

某大型农村商业银行拥有300+业务系统，原有基础设施长期采用VMware、集中式存储和物理机等多种技术栈。随着信创建设深入，银行并没有采用一次性整体替换方式，而是先从低风险业务开始，再逐步进入关键交易类和核心业务系统。

当前信创虚拟化采用两地三中心整体架构，通过C86和ARM多技术路线构建异构资源底座，整体信创虚拟化建设规模达到100+C。平台按照不同业务等级选择相应计算架构，并通过多集群方式承载不同类型业务。

业务承载已经从办公管理逐步进入核心交易、客户服务和风险管理等关键领域。在信创改造加速阶段，围绕30个关键交易类业务系统推进国产虚拟化承载，并结合银行后续核心系统改造持续扩展资源能力。

整体架构坚持“一云多芯、双轨并行”。银行根据系统业务等级规划不同CPU路线，并保留异构国产虚拟化技术栈作为技术储备。应用层则以双活设计为主，虚拟机主要承载无状态应用，数据库根据业务架构独立部署，使应用自身高可用与底层虚拟化可靠性相互配合。

对于银行而言，这种建设方式的价值不只是增加一套信创资源池，而是通过两地三中心、多芯并行和分阶段改造，将国产虚拟化逐步推进到关键交易业务，同时保持既有灾备和高可用体系的连续性。

 

3、西北某城商行：从办公协同走向生产业务，双栈信创云承载反洗钱、跨境管理与ESB

西北某城商行在信创建设初期采用C86+ARM双栈路线构建国产化云平台，并按照“控制增量、消耗存量、应替尽替、真替真用”的思路逐步扩大业务承载范围。

平台首先承载办公系统、邮件系统、即时消息协作系统和电子签章等基础应用，同时逐步进入更重要的金融业务领域，包括反洗钱系统、金融跨境管理系统以及ESB企业数据总线系统。随着平台持续扩展，大数据系统、数据脱敏系统、智能柜员机管理系统和客户风险报送系统等生产业务也逐步进入信创环境。

相比单纯增加国产服务器，该银行更加关注长期生产可靠性。信创改造过程中曾暴露出RAID卡固件、磁盘健康、网络亚健康和老版本升级等软硬件问题，因此平台进一步强化RAID卡异常监测、HDD坏道预测与隔离、SSD寿命预测、网络亚健康识别以及原地热升级等能力，通过软件定义可靠性提升国产硬件环境下的持续运行能力。

这一路径体现了银行信创建设的一个典型演进方式：先从办公和协同系统建立双栈能力，再逐步进入反洗钱、跨境管理、ESB、大数据和风险报送等重要生产系统，以真实业务运行持续验证信创平台。

 

4、东部某城商行：双栈资源池统一承载客户风险报送、大数据灾备与智能柜员机业务

东部某城商行在推进办公系统全栈国产化的同时，需要进一步完成多个生产及灾备业务的信创改造，并解决不同CPU路线、多个资源池分散管理的问题。

平台采用C86与ARM双栈架构，根据业务类型划分办公、生产、灾备和管理等资源池，并通过统一管理平台进行集中纳管。

在业务承载上，办公资源池承担OA、邮件和即时消息协作等系统；生产资源池重点承载客户风险报送业务，并运行国产中间件及达梦主备数据库；ARM灾备资源池则承载大数据灾备、数据脱敏和智能柜员机管理系统。不同业务根据应用适配和灾备要求选择相应技术路线，而不是为了统一架构强行采用单一CPU平台。

通过双栈资源池和统一管理，银行既能够推进服务器、操作系统、数据库和中间件的全栈国产化，又可以保留不同业务之间的架构差异。大数据灾备、数据脱敏、智能柜员机和客户风险报送等系统进入信创环境，也表明国产基础设施正在从办公场景逐步进入数据、风险和渠道管理等更重要的生产业务。

该实践证明，银行一云多芯的核心价值并不是简单同时部署两种CPU，而是按照业务适配结果选择技术路线，并最终通过统一平台把不同资源池重新组织成可持续运营的信创基础设施。

 

四、行业总结

四项实践从不同角度展示了银行信创基础设施从外围业务向核心生产场景深入的过程。

浙商银行已经在6000+虚拟机规模下承载大量生产系统，其中包括40+个一类业务系统，存款、贷款、手机银行、国际结算、支付清算和交易类业务开始大规模运行在国产虚拟化平台上。

某大型农村商业银行以100+C信创虚拟化规模构建两地三中心资源底座，将国产虚拟化逐步推进至核心交易、客户服务和风险管理领域，并通过一云多芯和应用双活保持长期演进能力。

西北某城商行则从办公协同逐步进入反洗钱、金融跨境管理、ESB、大数据、数据脱敏和风险报送等重要系统，以真实业务运行推动国产平台可靠性持续完善。

东部某城商行通过C86与ARM双栈资源池，统一承载客户风险报送、大数据灾备、数据脱敏和智能柜员机等业务，验证了多芯异构环境下分阶段国产化的可行性。

这些实践共同说明：

银行信创正在从“外围系统国产化”进入“核心业务生产级承载”

对于银行而言，真正成熟的信创基础设施，不只是完成国产服务器和虚拟化软件替换，而是要继续满足金融业务对于高可靠、生产级性能、开放兼容、平滑迁移和大规模自动化运维的要求。

基础设施可以分阶段替换，CPU路线也可以按业务差异灵活选择，但最终验收标准应该始终回到业务本身：交易能否稳定、数据是否可靠、故障能否恢复、投产效率是否保持，以及平台能否持续承载更重要的银行业务。

关于深信服信创超融合

深信服超融合连续多年位居IDC中国超融合市场占有率第一，已服务超过2.9万家客户，协助6000余家客户推进信创建设与改造，其中覆盖1000余家金融客户。依托面向核心业务承载打造的生产级可靠性、高性能、开放兼容、平滑迁移和大规模运维能力，深信服信创超融合正持续支撑银行从外围业务信创向交易、支付、风险管理等关键生产场景深入演进。