远程医疗（Telemedicine）近年来发展迅速，从线上问诊到远程会诊，再到慢病管理，整个行业对实时、稳定、安全的通信服务提出了很高的要求。Node.js凭借事件驱动和非阻塞I/O的特性，在处理大量长连接场景时表现出色，非常适合用来构建远程医疗系统的实时通信层。本文将从整体架构、音视频通信、实时消息、数据安全几个方面，详细讲解如何用Node.js落地一个远程医疗平台的核心功能。
一、远程医疗系统的整体架构设计
一个完整的远程医疗系统通常包含几个核心模块：用户管理（患者端与医生端）、预约挂号、音视频问诊、即时消息、电子处方、健康档案。其中对服务器压力最大的是音视频问诊和即时消息这两个实时模块，而这恰恰是Node.js的强项。
典型的技术选型可以是这样：Web层使用Express或Koa提供RESTful API，处理挂号、登录、处方提交等常规请求；实时通信层使用Socket.IO维护长连接，负责问诊室内的信令交互和消息收发；音视频流本身则通过WebRTC在浏览器之间点对点传输，Node.js只承担信令服务器的角色，不中转媒体流，这样既节省带宽，又降低延迟。
这种分层设计的好处在于职责清晰。REST层无状态可以水平扩展，实时层通过Socket.IO配合Redis适配器实现多实例部署，媒体流则完全由客户端承担。对于中小型医疗平台来说，这套架构在没有大规模自建流媒体服务器的情况下就能支撑数千人同时在线问诊。
二、用Node.js搭建WebRTC信令服务器
WebRTC是浏览器端点对点音视频通信的标准方案，医生和患者的视频问诊可以直接在浏览器中完成，无需安装客户端。但WebRTC建立连接之前，双方需要交换SDP描述和ICE候选信息，这个交换过程必须依赖信令服务器，而信令服务器通常就用Node.js的Socket.IO来实现。
信令服务器的核心逻辑是房间管理：医生和患者加入同一个问诊房间，服务器将一方产生的SDP和ICE消息转发给另一方。下面是一个简化但可运行的信令服务器实现：
const express = require('express');
const http = require('http');
const { Server } = require('socket.io');
const app = express();
const server = http.createServer(app);
const io = new Server(server, {
cors: { origin: '*' } // 生产环境应限制为具体域名
});
io.on('connection', (socket) => {
// 医生或患者加入问诊房间
socket.on('join-room', (roomId, role) => {
socket.join(roomId);
socket.data.role = role;
// 通知房间内已有成员：新用户加入了
socket.to(roomId).emit('peer-joined', socket.id, role);
});
// 转发WebRTC协商信息（SDP）
socket.on('offer', (targetId, offer) => {
io.to(targetId).emit('offer', socket.id, offer);
});
socket.on('answer', (targetId, answer) => {
io.to(targetId).emit('answer', socket.id, answer);
});
// 转发网络候选信息（ICE）
socket.on('ice-candidate', (targetId, candidate) => {
io.to(targetId).emit('ice-candidate', socket.id, candidate);
});
// 断线时通知对方，便于前端做重连或提示
socket.on('disconnect', () => {
socket.broadcast.emit('peer-left', socket.id);
});
});
server.listen(3000, () => console.log('信令服务器运行于 3000 端口'));
需要注意的一点是，上述代码使用socket.to(targetId)进行定向转发，避免了把协商信息广播给整个房间的所有人。在多方会诊场景下，这一点尤其重要，否则SDP交换的混乱会导致连接建立失败。
浏览器端的实现思路是：调用navigator.mediaDevices.getUserMedia获取摄像头和麦克风权限，创建RTCPeerConnection，把本地流加入连接，然后通过Socket.IO把offer和answer来回传递。整个协商完成后，音视频数据直接在两个浏览器之间流动，Node.js服务器几乎不承担流量压力。
三、即时消息与健康数据的实时同步
除了视频，问诊过程中还经常需要文字沟通、发送检查报告图片、同步心率血压等监测数据。这些都可以走Socket.IO通道。消息服务要考虑两个问题：一是消息的可靠送达，二是离线消息补发。
对于可靠送达，可以在应用层实现ACK机制：客户端发送消息后，服务器收到并落库，再回调确认，客户端超时未收到确认就重发。Socket.IO本身就支持确认回调，写法如下：
// 服务端：收到消息后持久化并确认
socket.on('chat-message', (msg, ack) => {
saveMessageToDb(msg) // 写入数据库
.then(() => ack({ status: 'ok', timestamp: Date.now() }))
.catch(() => ack({ status: 'fail' }));
});
// 客户端：带超时的可靠发送
function sendMessage(msg) {
return new Promise((resolve, reject) => {
const timer = setTimeout(() => reject(new Error('发送超时')), 5000);
socket.emit('chat-message', msg, (res) => {
clearTimeout(timer);
res.status === 'ok' ? resolve(res) : reject(res);
});
});
}
离线消息则依赖数据库：患者发的消息附带会话ID和时间戳，医生上线后按时间戳拉取增量。如果医生正在另一个房间问诊，可以通过消息队列做异步推送，避免单个连接被大量数据阻塞。
至于健康监测数据，比如可穿戴设备每几秒上报一次心率，这类高频小数据包非常适合走WebSocket。服务端可以设置节流逻辑，按分钟聚合后再写入数据库，既减轻存储压力，也让医生端看到的曲线更平滑。此外，医疗数据属于敏感信息，Socket.IO通道务必开启TLS，连接层可以加上JWT校验，确认每次会话的医生和患者都有对应的有效身份。
四、医疗影像存储与隐私合规的注意事项
远程医疗绕不开影像资料，CT、核磁这类大文件的上传和存储需要单独设计。Node.js处理大文件上传时，建议直接把文件流式写入对象存储，而不是先在服务器内存中拼装完整文件，否则并发上传几个大文件就可能把内存打爆。使用busboy或formidable解析multipart请求，配合流式管道写入，内存占用可以稳定在很低的水平。
隐私合规是医疗系统的一条红线。患者身份信息、病历、处方在数据库中应当加密存储，传输全程走HTTPS和WSS。日志里绝对不能出现明文病历内容，这一点在开发阶段就要用日志脱敏中间件统一处理。另外，建议对问诊视频录制功能做成可选开关，并在录制前获得患者明确同意，录像文件设置较短的保留周期，到期自动删除。
最后是会话稳定性。家庭网络环境复杂，WebRTC断线很常见，前端要监听iceconnectionstatechange事件，在状态变为failed时自动发起ICE restart重新协商；信令层配合Socket.IO自带的断线重连机制，可以保证信令通道的恢复。整体上线前，建议用弱网工具模拟丢包和延迟，充分验证极端情况下医患双方能否正常重连。
总结
用Node.js构建远程医疗系统，核心思路是把实时通信和常规业务分层处理：Express承担REST服务，Socket.IO承担信令与消息，WebRTC承担音视频流，对象存储承担大文件。Node.js在长连接场景下的低资源占用，让这套架构在中小规模部署下具备很好的性价比。开发过程中重点把握信令转发的准确性、消息送达的可靠性以及医疗数据的隐私合规，这三点做好，平台的整体质量就有了保障。