4. 平台总体架构设计

医学影像标注平台与普通 Web 系统最大的差别在于：它同时承载“人机交互密集”的标注操作和“计算密集”的影像处理与推理任务。一次 CT 序列标注，前端要流畅渲染数百张切片，后端要完成 DICOM 解析、窗宽窗位变换、分割结果存储与版本管理，还可能触发 AI 预标注。若把渲染、业务逻辑、影像计算、任务调度全部塞进一个单体应用，任何一处阻塞都会拖垮整个平台。因此总体架构设计的第一原则是：按“变化频率”和“资源特征”拆分，而不是按页面拆分。

前后端分离：把渲染压力留在浏览器，把数据一致性留在服务端

前端采用 SPA 架构，负责影像渲染、标注交互、图层管理与快捷键响应；后端只提供 REST/JSON 业务接口与 WebSocket 实时通道。影像像素数据不走业务接口，而是由前端通过预签名 URL 直连对象存储或影像网关拉取，避免大流量穿透业务服务。典型交互如下：

GET  /api/v1/studies/{studyUid}/series        → 返回序列元数据（JSON）
GET  /api/v1/series/{seriesUid}/frames?ww=400&wc=40
     → 返回窗宽窗位变换后的帧索引或瓦片地址
WS   /ws/tasks/{taskId}                        → 推送标注进度、AI 预标注完成事件
PUT  /api/v1/annotations/{annotationId}        → 提交标注结果（含版本号，乐观锁）

前端提交标注时必须携带 version 字段，服务端用乐观锁校验，防止两名医生同时修改同一病灶导致覆盖。这是前后端分离后必须显式处理的并发问题。

微服务与模块划分

平台按业务能力划分为若干微服务，每个服务独立部署、独立扩缩容：

• 影像服务（imaging-service）：DICOM 解析、序列管理、窗宽窗位变换、缩略图与瓦片生成，是 CPU/IO 密集型，需独立扩容。
• 标注服务（annotation-service）：标注对象 CRUD、版本管理、几何校验（如多边形自交检测）、标注状态机。
• 任务服务（task-service）：任务分配、领取、超时回收、进度统计，是标注流程的调度中枢。
• AI 推理服务（inference-service）：调用分割/检测模型生成预标注，GPU 资源独立，与业务服务隔离。
• 用户与权限服务（auth-service）：账号、角色、数据权限（按项目/科室隔离）。
• 审计服务（audit-service）：记录谁在何时修改了哪条标注，满足医疗数据合规要求。

服务之间通过消息队列解耦：标注提交后发事件，审计服务与统计服务异步消费，不阻塞主链路。影像服务与推理服务之间用对象存储传递中间结果，避免大文件走 RPC。

数据流与任务流

平台有两条主链路，必须分开设计。第一条是数据流：影像上传 → DICOM 解析 → 生成瓦片与元数据 → 写入对象存储与关系库 → 前端按需拉取。这条链路是“读多写少、大文件、可缓存”的，适合用 CDN 或边缘缓存加速。第二条是任务流：创建标注任务 → 分配/领取 → 标注中 → 提交 → 审核 → 完成/打回。这条链路是“状态驱动、强一致、需审计”的，适合用状态机加数据库事务保证。

两条链路在“标注提交”处交汇：提交时标注服务写入结果并发布事件，任务服务消费事件更新任务状态，审计服务记录操作，统计服务刷新进度。若 AI 预标注开启，推理服务在任务创建后异步生成预标注，通过 WebSocket 通知前端加载，医生在此基础上修改，可显著减少勾画时间。

可扩展性与高可用设计原则

可扩展性方面，遵循三条原则：其一，无状态服务，业务服务不保存会话，会话放 Redis，任意实例可处理任意请求，便于水平扩容；其二，计算与业务分离，影像解析和 AI 推理可独立扩容 GPU/CPU 节点，不影响标注业务；其三，接口版本化，/api/v1/ 与 /api/v2/ 并存，前端可灰度升级。

高可用方面，关键措施包括：网关层多实例加健康检查，故障实例自动摘除；数据库主从加读写分离，标注写入走主库，统计查询走从库；对象存储多副本，影像不丢失；消息队列持久化，消费者失败可重投；任务服务对超时未提交的任务自动回收并重新分配，避免任务卡死。对于标注这种“人参与”的流程，还需设置任务锁：同一任务同一时刻只允许一名标注员持有，锁带 TTL，超时自动释放。

综上，总体架构的核心不是堆砌技术名词，而是让“影像读取、标注写入、任务调度、AI 计算”四类负载各得其所：前端承担渲染，业务服务承担一致性，计算服务承担算力，消息队列承担解耦。这样平台才能在标注量增长、并发医生增多、AI 模型迭代时保持稳定与可扩展。