4. 平台总体架构设计

eCOA（electronic Clinical Outcome Assessment，电子临床结局评估）平台承载受试者自评、研究者他评、访视计划、量表逻辑校验、稽查轨迹与法规合规等关键能力。它既要满足临床试验对数据完整性与可追溯性的严格要求，又要在多中心、多时区、多语言环境下保持稳定可用。因此总体架构不能只追求“能跑起来”，而要在分层边界、服务拆分、前后端契约、部署拓扑与高可用策略上做出可验证的设计决策。本节围绕这四条主线展开，并给出可直接参考的架构骨架与关键参数示例。

一、分层架构：把变化隔离在可控边界内

推荐采用五层结构：接入层、应用层、领域服务层、数据层与基础设施层。接入层负责 TLS 终止、WAF、限流与路由；应用层承载 BFF（Backend for Frontend）与 API 网关，处理鉴权、审计埋点与协议转换；领域服务层按业务能力拆分，如受试者管理、访视计划、量表引擎、稽查与合规；数据层区分事务库、审计库、对象存储与缓存；基础设施层提供容器编排、服务网格、密钥管理与可观测性。分层的核心价值是：当量表版本升级或监管要求变化时，改动被限制在领域服务层与配置层，接入层与数据访问方式保持稳定。

层间调用应遵循“上层依赖下层抽象、同层通过接口通信”的原则。例如量表引擎不直接读取受试者表，而是通过受试者服务暴露的 gRPC 接口获取受试者标识与访视上下文；审计服务以事件订阅方式接收各领域服务发布的领域事件，避免在业务事务中同步写审计库造成耦合。

二、微服务与模块化：按业务能力而非技术分层拆分

微服务拆分最容易犯的错误是按“控制器/服务/DAO”技术分层拆，导致一次业务变更跨多个服务。正确做法是按限界上下文拆分：受试者与访视、量表与评分、稽查与合规、通知与提醒、报表与导出。每个服务拥有独立数据库 schema，禁止跨服务直连数据库。服务间同步调用用于强一致场景（如访视创建时校验受试者状态），异步事件用于最终一致场景（如评分完成后触发稽查记录与统计更新）。

模块化不仅体现在服务边界，也体现在服务内部。以量表引擎为例，内部可划分为量表定义解析、题目渲染、逻辑校验、评分计算四个模块，模块之间通过明确的输入输出契约交互。这样即使未来将量表引擎独立为单独服务，内部模块也可平滑迁移。

三、前后端分离：契约先行与多端一致

前后端分离的关键不是“前端用 React、后端用 Spring Boot”，而是接口契约的稳定性与可演进性。建议采用 OpenAPI 3.0 定义 REST 接口，gRPC 定义内部服务接口，前端通过 BFF 聚合多个领域服务，避免前端直接调用多个微服务造成耦合。BFF 负责将领域模型转换为前端视图模型，例如将“受试者 + 访视 + 量表状态”聚合为一个访视卡片对象，减少前端编排逻辑。

前端应支持受试者端（移动 Web/App）、研究者端（桌面 Web）与监查端（平板）三种形态，但共享量表渲染组件与逻辑校验规则。量表逻辑校验规则建议以 JSON Schema 或 DSL 形式由后端下发，前端执行即时校验，后端在提交时再次校验，确保“前端体验好、后端守底线”。

四、云原生部署与高可用设计

部署采用 Kubernetes 集群，按环境划分命名空间：dev、test、uat、prod。每个微服务以 Deployment 形式部署，配置 HPA（Horizontal Pod Autoscaler）基于 CPU 与自定义指标（如请求队列长度）扩缩容。数据库采用主从复制 + 只读副本，写走主库、读走副本；缓存使用 Redis Cluster，会话与热点量表定义缓存其中。对象存储用于存放量表附件与导出文件，开启版本控制与跨区域复制。

高可用设计需覆盖三个层面：无状态服务多副本、有状态数据主从切换、跨可用区部署。关键参数示例：生产环境每个服务至少 3 副本，跨 3 个可用区分布；数据库主库位于可用区 A，同步复制到可用区 B，异步复制到可用区 C；Redis 采用 3 主 3 从，开启 AOF 持久化。健康检查区分 liveness 与 readiness，readiness 探针检查数据库连接与依赖服务可达性，避免流量打入未就绪实例。

五、关键设计决策与验证方式

架构设计完成后，需要用可验证的方式确认其有效性。建议从三个维度验证：第一，故障注入测试，随机终止一个领域服务 Pod，观察请求是否在 30 秒内自动恢复且无数据丢失；第二，跨可用区切换演练，模拟可用区 A 不可用，确认数据库主库切换与 Redis 故障转移在 60 秒内完成；第三，契约兼容性测试，在 OpenAPI 规范变更后运行消费者驱动契约测试，确保前端 BFF 与领域服务接口不破坏现有调用。

以下为生产环境关键参数参考表（示例值，需根据实际压测结果调整）：

综上，eCOA 平台的总体架构应以分层隔离变化、以微服务拆分业务能力、以契约先行保障前后端协作、以云原生与多可用区部署支撑高可用。架构不是一次性设计，而是随监管要求、量表复杂度和受试者规模持续演进的过程。建议每季度回顾一次服务边界与容量指标，结合故障演练结果调整副本数与扩缩容阈值，使平台在合规与稳定之间保持平衡。