远程医疗系统的四层架构

远程医疗系统的四层架构从基础层到应用层的完整拆解不是微服务概念图。是一个踩了坑、跑了业务的真实架构。一、先看全貌远程医疗系统不是装个摄像头就能看病。它是一个跨终端、跨网络、跨机构的完整平台。经过多轮迭代最终定下来的是四层架构┌──────────────────────────────────────────────┐ │ 应用层 │ │ 患者端(APP/H5/小程序) 医生APP 内网PC端 │ │ 决策分析平台 配置管理平台 │ ├──────────────────────────────────────────────┤ │ 支撑层 │ │ 视频通话 语音 身份验证 角色权限 加解密 │ │ 文件存储 数据签名 短信 报表 AI 监控 │ ├──────────────────────────────────────────────┤ │ 数据层 │ │ 达梦/KingBase/MySQL 远程就诊库 共享库 │ │ 分布式文件系统 │ ├──────────────────────────────────────────────┤ │ 基础层 │ │ WindowsServer/Linux 网络/安全/主机 │ └──────────────────────────────────────────────┘ 两侧竖线接口技术规范 运行管理制度四层12 个支撑服务3 种终端。下面逐层拆解为什么这样分。二、基础层信创不是口号是真要跑在上面基础层决定了整个系统能跑在什么环境上。操作系统Windows Server Linux 双轨。Windows 跑 .NET 遗留服务Linux 跑新服务。不是技术偏好是历史包袱。硬件网络设施、安全设施、主机服务器——政务/医疗系统的标配三层防火墙隔离内外网前置机做数据交换应用服务器集群抗并发。设计决策基础层不绑定任何具体厂商。操作系统的选择由上层服务的运行时决定反过来不行。三、数据层三库一系统国产化是硬约束数据层的设计有一个绕不开的前提核心库必须是国产数据库。三库数据库用途为什么选它达梦 / KingBase核心业务库就诊记录、处方、结算信创要求必须国产MySQL辅助业务日志、配置、缓存表轻量运维成本低远程就诊信息库就诊过程的音视频元数据独立库不污染业务库医疗信息共享库跨机构数据交换转诊、会诊独立实例权限隔离分布式文件系统音视频文件、影像文件、电子签名文件——不上数据库用分布式文件存储。MinIO 或自建 DFS配合 CDN 加速。设计决策库里存路径文件系统存文件。解耦之后数据库的体积不会因为存了视频而膨胀。四、支撑层12 个服务拆的原则是独立变更支撑层是系统的发动机。12 个服务每个只做一件事核心业务服务服务职责对应的已有文章视频通话服务WebRTC 流管理 信令控制远程帮办 WebRTC 信令服务器语音服务语音输入、TTS 播报RAG 客服前端身份验证服务登录、人脸识别、实名认证Agent 系列的人脸核验远程手术服务手术过程的实时视频 设备数据同步高带宽、低延迟专用基础能力服务服务职责角色权限服务患者、医生、管理员三套权限模型加解密服务SM2/SM4 国密算法信创合规数据签名服务电子处方、诊断报告的不可否认性短信平台服务预约提醒、报告通知支撑类服务服务职责报表服务运营数据、监管报表医疗 AI 服务辅助诊断、影像分析运行监控服务所有服务的健康检查、告警分布式文件存储服务MinIO / DFS 的抽象封装设计决策12 个服务不是拍脑袋拆的。原则是——如果两个功能会因为不同的原因而改就拆开。视频服务和 AI 服务不放在一起因为视频升级和 AI 模型升级的触发条件完全不同。五、应用层三端分离各自有独立入口患者端APP / H5 / 小程序患者用的前端。三种形态并行APP 功能全、H5 免安装、小程序方便转发。核心功能预约挂号、在线就诊、查看报告、缴费。医生 APP医生端的独立应用。患者端不能看到医生端的排班、会诊、处方审批等功能。权限隔离在应用层就做了不依赖支撑层防。内网 PC 端应用医院内部管理端。药品管理、科室管理、统计报表、系统配置。这个端只能在医院内网访问外网不可达。两个管理平台平台给谁用决策分析平台院领导看数据大屏——就诊量、满意度、收入趋势配置管理平台运维人员配业务规则——科室排班、号源分配、流程配置六、两条竖线标准和制度写在架构里架构图两侧画了两条竖线不是装饰。是提醒没有规范和运维系统跑不久。接口技术规范所有支撑服务对外暴露统一的 RESTful API。入参出参格式有规范版本号管理有规范认证 Token 格式有规范。不守规范的服务不给上线。运行管理制度运维不是开发的事后补丁是架构阶段就要考虑的。包括数据备份策略全量 增量 异地日志保留周期业务日志 6 个月操作日志 3 年应急演练流程网络中断、数据库宕机、存储满版本发布窗口每周三凌晨 2:00-4:00七、为什么是四层不是三层也不是五层三层基础→业务→应用太粗——数据层和支撑层混在一起信创数据库替换时炸一片服务。五层太细——加一层网关层或中间件层没有必要。系统的并发量不需要独立的 API 网关做限流Nginx 就够了。四层的取舍逻辑基础层独立因为硬件和 OS 的变更频率最低跟上层解耦数据层独立因为国产数据库是硬约束独立出来方便替换和迁移支撑层独立因为 12 个服务各自独立变更互不阻塞应用层独立因为三端患者/医生/内网的用户、权限、UI 完全不同每一层有一个独立的变更原因。这就是分层的第一性原理。八、总结这篇文章不是讲远程医疗的业务。是讲当一个系统要同时满足信创合规、多终端接入、实时音视频、AI 辅助诊断时怎么分层、怎么拆服务、怎么在架构阶段就把运维和规范考虑进去。