AIclinicalresearch/docs/07-运维文档/架构优化建议：2人团队SAE降本增效方案.md

针对 2 人初创团队的 SAE + RDS 架构降本增效方案

现状诊断：

• 团队规模： 2人（极简团队）
• 当前痛点： 成本压力（双 SAE 环境费用） vs 运维安全（需要隔离测试）
• 关键约束： 必须防止类似 prisma db push 的生产事故再次发生。

策略一：数据库层面 —— “同居不同室”

你们现在的做法是共享同一个 RDS PostgreSQL 15 实例。这在创业初期是非常明智的选择，不需要改变。购买两个 RDS 实例对于目前的业务量来说太浪费了。

但是，“共享”的方式决定了生死。

1. 绝对禁止的做法

❌ Dev 和 Prod 使用同一个数据库名（Database Name），试图靠 Schema 区分。

• 风险：你们的代码中（特别是 Prisma 和 pg-boss）可能硬编码了 Schema 名称（如 platform_schema）。
• 后果：Dev 环境启动后，pg-boss Worker 会连接到数据库，开始抓取 Prod 环境的任务队列进行处理。这会导致生产任务丢失或被错误处理。

2. 推荐做法：Database 级别的隔离

✅ 在同一个 RDS 实例中，创建两个完全独立的数据库。

环境变量	生产环境 (Prod)	开发/测试环境 (Dev)
DATABASE_URL	.../ai_clinical_prod	.../ai_clinical_dev
用户名	aiclinical_prod_user	aiclinical_dev_user
资源限制	无限制	限制连接数 (避免 Dev 耗尽连接)

实施步骤：

1. 进入 RDS 控制台，新建数据库 ai_clinical_dev。
2. 即使是同一个 RDS 实例，由于数据库名不同，数据文件在逻辑上是完全隔离的。
3. Dev 环境即使执行 prisma db push --force-reset，也只会清空 ai_clinical_dev，生产环境绝对安全。

策略二：计算层面 (SAE) —— “分时租赁与按需启停”

对于 SAE，你们最大的优势是Serverless 的弹性。如果测试环境 24 小时开着，那就是把 SAE 当 ECS 用，非常亏。

1. 生产环境 (Production)

• 策略：保持常驻，配置最小实例数为 1（或 2 保证高可用）。
• 配置：开启弹性伸缩，根据 CPU/内存自动扩容。

2. 开发/测试环境 (Dev/Test)

核心建议：不要让它 24 小时运行！

方案 A：一键启停 (手动省钱法)

• 操作：
  • 平时开发：在本地 localhost 使用 Docker Compose + 本地 Postgres 开发（完全免费）。
  • 提交代码后：如果需要验证，去 SAE 控制台点击“启动”。
  • 验证完/下班后：去 SAE 控制台点击**“停止”**（由 1 实例缩容为 0）。
• 成本影响：SAE 停止的应用不收取计算费用（只收取极少的快照存储费）。如果每天只开 2 小时测试，成本降低 90%。

方案 B：CI/CD 触发式环境 (自动化法)

• 原理：利用 GitHub Actions 或 阿里云云效。
• 流程：
  1. 代码 Push 到 dev 分支。
  2. CI 流水线构建镜像。
  3. CI 调用阿里云 API，更新并启动 SAE Dev 应用。
  4. 设置一个定时任务（如每晚 22:00），自动调用 API 停止 Dev 应用。

策略三：极致省钱的替代架构 (如果不使用 SAE 测试环境)

如果连 SAE 测试环境的“按需启动”成本都想省，可以考虑以下架构：

1. "Localhost is King" 模式

既然只有 2 个人，且都在内网或可以通过 VPN 协作：

• 放弃 SAE 测试环境。
• 开发验证：每人本地运行全套 Docker Compose（包含前端、后端、Postgres、MinIO 模拟 OSS）。
• 集成测试：其中一人的电脑作为“临时服务器”，通过 ngrok 或 frp 暴露端口给另一人测试。
• 上线：直接部署到 SAE 生产环境。
• 缺点：缺乏一个稳定的“预发环境”，上线风险略高。

2. ECS "脏"环境模式 (Dirty Dev Box)

• 做法：买一台最便宜的 ECS (突发性能实例 t6/t5)，或者利用闲置的旧笔记本/工控机放在公司/家里。
• 部署：上面装一个 Docker，把所有 Dev 服务（前端、后端、Python、DB）全扔进去。
• 成本：一台 2核4G 的 t6 实例，一个月可能只要几十块钱（或者抢占式实例，更便宜）。
• 优势：固定 IP，成本极低，随便折腾。
• 劣势：需要自己维护 Linux、Docker 环境。

综合建议：给你们团队的最佳实践

考虑到你们已经熟悉了 SAE 且希望减少运维，我推荐 “改良版 SAE + 共享 RDS” 方案：

1. 数据库：
   • 继续使用同一个 RDS 实例。
   • 必须创建两个 DB：prod_db 和 dev_db。
   • 必须使用两个数据库账号，防止权限越界。
2. SAE 环境：
   • 生产环境：SAE 专业版（或标准版），常驻。
   • 测试环境：SAE 标准版（无需专业版）。
   • 关键动作：
     • 配置 SAE 测试环境的定时启停策略（阿里云 SAE 控制台支持定时启停）。
     • 例如：09:00 启动，20:00 停止。周末不启动。
     • 或者写一个脚本，只在部署新镜像时启动，闲置 1 小时无流量自动缩容到 0（需配合 ALB/CLB 流量监控，略复杂，建议手动或定时停止）。
3. 本地开发增强：
   • 完善 docker-compose.yml。确保本地开发体验和云端 99% 一致。
   • 这样你们 90% 的测试工作（包括 Python 微服务、数据清洗逻辑）都可以在本地完成，只有最后 10% 需要用到 SAE 测试环境。

成本对比预估 (月)

方案	生产环境成本	测试环境成本	运维复杂度	推荐度
现状 (双 SAE 常驻)	¥600+	¥300+	低	⭐⭐
推荐 (Dev 定时启停)	¥600+	¥50 (按量付费)	中 (需配置一次)	⭐⭐⭐⭐⭐
ECS 廉价测试机	¥600+	¥40-80	高 (需维护服务器)	⭐⭐⭐
Localhost 只有生产	¥600+	¥0	低 (但在上线时风险极高)	⭐

总结

对于 2 人团队，时间比计算资源更贵。

不要为了省几百块钱去维护一套复杂的自建 ECS 环境。

继续用 SAE，但是要学会“关机”。 就像你离开房间会关灯一样，没人测试的时候，把 SAE Dev 环境关掉（缩容到 0），这就是云原生最大的红利。