4. 平台总体架构设计
健康档案平台承载的是居民全生命周期健康数据，既要支撑院内诊疗、公卫随访、体检、免疫接种等多源数据的汇聚，又要满足高并发查询、跨机构调阅、隐私合规与长期演进。因此总体架构不能只回答“用什么技术”，而要回答“哪些能力放在哪一层、哪些服务独立部署、哪些组件依赖云原生能力弹性伸缩”。本节围绕分层架构、微服务拆分与云原生基础设施三条主线，说明它们在健康档案平台中的落地方式与选型依据。
一、分层架构：把“数据、服务、接入、渠道”分开
健康档案平台推荐采用五层结构：基础设施层、数据资源层、服务能力层、应用接入层与渠道展现层。分层的核心价值是依赖单向、职责收敛：上层只能调用下层暴露的接口，同层之间尽量不直接互调，避免“档案服务直接读体检库”这类跨层耦合。
基础设施层提供容器编排、服务网格、配置中心、日志与监控；数据资源层负责主索引（EMPI）、档案主库、临床文档库（CDR）、对象存储与检索索引；服务能力层是微服务的集中地，包括患者主索引服务、档案聚合服务、文档解析服务、授权与同意服务、审计服务等；应用接入层提供统一 API 网关、鉴权、限流与协议转换；渠道展现层面向医生工作站、居民端、公卫系统与第三方调阅。这样划分后，新增一个“慢病随访档案视图”只需在服务能力层增加聚合逻辑，不必改动数据层与渠道层。
二、微服务拆分：按“业务能力”而非“技术分层”切
微服务拆分最容易犯的错误是按技术分层切，例如“查询服务、写入服务、缓存服务”，结果每个业务变更都要改多个服务。健康档案平台应按业务能力拆分，并遵循“高内聚、低耦合、数据自治”原则。以下是一组可落地的服务边界示例：
| 服务 | 核心职责 | 数据归属 | 典型接口 |
|---|---|---|---|
| 患者主索引服务 | 身份匹配、合并、交叉索引 | EMPI库 | POST /empi/match |
| 档案聚合服务 | 按时间轴组装居民档案视图 | 只读CDR+缓存 | GET /archive/{id} |
| 文档解析服务 | CDA/PDF解析、结构化抽取 | 对象存储+解析结果 | POST /doc/parse |
| 授权与同意服务 | 调阅授权、患者同意书管理 | Consent库 | POST /consent/check |
| 审计服务 | 全量调阅行为留痕 | 审计库（只写） | POST /audit/log |
拆分后要处理两个关键问题。其一是分布式事务：档案聚合服务需要同时读取多个来源，不应使用强事务，而应采用最终一致性——通过消息队列接收各业务系统的档案变更事件，异步更新CDR，聚合服务只读本地视图。其二是服务粒度：初期不宜拆得过细，建议先按上述5～8个服务落地，待团队与运维能力成熟后再细分。例如“文档解析”与“结构化抽取”可先合并，避免跨服务调用链过长。
三、云原生选型：弹性、可观测与可迁移
云原生不是“上Kubernetes”这么简单，健康档案平台需要重点评估四类能力：
- 容器编排：Kubernetes 负责服务部署、滚动升级与故障自愈。档案查询服务在上午门诊高峰QPS可达平峰的5～8倍，通过HPA按CPU与自定义指标（如请求队列长度）自动扩缩容。
- 服务网格：Istio或Linkerd提供mTLS、流量灰度与熔断。跨机构调阅涉及外部网络，网格层可统一做双向认证，避免每个服务重复实现。
- 可观测性：Prometheus采集指标、Loki收集日志、Jaeger做链路追踪。健康档案调阅链路长，必须能定位“是网关慢、聚合服务慢，还是CDR查询慢”。
- 配置与密钥：配置中心管理不同院区的差异化参数，密钥管理服务托管数据库口令与接口证书，禁止硬编码。
四、选型决策：什么情况下用哪种组合
架构选型要结合建设阶段与约束条件。以下给出三种典型场景的判断依据：
| 场景 | 推荐架构组合 | 关键理由 |
|---|---|---|
| 区域级平台，多机构接入，高并发 | 五层分层 + 微服务 + 托管K8s + 服务网格 | 需要弹性伸缩、跨机构安全通信与统一治理 |
| 单体医院院内档案，规模中等 | 分层架构 + 模块化单体 + 容器化部署 | 微服务收益不足以抵消运维复杂度，先保证交付 |
| 已有多个业务系统，需快速整合 | 分层 + API网关 + 少量核心微服务 | 以集成和协议转换为主，避免大规模重构 |
无论选择哪种组合，都应坚持三条底线：数据分层不跨层直连、服务接口版本化、所有调阅行为可审计。健康档案涉及个人敏感信息，架构设计必须把授权、同意与审计作为一等公民，而不是事后补丁。只有把分层边界、服务边界与云原生治理能力同时设计清楚，平台才能在数据量增长、机构接入增多和合规要求变化时保持可演进。