Platform API 拆分计划（ECS 控制面 + Dell 算力池）

2026-06-12 更新：当前中心库是 ECS Docker PostgreSQL (biof3-pg)，不迁阿里云托管 RDS。本文的 API/Worker 拆分方向仍有效，数据库术语按 docs/ops/ECS-PLATFORM-CONVERGENCE-PLAN.md 执行。

目标（已对齐）：Docker R / Python 永远在算力节点（Dell）上；ECS 放 platform-api（+ 静态站 + nginx + biof3-pg）。算力节点可以 一台 Dell，也可以多台（水平扩展 worker）。 完成标准：登录 / 用户 / 权限 / Copilot / 项目 CRUD → platform + ECS Docker PostgreSQL；执行 → Dell 上的 r-compute + worker + R 容器、py-compute + worker + Python 容器；任务真相在 PostgreSQL，不靠「ECS 与 Dell 各一份 SQLite」。

1. 目标拓扑

1.1 谁在哪（核心）

逻辑服务	部署位置	Docker	职责
platform-api	ECS（同机连 `biof3-pg`）	否	鉴权、用户、权限、CRUD、Copilot、FigCode 入队、OSS 签名、admin
r-compute	Dell 算力节点	R 容器在本机	HTTP：`/api/run`、`/api/task` 入队、replot；可选瘦 API
r-worker	每台有 R 的 Dell	同机 `docker exec`	从 PostgreSQL `claim` 任务 → 跑 R → 写状态 / OSS
py-compute	Dell 算力节点	Python 容器在本机	HTTP：py 任务、upload、`/api/run`
py-worker	每台有 Python 的 Dell	同机	从 PostgreSQL 消费 py 队列

不是「三台 Node 都堆在 ECS 里跑 Docker」——ECS 内存不够、也和你们现有 16TB + 大内存 Dell 投资不一致。

1.2 多台 Dell 怎么扩

                    PostgreSQL (tasks, tool_jobs, analyses, …)
                         ▲           ▲           ▲
                         │ claim     │ claim     │ claim
              ┌──────────┴───┐ ┌─────┴─────┐ ┌───┴──────────┐
              │ Dell-A       │ Dell-B     │ Dell-C (未来) │
              │ r-worker     │ r-worker   │ py-worker     │
              │ R Docker     │ R Docker   │ Py Docker     │
              │ py-worker?   │            │               │
              └──────────────┘ └───────────┘ └──────────────┘

每个 worker 配置 BIOF3_WORKER_ID（唯一）、同一 DATABASE_URL（当前 Dell 通过 autossh 转发到 ECS biof3-pg）。
异步任务：worker 只连 PostgreSQL，不需要每台 Dell 都暴露公网 API。
同步 /api/run、replot、大文件 upload：仍需 某一扇 HTTP 入口 → nginx 可 反代到一台主 Dell（frp/专线），或后续 算力网关 按负载挑节点（M 后期优化）。

1.3 用户流量示意

  用户 → biof3.com (ECS nginx)
            ├─ /api/platform/*  → ECS :3011  platform-api  → ECS Docker PostgreSQL / OSS
            ├─ /api/r/*         → frp / 172.17.0.1:3001 → Dell r-server api mode (+ 本机 R)
            └─ /api/py/*        → frp / 172.17.0.1:3002 → Dell py-server api mode (+ 本机 Py)

  Dell r-worker / py-worker  ──(autossh localhost:5433)──►  ECS biof3-pg  抢任务、更新状态

2026-06-13 现状：ECS 只承担 platform 控制面；Dell 的 biof3-r-server / biof3-py-server 已按 api 模式作为算力兼容入口，实际执行由 biof3-r-worker / biof3-py-worker 以 worker 模式从 ECS Docker PostgreSQL 抢任务。

1.4 与「Dell 纯 Worker」旧说法的差异

旧 C/D 草案	当前定稿
platform 在 ECS，Dell 也临时承接控制面	platform 控制面固定在 ECS，Dell 不再接 `/api/platform/*`
把 R/Python compute 迁到 ECS	R/Python Docker 保留在 Dell，利用现有大内存和大盘
py-server / r-server 单进程全包	server=api 模式入队/兼容入口，worker=worker 模式执行 PG 队列

2. 现状 vs 目标（能力表）

能力	今天	目标
登录 / JWT / 用户 / 权限	`biof3-r-server`	platform-api
项目 / 数据集 / 分析 CRUD	`r-server` `/api/data/*`	platform-api
Copilot / AI / 反馈 / 埋点	`r-server` `routes/*`	platform-api
FigCode 提交 `tool_jobs`	`r-server` `routes/tools.js`	platform-api（入队）；执行在 r-compute worker
FigCode / 单细胞跑 R	混在 r-server	r-compute（3011 + R Docker + worker）
空间 / ML 跑 Python	py-server 全包	py-compute（3012 + Python Docker + worker）
元数据 DB	ECS Docker PostgreSQL	不变；platform 主写，compute 只写任务/分析状态
R 队列	PostgreSQL tasks, `engine='R'`	已迁 PG
Py 队列	PostgreSQL tasks, `engine='Python'`	已迁 PG（与 R 对称）

历史兼容期：/api/r/auth/* 曾计划反代到 platform。当前生产已退役该入口： /api/r/auth/* 返回 404，认证统一走 /api/platform/auth/*。

2. 路由归属清单（从 `r-server` 拆出）

2.1 → platform-api（控制面）

前缀 / 文件	说明
`auth.js` + `/api/auth/*`	登录、注册、me、改密
`api-data.js` → `/api/data/*`	projects / datasets / analyses / quota
`routes/ai-*.js`, `feedback.js`, `analytics.js`	Copilot 全家桶
`routes/tools.js`	仅创建 job、查状态、历史、public-demo；不在 platform 里 `docker exec R`
`server.js` 片段	`/api/health`, `/api/oss/sign`, `/api/upload`（若给 Copilot/云平台上传）
`server.js` admin	`/api/admin/users`, guest-permissions, impersonate, cache/backup 管理 UI
`/api/public/guest-permissions`, `/api/error-report`, `/api/pageview`	公开/埋点
`helpers/permissions.js`, `guest-permissions.js`	模块权限
`db.js` + `db--pg.js` + `db-p2-`	唯一 PG 访问层（worker 只读/写任务状态）

2.2 → r-compute + r-worker（Dell，目录仍 `r-server/`）

组件	部署	说明
r-compute HTTP	Dell（可选仅内网）	`/api/run`、`/api/task*` 入队、replot；验 JWT
r-worker	每台跑 R 的 Dell	`claimPendingTask` + R Docker；只连 PostgreSQL
代码	`task-queue`, `task-store`, `r-pool`, `worker.js`	`task-store` 必须 PG
数据盘	Dell 本地/NAS	容器挂载路径保持现有（如 `/mnt/storage_16tb/...`）

不做：auth、/api/data、Copilot、tools 提交逻辑（提交在 platform）。

2.3 → py-compute + py-worker（Dell，目录 `py-server/`）

组件	部署	说明
py-compute HTTP	Dell	`/api/task*`, `/api/run`, `/api/upload`
py-worker	每台跑 Python 的 Dell	消费 py 队列 + Python Docker
任务表	ECS Docker PostgreSQL	`pyserver.db` SQLite 废弃（迁 PG）

不做：用户表、Copilot；JWT 与 platform 相同 JWT_SECRET。

3. 代码组织（推荐目录）

BioF3/
  platform-server/          # 仅部署 ECS
    server.js               # 无 R/py Docker、不 drain 队列
    routes/, api-data.js, auth.js, db*.js
  r-server/                 # 仅部署 Dell（r-compute + worker）
    server.js               # 瘦：run/task/replot
    worker.js
  py-server/                # 仅部署 Dell（py-compute + worker）

共享库（避免双份逻辑） — 二选一：

A（快）：packages/biof3-db 私有包，platform-server 与 r-compute 都 require('@biof3/db')
B（更快落地）：短期 git submodule / 同步脚本 只同步 db-pg.js, db-auth-pg.js, auth.js, config 片段

4. 分阶段实施（建议顺序）

Phase M0 — 文档与开关（1 天）

本文件评审通过
ECS 端口规划：platform:3020, r-compute:3011, py-compute:3012（与 frp 3001/3002 脱钩）
环境变量：JWT_SECRET、DATABASE_URL 三进程一致；新增 BIOF3_INTERNAL_TOKEN

Phase M1 — 拉起 platform-api（2～3 天）

新建 platform-server/，从 r-server 复制并删除 run/task/replot/r-pool/worker 挂载
registerRoutes(app) + auth + api-data 可启动
ECS：pm2 start platform-server，仅 curl localhost:3020/api/health
不切 nginx

Phase M2 — nginx 双轨 + 前端灰度（2 天）

location /api/platform/ { proxy_pass http://127.0.0.1:3020/api/; }
前端 authClient / copilotClient / scrna API base 改为 /api/platform（或统一 API_BASE 环境变量）
兼容：/api/r/auth/* → rewrite 到 platform（旧书签、旧脚本）

Phase M3 — Dell 算力 + ECS 只留 platform（3～5 天）

tasks / py 任务 → PG（§5，阻塞项）
ECS：下线跑 R 的 biof3-r-server:3011（或缩成仅 platform）；不在 ECS 装 R/Python Docker
Dell：biof3-r-compute + biof3-r-worker + 现有 R 容器；biof3-py-server + py-worker + Python 容器
nginx：/api/platform/ → ECS:3020；/api/r/、/api/py/ → frp/专线 → Dell
platform：tools 提交 tool_jobs；Dell r-worker 执行

Phase M4 — py 瘦身 + 多 Dell 预留（2～4 天）

py-compute 去掉用户/业务 CRUD；JWT 与 platform 一致
文档：新增算力节点 checklist（WORKER_ID、PostgreSQL 连通、Docker、pm2）
前端：/api/platform 登录与 CRUD；/api/r、/api/py 算力
冒烟：platform 登录 + Dell 一条 R + 一条 py

Phase M5 — 清理（1～2 天）

ECS 无「全量 r-server」；Dell 无 auth/data/ai 路由（或仅内网维护口）
PostgreSQL 连接面：ECS biof3-pg 只暴露必要端口；Dell 通过受控 autossh/VPN/专线连接
deploy.sh：--platform-deploy（ECS）、--compute-deploy（Dell）
更新 architecture-target.md、ops-phase-cd-roadmap.md

5. 任务队列：必须 PG（ECS 入队、Dell worker 抢同一库）

队列	今天	拆分后
tool_jobs	PostgreSQL	platform INSERT → r-compute worker UPDATE/执行
tasks（单细胞）	SQLite `biof3.db`	`migrations/pg/005_tasks.sql` + `task-store-pg.js`
py 任务	`pyserver.db` SQLite	`006_py_tasks.sql` 或统一 `tasks` 加 `engine` 列

原则：凡「HTTP 入队 + worker 消费」都走 PostgreSQL，禁止 api/worker 各一份 SQLite。

6. 部署约束

ECS（仅 platform）

项	建议
规格	2～4 vCPU、4～8GB 即可（无 Docker 算力）
进程	`biof3-platform` :3020；不要 R/Python 容器
PostgreSQL	本机 / Docker 网络 `DATABASE_URL`

Dell（算力节点，可多台）

项	建议
Docker	R + Python 容器与现网一致；大盘挂载不变
pm2	`r-compute` + `r-worker`；`py-compute` + `py-worker`（可按机只跑 R 或只跑 Py）
PostgreSQL	每台 worker 同一 `DATABASE_URL`；唯一 `BIOF3_WORKER_ID`
公网	frp/专线供 nginx 反代 `/api/r`、`/api/py`；worker 不必对公网暴露
扩容	新 Dell = 装 Docker + worker +（可选）compute HTTP + 注册 worker_id

7. nginx 示例（ECS `biof3.conf`）

# 控制面
location /api/platform/ {
    proxy_pass http://172.17.0.1:3011/api/;
    # ... 同现有 timeout / body size ...
}

# 算力 — R（反代到 Dell，frp 映射宿主机 3001）
location /api/r/ {
    proxy_pass http://172.17.0.1:3001/api/;
}

# 算力 — Python（反代到 Dell :3002）
location /api/py/ {
    proxy_pass http://172.17.0.1:3002/api/;
}

# 旧客户端兼容入口已退役，避免 /api/r/ catch-all 转到 Dell auth
location /api/r/auth/ {
    return 404;
}

7. 验收清单（「迁移完成」定义）

新用户注册、登录、模块权限仅依赖 platform + ECS Docker PostgreSQL
单细胞：建项目 → 上传 → 提交分析 → Dell r-worker 完成 → 结果在 OSS / PG 状态正确
FigCode：提交工具 job → 完成 → 下载结果
Copilot：对话、计划、Methods（无 helpers_missing）
空间：走 py-compute，登录 token 来自 platform
Dell 重启：platform 仍可用；进行中的 R 任务可失败可重试，不 502 全站
无生产依赖 biof3.db SQLite（tasks 已进 PG）

8. 建议的「第一周」执行顺序

M1：拷贝出 platform-server，ECS 3020 跑通 health + login + GET /api/data/projects
M5 前置：tasks → PG（可与 M1 并行，优先级高）
M2：前端改 API_BASE + nginx /api/platform/
M3：瘦 r-server + Dell worker 只消费 PG tasks
M4：py JWT + 路由文档；nginx 保持 py 在 Dell 直至远程执行设计完成

9. 与已完成的阶段 A/B/C 关系

已完成	本计划
A+B 数据在 PostgreSQL	platform 独占 PG 写；worker 写 task 状态
C3 r API 在 ECS :3011	拆后 :3011 仅 compute；3020 为 platform
C5 py 未切 ECS	M4 后再切；compute 可在 Dell

文档版本：2026-06-05 · 与 docs/ops-phase-cd-roadmap.md 并列维护

10. M3 执行记录（2026-06-05）

完成项

项	状态	说明
`006_tool_jobs.sql`	✅	PG 建表 + 4 个索引（id/uid/status/test/public）
`tools.js` 改 PG	✅	ECS+Dell 共用：删 `db.exec()` 建表，`dbMod.db` → `dbMod.getSqliteForLegacyModules()`
`db.js` 加 PG 连通性检测	✅	`checkPgReachable()`：PG 不通时 fallback SQLite（Dell 家宽网络限制）
ECS platform 重启验证	✅	`PG reachable` + `/api/platform/health` 200
Dell r-server/r-worker 重启验证	✅	`PG reachable` + `/api/r/health` 200
ECS tool_jobs INSERT 测试	✅	`/api/platform/tools/history` → PG 查询正常
`tool_jobs` 数据一致性	✅	ECS+Dell 共 264 条，已完成迁移

技术债务

Dell → RDS 网络限制：Dell（家庭宽带）无法直连阿里云 VPC 内 RDS → 当前不再以阿里云托管 RDS 为目标；Dell 通过 autossh 本地转发 localhost:5433 连接 ECS Docker PostgreSQL。

~~Dell tool_jobs 数据迁移未完成~~ → 已完成。

11. M4 执行记录（2026-06-06）

完成项

项	状态	说明
`tasks` 表加 `engine` 列	✅	PG `ALTER TABLE tasks ADD COLUMN engine TEXT CHECK (engine IN ('R','Python'))`
`engine` 索引	✅	`idx_tasks_engine_status` 复合索引
r-server `task-store-pg.js` engine 写入	✅	`INSERT tasks` 加 `engine='R'`
r-server `task-store-pg.js` claim 过滤	✅	`WHERE engine='R'`
r-server `worker.js` tick 超时保护	✅	`Promise.race` 12s claim 超时，防止 busy 锁死
r-server `db-pg.js` pool 超时	✅	`connectionTimeoutMillis: 15000`, `statement_timeout: 10000`, 预热连接
Dell r-worker 重启验证	✅	PG R 任务可被正确 claim (`worker_id=devah`)
py-server `task-store-pg.js`	✅	新建，独立 PG 模块，导出 `asyncClaimPendingTask` + 同步 wrapper
py-server `db-pg.js`	✅	同步 r-server 配置（timeout + 预热）
py-server `task-store.js` PG 切换	✅	`USE_TASK_PG` 开关，PG 走 `task-store-pg.js`，SQLite fallback
py-server `task-queue.js` 完全异步化	✅	去同步化：`setInterval` → `drainQueue()` → `executeTask()` fire-and-forget
py-server ecosystem.config.js 环境变量	✅	`DATABASE_URL`, `BIOF3_P2_PG`, `OSS_*` 全量配置
Dell py-worker PG 连接验证	✅	`engine='Python'` 正确写入，worker_id='py-dell'

架构现状（M4 后）

路径	实际处理	数据存储
`/api/platform/*`（ECS）	`biof3-platform:3011`	ECS Docker PostgreSQL (`biof3-pg`)
`/api/r/*`（Dell）	`biof3-r-server:3001`（`api` 模式）	PG tasks (engine='R')
`/api/py/*`（Dell）	`biof3-py-server:3002`（`api` 模式）	PG tasks (engine='Python')
所有 workers	Dell `biof3-r-worker` / `biof3-py-worker`（`worker` 模式）	PG tasks 共享队列，engine 隔离

注意：ECS platform 实际端口由 /etc/biof3.env 中 R_SERVER_PORT 决定（2026-06-06 为 3011）。nginx 代理配置需同步保持一致。

待完成

~~py-server JWT_SECRET 同步~~ → ✅ 已同步（py-server/ecosystem.config.js） ~~ECS platform 配置 JWT_SECRET~~ → ✅ 已确认（/etc/biof3.env 加载正确）

nginx 端口变更记录（3020→3011）已同步至 infra/nginx/biof3.conf
Dell r-worker BIOF3_WORKER_ID 配置为固定值（当前为 devah，应与 PM2 hostname 一致）

静态文件

离线资料下载

手册 HTML / PDF 已在后台预生成，点击后直接下载网站静态资源。

本篇 HTML 本篇 PDF说明

1. 目标拓扑​

1.1 谁在哪（核心）​

1.2 多台 Dell 怎么扩​

1.3 用户流量示意​

1.4 与「Dell 纯 Worker」旧说法的差异​

2. 现状 vs 目标（能力表）​

2. 路由归属清单（从 r-server 拆出）​

2.1 → platform-api（控制面）​

2.2 → r-compute + r-worker（Dell，目录仍 r-server/）​

2.3 → py-compute + py-worker（Dell，目录 py-server/）​

3. 代码组织（推荐目录）​

4. 分阶段实施（建议顺序）​

Phase M0 — 文档与开关（1 天）​

Phase M1 — 拉起 platform-api（2～3 天）​

Phase M2 — nginx 双轨 + 前端灰度（2 天）​

Phase M3 — Dell 算力 + ECS 只留 platform（3～5 天）​

Phase M4 — py 瘦身 + 多 Dell 预留（2～4 天）​

Phase M5 — 清理（1～2 天）​

5. 任务队列：必须 PG（ECS 入队、Dell worker 抢同一库）​

6. 部署约束​

ECS（仅 platform）​

Dell（算力节点，可多台）​

7. nginx 示例（ECS biof3.conf）​

7. 验收清单（「迁移完成」定义）​

8. 建议的「第一周」执行顺序​

9. 与已完成的阶段 A/B/C 关系​

10. M3 执行记录（2026-06-05）​

完成项​

技术债务​

11. M4 执行记录（2026-06-06）​