📚 课程目录第4章采集平台需求分析与架构设计

4. 采集平台需求分析与架构设计

医疗设备数据采集平台的需求分析与架构设计，核心任务是把临床现场“设备多、协议杂、数据不能丢、系统不能停”的诉求，翻译成可验证的工程条目和可落地的结构决策。需求分析不是写一份愿望清单，架构设计也不是画一张漂亮的分层图，二者必须形成可追溯的映射：每一条架构决策都能回答它满足了哪条需求，每一条需求都能找到对应的验证方式。

一、功能性需求：从设备接入到数据可用

功能性需求描述平台“必须做什么”。在采集平台中，它至少覆盖四条主线：设备接入、数据解析、数据流转、数据服务。

设备接入方面，典型需求包括：支持 HL7 v2、ASTM、DICOM、Modbus TCP、MQTT 等协议；支持串口、网口、USB 转串口等多种物理链路；单台采集网关并发接入不少于 32 台设备；支持设备断线自动重连，重连间隔可配置（示例：5s、10s、30s 退避）。

数据解析方面，需要把原始报文转换为统一内部模型。例如监护仪通过 HL7 ORU^R01 上报，一条消息可能包含心率、血氧、血压等多个 OBX 段。解析需求应明确：字段映射规则可配置、单位换算可配置、异常报文进入死信队列而非直接丢弃。

数据流转方面，需求通常包括：本地缓存不少于 24 小时原始数据；支持断网续传；支持按设备、按时间段、按指标类型订阅；向 HIS、EMR、科研平台提供 REST 与消息两种输出方式。

数据服务方面，需要提供设备状态查询、采集质量统计、数据补采、时间对齐等能力。这里的关键是：功能性需求必须写成可测试的条目，而不是“系统应稳定运行”这类无法验证的表述。

二、非功能性需求：决定平台能否长期运行

非功能性需求描述平台“必须做到什么程度”。它往往比功能需求更影响架构走向。采集平台最常被忽略却最致命的是时间同步：如果多台设备时间不一致，后续趋势分析、报警回溯、科研数据对齐都会失真。因此应明确：所有采集网关与 NTP 服务器同步，偏差不超过 100ms；数据入库时同时记录设备时间与平台接收时间。

性能方面，示例指标可设为：单网关每秒处理 500 条消息；端到端延迟 P95 小于 2s；查询最近 24 小时单设备数据响应小于 1s。可靠性方面：年可用性不低于 99.9%；单点故障不影响整体采集；数据丢失率低于 0.01%。安全性方面：设备接入需认证；传输加密；操作审计留存不少于 6 个月。可维护性方面：新增一种设备协议的工作量不超过 5 人日；配置变更无需停机。

非功能性需求要尽量量化，并注明验证方法。例如“端到端延迟 P95 小于 2s”应说明是在多少并发、多少设备、什么网络条件下测得，否则指标无法验收。

三、高可用、可扩展、可维护的架构拆解

高可用关注“故障时还能不能采”。采集平台的高可用不能只靠数据库主备，因为最靠近设备的采集网关一旦宕机，数据就断了。合理做法是：网关层支持双机热备或容器多副本，设备连接通过虚拟 IP 或服务发现切换；消息层使用 Kafka 或 RabbitMQ 做缓冲，消费者可多实例部署；存储层采用时序数据库集群加对象存储归档。

可扩展关注“新增设备、新增指标、新增消费方时改哪里”。架构上应把协议适配、解析规则、输出通道做成可插拔模块。新增一台呼吸机，理想情况下只新增一个协议适配器和一份字段映射配置，而不是修改核心采集流程。

可维护关注“出问题时能不能快速定位”。这要求架构中预留可观测性：每条数据带 traceId；网关、解析、入库各阶段记录指标；提供设备连接状态、队列积压、解析失败率等看板。可维护性还体现在配置管理上：设备档案、协议参数、映射规则应版本化，支持回滚。

四、文档化：让需求和架构可追溯

需求与架构文档化的关键不是篇幅，而是可追溯。推荐使用“需求—架构—验证”三列映射表，每条需求有唯一编号，每条架构决策引用需求编号，每条验证用例引用架构模块。例如：

需求编号	需求描述	架构决策	验证方式
FR-01	支持 HL7 v2 监护仪接入	协议适配器插件 + 字段映射配置	接入 3 台监护仪，核对 5 个指标
NFR-01	端到端延迟 P95 < 2s	Kafka 缓冲 + 消费者多实例	500 msg/s 压测，统计 P95
NFR-02	年可用性 ≥ 99.9%	网关双机热备 + 存储集群	故障注入：主网关宕机切换
NFR-03	时间偏差 ≤ 100ms	NTP 同步 + 双时间戳记录	抽样比对设备时间与平台时间

文档还应包含部署视图和配置样例。例如采集网关的配置片段：

gateway:
  id: gw-icu-01
  ntp_server: 10.10.1.20
  reconnect:
    initial_interval: 5s
    max_interval: 30s
  devices:
    - name: monitor-bed-03
      protocol: hl7v2
      endpoint: 10.20.3.15:2575
      mapping: monitor_standard_v2.yaml
  buffer:
    local_cache_hours: 24
    resend_on_reconnect: true

这份配置本身就是架构决策的落地证据：它体现了断线重连、本地缓存、映射可配置等设计。评审时，评审人不需要读代码，就能判断需求是否被覆盖。

常见误区是把非功能性需求写成“系统应稳定、应安全、应易维护”。这类表述无法验证，也无法驱动架构。应改为可测量指标，并明确测量条件与验收方法。

五、从需求到架构的检查闭环

完成拆解后，建议做一次闭环检查：每条功能性需求是否都有对应模块？每条非功能性需求是否都有对应架构策略和验证方式？新增设备时，改动是否局限在适配器和配置层？故障发生时，是否有降级和恢复路径？如果这四个问题都能回答，需求分析与架构设计才算真正完成，而不是停留在文档层面。