3. DCT平台总体架构设计
去中心化临床试验（DCT）平台要同时承载受试者远程访视、电子知情同意、ePRO/eCOA 量表、可穿戴设备数据采集、药物直达配送、远程监查与稽查留痕等业务。这些业务在合规、时延、数据敏感度和可用性上的要求差异极大，因此总体架构不能是单体应用的简单堆叠，而应以微服务与模块化为骨架、以云原生为运行底座、以多租户为隔离边界，并用清晰的数据流与集成架构把院内系统、设备、第三方物流和监管申报串起来，最后用高可用与灾备策略和架构决策记录（ADR）把设计意图固化下来。
微服务与模块化：按业务能力切分，而非按技术分层
切分的第一原则是“业务能力边界”，而不是“技术分层”。DCT 平台可划分为若干核心服务：受试者身份与同意服务（Consent）、访视与日程服务（Visit）、ePRO/eCOA 采集服务、设备接入与数据规范化服务、随机化与药物供应服务（IRT/RTSM）、安全事件与 SAE 上报服务、监查与稽查服务、通知与消息服务、审计与合规服务。每个服务拥有独立的数据存储与独立部署单元，服务之间只通过明确定义的接口通信。
模块化的关键约束是数据所有权唯一：受试者主数据只属于受试者服务，其他服务通过 ID 引用而非复制全量字段。例如 ePRO 服务只保存 subject_id、访视 ID 和量表作答，不保存受试者姓名与联系方式；需要发送提醒时，由通知服务通过受试者服务获取脱敏后的联系渠道。这样既满足最小必要原则，也避免跨服务的数据不一致。
服务间通信采用“同步查询 + 异步事件”混合模式：需要即时返回的（如访视签到校验）走 REST/gRPC 同步调用；状态变更类（如同意书签署完成、SAE 上报、药物发运）走事件总线发布领域事件，由订阅方异步消费。事件必须携带 tenant_id、subject_id、event_time 和幂等键，保证可追溯与可重放。
云原生原则：声明式、可观测、可弹性
云原生不是“上云”本身，而是四条可执行原则。第一，声明式交付：所有服务以容器镜像 + Kubernetes 清单（Deployment、Service、HPA、NetworkPolicy）描述，环境差异通过 ConfigMap/Secret 注入，禁止手工登录节点改配置。第二，无状态优先：应用实例不保存会话，会话与文件落到 Redis 和对象存储，使 Pod 可随时重建。第三，可观测性内建：每个服务暴露 /healthz、/readyz 与 Prometheus 指标，日志统一结构化输出 trace_id，链路追踪覆盖跨服务调用。第四，弹性与自愈：按 CPU/队列深度配置 HPA，配合 PodDisruptionBudget 与就绪探针，滚动升级期间不中断访视提交。
一个可参考的部署参数示例（属教学假设）：ePRO 采集服务常态 3 副本，HPA 在 CPU 超过 65% 时扩至最多 12 副本；数据库连接池每副本上限 20，避免扩容时打爆数据库连接数。这类参数必须在压测后回填到 ADR 中，而不是凭经验拍定。
多租户设计：隔离级别要与数据敏感度匹配
DCT 平台天然多租户：每个申办方、每个临床试验（study）都是独立租户。隔离有三个层次，应按数据敏感度选择而非一刀切。共享库共享表 + tenant_id 行级隔离成本最低，适合配置类数据；共享库独立 Schema 适合中等隔离需求；独立数据库实例适合涉及基因数据或跨境传输的高敏感研究。无论哪一层，都必须在数据访问层强制注入 tenant_id 过滤，并在数据库启用行级安全策略（RLS）作为第二道防线，防止应用层漏写条件导致越权。
租户上下文应通过网关解析 JWT 中的 tenant_id 与 study_id 后透传，服务不得信任请求体中的租户字段。密钥管理按租户隔离 KMS 密钥，审计日志按租户分索引，确保某租户的稽查导出不会看到其他租户数据。
数据流与集成架构
DCT 平台的数据来源分散：受试者手机 App、可穿戴设备、院内 EDC/EMR、中心实验室、药物配送商、监管申报网关。集成架构的核心是“接入层归一化、主数据统一、出站可审计”。设备与第三方数据先进入接入层，完成协议适配（HL7/FHIR、CSV、MQTT）、单位换算、时间戳统一为 UTC 并保留原始时区，再写入原始数据湖；经校验与去重后进入业务库，供监查与统计使用。所有出站数据（如向 EDC 传输、向监管提交）必须记录数据版本、传输时间与接收确认，形成可回溯链路。
高可用与灾备策略
DCT 平台的可用性目标应分级定义：受试者提交 ePRO 与 SAE 上报属于关键路径，目标可用性 99.95%，RTO≤5 分钟、RPO≈0；监查报表与统计导出可放宽到 99.9%、RTO≤4 小时。实现手段上，同城双可用区部署 + 数据库同步复制保证单机房故障自动接管；异地灾备采用异步复制与每日快照，用于区域性灾难。必须强调：灾备不是备份，备份解决误删与逻辑损坏，灾备解决基础设施级故障，两者都要有，且每季度至少做一次真实切换演练并记录实际 RTO。
架构决策记录（ADR）
架构决策记录把“为什么这样设计”写成可追溯的短文档，避免半年后无人能解释某个约束的来源。每条 ADR 建议包含：编号与标题、状态（提议/已接受/已废弃/被替代）、背景与问题、决策、备选方案、后果（正面与负面）、关联需求或法规条款。例如“ADR-007：ePRO 服务采用事件驱动写入数据湖”会记录：选择异步事件是为了削峰并保留原始数据，代价是引入最终一致性，因此监查页面必须显示数据同步时间戳。ADR 应纳入版本库随代码评审，被替代时保留历史而非删除。