xiaoyu/topfans
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add design spec for Docker to Kubernetes migration

Browse Source 
Three approaches analyzed (single-tenant, hybrid, full-isolation), with detailed pros/cons comparison. Recommended: shared platform services + per-group data services isolation via namespaces and Helm chart.
This commit is contained in:
zheng020 2026-06-08 14:27:09 +08:00
parent 0029fb8cc8
commit 82ba768880
1 changed files with 502 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

502
docs/superpowers/specs/2026-06-08-docker-to-k8s-migration-design.md Normal file
View File

@ -0,0 +1,502 @@
# Docker → Kubernetes 迁移 设计文档
- 日期: 2026-06-08
- 涉及模块: `docker/` 全部产物、新增 `k8s/` 目录、未来四个新服务
- 现状: `docker-compose.prod.yml` 在单台 VM (`101.132.250.62`) 上跑 10 个 Go 服务 + Postgres + Redis
- 目标: 迁移到 Kubernetes,支持按"明星组"分服务器扩展,为新服务(admin/review/ai-image-gen/ai-chat)预留接入位
---
## 一、背景与动机
### 1.1 业务背景
TopFans 是一个"明星粉丝平台"。不同明星的粉丝量差异极大:
- **头部明星**: 单明星可占整平台 50%+ 流量,需要独立扩展
- **腰部明星**: 几个明星可共享资源池
- **尾部明星**: 大量冷启动明星,合并部署降低成本
运营方希望:**针对不同明星组,可以独立分配服务器资源、互不影响。**
### 1.2 当前架构瓶颈
`docker-compose.prod.yml` 是单机部署,本质限制:
| 能力 | Docker Compose | Kubernetes |
|---|---|---|
| 多机部署 | ❌ | ✅ |
| 按业务线隔离资源 | ❌ | ✅ (namespace + ResourceQuota) |
| 自动扩缩容 | ❌ | ✅ (HPA/KEDA) |
| 滚动升级 | 手动 | ✅ |
| 故障自愈 | 手动 | ✅ |
| 新增业务线 | 改 compose | helm install |
### 1.3 即将到来的新服务
代码或 PRD 中已提及、未来需要独立部署的:
| 服务 | 作用 | 复用关系 |
|---|---|---|
| `admin` | 后台管理平台(运营、客服) | 复用 userservice / 独立 DB schema |
| `review` | 审核工作流(UGC 内容审核) | 调用 assetservice / 独立 DB |
| `ai-image-gen` | AI 图片生成(镭射卡) | 当前嵌在 gateway 调用 MiniMax,可独立 |
| `ai-chat` | AI 对话(粉丝互动) | 当前是 aichatservice,可拆分 |
---
## 二、候选方案 (三个架构 + 优缺点对比)
### 2.1 方案 A:单租户架构 (应用层多租户)
**结构**: 集群里只部署**一份**完整的微服务栈,所有明星组共享,通过 `group_id` 在应用层和数据层做隔离。
```
namespace: topfans
├── gateway, userservice, assetservice, galleryservice, ...
├── postgres (一份,所有组数据混在一起,用 group_id 区分)
└── redis (一份,key 加 group: 前缀)
```
**优点**:
1. **部署最简单**: 只有一套 deployment,运维心智负担最低
2. **资源利用率最高**: 没有"为低流量组预留资源"的浪费
3. **代码改动最小**: 完全沿用现有 docker-compose 的服务间调用方式
4. **配置最少**: 只需要一份 values.yaml
**缺点**:
1. ❌ **吵市占率问题严重**: 头部明星的爆款活动会拖慢所有其他明星
2. ❌ **无法"按明星分服务器"**: 这正是用户提的核心需求
3. ❌ **故障爆炸半径大**: gateway 单点故障影响所有组
4. ❌ **扩容粒度粗**: 只能整体扩,无法精准给某个组加机器
5. ❌ **合规/数据隔离弱**: 某些明星可能有合规要求(肖像、隐私),数据物理混在一起不好处理
6. ❌ **不满足用户的根本需求**: 用户明确说"分服务器使用",此方案做不到
**适用场景**: 业务初期、流量小、组少(<3)、无合规要求。
**结论**: **不推荐**。与用户需求正面冲突。
---
### 2.2 方案 B:共享基础服务 + 按组隔离数据服务 ⭐ 推荐
**结构**: 平台型服务全集群一份(放 `topfans-shared`),数据敏感型服务按组复制(放 `topfans-group-*`)。
```
namespace: topfans-shared (平台共享,1 份)
├── admin (未来)
├── review (未来)
├── ai-image-gen (未来)
├── ai-chat (未来)
└── (Postgres / Redis 走外部托管,K8s 内只放 ExternalName 占位)
namespace: topfans-group-<group-name> (每组 1 个,1+ 明星)
├── gateway ← 入口,组内独享
├── userservice, assetservice, galleryservice,
│ socialservice, activityservice, starbookservice,
│ taskservice, aichatservice, lasercompositor
├── ResourceQuota ← 防吵市占率
└── LimitRange ← 单 Pod 上限
Ingress (集群级)
├── *.api.example.com → 按 Host 路由
└── admin.api.example.com → topfans-shared/admin
```
**优点**:
1. ✅ **核心数据服务可按组独立扩缩容** (用户核心需求)
2. ✅ **Gateway 也按组分**,Dubbo tri:// 协议栈短 DNS 名就够用,应用代码零改动
3. ✅ **共享服务复用**: AI 模型权重不可能每组复制,放 shared 反而合理
4. ✅ **故障隔离**: 一个组的 gateway 挂了不影响其他组
5. ✅ **可加新组成本极低**: `helm install` 一行,无需改应用代码
6. ✅ **运维友好**: 每组 namespace 独立,`kubectl config set-context --namespace=...` 即可隔离操作
7. ✅ **ResourceQuota + LimitRange 双层防爆**: 既控总量又控单 Pod
8. ✅ **新服务天然接入**: `admin / review / ai-*` 放 shared,一次部署全集群可用
**缺点**:
1. ⚠️ **管理面多**: 每组要单独做一次 helm install(可由 CI/CD 自动化)
2. ⚠️ **Pod 数量较多**: 9 数据服务 × N 组 = 较多 Pod,但 K8s 调度能 handle
3. ⚠️ **DB 仍是中心化**: Postgres 走外部托管,流量大时需做读写分离或拆库(后续可加 K8s 内的只读副本 Service)
4. ⚠️ **AI 服务被多个组共享**: 需要做 rate limit / quota 防止某组把 AI 资源吃光(可在 gateway 层加限流)
5. ⚠️ **首次配置稍复杂**: 要给每组填一份 values.yaml,但模板化后还好
**适用场景**: 中型平台、有明显头部尾部差异、需要合规隔离、为未来扩展留空间。**完全匹配用户需求**。
**结论**: **强烈推荐**。
---
### 2.3 方案 C:完全独立每组(含 AI/审核/管理也复制)
**结构**: 每个明星组独立一个 namespace,里面有**完整**的服务栈,包括 admin / review / AI。
```
namespace: topfans-group-a
├── gateway, userservice, assetservice, ... (9 个数据服务)
├── admin, review, ai-image-gen, ai-chat (平台服务也复制)
└── (无外部 DB,每组有独立 PG/Redis)
```
**优点**:
1. ✅ **物理级隔离**: 任何资源共享都不存在
2. ✅ **故障爆炸半径最小**: 一组全挂不影响其他组
3. ✅ **合规最优**: 数据完全分开
4. ✅ **可独立选择技术栈**: 每组可用不同版本
**缺点**:
1. ❌ **AI 模型权重不可能每组复制**: 一个 LLaVA/SD 模型几十 GB,几个组就是几 TB,启动慢、内存贵
2. ❌ **运维噩梦**: N 个组要维护 N 套全栈,版本同步、配置漂移都是问题
3. ❌ **资源严重浪费**: 小流量组根本用不上那么多资源
4. ❌ **新服务接入要 N 次部署**: 加一个 ai-image-gen 要 N 个 namespace 改一遍
5. ❌ **与用户实际需求不匹配**: 用户没要求"AI 也每组独立"
**适用场景**: 金融、医疗、政企等强合规、且客户付费意愿足够高的场景。
**结论**: **不推荐**。对本业务过度设计。
---
## 三、方案对比总结表
| 维度 | 方案 A 单租户 | 方案 B 共享+按组隔离 ⭐ | 方案 C 完全隔离 |
|---|---|---|---|
| 部署复杂度 | ⭐ 最低 | ⭐⭐ 中等 | ⭐⭐⭐ 最高 |
| 资源利用率 | ⭐⭐⭐ 最高 | ⭐⭐ 中等 | ⭐ 最低 |
| 按组扩缩容 | ❌ 不支持 | ✅ 完美支持 | ✅ 完美支持 |
| 故障爆炸半径 | 大 | 中(按组) | 小(按组) |
| 吵市占率 | 严重 | 轻(ResourceQuota 控) | 几乎无 |
| AI 资源浪费 | 无 | 低(共享) | 严重(每组一份) |
| 新服务接入成本 | 1 次 | 1 次(放 shared) | N 次(每组) |
| 数据合规隔离 | 弱 | 中(逻辑隔离) | 强(物理隔离) |
| 与"分服务器"需求匹配 | ❌ | ✅ | ✅ |
| **推荐度** | ❌ | ✅✅✅ 强烈推荐 | ❌ |
---
## 四、推荐方案 (B) 详细设计
### 4.1 集群拓扑
```
K8s 集群
│
├── namespace: topfans-shared
│ ├── (未来) admin — Deployment + Service
│ ├── (未来) review — Deployment + Service
│ ├── (未来) ai-image-gen — Deployment + Service
│ ├── (未来) ai-chat — Deployment + Service
│ ├── postgres-ext — Service (ExternalName → RDS endpoint)
│ ├── redis-ext — Service (ExternalName → ElastiCache endpoint)
│ ├── db-credentials — Secret
│ └── oss-credentials — Secret
│
├── namespace: topfans-group-<group-name> (例: topfans-group-a)
│ ├── ResourceQuota (CPU/内存/Pod 总上限)
│ ├── LimitRange (单 Pod 默认值)
│ ├── gateway — Deployment + Service (ClusterIP) + ConfigMap + Secret
│ ├── userservice — Deployment + Service (ClusterIP) + ConfigMap
│ ├── assetservice — 同上
│ ├── galleryservice — 同上
│ ├── socialservice — 同上
│ ├── activityservice — 同上
│ ├── starbookservice — 同上
│ ├── taskservice — 同上
│ ├── aichatservice — 同上
│ └── lasercompositor — 同上
│
└── Ingress (集群级,Gateway API 或传统 Ingress)
├── group-a.api.example.com → topfans-group-a/gateway:8080
├── group-b.api.example.com → topfans-group-b/gateway:8080
├── admin.api.example.com → topfans-shared/admin:80
└── ... (按 Host 头或 path 路由)
```
### 4.2 关键设计点
#### 4.2.1 Gateway 放在每组 namespace 内 (而不是 shared)
**原因**: Dubbo `tri://` 是 TCP 二进制协议,K8s Ingress / Service 无法做基于 HTTP Host/Path 的智能路由。
把 gateway 放在组内,可以让组内服务间用短 DNS 名调用:
```yaml
# 组内 gateway 的环境变量 (相对原 compose 几乎无改动)
DUBBO_USER_SERVICE_URL: tri://userservice:20000 # 同 ns 短名
DUBBO_ASSET_SERVICE_URL: tri://assetservice:20003
DUBBO_SOCIAL_SERVICE_URL: tri://socialservice:20002
DUBBO_GALLERY_SERVICE_URL: tri://galleryservice:20001
DUBBO_ACTIVITY_SERVICE_URL: tri://activityservice:20004
DUBBO_TASK_SERVICE_URL: tri://taskservice:20006
DUBBO_STARBOOK_SERVICE_URL: tri://starbookservice:20005
DUBBO_AI_CHAT_SERVICE_URL: tri://aichatservice:20008
LASER_COMPOSITOR_URL: http://lasercompositor:7002
```
**应用代码零改动** — 相对原 `docker-compose.prod.yml` 只需把服务名换成 K8s 短 DNS 名。
#### 4.2.2 Postgres / Redis 走外部托管
K8s 内只创建 `ExternalName` Service 占位:
```yaml
# topfans-shared/postgres-external.yaml
apiVersion: v1
kind: Service
metadata:
name: postgres
namespace: topfans-shared
spec:
type: ExternalName
externalName: rm-xxxxxx.mysql.rds.aliyuncs.com # 阿里云 RDS endpoint
```
**好处**:
- K8s 不需要管 StatefulSet / PVC / 备份 / 主从切换(全部交给云服务)
- 所有组共享同一份数据库,通过 `group_id` 在 schema 层面区分
- 后续压力大了,云上一键升配即可,无需迁移数据
**所有组数据如何隔离**: 在现有表上加 `group_id` 字段,应用层做行级过滤。**这是应用层改动,不在本次 K8s 迁移范围**,但需要在设计文档里记录。
#### 4.2.3 ResourceQuota + LimitRange 双层防护
```yaml
# topfans-group-a/resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: group-a-quota
namespace: topfans-group-a
spec:
hard:
requests.cpu: "10" # 总 CPU 申请
requests.memory: 20Gi # 总内存申请
limits.cpu: "20"
limits.memory: 40Gi
pods: "50" # 最多 50 个 Pod
persistentvolumeclaims: "5"
---
apiVersion: v1
kind: LimitRange
metadata:
name: group-a-limits
namespace: topfans-group-a
spec:
limits:
- type: Container
default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 100m
memory: 128Mi
max:
cpu: 2
memory: 4Gi
```
#### 4.2.4 镜像构建与推送策略
**两种选择**:
- **方式 1 (推荐)**: CI 构建镜像推送阿里云 ACR,Helm 通过 `image.tag` 引用
- **方式 2**: 维持当前 `deploy.sh` 的"本地 build → SSH 推到服务器"流程,服务器装 containerd/nerdctl
**推荐方式 1**,原因:
- 镜像版本化管理 (`:v1.0.0`)
- 利用镜像分发,build 一次,所有 K8s 节点共享
- rollback 简单: `helm rollback topfans-group-a 1`
需要在 `Dockerfile.services` 增加 base 镜像 tag 参数(目前是 `FROM --platform=linux/amd64 alpine:3.19`,已 OK),在 CI 脚本里改 tag 即可。
#### 4.2.5 健康检查修正
原 `docker/Dockerfile.services` 中存在 **HEALTHCHECK 端口错配 bug**:
| 服务 | 应用监听 | Dockerfile HEALTHCHECK 用 | 状态 |
|---|---|---|---|
| galleryservice | 20001 | 21001 | ❌ 错的,会一直 fail |
| socialservice | 20002 | 21002 | ❌ 同上 |
| activityservice | 20004 | 21004 | ❌ 同上 |
| taskservice | 20006 | 21006 | ❌ 同上 |
| starbookservice | 20005 | 21005 | ❌ 同上 |
| aichatservice | 20008 | 21008 | ❌ 同上 |
其他服务端口配置正确: gateway 8080、userservice 20000、assetservice 20003、lasercompositor 7002。
K8s 迁移时,改用 `livenessProbe` / `readinessProbe` 显式配置,**顺便修复这个 bug**。
#### 4.2.6 Secrets 管理
```yaml
# topfans-group-a/gateway-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: gateway-secrets
namespace: topfans-group-a
type: Opaque
stringData:
DB_PASSWORD: <从 base64 或外部 secret store 注入>
REDIS_PASSWORD: ...
JWT_SECRET: ...
OSS_ACCESS_KEY_ID: ...
OSS_ACCESS_KEY_SECRET: ...
DIFY_API_KEY: ...
MINIMAX_API_KEY: ...
QWEN_API_KEY: ...
```
**生产建议**: 配合 [External Secrets Operator](https://external-secrets.io/) 或阿里云 KMS,不要把明文 secret 提交到 git。本期先用原生 Secret 加密,后续接 secret manager。
### 4.3 数据层多租户设计 (应用层改动,不在本次范围)
本次 K8s 迁移只解决编排层。多组数据隔离需要在应用层做配套改动,简要列出:
| 表 | 加 group_id 字段 | 中间件透传 group_id |
|---|---|---|
| users | ✅ | JWT 携带 group_id |
| galleries / assets / stars | ✅ | Dubbo attachment 透传 |
| 评论/点赞/收藏 | ✅ | 同上 |
建议在另一份专门的设计文档中详细设计,**本文档不展开**。
---
## 五、目录结构
```
k8s/ (新目录,根目录同级)
├── README.md 运维使用手册
├── helm/
│ ├── topfans-shared/ Chart 1: 共享服务
│ │ ├── Chart.yaml
│ │ ├── values.yaml 默认值
│ │ ├── values-prod.yaml 生产覆盖
│ │ ├── values-dev.yaml 开发覆盖
│ │ └── templates/
│ │ ├── _helpers.tpl
│ │ ├── external-db/
│ │ │ ├── postgres-external.yaml ExternalName → RDS
│ │ │ └── redis-external.yaml ExternalName → ElastiCache
│ │ ├── admin/ (未来,.gitkeep 占位)
│ │ ├── review/ (未来)
│ │ ├── ai-image-gen/ (未来)
│ │ ├── ai-chat/ (未来)
│ │ └── secrets/
│ │ ├── db-credentials.yaml
│ │ └── oss-credentials.yaml
│ │
│ └── topfans-group/ Chart 2: 每组一份
│ ├── Chart.yaml
│ ├── values.yaml 默认值 + 文档
│ ├── values-group-a.yaml 实际组 A 配置示例
│ ├── values-group-b.yaml 实际组 B 配置示例
│ └── templates/
│ ├── _helpers.tpl
│ ├── namespace.yaml 创建组 namespace
│ ├── resource-quota.yaml
│ ├── limit-range.yaml
│ ├── gateway/ deployment + service + configmap + secret
│ ├── userservice/
│ ├── assetservice/
│ ├── galleryservice/
│ ├── socialservice/
│ ├── activityservice/
│ ├── starbookservice/
│ ├── taskservice/
│ ├── aichatservice/
│ └── lasercompositor/
│
└── ingress/
└── ingress.yaml 集群级 Ingress(可放 helm 也可 kubectl apply)
```
**原则**:
- `docker/` 目录保留,继续支撑本地开发 (`docker-compose.local.yml`)
- `k8s/` 是新增的部署维度,与 `docker/` 并存
- 未来四个新服务**不在本次实现**,只留 `.gitkeep` 占位 + README 说明
- 镜像构建继续走 `docker/Dockerfile.services` (多阶段),不重复造轮子
---
## 六、迁移计划 (建议分 4 步走)
### Step 1: K8s 基础设施 (本期)
- [ ] 在阿里云 ACK 创建测试集群 (或自建 k3s)
- [ ] 部署 nginx-ingress / cert-manager (HTTPS)
- [ ] 创建 `topfans-shared` namespace + ExternalName 占位
- [ ] 编写 `topfans-shared` Helm chart (不含未来服务)
- [ ] 编写 `topfans-group` Helm chart (含全部 9 个数据服务 + gateway)
- [ ] 准备 `values-group-a.yaml` 模板 (用现有 .env.prod 内容填充)
- [ ] 修复 Dockerfile 健康检查端口错配 bug
- [ ] 编写 README: 加新组的步骤 (`helm install` 一行)
### Step 2: 灰度切换 (本期可一并做)
- [ ] 把现有 .env.prod 的所有密钥搬到 K8s Secret
- [ ] 准备 DNS 切换预案 (`group-a.api.example.com` 先解析到 K8s,旧 VM 保留回滚)
- [ ] 选 1 个非关键组(如内部测试组)切到 K8s,跑 1~2 周
- [ ] 验证: 业务功能 / 性能 / 故障恢复
### Step 3: 全量切换
- [ ] 切所有组到 K8s
- [ ] 停 VM 上的 `docker-compose`
- [ ] 释放 VM 资源
- [ ] 第一次: 取消注释 `init-db.sql` 中所有序列同步(从手工迁移数据开始时,见 CLAUDE.md 规范)
### Step 4: 后续优化 (本期不做)
- [ ] 接 External Secrets Operator
- [ ] 接 Prometheus + Grafana
- [ ] 接 Loki 日志收集
- [ ] 接 ArgoCD / Flux 做 GitOps
- [ ] 加 HPA (HPA + 自定义指标:KEDA)
- [ ] 实施应用层多租户改造(group_id 透传)
---
## 七、风险与待定项
| 风险/待定 | 影响 | 缓解 |
|---|---|---|
| 现有 docker-compose 在生产跑,切换期间需双轨 | 资源消耗 | 测试组先切,观察 1~2 周再切正式组 |
| Postgres 走外部 RDS,数据迁移 | 数据一致性 | 用阿里云 DTS 做实时同步,切换时切流量 |
| Gateway 在 K8s 内,Dubbo 跨 ns 调用 | 服务发现 | 短 DNS 名 + 同 ns 部署,无问题 |
| 镜像构建走 CI 还是保留 deploy.sh | 流程变更 | 推荐 CI,本期可先保留 deploy.sh 过渡 |
| 新服务具体技术栈未定 | 模板不完整 | `.gitkeep` 占位,后续按需填 |
| 集群选型:ACK / TKE / 自建 k3s | 成本/可控性 | 建议先 ACK 测试,稳定后定型 |
| HPA 是否启用 (按 CPU / 自定义指标) | 资源效率 | 本期不开,观察流量稳定后加 |
| 多集群 / 多 region 容灾 | 灾备 | 暂不考虑,后续规划 |
---
## 八、用户已确认的关键决策
1. ✅ **按"组"隔离资源**,每组 1 个或多个明星,可灵活组合
2. ✅ **配置格式: Helm Chart**
3. ✅ **数据库: 外部托管 (RDS/ElastiCache)**
4. ✅ **Gateway 放在每组 namespace 内** (而非 shared)
5. ✅ **新服务 (admin / review / ai-image-gen / ai-chat) 放在 `topfans-shared`**
6. ✅ **保留 `docker/` 目录,继续支撑本地开发**
---
## 九、不在本次范围
- 新服务 (admin / review / ai-image-gen / ai-chat) 的实现
- 应用层多租户改造 (group_id 字段添加与透传)
- CI/CD 流水线改造 (CI 自动构建镜像)
- 监控/日志/告警接入
- 灾备多集群
- K8s 内的 StatefulSet (Postgres/Redis 用云服务,不自己跑)