1. 医疗系统高可用架构导论

医疗信息系统与一般互联网业务最大的区别在于：它的停机代价往往不是“少卖几单”，而是直接影响患者安全。挂号、医嘱、检验、影像、收费、发药、手术麻醉、重症监护等环节已经高度依赖信息系统，一旦核心业务不可用，临床就可能被迫退回纸质流程，产生漏项、重复、延误甚至用药错误。因此，医疗系统的高可用架构，本质上是在为“临床业务连续性”提供技术保障。

一、医疗业务连续性要求

医疗业务连续性（Business Continuity）指在系统故障、网络中断、机房断电、数据库损坏乃至区域性灾难发生时，医疗机构仍能维持关键诊疗活动的能力。它关注的不是“系统永远不坏”，而是“坏了以后业务还能不能转、多久能恢复、数据会不会丢”。

医疗业务通常按临床影响程度分级。以一家三级医院为例，可粗略划分为：

• 一级（生命攸关）：急诊抢救、手术麻醉、ICU监护、医嘱执行、危急值报告。这类业务中断数分钟即可能危及生命，要求接近“零中断”，通常需要双活或本地高可用集群支撑。
• 二级（诊疗核心）：门诊挂号、医生站、护士站、检验检查申请与报告、药房发药、住院结算。中断会影响大量患者，要求分钟级恢复。
• 三级（运营支撑）：财务、人事、办公、科研、报表。可容忍小时级中断，通常安排在业务低峰维护。

连续性要求最终要落到两个可度量的目标上：RTO（Recovery Time Objective，恢复时间目标）和RPO（Recovery Point Objective，恢复点目标）。RTO 回答“业务允许停多久”，RPO 回答“数据允许丢多少”。例如，某医院为 HIS 核心库设定 RTO≤5 分钟、RPO=0，就意味着故障后 5 分钟内必须恢复服务，且不允许丢失任何已提交的医嘱或收费记录。这两个指标是后续所有架构选型、投资和演练的出发点。

二、高可用定义与度量指标

高可用（High Availability，HA）指系统通过冗余、故障检测与自动切换等机制，在组件失效时仍能持续提供服务的能力。它不等于“高性能”，也不等于“容灾”——容灾侧重灾难场景下的数据与业务恢复，高可用侧重日常故障下的持续运行，二者常配合使用。

可用性通常用“年停机时间”衡量。业界常用“几个 9”表示：

除可用性外，还需关注 MTBF（平均无故障时间）与 MTTR（平均修复时间）。三者关系可近似表示为：可用性 = MTBF / (MTBF + MTTR)。这说明提升可用性有两条路径：一是延长无故障时间（提高质量、冗余设计），二是缩短修复时间（自动切换、快速定位、预案演练）。在医疗场景中，缩短 MTTR 往往比追求“永不出错”更现实、更有效。

三、架构工程全景图

医疗高可用架构不是单一技术，而是一套分层协同的工程体系。从下到上可理解为：基础设施层、数据层、应用层、接入层、运维与治理层。每一层都要回答“冗余在哪里、故障如何发现、切换由谁执行、数据是否一致”。

下面这张全景图把各层的关键对象、冗余手段与故障切换关系集中呈现，便于建立整体认知。

这张图强调三点：第一，冗余必须分层，任何单层冗余都无法覆盖上层或下层的故障；第二，故障检测与切换机制要贯穿各层，否则冗余只是“备而不用”；第三，数据层是医疗高可用的核心难点，因为医嘱、检验结果、影像索引都要求强一致或可追溯，RPO=0 往往意味着同步复制与存储双活，成本和技术复杂度都最高。

四、从指标到工程落地

理解概念之后，关键是把指标翻译成工程动作。假设某医院为门诊 HIS 设定 RTO≤5 分钟、RPO=0，可按如下思路拆解：

1. 识别单点：梳理从终端到数据库的调用链，标出负载均衡、应用实例、数据库、存储、网络、供电中的单点。
2. 设计冗余：接入层双机 VIP，应用层多实例，数据库一主一备同步复制，存储双活，网络双上行。
3. 定义检测：健康检查间隔 3 秒、连续 2 次失败判定异常，避免误切；数据库复制延迟超过阈值即告警。
4. 自动切换：应用层由负载均衡摘除故障节点；数据库由集群管理组件触发主备切换，切换后校验数据一致性。
5. 验证与演练：每季度做一次真实切换演练，记录实际 RTO 与 RPO，与目标比对，形成改进项。

例如，一次演练中模拟主库宕机，监控在 8 秒内发现异常，集群在 42 秒完成主备切换，应用重连后业务恢复，总耗时约 1 分 10 秒，RPO 为 0。若目标 RTO 是 5 分钟，则达标；若目标是 1 分钟，则需优化检测灵敏度或切换脚本。这样的演练数据，才是架构是否真正高可用的判断依据。