中医医院是我国医疗服务体系中具有独立形态的一类机构。它既要完成综合医院的完整诊疗链条——挂号、门诊、住院、检验、检查、手术、结算，又要承载极具特色的中医业务：中医电子病历与辨证论治记录、治未病中心、名医传承工作室、中药房与煎药中心、膏方与代煎配送、针灸推拿等非药物疗法的排程管理。这些业务在信息系统中的共同特征是流程长、单据多、与患者服务强耦合，任何一次系统中断都不只是"IT 故障"，而是直接切断患者的就医路径。

近年来中医医院的数字化呈现出两个明显趋势。一是业务边界向线上延伸，互联网中医医院、线上复诊、线上开方、代煎配送等场景快速普及，核心系统的并发量与单据量被成倍放大；二是核心系统本身在换代，新一代 HIS 普遍转向微服务架构，服务被拆分、调用链变长，承载平台需要同时提供弹性与稳定。与之叠加的还有国产化替代的节奏——VMware 停售 vSphere 主力版本后，中医医院同样面临存量虚拟化平台替换的现实压力。

与综合医院不同的是，中医医院的信息化建设往往同时受两类要求牵引：一类是公立医院绩效考核、电子病历分级评价、互联互通测评等通用性指标，另一类是中医药特色业务对系统的个性化诉求，例如辨证论治结构化记录、中药饮片与代煎流程追溯、名医经验数据沉淀。前者要求系统稳定、数据规范，后者要求系统灵活、可扩展。当这两类要求落在同一套基础设施上时，承载平台的架构弹性与可靠性就成了一道必答题。这两条线索交会在一处：中医院既要在架构升级中保持业务连续，又要在信创替代中不牺牲可靠性。对承载平台的要求因此非常明确——双活不能只做到"数据有副本"，而要保证故障发生时业务分钟级接管；架构要能同时容纳传统业务与微服务，还要能把不同国产芯片路线统一到一套运维视图中；迁移则必须在真实业务量下完成验证，而不是把风险留到上线之后。本文以浙江省中医院、江苏省中医院两家大型三甲中医医院的实践，说明这条路径如何落地。

一、中医院的核心业务，为什么更怕“停”

• 核心业务同样"停不得"：HIS、电子病历、检验、影像、中药房与煎药配送环环相扣，挂号与门诊收费一旦中断，院内排队会迅速外溢，中医特色业务的单据流转也随之停摆。中医医院的业务高峰往往与季节性强相关，膏方季、冬病夏治等时段门诊量集中，对平台的短时承载能力构成额外考验。

• 架构升级与连续性必须同步完成：新一代 HIS 转向微服务后，服务实例数量多、调用链长，故障传播路径不再是单点，承载平台既要支撑弹性伸缩，也要保证链路异常时能快速隔离。架构换代通常只能在一个有限窗口内完成，医院无法承受"先跑一段时间再补可靠性"的做法。

• 线上业务放大并发峰值：互联网诊疗与线上处方把业务压力从院内窗口延伸到全天候入口，单日单据量可达千万级，平台必须在这种峰值下仍保持稳定响应，且响应时延的波动会直接体现为患者端的使用体验。

• 双活的门槛在"接管"而非"同步"：原有双活体系要求 RPO=0 与分钟级 RTO，替换后的平台若只能恢复数据而不能自动接管业务，连续性实际上是降级的。跨机房场景下还需解决网络二层打通、虚拟机漂移后业务地址保持不变等细节问题。

• 多芯片路线并存带来运维割裂：C86 与 ARM 并行建设是信创推进中的常见选择，若各资源池独立管理，运维成本与使用体验的差异会被放大；一旦形成多套操作界面与多套流程，运维团队的实际负担可能不降反升。

二、把双活与信创放进同一张图纸

双活不是备份的升级版

超融合延展集群支持两个独立故障域对等承载业务，数据双副本实时强一致同步，实现 RPO=0；任一故障域异常时，另一域可自动接管全部业务，达到分钟级 RTO。配合跨机房二层网络互通，虚拟机跨中心漂移后仍保持原有业务 IP，业务侧不感知迁移动作。

微服务 HIS 需要怎样的底座

超融合与容器、微服务架构可以融合部署，HIS 的微服务实例可随业务量弹性扩缩；配合网络流量可视与亚健康检测能力，服务间东西向调用异常能够被及时发现与定位，避免"服务还在、链路已断"的隐性故障。

两条芯片路线，一套运维手感

同一套云平台可同时纳管 C86 与 ARM 架构资源，多资源池统一管理，使用功能与操作体验保持一致。医院可以按业务重要性与供应情况分步演进，不被单一芯片生态绑定，也不会因双栈并行而形成新的基础设施孤岛。

从数据库到中间件的全栈适配

从操作系统、数据库、中间件到上层应用运行环境形成完整适配链路，使信创交付覆盖整个栈，而非只更换底层服务器。对核心业务而言，这种全栈一致性是"迁得上、跑得稳"的前提。

切换之前，先把风险演练一遍

存量 VMware 业务可通过虚拟机级迁移分批切换，迁移前以真实业务数据做性能与稳定性验证，迁移中保持上层应用少改造。中医院核心系统不宜"先上线再优化"，这种前置验证方式更符合其业务节奏。

三、两家中医院的两种落地路径

两家中医医院的切入点不同：一家从架构升级切入，把微服务 HIS 放到双活底座上；一家从芯片路线切入，用双栈资源池解决异构管理难题。

浙江省中医院：微服务 HIS 落在双活架构之上

浙江省中医院（浙江中医药大学附属第一医院）是大型三甲中医院，其新一代 HIS 转向微服务架构，承载平台需要弹性与可靠兼得；同时线上服务规模激增，核心业务的故障切换能力成为硬性要求。医院将微服务与超融合架构全面融合，并以双活架构承载微服务新一代 HIS，核心业务支持分钟级故障切换。成效体现在真实业务量上：平台单日承载 1000+ 万线上处方贴、56 万线上患者注册数，挂号、处方等就医服务在高并发下保持连续可用。对中医院而言，这种"弹性扩展 + 双活容灾"的组合，正是新一代医疗应用最需要的底座形态。

江苏省中医院：C86+ARM 双栈资源池，异构资源统一管理

如果说浙江省中医院解决的是架构与连续性的矛盾，江苏省中医院面对的则是芯片路线多元带来的管理问题。这家大型三甲中医院以国产 C86 芯片为主、ARM 芯片为辅，基于深信服超融合建设双栈架构信创资源池，通过异构虚拟化多资源池统一管理，使双栈并行下的使用功能与操作体验保持一致。实际效果有两点：一是 C86 与 ARM 双栈并行不产生体验割裂，医护与运维人员的操作方式统一；二是多资源池统一管理后，异构信创资源的运维负担明显下降。这种路线既保证了技术自主，也避免了被单一生态锁定，为后续按需演进留出空间。

两家医院的选择共同说明：中医医院的信创不是一次性的平台替换，而是"架构演进 + 芯片多元 + 连续性保障"三件事的同步推进——只有在承载层把这三者统一起来，核心业务才敢真正迁上去。

结语：连续性先于国产化

中医医院的核心业务规模或许不像超大型综合医院那样庞大，但业务链条更长、患者服务触点更密，中断的代价同样不可承受。浙江省中医院以双活架构承载微服务 HIS，江苏省中医院以 C86+ARM 双栈资源池实现异构统一，两条路径指向同一个结论：信创替代的底线是连续性不降级，前提是平台具备双活接管、弹性承载与多芯统一管理的能力。目前已有超 900 家三甲医院选择深信服超融合推进国产云平台升级，其中中医医疗机构的实践，正在为同类机构提供可借鉴的推进节奏与技术路线。