chore: 添加 .gitignore 和 Traefik 部署策略文档
.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 反向代理的三种部署策略， 为多应用部署提供参考方案。
This commit is contained in:
zly
519
docs/strategy-3-hybrid.md
Normal file
519
docs/strategy-3-hybrid.md
Normal file
@@ -0,0 +1,519 @@
|
||||
# 策略 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)
|
||||
|
||||
---
|
||||
|
||||
**结论**：混合策略是一个**平衡方案**，适合业务分层明确、需要灵活性的场景。它在性能、成本和复杂度之间取得平衡，但需要团队有较高的技术水平和明确的决策标准。⭐⭐⭐⭐
|
||||
Reference in New Issue
Block a user