Sub2API 分阶段部署调研与决策建议

调研与仓库核对日期：2026-07-19
适用场景：面向中国大陆用户，以中国香港为首发地域，前期主要转发第三方模型 API，不在本机运行模型。
价格口径：本文按当前购买页看到的中国香港 4 vCPU / 8 GB / 70 GB / 页面显示不限流量 / Max 200 Mbps / US$32/月 作为服务器基线；订阅、备份、对象存储、域名和监控费用另计，并以结账页为准。

一页结论

现在可以这样上线，而且是合理的 MVP 方案：

text

Zeabur 中国香港 4C8G / 70GB（单机故障域）
└─ 同一个 Project，内部网络互通
   ├─ Sub2API        仅它暴露 HTTPS
   ├─ PostgreSQL     持久化卷，不开放公网
   └─ Redis          持久化卷，不开放公网

独立 S3 兼容对象存储（最好不同账号或不同供应商）
└─ PostgreSQL 定时备份、配置与恢复材料

这套配置适合以下前提：

100～500 指注册或低频用户，不是 100～500 条同时活跃的长连接；
峰值活跃 SSE/WebSocket 流大致在 20～30 以内；
文本请求为主，大图片、批量任务和本地文件存储较少；
团队能接受服务器故障后停服 2～4 小时，但不能接受业务数据永久丢失；
上游 API 从香港访问符合上游地区、账号和转售条款。

现在不建议做的事：

不要仅因为“以后可能有 500 个用户”就先买三台服务器；
不要为 PostgreSQL 和 Redis 各买一台普通服务器，却仍然只有单实例；这只是把一个单点拆成多个单点；
不要一开始上 Kubernetes；
不要把容器 Volume、主机快照或 Zeabur 7 天备份中的任何一个单独当作完整备份方案；
不要假设“香港、腾讯云或 200 Mbps”就等于 CN2/精品线路。

开始有收入以后，第一笔基础设施预算优先花在 PostgreSQL 数据保护上，而不是立刻复制应用服务器。 当业务已经不能接受单机停服，再进入“两应用副本 + 负载均衡 + 托管 PostgreSQL + 托管 Redis”的同地域、同 VPC 架构。

1. 为什么 4C8G 对当前业务是可行起点

Sub2API 自己不做模型推理。大部分计算和首字延迟发生在第三方模型 API，服务器主要承担：

鉴权、路由、额度与计费；
PostgreSQL 事务和用量写入；
Redis 并发槽位、队列、缓存、锁与 Pub/Sub；
SSE/WebSocket 长连接转发；
日志、后台任务和少量加解密。

因此，早期容量更接近“长连接网关 + 小型数据层”，而不是 GPU 推理服务。4C8G 的主要风险通常不是 CPU 算不动，而是：

默认连接池太大，挤占 PostgreSQL/Redis 和整机内存；
日志、镜像和本机备份填满 70GB 磁盘；
单台服务器或单块磁盘故障；
香港到中国大陆三网线路在晚高峰抖动；
平台代理对 SSE/WS 的超时、缓冲或发布断流。

建议的资源预算

下表是起始约束，不是性能承诺：

组件	建议内存预算	说明
系统与 Zeabur/K3s	约 1GB	给平台组件和内核留空间
Sub2API	约 2GB	文本流为主；图片和批量任务需提高
PostgreSQL	约 2.5GB	包括连接、缓存和维护操作
Redis	约 0.75GB	必须限制最大内存，不能挤爆宿主机
页缓存与安全余量	约 1.75GB	不直接分满，为突发和页缓存留空间

建议先收敛连接池：

dotenv

DATABASE_MAX_OPEN_CONNS=20
DATABASE_MAX_IDLE_CONNS=5
DATABASE_CONN_MAX_LIFETIME_MINUTES=30
DATABASE_CONN_MAX_IDLE_TIME_MINUTES=5

REDIS_POOL_SIZE=64
REDIS_MIN_IDLE_CONNS=8

当前仓库程序默认数据库池为 256/128、Redis pool 为 1024；这些默认值偏向高并发，不适合照搬到单机 4C8G。若压测出现 pool wait，先确认 PG/Redis CPU、内存和 IO 仍有余量，再小步增加。

70GB 是否够用

MVP 可以，但必须把磁盘当作受限资源：

PostgreSQL、Redis 和应用各自挂持久化卷；
备份完成后上传到外部对象存储，不在本机长期保留；
Docker 镜像和日志设置轮转与保留期；
磁盘使用率达到 60% 开始处理，70% 视为升级信号；
图片或大文件尽早放对象存储，不把主机当文件仓库。

2. 容器是否稳定：问题不在“是不是容器”

单机 Docker/Compose 或平台容器是同类项目的常见 MVP 路线。容器本身不会让 PostgreSQL 天生不稳定；真正决定稳定性的因素是：

数据目录是否放在持久化卷；
镜像是否固定版本或 digest；
是否设置 restart policy、资源上限和健康检查；
数据库升级是否遵循版本与迁移流程；
是否有独立备份、告警和实际恢复演练；
服务器、磁盘和数据库是否仍处于同一个故障域。

所以可以把 PG 和 Redis 作为容器部署，但要准确理解边界：

能力	同机容器能否提供
容器重启后数据仍在	可以，前提是正确挂载 Volume
低成本、快速部署	可以
主机损坏后自动恢复	不可以
PostgreSQL PITR	默认不可以
数据库主备自动切换	不可以
跨节点高可用	不可以

MVP 阶段接受的是“服务可能停，但数据能够从别处恢复”，而不是把单机包装成高可用。

3. 业界同类项目怎么部署

本次只使用项目官方仓库或官方部署文档。对比结果很一致：快速启动普遍允许单机容器；承担稳定收入与明确 SLO 后，才把应用无状态化、把数据层迁到托管或高可用基础设施。

项目	官方的小规模路径	官方的生产/扩展路径	对 Sub2API 的启示
New API	Compose 同机运行应用、PostgreSQL、Redis	多节点要求统一 `SESSION_SECRET`，共享数据库和 Redis	与 Sub2API 最接近，验证三服务 MVP 很常见
One API	Compose 运行应用、Redis、MySQL	多节点共享同一 SQL，统一 `SESSION_SECRET`	“多应用”不等于“每台各自一套数据”
LiteLLM	Compose 运行 Proxy、PostgreSQL、Prometheus	官方 Terraform/云方案使用 LB、托管数据库、Redis、对象存储和 Secret 管理	更接近有稳定收入后的目标架构
Helicone	Docker/Compose 用于快速、小规模自托管	Kubernetes 用于扩展性和韧性	K8s 是阶段选择，不是 MVP 前提
Portkey	OSS Gateway 可以单容器运行	企业 EKS 建议至少两个节点跨 AZ，Redis 与 Gateway 同 VPC，日志进入对象存储	API 转发本身很轻；HA 成本主要来自冗余和数据保障

官方依据：

这里不能简单照抄纯代理网关的最低配置。Sub2API 还保存用户、余额、订单、API Key、账号、用量和运维数据，PostgreSQL 是业务事实来源；Redis 也不只是可随时清空的页面缓存。

4. 推荐的三个阶段

阶段 A：MVP / 尚未形成稳定收入

目标：最低成本验证业务，允许单机停服，但要求数据可恢复。

text

Internet
   │
DNS / TLS / Zeabur Ingress
   │
Sub2API（唯一公网服务）
   │ private hostname
   ├─ PostgreSQL + Volume
   └─ Redis + Volume

Independent Object Storage
   └─ pg_dump/gzip + 配置恢复材料

建议指标：

规划并发：峰值活跃流 20～30 以内；
RPO：6～24 小时；
RTO：2～4 小时；
可用性：不承诺主机级 HA；
成本：当前服务器 US$32/月，加平台订阅、独立对象存储和基础监控；不含上游 API 成本。

此时 PostgreSQL 和 Redis 不用拆服务器。在同一 Project 内使用内部 hostname 即可，5432/6379 不开放公网。

阶段 B：开始有收入，但停机尚未致命

“收到第一笔钱”和“业务必须高可用”不是同一件事。刚开始收费时，最优先解决的是数据回退，而不是堆机器。

推荐升级顺序：

PostgreSQL 迁到同一香港地域、可私网访问的托管 PostgreSQL；
开启自动备份、PITR，并保留独立逻辑备份；
再把 Redis 迁到标准单分片、主从高可用的托管 Redis；
应用暂时仍可单实例，前提是能接受短时停服；
用恢复演练验证迁移，而不是只看控制台显示“备份成功”。

目标可以提高到：

PostgreSQL RPO：5～15 分钟，取决于产品的 PITR 能力；
整体 RTO：1～2 小时；
数据层与应用同 Region、同 VPC；
仍可接受应用主机故障后的人工重建。

这是性价比最高的“收入早期”方案：先去掉最昂贵的数据风险，同时避免过早承担双应用、LB、集群和复杂发布流程。

阶段 C：收入已重要 / 停机直接造成损失

当需要不停机发布、单应用节点故障不影响新请求，或明确承诺 SLA 时，目标拓扑为：

text

同一中国香港 Region / VPC

Internet
   │
L7 Load Balancer
   ├───────────────┐
   ▼               ▼
Sub2API A        Sub2API B
Zone A            Zone B
   └──────┬────────┘
          │ private VPC
          ├─ Managed PostgreSQL HA + PITR
          └─ Managed Redis（单分片主从）

Object Storage / Secret Manager / Central Logs / Monitoring

建议目标：

RPO：5～15 分钟；
RTO：30～60 分钟；
两个应用副本固定相同镜像、JWT_SECRET、TOTP_ENCRYPTION_KEY 和业务配置；
LB 支持 SSE/WS、长超时、健康检查和 connection draining；
生产发布逐台摘流、验证、再加回；
没有成熟 K8s 运维能力时，两台 VM/容器服务器已经足够，不必为了两个副本上 K8s。

这一阶段的香港基础设施预算可先按 约 1,800～4,500 元/月 做规划占位，但这不是供应商报价；最终取决于线路、两台应用机、托管 PG/Redis 规格、LB、备份和日志保留。上游 API 成本另算。

5. 什么时候升级：不要用注册用户数单独判断

满足任一条件，就应评估进入下一阶段：

付费用户已经依赖服务，单次停机损失高于新增基础设施月费；
业务要求 RPO 小于 24 小时，或恢复不能依赖人工重建单机；
峰值活跃 SSE/WS 持续超过 20～30；
应用 CPU 持续高于 60%，内存持续高于 70%；
PG 出现连接等待、慢查询、IO 饱和或备份影响业务；
Redis 内存或连接接近 60%～70%，出现延迟或 evicted_keys > 0；
磁盘超过 60%，而且无法通过日志/数据保留策略解决；
需要不停机发布、自动故障切换或明确 SLA。

100 个持续运行 Agent 的团队用户，可能比 500 个偶尔调用的个人用户更重。应记录：活跃长连接数、请求时长、QPS、TTFT、出站带宽、PG pool wait、Redis 延迟、用量写入队列和上游 429/5xx，而不是只看账号总数。

6. 数据备份：本方案最重要的上线门槛

先定义恢复目标

MVP 的建议承诺：

RPO 6～24 小时：最坏可能丢失最近一次成功备份之后的数据；
RTO 2～4 小时：从服务器不可用到新环境恢复核心服务；
不承诺单机无停机，但必须能在没有原服务器的情况下恢复。

有稳定收入后，把 PostgreSQL 改为带 PITR 的托管实例，将 RPO 降到 5～15 分钟，并把 RTO 降到 30～60 分钟。

MVP 至少保留三层材料

平台备份：如果订阅方案支持，开启 Zeabur PostgreSQL 每日在线备份。官方说明自动备份为每日一次、仅保留 7 天，更长期需要自行下载到别处。Zeabur Backup
Sub2API 外部备份：当前项目内置 pg_dump -> gzip -> S3、保留清理、下载和恢复能力，应配置到独立 S3 兼容对象存储；不要把 Bucket 放在同一台服务器。
恢复清单：备份固定 secrets、域名/DNS、镜像 tag/digest、环境变量模板、对象存储权限和一份从零重建步骤。密钥材料必须加密，不把明文 secret 放入普通文档或 Git。

推荐策略：

项目	MVP 建议
PG 逻辑备份	每 6～24 小时一次
保留	7 份每日、4 份每周、6 份每月，可按数据量调整
备份位置	独立账号或独立供应商的对象存储
发布前	手动再做一次备份并记录镜像版本
恢复演练	每月一次，恢复到隔离 PostgreSQL
监控	最近成功备份超过两个周期立即告警

Redis 建议开启 AOF + RDB、保留持久化卷，并定期把 Redis 持久化数据复制到外部备份位置，不能只备份 PG。Sub2API 的 Redis 包含并发槽位、队列、锁、Pub/Sub、调度和部分计费缓存状态；故障恢复后要验证并发和计费一致性，不能简单把它当作无状态页面缓存。

恢复演练的验收标准

在一套隔离 PostgreSQL 中恢复最新备份，至少验证：

管理员和普通用户可以登录；
API Key、账号和渠道数据可读取；
余额、订阅、订单和历史用量数量合理；
新建低额度测试 Key 后可以完成一次真实流式请求；
新用量能够入库且扣费正确；
记录恢复用时、缺少的 secret、手工步骤和失败原因。

没有完成过一次从对象存储到隔离数据库的恢复，不能把“控制台里存在备份文件”视为备份方案已经验收。

7. 多服务器和内网应该怎么做

现在：已经应该用内部网络，但不用额外买“内网服务器”

Zeabur 官方私网 hostname 用于同一 Project 的服务间通信，例如 postgresql.zeabur.internal。当前就应该：

只公开 Sub2API 的 HTTPS；
Sub2API 通过内部 hostname 连接 PG/Redis；
不给 PG/Redis 创建公网域名或端口；
用平台防火墙限制管理入口。

Zeabur Private Networking 的公开承诺是“同一 Project 内服务互通”。不要据此推定任意两台独立 Server 天然处于同一个隔离 VPC。

后面：多服务器必须使用真正的同地域私网

推荐顺序是：

选择能把两台应用机、托管 PG、托管 Redis 放进同一香港 VPC 的云产品；
只让 LB 暴露公网；应用节点仅接受 LB/安全组私网流量；
PG/Redis 只开放给应用安全组；
跨主机数据库连接启用 TLS；
若继续使用 Zeabur，先取得多 Server 私网、故障切换和 Volume 行为的书面确认；需要自动跨节点调度时，官方路径是 Dedicated Cluster，而不是把两台独立 Server 手工拼接。Zeabur High Availability

不推荐用公网 IP + 白名单伪装成内网作为长期生产架构。它可以临时迁移，但会增加带宽、延迟、证书、防火墙和公网暴露风险。

8. Sub2API 多副本前必须处理的代码边界

当前仓库并非所有后台任务都天然适合两个应用进程同时运行：

backend/internal/service/backup_service.go 的 cron 和 backingUp 互斥只在单进程内生效；两个副本会各自启动定时器，可能重复备份或竞争同一份备份记录；
backend/internal/service/channel_monitor_runner.go 也是每个应用进程各自启动，当前没有看到跨实例 leader lock；
数据库 migration、部分 Ops 和 scheduler cleanup 已使用 PostgreSQL advisory lock，说明项目已有可复用的分布式互斥模式；
backend/cmd/server/main.go 收到 SIGTERM 后只给 HTTP Server 5 秒 shutdown；对长 SSE/WS 来说，LB 必须先摘流和等待，不能直接停止容器；
/health 仅返回进程存活，不检查 PostgreSQL、Redis 或真实上游。

因此，在阶段 C 上第二个应用副本前，应完成以下任一方案：

给备份、渠道监控等定时任务增加 PostgreSQL advisory lock 或 Redis leader lock；或
明确拆分一个 worker/leader 角色，只有一个实例运行定时任务；应用副本只处理请求。

同时补充 dependency/readiness probe，并把 LB draining 时间按最长正常请求校准。否则“两个副本”可能增加重复任务和发布断流，并不等于真正高可用。

9. 香港线路和延迟怎么判断

香港到中国大陆的物理距离通常不是主要问题，第三方模型响应往往以秒计；多出几十毫秒对总响应的影响可能不大。更值得关注的是晚高峰丢包、路由绕行、TLS 建连和长连接重连。

当前规格只写了 Max 200 Mbps，不能证明是 CN2、精品 BGP 或三网优化。付款前或退款窗口内，应从中国电信、联通、移动分别测试：

早晚高峰 RTT、丢包和 TCP/TLS 建连时间；
首页和普通 API 的 p50/p95/p99；
30 分钟 SSE 持续输出，是否被缓冲或断开；
60 分钟 WebSocket 心跳与重连；
真实上游 API 的成功率、TTFT 和 429/5xx；
Cloudflare 代理和直连 Zeabur 两种路径。

如果三网中某一网络持续不达标，再考虑明确标注 CN2/精品 BGP 的香港 VPS、全球加速或大陆备案后的境内节点。不要先为“也许会慢”支付高额线路费，也不要在没有实测时把普通香港线路当成 CN2。

10. 最终决策表

问题	当前建议	原因
US$32 的香港 4C8G/70GB 能否先用	可以	对 API 转发型 MVP 足够，前提是低到中等峰值并发和磁盘治理
是否部署三个容器/服务	是	Sub2API、PG、Redis 分服务，同机共享资源和内部网络
PG/Redis 现在是否要分服务器	不需要	成本增加，但仍是单实例，备份和 HA 没有本质改善
容器 PG 是否不稳定	不是这个判断方式	Volume、备份、恢复演练和故障域才是关键
是否只用 Zeabur 自动备份	不可以	官方保留 7 天，无 PITR，必须有独立对象存储副本
是否现在做多服务器内网	不用额外做	当前同 Project 私网已够用；多服务器时再采用真实同地域 VPC
有第一笔收入是否立刻双机	不一定	先升级 PG 备份/PITR 的收益通常更高
何时双应用 + LB	停机开始造成明确损失时	以 RPO/RTO、并发和发布要求决定，不以注册用户数决定
是否上 Kubernetes	当前不建议	两台 VM/容器服务器足以覆盖早期 HA，K8s 运维成本过高

11. 推荐执行计划

上线前

[ ] 确认 US$32 套餐的续费价、磁盘类型、∞ 流量的公平使用/限速规则和退款窗口；
[ ] 向 Zeabur 确认线路是否 CN2/精品 BGP，不确认就按普通线路评估；
[ ] 确认 Dev/备份功能是否另收费，以及出口 IP 是否固定；
[ ] 固定 Sub2API 镜像 tag/digest，不使用旧社区模板或长期使用 latest；
[ ] 创建 Sub2API、PostgreSQL、Redis 三个服务，PG/Redis 不开放公网；
[ ] 为 PG/Redis 挂 Volume，Redis 开启 AOF + RDB；
[ ] 收敛 PG/Redis 连接池，设置固定 JWT/TOTP secret；
[ ] 配置独立 S3 兼容对象存储与 Sub2API 定时备份；
[ ] 完成一次空环境恢复演练；
[ ] 做三网晚高峰和 30 分钟 SSE 测试。

上线后第一个月

[ ] 记录峰值活跃流、CPU、RSS、磁盘、PG pool wait、Redis 内存和出站流量；
[ ] 每日检查最近备份是否成功；
[ ] 每周检查日志、镜像和最大数据表增长；
[ ] 每月恢复一次，记录真实 RTO；
[ ] 服务器磁盘达到 60% 即处理，不等 90%；
[ ] 用数据判断是否需要更好的香港线路，而不是只看单次 ping。

收入形成后

[ ] 先采购同地域托管 PostgreSQL，验证 session-level advisory lock 和 PITR；
[ ] 再迁 Redis，验证 Lua、ZSET、Pub/Sub、锁和重连；
[ ] 需要应用 HA 前，先处理进程内 cron/monitor 和 5 秒 shutdown 边界；
[ ] 最后增加第二应用节点和 LB，执行摘流与故障演练。

最终建议

建议现在就用这台 US$32/月的香港 4C8G 机器跑起来，部署 Sub2API、PostgreSQL、Redis 三个服务。 这不是“临时凑合”，而是同类产品很常见、与当前风险相匹配的 MVP 架构。

但上线的硬条件不是再买一台服务器，而是：外部 PostgreSQL 备份、实际恢复演练、连接池收敛、磁盘告警、三网和长连接测试。 如果这些没有做，拆成多台机器也不会真正安全。

后续有收入时按“PostgreSQL PITR → 托管 Redis → 第二应用节点和 LB”的顺序升级。多服务器阶段再采用同一香港 Region/VPC 的私网架构；不要前期手工拼接跨服务器网络，也不要提前承担 Kubernetes 的成本。

Sub2API 分阶段部署调研与决策建议 ​

一页结论 ​

1. 为什么 4C8G 对当前业务是可行起点 ​

建议的资源预算 ​

70GB 是否够用 ​

2. 容器是否稳定：问题不在“是不是容器” ​

3. 业界同类项目怎么部署 ​

4. 推荐的三个阶段 ​

阶段 A：MVP / 尚未形成稳定收入 ​

阶段 B：开始有收入，但停机尚未致命 ​

阶段 C：收入已重要 / 停机直接造成损失 ​

5. 什么时候升级：不要用注册用户数单独判断 ​

6. 数据备份：本方案最重要的上线门槛 ​

先定义恢复目标 ​

MVP 至少保留三层材料 ​

恢复演练的验收标准 ​

7. 多服务器和内网应该怎么做 ​

现在：已经应该用内部网络，但不用额外买“内网服务器” ​

后面：多服务器必须使用真正的同地域私网 ​

8. Sub2API 多副本前必须处理的代码边界 ​

9. 香港线路和延迟怎么判断 ​

10. 最终决策表 ​

11. 推荐执行计划 ​

上线前 ​

上线后第一个月 ​

收入形成后 ​

最终建议 ​

Sub2API 分阶段部署调研与决策建议

一页结论

1. 为什么 4C8G 对当前业务是可行起点

建议的资源预算

70GB 是否够用

2. 容器是否稳定：问题不在“是不是容器”

3. 业界同类项目怎么部署

4. 推荐的三个阶段

阶段 A：MVP / 尚未形成稳定收入

阶段 B：开始有收入，但停机尚未致命

阶段 C：收入已重要 / 停机直接造成损失

5. 什么时候升级：不要用注册用户数单独判断

6. 数据备份：本方案最重要的上线门槛

先定义恢复目标

MVP 至少保留三层材料

恢复演练的验收标准

7. 多服务器和内网应该怎么做

现在：已经应该用内部网络，但不用额外买“内网服务器”

后面：多服务器必须使用真正的同地域私网

8. Sub2API 多副本前必须处理的代码边界

9. 香港线路和延迟怎么判断

10. 最终决策表

11. 推荐执行计划

上线前

上线后第一个月

收入形成后

最终建议