3. 智慧病区平台总体架构设计

智慧病区平台要同时承载床旁监护、输液监测、护理交互、医嘱闭环、定位与呼叫等多类业务，这些业务在实时性、数据量、可用性和合规要求上差异极大。因此总体架构不能是单一技术栈的堆叠，而应是一套“分层解耦 + 微服务化 + 云边协同 + 高可用兜底”的组合设计。本节先给出分层骨架，再说明微服务如何切分、云边如何分工，最后讨论架构风格选型时的权衡依据。

一、分层架构：把变化隔离在层内

推荐采用五层结构，自下而上为：设备接入层、边缘计算层、平台服务层、业务应用层、统一门户层。分层的核心价值是“每层只暴露稳定接口，内部实现可独立演进”。

• 设备接入层：负责监护仪、输液泵、床旁终端、定位标签、呼叫手柄等设备的协议适配。常见协议包括 HL7 v2、IEEE 11073、MQTT、Modbus TCP 以及厂商私有串口协议。该层输出统一设备模型，例如 {deviceId, patientId, metric, value, unit, ts, quality}。
• 边缘计算层：部署在病区机房或楼层边缘节点，承担协议转换、数据清洗、阈值告警初判、断网缓存与本地联动。边缘节点是“病区自治”的关键，网络中断时仍能维持床旁告警和呼叫。
• 平台服务层：提供患者主索引、设备管理、消息总线、时序存储、规则引擎、权限与审计等共性能力，供上层业务复用。
• 业务应用层：实现监护看板、输液管理、护理任务、医嘱闭环、质控统计等业务微服务。
• 统一门户层：面向护士站大屏、移动护理 PDA、医生工作站提供统一入口与单点登录。

层间调用遵循“上层依赖下层接口、同层通过消息总线异步协作”的原则。例如监护数据从设备接入层进入后，经边缘层清洗，由平台层消息总线分发，业务层订阅后写入时序库并触发规则引擎，门户层只做展示，不直接访问设备。

二、微服务切分：按业务能力而非技术分层

微服务切分应遵循“高内聚、低耦合、数据自治”原则。智慧病区平台可按业务能力划分为：患者服务、设备服务、监护数据服务、告警服务、输液服务、护理任务服务、医嘱服务、定位服务、审计服务。每个服务拥有独立数据库，禁止跨库直连，跨服务协作通过消息总线或 API 网关完成。

以“监护数据服务”为例，其职责边界是：接收边缘层上报的时序数据、按患者与时间窗口聚合、对外提供查询接口。它不负责告警判定，告警判定由“告警服务”订阅消息后独立完成。这样切分的好处是：告警规则变更不影响数据写入，数据存储扩容不影响告警逻辑。

服务间通信建议采用“同步查询 + 异步事件”混合模式。查询类接口走 REST/gRPC 同步调用，状态变更类走消息总线异步发布。例如患者入区事件发布后，监护服务、护理任务服务、定位服务各自订阅并初始化上下文，避免网关串行编排。

三、云边协同：把实时性留在边侧，把全局性放在云侧

云边协同的核心是职责划分。边侧负责“毫秒到秒级”的实时处理：设备协议解析、阈值初判、床旁声光告警、断网缓存。云侧负责“秒到分钟级”的全局处理：跨病区数据汇聚、历史趋势分析、质控统计、模型训练与下发。

一个可参考的协同参数示例（示例值，需按实际病区调整）：边缘节点本地缓存容量按 24 小时数据量设计，假设单病区 60 张床、每床 8 个参数、采样周期 1 秒，则日增原始数据约 60×8×86400 ≈ 4147 万条，经边缘聚合为 1 分钟粒度后约 69 万条，缓存压力显著降低。同步通道采用 MQTT over TLS，QoS 1，断点续传以消息序号和幂等键去重。

四、高可用设计：从单点消除到故障域隔离

高可用不是“多买几台服务器”，而是按故障域逐层设计。可参考以下要点：

• 接入层：边缘网关双机热备，VIP 漂移；设备支持双上行时优先双链路。
• 平台层：微服务无状态化，至少 2 副本，跨物理节点反亲和部署；消息总线三节点集群，副本数 3。
• 数据层：时序库按患者 ID 分片，副本数 2；关系库主备同步，切换 RTO ≤ 30 秒、RPO ≤ 5 秒。
• 网络层：病区与云侧之间采用双运营商链路，关键告警走本地闭环不依赖云侧。
• 降级策略：云侧不可用时，边侧进入自治模式，仅保留告警、呼叫、缓存三项核心能力。

五、架构风格选型与权衡

常见候选风格包括单体分层、微服务、事件驱动、服务网格。选型时建议用“实时性、可维护性、部署复杂度、故障影响面、团队能力”五个维度打分。对于智慧病区平台，推荐“分层 + 微服务 + 事件驱动”组合：分层保证边界清晰，微服务保证业务独立演进，事件驱动保证告警与联动的低耦合。

权衡的关键不是追求“最先进”，而是让架构复杂度与病区规模、团队能力和合规要求匹配。建议先以“分层 + 边缘自治”保证临床可用性，再逐步将云侧业务拆分为微服务，最后在服务数量增长后引入服务网格。每一步演进都应保留可回退路径，避免一次性重构带来的临床风险。