236 lines
13 KiB
Markdown
236 lines
13 KiB
Markdown
# 技术中台 模块规划
|
||
|
||
---
|
||
|
||
## 1. 模块定位
|
||
|
||
技术中台是整个医养平台的**技术基础设施层**，负责为所有业务系统提供统一的微服务架构、医疗互联互通协议（HL7/FHIR）、API网关治理、消息队列、区块链存证和国密安全加密等基础技术能力，确保整个平台的高可用、高安全、高可扩展性。
|
||
|
||
技术中台不直接提供业务功能，而是作为平台**技术底座**，是所有业务系统稳定运行的基础保障。
|
||
|
||
---
|
||
|
||
## 2. 建设目标
|
||
|
||
1. 建立微服务架构体系（服务拆分/注册/发现/治理）
|
||
2. 实现医疗互联互通标准协议（HL7 FHIR R4）的统一适配
|
||
3. 构建独立API网关（统一鉴权/限流/熔断/审计）
|
||
4. 建立统一消息队列体系（异步解耦/顺序保障/死信处理）
|
||
5. 构建区块链存证服务（服务记录/审批数据/电子签章不可篡改）
|
||
6. 建立国密加密体系（SM2/SM3/SM4满足医疗数据合规加密要求）
|
||
7. 提供统一的监控告警、日志采集和链路追踪能力
|
||
|
||
---
|
||
|
||
## 3. 核心功能范围
|
||
|
||
### 3.1 一级模块
|
||
|
||
1. 微服务治理平台
|
||
2. 医疗互联互通协议层（HL7/FHIR）
|
||
3. API网关
|
||
4. 消息队列服务
|
||
5. 区块链存证服务
|
||
6. 国密安全加密服务
|
||
7. 统一监控与可观测性
|
||
|
||
### 3.2 二级功能清单
|
||
|
||
**微服务治理平台**：
|
||
|
||
- 服务注册与发现（Nacos）
|
||
- 服务配置中心（动态配置下发，无需重启）
|
||
- 服务熔断与降级（Sentinel/Resilience4j）
|
||
- 负载均衡策略配置
|
||
- 灰度发布与蓝绿部署支持
|
||
- 服务版本管理与 API 契约管理（OpenAPI 3.0）
|
||
|
||
**医疗互联互通协议层**：
|
||
|
||
- HL7 FHIR R4 资源适配（Patient/Observation/MedicationRequest等标准资源）
|
||
- FHIR Server（开源 HAPI FHIR）
|
||
- 接口适配网关（将各业务系统内部接口适配为FHIR标准接口）
|
||
- 医疗数据交换格式校验（与外部HIS/LIS/PACS对接时格式验证）
|
||
- 互联互通成熟度等级评测支持（⚠️ 待确认目标等级与评测节点）
|
||
|
||
**API网关**：
|
||
|
||
- 统一鉴权（JWT/OAuth2.0/API Key多种鉴权方式）
|
||
- 请求限流（按IP/用户/接口的多维度限流）
|
||
- 熔断降级（自动熔断异常服务，返回fallback响应）
|
||
- 请求路由（按路径/版本/灰度标签路由）
|
||
- 接口审计日志（所有API调用完整记录）
|
||
- SSL/TLS终止（统一证书管理，加密传输）
|
||
|
||
**消息队列服务**：
|
||
|
||
- 业务解耦消息发布订阅（各业务系统间异步通信）
|
||
- 顺序消息支持（如审批流程的顺序节点推进）
|
||
- 延迟消息（定时提醒/超时预警等场景）
|
||
- 消息重试与死信队列（消费失败后的重试与人工处理）
|
||
- 消息轨迹追踪（消息全链路状态查询）
|
||
- 与区块链存证联动（关键业务消息的存证触发）
|
||
|
||
**区块链存证服务**：
|
||
|
||
- 存证数据写入（服务记录/长护险服务凭证/审批结果/电子合同）
|
||
- 存证哈希查询（按业务ID查询对应区块链哈希）
|
||
- 存证验真（对比本地数据与链上哈希，验证未被篡改）
|
||
- 区块链平台管理（节点状态/存证量统计）
|
||
- 对接公信力区块链平台（⚠️ 待确认：百度超级链/腾讯TrustSQL/蚂蚁链等，需政府监管认可）
|
||
|
||
**国密安全加密服务**：
|
||
|
||
- SM2（非对称加密）：关键数据的加密存储与数字签名
|
||
- SM3（哈希算法）：数据完整性校验（替代SHA-256）
|
||
- SM4（对称加密）：批量数据的加密传输与存储
|
||
- 密钥管理服务（KMS）（密钥生成/存储/轮换/销毁）
|
||
- 国密TLS（TLCP协议支持，⚠️ 需专用服务器支持）
|
||
- 电子签章服务（结合SM2完成电子文件签章）
|
||
|
||
**统一监控与可观测性**：
|
||
|
||
- 指标监控（Prometheus + Grafana：系统负载/接口响应时间/错误率）
|
||
- 日志采集（ELK：Elasticsearch + Logstash + Kibana）
|
||
- 分布式链路追踪（SkyWalking / Jaeger）
|
||
- 告警规则配置与通知（告警→飞书/钉钉/短信通知）
|
||
- 容量规划看板（各服务资源使用趋势预测）
|
||
- 故障自动诊断（AIOps初级能力，基于历史告警模式）
|
||
|
||
### 3.3 技术架构总览
|
||
|
||
| 层次 | 组件 | 作用 |
|
||
| -------- | ----------------------------- | -------------------- |
|
||
| 接入层 | API网关（Kong/APISIX） | 统一入口、鉴权、限流 |
|
||
| 服务层 | Nacos + Sentinel | 服务注册、发现、熔断 |
|
||
| 通信层 | RabbitMQ / Kafka | 异步消息解耦 |
|
||
| 安全层 | 国密SDK + KMS | 数据安全加密 |
|
||
| 互联层 | HAPI FHIR Server | 医疗标准协议适配 |
|
||
| 存证层 | 区块链平台 | 关键数据不可篡改 |
|
||
| 可观测层 | ELK + Prometheus + SkyWalking | 全链路监控 |
|
||
| 基础设施 | Docker + Kubernetes | 容器化部署与弹性伸缩 |
|
||
|
||
---
|
||
|
||
## 4. 与现有 mall 的关系
|
||
|
||
**契合度：D（不适配）**
|
||
|
||
| 能力需求 | mall 现状 | 结论 |
|
||
| ----------------------------- | ------------------------------------- | ---------- |
|
||
| HL7/FHIR 医疗互联互通协议 | 无 | 须独立建设 |
|
||
| 区块链存证服务 | 无 | 须独立建设 |
|
||
| 国密加密体系（SM2/SM3/SM4） | 无 | 须独立建设 |
|
||
| 微服务治理平台 | mall 为单体或简单分层架构，无中台治理 | 须独立建设 |
|
||
| 统一API网关（含医疗合规审计） | 无 | 须独立建设 |
|
||
| 分布式消息队列 | 无 | 须独立建设 |
|
||
|
||
mall 是通用电商平台，不具备任何医疗互联互通、区块链存证、国密加密等专业技术能力，强行堆入会导致整体架构崩溃和医疗数据合规失控。
|
||
|
||
---
|
||
|
||
## 5. 规划判断
|
||
|
||
**独立建设（Platform Engineering，技术基础设施优先建设）**
|
||
|
||
建议云原生方案（降低运维难度，按需弹性伸缩）：
|
||
|
||
- **容器化**：Docker + Kubernetes（阿里云ACK / 腾讯云TKE托管）
|
||
- **API网关**：Kong（开源版）/ APISIX
|
||
- **服务治理**：Spring Cloud Alibaba（Nacos + Sentinel + Seata）
|
||
- **消息队列**：RabbitMQ（业务消息）+ Kafka（日志/流数据）
|
||
- **区块链**：⚠️ 待确认平台（需政府认可，优先考虑已在民政系统使用的公链）
|
||
- **国密**：BouncyCastle（Java国密库）/ GmSSL（C/Python国密库）
|
||
- **FHIR Server**：HAPI FHIR（开源，Java）
|
||
- **监控**：Prometheus + Grafana + SkyWalking + ELK
|
||
|
||
---
|
||
|
||
## 6. 需新增业务能力
|
||
|
||
1. **DevOps流水线**：CI/CD自动化发布（Jenkins / GitLab CI + Helm Chart部署）
|
||
2. **灾备方案**：关键数据的异地双活或同城双备（医疗数据丢失不可接受）
|
||
3. **等保三级合规**：系统安全等级保护三级认证（医疗信息系统要求）
|
||
4. **国密TLS通信**：部分政府对接接口可能要求国密通信链路
|
||
5. **接口标准文档**：OpenAPI 3.0规范维护，供对接方接入使用
|
||
|
||
---
|
||
|
||
## 7. 需新增数据模型（基础设施侧）
|
||
|
||
| 模型 | 关键字段 |
|
||
| --------------------- | ---------------------------------------------------------------------------------- |
|
||
| `blockchain_record` | id, biz_type, biz_id, data_hash(SM3), chain_tx_id, chain_time, verify_status |
|
||
| `api_call_log` | id, gateway_id, path, method, client_ip, user_id, status_code, latency_ms, ts |
|
||
| `encryption_key_meta` | id, key_type(SM2/SM4), key_version, created_at, expire_at, status, managed_by_kms |
|
||
| `fhir_resource_log` | id, resource_type, resource_id, operation, requestor, source_system, created_at |
|
||
| `service_health` | id, service_name, instance_id, status, cpu_pct, mem_pct, latency_p99, check_at |
|
||
| `alert_rule` | id, metric_name, condition, threshold, severity, notify_channels(JSONB), is_active |
|
||
|
||
---
|
||
|
||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||
|
||
| 类别 | 技术选型 | 用途 |
|
||
| ----------- | ------------------------------------- | ------------------- |
|
||
| 容器编排 | Kubernetes（云托管） | 服务部署与弹性伸缩 |
|
||
| API网关 | Kong / APISIX（开源） | 统一鉴权/限流/路由 |
|
||
| 服务注册 | Nacos | 微服务注册与配置 |
|
||
| 熔断限流 | Sentinel | 流量控制与熔断 |
|
||
| 消息队列 | RabbitMQ + Kafka | 业务解耦 + 日志流 |
|
||
| 链路追踪 | SkyWalking | 分布式链路追踪 |
|
||
| 日志管理 | ELK Stack | 日志采集与查询 |
|
||
| 监控 | Prometheus + Grafana | 指标监控与可视化 |
|
||
| FHIR服务 | HAPI FHIR（开源） | HL7 FHIR R4标准适配 |
|
||
| 国密加密 | BouncyCastle / GmSSL | SM2/SM3/SM4加密 |
|
||
| KMS密钥管理 | 阿里云KMS / 腾讯云KMS | 密钥安全管理 |
|
||
| 区块链 | ⚠️ 待确认（蚂蚁链/腾讯链/百度超级链） | 关键数据存证 |
|
||
|
||
---
|
||
|
||
## 9. 外部系统对接关系
|
||
|
||
| 对接系统 | 方向 | 内容 |
|
||
| ---------------- | ------------------------- | ------------------------------------ |
|
||
| 全部27个业务系统 | 依赖 | API网关/消息队列/国密加密/区块链存证 |
|
||
| 志愿者管理（12） | 调用区块链存证 | 时间银行积分存证 |
|
||
| 长护险（18） | 调用区块链存证 | 服务凭证存证 |
|
||
| 政府审批（04） | 调用区块链存证 + 电子签章 | 审批结果存证 |
|
||
| 外部HIS/LIS | 依赖FHIR适配层 | 医疗数据互联互通 |
|
||
| 运营监控人员 | 使用监控平台 | 系统健康状态监控 |
|
||
| 等保测评机构 | 外部审查 | 等保三级合规评测 |
|
||
|
||
---
|
||
|
||
## 10. 风险与边界
|
||
|
||
| 风险 | 说明 | 应对 |
|
||
| ------------------------------ | ------------------------------------------- | ------------------------------------------------------------ |
|
||
| 技术复杂度高 | 微服务+区块链+国密+FHIR并行建设复杂度极高 | 分期建设，P0阶段先建API网关+微服务治理，其他逐步扩展 |
|
||
| 区块链平台选择 | 国内区块链平台众多，政府认可度不同 | 与政府监管部门确认认可的区块链平台后再选型 |
|
||
| 国密TLS兼容 | 国密TLS需要专用客户端支持，兼容性有限 | 非强制要求时用标准TLS，政府接口按要求提供国密通道 |
|
||
| FHIR标准复杂 | FHIR资源模型学习成本高，国内HIS适配程度不一 | 先完成Patient/Observation等核心资源，逐步扩展 |
|
||
| 等保三级成本 | 等保三级测评和整改成本较高（数十万元+） | 提前规划等保要求，在系统设计阶段就满足技术要求，避免后期整改 |
|
||
| 边界：技术中台只做通用技术能力 | 不在技术中台中实现任何业务逻辑 | 技术中台只提供协议/安全/治理/存证等通用技术服务 |
|
||
|
||
---
|
||
|
||
## 11. 实施优先级与分期建议
|
||
|
||
**优先级：P2（分期建设，基础部分需在P0之前就绪）**
|
||
|
||
| 分期 | 内容 | 时间节点 |
|
||
| ------------------------ | ---------------------------------------------------------- | ------------------ |
|
||
| 前置建设（P0系统上线前） | Docker+K8s基础环境 + API网关 + Nacos + RabbitMQ + 基础监控 | 在P0系统开发前完成 |
|
||
| 第一期 | 国密加密服务 + ELK日志 + SkyWalking链路追踪 | P0/P1系统建设期间 |
|
||
| 第二期 | HAPI FHIR Server + 外部HIS对接 | P1系统建设期间 |
|
||
| 第三期 | 区块链存证 + 等保三级合规建设 + 国密TLS | P2阶段按需推进 |
|
||
|
||
---
|
||
|
||
## 12. 结论
|
||
|
||
技术中台是整个医养平台的**技术底座**，其微服务治理、API网关、国密加密、HL7/FHIR协议、区块链存证等能力在 mall 中完全缺失，**必须独立建设**。
|
||
|
||
技术中台的建设应遵循"先基础后专业"的原则：优先完成API网关、微服务治理、容器化部署等通用基础设施（在P0业务系统之前就绪），再根据业务需求逐步引入HL7/FHIR医疗互联互通、国密加密和区块链存证等专业医疗技术能力。建议优先采用云托管服务（K8s/KMS/日志服务等）降低运维复杂度，让团队聚焦业务能力建设。
|