Skip to content

中国大陆与亚太生产部署云厂商调研

核查时间:2026-07-17
适用项目:Sub2API
调研范围:阿里云、腾讯云、华为云的中国大陆、中国香港、新加坡、日本东京相关计算、PostgreSQL、Redis、负载均衡、对象存储、备份、跨境网络与备案能力。
来源边界:仅引用项目仓库和云厂商、工信部、国家网信办的一手资料。

分阶段拓扑、配置参数、扩容阈值、RPO/RTO、压测与运维清单,见中国大陆与亚太生产部署分阶段方案

1. 结论摘要

1.1 云厂商建议

如果希望尽量使用一家云完成“中国大陆 + 中国香港/新加坡/东京”的完整部署,优先级建议是:

  1. 阿里云:默认首选。
    • ECS、RDS PostgreSQL、Tair/Redis、ALB、OSS、全球加速在中国大陆、中国香港、新加坡均具备完整产品链。
    • 东京也有 ECS、RDS PostgreSQL、Tair 和 OSS 等区域能力,适合后期建设日本节点。
    • 适合从单区域平滑演进到大陆与 APAC 双区域。
  2. 腾讯云:与阿里云同级备选,香港接入值得重点实测。
    • CVM、TencentDB for PostgreSQL、分布式缓存数据库、CLB、COS、GAAP 在大陆、香港、新加坡、东京均有覆盖。
    • 全球加速官方提供香港精品 BGP 选项,适合重点测试“中国大陆用户访问香港源站”的链路质量。
    • Redis 标准架构支持 0.25 GB 起步、1~5 个副本和多可用区,早期规格较灵活。
  3. 华为云:适合已有华为云采购、政企或统一运维体系的团队。
    • 大陆、香港、新加坡的 ECS、RDS PostgreSQL、DCS、ELB、OBS 能形成完整栈。
    • 官方 ECS 区域说明对大陆以外亚太重点推荐香港、曼谷、新加坡;本次未找到东京完整生产 Region 的明确官方证据,因此日本全栈不能按“已确认可用”规划。
    • DCS 自动备份默认关闭且自动备份最长保留 7 天,需在运维设计中额外补强。

这不是网络性能排行榜。三家云在不同省份、运营商、时段和线路上的实际延迟会变化,最终选型必须使用三网探针和真实长连接请求做 7~14 天测试。

1.2 区域建议

业务目标推荐主区域说明
主要服务中国大陆,已具备备案条件广州/深圳或上海的大陆 Region用户到入口延迟最低;必须完成 ICP 备案;访问境外 AI 上游仍可能遇到跨境抖动
需要尽快上线,尚未备案中国香港无需 ICP 备案,是大陆与 APAC 的折中点;大陆公网质量不能获得与大陆 Region 相同的确定性
东南亚用户为主新加坡面向东南亚更稳定;不应把新加坡 PostgreSQL/Redis 远程提供给大陆应用实例
日本、韩国用户占比较高东京适合东北亚独立节点;不能作为中国大陆低延迟节点
大陆与 APAC 都是核心市场大陆独立栈 + 香港/新加坡独立栈用户和数据按“归属 Region”路由,禁止跨境共享一套低延迟数据库和 Redis

1.3 Redis 和 PostgreSQL 放在哪里

无论选择哪家云,生产默认规则是:

  • PostgreSQL、Redis、Sub2API 应用必须在同一 Region,优先在同一 VPC。
  • PostgreSQL 使用托管服务的主实例内网直连地址
  • Redis 使用标准/主备、单分片、稳定写地址,不要从多分片 Cluster 起步。
  • 不要在大陆应用和香港、新加坡或东京数据库之间走公网。
  • 不要让每个 Sub2API 副本各带一套 PostgreSQL/Redis;同一区域的所有应用副本必须共享同一数据层。
  • 不要为了“双区域”直接让两个区域共享一套 Redis。Sub2API 的 Redis 包含并发槽位、限流、Pub/Sub、分布式锁和队列状态,跨区域 RTT 和网络分区会直接影响请求正确性。

1.4 部署方式建议

应用层优先使用 Docker,但分阶段处理:

  • 早期单机:使用项目 Docker Compose,允许应用、PostgreSQL、Redis 同机,仅适用于测试或可接受停机的低成本试运营。
  • 正式商业生产:使用 docker-compose.standalone.yml 只运行 Sub2API,PostgreSQL 和 Redis 改用同云同 Region 的托管服务。
  • 两个及以上应用副本:每台 ECS/CVM/ECS 单独运行一个 Sub2API 容器,由云负载均衡接入;不使用跨主机 Docker Compose 管理集群。
  • 大规模阶段是否迁移 Kubernetes,不应由“用户数”触发,而应由发布频率、服务数量、团队规模和自动伸缩需求触发。仅运行一个 Go 应用时,虚拟机 + Docker 通常更简单。

2. Sub2API 对基础设施的真实约束

2.1 仓库给出的容量起点

项目部署文档给出的起点为:

场景应用PostgreSQLRedis
个人/测试2 vCPU / 2~4 GB可同机可同机
小团队4 vCPU / 8 GB2~4 vCPU / 8 GB1~2 GB
公开运营4~8+ vCPU / 8~16 GB,多副本独立或托管,主从/备份独立或托管,高可用

来源:部署前准备与容量规划

这些数值是基础设施起点,不是用户数与机器规格的固定换算。Sub2API 的主要负载具有以下特点:

  • 大量 SSE、WebSocket、HTTP/2 长连接。
  • 网关请求生命周期通常受上游 AI 服务 TTFT 和生成时间控制。
  • 图片和批量任务会显著增加请求体、内存、对象存储和带宽压力。
  • 上游账号池额度与并发限制通常先于应用 CPU 成为瓶颈。
  • PostgreSQL 的用量、日志、订单、账号和调度数据会持续增长。

2.2 多副本必须共享数据层和密钥

项目文档明确要求所有应用副本共享:

  • PostgreSQL。
  • Redis。
  • JWT_SECRET
  • TOTP_ENCRYPTION_KEY
  • 时区和安全配置。

来源:多实例与高可用部署

因此,正确拓扑是“多个无状态或弱状态应用副本 + 一套区域级共享 PostgreSQL/Redis”,而不是“每个应用副本带自己的数据库”。

2.3 PostgreSQL 连接语义

源码使用 session-level PostgreSQL advisory lock:

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

因此:

  • 使用托管 PostgreSQL 的普通主实例直连 endpoint 最安全。
  • 如果引入 PgBouncer,必须明确为 session mode
  • 不要默认使用 transaction-mode pooler。
  • 使用云数据库代理前必须验证会话级 advisory lock 不会被破坏。

2.4 Redis 不是可丢弃缓存

源码和项目文档显示 Redis 承担:

  • 并发槽位和等待队列。
  • API Key、订阅、余额和配额缓存。
  • 调度快照与粘性状态。
  • OAuth refresh lock 和 leader lock。
  • Pub/Sub 缓存失效。
  • Lua、ZSET、批量任务队列和 inflight 状态。

来源:PostgreSQL 与 Redis 运维

托管 Redis 必须至少支持:

  • 原生 Redis TCP/RESP。
  • TLS 或同 VPC 私网访问。
  • EVALEVALSHASCRIPT LOAD
  • ZSET。
  • Pub/Sub。
  • 单一、稳定的可写 endpoint。

推荐从标准/主备单分片开始,先纵向扩容,再评估 Cluster。多分片 Redis 的跨 slot Lua、Pub/Sub 和代理语义可能与项目假设冲突。

2.5 健康检查边界

项目 /health 只证明进程存活,不会主动验证 PostgreSQL、Redis 或 AI 上游。

负载均衡应使用:

  • 高频 liveness:GET /health
  • 独立依赖探针:PostgreSQL 简单查询、Redis Ping/Lua。
  • 低频业务合成探针:使用专用低额度 Key 发起最小模型请求。

来源:监控、日志与告警

2.6 当前 standalone Compose 的一个注意点

当前 deploy/docker-compose.standalone.yml 会传入数据库、Redis 和 JWT_SECRET,但没有传入 TOTP_ENCRYPTION_KEY

多副本正式上线前,应在实际部署模板中补齐固定的 TOTP_ENCRYPTION_KEY。本文不修改现有 Compose,只记录该生产风险。

3. 中国大陆与跨境合规边界

3.1 ICP 备案

工信部《非经营性互联网信息服务备案管理办法》规定,在中华人民共和国境内提供非经营性互联网信息服务,应依法履行备案手续;未经备案不得提供相关服务。

官方来源:工信部《非经营性互联网信息服务备案管理办法》

三家云官方备案文档均明确:

  • 域名指向中国大陆服务器,需要 ICP 备案。
  • 香港或海外服务器通常无需 ICP 备案。
  • 如果已在其他接入商备案,迁移到新云厂商大陆服务器通常需要办理接入备案。

官方来源:

实际运营还需要根据主体、是否收费、业务内容、支付、用户生成内容、AI 服务等判断是否涉及经营许可或其他专项要求。本报告不是法律意见,正式上线前应由合规人员复核。

3.2 跨境网络加速不是普通开关

三家云的官方全球加速文档均显示:涉及中国大陆与香港/海外之间的加速时,通常需要额外的跨境资质或合规审核。

  • 阿里云:跨境全球加速可能要求域名已备案;联通跨境专线需要跨境合规认证。
  • 腾讯云:全球加速和云联网跨境段使用运营商跨境线路,跨境场景需要企业合规审核。
  • 华为云:涉及跨中国大陆通信时,需要申请跨境资质。

官方来源:

因此,不能把“购买香港服务器 + 打开全球加速”当作无需准备即可获得稳定大陆访问的方案。

3.3 数据跨境

如果大陆用户的账号、日志、请求内容、支付信息、设备信息或其他个人信息被传输到香港、新加坡、东京或境外 AI 上游,可能构成数据出境。

国家网信办《促进和规范数据跨境流动规定》对免申报、标准合同/认证和安全评估的门槛做了区分。即使用户量只有 100 或 500,也仍需:

  • 识别是否传输个人信息、敏感个人信息或重要数据。
  • 告知用户数据流向并取得适当授权。
  • 实施数据最小化。
  • 记录境外接收方、用途、保留期和安全措施。

官方来源:

基础设施上的安全默认值应是:

  • 大陆用户数据优先保存在大陆 Region。
  • APAC 用户数据优先保存在 APAC Region。
  • 跨区域只同步必要的汇总、配置或匿名化数据。
  • 不直接复制完整请求日志、OAuth token、API Key 和支付数据,除非已有明确的合规依据。

4. 区域架构选择

4.1 单一大陆 Region

适合:

  • 主要用户在大陆。
  • 已完成 ICP 备案。
  • 上游服务在大陆可稳定、合法访问。

拓扑:

text
大陆用户

大陆公网 / WAF / ALB

Sub2API ECS × 1~N
   ├── RDS PostgreSQL(同 Region、同 VPC)
   ├── 托管 Redis(同 Region、同 VPC)
   └── OSS/COS/OBS(同 Region)

优点:

  • 大陆用户入口延迟最低。
  • 数据驻留和云内私网最清晰。
  • 可直接使用大陆 WAF、CDN、对象存储和监控。

风险:

  • 访问境外 AI 上游的出口质量可能成为 TTFT 主要瓶颈。
  • APAC 用户访问大陆源站可能受跨境链路影响。
  • 域名、备案、接入和内容合规准备周期更长。

4.2 单一中国香港 Region

适合:

  • 需要快速上线。
  • 上游主要在境外。
  • 当前不具备 ICP 备案条件。
  • 可以接受大陆访问质量按运营商和时段波动。

拓扑:

text
大陆 / APAC 用户

香港精品 BGP / 全球加速 / 公网 LB

Sub2API 香港实例 × 1~N
      ├── 香港 PostgreSQL
      ├── 香港 Redis
      └── 香港对象存储

优点:

  • 不需要 ICP 备案。
  • 香港到多数境外 AI 上游和 APAC 用户的链路通常比大陆 Region 简单。
  • 阿里云、腾讯云均有完整的香港数据层与网络产品。

风险:

  • 云厂商官方文档明确提示大陆访问海外/香港普通公网可能出现较高延迟或丢包。
  • 无法承诺与大陆 Region 同等级的全国三网体验。
  • 仍可能涉及大陆个人信息出境。

香港适合作为第一阶段折中方案,不应被描述成“等价于大陆节点”。

4.3 单一新加坡 Region

适合:

  • 东南亚用户占比高。
  • 大陆只是次要市场。
  • 上游、支付和其他依赖主要在国际网络。

不适合:

  • 追求大陆用户极低入口延迟。
  • 让大陆应用远程访问新加坡 PostgreSQL/Redis。

4.4 东京 Region

适合:

  • 日本和韩国用户量足以支撑独立区域成本。
  • 需要在东北亚降低 RTT。

不适合:

  • 作为大陆与整个 APAC 的统一中心。

阿里云和腾讯云都有明确的东京计算、PostgreSQL、Redis 或区域产品资料。华为云本次核查没有取得东京完整 Region 的充分证据,因此使用华为云时,日本节点应先在控制台和商务侧确认完整产品可用性。

4.5 大陆 + APAC 双区域

当大陆与 APAC 都成为收入关键市场时,推荐:

text
GeoDNS / 智能解析
   ├── 大陆用户 ──> 大陆 WAF/LB ──> Sub2API CN ──> PG CN + Redis CN
   └── APAC 用户 ──> 香港/新加坡 LB ──> Sub2API APAC ──> PG APAC + Redis APAC

关键原则:

  • 用户注册时确定 home_region
  • API Key、余额、订单、账号和用量的事实来源必须有明确 Region owner。
  • 同一个用户的写请求默认回到 home region。
  • 跨区域同步使用业务事件或经过筛选的 CDC,不共享 Redis。
  • Redis 锁、并发槽位和队列只在本区域内生效。
  • 全局报表使用异步汇总,不跨境实时扫生产库。

双区域的复杂度来自数据一致性和合规,不来自“再买一台服务器”。除非单区域已稳定运行、恢复演练通过且收入足以覆盖双倍基础设施和运维,不建议过早建设。

5. 100、500 用户与增长阶段的容量模型

5.1 用户数假设

注册用户数不能直接换算 QPS。本文为了给出可执行规格,使用以下保守假设:

指标约 100 注册用户约 500 注册用户后续增长
日活10~3050~150300+
峰值同时在线5~1520~60100~300+
活跃流式模型请求3~1010~4050~200+
请求特征文本为主,少量图片文本 + 图片,开始有批量多平台、多账号池、批量任务

如果用户是高频开发者、团队共享 Key 或自动化 Agent,这个假设会严重低估负载。必须以峰值活跃请求、TTFT、长连接数、Token/s 和上游账号并发作为扩容指标。

5.2 约 100 用户

最低成本试运营:

  • 1 台 4 vCPU / 8 GB 云服务器。
  • Docker Compose 同机运行应用、PostgreSQL、Redis。
  • 80~100 GB SSD/ESSD 系统盘或独立数据盘。
  • Caddy/Nginx 终止 TLS。
  • 每日 pg_dump、云盘快照、Redis AOF/RDB,并复制到对象存储。

限制:

  • 应用、数据库、Redis 和磁盘是共同故障域。
  • 内核、宿主机、磁盘或误操作都可能导致整站不可用。
  • 只能作为可接受数小时恢复时间的验证阶段。

推荐的小型正式生产:

  • 应用:1 台 2 vCPU / 4 GB;有图片/批量时直接 4 vCPU / 8 GB。
  • PostgreSQL:托管基础版 2 vCPU / 4 GB,50~100 GB SSD。
  • Redis:托管标准主备 0.25~1 GB,单分片。
  • 对象存储:同 Region。
  • 入口:单机 Caddy/Nginx;如果云 LB 固定费用可接受,可提前使用云 LB 简化后续扩容。
  • 公网带宽:文本为主从 5~10 Mbps 起测;图片业务按真实 P95 出网重新计算。

连接池起点:

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

5.3 约 500 用户

推荐:

  • 应用:2 台 4 vCPU / 8 GB,跨两个可用区。
  • 入口:云 ALB/CLB/ELB,HTTPS,健康检查,连接排空。
  • PostgreSQL:托管高可用主备,建议 2 vCPU / 8 GB 或 4 vCPU / 8 GB,100 GB 起步。
  • Redis:标准主备单分片 1~2 GB,跨可用区。
  • 对象存储:批量图片、备份导出和大文件。
  • NAT/EIP:为应用提供固定出站地址,便于上游 allowlist 和审计。
  • 日志:云日志服务;应用本地只保留短期滚动日志。

每个应用副本的连接池起点:

dotenv
DATABASE_MAX_OPEN_CONNS=25
DATABASE_MAX_IDLE_CONNS=5
REDIS_POOL_SIZE=128
REDIS_MIN_IDLE_CONNS=16

两个副本的数据库理论连接上限为 50,仍需为迁移、备份、管理和监控预留至少 20% 余量。

触发扩容的指标:

  • 应用 CPU 持续超过 65%~70%。
  • 活跃长连接接近压测安全上限的 60%~70%。
  • DB connection wait、lock wait 或慢查询持续升高。
  • Redis P95 延迟、连接数或内存超过安全阈值。
  • 队列持续增长。
  • 上游账号可用并发耗尽。

5.4 后续增长

应用层:

  • 从 2 台 4C8G 增至 3~4 台 4C8G,通常优先于单机升到超大规格。
  • 图片、批量任务和普通文本网关可在负载明显不同后拆分 worker。
  • 只有发布、服务数量和团队复杂度需要时再使用 Kubernetes。

PostgreSQL:

  • 先优化索引、保留期、聚合和慢查询。
  • 再从 2C/4C 升到 4C/8C/16C。
  • 报表读压力明显时添加只读实例,但写入、锁和迁移继续走主实例。
  • 设置 14~35 天 PITR,定期做跨区域备份或逻辑导出。

Redis:

  • 标准主备从 1 GB 升到 2 GB、4 GB。
  • 在单分片 CPU、带宽或内存已成为明确瓶颈前,不迁移 Cluster。
  • 如果必须使用 Cluster,先用生产流量回放验证 Lua、Pub/Sub、ZSET 和批量队列。

多区域:

  • 大陆与 APAC 收入都变得关键后再建设独立栈。
  • 第三个东京节点只在日本/韩国用户和收入可覆盖独立数据层成本时建设。

6. 三阶段运维部署方案

第一阶段:验证市场,成本优先

目标:

  • 约 0~100 用户。
  • 能快速发布和恢复。
  • 接受单机或单应用副本。

方案 1A:未备案,香港快速上线

  • Region:中国香港。
  • 计算:1 台 4C8G。
  • 方式:Docker Compose 全家桶。
  • 存储:独立 SSD 数据盘或明确的数据目录。
  • 备份:
    • PostgreSQL 每日逻辑备份。
    • 云盘每日快照。
    • Redis AOF everysec + RDB。
    • 备份复制到同 Region 对象存储。
  • 域名:香港公网 HTTPS,无 ICP。
  • 验收:大陆电信/联通/移动、香港、新加坡探针测试 7 天。

适合:

  • 验证付费和上游账号池。
  • 可以接受故障后 2~4 小时恢复。

方案 1B:已备案,大陆正式起步

  • Region:广州/深圳或上海。
  • 计算:1 台 2C4G 或 4C8G。
  • 数据层:优先托管 PG + 托管 Redis 主备。
  • 入口:已备案域名、HTTPS、WAF 可按风险开启。
  • 出口:固定 NAT/EIP,测试到所有 AI 上游的 P50/P95。

成本控制:

  • 稳定使用的 ECS、RDS、Redis优先比较包年包月。
  • 上线前和压测期使用按量付费,规格稳定后转预付费。
  • 不在第一阶段购买跨境专线、双区域数据库或 Kubernetes。

第一阶段退出条件:

  • PostgreSQL 恢复演练成功。
  • Redis 重启后业务恢复。
  • 峰值活跃请求有 50% 以上余量。
  • 上游账号并发和代理稳定。
  • 已建立基础告警。

第二阶段:约 100~500 用户,消除主要单点

目标:

  • 应用层可滚动发布。
  • 单台应用故障不影响服务。
  • 数据层具备主备和自动备份。

拓扑:

text
Internet

WAF / ALB
   ├── Sub2API A(AZ-1,Docker)
   └── Sub2API B(AZ-2,Docker)

          ├── PostgreSQL HA(跨 AZ)
          ├── Redis 主备(跨 AZ)
          └── 对象存储

实施清单:

  • 两个应用副本使用相同镜像 digest。
  • 从同一个 Secret Manager/KMS 注入密钥。
  • 固定 JWT_SECRETTOTP_ENCRYPTION_KEYTZ
  • LB 健康检查使用 /health
  • 启用连接排空,长流最大 drain 时间按真实请求分布设置。
  • WebSocket 默认支持仍需实测;SSE 必须验证无缓冲和空闲超时。
  • PostgreSQL 使用高可用系列,自动备份和日志备份开启。
  • Redis 使用主备、多可用区、单分片。
  • 每月恢复一次 PG 到隔离实例。
  • 每季度做一次应用节点故障、Redis 切主和数据库切主演练。

第二阶段退出条件:

  • 任意一台应用下线时请求仍可成功。
  • PostgreSQL/Redis 切换后客户端可自动重连。
  • 发布过程中错误率和断流率符合目标。
  • 有完整的容量和成本月报。

第三阶段:大陆与 APAC 双区域,收入关键

目标:

  • 大陆和 APAC 用户都有区域内应用与数据层。
  • 区域级故障有明确降级和恢复路径。
  • 跨境数据和网络链路满足合规要求。

推荐拓扑:

text
                   GeoDNS / Traffic Manager
                    /                     \
             中国大陆 Region          APAC Region
              WAF + ALB                WAF + ALB
              App × 2~N               App × 2~N
              PG HA                    PG HA
              Redis HA                 Redis HA
              Object Storage           Object Storage
                    \                     /
                     异步业务事件/汇总

不要实施:

  • 大陆 App 直接连香港或新加坡 Redis。
  • 两个区域共同抢同一把 Redis/PG lock。
  • 通过公网做数据库同步。
  • 未定义 owner 的用户余额和订单双写。

必须先设计:

  • 用户、API Key、账号池、订单、余额和用量的 Region ownership。
  • 跨区请求重定向规则。
  • 异步同步字段白名单。
  • 数据出境评估。
  • 区域故障时只读、拒写或回源策略。

成本控制:

  • APAC 初始只选香港或新加坡一个 Region。
  • 东京作为第三节点单独立项。
  • 跨境 GA/GAAP、精品 BGP、专线和跨区域备份单独计量。
  • 低频报表和归档使用对象存储,不长期占用高性能数据库。

7. 厂商逐项调研

7.1 阿里云

区域与计算

阿里云 ECS 官方地域列表包含中国大陆多个 Region、中国香港、新加坡和日本东京。官方同时提示,中国地区 ECS 通过公网访问其他国家和地区可能出现较高延迟和丢包。

来源:ECS 地域和可用区

PostgreSQL

  • RDS PostgreSQL 高可用系列采用一主一备。
  • 主备可以部署在同一 Region 的不同可用区。
  • 主节点故障时自动切换。
  • 高可用系列主备不能跨 Region。
  • 支持自动/手动数据备份与日志备份。
  • 支持跨地域备份,但这是灾备能力,不应作为跨区在线数据库访问方案。

来源:

推荐:

  • 100 用户:基础版 2C4G 可作为成本优先选择,但商业关键数据建议直接高可用。
  • 500 用户:高可用 2C8G 或 4C8G,跨可用区。
  • 应用走内网主实例 endpoint,不默认使用数据库代理。

Redis/Tair

  • Redis 开源版/Tair 支持标准主备、高可用和多可用区方案。
  • 成本优先的官方选型包含 256 MB 起步的 Redis 开源版高可用、非集群规格。
  • 标准主备可自动故障转移。
  • 默认每天备份一次,备份保留时间可配置;单节点不支持备份恢复。
  • Redis 开源版命令兼容文档覆盖 Lua 和原生命令能力。

来源:

对 Sub2API 的推荐:

  • Redis 6/7 标准主备、单分片。
  • 不选单节点。
  • 不从 Cluster 起步。
  • 上线前执行 Lua、ZSET、Pub/Sub、锁和队列兼容测试。

负载均衡

  • ALB 是七层负载均衡。
  • HTTP/HTTPS 监听默认支持 WebSocket。
  • 可用于多个应用副本和 HTTPS 卸载。

来源:

Sub2API 必须实测:

  • SSE 是否逐段返回。
  • 监听器和后端空闲超时是否覆盖最长模型请求。
  • 滚动发布时连接排空。

对象存储

  • OSS 提供同 Region 内网 endpoint。
  • 官方建议应用和 Bucket 同 Region。
  • 官方明确提示大陆访问香港/新加坡等跨境 OSS 公网可能出现高延迟或不稳定。
  • 可以使用传输加速处理必要的长距离上传下载。

来源:

跨境与价格

  • 跨境全球加速需要备案或跨境资质,具体取决于线路类型。
  • CEN 可以连接跨 Region VPC,但中国大陆与境外的跨境带宽需要提交企业材料并通过运营商合规审核。
  • ECS、RDS、Tair、ALB、OSS、GA 和公网带宽均独立计费。
  • RDS 和 Tair 价格因 Region、系列、规格、磁盘、备份和购买方式变化,应在采购当天使用售卖页/价格计算器。

来源:

7.2 腾讯云

区域与计算

腾讯云 CVM 和数据库地域文档列出中国香港、新加坡和东京。官方建议选择靠近用户的 Region;不同 Region 默认网络隔离。

来源:

PostgreSQL

  • TencentDB for PostgreSQL 提供双机高可用能力。
  • 支持自动全量、手动全量和日志备份。
  • 2026 年文档显示高可用版全量每日备份、增量实时备份,备份可配置 7~1830 天。
  • 香港、新加坡、东京均出现在 PostgreSQL 地域/定价资料中。
  • 数据库业务访问应走同 Region 内网,外网地址不提供相同可用性保证。

来源:

推荐:

  • 100 用户:2C4G 或相近小规格,缩小应用连接池。
  • 500 用户:双机高可用 2C8G/4C8G,100 GB 起步。
  • 不为便利而开启生产数据库公网地址。

Redis

  • 标准架构采用主从复制。
  • 支持 1~5 个副本,0.25~64 GB。
  • 主节点故障时自动切换。
  • 多可用区实例使用单一 VIP,主节点切换后 VIP 不变。
  • 默认每日从副本生成 RDB 备份,也支持手动备份和克隆恢复。
  • Redis/Valkey 大版本命令兼容性存在明确差异,RESP3 和 ACL 等能力需按项目依赖确认。
  • 腾讯云另有 Redis 全球复制能力,但支持地域不能假定覆盖香港、新加坡、东京全部组合;Sub2API 双区域仍应按独立 Redis 规划。

来源:

对 Sub2API 的推荐:

  • Redis 6.2/7.0 标准架构、1 个以上副本、单分片。
  • 明确不要禁用 EVALEVALSHASCRIPT
  • 生产前验证 Pub/Sub 和 Lua。

负载均衡

  • CLB 支持 HTTP/HTTPS 监听和长连接相关配置。
  • 后端长连接功能会改变连接复用和源 IP 获取方式,需要结合应用连接数评估。

来源:腾讯云 CLB HTTP 监听器

对象存储

  • COS 覆盖中国大陆、中国香港、新加坡、东京。
  • 对象存储应与应用同 Region。
  • 跨境和跨 Region 访问不作为应用主链路。

来源:

跨境与价格

  • GAAP 使用全球高速通道和智能路由。
  • 大陆跨境段需跨境资质审核。
  • 香港支持精品 BGP 接入,官方定位为改善大陆访问境外 IP 的线路选项。
  • 精确月价需要登录价格计算器,以 Region、规格、带宽和优惠为准。

来源:

7.3 华为云

区域与计算

华为云 ECS 官方区域说明建议:

  • 大陆用户选择大陆 Region。
  • 大陆以外 APAC 可选择中国香港、曼谷、新加坡。
  • 同一 Region 跨 AZ 可建设高可用。

来源:华为云 ECS 区域和可用区

本次没有找到东京完整 Region 的可靠官方证据。日本节点如果是硬需求,应在华为云控制台、价格计算器和产品工单中逐项确认 ECS、RDS PostgreSQL、DCS、ELB、OBS 均能在同一东京 Region 购买后,再纳入方案。

PostgreSQL

  • RDS for PostgreSQL 主备版采用一主一备。
  • 支持跨 AZ 高可用。
  • 主备共用连接地址,故障切换时客户端会短暂中断并需要重连。
  • RDS 自动备份默认开启,官方资料显示保留期可配置为 1~3660 天,具体选项按 Region 和实例版本确认。
  • 香港、新加坡出现在 RDS PostgreSQL 规格支持范围。
  • 应用与 RDS 同 Region、同 VPC 时建议使用内网 IP。

来源:

Redis/DCS

  • DCS 主备实例包含主节点和备节点,默认数据持久化。
  • 主节点故障后,官方文档给出的自动切换时间为约 15~30 秒。
  • 支持跨 AZ 主备。
  • 主备、集群和读写分离实例支持备份恢复;单机不支持。
  • 自动备份默认关闭,自动备份最长保留 7 天。
  • DCS Redis 7.0 命令资料列出 EVAL、EVALSHA 和 Pub/Sub 能力。
  • 华为云官方明确 DCS 不支持原生跨 Region 多活。

来源:

对 Sub2API 的推荐:

  • 选择 Redis 6/7 主备,不选单机。
  • 创建后立即开启自动备份。
  • 额外将备份下载或转存到受控 OBS,以弥补 7 天自动保留限制。
  • 验证 15~30 秒切主期间的连接重试和锁恢复。

负载均衡和对象存储

  • ELB 支持 HTTP/HTTPS、长连接和 WebSocket。
  • ELB 到后端 ECS 使用 VPC 内网。
  • OBS 应和应用同 Region。

来源:

跨境与价格

  • 华为云 GA 覆盖大陆、香港、新加坡等接入点。
  • 跨中国大陆通信需要跨境资质审核。
  • ECS、RDS、DCS、ELB、OBS、EIP 和 GA 的具体价格应在采购时使用官方价格计算器。

来源:

8. 厂商对比

维度阿里云腾讯云华为云
大陆完整栈完整完整完整
香港完整栈已确认已确认已确认
新加坡完整栈已确认已确认已确认
东京完整栈已确认已确认本次未充分确认
PostgreSQL HA一主一备、跨 AZ双机高可用、多 AZ一主一备、跨 AZ
Redis 低配 HA256 MB 起的高可用选项0.25 GB 起、1~5 副本主备规格丰富,具体以控制台为准
Redis 备份默认每日,单节点不支持默认每日 RDB,支持克隆自动备份默认关闭,最长 7 天
七层 LBALBCLBELB
WebSocket默认支持支持默认支持
对象存储OSSCOSOBS
大陆跨境加速GA,备案/资质约束GAAP,跨境审核,香港精品 BGPGA,跨境资质审核
适合场景单云覆盖大陆、港新日大陆/香港链路重点实测已有华为云体系、港新部署

9. 成本评估方法

9.1 为什么本文不写死人民币月价

三家云的价格同时受以下因素影响:

  • Region。
  • 实例系列和 CPU 架构。
  • 包年包月、按量、节省计划和活动折扣。
  • 新老用户身份。
  • 系统盘、数据盘类型和容量。
  • 公网带宽按固定带宽或流量计费。
  • 数据库基础/高可用系列。
  • Redis 单机/主备/副本数。
  • 备份超额、日志、监控、审计、WAF、GA。
  • 税费和商务折扣。

因此,脱离账号和购买时间给出精确月价会形成虚假精度。

9.2 分阶段成本级别

阶段成本级别最大成本变量
第一阶段全家桶单机云服务器、磁盘、公网带宽、对象存储备份
第一阶段托管数据层中低小型 RDS + 主备 Redis
第二阶段双应用 + HA 数据层两台计算、LB、RDS HA、Redis HA、日志
第三阶段大陆 + APAC 双栈两套完整数据层、跨境加速、出网、WAF、备份和运维人力

一般而言:

  • 从单机升级为托管 PG/Redis,是第一次明显成本跃升。
  • 从单应用升级为两副本 + 数据层 HA,是第二次成本跃升。
  • 建设大陆与 APAC 两套独立数据层,成本不只是“翻倍”,还增加同步、合规、监控和演练。
  • GA/GAAP、精品 BGP 和跨境带宽可能成为第三阶段最大的可变账单。

9.3 采购当天的报价清单

在三家云价格计算器中建立相同配置,保存截图和导出预算:

100 用户

  • 1 × 应用 2C4G。
  • 可选 1 × 应用 4C8G。
  • 1 × PostgreSQL 2C4G 基础版。
  • 1 × PostgreSQL 2C4G/2C8G 高可用版。
  • 1 × Redis 主备 0.25/1 GB。
  • 50/100 GB 数据库存储。
  • 5/10 Mbps 公网带宽。
  • 100 GB 对象存储和备份。

500 用户

  • 2 × 应用 4C8G。
  • 1 × 七层负载均衡。
  • 1 × PostgreSQL HA 2C8G、4C8G。
  • 1 × Redis 主备 1/2 GB。
  • 100/200 GB 数据库存储。
  • 10/30 Mbps 公网带宽,另算出网流量。
  • WAF 基础套餐。
  • 日志服务 30 天。
  • 对象存储 500 GB。

双区域

  • 大陆与香港/新加坡分别复制上述第二阶段清单。
  • 单独添加 GeoDNS/全局流量、GA/GAAP、跨境资质线路、跨区备份和同步服务。

至少比较:

  • 按量月化。
  • 包月。
  • 包年折算月价。
  • 续费价,不只看首购活动价。

10. 上线验收清单

数据库

  • 使用 PostgreSQL 15+。
  • 应用通过 VPC 内网直连主实例。
  • 在同一连接中验证 pg_try_advisory_lock 和 unlock。
  • 执行全量迁移。
  • 设置连接数告警。
  • 完成 PITR 到隔离实例。
  • 验证管理员、用户、API Key、账号、余额、订单和用量。

Redis

  • 验证 EVALEVALSHASCRIPT LOAD
  • 验证 ZSET。
  • 验证两个应用副本间 Pub/Sub 缓存失效。
  • 验证并发槽位全局一致。
  • 验证 OAuth refresh lock 和 leader lock。
  • 执行主备切换。
  • 确认客户端自动重连。
  • 确认未使用会淘汰锁/队列 key 的 eviction policy。

负载均衡

  • HTTPS。
  • WebSocket。
  • SSE 首包和持续流。
  • 30 分钟以上长请求。
  • 空闲 keepalive。
  • 真实客户端 IP。
  • 连接排空。
  • 单副本下线。

网络

  • 大陆电信、联通、移动。
  • 香港、新加坡、东京探针。
  • P50/P95/P99 TCP connect、TLS、TTFB、完整流。
  • 到每个 AI 上游的 P50/P95。
  • 每天高峰和低峰持续 7~14 天。

备份

  • 不是只检查“备份任务成功”,而是恢复到新实例。
  • 发布前手动备份。
  • 每月 PG 恢复演练。
  • 每季度 Redis 和应用故障演练。
  • 对象存储备份启用加密、生命周期和访问审计。

安全

  • 数据库和 Redis 无公网入口。
  • 应用实例不直接暴露 8080。
  • SSH 仅堡垒机/VPN/固定管理网段。
  • 固定并备份 JWT_SECRETTOTP_ENCRYPTION_KEY
  • 启用管理员 TOTP。
  • 开启 URL allowlist 和 SSRF 防护。
  • 数据库备份含 OAuth token/API Key,必须加密和最小权限。

11. 最终推荐

如果现在只有约 100 用户

如果还没有 ICP:

  • 选择阿里云或腾讯云中国香港。
  • 低成本试运营可先单台 4C8G Docker Compose。
  • 一旦开始稳定收费,先把 PostgreSQL 和 Redis 迁到同 Region 托管服务。

如果已有 ICP:

  • 选择广州/深圳或上海大陆 Region。
  • 应用 Docker 单实例 2C4G/4C8G。
  • PostgreSQL 2C4G 托管。
  • Redis 0.25~1 GB 主备。
  • 同时测试境外 AI 上游链路;如果上游 RTT 是主要瓶颈,再评估香港独立栈,而不是把数据库搬到香港。

如果接近约 500 用户

  • 两台 4C8G 跨 AZ。
  • 云七层负载均衡。
  • PostgreSQL 高可用 2C8G 或 4C8G。
  • Redis 1~2 GB 主备、单分片。
  • 对象存储、云日志、固定出口。
  • 仍保持单 Region,先把恢复、滚动发布和故障切换做好。

如果大陆和 APAC 都需要低延迟

  • 阿里云是本次调研中最容易形成大陆、香港、新加坡、东京同云产品矩阵的默认选择。
  • 腾讯云同样可行,尤其应实测香港精品 BGP 对大陆三网的改善。
  • 华为云适合大陆、香港、新加坡方案;日本节点需额外确认。
  • 最终架构应是大陆和 APAC 两套独立 Sub2API + PostgreSQL + Redis。
  • 不采用跨境远程数据库,不共享 Redis,不在没有数据 ownership 的情况下做双写。

12. 官方资料索引

项目文档

监管

阿里云

腾讯云

华为云

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