Sub2API 101

Appearance

中国大陆与亚太生产部署分阶段方案 ​

适用版本：以 2026 年 7 月当前仓库为准。本文给出的是容量规划与运维基线，不是对任何上游服务地区授权、转售许可或中国大陆监管资质的替代判断。

配套的厂商区域、产品、HA、备份、跨境资质与官方计价入口核查，见中国大陆与亚太生产部署云厂商调研。

先给结论 ​

  1. 应用优先使用 Docker 镜像部署。 第一阶段用 Docker Compose 最省事；第二阶段仍然用容器，但改为只运行 Sub2API 应用的 docker-compose.standalone.yml，PostgreSQL 和 Redis 使用同一家云、同一地域、同一 VPC 的托管服务。没有现成 Kubernetes 团队时，不要为了两个应用副本上 Kubernetes。
  2. 第一阶段可以把应用、PostgreSQL、Redis 放在同一台服务器，第二阶段必须拆开。 同机方案只适合验证期或可以接受停机的小规模生产；公开付费服务即使用户不多，也应尽早切换到托管 PostgreSQL、托管 Redis 和至少两个应用副本。
  3. 所有应用副本必须共享同一套 PostgreSQL、Redis 和固定密钥。 不能让每个副本启动自己的 PostgreSQL/Redis，否则用户、余额、用量、并发槽位、缓存失效、leader lock 和后台任务会互相分裂。
  4. PostgreSQL 使用直接主库地址，Redis 使用标准版单分片主从高可用。 不要默认接 transaction-mode PgBouncer；不要默认选择 Redis Cluster 多分片。当前项目使用会话级 PostgreSQL advisory lock，并且 Redis 使用 Lua、ZSET、Pub/Sub、分布式锁和多 key 操作。
  5. 100 或 500 个“注册用户”不是容量单位。 真正决定规格的是峰值并发流、WebSocket 数量、请求持续时间、图片流量、用量写入速度、上游账号并发和数据库增长。本文给出的用户规模都附带了并发假设，必须用真实流量压测校准。
  6. 大陆与亚太不要一开始做跨地域 active-active。 当前 Sub2API 是共享 PostgreSQL/Redis 的单数据平面设计。大陆、香港、新加坡之间共享远程数据库会把延迟和故障域放大；真正的双地域 active-active 需要产品级的数据分区、账务一致性和冲突解决改造，不是改一份 Compose 就能完成。

上线前必须先决定的合规路线 ​

路线 A：中国大陆主站 ​

适合以下条件同时成立的情况：

  • 主要用户位于中国大陆。
  • 运营主体、域名、备案、支付、内容与数据处理手续已经明确。
  • 实际使用的模型和上游渠道允许从中国大陆提供服务，并允许你的账号使用、共享或转售方式。
  • 用户请求中可能包含的个人信息、提示词、文件和日志跨境路径已经完成评估。

技术上可选广州、深圳、上海、杭州或北京。没有真实用户分布时：

  • 华南、大湾区、东南亚用户较多：优先广州或深圳。
  • 华东、华北、日本、韩国用户较多：优先上海或杭州。
  • 不要为了“全国平均”同时建立两个生产主地域；先选一个数据主地域，用真实网络监测再决定是否增加加速或灾备。

域名解析到中国大陆服务器或使用中国大陆 CDN 节点前，需要完成 ICP 备案；备案成功上线后还要按要求完成公安联网备案。阿里云官方备案文档明确说明，即使域名只用于 API，只要解析到中国大陆服务器，也需要备案；中国大陆 CDN 加速同样要求备案：

如果面向公众收费，是否需要增值电信业务经营许可、生成式 AI/算法/深度合成相关备案或其他许可，必须由熟悉实际业务模式的中国大陆律师或合规负责人判断，不能只凭“已经有 ICP 备案”推定可以运营。

路线 B：新加坡 APAC 主站 ​

适合亚太用户是主要用户、使用的上游在新加坡或国际网络可稳定访问、且业务服务地区符合上游条款的情况。新加坡通常比中国大陆地域更容易获得稳定的国际上游链路，但中国大陆用户的时延与网络抖动会更高。

需要特别强调：把服务器放到新加坡不自动获得向中国大陆用户提供上游服务的授权。 例如 OpenAI 当前官方支持地区列表包含新加坡，但未列出中国大陆和中国香港，并明确提示在列表外访问或提供访问可能导致账号被封禁或暂停。实际运营前应取得适用于你的主体、服务器位置、终端用户位置和中转模式的书面确认：

项目自身的 README_CN.md 和 docs/legal/admin-compliance.zh.md 也明确提示了上游条款、地区限制、商业中转、数据处理和中国大陆运营风险。

路线 C：中国香港折中主站 ​

香港在物理距离上适合作为中国大陆与东南亚之间的折中点，且香港服务器本身不要求中国大陆 ICP 备案。但它有三个限制：

  • 没有备案时不能使用中国大陆 CDN 节点获得真正的境内加速。
  • 普通国际 BGP 到中国大陆的质量会随运营商和时段波动。
  • 香港服务器位置不能替代上游厂商的地区与转售授权；部分上游当前并不把香港列为支持地区。

阿里云 BGP（多线）精品 EIP、腾讯云精品 BGP 可以改善香港/新加坡到中国大陆的公网线路，但价格明显高于普通带宽。阿里云官方示例价格为香港 BGP（多线）精品按固定带宽 232 元/Mbps/月，5 Mbps 仅带宽约 1,160 元/月：

跨境全球加速也不是“开关即用”。阿里云 GA 和腾讯云 GAAP 的中国大陆跨境加速均涉及跨境资质审核与合规承诺：

当前项目对基础设施的真实约束 ​

PostgreSQL 是事实来源 ​

PostgreSQL 保存用户、API Key、账号凭证、分组、订阅、余额、订单、用量和运维数据。项目要求 PostgreSQL 15+，启动时会执行向前迁移。回退应用版本不等于回退数据库结构。

项目存在会话级 PostgreSQL advisory lock：

  • 数据库迁移使用 pg_try_advisory_lock。
  • Ops 和 scheduler outbox 清理会通过固定连接持有并释放 advisory lock。
  • 因此应使用托管 PostgreSQL 的直接主库 endpoint，或明确支持 session mode 的连接池。
  • transaction-mode PgBouncer 可能在不同事务间切换后端会话，不应作为默认入口。

相关代码：

  • backend/internal/repository/migrations_runner.go
  • backend/internal/service/ops_advisory_lock.go
  • backend/internal/repository/scheduler_outbox_repo.go

Redis 不是可以随时清空的普通缓存 ​

Redis 承担以下运行时职责：

  • 用户、API Key、账号和平台并发槽位。
  • 等待队列、批量图片队列和 inflight 状态。
  • 调度快照、粘性会话、限流与冷却状态。
  • OAuth/token refresh、后台任务和 leader lock。
  • 多实例 L1 缓存失效 Pub/Sub。
  • 余额、订阅和平台额度的缓存与增量状态。

代码中直接使用了 Lua/EVAL、ZSET、Pub/Sub、SET NX 和多 key 操作。因此托管 Redis 应选择：

  • 原生 Redis TCP/TLS endpoint。
  • 标准版、单分片、主从高可用。
  • 支持 EVAL/EVALSHA、ZSET、Pub/Sub、事务和持久化。
  • 提供稳定的可写 endpoint，并在主从切换后保持地址不变。

不要在没有完整兼容测试前改为 Redis Cluster 多分片。当前客户端初始化使用 redis.Client，不是 ClusterClient；多 key Lua 在分片集群中还可能遇到跨 slot 限制。

相关代码：

  • backend/internal/repository/redis.go
  • backend/internal/repository/concurrency_cache.go
  • backend/internal/repository/billing_cache.go
  • backend/internal/repository/leader_lock_cache.go
  • backend/internal/repository/api_key_cache.go

阿里云 Tair 标准架构官方说明其为单分片、完整 Redis 协议兼容、主从高可用，并支持持久化和备份；腾讯云 Redis 标准架构同样提供主节点、1～5 个副本和自动切换。这两类产品比多分片集群更适合当前项目：

应用是长连接网关，不是普通短请求网站 ​

Sub2API 支持 SSE、WebSocket、HTTP/2 cleartext 和长时间模型请求。HTTP Server 特意不设置全局 WriteTimeout 和 ReadTimeout，因为流式响应和大请求体可能持续较长时间。容量规划必须关注：

  • 同时活跃的 SSE/WS 连接。
  • 应用、反向代理、LB 和上游连接共同消耗的文件描述符。
  • 每条请求的持续时间，而不只是瞬时 QPS。
  • 图片上传、下载和 base64 对内存与带宽的放大。
  • 上游账号池允许的真实并发。

项目默认 stream keepalive 为 10 秒。云 LB 应支持 WebSocket，连接/请求 timeout 至少配置为 600 秒；长图片或长 WS 场景建议申请或设置到 3,600 秒，并开启 connection draining。阿里云 ALB 当前支持 WebSocket，默认可配到 600 秒，配额最高可提高到 3,600 秒：

/health 只证明进程活着 ​

当前 /health 固定返回 {"status":"ok"}，不会检查 PostgreSQL、Redis、账号池和真实上游。因此探针要拆成四层：

  1. LB liveness：GET /health。
  2. 公网 DNS/TLS/Proxy：从外部访问 /health。
  3. 依赖探针：独立检查 PostgreSQL 查询与 Redis PING/Lua。
  4. 业务合成：用低额度专用 Key 定时请求低成本模型，并验证用量成功入库。

默认连接池不能直接照抄到小机器 ​

当前程序默认值和 .env.example 偏向较高并发：

  • 应用数据库池默认 256/128。
  • Redis pool 默认 1024，.env.example 示例甚至为 4096/256。
  • 用量记录 worker 默认 128，自动扩到 512。

Compose 自身把数据库池默认收敛到 50/10，但 Redis 仍是 1024/10。对于 2C4G 或小规格托管实例，这些值过大。

另外，.env.example 中的 POSTGRES_MAX_CONNECTIONS、POSTGRES_SHARED_BUFFERS 等变量当前没有被 docker-compose.local.yml 注入 PostgreSQL 容器，修改它们不会自动完成服务端调优。需要显式增加 PostgreSQL command 参数、挂载配置文件，或直接使用托管 PostgreSQL。

容量口径：把“用户数”转换为可测量指标 ​

以下是规划假设，不是项目官方 benchmark：

业务规模注册/付费用户典型峰值并发流压力峰值说明
小规模验证约 1005～1520～30以文本 SSE 为主，图片较少
稳定运营约 50020～5080～120团队/Agent 用户可能明显更高
增长阶段500+80～200200～400+需要根据真实模型、请求时长和上游容量压测

如果 100 个用户都是持续运行 Agent 的企业用户，容量可能高于 500 个低频个人用户。扩容判断应以以下指标为准：

  • 峰值活跃 SSE/WS 数。
  • 新连接数、平台 QPS、请求持续时间和 TTFT。
  • 应用 CPU、内存、goroutine、fd 和网络。
  • PostgreSQL active/waiting、CPU、IOPS、慢查询和 WAL。
  • Redis CPU、内存、连接数、命令延迟、blocked clients 和 evicted keys。
  • usage worker queue、write failure、scheduler outbox lag。
  • 上游账号 in-use、queue、429/529 和切换率。

文本流量可用下面的公式估算出口带宽：

text
文本出口 Mbps ≈ 活跃流数量 × 每条流平均 KB/s × 8 / 1024

例如 100 条流平均 10 KB/s，纯文本出口约 7.8 Mbps。图片和大文件必须单独计算，不能套用文本估算。

第一阶段：0～100 用户，最低成本可恢复生产 ​

目标 ​

  • 快速上线并验证真实流量。
  • 接受单机故障会停服，但要求数据有异地备份且可以恢复。
  • 不以首年促销价为长期成本基线。

推荐拓扑 ​

text
Internet
   │
DNS / HTTPS
   │
Caddy 或 Nginx（宿主机）
   │ 127.0.0.1:8080
   ▼
单台云服务器 4C8G / 100GB SSD
   └─ Docker Compose
      ├─ Sub2API
      ├─ PostgreSQL
      └─ Redis AOF + RDB

异地对象存储
   ├─ 每日 pg_dump
   ├─ 配置与密钥加密备份
   └─ 每周主机/数据盘快照

服务器规格 ​

条件最低规格推荐规格
内测、并发不超过 10、文本为主2 vCPU / 4 GB / 80～100 GB SSD4 vCPU / 8 GB
公开小规模生产、峰值 10～30 并发不建议 2C4G 长期运行4 vCPU / 8 GB / 100 GB SSD
图片/批量任务较多4C8G 仅作为起点8C16G 或提前进入第二阶段

公网带宽：

  • 中国大陆文本业务从 5～10 Mbps 起步，流量波动大时可选择按流量计费并设置较高峰值上限。
  • 香港/新加坡普通 BGP 应先从多个中国大陆运营商实测；需要精品 BGP 时要把高额固定带宽费单列。
  • 图片与大文件应尽早走对象存储和 CDN，不要长期由 Sub2API 主机直接承担所有文件出口。

部署方式 ​

使用 deploy/docker-compose.local.yml，但做以下生产修订：

  • 固定镜像版本或 digest，禁止长期使用 latest。
  • BIND_HOST=127.0.0.1，只让宿主机 Caddy/Nginx 访问 8080。
  • 不暴露 5432/6379。
  • PostgreSQL、Redis 和应用数据使用明确的数据目录或独立数据盘。
  • 设置随机 POSTGRES_PASSWORD、REDIS_PASSWORD、固定 JWT_SECRET 和 TOTP_ENCRYPTION_KEY。
  • 开启 URL allowlist，关闭私网地址和非 HTTPS 上游。

建议的小规格连接池起点：

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

如果 30 分钟压测中 Redis pool wait 明显，再提高到 128；不要一开始设置 1024 或 4096。

小机器还应通过 config.yaml 收敛用量 worker：

yaml
gateway:
  usage_record:
    worker_count: 32
    queue_size: 4096
    task_timeout_seconds: 5
    overflow_policy: sync
    auto_scale_enabled: true
    auto_scale_min_workers: 32
    auto_scale_max_workers: 128

overflow_policy 保持 sync。drop 或 sample 会造成用量、扣费和对账缺口，不适合默认生产。

运维基线 ​

  • 每日：外部 /health、一次真实流式请求、错误率、账号可用率、磁盘、PG/Redis、备份任务。
  • 每周：检查最大表/索引、Redis 内存、日志体积、上游账号到期与限流。
  • 每月：把最近备份恢复到隔离 PostgreSQL，验证登录、API Key、账号、余额和历史用量。
  • 发布前：额外 pg_dump，记录镜像版本与 migration，低峰升级。
  • 备份：每日逻辑备份保留 7～30 天；每周快照保留 4～8 份；至少一份在独立账号或区域。

阶段一建议目标：

  • RPO：不超过 24 小时。
  • RTO：2～4 小时。
  • 可用性：不承诺主机级高可用。

第一阶段成本 ​

中国大陆长期预算建议按 300～900 元/月 估算，包括一台常规云服务器、系统/数据盘、5～10 Mbps 或等量流量、对象存储备份与基础监控，不含 AI 上游调用费、短信、邮件和人工运维。

首年活动可能远低于此范围，但不能作为续费预算。例如：

  • 腾讯云当前官网示例中，北京 2C4G、50 GB、1 Mbps 的 CVM 为 1,567 元/年。
  • 阿里云当前符合条件的新用户 2C4G、80 GB、5 Mbps 活动机可低至 199 元/年。

这些都是活动或特定实例价格，续费、磁盘和带宽以购买页为准：

香港/新加坡普通网络建议按 800～2,500 元/月 起步；精品 BGP、全球加速和高流量可能让网络费用超过计算费用。

进入第二阶段的触发条件 ​

满足任一项就应升级，不必等到 500 用户：

  • 已开放付费，单机停机造成的损失高于两台应用和托管数据库成本。
  • 峰值活跃流持续超过 20～30。
  • 应用 CPU 持续高于 60% 或内存持续高于 70%。
  • PostgreSQL 出现持续连接等待、IOPS 饱和或慢查询。
  • Redis 延迟、内存或连接开始接近 60%～70% 容量。
  • 磁盘达到 60%，且 usage/log 增长无法通过保留策略控制。
  • 要求不停机发布、自动故障转移或 RPO 小于 24 小时。

第二阶段：100～500 用户，单地域高可用生产 ​

目标 ​

  • 应用层无单点。
  • PostgreSQL、Redis 使用托管高可用产品。
  • 发布时通过滚动和 draining 尽量不影响新请求。
  • 所有数据服务和应用保持同地域、同 VPC 私网访问。

推荐拓扑 ​

text
Internet
   │
DNS / WAF（可选）
   │
公网 ALB / CLB
   ├─────────────┐
   ▼             ▼
App A 4C8G    App B 4C8G
Zone A         Zone B
Docker         Docker
   └──────┬──────┘
          │ private VPC
          ├─ Managed PostgreSQL HA 2C4G / 100GB
          └─ Managed Redis Standard HA 1GB

对象存储 / 日志 / Secret Manager / 云监控

应用部署 ​

  • 使用 deploy/docker-compose.standalone.yml，每台服务器只运行一个 Sub2API 容器。
  • 两个副本固定同一镜像版本、JWT_SECRET、TOTP_ENCRYPTION_KEY、时区、URL allowlist、OAuth/支付 secret 和网关配置。
  • 应用节点使用私网地址加入 LB，8080 不开放公网。
  • 本地日志由采集 agent 发送到 SLS/CLS/LTS 等集中日志服务；不依赖单机日志做审计事实来源。
  • 配置来自 Secret Manager/参数服务或受控配置仓库，不手工逐台修改。

建议每副本连接池起点：

dotenv
DATABASE_MAX_OPEN_CONNS=20
DATABASE_MAX_IDLE_CONNS=5
REDIS_POOL_SIZE=64
REDIS_MIN_IDLE_CONNS=8

两个副本的数据库理论应用上限为 40。数据库 max_connections 还要为迁移、备份、监控、管理员和临时扩容预留至少 20%～30%。只有出现真实 DB pool wait 且数据库 CPU/IO 仍有余量时，才增加连接池。

托管 PostgreSQL ​

推荐：

  • PostgreSQL 15+。
  • 高可用版，主备跨可用区。
  • 2 vCPU / 4 GB 起步；报表和 raw usage 查询较重时使用 4 vCPU / 8 GB。
  • 100 GB SSD 起步并启用自动扩容或容量告警。
  • 自动备份、PITR 7～30 天、升级前手动快照、跨地域备份。
  • 只开放 VPC 白名单，应用使用直接主库 endpoint。
  • 跨主机连接启用 SSL；如果云服务提供 CA，优先 verify-full。

不要为了“连接更多”立即启用数据库代理。先确认代理的会话语义，尤其是 advisory lock；默认使用直接 endpoint 最稳妥。

阿里云 RDS PostgreSQL 高可用版为主备架构，支持跨可用区和自动切换；腾讯云 PostgreSQL 提供一主一从高可用和自动/日志备份：

托管 Redis ​

推荐：

  • 标准架构、单分片、主从高可用。
  • 1 GB 起步；不因为实例便宜就选无持久化单节点。
  • 开启备份、自动故障转移和内存/连接/延迟告警。
  • 不设置会导致业务 key 被静默删除的激进 LRU 策略；生产目标是 evicted_keys=0。
  • 切换演练必须验证 Lua、Pub/Sub、锁、并发槽位和应用自动重连。

负载均衡和长连接 ​

  • 使用 L7 ALB/CLB，支持 HTTPS、HTTP/2、SSE 与 WebSocket。
  • API 路径全部禁用缓存；仅 /assets/* 等带 hash 静态资源长期缓存。
  • listener idle/request timeout 至少 600 秒，图片或长 WS 场景配置/申请 3,600 秒。
  • health check 使用 /health，但另设依赖和业务合成监控。
  • 开启 connection draining，建议 300～900 秒，并根据最长正常请求校准。
  • 应用当前收到 SIGTERM 后 HTTP shutdown context 只有 5 秒，因此滚动发布必须先在 LB 摘流并等待活跃连接接近零，再停止容器；不能依赖应用退出时自动等待十几分钟长流完成。

第二阶段运维 ​

发布流程：

  1. 查看 migration 和 release notes。
  2. 创建 PostgreSQL 备份并记录恢复点。
  3. 从 LB 摘除 App A，进入 draining。
  4. 活跃连接接近零后升级 App A。
  5. 验证 /health、登录、DB/Redis、非流式、SSE、WS、用量与扣费。
  6. App A 加回 LB，观察一个告警窗口。
  7. 对 App B 重复同样流程。

故障演练至少每季度一次：

  • 停止一个应用节点，确认 LB 正常摘除。
  • 执行 PostgreSQL 主备切换或克隆恢复演练。
  • 执行 Redis 主从切换，验证应用重连和 leader lock。
  • 恢复到隔离环境，完成登录、账号、API Key、余额、历史用量和支付对账验证。

阶段二建议目标：

  • RPO：5～15 分钟，取决于托管 PostgreSQL PITR 与跨区域备份设置。
  • RTO：30～60 分钟。
  • 单应用节点故障不影响新请求。
  • 数据库或 Redis 切换允许短暂重连错误，但不得人工重建整套数据。

第二阶段成本 ​

中国大陆单地域 HA 建议按 1,800～4,500 元/月 规划：

  • 两台 4C8G 应用服务器。
  • PostgreSQL HA 2C4G～4C8G、100 GB。
  • Redis 标准主从 1 GB。
  • 公网 LB、10～20 Mbps 或等量流量。
  • 对象存储、日志、监控、备份和基础 WAF。

当前官方价格可以作为锚点：

  • 腾讯云 PostgreSQL 2C4G：中国大陆主要地域 408 元/月；香港 684 元/月；新加坡 700 元/月，存储另计。
  • 腾讯云 PostgreSQL 4C8G：中国大陆主要地域 816 元/月；香港 1,368 元/月；新加坡 1,400 元/月。
  • 阿里云杭州 1 GB Tair/Redis 标准主从按量示例约 151.2 元/月，资源包示例约 98～144 元/月。
  • 阿里云 ALB Basic 实例费 0.049 元/小时，LCU 0.049 元/LCU/小时，公网 EIP/流量另计。

来源：

香港/新加坡同等级 HA 建议按 3,500～8,000 元/月 规划；若需要精品 BGP 或中国大陆跨境加速，网络费应单独报价，可能成为最大基础设施成本。

进入第三阶段的触发条件 ​

  • 峰值活跃流达到 80～120，或两个 4C8G 节点仍持续 CPU > 60%/内存 > 70%。
  • usage worker queue、scheduler outbox lag 或日志写入队列持续增长。
  • PostgreSQL 2C4G/4C8G CPU、IOPS 或连接等待逼近容量。
  • Redis 内存、带宽或 CPU 持续超过 60%，或出现 eviction/高延迟。
  • 业务要求 99.9%+、跨地域灾备、蓝绿发布或更严格 RPO/RTO。
  • 上游账号池已具备足够并发；如果瓶颈是账号 429/529，增加应用节点不会解决问题。

第三阶段：500+ 用户或收入关键业务 ​

目标 ​

  • 单地域多可用区高可用。
  • 可水平扩应用并完成蓝绿/灰度发布。
  • 数据层具备 PITR、跨地域备份和明确的灾备切换手册。
  • 监控、告警、审计、成本和安全运维制度化。

推荐拓扑 ​

text
                  DNS / WAF / Global Acceleration
                              │
                         ALB / CLB
                 ┌────────────┼────────────┐
                 ▼            ▼            ▼
              App A        App B        App C
              Zone A       Zone B       Zone C
                 └────────────┬────────────┘
                              │ private VPC
            ┌─────────────────┴─────────────────┐
            ▼                                   ▼
   PostgreSQL HA 4C16G+              Redis Standard HA 2～4GB
   PITR / cross-region backup         multi-zone / backup

   Object Storage / Central Logs / Metrics / Secret Manager
                              │
                              ▼
                 Secondary-region DR environment
                 backup or warm standby, no traffic

应用层 ​

  • 三个 4C8G 副本起步；协议转换、图片或日志压力高时升级为 8C16G。
  • 使用伸缩组 + Docker/系统镜像即可满足大量场景。只有团队已经能维护 Kubernetes，或副本、服务和发布编排明显增加时，才考虑 ACK/TKE/CCE。
  • 扩容前先检查上游账号池、数据库和 Redis，不以应用副本数量替代完整容量。
  • 每增加一个副本，重新计算数据库连接、Redis pool、fd、LB LCU 和上游并发。
  • 使用蓝绿或滚动发布，每次只让一个新版本进入少量流量。

数据层 ​

PostgreSQL：

  • 4C16G、200 GB 起步，按慢查询、IOPS 和数据增长决定是否升到 8C32G。
  • 高可用主备跨可用区，PITR 7～30 天。
  • 跨地域备份；对关键业务考虑灾备实例或只读容灾副本。
  • 当前应用没有独立读库配置，不要仅为“看起来可扩展”购买读副本。先解决慢查询、预聚合和 retention，再评估代码层读写分离。

Redis：

  • 标准主从 2～4 GB 起步，多可用区。
  • 仍优先单分片，不在没有兼容性测试前升级 Cluster。
  • 监控 big key、Lua 延迟、Pub/Sub、连接数、复制和切换事件。
  • Redis 故障可能损失短时 inflight、队列和锁状态，因此灾备演练要覆盖重复执行、漏执行和并发槽位恢复。

灾备而不是跨地域共享数据库 ​

推荐两档：

冷灾备 ​

  • 第二地域只保留 VPC、镜像、IaC、Secret 副本和跨地域数据库备份。
  • 故障时恢复 PostgreSQL、创建 Redis、启动应用并切 DNS。
  • 成本低，RTO 通常 2～4 小时。

温灾备 ​

  • 第二地域保留 PostgreSQL 灾备/复制、Redis 备份或复制能力和至少一个关闭流量的应用节点。
  • 定期演练提升、重连、用量一致性和 DNS 切换。
  • RTO 目标 30～60 分钟，成本约增加主环境的 50%～100%。

不要把中国大陆 App A、香港 App B、新加坡 App C 同时接到一个地域的 PostgreSQL/Redis。这样会产生：

  • 每次鉴权、调度、并发和用量写入的跨境 RTT。
  • Redis Pub/Sub、锁和队列对网络抖动极度敏感。
  • 一个主地域故障拖垮全部入口。
  • 跨境数据、隐私和运营合规范围扩大。

如果未来必须做中国大陆 + APAC active-active，需要新增产品设计：

  • 用户/租户归属地域和不可随意漂移的路由规则。
  • 地域本地 PostgreSQL/Redis。
  • 全球身份、余额与账务总账的一致性模型。
  • Usage event 全局唯一 ID、幂等入账和冲突解决。
  • 账号池和上游凭证的地域归属。
  • 跨地域配置、价格、模型和风控版本发布。
  • 故障时用户迁移、余额对账和数据出境处理。

这应作为独立研发项目，而不是第三阶段的临时运维改动。

第三阶段成本 ​

中国大陆单地域三节点 + 托管高可用数据层建议按 8,000～20,000 元/月 规划；APAC 或精品跨境网络建议按 10,000～30,000 元/月 规划。加入温灾备、全球加速、WAF 高级版、日志长期保留和商业支持后，基础设施可能达到 15,000～40,000 元/月以上。

以上全部不含：

  • OpenAI、Anthropic、Google 或其他模型上游成本。
  • 上游账号/订阅采购和代理成本。
  • 支付通道费、短信、邮件和对象存储大流量。
  • 等保、合规、审计、律师和 7×24 运维人力。

云厂商选择原则 ​

不要跨云拼接核心数据层 ​

不建议“阿里云 ECS + 腾讯云 PostgreSQL + 另一家 Redis”。跨云公网或专线会增加：

  • 延迟和抖动。
  • 出网费和专线费。
  • 安全组、白名单、证书与故障排查复杂度。
  • 云厂商故障时的责任边界。

计算、PostgreSQL、Redis、LB、日志和对象存储尽量选同一家云、同一地域。真正的异云灾备可以在第三阶段单独设计。

阿里云参考栈 ​

  • ECS：应用节点。
  • ALB：HTTPS/SSE/WS、长 timeout、connection draining。
  • RDS PostgreSQL 高可用版：直接主库 endpoint、PITR。
  • Tair/Redis 标准主从版：单分片完整协议。
  • OSS：备份和大文件。
  • SLS/CloudMonitor：日志、指标、告警。
  • KMS/Secrets Manager：密钥。
  • BGP（多线）精品 EIP/GA：中国大陆与香港/海外线路优化，需评估资质和成本。

适合已经在阿里云备案、重视全球网络产品或计划使用香港 BGP 精品线路的团队。

腾讯云参考栈 ​

  • CVM：应用节点。
  • CLB：HTTPS/SSE/WS。
  • TencentDB for PostgreSQL 高可用版。
  • Redis 标准架构主从版。
  • COS/CLS/Cloud Monitor：备份、日志、监控。
  • KMS/SSM/CAM：Secret 与权限。
  • 精品 BGP/GAAP：香港、新加坡和中国大陆的线路优化，跨境需要资质审核。

适合用户集中在华南、大湾区、香港，或支付和运营体系已经大量使用腾讯云/微信生态的团队。

华为云参考栈 ​

  • ECS + ELB。
  • RDS for PostgreSQL。
  • DCS for Redis 的主备/高可用规格。
  • OBS + LTS/AOM + DEW/KMS。
  • CCE 只在已有 Kubernetes 运维能力时使用。

如果企业已经使用华为云专线、政企网络、安全合规服务或统一采购，华为云可以减少组织成本；否则不应仅因为单项促销跨云拆分核心链路。

扩容阈值与动作 ​

指标预警阈值扩容/处理动作
应用 CPU> 60% 持续 15 分钟先 profile/检查日志与协议转换，再加副本或升规格
应用内存> 70% 持续 15 分钟检查长流、响应体、goroutine、队列；保留至少 30% 余量
fd> 60% 限额提高应用/LB/主机限制并检查连接泄漏
平台错误率> 1% 持续 5 分钟按 auth/routing/upstream/billing 分层定位
上游错误率> 10% 持续 5 分钟增加独立上游容量，不盲目扩应用
并发 queue> 0 持续 5 分钟检查账号并发、上游 429 和调度，不只看服务器
DB active connections> 60% 预算查 pool wait/慢 SQL，必要时升 DB 后再调池
DB CPU/IOPS> 60% 持续 15 分钟优化查询、聚合与 retention；再升规格
PG 存储> 60%检查 usage_logs、索引、WAL；开启扩容计划
Redis memory> 60%查 big key/TTL，规划升规格；目标 eviction=0
Redis p99 延迟同 VPC 持续 > 5 ms查热 key、Lua、CPU、网络与连接池
usage queue持续增长查 DB 写入、worker 和 overflow，禁止直接 drop
scheduler outbox lag> 5 秒持续查 DB/Redis/副本状态和全量重建

阈值不是自动扩容脚本的唯一条件。扩容前要区分平台、上游和网络故障，避免把上游 429 当成应用 CPU 不足。

压测与验收方法 ​

项目没有可直接用于你业务分布的官方容量数字。每次阶段升级都应做：

  1. 10 分钟逐步升压。
  2. 30～60 分钟目标峰值稳定压测。
  3. 2～4 小时低于峰值的 soak test。
  4. 主动断开客户端，验证并发槽位释放。
  5. 压测中滚动一个应用节点，验证 draining 和重连。
  6. 模拟 Redis/PG 短暂切换，验证错误恢复。
  7. 对比请求数、usage_logs、余额和上游账单，确认没有漏记或重复扣费。

建议流量模型：

  • 60%～70% 文本 SSE。
  • 10%～20% 非流式请求。
  • 10%～20% WebSocket/工具调用。
  • 图片和批量任务按实际业务单独建立场景，不与文本平均。

通过标准：

  • 应用 CPU/内存有 30% 以上余量。
  • 平台自身错误率 < 1%，且没有持续 queue。
  • PostgreSQL 无持续 connection wait、lock wait 或慢查询堆积。
  • Redis 无 eviction、blocked clients 或持续高延迟。
  • usage worker queue 能在流量下降后快速归零。
  • 账号池真实并发大于目标用户并发。
  • 流式事件逐步返回，不被 LB/CDN 缓冲。
  • 请求数、用量、扣费和上游账单可以对账。

安全与网络基线 ​

  • 公网只开放 80/443；SSH 只允许 VPN/管理网段。
  • 8080、5432、6379 仅 VPC/本机访问。
  • 管理后台增加 VPN/IP/零信任限制。
  • RUN_MODE=standard。
  • 开启 URL allowlist，禁止 private hosts 和 HTTP upstream。
  • 数据库、快照、逻辑备份和对象存储使用加密。
  • Secret 不写入 Git、镜像、CI 日志或普通运维文档。
  • 管理员启用 TOTP；用户注册启用邮箱验证、Turnstile、默认余额 0 和低并发。
  • API、鉴权、支付 webhook 路径禁止 CDN 缓存。
  • 日志默认不记录 Authorization、Cookie、完整 prompt、图片 base64、支付签名和上游完整错误体。
  • 对公网 API Key 设置 quota、expires_at、IP 规则和异常费用告警。

如果大陆用户的提示词、邮箱、IP、文件或支付信息会发送到境外模型、日志或支持系统，需要评估个人信息跨境处理。个人信息保护法要求向境外提供个人信息时满足相应条件、履行告知并取得单独同意；2024 年《促进和规范数据跨境流动规定》调整了安全评估、标准合同和认证阈值，但不免除数据保护义务：

最终推荐 ​

现在只有约 100 用户 ​

如果仍是验证期、没有公开付费、可接受单机停服：

  • 选择一个主地域。
  • 4C8G/100 GB SSD 单机。
  • Docker Compose 同机运行 Sub2API、PostgreSQL、Redis。
  • 收紧连接池与 worker。
  • 每日 PostgreSQL 异地备份、每周快照、每月恢复演练。
  • 先完成真实 30 并发流压测。

如果已经收费或不能接受单机故障，即使只有 50～100 用户也直接进入第二阶段。

预计约 500 用户 ​

  • 两台 4C8G 应用节点，跨两个可用区。
  • 应用使用 standalone Docker Compose。
  • 同地域托管 PostgreSQL HA 2C4G/100 GB；报表重时 4C8G。
  • 同地域 Redis 标准主从 1 GB。
  • ALB/CLB 终止 TLS，配置 600～3,600 秒 timeout 和 draining。
  • 集中日志、Secret Manager、PITR、跨地域备份、季度灾备演练。
  • 以 80～120 峰值并发流做容量验收，而不是只按 500 个账号估算。

大陆与 APAC 都要低延迟 ​

短期只能选择一个事实数据主地域：

  • 大陆合规上游和大陆用户优先：大陆主地域 + 国内 LB/CDN，APAC 通过全球加速改善。
  • APAC 合规用户和国际上游优先：新加坡主地域，明确不把它当作规避大陆或上游地区限制的方案。
  • 香港折中：使用精品 BGP 前先实测并接受较高带宽成本，同时重新确认上游地区授权。

第三阶段建立第二地域冷/温灾备。只有在完成租户分区、地域本地账务和数据一致性设计后，才考虑真正的大陆 + APAC active-active。

采购前价格复核清单 ​

价格随地域、活动、账号、包年时长和续费政策变化。正式采购时，在同一家云的价格计算器里保存三份报价：

  1. 第一阶段：4C8G + 100 GB + 10 Mbps/流量 + 对象存储。
  2. 第二阶段：2×4C8G + ALB/CLB + PG HA 2C4G/100 GB + Redis HA 1 GB + 日志/备份。
  3. 第三阶段：3×4C8G 或 8C16G + PG HA 4C16G/200 GB + Redis HA 2～4 GB + WAF/GA + 跨地域备份。

报价必须同时包含：

  • 新购价与续费价。
  • 系统盘、数据盘和快照。
  • 公网带宽、流量和精品线路。
  • LB 实例/LCU/连接与流量费。
  • PostgreSQL 存储、备份超额、PITR、跨地域备份和审计。
  • Redis 备份、跨可用区和连接限制。
  • 日志写入、索引、存储和查询。
  • 对象存储请求、容量与出网。
  • WAF、DDoS、Secret Manager、KMS 和商业支持。

以正式计算器导出的续费级报价作为预算，不以首页首购促销图作为生产 TCO。

本文档用于帮助你理解、部署和运维 Sub2API。使用前请确认上游服务条款与当地法律要求。

Sub2API Docs 101