# 容量与安全收口计划

## 当前架构判断

当前生产方案是单机 Docker Compose：

- Caddy：HTTPS、反向代理、基础安全头。
- Web：Next production server，单容器。
- Backend：Node 22 lite server，单容器、单进程。
- Postgres：单实例。
- MinIO：单实例对象存储。
- Prometheus / Grafana / Alertmanager：监控骨架。

这套架构适合第一版生产上线和真实业务验证，但不是“天然无限并发”。上线前必须做压测和安全验收，上线后按指标扩容。

## 粗略容量预估

下面是没有正式压测前的保守估计，只能用于规划，不能当 SLA。

| 服务器规格 | 适合阶段 | 活跃并发用户 | 混合 API 吞吐 | 备注 |
| --- | --- | ---: | ---: | --- |
| 2C / 4G | 体验/预生产 | 50-100 | 20-50 RPS | 只适合内测和小流量 |
| 4C / 8G | 第一版生产 | 200-500 | 50-150 RPS | 比较适合作为初始生产 |
| 8C / 16G | 稳定生产起步 | 500-1500 | 150-300 RPS | 需要配好 DB、磁盘、监控 |

用户总量和并发不是一回事。注册用户可以是几万甚至更多，关键看同时在线、同时下单、同时上传文件、后台操作峰值。

第一版上线建议按以下容量口径验收：

- 日活：先按 1,000-5,000 人准备。
- 同时活跃：先按 200-500 人准备。
- 支付创建：先按 5-15 单/秒以内准备。
- 文件上传：限制大文件并发，第一版不要超过 5-10 个大文件同时上传。
- 后台员工：10-50 人同时操作通常不是瓶颈。

如果活动推广、集中报名、课程抢购、专家预约集中开放，需要单独做峰值压测。

## 压测通过门槛

服务器 Agent 部署后必须补压测，建议使用 k6、autocannon 或 Artillery。

最低通过标准：

- 首页/商品/列表类接口 p95 < 800ms。
- 登录、订单、支付创建类接口 p95 < 2000ms。
- 5xx 错误率 < 1%。
- Postgres CPU 长时间 < 70%。
- Postgres 连接数 < 最大连接数 70%。
- 后端容器内存稳定，无持续增长。
- MinIO 上传/下载 p95 在可接受范围内。
- 支付回调重复请求不会重复发权益。
- 短信接口压测时能触发限流，不会无限发送。

建议压测场景：

1. 匿名用户浏览首页、商品、专家、课程。
2. 普通用户手机号验证码登录。
3. 用户创建订单、创建支付单、轮询支付状态。
4. PC 小程序码登录轮询。
5. 后台订单/发票/异常中心列表查询。
6. 文件上传和下载。

## 当前主要瓶颈

1. Backend 是单 Node 进程  
   CPU 密集或大量同步 JSON/文件处理会阻塞。需要后续多副本或 Node cluster。

2. Postgres 与业务服务在同一台机器  
   磁盘 IO、备份、查询峰值会互相影响。业务增长后应独立数据库或至少独立磁盘。

3. 目前没有 PgBouncer  
   Prisma/业务连接在高并发时可能打满 Postgres 连接数。生产压测后建议加 PgBouncer。

4. MinIO 与数据库同机  
   大文件上传/下载会抢磁盘和带宽。高文件量时建议 MinIO 单独磁盘、单独机器或切 OSS。

5. Caddy 目前没有强限流/WAF  
   生产必须补边缘限流，尤其是短信、登录、支付、上传、后台接口。

6. 仍有历史 SQL 字符串代码  
   Prisma 已推进，但还没 100% 消除运行时 SQL 拼接。这仍是安全债。

7. 小程序/PC 登录轮询会放大请求量  
   扫码登录、支付状态轮询都要控制频率和过期时间，避免大量用户同时轮询拖垮后端。

## 第一版生产必须补的安全措施

### 网络与边界

- 公网 80/443 只由宿主机外层 nginx 暴露；本项目 Docker Compose 内的 Caddy 仅绑定 `127.0.0.1:8082`。
- Postgres、MinIO Console、Prometheus、Grafana、Alertmanager 不对公网开放。
- Grafana/Prometheus 只允许内网或 VPN 访问。
- Caddy 保留 HSTS、nosniff、Referrer-Policy。
- 增加 Content-Security-Policy，降低 XSS 风险。
- 使用 CDN/WAF 或至少在 Caddy 层做基础限流。

### 限流

必须限流的接口：

- 发送验证码。
- 验证码登录。
- PC 扫码登录创建和轮询。
- 支付单创建。
- 支付状态轮询。
- 文件上传。
- 后台登录和高危操作。

建议初始规则：

- 发送验证码：同手机号 1 分钟 1 次，1 小时 5 次，1 天 10 次。
- 登录尝试：同手机号/同 IP 10 分钟 10 次。
- 支付创建：同用户 1 分钟 10 次。
- 支付轮询：同 session 2 秒以上一次。
- 文件上传：单用户并发 2-3 个，单文件大小按业务分场景限制。

### 管理后台

- 超级管理员只保留一个 bootstrap 手机号。
- 管理员/员工继续手机号验证码登录，但高危操作建议二次确认。
- 后续建议增加后台登录 IP allowlist 或 VPN。
- 财务、发票、提现、订单补偿、异常处理全部写审计日志。
- 删除、驳回、标记已支付、上传凭证等动作必须可追溯。

### 数据与隐私

- 日志不得记录验证码、密钥、证书、完整身份证、完整银行卡。
- 手机号展示做脱敏，后台详情按权限显示完整信息。
- 发票文件、专家材料、数据服务交付文件必须私有鉴权。
- 备份文件必须加密或至少隔离权限。
- 制定数据删除、导出和留存策略。

### 文件安全

- 上传必须校验大小、扩展名、MIME。
- 私有文件不走公开 MinIO bucket。
- 公共 bucket 只放商品/CMS/Logo/公开头像。
- 发票 PDF/OFD、专家材料、提现凭证、交付文件必须鉴权下载。
- 后续建议接 ClamAV 或云查毒。

### 支付安全

- 微信支付成功只认后端验签回调。
- 前端支付成功只能刷新状态，不能直接改订单。
- 回调必须校验 appid、mchid、金额、out_trade_no。
- 重复回调必须幂等，不能重复发权益。
- 增加主动查单补偿和超时关单。
- 财务对账必须有后台记录和导出。

### 代码安全

- Prisma 全量迁移继续推进，最终业务运行时不再使用 SQL 字符串拼接。
- CI 增加依赖漏洞扫描、secret scan、lint、build、测试。
- 生产禁用 dev 验证码、dev 支付、dev-admin-token。
- `.env`、pem、p12、zip 证书永远不进 Git。

## 扩容路线

### 第 1 阶段：单机稳态

- 4C/8G 或 8C/16G。
- Docker Compose 单机。
- Postgres + MinIO 同机但持久卷独立。
- 适合第一版上线、低到中等访问量。

### 第 2 阶段：单机增强

- 加 PgBouncer。
- 后端多副本。
- Web 多副本。
- Caddy 负载均衡。
- MinIO 单独磁盘。
- 增加 Redis，用于限流、验证码、短期 session、任务队列。

### 第 3 阶段：拆分服务

- Postgres 独立服务器或托管数据库。
- MinIO 独立服务器或切阿里云 OSS。
- 后端服务水平扩容。
- 异步任务 worker 独立处理短信、支付补偿、发票、备份、文件扫描。
- CDN/WAF 承接静态资源和攻击流量。

## 上线前阻断项

以下任一项不通过，不建议正式开放大流量：

- 生产 `.env` 仍使用默认密码或默认密钥。
- `/api/health/deep` 不通过。
- 备份没有实跑，恢复没有演练。
- 微信支付回调没有真单验证。
- MinIO 私有文件越权测试失败。
- 验证码/登录/支付没有限流。
- 管理后台公网裸奔且没有强登录保护。
- 监控和告警没有跑通。
- 服务器 Agent 没有完成压测。
