3. 平台总体架构设计

医疗设备数据平台的总体架构，本质上是在“设备侧的高频、异构、强实时数据”与“临床、科研、运维侧的稳定、可追溯、可复用数据服务”之间，建立一条职责清晰、边界明确、可演进的分层通道。分层不是为了画图好看，而是为了让每一层只解决一类问题：采集层解决“怎么把设备数据完整、准确地拿到”，传输层解决“怎么可靠、有序、可追溯地送到平台”，存储层解决“不同形态的数据放在哪里、保留多久”，计算层解决“怎么把原始信号变成有临床或工程意义的指标”，服务层解决“怎么以稳定接口把能力交付给上层应用”，治理层则贯穿全程，解决“数据是否可信、是否合规、是否可被找到和复用”。

下面这张图给出的是本节推荐的分层架构与接口边界示意。它强调的不是部署拓扑，而是各层之间的数据形态变化与职责切分：越往下越接近设备与原始信号，越往上越接近业务语义与服务契约。

从图中可以看到，六层并非简单的上下堆叠，而是存在明确的“接口边界”。采集层与传输层之间的边界是“原始帧 + 设备标识 + 采集时间戳”；传输层与存储层之间的边界是“带主题与分区键的消息”；存储层与计算层之间的边界是“可查询的数据集或流”；计算层与服务层之间的边界是“指标、事件、告警等语义化结果”；服务层与上层应用之间的边界是“带版本号的接口契约”。治理层不单独占一个数据阶段，而是以旁路方式贯穿所有层，采集元数据、质量指标、血缘关系和审计日志。

各层的职责可以进一步落到具体设计决策上。采集层的关键不是“能连上设备”，而是“连上之后不丢数、不乱序、时间戳可信”。以一台多参数监护仪为例，假设它通过串口每 1 秒输出一帧包含心率、血氧、呼吸率的数据，采集服务需要为每帧打上设备本地时间与平台接收时间两个时间戳，并在网络中断时把数据写入本地环形缓存，恢复后按序补传。传输层则要为每类数据定义主题，例如 device.vitals.raw、device.waveform.raw，用设备 ID 作为分区键，保证同一台设备的数据在同一分区内有序。存储层要根据数据特征选择介质：波形数据写入时序库并设置 90 天热存储、1 年冷存储；影像文件写入对象存储并保留 DICOM 元数据索引；患者与设备主数据写入关系库并做唯一性约束。计算层要区分流式与批量：实时告警走流式计算，窗口设为 5 秒滑动；趋势统计走批处理，每天凌晨对前一日数据做聚合。服务层要对外暴露稳定接口，例如 GET /v1/patients/{id}/vitals?from=&to=，并明确返回字段、单位、时间格式和错误码。治理层则要回答“这条数据从哪台设备来、经过了哪些处理、当前质量如何、谁看过、是否脱敏”。

在关键设计原则上，有几条需要特别强调。第一，时间对齐优先：医疗设备数据常来自不同时钟源，平台必须统一到同一时间基准，否则心率与血氧的联合分析会失真。第二，接口契约化：层与层之间只通过约定格式交互，禁止跨层直连，例如计算层不得直接读取采集层缓存。第三，冷热分层与生命周期：不是所有数据都值得长期高成本保存，原始波形可降采样归档，指标与事件长期保留。第四，幂等与可回放：计算任务重复执行不应产生重复结果，消息队列应支持按时间偏移重放，便于故障恢复和算法验证。第五，最小必要与权限隔离：服务层对外只暴露必要字段，敏感数据在治理层完成脱敏后再进入科研或运营视图。

实际落地时，建议先用一张“层间接口清单”把边界固定下来，再逐层实现。清单至少包含：接口名称、数据形态、格式示例、时间戳字段、分区键、保留策略、责任团队。例如采集到传输的接口可定义为“原始帧消息”，格式为 JSON 或 Protobuf，必含 deviceId、collectTime、payload；传输到存储的接口可定义为“主题消息”，必含 topic、partitionKey、offset。这样，后续无论更换消息中间件还是调整存储介质，只要接口契约不变，上层计算与服务就不需要跟着改。分层架构的价值，最终体现在“局部可替换、整体可演进”上。