某大型三级甲等综合医院在多院区运行格局下，以深信服超融合承载新一代 HIS 核心诊疗系统，并统一承载 PACS、EMR 等业务系统。建设过程把容灾、性能与云原生承载放进同一套架构设计，新系统先在灾备中心上线并与原系统并行运行，验证充分后再调整主备角色。核心诊疗系统的架构升级，难点往往不在新平台的性能指标，而在新老系统并行期怎么过。

一、HIS 停不得，底层却又必须动

HIS 贯穿挂号、收费、医生工作站、检查预约等诊疗环节，环节之间依赖紧密，患者集中就诊时系统响应直接影响诊疗效率；一旦中断，临床诊疗秩序会受到直接冲击。与此同时，电子病历应用水平分级评价五级、医院信息互联互通标准化成熟度四级，对核心业务的容灾备份指标提出了明确要求，信创改造要求也已明确。新一代 HIS 又在向云原生与微服务演进，对底层资源量、容器兼容性与调优提出新的要求，这类适配往往需要应用厂商与基础设施侧长期共同投入。多院区格局下，跨院区诊疗、检查结果共享与用药协同，对数据一致性和实时性要求严格。所以这类项目真正的难点，是在不能停的前提下完成底层更换。

二、项目背景

改造前，该院主数据中心长期采用国外虚拟化平台结合集中存储的建设模式，承载大量核心业务系统；部分 HIS 模块建设年份较早，与其他模块之间的耦合较紧，扩容时需要连带调整的范围较大。新一代 HIS 建设已经启动，新系统采用服务化架构、集中部署，对底层的并发承载提出了新的量级要求；底层技术路线上，C86 与 ARM 的选择在项目启动时尚无定论。运维侧的分工也影响了改造方式的选择：既有驻场力量按业务系统划分，分别对应数据库、HIS、PACS、LIS 等应用，基础设施层的日常调优与故障处置此前主要依赖各系统厂商各自响应。

三、方案设计

先并行，再换角色。 新一代 HIS 等核心业务系统先部署在双活灾备中心，与原有生产系统并行运行、持续验证；运行效果验证充分后，再逐步调整主备角色，把灾备中心演进为主业务承载环境。这条路径的意义在于，业务不需要先停下来等切换，验证不通过也随时可以退回原有环境。

双活落在四层，而不只是存储一层。 评级要求的容灾指标，靠单一层面的冗余撑不住，本项目把双活拆到四处分别实现：

·       存储层：两个数据中心同时进行数据存取，互为生产与备份，一个中心故障时业务自动切换到另一个。本项目实现 RPO=0、RTO≈0。

·       数据库层：Oracle RAC 跨站点部署，两个 RAC 节点分别位于生产中心与双活灾备中心，ASM 卷在两边存储做镜像绑定以保证读写一致；主中心故障不影响分中心节点运行，并可借平台 HA 自动重启原本运行在主中心的节点。深信服支持 11.2、12.1、12.2、19.15 四个版本的双节点 RAC。

·       应用层：在线交易通过负载均衡自动路由到不同数据中心的应用服务器，两个中心同时对外提供服务。

·       计算与网络层：两个中心通过服务器虚拟化构建统一资源池；每台超融合服务器以万兆光口卡分别连接两台万兆存储平面交换机，两台交换机再分别与对端中心互联，构成冗余存储网络。

硬件维护和扩容也不需要停业务。 借助虚拟机漂移可在线迁移 RAC 节点，避免硬件维护造成的应用中断；通过热添加可在线增加 RAC 节点虚拟机的 CPU 数量与内存容量，避免硬件扩容造成的中断。对一套全年无停机窗口的诊疗系统来说，这两项决定了日常维护能不能排进白天。

门诊高峰的时延靠数据路径优化。 依托 RDMA 网络加速与 SSD 缓存优化数据传输路径，本项目实测单业务查询延迟改善 5 毫秒，总延迟由 180 毫秒缩短至 110 毫秒。

同一平台同时承载虚拟机与容器。 新一代 HIS 的微服务组件可独立部署与弹性伸缩，由 Kubernetes 编排引擎管理微服务生命周期，支持灰度发布与无损升级，不必为容器另建一套资源池。

恢复目标的产品侧口径，方案阶段就能核。 深信服公开材料对各容灾形态给出的口径是：CDP 形态 RTO≤1 秒；同城双活形态要求两中心距离小于 50KM、万兆裸纤 RTT≤5 毫秒、三副本主 2 备 1、RPO=0，单机 HA 场景 RTO≤5 分钟；延伸集群下主机房异常时集群自动切换共享盘，RTO 小于 30 秒。虚拟机层面，捕获到虚拟机异常后 30 秒内完成拉起，主机侧故障探测覆盖管理网、存储网、Vxlan 网、业务网、终端通信网共 5 种网络的中断情形。这些口径带着各自的前提条件，方案评估阶段就能逐条对照现场条件核实，不必等到上线后才发现对不上。

四、用户价值

演进期间业务未中断。 新老系统并行运行至主备角色调整完成，核心诊疗系统全程持续对外提供服务。

容灾指标落到可核的口径上。 存储双活实现 RPO=0、RTO≈0，对应电子病历与互联互通评级对核心业务容灾备份的要求。

门诊高峰的响应更稳。 总延迟由 180 毫秒缩短至 110 毫秒，单业务查询延迟改善 5 毫秒。

资源与运维收敛到一套。 计算、存储、网络资源池化，虚拟机与容器统一管理，替代原先计算与存储分离的建设模式，减少多套异构系统并行维护带来的复杂性。

运维方式从被动转为主动。 从以故障响应为主，转向运行状态持续监测、风险提前识别与问题闭环处置。

五、本项目结论

本项目显示：新一代 HIS 的核心生产系统可以在双活承载与并行演进的架构下完成底层更换，且在新老系统并行期保持业务连续，对容灾目标、性能时延与云原生承载都有明确落点。

本项目留下三处需要持续管理的地方。一是并行期内两套环境同时在跑，监控、变更与备份都要维持两份口径，直到主备角色调整完成才收敛为一份。二是项目启动时底层芯片路线尚无结论，适配验证是在路线待定的前提下同步展开的，这决定了平台侧必须保持对多种路线的兼容，而不能按单一架构做深度优化。三是双活的效果与两个中心的物理条件直接绑定，本项目的链路条件满足同城双活的前提，但这一条不随方案复制。

六、案例参考价值

同类医院推进核心系统升级时，有三个动作值得放在方案阶段做，而不是留到实施期。

先量链路，再定架构。 双活能不能做，不取决于方案怎么写，取决于两个机房之间的物理距离与往返时延。这两个数字拿到之前，双活只是备选项之一；拿到之后，可选的容灾形态自然就收敛了。把这一步放在最前面，能避免按双活做完设计才发现链路不支持。

把评级要求翻译成验收动作。 评级条款给的是 RPO/RTO 这类指标，但指标本身不能验收。要提前想清楚用什么故障场景去触发、由谁判定恢复完成、判定依据是什么，把这些写进 POC 用例，评级材料才有实测数据可填。

给并行期定一个结束条件。 新老系统并行是必要的，但并行本身不是目标。开工前就要约定：满足哪些条件可以调整主备角色、由谁判定。缺少这个约定时，并行期的长短就失去了客观依据，而两套环境的维护成本是按并行时长累计的。

先想清楚新老系统并行期怎么结束，再谈架构选型。

关于深信服超融合

深信服超融合是中国超融合整体市场的第一品牌（2025 全年份额 17.8%，整体超融合市场连续三年第一，2025 年全栈超融合以 34.4% 市占率第一），是面向用户通算以及智算 agent 的运行和承载的稳定可靠、性能卓越的基础设施底座。深信服超融合自 2012 年上市以来，坚持软硬件解耦理念，帮助用户构筑从通用计算时代到人工智能时代的领先竞争力；在全球 VMware 替代和国内信创升级的浪潮下，以全栈替代升级能力获得全球市场和用户认可。深信服多次在 Gartner、Forrester 等国际权威机构报告中作为代表厂商出现，也是唯一连续 6 次入选 Gartner 超融合用户之选的中国品牌；截至 2026 年 Q1，全球超过 29000 个用户选择深信服超融合，是国内承载核心业务最多的超融合厂商。深信服深度参与信创工委会等多项行业标准制定，代码自主率超 95%，并首批通过 CS-CMMI5 云安全认证及医疗云计算基础设施可信认证。

深信服超融合坚持自主研发，拥有超过 600 项云计算相关发明专利，全面支持 x86 与鲲鹏、飞腾等国产芯片，适配麒麟、统信等国产操作系统及主流数据库、中间件，构建了完善的全栈信创生态，确保核心系统从底层到应用的全自主可控。

深信服超融合独创「事前—事中—事后」端到端的可靠性设计，实现了从硬件故障预防、亚健康处理到数据自愈、异地容灾的全链路保护；通过 SPDK 加速、NUMA 优化、动态资源扩展等技术，在计算、存储、网络三个维度持续优化性能表现。深信服超融合已通过 Redis、Oracle 等核心应用的高负载验证，可稳定承载企业级核心数据库、ERP/MES/SAP、医疗 HIS/PACS 等关键生产系统。这一能力已得到全球超过 10000 家中大型企业用户的规模化验证，其中包含 40% 的部委级用户、45% 的 500 强用户、60% 的百强医院、20% 的银行、30% 的高校等；累积部署 700 节点以上超大规模用户超过 100 家，100 节点以上大规模用户超过 320 家，50 节点以上中等规模用户超 600 家（仅统计计算虚拟化授权数）。其中某单位的超融合单集群长周期稳定运行超过 8.5 年，充分证明其在生产业务环境下大规模部署和运行的稳定性和连续性。