# **CTO 代码审查报告：AI临床研究平台部署架构**

审核对象�?份独立部署文�?(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�?G) 即可，不要买独享型，够用很久�? 
2. **不要自建监控**�? 
   * 直接用阿里云 **ARMS** (应用实时监控服务) 的免费额度或基础版。不要自己搭 Prometheus \+ Grafana，维护成本太高�? 
3. **数据备份是底�?*�? 
   * RDS 开启自动备份（保留7天）�? 
   * ECS 上的 Dify docker-compose.yaml �?.env 文件，务必在本地�?Git 私有仓库备份一份。ECS 没了可以重买，配置文件没了就得重配�? 
4. **开发效�?*�? 
   * 利用 ECS �?*跳板�?*，本地直�?RDS 开发。不要每次都写代码去查数据�?
**最终结�?*：这套架构设计得非常扎实，完全可以支撑从 0 �?10 万用户的规模。请重点解决 **"SAE 访问公网 (NAT)"** 这个问题，即可开始部署�