2、系统总体架构设计：端-边-云三层架构、各层职责划分、通信协议选型（MQTT/CoAP/HTTP）
好，我们直接进入正题。这一章聊的是整个系统的骨架——端-边-云三层架构。说白了，就是决定你的医疗设备数据怎么跑、指令怎么下、升级包怎么推。我见过不少团队，一上来就撸代码，结果后面发现协议选错了、边界划不清，整个项目推倒重来。嗯，咱们先把地基打牢。
2.1 为什么是三层？不是两层，也不是四层？
你可能会问：直接设备连云端不行吗？非要中间加个“边”？
我举个例子。一台ICU的呼吸机，每秒钟产生上百条波形数据。如果全部直连云端，先不说带宽够不够，万一网络抖动一下，数据丢了怎么办？更关键的是——延迟。有些报警需要毫秒级响应，云端绕一圈回来，黄花菜都凉了。
所以，三层架构的核心逻辑是：端做采集与控制，边做实时处理与缓存，云做汇聚与分析。各司其职，互不干扰。
核心原则：端侧只做最必要的事，边侧扛住实时性压力，云侧负责全局管控。千万别让端侧干云的活，也别让云侧管端的实时中断。
2.2 各层职责划分
2.2.1 端侧（设备层）
端侧就是你的医疗设备本体——监护仪、输液泵、除颤仪等等。它的职责其实很纯粹：
- 数据采集：传感器读数、设备状态、运行日志。注意，这里只做原始数据的打包，不做复杂分析。
- 本地控制：接收边侧或云端的指令，执行参数调整、紧急停机等操作。
- 固件升级执行：接收升级包，校验签名，写入Flash，回滚失败版本。
我个人习惯，在端侧会保留一个“最小安全模式”。万一网络断了、边侧挂了，设备还能按最后一套安全参数独立运行。我在项目中遇到过，有一次边侧服务器宕机，所有输液泵差点失控，幸亏端侧有本地兜底逻辑。
避坑指南：端侧不要做OTA升级的“全量校验”。我曾经见过一个团队，升级包10MB，端侧校验花了3分钟，结果设备在这期间无法响应任何指令。正确的做法是：边侧先做哈希校验，端侧只做签名验证。
2.2.2 边侧（边缘层）
边侧是整个架构的“腰部”。它扛着实时性、可靠性和带宽优化的重任。
- 实时数据处理：比如心电信号的异常波形检测，必须在几十毫秒内完成。云端做不到，端侧算力不够，边侧最合适。
- 协议转换与数据缓存：端侧可能用CoAP或私有协议，边侧统一转换成MQTT或HTTP再上云。同时，边侧要缓存最近24小时的数据，防止网络中断导致数据丢失。
- 升级包分发与策略管理：云端把升级包推给边侧，边侧再按设备批次、地理位置、在线状态，分批下发。说白了，边侧是升级任务的“调度员”。
你想想看，如果每台设备都直接去云端拉升级包，云端压力多大？而且万一升级包有问题，边侧可以立刻暂停下发，避免“全军覆没”。
2.2.3 云侧（平台层）
云侧是大脑，负责全局视角的事情。
- 设备管理与注册：每台设备上线、下线、固件版本、地理位置，云侧都要记录。
- 固件版本管理与发布：灰度发布、AB测试、强制升级策略，都在云侧配置。
- 大数据分析与报表：所有设备的历史数据汇聚到云侧，做趋势分析、故障预测。
- 远程运维接口：给医院IT或厂商运维人员提供Web界面或API，查看设备状态、触发升级。
注意：云侧绝对不能直接控制设备。所有控制指令必须经过边侧转发。为什么？安全。云侧被攻破，最多影响策略下发；如果云侧能直控设备，那一旦被入侵，所有设备都可能被远程操控。这是医疗设备安全的大忌。
2.3 通信协议选型：MQTT / CoAP / HTTP
协议选型，说白了就是看你的设备“穷不穷”、“急不急”、“稳不稳”。
| 协议 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| MQTT | 端→边、边→云的数据上报与指令下发 | 轻量、支持QoS、双向通信、持久连接 | 依赖TCP，弱网环境可能断连 |
| CoAP | 端侧资源受限设备（如传感器节点） | 基于UDP，极轻量，适合低功耗 | 可靠性不如MQTT，需要自己实现重传 |
| HTTP/HTTPS | 云侧管理接口、固件包下载 | 成熟、调试方便、安全（HTTPS） | 头部开销大，不适合高频实时通信 |
2.3.1 MQTT——我个人的首选
在医疗设备场景下，MQTT是我用得最多的协议。为什么？因为它支持发布/订阅模式，天然适合设备状态上报和远程指令下发。而且QoS等级可以灵活选择：
- QoS 0：最多发一次，适合心跳包、非关键日志。
- QoS 1：至少发一次，适合报警事件、状态变更。
- QoS 2：恰好发一次，适合固件升级指令、参数设置。
我建议，端侧到边侧用MQTT over TLS，边侧到云侧用MQTT over TCP（内网环境可以省掉TLS开销）。
实战经验：MQTT的遗嘱消息（Last Will）一定要用。设备突然掉线时，边侧能立刻感知，触发备用策略。我曾经因为没配遗嘱，一台输液泵断线后，边侧还以为它在线，继续下发指令，结果导致药物输注异常。
2.3.2 CoAP——给“穷”设备准备的
如果你的设备是电池供电的传感器节点，或者MCU只有几十KB的RAM，那MQTT可能太重了。这时候CoAP是更好的选择。
CoAP基于UDP，头部只有4字节。它支持GET/POST/PUT/DELETE，跟HTTP很像，但轻量得多。不过要注意，CoAP的可靠性需要自己实现——比如用CON（确认）消息和重传机制。
我在一个病房环境监测项目中用过CoAP。温度传感器每5秒上报一次数据，用CoAP + DTLS加密，电池续航从3个月延长到了8个月。嗯，这就是轻量协议的价值。
2.3.3 HTTP/HTTPS——管理接口的标配
HTTP主要用在云侧的管理接口和固件包下载。原因很简单：
- 调试方便，curl一把梭。
- HTTPS的证书体系成熟，适合安全传输。
- 支持断点续传，适合大文件下载（比如固件包）。
但注意，不要在端侧用HTTP做实时数据上报。头部开销太大，而且HTTP是请求-响应模式，服务器没法主动推数据给设备。除非你配合WebSocket，但那又增加了复杂度。
避坑指南：固件包下载一定要用HTTPS + 断点续传。我曾经见过一个团队，用HTTP下载升级包，结果网络波动导致下载到一半失败，设备进入“半砖”状态。后来改成HTTPS + Range请求，问题解决。
2.4 协议组合推荐
在实际项目中，我通常这样组合：
- 端→边：MQTT（数据上报）+ CoAP（低功耗传感器）
- 边→云：MQTT（实时数据）+ HTTP（固件包拉取）
- 云→边：MQTT（指令下发）+ HTTP（管理API）
你想想看，这样分层之后，每一层的协议都是最合适的。端侧不用操心HTTPS的握手开销，云侧不用处理UDP的丢包重传。各层各司其职，系统才稳定。
总结一句话：端侧做减法，边侧做缓存与调度，云侧做聚合与管控。协议选型跟着场景走，别为了技术而技术。
好，这一章就到这里。下一章我们聊具体的固件升级流程设计——从打包、签名、分发到回滚，每一步都有坑。到时候我把我踩过的坑都抖出来。