4. 平台总体架构设计
远程医疗会诊平台的总体架构，决定了系统能否同时承载“实时音视频会诊、医学影像调阅、电子病历共享、多方协同标注、会诊过程留痕”等多类业务。它不是一个单纯的技术选型问题，而是要在业务隔离、故障边界、扩容成本、运维复杂度之间取得平衡。本节围绕分层架构、微服务与单体架构对比、高可用设计、可扩展性与容灾架构四条主线展开，并给出可落地的设计判断依据。
一、分层架构：把“会诊一次”拆成可独立演进的层
推荐采用五层结构，自下而上依次为：基础设施层、数据层、服务层、接入层、应用层，并叠加贯穿各层的安全与运维体系。
- 基础设施层：机房/云可用区、Kubernetes 集群、GPU 节点（用于影像 AI 预处理）、专线或 VPN 通道。
- 数据层：关系库（会诊申请、排班、用户权限）、对象存储（DICOM 影像、会诊录像）、缓存（Redis，存放会诊房间状态与令牌）、消息队列（Kafka，承载会诊事件与转码任务）。
- 服务层：按业务域拆分的微服务，如会诊调度、音视频信令、影像调阅、病历交换、消息通知、审计留痕。
- 接入层：API 网关、WebSocket 网关、SIP/WebRTC 信令接入，统一鉴权、限流、路由。
- 应用层：医生端、基层申请端、专家端、管理后台，通过统一 SDK 调用下层能力。
分层的价值在于依赖单向：上层可调用下层，下层不反向依赖上层。例如影像调阅服务只依赖对象存储与索引库，不感知前端是 Web 还是移动端，从而在终端形态变化时无需改动核心服务。
二、微服务与单体架构对比：不是越“微”越好
会诊平台早期若直接上微服务，往往被服务发现、链路追踪、分布式事务拖慢交付。更务实的做法是按业务变化频率与伸缩需求决定拆分粒度。
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署单元 | 一个进程/镜像 | 每服务独立镜像 |
| 扩容方式 | 整体复制，资源浪费 | 按服务横向扩容 |
| 故障影响 | 一处异常可能全站不可用 | 故障隔离在单服务 |
| 数据一致性 | 本地事务，简单可靠 | 需 Saga/最终一致 |
| 适用阶段 | 业务未定型、团队小 | 业务域清晰、团队可独立交付 |
建议的拆分边界是：音视频信令、影像调阅、会诊调度三类服务优先独立，因为它们对 CPU/带宽/存储的需求差异极大；而“用户与权限”“字典配置”可先合并在一个基础服务中，避免过早碎片化。判断标准可以量化为：若某模块的峰值 QPS 与主站相差 5 倍以上，或需要独立发布节奏，就具备拆分条件。
三、高可用设计：消除单点，明确降级路径
高可用的核心是无单点 + 可降级 + 可观测。具体做法包括：
- 接入层部署多实例，前置负载均衡，健康检查间隔 5s、失败 3 次摘除。
- 数据库采用主备 + 只读副本，主库故障时由哨兵或编排组件在 30s 内切换。
- Redis 使用哨兵或集群模式，会诊房间状态写入时设置 TTL，避免脏状态长期占用。
- 音视频媒体服务器按区域部署，单区域故障时信令层将会诊重定向至备用区域。
- 关键依赖（如第三方短信、CA 签名）配置熔断与本地缓存，超时阈值建议 800ms～1.5s。
四、可扩展性与容灾架构：从“能扩”到“敢切”
可扩展性分为垂直扩展（提升单机规格）与水平扩展（增加实例）。会诊平台应优先水平扩展，并把无状态服务与有状态组件分开处理：应用服务无状态，可随流量增减副本；媒体服务器、数据库、对象存储属于有状态，需按分区或主从方式扩展。
容灾按能力分为三个等级，建议核心会诊业务至少达到同城双活：
- 备份恢复：RTO 数小时，RPO 分钟级，适合非核心报表。
- 同城双活：两可用区同时承载流量，RTO 分钟级，RPO 接近 0，适合会诊调度与信令。
- 异地容灾：跨城市部署，RTO 30 分钟内，RPO 秒级，适合影像归档与审计数据。
下面用一张架构关系图，把分层、服务拆分、双活与容灾切换路径放在同一视图中，便于对照理解。
五、落地时的关键判断
架构设计最终要落到可验证的指标上。建议在方案评审时明确以下参数：
- 可用性目标：核心会诊链路年可用性 ≥ 99.9%，即全年不可用不超过约 8.76 小时。
- 扩容触发线：单服务 CPU 持续 5 分钟超过 65%，或 P95 响应时间超过 500ms，触发自动扩容。
- 容灾演练：每季度执行一次可用区切换演练，记录实际 RTO/RPO，与设计值偏差超过 20% 时需复盘。
- 数据保留：会诊录像与影像按规范保留，对象存储启用版本控制与生命周期策略，避免误删。
综上，远程医疗会诊平台的总体架构应以分层明确依赖方向，以业务域驱动微服务拆分，以无单点和降级保障高可用，以同城双活加异地容灾支撑可扩展与容灾目标。架构不是一次画完的图，而是随业务量、团队规模和合规要求持续调整的工程决策。