Qiniu/xinfra/issues/001-unified-infra-platform.md

---
tags: [xinfra, issue, proposal]
create time: 2026-07-08 14:03
status: proposal
spec: FullSpec
---

# ISSUE-001：统一基础设施平台（XINFRA）

---

## 状态

`proposal`

## 规格

FullSpec

---

## 设计点

**在七机房、多集群的复杂基础设施拓扑下，如何为开发者、DBA、SRE 提供一个统一的、平台化的基础设施操作入口，消除"多工具跳转 + 命令行直操"带来的效率损耗和安全风险？**

---

## 动机 / 用户故事

周三下午 3 点，后端开发小张发现线上服务响应变慢，排查后怀疑是 Redis 大 Key 导致。他想做三件事：

1. **看一下 Redis 实例的慢查询**——他需要登录 CacheCloud 平台，找到对应实例，翻到诊断页面
2. **扩容一个从节点分担读压力**——他发现自己没有 CacheCloud 的运维权限，只能提工单找 SRE
3. **顺手把昨天写好的 SQL 变更推到生产库**——他需要打开 CloudDM，手动粘贴 SQL，等 DBA 审核

三个操作，三个平台，三套账号体系。小张在浏览器里开了五个 Tab，来回切换了半小时才把工单都提交出去。他跟旁边的同事吐槽：

> "我就是想改个配置、扩个 Redis、上线个 SQL，怎么比写代码还累？"

与此同时，SRE 老李正在处理一个更头疼的事——某个服务要从机房 A 迁移到机房 B，他需要手动在 Wayne 里创建新集群的 Deployment，核对 YAML 模板版本，再用 kubectl 验证 Pod 状态。整个流程没有任何自动化，全凭经验。

**这些场景的共同痛点是**：基础设施操作被分散在 Wayne、CloudDM、CacheCloud、Ansible、kubectl 等多个工具中，开发者需要记忆不同平台的操作路径，而关键操作（如生产发布、数据库变更）缺乏统一的审批和审计链路。

---

## 典型场景

### 场景一：日常发布

> 小张提交了一段 Go 代码到 GitLab。他希望代码合并后自动构建镜像、推送到 Harbor、然后部署到 dev 环境。部署到 prod 时需要主管审批。
>
> **当前做法**：手动在 GitLab 触发 CI → 等镜像构建完成 → 打开 Wayne → 找到项目 → 手动填写镜像 tag → 点击发布。如果要部署到 prod，还要在企业微信群里 @主管说"帮我批一下"。
>
> **期望做法**：代码合并后 CI 自动触发，dev 环境自动部署；prod 环境通过 Wayne 工单流审批，审批通过后自动执行。

### 场景二：数据库变更

> 小张需要给用户表加一个索引。他写好了 `ALTER TABLE` 语句。
>
> **当前做法**：打开 CloudDM → 选择数据源 → 粘贴 SQL → 提交审核 → 等 DBA 审核 → 手动选择执行时间窗口。如果审核规则报错，他还要回来改 SQL 再重新提交。
>
> **期望做法**：在 CloudDM 中直接编写 SQL，实时预检规则反馈，一次提交通过后自动进入 DBA 审核队列，审核通过后在指定时间窗口自动执行，结果回填工单。全程无需离开 CloudDM。

---

## 目标用户

### 第一目标用户

| 维度 | 描述 |
|------|------|
| **角色** | 后端开发工程师 |
| **行业** | 云计算 / 互联网基础设施 |
| **使用目的** | 日常服务发布、数据库变更、缓存资源申请 |
| **技术水平** | 熟悉 K8s 基本概念，但不愿直接操作 kubectl |
| **核心诉求** | "我只想写代码和发布，不想学五套平台的操作方式" |

### 优先验证场景

- 七机房 RKE2 集群中的**服务发布全流程**（CI → 镜像 → Wayne 部署）
- CloudDM 的 **SQL 审核工单流**（编写 → 预检 → 审核 → 执行）

### 本期不面向

- 多云成本管控的精细化运营（FR-9 为 P1/P2，本期仅做数据采集基础）
- WAF 安全策略的深度定制（FR-7 为基础防护，不做高级规则引擎）
- 非容器化部署的虚拟机管理场景

---

## 现有做法及其不足

| 做法 | 工具 | 不足 |
|------|------|------|
| 直接 kubectl 操作 | kubectl + kubeconfig | 无审计、无权限隔离、易误操作、yaml 散落在本地 |
| 单集群管理面板 | Rancher Dashboard | 仅管理单集群，不支持跨机房统一视图 |
| 数据库直连执行 | Navicat / DBeaver | 无审核流程、无权限分级、生产库误操作风险极高 |
| 手动部署 Redis | SSH + 手动编译 | 无标准化、无监控、无自动故障转移 |
| 脚本化部署 | Shell 脚本 | 不幂等、无版本管理、交接成本高 |

**本项目的核心差异**：

1. **统一入口**：开发者不需要在 5 个平台间跳转，核心操作（发布、SQL、缓存）在同一生态内闭环
2. **审计留痕**：所有关键操作（容器发布、数据库变更、权限申请）全程可追溯，满足合规要求
3. **平台化自治**：自助申请资源、自助发布、自助诊断，减少人工工单流转和等待时间

---

## 本期范围（P0）

**P0 范围：**

| # | 交付项 | 说明 |
|---|--------|------|
| 1 | RKE2 集群标准化部署 | 七机房各一套 RKE2 集群，Canal CNI，containerd 运行时，支持 Air-gap 离线部署 |
| 2 | Wayne 多集群管理接入 | 各机房集群注册到 Wayne，RBAC 权限体系（Project → Environment → Namespace），审计日志 |
| 3 | CI/CD → Wayne 全链路打通 | GitLab CI 编译 → Harbor 推送镜像 → APIKey 调用 Wayne API 触发部署，prod 环境审批卡点 |
| 4 | CloudDM SQL 审核流水线 | Console + Sidecar 部署，54 条审核规则，SQL 工单流（编写 → 预检 → DBA 审核 → 执行），全程留痕 |
| 5 | CacheCloud 基础实例管理 | 支持 Sentinel / Cluster 两种架构的实例申请、部署、监控，Agent 心跳管理 |
| 6 | Ansible 基础 Playbook | MySQL Server 和 Redis Cluster 的标准化部署 Playbook，支持多环境 Inventory |

---

## 本期明确不做

| # | 不做的事项 | 原因 |
|---|-----------|------|
| 1 | 多云成本看板的可视化和分析 | 成本数据采集可先行，可视化为 P1 |
| 2 | WAF 高级规则引擎和自定义策略 | 基础防护即可，深度安全策略为独立安全项目 |
| 3 | 跨机房双活流量调度 | 本期仅实现网络互联和 Pod 跨机房可达，双活调度需额外方案设计 |
| 4 | CacheCloud 跨机房双写双读 | 本期支持单机房实例管理，Cross-Room 为 P1 |
| 5 | 数据库 CI/CD（Git Push 触发） | 本期走 Web UI 工单流，自动化触发为 P1 |
| 6 | Wayne Web Shell 远程终端 | 权限模型较复杂，为 P1 |
| 7 | 非 K8s 容器运行时支持（Docker） | RKE2 默认 containerd，不额外适配 Docker |

---

## 关键决策与依据

### 决策 1：容器编排方案——RKE2 vs 原生 K8s（kubeadm）vs K3s

| 备选方案 | 优势 | 劣势 |
|---------|------|------|
| **原生 K8s（kubeadm）** | 社区主流，文档丰富 | 部署复杂，安全加固需额外工作 |
| **K3s** | 极轻量，边缘场景友好 | 生产级特性不足，etcd 稳定性存疑 |
| **RKE2** ✅ | 单二进制部署，FIPS 140-2 合规，安全优先 | 生态略小于原生 K8s |

**选择结果**：RKE2

**理由**：
- 七机房环境对安全合规有硬性要求，RKE2 的 FIPS 140-2 合规是决策性优势
- 单二进制 + Systemd 部署大幅降低七机房集群的运维复杂度
- Rancher 生态成熟，节点注册、证书管理等开箱即用
- Air-gap 离线部署能力匹配内网无外网的机房环境

---

### 决策 2：多集群管理方案——Wayne vs Rancher Dashboard vs 自研

| 备选方案 | 优势 | 劣势 |
|---------|------|------|
| **Rancher Dashboard** | 与 RKE2 同生态，官方维护 | 偏运维视角，开发者发布体验弱；RBAC 模型较粗 |
| **自研管理平台** | 完全可控，可定制 | 开发成本高，3-6 个月才能基本可用 |
| **Wayne** ✅ | 开源成熟，发布流程完善，API 开放 | 360 维护活跃度不确定，需内部 Fork |

**选择结果**：Wayne（内部 Fork）

**理由**：
- Wayne 的 Project → Environment → Namespace 三级结构天然匹配多机房、多环境的管理需求
- 内置审计模块和 APIKey 开放接口，CI/CD 对接开箱可用
- Beego（Go）后端与团队技术栈一致，二次开发成本可控
- 内部 Fork 降低上游停更风险，核心模块可自行维护

---

### 决策 3：数据库管控方案——CloudDM vs Yearning vs 自研审核网关

| 备选方案 | 优势 | 劣势 |
|---------|------|------|
| **Yearning** | 轻量，社区活跃 | 功能偏 SQL 审核，缺少数据查询和脱敏能力 |
| **自研审核网关** | 完全可控 | 需自建权限、工单、审核规则引擎，工作量大 |
| **CloudDM** ✅ | 功能全面（查询+审核+脱敏+CI/CD），支持 20+ 数据源 | 较重，需评估资源开销 |

**选择结果**：CloudDM

**理由**：
- 不仅仅是 SQL 审核，数据查询、权限管控、数据脱敏一体化，避免后期再引入多个工具
- 54 条内置审核规则 + 自定义扩展，满足当前和可预见的审核需求
- Console + Sidecar 架构支持跨机房数据库统一管理，匹配七机房拓扑
- 统一认证（LDAP/OIDC）可与公司现有账号体系对接

---

## 基本概念与信息结构

### 核心实体

| 实体 | 定义 | 关键属性 |
|------|------|---------|
| **Cluster** | 一个机房的 RKE2 集群实例 | clusterId, datacenter, cidr, status |
| **Project** | Wayne 中的项目分组，对应一个业务团队 | projectId, name, department, owner |
| **Environment** | 部署环境，隔离不同阶段 | envId, type(dev/staging/prod), clusterId |
| **Deployment** | 一次服务部署记录 | deployId, projectId, envId, imageTag, status, rollbackTarget |
| **SQLTicket** | CloudDM 的 SQL 审核工单 | ticketId, datasourceId, sqlContent, auditStatus, executor, scheduledAt |
| **RedisInstance** | CacheCloud 管理的 Redis 实例 | instanceId, appId, arch(sentinel/cluster), memoryMB, nodes[], status |
| **PlaybookRun** | Ansible Playbook 的一次执行记录 | runId, playbookName, inventory, status, diffOutput |

### 数据示例

```json
{
  "deployment": {
    "deployId": "dep-20260708-001",
    "projectId": "proj-qiniu-cdn",
    "environment": "prod",
    "cluster": {
      "clusterId": "rke2-bjdc-01",
      "datacenter": "北京机房 A"
    },
    "image": {
      "registry": "harbor.internal.qiniu.com",
      "repository": "cdn/edge-proxy",
      "tag": "v2.3.1-abc1234"
    },
    "replicas": 3,
    "strategy": "RollingUpdate",
    "status": "deploying",
    "triggeredBy": "gitlab-ci",
    "auditLog": [
      {
        "action": "create",
        "operator": "ci-bot",
        "timestamp": "2026-07-08T14:00:00+08:00"
      },
      {
        "action": "approve",
        "operator": "zhangwei@qiniu.com",
        "timestamp": "2026-07-08T14:02:30+08:00",
        "comment": "LGTM, 已在 staging 验证通过"
      }
    ]
  }
}
```

```json
{
  "sqlTicket": {
    "ticketId": "sql-20260708-042",
    "datasource": {
      "id": "ds-user-center-prod",
      "type": "MySQL",
      "host": "10.1.2.3",
      "database": "user_center"
    },
    "sqlContent": "ALTER TABLE users ADD INDEX idx_phone (phone) USING BTREE;",
    "type": "DDL",
    "auditResult": {
      "passed": true,
      "rulesChecked": 54,
      "warnings": [
        {
          "rule": "DDL-MUST-HAVE-WHERE",
          "level": "info",
          "message": "ALTER TABLE 语句，建议在低峰期执行"
        }
      ]
    },
    "status": "approved",
    "executor": "dba-liwei@qiniu.com",
    "scheduledAt": "2026-07-09T03:00:00+08:00",
    "executionResult": null
  }
}
```

```json
{
  "redisInstance": {
    "instanceId": "redis-order-cache-01",
    "appId": "app-order-service",
    "architecture": "sentinel",
    "memoryMB": 4096,
    "nodes": [
      { "role": "master", "host": "10.2.1.10", "port": 6379 },
      { "role": "slave", "host": "10.2.1.11", "port": 6379 },
      { "role": "sentinel", "host": "10.2.1.12", "port": 26379 }
    ],
    "status": "running",
    "alerts": {
      "bigkeys": 2,
      "slowlogLastMinute": 0
    }
  }
}
```

---

## 关联笔记

- [[requirements|XINFRA 平台需求文档]]
- [[technical/xinfra-preview|XINFRA 预习总览]]