Files
labweb/docs/strategy-3-hybrid.md
zly 9a261bb265 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 反向代理的三种部署策略,
为多应用部署提供参考方案。
2025-11-22 21:30:19 +08:00

520 lines
11 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 策略 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)
---
**结论**:混合策略是一个**平衡方案**,适合业务分层明确、需要灵活性的场景。它在性能、成本和复杂度之间取得平衡,但需要团队有较高的技术水平和明确的决策标准。⭐⭐⭐⭐