随着医疗行业信创建设持续深入，医院信息化正在从“外围系统国产化”进一步进入“核心生产业务国产化”阶段。

过去，医院往往优先从办公、门户、测试开发等外围系统开展信创建设，通过国产服务器、操作系统和基础软件完成基础替代。但对于三级甲等医院而言，真正决定信创建设能否走向纵深的，并不是外围业务是否能够运行，而是 HIS、EMR、LIS、PACS、医疗集成平台等核心系统，能否在国产基础设施上长期、稳定、高性能运行。

这些系统直接支撑挂号收费、门诊诊疗、住院、检验、影像、电子病历和临床协同，一旦基础设施出现性能下降、资源异常或业务中断，影响的不只是某个信息系统，而可能直接影响医院正常诊疗秩序。

因此，三甲医院核心业务信创建设关注的问题已经从：

“国产平台能不能运行？”

进一步转变为：

“核心业务敢不敢上、性能能不能扛住、故障能不能兜住、原有平台能不能平滑替代，以及信创改造以后业务连续性会不会降低。”

 

一、三甲医院核心业务信创面临的五大核心挑战

 

1. 核心医疗业务不能只“能跑”，还要长期稳定运行

医院核心业务具有明显的 7×24 小时连续运行特征。

HIS、EMR、LIS、PACS 等系统直接支撑门诊、住院、检验、影像和临床诊疗流程。在业务高峰期，大量并发访问、数据库读写、影像调阅以及系统间数据交换同时发生，对底层计算、网络和存储形成持续压力。

因此，医院关注的并不是平台能否完成安装、启动和基础兼容，而是：

在长期生产运行、业务高峰和异常状态下，平台是否依然能够保持稳定。

 

2. 国产计算平台性能必须满足医院高并发业务需求

国产 CPU 在核心数量、NUMA 架构、调度方式以及 IO 特性等方面，与传统 X86 环境存在差异。

如果虚拟化平台只是简单完成硬件兼容，而没有针对计算调度、内存访问、网络和存储数据路径进行优化，就可能出现应用响应时间增加、数据库吞吐下降、存储时延波动、业务高峰卡顿等问题。

对于三甲医院而言，信创平台不能只达到“性能可接受”，而是需要确保：

核心业务迁移以后，不因为国产化造成明显性能退化。

 

3. 医疗信创是全栈工程，不是单点设备替换

医院 IT 环境涉及国产 CPU、操作系统、数据库、中间件、容器平台以及大量医疗应用。

任何一层兼容不足，都可能影响整体生产运行。因此，医院真正需要验证的是一条完整业务链路：

硬件 → 虚拟化 → 操作系统 → 数据库 → 中间件 → 医疗应用。

只有当整套技术栈在真实负载、资源竞争和异常场景下都能够保持稳定，信创平台才真正具备进入核心生产环境的基础。

 

4. VMware、Hyper-V 等原有平台必须平滑替代

不少大型三甲医院已经使用 VMware、Hyper-V 等虚拟化平台多年，并形成成熟的业务架构和运维体系。

因此，医院很难接受“重新建设平台，再把所有应用重新安装一遍”的改造方式。

更加现实的要求是：

底层基础设施可以变化，上层业务尽量不变。

这要求新的信创平台具备完善的迁移、网络延续和回退能力，把核心业务切换窗口和迁移风险降到最低。

 

5. 信创改造不能降低原有业务连续性标准

很多医院在信创建设之前已经建立 HA、备份、双活和容灾体系。

因此，信创不能意味着：

“为了国产化，重新接受更低的可靠性。”

尤其是已经采用跨机房双活、异地容灾的医院，新平台不仅需要完成虚拟化替代，还必须继续满足医院原有的 RPO、RTO 和业务连续性要求。

 

二、深信服信创超融合：面向医疗核心业务打造生产级信创底座

 

2.1 从风险预防到双活容灾，构建医疗核心业务完整可靠性体系

对于三级甲等医院而言，高可靠并不是简单增加一个 HA 功能，而是需要贯穿业务运行全过程。

真实数据中心中，很多故障不会立即表现为服务器彻底宕机，而是首先进入亚健康状态，例如网络时延持续增加、间歇性丢包、磁盘卡慢、内存异常、主机负载过高或者存储 IO 持续抖动。如果不能提前识别，这些异常最终可能表现为 HIS 卡顿、数据库响应升高、影像调阅缓慢甚至业务中断。

深信服围绕医疗核心业务构建覆盖 “风险预防—异常识别—故障自愈—数据保护—业务连续” 的完整可靠性体系。通过硬件亚健康检测、故障预测、HA、DRS 等能力持续感知计算、网络、存储和硬件运行状态，在故障真正影响业务之前进行风险隔离、资源调整或业务迁移，使可靠性从传统的“故障后恢复”进一步走向“故障前发现和主动处置”。

在数据层面，通过分布式存储多副本、备份、CDP 等机制降低单节点、单磁盘故障带来的数据风险；对于更高等级的医疗核心业务，还可以进一步通过延展集群、同城双活和异地容灾构建跨数据中心业务连续性体系。

针对不同重要程度的业务，可按照实际要求配置不同 RPO、RTO，从本地主机和集群高可用，一直延伸至双活、异地灾备，并逐步将保护对象从虚拟机扩展到数据库、应用及容器环境。

这样，即使底层硬件完成信创替换，医院原有业务连续性标准仍然可以得到延续：

核心业务上信创，可靠性不能下降；基础设施发生故障，业务影响要尽可能小。

 

2.2 针对国产平台深度优化，让核心医疗业务获得生产级性能

医疗核心业务对性能具有明显的复合型特征。

HIS、EMR、集成平台和数据库具有高并发、小 IO、高频交互特点；PACS、影像和数据交换场景又对顺序吞吐和网络带宽提出较高要求。

因此，单纯完成国产 CPU 适配，并不足以满足三级甲等医院的生产要求。

深信服基于多年虚拟化和超融合生产环境经验，针对国产 CPU 多核、多 NUMA 等架构特点，从虚拟化内核、CPU 调度、NUMA、网络和存储 IO 等关键路径持续优化。

计算层通过 CPU 调度和 NUMA 优化，使虚拟 CPU、内存尽可能保持本地访问，减少跨 NUMA 调度带来的性能损耗；网络层通过虚拟网络数据路径优化降低转发开销，为应用、中间件和数据库之间的大量东西向流量提供稳定支撑；存储层则围绕数据库随机 IO、PACS 大吞吐和医疗混合负载优化 IO 调度与数据路径，降低高并发场景中的时延和性能波动。

目前，深信服信创超融合虚拟化 CPU 性能转化率超过 90%，单核最高可达 97%以上。数据库场景中，达梦 400 并发测试 tpmC 达到 36.9 万，人大金仓 1000 仓测试达到 153 万 tpmC；在鲲鹏 920 平台上，4K 随机读性能达到 138 万 IOPS。

性能优化最终不是为了获得单一实验室指标，而是要转换成真实业务体验：

门诊高峰 HIS 不出现明显卡顿，EMR 和集成平台在大量并发调用下保持稳定，数据库国产化以后仍具备足够吞吐能力，PACS 大规模影像访问不会形成新的基础设施瓶颈。

 

2.3 双栈一致 + 全栈生态兼容，让复杂医疗信创环境真正落地

医疗信创并不存在唯一的技术路线。

不同医院可能根据既有应用、数据库认证和采购规划选择 C86、ARM 等不同国产计算架构，上层又涉及多种国产操作系统、数据库、中间件、备份软件、容器平台以及 HIS、EMR、LIS、PACS 等医疗应用。

如果每一种硬件路线都单独建设一套虚拟化和管理平台，很容易在完成信创以后重新形成资源孤岛。

深信服通过双栈一致架构，以统一的软件定义数据中心技术体系，以及硬件适配层、操作系统抽象层等机制屏蔽底层差异，实现 X86、C86、ARM 等多架构平台在计算、存储、网络、安全和运维体验上的一致性。

医院可以根据应用适配情况选择不同国产计算路线，而无需为不同 CPU 重新建设不同的资源管理和运维体系，从而实现多技术路线统一承载和持续演进。

但医疗信创的复杂性并不只来自硬件。

一套核心医疗系统背后往往同时涉及服务器、操作系统、数据库、中间件、备份软件和应用厂商。传统“兼容认证”更多只能回答“能不能安装、能不能启动”，而医疗核心业务真正关心的是：

高负载能不能稳定运行，资源竞争会不会出现异常，网络和存储波动时业务是否稳定，节点发生故障以后应用能不能继续运行。

为此，深信服持续构建覆盖国产服务器、操作系统、数据库、中间件、备份软件及行业应用的全栈生态。目前已适配 100+ 国产服务器平台、200+ 国产操作系统版本，联合生态伙伴完成 100+ 国产数据库及行业核心应用适配，并与爱数、英方、鼎甲等国内主流备份厂商完成无代理兼容适配，与卫宁、东华等医疗生态伙伴形成持续实践。

同时，通过压力测试、混沌工程和故障模拟等方式，对资源竞争、节点异常、网络波动、存储异常和数据库高负载等情况进行验证，使信创生态从简单的：

“可安装、可运行”

进一步走向：

“可迁移、可运行、可稳定”。

 

2.4 平滑替代 VMware、Hyper-V，让信创改造从“大迁移”变成“平滑演进”

医院核心业务往往已经运行多年。

HIS、EMR、LIS、PACS 与数据库、中间件、网络、安全系统之间已经形成大量接口和依赖关系。如果信创改造要求所有业务重新安装、重新配置甚至重新调整网络，不仅项目周期长，核心业务迁移风险也会显著增加。

因此，深信服在医疗信创改造中强调：

底层基础设施替换，上层业务尽可能少改。

通过虚拟机纳管、在线迁移、无代理及有代理迁移等多种能力，可以将 VMware、Hyper-V 等平台上的业务逐步迁移至国产环境；对于大规模改造项目，可通过集中纳管、批量迁移和自动化任务提升迁移效率。

同时结合 SDN 等技术延续原有网络关系，使迁移后的业务尽可能保持原有 IP 和访问方式，降低 HIS、LIS 等系统重新配置接口和网络策略的工作量。

对于核心业务迁移，更重要的不是单纯追求迁移速度，而是形成：

迁移前可评估、迁移中少中断、切换过程可控制、异常情况下可回退

的完整迁移机制。

这样，医院无需一次性将所有业务整体切换，可以按照外围业务、一般生产业务、核心业务逐步推进，在每一阶段完成充分验证后再扩大信创范围。

信创替代也由此从一次高风险的基础设施“大迁移”，转变为一个 分阶段、可验证、可回退的平滑演进过程。

 

三、四家三甲医院实践：核心医疗业务信创已经进入真实生产环境

 

3.1 河南科技大学第一附属医院：86 个信创应用，以严苛测试和长期运行验证核心承载能力

河南科技大学第一附属医院是大型三级甲等综合医院，医疗信息化体系覆盖门诊、住院、电子病历、医技和数据交换等大量关键场景。

此次信创建设并没有从办公、测试等外围系统开始，而是直接面向核心生产环境，将 HIS、EMR、病理、输血、康复、数据中心、集成平台等五大类业务逐步迁移至信创环境。

平台于 2024 年 4 月正式上线，目前已经稳定承载 86 个信创应用系统。

医院没有把“通过兼容认证”作为核心业务上线的充分条件，而是通过性能压力、真实业务和复杂故障场景进行多重验证。

单虚拟机、单数据盘场景下，4K 随机读达到 244,128 IOPS，平均时延约 0.52ms；4K 随机写达到 124,091 IOPS，平均时延约 1.03ms。进一步增加到多虚拟机、多数据盘并行压力后，256K 和 1024K 顺序读吞吐量分别达到 26,480 MiB/s 和 26,565 MiB/s。

医院还选取 iHO ESB 2.0、电子病历、临床专科应用等真实业务，与原有 X86 虚拟化环境进行对比，通过近 30 天实际运行数据验证信创平台的业务性能。

可靠性方面，除主机、网络、存储、磁盘等故障测试外，医院还通过混沌工程模拟网络时延、网络丢包、磁盘卡慢和内存异常等亚健康状态，验证平台对潜在风险的提前发现、隔离和调度能力。

上线以来，平台已经经历多次节前、节后门诊和住院业务高峰，在高并发访问和大量数据交互过程中，没有因平台性能问题影响医院正常诊疗。

从压力测试、真实医疗业务对比、复杂故障模拟，到业务高峰和长期生产运行，该项目形成了一条完整的核心业务信创验证链路。

 

3.2 江苏省中医院：平滑替代 VMware vSAN 双活，核心业务连续性不降级

江苏省中医院原有 HIS、LIS、PACS、EMR、医疗集成平台等核心系统已经形成成熟的信息化架构，并长期运行于 VMware 虚拟化和 vSAN 延伸集群双活环境之上。

因此，本次信创建设面对的并不是简单的“VMware 能不能换”，而是：

原有 VMware vSAN 延伸集群具备的生产级双活能力，国产平台能不能完整接住。

深信服采用信创超融合延展集群，对原 VMware vSAN 双活体系进行平滑替代。两个机房共同参与业务承载，并通过 SDN 实现跨机房二层网络互通，使虚拟机跨中心漂移或故障恢复以后仍能够保持原有业务 IP，减少 HIS、LIS 等系统因为基础设施变化产生的网络改造。

双活架构可实现 RPO=0、分钟级 RTO，继续满足医院核心业务 7×24 小时连续运行要求。

与此同时，医院的全栈信创改造还涉及 OceanBase、海量数据、华为高斯、达梦、人大金仓等多种数据库。项目采用分阶段方式推进数据库国产化，先进行实时同步和部分只读业务验证，再逐步扩大生产使用范围。

平台还进一步对 HIS、EMR、PACS、医疗集成平台等数据库进行统一管理，并提供 SQL 卡慢分析、锁阻塞发现和会话快速释放等能力，使信创改造从底层平台替代进一步延伸至运维能力升级。

目前平台已经稳定承载 HIS、LIS、PACS、EMR、医疗集成平台、手麻、科研及管理等多类业务，并稳定运行 2 年。

江苏省中医院的实践说明，医疗 VMware 替代已经可以从单纯的虚拟机迁移进一步升级为：

双活能力平滑替代、全栈信创适配和核心生产业务长期承载。

 

3.3 上海某大型三甲医院：700 万+年门诊量下完成 Hyper-V 平滑替代，真实故障业务无感

上海某大型三甲医院实际开放床位超过 2000 张，年门诊量超过 700 万人次，HIS、EMR、LIS、PACS 等系统长期支撑高频、连续的门诊、住院、检验、影像和临床业务。

医院原有核心业务长期运行于 Hyper-V 虚拟化平台。随着原平台逐渐老旧以及信创建设推进，需要进行国产化升级，但医院并不希望因此大规模调整上层应用和原有业务架构。

深信服基于信创超融合重新构建统一国产基础设施底座，重点承载 EMR、PACS、LIS 及相关核心数据库，同时部署 HIS 应用，使信创建设直接进入医院核心生产环境。

迁移过程中，通过虚拟机迁移能力将 Hyper-V 上的业务逐步迁移至信创平台，实际迁移速度达到约 300MB/s。迁移过程中尽量减少对上层应用系统的改造和影响，在提高迁移效率的同时降低核心生产业务的切换风险。

相比单纯实验室测试，这个项目还经历了一次更具代表性的生产验证。

在实际运行过程中曾发生服务器电源损坏，但在真实硬件故障情况下，医院业务端未受到影响，核心系统仍持续对外提供服务。相比模拟故障，这次真实生产事件更直接地验证了信创平台在异常情况下的高可用和业务连续性能力。

对于一家年门诊量超过 700 万人次的大型三甲医院而言，这一实践证明：

国产信创超融合已经能够进入高业务量核心医疗生产环境，并在传统虚拟化迁移和真实硬件故障场景下保障业务持续运行。

 

3.4 浙江省人民医院：核心业务全栈信创，并将业务连续性延伸至健康云异地容灾

浙江省人民医院在新院区建设过程中，需要同步完成基础设施云化和信创改造。

与一般从办公、测试等外围业务开始的建设方式不同，该项目面向全院业务信创化，范围从底层计算、存储、网络，一直延伸至操作系统、数据库、中间件以及上层医院应用。

同时，医院还需要依托浙江省健康云建设异地容灾，使核心业务完成信创改造以后仍然具备完善的业务连续性保障能力。

深信服为医院建设基于 C86 + ARM 的信创云平台，HIS、LIS、PACS、EMR 等关键业务统一运行于信创平台之上，并与国产操作系统、数据库、中间件形成完整适配，实现从基础设施到应用运行环境的全链路信创交付。

平台同时支持 C86、ARM 等多种国产计算技术路线，通过统一云平台管理，减少不同技术栈之间形成新的基础设施孤岛。

在业务连续性方面，项目进一步与浙江省健康云衔接，构建信创异地容灾体系。

异地保护范围不再局限于传统虚拟机，而是扩展至 K8S、应用系统和数据库，并根据不同业务的重要程度配置差异化 RPO、RTO，实现从本地基础设施高可用到异地业务级容灾的完整保护。

浙江省人民医院富阳院区由此形成了一条具有代表性的三级医院全信创上云路径：

核心医疗业务可以上信创，复杂医疗生态可以完成全栈适配，信创环境同样可以建立完善的高可用与异地容灾体系。

 

四、从“信创可用”走向“核心生产可用”

 

四家三级甲等医院的实践，从不同维度回答了医疗行业推进核心业务信创最关心的问题。

河南科技大学第一附属医院，通过性能压力、真实业务、混沌工程以及长期生产运行，验证了国产平台对核心医疗业务的持续承载能力。

江苏省中医院，通过信创超融合延展集群完成 VMware vSAN 双活体系平滑替代，证明医疗信创可以在国产化的同时继续保持原有业务连续性等级。

上海某大型三甲医院，在 700 万+年门诊量业务规模下完成 Hyper-V 平滑替代，并通过真实服务器硬件故障进一步验证平台高可用能力。

浙江省人民医院，则从基础设施进一步走向 C86 + ARM、操作系统、数据库、中间件、医疗应用以及异地容灾的一体化全栈信创建设。

这些实践共同说明：

三甲医院信创建设，正在从“合规可用”进入“核心生产可用”。

对于医疗行业而言，真正成熟的信创基础设施，并不是简单完成国产服务器、操作系统和数据库替换，而是要继续满足医院核心业务对于 高性能、高可靠、业务连续性、生态兼容和平滑演进 的要求。

深信服信创超融合围绕医疗核心生产场景，以生产级可靠性、国产平台性能优化、开放兼容和平滑迁移四大能力，帮助 HIS、EMR、LIS、PACS 等核心医疗业务从传统基础设施平稳进入信创环境。

信创的目标不只是“换成国产”，而是让核心医疗业务在国产基础设施上：

稳定运行、高效运行、长期运行。

关于深信服信创超融合

深信服超融合连续多年位居 IDC 中国超融合市场占有率第一，已服务超过 2.9 万家客户，协助 6000 余家客户推进信创建设与改造，其中包括 1000 余家金融客户、3000 余家央国企和1200余家医疗机构。依托长期生产实践、双栈一致架构及完善信创生态，深信服持续推动信创基础设施从“合规可用”向“核心生产可用”演进。