3. 健康数据接入协议选型

在可穿戴健康数据接入平台中，协议选型不是“哪个更先进”的问题，而是“哪一段链路由谁承担什么职责”的问题。可穿戴设备通常先通过 BLE 与手机或网关通信，再由手机/网关把数据送到云端；云端内部又可能用 MQTT 做设备上行、用 WebSocket 做实时推送、用 HTTP 做配置查询与批量补传。因此，本节把协议放在“设备—网关—平台—应用”的完整链路中比较，而不是孤立地罗列特性。

一、先明确四类协议在链路中的位置

BLE 是短距无线链路协议，工作在设备与手机/网关之间，典型角色是“采集端到汇聚端”。MQTT 是面向物联网的发布/订阅消息协议，通常运行在 TCP 之上，适合网关到云端的持续上行。HTTP 是请求/响应式应用层协议，适合配置下发、历史查询、批量补传等“有明确请求—响应”的场景。WebSocket 是在 HTTP 升级后建立的全双工长连接，适合云端向 App、看板或医生工作站实时推送数据。

理解这一点后，选型判断就有了第一层依据：看这段链路是短距还是广域、是持续流还是偶发请求、是设备主动上报还是服务端主动推送。下面这张图把四类协议放回真实链路中，标出各自的承载段与典型数据方向。

二、四类协议的关键差异与判断依据

BLE 的核心约束是连接数、功耗和吞吐。以心率带为例，若采用 GATT Notify 每秒推送 1 个心率值，单包约 20 字节，实际占用带宽极低，但连接建立、配对和断线重连会带来明显延迟。因此 BLE 适合“设备到手机”的持续小数据流，不适合直接跨公网传输。

MQTT 的优势在于长连接、低开销和发布/订阅解耦。设备或网关只需连接 Broker，按主题发布数据，平台按主题订阅。典型主题可设计为 health/{deviceId}/vitals，QoS 1 保证至少一次送达，适合心率、血氧等周期性数据。但 MQTT 不擅长“请求—响应”式查询，也不适合直接承载大文件。

HTTP 的优势是通用、易调试、易与现有后端集成。它适合配置下发、历史数据查询、批量补传。例如设备离线 2 小时后恢复，网关可用 HTTP POST 将缓存数据批量提交到 /api/v1/vitals/batch，服务端返回 200 表示接收成功。但 HTTP 每次请求都要建立连接，不适合高频实时推送。

WebSocket 的优势是全双工、低延迟、服务端可主动推送。当平台收到新数据后，可立即通过 WebSocket 推送给 App 或看板，避免轮询。但它需要维护长连接，对连接数、心跳和断线重连有额外要求，适合“服务端到应用”的实时通道。

三、选型决策表与典型组合

实际工程中很少只用一种协议，而是按链路分层组合。下面给出一个可直接参考的选型决策表，字段包括链路位置、数据方向、推荐协议、关键参数和典型场景。

一个典型的组合是：手环通过 BLE 将心率推送到手机 App；App 在本地做初步过滤后，通过 MQTT 将数据发布到云端；云端在收到异常心率时，通过 WebSocket 推送给医生工作站；同时，App 每天通过 HTTP 拉取一次用户配置和历史统计。这个组合覆盖了短距、广域、实时推送和请求响应四类需求。

四、实操示例：用 MQTT 上报心率并观察结果

下面以网关通过 MQTT 上报心率为例，给出可执行的配置与观察方法。示例参数为教学假设，不是实测结果。

Broker: mqtts://health-broker.example.com:8883
Client ID: gw-ward-03
Username: gateway
Password: ******
Topic: health/gw-ward-03/vitals
QoS: 1
Keep Alive: 60
Payload:
{
  "deviceId": "band-1024",
  "ts": 1735689600000,
  "hr": 78,
  "spo2": 97,
  "temp": 36.6
}

网关启动后，先订阅 health/gw-ward-03/ack 用于接收平台确认，再向 health/gw-ward-03/vitals 发布数据。判断是否成功，可以观察三个信号：一是 Broker 返回 PUBACK，说明 QoS 1 消息已被接收；二是平台侧订阅端在 1 秒内收到消息并写入时序库；三是若 5 秒内未收到 PUBACK，网关应重发并记录重试次数。若连续重试 3 次仍失败，则切换为 HTTP 批量补传，避免数据丢失。

总结来看，BLE 负责短距采集，MQTT 负责广域上行，HTTP 负责请求响应与补传，WebSocket 负责实时推送。四者不是替代关系，而是分层协作关系。选型时先画清链路，再按数据方向、频率和实时性要求逐段匹配，才能得到稳定、可维护的健康数据接入方案。