# 三台服务器 Runner 分工规划

**制定日期：** 2026-07-13
**状态：** 规划中

---

## 一、现状总览

当前共 9 个 Gitea Actions Runner，分布在 3 台服务器上：

| 服务器 | IP | 配置 | Runner 数量 | 当前状态 |
|--------|-----|------|-------------|----------|
| 构建服务器 | 114.55.236.178 | 4核 / 7.1G RAM / 49G NVMe | 4个（ID: 8, 42, 46, 47） | ✅ 在线 |
| 新CI服务器 | 116.62.226.203 | 8核 / 14G RAM | 5个（ID: 58-62） | ✅ 在线 |
| 业务服务器 | 47.98.113.167 | - | 0个（旧3个已下线） | ⚠️ 待规划 |

**所有 Runner 共用标签：** `saas`, `runtime-builder`, `host`, `ubuntu-latest`

---

## 二、问题分析

### 2.1 标签无区分
所有 Runner 标签完全一致，CI 任务随机分配到任意 Runner，导致：
- 构建任务（Build）可能跑到配置低的机器上，构建慢
- 代码检查任务占着构建服务器，影响构建速度
- 业务服务器跑 CI 影响线上服务稳定性

### 2.2 资源浪费
- 新服务器 8核14G 跑 validate/lint 有点大材小用
- 构建服务器 4核7G 跑 Docker 构建偏紧张

---

## 三、规划方案

### 3.1 分工原则

| 服务器 | 角色 | 主要任务类型 | 标签策略 |
|--------|------|-------------|----------|
| **构建服务器** (114.55.236.178) | 构建专机 | Build Staging / Build Production / Docker 镜像构建 | 保留 `saas` + `host`，新增 `build-only` |
| **新CI服务器** (116.62.226.203) | 代码检查专机 | Validate / Unit Tests / Integration Tests / Frontend Lint | 保留 `saas` + `host`，新增 `ci-check` |
| **业务服务器** (47.98.113.167) | 部署专机 | Deploy Staging / Deploy Production / E2E Tests | 保留 `saas` + `host`，新增 `deploy-only` |

### 3.2 具体配置

#### 构建服务器（4个 Runner）
- **数量：** 3个（从4个缩减，释放资源给构建缓存）
- **标签：** `saas`, `host`, `build-only`, `ubuntu-latest`
- **负责 Job：**
  - `build-staging`
  - `build-production-runtime-images`
  - 其他需要 Docker buildx 的任务

#### 新CI服务器（5个 Runner）
- **数量：** 5个（保持不变）
- **标签：** `saas`, `host`, `ci-check`, `ubuntu-latest`
- **负责 Job：**
  - `validate`
  - `unit-tests`
  - `integration-tests`
  - `frontend-lint`
  - 安全扫描（gitleaks / pip-audit / vulture 等）

#### 业务服务器（1-2个 Runner）
- **数量：** 1-2个（逐步替换旧的3个）
- **标签：** `saas`, `host`, `deploy-only`, `ubuntu-latest`
- **负责 Job：**
  - `deploy-staging`
  - `deploy-production`
  - `staging-e2e` / `production-e2e`
  - `staging-api-tests`

---

## 四、实施步骤

### Phase 1: 标签打标（低风险，立即做）
1. 新服务器 5 个 Runner 添加 `ci-check` 标签
2. 构建服务器保留 3 个 Runner，添加 `build-only` 标签
3. 业务服务器部署 1 个新 Runner，标签 `deploy-only`

### Phase 2: Job 路由调整（中风险，逐步来）
1. validate / unit-tests / integration-tests / frontend-lint 改为 `runs-on: ci-check`
2. build-staging / build-production 改为 `runs-on: build-only`
3. deploy-* / e2e 改为 `runs-on: deploy-only`

### Phase 3: 旧 Runner 下线
- 业务服务器旧的 3 个 Runner 确认无任务后下线
- 构建服务器多余的 1 个 Runner 迁移到新服务器

---

## 五、并发配置优化建议

### 5.1 当前并发情况
- 首发并行 Job：validate + unit-tests + frontend-lint（3个并行）
- integration-tests 依赖 validate（串行，浪费资源）
- 无 concurrency 限制，同一分支多次 push 会重复跑

### 5.2 优化建议

**1. integration-tests 改为与 unit-tests 并行**
```yaml
# 当前
integration-tests:
  needs: validate  # 没必要等validate

# 优化后
integration-tests:
  needs: []  # 直接和unit-tests并行跑
```

**2. 增加分支级 concurrency，取消重复构建**
```yaml
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
```
同一 PR 多次 push 时，取消旧的构建，只跑最新的。

**3. Build Staging 移出 PR 门禁**
- 已在阶段二优化中完成（PR #245）
- Build Staging 只在 develop/main 上异步构建

---

## 六、预期收益

| 指标 | 当前 | 优化后 | 提升 |
|------|------|--------|------|
| PR CI 总时长 | ~8-12分钟 | ~4-6分钟 | ⏱️ 缩短 40-50% |
| 构建速度 | 可能抢到慢机器 | 固定高配构建机 | 🚀 更稳定更快 |
| 线上稳定性 | CI和业务抢资源 | 部署独立Runner | 🛡️ 隔离保障 |
| Runner 利用率 | 随机分配 | 按任务类型调度 | 📈 更合理 |