HaHafeng
6124c7abc6
Completed: - Add 6 core database documents (docs/01-平台基础层/07-数据库/) Architecture overview, migration history, environment comparison, tech debt tracking, seed data management, PostgreSQL extensions - Restructure deployment docs: archive 20 legacy files to _archive-2025/ - Create unified daily operations manual (01-日常更新操作手册.md) - Add pending deployment change tracker (03-待部署变更清单.md) - Update database development standard to v3.0 (three iron rules) - Fix Prisma schema type drift: align @db.* annotations with actual DB IIT: UUID/Timestamptz(6), SSA: Timestamp(6)/VarChar(20/50/100) - Add migration: 20260227_align_schema_with_db_types (idempotent ALTER) - Add Cursor Rule for auto-reminding deployment change documentation - Update system status guide v6.4 with deployment and DB doc references - Add architecture consultation docs (Prisma guide, SAE deployment guide) Technical details: - Manual migration due to shadow DB limitation (TD-001 in tech debt) - Deployment docs reduced from 20+ scattered files to 3 core documents - Cursor Rule triggers on schema.prisma, package.json, Dockerfile changes Made-with: Cursor
95 lines
5.1 KiB
Markdown
95 lines
5.1 KiB
Markdown
# **CTO 代码审查报告：AI临床研究平台部署架构**
|
||
|
||
审核对象：5份独立部署文档 (Dify/Python/Node/Frontend/PostgreSQL)
|
||
审核人：虚拟架构师
|
||
结论：A- (优秀)。架构设计符合云原生理念，成本与扩展性平衡良好。但存在网络出口和依赖闭环两个关键风险点需解决。
|
||
|
||
## **1\. 模块级深度审计 (Module-Level Audit)**
|
||
|
||
### **✅ 1.1 前端 Nginx (SAE)**
|
||
|
||
* **优点**：多阶段构建优秀（体积小）；环境变量注入方案（envsubst）非常专业，解决了静态页面无法动态配置后端的难题。
|
||
* **修正建议**：
|
||
* 确认 nginx.conf 中开启 gzip，这对 React 大体积 JS 文件至关重要。
|
||
* 检查 Nginx 的 client\_max\_body\_size 配置。医疗 PDF/Excel 可能超过默认的 1MB，建议设置为 50M。
|
||
|
||
### **✅ 1.2 后端 Node.js (SAE)**
|
||
|
||
* **优点**：Prisma "反向同步" 流程非常务实，解决了开发习惯不规范的问题。Postgres-Only 的架构极大地降低了运维负担。
|
||
* **修正建议**：
|
||
* **连接泄漏风险**：Python 服务如果响应慢，后端的 HTTP Client 设置超时了吗？建议设置 timeout: 30s，防止后端连接数堆积。
|
||
|
||
### **✅ 1.3 Python 微服务 (SAE)**
|
||
|
||
* **优点**：明确指出了 libGL 等系统依赖问题，这是 Python 容器化最大的坑，文档已提前规避。
|
||
* **修正建议**：
|
||
* **OOM 风险**：Python 进程（尤其是 PyMuPDF/OCR）非常吃内存。在 2G 内存限制下，务必限制并发数（Gunicorn Workers 不要超过 2 个）。
|
||
|
||
### **✅ 1.4 Dify (ECS)**
|
||
|
||
* **优点**：选择了 ECS 部署以保证数据私有化，同时使用 Swap 防止 OOM，非常懂行。
|
||
* **修正建议**：
|
||
* **安全性**：ECS 的 Redis 端口 (6379) 和 Weaviate 端口 (8080) **绝对不要**对公网开放。仅允许 localhost 和 VPC 内网访问。
|
||
|
||
### **✅ 1.5 数据库 (RDS)**
|
||
|
||
* **优点**：Schema 隔离设计极佳。
|
||
* **修正建议**：
|
||
* **Dify 数据库隔离**：确认 Dify 使用的是独立的 dify\_prod 库，不要和业务表混在 ai\_clinical\_research 库中，防止 Dify 升级脚本误删业务表。
|
||
|
||
## **2\. 跨模块集成风险 (Integration Risks)**
|
||
|
||
### **🚨 风险一：SAE 的"孤岛效应" (Internet Access)**
|
||
|
||
* **问题**：SAE 部署在 VPC 内，默认**没有公网出口**。
|
||
* **场景**：后端调用 DeepSeek API、Python 下载公网 PDF、NPM 安装依赖（构建时）。
|
||
* **对策**：必须在 VPC 中配置 **NAT 网关** (推荐) 或确保 SAE 有绑定公网 IP 的能力。**否则上线当天所有 AI 功能都会超时。**
|
||
|
||
### **🔄 风险二：部署依赖死锁 (Deployment Deadlock)**
|
||
|
||
* **现象**：
|
||
1. 后端启动需要 DIFY\_API\_KEY。
|
||
2. DIFY\_API\_KEY 需要 Dify 启动并人工登录后才能生成。
|
||
3. 后端如果配置了"健康检查失败则重启"，在填入 Key 之前会无限重启。
|
||
* **对策**：首次部署时，后端环境变量 DIFY\_API\_KEY 可以先填个假值（如 temp），让服务跑起来。等 Dify 部署好拿到真 Key 后，更新 SAE 配置并重启。
|
||
|
||
### **🌐 风险三：前端与 Dify 的跨域 (CORS)**
|
||
|
||
* **问题**：前端直接调用后端（通过 Nginx 代理）没问题。但如果前端需要**直接嵌入** Dify 的 Web UI（如 iframe）或直接调用 Dify API（绕过后端），会遇到 CORS。
|
||
* **对策**：坚持\*\*"所有请求走后端"\*\*的原则。前端 \-\> Nginx \-\> 后端 \-\> Dify。不要让前端直连 Dify，既安全又避免 CORS。
|
||
|
||
## **3\. 架构关系图谱**
|
||
|
||
\[浏览器\]
|
||
| (HTTPS)
|
||
v
|
||
\[SAE: 前端 Nginx\]
|
||
| (反向代理 /api)
|
||
v
|
||
\[SAE: 后端 Node.js\] \--(内网HTTP)--\> \[SAE: Python 微服务\]
|
||
| | (内网HTTP)
|
||
| v
|
||
| \[ECS: Dify API\] \<--\> \[ECS: Weaviate/Redis\]
|
||
|
|
||
\+--(TCP Connection)--\> \[RDS PostgreSQL 15\]
|
||
| | (Schema: platform, asl, dc...)
|
||
| \+ (Database: dify\_prod)
|
||
|
|
||
\+--(HTTPS)--\> \[OSS 对象存储\]
|
||
|
|
||
\+--(NAT网关)--\> \[互联网: DeepSeek/OpenAI\]
|
||
|
||
## **4\. 给 1-2 人团队的生存建议**
|
||
|
||
1. **省钱黑科技**：
|
||
* SAE 2.0 有**闲置计费**功能。开发环境（测试环境）务必开启，没人用时不收 CPU/内存 费。
|
||
* RDS 购买**通用型** (2核4G) 即可，不要买独享型，够用很久。
|
||
2. **不要自建监控**：
|
||
* 直接用阿里云 **ARMS** (应用实时监控服务) 的免费额度或基础版。不要自己搭 Prometheus \+ Grafana，维护成本太高。
|
||
3. **数据备份是底线**：
|
||
* RDS 开启自动备份（保留7天）。
|
||
* ECS 上的 Dify docker-compose.yaml 和 .env 文件，务必在本地或 Git 私有仓库备份一份。ECS 没了可以重买，配置文件没了就得重配。
|
||
4. **开发效率**：
|
||
* 利用 ECS 做**跳板机**，本地直连 RDS 开发。不要每次都写代码去查数据。
|
||
|
||
**最终结论**：这套架构设计得非常扎实，完全可以支撑从 0 到 10 万用户的规模。请重点解决 **"SAE 访问公网 (NAT)"** 这个问题，即可开始部署。 |