.gitignore 更新: - 添加 pixi 环境和 .claude 目录忽略 - 添加 supabase-stack 相关忽略规则 - 添加 web/ws/postgres_data/pgdata/ 数据库数据忽略 docs/ 文档: - strategy-1-path-prefix.md: 路径前缀部署方案 - strategy-2-subdomain.md: 子域名部署方案 - strategy-3-hybrid.md: 混合部署方案 - strategy-comparison-report.md: 策略对比报告 这些文档详细说明了 Traefik 反向代理的三种部署策略, 为多应用部署提供参考方案。
520 lines
11 KiB
Markdown
520 lines
11 KiB
Markdown
# 策略 3:混合部署方案
|
||
|
||
## 📋 策略概述
|
||
|
||
**核心思想**:主要业务使用子域名,次要功能使用路径前缀,灵活组合。
|
||
|
||
**访问方式**:
|
||
```
|
||
主要业务(子域名):
|
||
https://abm.amiap.hzau.edu.cn # ABM 数据库
|
||
https://lab.amiap.hzau.edu.cn # 实验室主页
|
||
|
||
次要功能(路径):
|
||
https://amiap.hzau.edu.cn/api # API 接口
|
||
https://amiap.hzau.edu.cn/downloads # 下载中心
|
||
https://amiap.hzau.edu.cn/ # 主站
|
||
```
|
||
|
||
---
|
||
|
||
## 🏗️ 技术架构
|
||
|
||
### 路由配置
|
||
```yaml
|
||
services:
|
||
# ========== 主要业务:子域名 ==========
|
||
nginx-abm:
|
||
labels:
|
||
- "traefik.http.routers.abm.rule=Host(`abm.amiap.hzau.edu.cn`)"
|
||
# 无需 priority
|
||
|
||
nginx-lab:
|
||
labels:
|
||
- "traefik.http.routers.lab.rule=Host(`lab.amiap.hzau.edu.cn`)"
|
||
|
||
# ========== 次要功能:路径 ==========
|
||
nginx-main:
|
||
labels:
|
||
# API 服务
|
||
- "traefik.http.routers.api.rule=Host(`amiap.hzau.edu.cn`) && PathPrefix(`/api`)"
|
||
- "traefik.http.routers.api.priority=100"
|
||
|
||
# 下载中心
|
||
- "traefik.http.routers.downloads.rule=Host(`amiap.hzau.edu.cn`) && PathPrefix(`/downloads`)"
|
||
- "traefik.http.routers.downloads.priority=100"
|
||
|
||
# 主站(根路径)
|
||
- "traefik.http.routers.main.rule=Host(`amiap.hzau.edu.cn`)"
|
||
- "traefik.http.routers.main.priority=1"
|
||
```
|
||
|
||
### 文件系统结构
|
||
```
|
||
容器 1 (ABM - 子域名):
|
||
/usr/share/nginx/html/
|
||
├── index.html ← 根目录
|
||
├── css/
|
||
└── js/
|
||
|
||
容器 2 (Lab - 子域名):
|
||
/usr/share/nginx/html/
|
||
├── index.html ← 根目录
|
||
└── assets/
|
||
|
||
容器 3 (Main - 混合):
|
||
/usr/share/nginx/html/
|
||
├── index.html ← 主站根目录
|
||
├── api/ ← API 路径对齐
|
||
│ └── index.html
|
||
└── downloads/ ← 下载中心路径对齐
|
||
└── index.html
|
||
```
|
||
|
||
### 决策树
|
||
```
|
||
新网站/功能 → 判断重要性
|
||
↓
|
||
是否是主要业务?
|
||
├─ 是 → 使用子域名
|
||
│ ├─ 需要独立品牌
|
||
│ ├─ 高流量
|
||
│ ├─ 需要独立管理
|
||
│ └─ 长期运行
|
||
│
|
||
└─ 否 → 使用路径前缀
|
||
├─ 辅助功能(API、下载)
|
||
├─ 临时功能
|
||
├─ 流量小
|
||
└─ 不需要独立品牌
|
||
```
|
||
|
||
---
|
||
|
||
## ✅ 优点分析
|
||
|
||
### 1. 灵活性最高 ⭐⭐⭐
|
||
**场景适应**:
|
||
```
|
||
业务 A:重要产品 → 子域名
|
||
业务 B:辅助工具 → 路径
|
||
业务 C:临时活动 → 路径
|
||
```
|
||
|
||
**按需选择**:
|
||
- 重要的用子域名(最佳性能)
|
||
- 次要的用路径(快速部署)
|
||
- 根据实际情况灵活调整
|
||
|
||
### 2. 成本优化 ⭐⭐
|
||
**DNS 成本**:
|
||
```
|
||
主要业务:3-5 个子域名
|
||
次要功能:共用主域名
|
||
总计:3-5 条 DNS 记录(而不是 10+ 条)
|
||
```
|
||
|
||
**证书成本**:
|
||
```
|
||
方案 A:通配符证书(覆盖所有)
|
||
方案 B:主域名证书 + 单独子域名证书
|
||
```
|
||
|
||
### 3. 逐步迁移 ⭐⭐
|
||
**迁移路径**:
|
||
```
|
||
阶段 1:所有网站用路径(快速启动)
|
||
阶段 2:重要业务迁移到子域名
|
||
阶段 3:次要功能保持路径
|
||
```
|
||
|
||
**无需一次性切换**:
|
||
- 可以分批迁移
|
||
- 降低风险
|
||
- 平滑过渡
|
||
|
||
### 4. 资源分层 ⭐
|
||
**优先级管理**:
|
||
```
|
||
高优先级业务:子域名 + 独立容器 + 独立资源
|
||
低优先级功能:路径 + 共享容器 + 共享资源
|
||
```
|
||
|
||
**运维分层**:
|
||
```
|
||
核心业务:专人维护、监控告警
|
||
辅助功能:自动化管理、低优先级
|
||
```
|
||
|
||
### 5. 品牌区分 ⭐⭐
|
||
**独立品牌**:
|
||
```
|
||
主要产品:子域名(专业形象)
|
||
内部工具:路径(简单实用)
|
||
```
|
||
|
||
**示例**:
|
||
```
|
||
ABM 数据库:abm.example.com(面向外部用户)
|
||
API 文档: example.com/api-docs(面向开发者)
|
||
```
|
||
|
||
---
|
||
|
||
## ❌ 缺点分析
|
||
|
||
### 1. 配置复杂度增加
|
||
**问题**:
|
||
```yaml
|
||
# 需要管理两套规则
|
||
Host(xxx.example.com) # 子域名规则
|
||
PathPrefix(/xxx) + priority # 路径规则
|
||
```
|
||
|
||
**后果**:
|
||
- 配置文件更长
|
||
- 需要理解两种模式
|
||
- 容易混淆
|
||
|
||
### 2. 需要明确决策标准
|
||
**挑战**:
|
||
```
|
||
新功能 → 用子域名还是路径?
|
||
需要制定清晰的决策标准
|
||
避免决策混乱
|
||
```
|
||
|
||
**决策困难**:
|
||
- 边界模糊的功能难以判断
|
||
- 团队需要达成共识
|
||
- 需要文档化决策标准
|
||
|
||
### 3. 部分功能需要优先级管理
|
||
**问题**:
|
||
```yaml
|
||
# 路径部分仍需配置优先级
|
||
PathPrefix(/api) priority=100
|
||
PathPrefix(/downloads) priority=100
|
||
Path(/) priority=1
|
||
```
|
||
|
||
**维护成本**:
|
||
- 路径部分仍有复杂度
|
||
- 不能完全避免优先级问题
|
||
|
||
### 4. 文件结构不统一
|
||
**问题**:
|
||
```
|
||
子域名服务:文件在根目录
|
||
路径服务: 文件在子目录(需要对齐)
|
||
```
|
||
|
||
**后果**:
|
||
- 部署流程不统一
|
||
- 容易出错
|
||
- 需要额外文档说明
|
||
|
||
### 5. 学习曲线较高
|
||
**要求**:
|
||
- 理解子域名模式
|
||
- 理解路径模式
|
||
- 理解何时用哪种
|
||
- 更高的技术要求
|
||
|
||
---
|
||
|
||
## 🎯 适用场景
|
||
|
||
### ✅ 最适合的场景
|
||
|
||
#### 1. 资源有限的多业务场景 ⭐⭐
|
||
```
|
||
场景:有限的 DNS 记录配额
|
||
策略:
|
||
- 核心业务(3个)→ 子域名
|
||
- 辅助功能(5个)→ 路径
|
||
优势:兼顾性能和成本
|
||
```
|
||
|
||
#### 2. 业务分层明确 ⭐⭐
|
||
```
|
||
核心层:面向用户的产品(子域名)
|
||
- abm.example.com
|
||
- lab.example.com
|
||
|
||
辅助层:内部工具/API(路径)
|
||
- example.com/admin
|
||
- example.com/api
|
||
```
|
||
|
||
#### 3. 渐进式迁移 ⭐⭐⭐
|
||
```
|
||
现状:所有网站用路径
|
||
目标:迁移到子域名
|
||
策略:
|
||
阶段 1:核心业务先迁移
|
||
阶段 2:逐步迁移其他
|
||
阶段 3:保留部分路径功能
|
||
```
|
||
|
||
#### 4. 大型组织 ⭐
|
||
```
|
||
场景:多部门、多业务线
|
||
策略:
|
||
- 部门级业务:子域名
|
||
dept1.example.com
|
||
dept2.example.com
|
||
|
||
- 公共资源:路径
|
||
example.com/downloads
|
||
example.com/docs
|
||
```
|
||
|
||
#### 5. 实验性功能 ⭐
|
||
```
|
||
稳定功能:子域名(长期)
|
||
实验功能:路径(可能下线)
|
||
```
|
||
|
||
### ⚠️ 不太适合的场景
|
||
|
||
#### 1. 团队技术水平不统一
|
||
```
|
||
问题:混合策略需要更高的理解力
|
||
风险:配置出错概率增加
|
||
建议:选择单一策略
|
||
```
|
||
|
||
#### 2. 简单小型项目
|
||
```
|
||
场景:网站数量 ≤ 3 个
|
||
问题:混合策略过于复杂
|
||
建议:纯子域名或纯路径
|
||
```
|
||
|
||
#### 3. 需要极致性能
|
||
```
|
||
场景:所有业务都是高流量
|
||
问题:路径部分性能不如子域名
|
||
建议:全部使用子域名
|
||
```
|
||
|
||
#### 4. 追求配置简洁
|
||
```
|
||
问题:混合策略配置更复杂
|
||
建议:纯子域名策略
|
||
```
|
||
|
||
---
|
||
|
||
## 📊 性能指标
|
||
|
||
### 混合性能
|
||
```
|
||
子域名部分:
|
||
路由匹配:0.05-0.1ms ⭐⭐⭐⭐⭐
|
||
|
||
路径部分:
|
||
路由匹配:0.1-0.5ms ⭐⭐⭐
|
||
|
||
整体性能:⭐⭐⭐⭐
|
||
优于纯路径,略低于纯子域名
|
||
```
|
||
|
||
### 资源占用
|
||
```
|
||
DNS 记录:3-5 条(核心业务)
|
||
路由规则:子域名规则 + 路径规则
|
||
内存占用:介于两种策略之间
|
||
```
|
||
|
||
---
|
||
|
||
## 🛠️ 最佳实践
|
||
|
||
### 1. 决策标准文档化
|
||
|
||
**创建决策矩阵**:
|
||
```markdown
|
||
## 新功能部署决策标准
|
||
|
||
### 使用子域名的条件(满足任意 2 条):
|
||
- [ ] 面向外部用户的主要产品
|
||
- [ ] 预期日均 PV > 1000
|
||
- [ ] 需要独立品牌形象
|
||
- [ ] 长期运行(> 6 个月)
|
||
- [ ] 需要独立访问控制
|
||
- [ ] 需要独立监控和告警
|
||
|
||
### 使用路径的条件(满足任意 2 条):
|
||
- [ ] 内部工具或辅助功能
|
||
- [ ] 日均 PV < 500
|
||
- [ ] 临时性功能(< 3 个月)
|
||
- [ ] 不需要独立品牌
|
||
- [ ] 与主站功能紧密相关
|
||
```
|
||
|
||
### 2. 命名规范
|
||
```
|
||
子域名服务:
|
||
{功能}.amiap.hzau.edu.cn
|
||
例如:abm, lab, shop
|
||
|
||
路径服务:
|
||
amiap.hzau.edu.cn/{功能}
|
||
例如:/api, /downloads, /admin
|
||
```
|
||
|
||
### 3. 配置组织
|
||
```yaml
|
||
# docker-compose.yml
|
||
services:
|
||
# ========================================
|
||
# 子域名服务(主要业务)
|
||
# ========================================
|
||
nginx-abm:
|
||
# ...
|
||
|
||
nginx-lab:
|
||
# ...
|
||
|
||
# ========================================
|
||
# 路径服务(辅助功能)
|
||
# ========================================
|
||
nginx-main:
|
||
# 包含多个路径路由
|
||
# ...
|
||
```
|
||
|
||
### 4. 监控分层
|
||
```yaml
|
||
# 核心业务(子域名):高优先级监控
|
||
alerting:
|
||
- name: ABM Down
|
||
expr: probe_success{job="abm"} == 0
|
||
severity: critical
|
||
|
||
# 辅助功能(路径):低优先级监控
|
||
- name: API Slow
|
||
expr: http_request_duration > 1s
|
||
severity: warning
|
||
```
|
||
|
||
### 5. 文档维护
|
||
```markdown
|
||
# 服务清单
|
||
|
||
## 子域名服务
|
||
| 子域名 | 服务 | 负责人 | 重要性 |
|
||
|--------|------|--------|--------|
|
||
| abm | ABM数据库 | 张三 | 高 |
|
||
| lab | 实验室主页 | 李四 | 高 |
|
||
|
||
## 路径服务
|
||
| 路径 | 服务 | 负责人 | 重要性 |
|
||
|------|------|--------|--------|
|
||
| /api | API接口 | 王五 | 中 |
|
||
| /downloads | 下载中心 | 赵六 | 低 |
|
||
```
|
||
|
||
---
|
||
|
||
## 💰 成本分析
|
||
|
||
### 时间成本
|
||
```
|
||
初期规划:1-2 小时(制定决策标准)
|
||
首次配置:2-3 小时(两套系统)
|
||
添加新功能:
|
||
- 子域名:10 分钟
|
||
- 路径: 15 分钟
|
||
维护成本:中等(需要管理两套规则)
|
||
```
|
||
|
||
### 资源成本
|
||
```
|
||
DNS 记录:3-5 条(节省成本)
|
||
证书:通配符或多个单独证书
|
||
服务器:共享,无额外需求
|
||
```
|
||
|
||
### 学习成本
|
||
```
|
||
技术要求:较高
|
||
需要理解:两种模式 + 决策标准
|
||
培训时间:2-3 小时
|
||
```
|
||
|
||
---
|
||
|
||
## 📝 决策建议
|
||
|
||
### ✅ 选择此策略的理由
|
||
|
||
1. **业务分层清晰(核心+辅助)**
|
||
2. **逐步从路径迁移到子域名**
|
||
3. **DNS 记录有限制或成本考虑**
|
||
4. **有明确的决策标准和流程**
|
||
5. **团队有较高的技术水平**
|
||
6. **需要平衡性能和灵活性**
|
||
|
||
### ❌ 不选择此策略的理由
|
||
|
||
1. **业务简单(≤3个网站)** → 选择策略 2(纯子域名)
|
||
2. **追求最佳性能** → 选择策略 2
|
||
3. **追求最简配置** → 选择策略 2
|
||
4. **无 DNS 权限** → 选择策略 1(纯路径)
|
||
5. **团队技术水平不统一** → 选择单一策略
|
||
|
||
---
|
||
|
||
## 🔄 实施建议
|
||
|
||
### 阶段 1:评估现有业务
|
||
```bash
|
||
# 列出所有网站/服务
|
||
1. ABM 数据库 → 重要性:高,流量:大
|
||
2. 实验室主页 → 重要性:高,流量:中
|
||
3. API 接口 → 重要性:中,流量:小
|
||
4. 下载中心 → 重要性:低,流量:小
|
||
5. 主站 → 重要性:中,流量:中
|
||
```
|
||
|
||
### 阶段 2:制定迁移计划
|
||
```
|
||
第 1 批:核心业务迁移到子域名
|
||
- ABM 数据库 → abm.amiap.hzau.edu.cn
|
||
- 实验室主页 → lab.amiap.hzau.edu.cn
|
||
|
||
第 2 批:辅助功能保持路径
|
||
- API 接口 → /api
|
||
- 下载中心 → /downloads
|
||
|
||
第 3 批:主站评估
|
||
- 如果流量大 → www.amiap.hzau.edu.cn
|
||
- 如果流量小 → amiap.hzau.edu.cn (根路径)
|
||
```
|
||
|
||
### 阶段 3:实施和监控
|
||
```
|
||
1. 配置 DNS(核心业务)
|
||
2. 部署子域名服务
|
||
3. 保持路径服务
|
||
4. 监控性能和错误
|
||
5. 用户反馈收集
|
||
```
|
||
|
||
---
|
||
|
||
## 📚 相关文档
|
||
|
||
- [完整多站点策略指南](MULTI_SITE_STRATEGY_GUIDE.md)
|
||
- [策略 1:路径前缀方案](strategy-1-path-prefix.md)
|
||
- [策略 2:子域名方案](strategy-2-subdomain.md)
|
||
- [总结对比报告](strategy-comparison-report.md)
|
||
- [快速参考手册](QUICK_REFERENCE.md)
|
||
|
||
---
|
||
|
||
**结论**:混合策略是一个**平衡方案**,适合业务分层明确、需要灵活性的场景。它在性能、成本和复杂度之间取得平衡,但需要团队有较高的技术水平和明确的决策标准。⭐⭐⭐⭐
|