labweb/docs/strategy-3-hybrid.md

策略 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/          # 主站

---

🏗️ 技术架构

路由配置

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. 配置复杂度增加

问题：

# 需要管理两套规则
Host(xxx.example.com)           # 子域名规则
PathPrefix(/xxx) + priority     # 路径规则

后果：

• 配置文件更长
• 需要理解两种模式
• 容易混淆

2. 需要明确决策标准

挑战：

新功能 → 用子域名还是路径？
需要制定清晰的决策标准
避免决策混乱

决策困难：

• 边界模糊的功能难以判断
• 团队需要达成共识
• 需要文档化决策标准

3. 部分功能需要优先级管理

问题：

# 路径部分仍需配置优先级
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. 决策标准文档化

创建决策矩阵：

## 新功能部署决策标准

### 使用子域名的条件（满足任意 2 条）：
- [ ] 面向外部用户的主要产品
- [ ] 预期日均 PV > 1000
- [ ] 需要独立品牌形象
- [ ] 长期运行（> 6 个月）
- [ ] 需要独立访问控制
- [ ] 需要独立监控和告警

### 使用路径的条件（满足任意 2 条）：
- [ ] 内部工具或辅助功能
- [ ] 日均 PV < 500
- [ ] 临时性功能（< 3 个月）
- [ ] 不需要独立品牌
- [ ] 与主站功能紧密相关

2. 命名规范

子域名服务：
  {功能}.amiap.hzau.edu.cn
  例如：abm, lab, shop

路径服务：
  amiap.hzau.edu.cn/{功能}
  例如：/api, /downloads, /admin

3. 配置组织

# docker-compose.yml
services:
  # ========================================
  # 子域名服务（主要业务）
  # ========================================
  nginx-abm:
    # ...
    
  nginx-lab:
    # ...
    
  # ========================================
  # 路径服务（辅助功能）
  # ========================================
  nginx-main:
    # 包含多个路径路由
    # ...

4. 监控分层

# 核心业务（子域名）：高优先级监控
alerting:
  - name: ABM Down
    expr: probe_success{job="abm"} == 0
    severity: critical
    
# 辅助功能（路径）：低优先级监控
  - name: API Slow
    expr: http_request_duration > 1s
    severity: warning

5. 文档维护

# 服务清单

## 子域名服务
| 子域名 | 服务 | 负责人 | 重要性 |
|--------|------|--------|--------|
| 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：评估现有业务

# 列出所有网站/服务
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. 用户反馈收集

---

📚 相关文档

• 完整多站点策略指南
• 策略 1：路径前缀方案
• 策略 2：子域名方案
• 总结对比报告
• 快速参考手册

---

结论：混合策略是一个平衡方案，适合业务分层明确、需要灵活性的场景。它在性能、成本和复杂度之间取得平衡，但需要团队有较高的技术水平和明确的决策标准。⭐⭐⭐⭐