Files
AIclinicalresearch/docs/03-业务模块/Redcap/REDCap 生产环境部署:ECS vs SAE 深度决议报告.md
HaHafeng 38d9bf99d6 feat(redcap): REDCap 15.8.0 Docker本地开发环境部署完成
核心成果:
- REDCap 15.8.0成功部署在Docker环境
- 登录功能正常,管理员账户: Admin/Admin123!
- MySQL 8.0 + PHP 8.1 + Apache 2.4环境验证通过

问题解决:
1. 修复ERR_CONTENT_DECODING_FAILED错误
   - 强制禁用Apache deflate模块
   - PHP配置关闭zlib.output_compression
   - 自动注释REDCap源码中的压缩设置

2. 修复Base URL配置错误
   - 更新redcap_config表中的redcap_base_url
   - 统一DocumentRoot与访问路径

3. 修复登录失败问题(CRLF污染)
   - 删除database.php末尾的PHP结束标签
   - 创建.gitattributes规范换行符
   - 验证REDCap官方源码无此问题

技术改进:
- 添加密码重置工具脚本
- 完善docker-entrypoint.sh启动脚本
- 创建详细的部署问题解决记录
- 建立PHP配置文件最佳实践

部署文档:
- REDCap本地Docker开发环境部署方案
- REDCap生产环境部署决策报告(ECS vs SAE)
- 部署问题解决记录(含根因分析)

下一步:
- Day 2: 开发REDCap API Adapter
- 实现与IIT Manager Agent的数据对接
2026-01-02 10:02:46 +08:00

53 lines
3.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# **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核4G) 约 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 的生产环境搭建。