HaHafeng
96290d2f76
Sprint 1-3 Completed (Backend + Frontend): Backend (Sprint 1-2): - Implement 5-layer Agent framework (Query->Planner->Executor->Tools->Reflection) - Create agent_schema with 6 tables (agent_definitions, stages, prompts, sessions, traces, reflexion_rules) - Create protocol_schema with 2 tables (protocol_contexts, protocol_generations) - Implement Protocol Agent core services (Orchestrator, ContextService, PromptBuilder) - Integrate LLM service adapter (DeepSeek/Qwen/GPT-5/Claude) - 6 API endpoints with full authentication - 10/10 API tests passed Frontend (Sprint 3): - Add Protocol Agent entry in AgentHub (indigo theme card) - Implement ProtocolAgentPage with 3-column layout - Collapsible sidebar (Gemini style, 48px <-> 280px) - StatePanel with 5 stage cards (scientific_question, pico, study_design, sample_size, endpoints) - ChatArea with sync button and action cards integration - 100% prototype design restoration (608 lines CSS) - Detailed endpoints structure: baseline, exposure, outcomes, confounders Features: - 5-stage dialogue flow for research protocol design - Conversation-driven interaction with sync-to-protocol button - Real-time context state management - One-click protocol generation button (UI ready, backend pending) Database: - agent_schema: 6 tables for reusable Agent framework - protocol_schema: 2 tables for Protocol Agent - Seed data: 1 agent + 5 stages + 9 prompts + 4 reflexion rules Code Stats: - Backend: 13 files, 4338 lines - Frontend: 14 files, 2071 lines - Total: 27 files, 6409 lines Status: MVP core functionality completed, pending frontend-backend integration testing Next: Sprint 4 - One-click protocol generation + Word export
124 lines
6.4 KiB
Markdown
124 lines
6.4 KiB
Markdown
# **针对 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），这就是云原生最大的红利。 |