# **REDCap 生产环境部署：ECS vs SAE 深度决议报告**

## **1\. 核心结论：认�?ECS 优先策略**

针对 IIT Manager Agent 项目，我们决定将 REDCap 生产环境部署�?**ECS (Docker 模式)** 运行，而不�?SAE�?
### **为什么我们“认错”并转向 ECS�?*

在讨�?AI 后端时，SAE 的免运维特性很吸引人，�?REDCap 的三个“致命特性”决定了它在 SAE 上会极其痛苦�?
1. **Cron 依赖（心跳丢失）**：REDCap 每分钟都需要运行一�?cron.php。在 SAE 中，你得额外�?SchedulerX 服务；在 ECS，只需一�?crontab 就能搞定�?100% 可靠�? 
2. **Session 粘滞（掉线噩梦）**：REDCap 默认将会话存本地。SAE 是多实例的，如果没做 Redis 共享，用户登录后会反复掉线，2 人团队去修这�?Bug 会耗费大量时间�? 
3. **文件系统 POSIX 依赖**：REDCap �?10 年前的软件一样极其依赖本地文件夹读写。SAE 必须挂载 NAS，网络延迟会拖慢整个系统的响应�?
## **2\. 深度对比：务实派的决策依�?*

| 维度 | ECS \+ Docker (我们的选择) | SAE (Serverless) | 结论 |
| :---- | :---- | :---- | :---- |
| **部署成本** | **�?*。入门级 ECS (2�?G) �?1500�?年�?| **�?*。SAE \+ NAS \+ 闲置费用可能更贵�?| **ECS �?* |
| **配置复杂�?* | **极简**。只需运行 docker-compose.yml�?| **复杂**。需解决共享存储、Session同步、定时任务�?| **ECS �?* |
| **系统透明�?* | **透明**。直�?docker logs 查看 PHP 日志�?| **黑盒**。云原生链路长，报错时排查难度大�?| **ECS �?* |
| **可移植�?* | **最�?*。这�?Docker 配置可以原封不动挪到医院内网�?| **�?*。医院内网通常没有 SAE 这种环境�?| **ECS �?* |

## **3\. 2 人团队的“生存之道�?*

作为一个只�?2 人的团队，我们的时间应该花在 **Agent �?Prompt 调优** �?**业务逻辑** 上，而不是花在“调试云产品之间的连接”上�?
* **ECS 方案**：你就像拥有了一台真正的电脑。文件在哪、日志在哪、数据库连没连上，你一眼就能看清�? 
* **SAE 方案**：你会陷入“为什么挂载了 NAS 还是没写权限？”、“为什�?Cron 没触发？”这种与业务无关的琐事中�?
## **4\. 最终定稿：混合架构蓝图**

我们将采取\*\*“混合云”\*\*的思路，发挥各自的长处�?
### **4.1 数据平面 (Data Layer) \-\> 部署�?ECS**

* **组件**：REDCap (Apache \+ PHP 8.1)�? 
* **方式**：使�?Docker-Compose 运行�? 
* **存储**：附件存储在 ECS 挂载的云盘；数据库连�?**RDS MySQL**�? 
* **优势**：保证了 EDC 系统的绝对稳定和传统运维的简便�?
### **4.2 控制平面 (AI Agent Layer) \-\> 部署�?SAE**

* **组件**：Node.js 后端、Python 算法、AI 前端�? 
* **方式**：Serverless 部署�? 
* **优势**：利�?SAE 处理 AI 这种流量波动大、需要弹性伸缩的模块�?
## **5\. 对后续开发的意义**

1. **本地环境即生产环�?*：由�?ECS 跑的�?Docker，你在本�?03-REDCap本地部署方案.md 里写的代码，直接就能上线，没有任何“环境漂移”�? 
2. **离线交付预演**：如果未来医院要求内网部署，我们已经有了一套完整的、基�?ECS/Docker 的交付包，这�?SAE 方案更容易被医院 IT 接受�?
**当前状�?*：Deployment Strategy Locked | **建议**：立即执行基�?ECS 的生产环境搭建�