3. 康复设备系统架构风格与模式
康复设备系统通常同时包含实时控制、信号采集、治疗流程管理、患者数据管理、远程运维与第三方扩展等多类职责。把这些职责全部塞进一个“大泥球”式程序，短期能跑，长期必然在安全、升级、认证和扩展上付出代价。架构风格与模式，本质上就是对这些职责的“切分方式”和“连接方式”做出可复用的选择。本节围绕四种常见风格——分层架构、微服务架构、事件驱动架构、插件化架构——说明它们各自解决什么问题、在康复设备中如何落地，以及如何按场景选型。
一、分层架构：把“安全相关”和“业务相关”隔开
分层架构是最贴近康复设备工程现实的一种风格。典型做法是自下而上分为：硬件抽象层（HAL）、实时控制层、设备服务层、业务应用层、人机交互层。层与层之间只允许上层调用下层，禁止反向依赖和跨层直连。这样做的核心价值不是“好看”，而是让安全相关代码（如电刺激电流闭环、电机力矩限制、急停响应）与易变的业务代码（如治疗处方、界面、报表）解耦。
以一台带助力训练和电刺激的上下肢康复机器人为例：HAL 封装编码器、力矩传感器、电流采样 ADC、PWM 输出；实时控制层以 1 kHz 周期执行电流环与速度环，并做力矩上限钳位；设备服务层把“设置助力等级 3”“启动电刺激通道 A”翻译成控制层可执行的指令；业务应用层管理治疗会话、处方参数和患者档案；交互层负责触摸屏与语音提示。若把急停逻辑写在业务层，一旦界面卡顿，安全响应就会被拖累，这正是分层要避免的。
分层的代价是：跨层新增功能需要逐层透传，容易产生“层层转发”的样板代码；对高频数据流（如 1 kHz 力矩采样）不宜层层封装，通常让实时层直接对接采集驱动，仅把降采样后的状态上报给上层。
二、微服务架构：适合“多设备、多院区、多团队”的平台侧
微服务架构把系统拆成独立部署、独立扩缩的服务，通过 HTTP/REST 或 gRPC 通信。它并不适合直接放进设备实时控制回路——网络抖动和进程间通信延迟会破坏确定性。但在康复设备的平台侧，微服务非常合适：患者管理服务、治疗记录服务、设备台账服务、远程升级服务、报表分析服务各自独立，某个服务升级不影响正在治疗的其他设备。
例如，某康复中心有 40 台设备分布在 3 个院区。若采用单体后端，一次报表模块升级需要停机窗口；改为微服务后，报表服务可灰度发布，设备侧只依赖稳定的“治疗记录写入”接口。选型时要重点评估：团队是否有独立部署与可观测性能力（日志、指标、链路追踪），以及是否真的存在独立扩缩需求。若只有 2~3 台设备、1 个团队，微服务带来的运维复杂度往往超过收益。
三、事件驱动架构：让状态变化“广播”而不是“轮询”
事件驱动架构（EDA）中，组件不直接调用彼此，而是发布/订阅事件。康复设备里大量场景天然是事件：治疗开始、治疗暂停、达到目标角度、电流超限、传感器断线、急停触发、治疗结束。采用事件总线后，报警服务、记录服务、界面提示、远程通知可以各自订阅，互不阻塞。
一个典型链路是：实时控制层检测到“力矩持续 200 ms 超过安全阈值”，发布 TorqueLimitExceeded 事件；安全服务订阅后立即执行降功率并置位故障；记录服务写入带时间戳的事件日志；交互层弹出提示并语音播报。这里的关键工程约束是：安全相关事件不能只依赖“最终一致”，必须有本地快速路径兜底，事件总线用于通知与记录，而不是替代硬实时保护。
四、插件化架构：把“疗法扩展”和“第三方算法”变成可插拔模块
插件化架构定义稳定的宿主接口（如 ITrainingMode、IStimulationPattern），具体疗法或算法以插件形式加载。宿主负责生命周期、资源分配和安全边界，插件只实现约定接口。这样，新增一种“镜像疗法训练”或“基于表面肌电的触发式电刺激”时，不必改动核心控制代码，只需按接口实现并注册。
插件化的风险在于接口一旦发布就难以更改，且插件质量参差。工程上通常要求：插件运行在受限沙箱或独立进程；对插件可调用的电流、力矩、时长参数设置硬上限；插件必须通过回归测试集才能上机。插件化最适合“疗法种类多、迭代快、需要第三方生态”的产品线。
五、选型：先看“实时与安全边界”，再看“变化频率”
四种风格并非互斥。康复设备的常见组合是：设备内部用分层架构保证实时与安全；平台侧用微服务支撑多院区；设备与平台之间、设备内部模块之间用事件驱动做状态广播；疗法与算法用插件化扩展。选型时可按以下顺序判断：
- 是否存在硬实时或安全相关回路？有，则实时控制必须落在分层架构的底层，微服务与事件总线不得进入该回路。
- 变化频率最高的是哪一层？疗法种类变化快，优先插件化；平台业务变化快且团队独立，优先微服务。
- 是否存在多个消费者关心同一状态变化？有，则用事件驱动解耦，但安全动作保留本地快速路径。
- 团队规模与运维能力是否匹配？小团队、少设备时，分层 + 插件化通常比微服务更务实。
六、选型对照示例
| 场景 | 首选风格 | 关键理由 | 需规避 |
|---|---|---|---|
| 单机上下肢康复机器人，含电刺激 | 分层 + 插件化 | 实时控制与安全需确定性；疗法需快速扩展 | 把急停逻辑放在业务层或网络侧 |
| 多院区康复设备管理平台 | 微服务 + 事件驱动 | 服务独立部署、灰度发布；状态变化多订阅者 | 让平台服务参与设备实时控制 |
| 肌电触发式电刺激研究样机 | 分层 + 事件驱动 | 信号链实时处理；触发事件广播给记录与提示 | 用事件总线替代硬实时触发路径 |
| 第三方算法接入的评估系统 | 插件化 + 微服务 | 算法沙箱隔离；评估服务独立扩缩 | 插件直接访问底层执行器 |
选型的最终判据不是“哪种架构更先进”，而是“哪种切分方式能让安全边界清晰、让变化被隔离在最小范围内”。在康复设备中，安全与实时永远是第一约束，扩展性与迭代速度是在此约束下的第二目标。把这两条顺序摆正，四种风格就能各归其位、组合使用。