# **针对 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），这就是云原生最大的红利。