920 lines
22 KiB
Markdown
920 lines
22 KiB
Markdown
---
|
||
theme: frankfurt
|
||
title: XINFRA 平台需求与架构
|
||
author: 实训小组
|
||
infoLine: true
|
||
transition: slide-left
|
||
mdc: true
|
||
drawings:
|
||
persist: false
|
||
---
|
||
|
||
# XINFRA 平台需求与架构
|
||
|
||
<div class="text-xl mt-4 text-gray-400">
|
||
统一基础设施管理平台 · 总体架构设计
|
||
</div>
|
||
|
||
<div class="mt-8 text-lg text-gray-500">
|
||
实训小组
|
||
</div>
|
||
|
||
<!--
|
||
封面：XINFRA 平台架构总览
|
||
-->
|
||
|
||
---
|
||
layout: default
|
||
---
|
||
|
||
# 小组介绍
|
||
|
||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||
<div>
|
||
|
||
### 团队成员
|
||
|
||
| 角色 | 姓名 |
|
||
|------|------|
|
||
| 导师 | 秦秀科（Adam） |
|
||
| 助教 | 张少坡 |
|
||
| 组长 | 汪大炜 |
|
||
| 组员 | 郭永昊 |
|
||
| 组员 | 何朝晖 |
|
||
| 组员 | 刘家辉 |
|
||
| 组员 | 张少坡 |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 项目背景
|
||
|
||
**XINFRA 统一基础设施管理平台**
|
||
|
||
本项目旨在解决各业务线长期独立建设导致的资源分散、交付效率低、权限过大、监控割裂等问题，通过统一入口整合资源、服务、任务、审计和监控能力。
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
layout: default
|
||
---
|
||
|
||
# 目录
|
||
|
||
<div class="grid grid-cols-3 gap-8 mt-8">
|
||
<div>
|
||
|
||
### 一、系统需求
|
||
|
||
- 一句话概括需求
|
||
- 系统边界 — 做什么 vs 不做什么
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 二、用户故事
|
||
|
||
- 资源查看
|
||
- 业务交付
|
||
- 基础服务交付
|
||
- 数据库审核
|
||
- 业务线切换
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 三、关键决策
|
||
|
||
- 入口聚合而非替代
|
||
- 业务线作为核心隔离维度
|
||
- 基础服务交付自动化
|
||
- 引入统一监控引擎整合分散数据
|
||
- 按需资源纳管
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 四、架构设计
|
||
|
||
- 总体分层架构
|
||
- 主系统功能架构
|
||
- 自动化执行架构
|
||
- 监控与数据流
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 五、对接子系统
|
||
|
||
- Wayne
|
||
- CloudDM
|
||
- CacheCloud
|
||
- Apollo
|
||
- qpass
|
||
- Grafana
|
||
- Superset
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
section: 系统需求
|
||
layout: center
|
||
---
|
||
|
||
# 一、系统需求
|
||
|
||
<div class="text-gray-400 mt-2">系统边界 · 做什么 vs 不做什么</div>
|
||
|
||
---
|
||
|
||
# 一句话概括需求
|
||
|
||
<div class="mt-28 text-lg leading-relaxed text-center px-12">
|
||
|
||
**背景：** 各业务线长期独立建设，资源分散、交付效率低、权限过大、监控割裂、基础服务交付不标准。
|
||
|
||
**需求：** XINFRA 以**机房容器资源**为核心，把资源、服务、任务、审计和监控统一纳管，配套容器发布、SQL 审核、Redis 管理、配置中心、指标可视化、日志分析等子系统，完成多种运维场景下的需求。
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 系统边界 — 做什么 vs 不做什么
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4 text-sm">
|
||
<div>
|
||
|
||
### ✅ 做什么
|
||
|
||
| 范围 | 说明 |
|
||
|------|------|
|
||
| 统一入口 | 一个入口登录，集中展示各子系统和平台能力 |
|
||
| 资源台账 | 统一查看物理机、虚机、云主机、K8s 资源 |
|
||
| 容器纳管 | 管理 K8s 集群、Namespace、配额和业务线归属 |
|
||
| 业务交付 | 跳转 Wayne、CloudDM、Apollo、Superset 等系统 |
|
||
| 基础服务交付 | 标准化模板 + Ansible 编排 |
|
||
| 数据库审核 | SQL 工单、审批、审计 |
|
||
| 监控纳管 | 对接夜莺，按业务线展示告警 |
|
||
| 权限管理 | 业务线维度授权、子系统角色管理 |
|
||
| 审计 | 记录登录、跳转、审批和自动化执行 |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### ❌ 不做什么
|
||
|
||
| 范围 | 不做原因 |
|
||
|------|---------|
|
||
| 替代 Wayne、Apollo、CloudDM、CacheCloud、Grafana、Superset 等 | 专业系统继续保留 |
|
||
| 全量自研监控和告警引擎 | 成本高，非当前重点 |
|
||
| 复杂 AI 排障 | 由其他项目负责 |
|
||
| 虚机创建主流程 | 统一走线下流程 |
|
||
| 大而全的运维平台 | 两个月内不现实，也不必要 |
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
section: 用户故事
|
||
layout: center
|
||
---
|
||
|
||
# 二、用户故事
|
||
|
||
<div class="text-gray-400 mt-2">资源查看 · 业务交付 · 基础服务交付 · 数据库审核 · 业务线切换</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 资源查看
|
||
|
||
<div class="mt-8 space-y-6 text-lg">
|
||
|
||
**场景**：运维人员登录 XINFRA 后，直接看到全量资源分布、业务线归属、节点状态和容量概览，不需要在多个 CMDB 和云平台之间来回切换。
|
||
|
||
**链路**：业务 SRE 登录 XINFRA → 选择业务线 → 平台同步 CMDB / 云平台 / RKE2 数据 → 展示全量资源大盘
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 资源查看 · 交互图
|
||
|
||
<div class="mt-4" style="transform: scale(1.0); transform-origin: top left; height: 50vh;">
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
actor SRE as 业务 SRE
|
||
participant XINFRA as XINFRA 主系统
|
||
participant CMDB as SINA CMDB
|
||
participant Cloud as 云平台 API
|
||
participant K8s as RKE2 集群
|
||
|
||
SRE->>XINFRA: 登录，选择业务线
|
||
XINFRA->>CMDB: 同步物理机/虚机数据
|
||
XINFRA->>Cloud: 同步云主机数据
|
||
XINFRA->>K8s: 查询集群节点状态
|
||
XINFRA-->>SRE: 展示全量资源分布<br/>业务线归属 · 节点状态 · 容量概览
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 业务交付
|
||
|
||
<div class="mt-8 space-y-6 text-lg">
|
||
|
||
**场景**：业务 SRE 在 XINFRA 中进入"业务交付"，选择对应业务线后跳转到 Wayne、CloudDM、Apollo 或 Superset 完成实际操作，平台保留入口、上下文和审计。
|
||
|
||
**链路**：业务 SRE 登录 → 进入业务交付 → 选择业务线 → 展示子系统入口 → SSO 跳转至目标系统 → 记录审计日志
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 业务交付 · 交互图
|
||
|
||
<div class="mt-4" style="transform: scale(0.7); transform-origin: top left; height: 80vh;">
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
actor SRE as 业务 SRE
|
||
participant XINFRA as XINFRA
|
||
participant Sub as 子系统<br/>Wayne/CloudDM/Apollo/Superset
|
||
|
||
SRE->>XINFRA: 进入业务交付，选择业务线
|
||
XINFRA-->>SRE: 展示子系统入口卡片
|
||
SRE->>XINFRA: 点击目标子系统卡片
|
||
XINFRA->>Sub: SSO 跳转 + 上下文传递
|
||
Sub-->>SRE: 免登录进入子系统
|
||
XINFRA->>XINFRA: 记录跳转审计日志
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 基础服务交付
|
||
|
||
<div class="mt-8 space-y-6 text-lg">
|
||
|
||
**场景**：运维人员在 XINFRA 中提交 MySQL、Redis 等基础服务交付任务，平台调用 Ansible 控制中心执行标准化部署，并在任务中心查看日志和结果。
|
||
|
||
**链路**：运维人员登录 → 选择服务卡片 → 填写业务线和规格 → 提交任务 → Ansible 执行部署 → 自动注册至子系统 → 部署完成通知
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 基础服务交付 · 交互图
|
||
|
||
<div class="mt-4" style="transform: scale(0.9); transform-origin: top left;">
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
actor Ops as 运维人员
|
||
participant XINFRA as XINFRA 服务目录
|
||
participant Ansible as Ansible 控制中心
|
||
participant Target as 目标主机/RKE2
|
||
participant Reg as 子系统注册
|
||
|
||
Ops->>XINFRA: 选择 MySQL/Redis/Nginx 服务卡片
|
||
XINFRA-->>Ops: 展示标准化模板，填写业务线、规格
|
||
Ops->>XINFRA: 确认提交
|
||
XINFRA->>Ansible: 提交 playbook 任务
|
||
Ansible->>Target: 执行标准化部署
|
||
Ansible-->>XINFRA: WebSocket 实时日志推送
|
||
XINFRA-->>Ops: 任务中心查看执行进度
|
||
Target-->>Reg: 部署完成，自动注册至 CloudDM / CacheCloud
|
||
XINFRA-->>Ops: 部署完成通知
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 数据库审核
|
||
|
||
<div class="mt-8 space-y-6 text-lg">
|
||
|
||
**场景**：开发或运维提交 SQL 工单后，审核人可以在 XINFRA 中完成审批、查看执行记录和审计信息，减少线下沟通和手工操作。
|
||
|
||
**链路**：开发/运维提交 SQL 工单 → 转发至 CloudDM → 审核人审批 → 执行变更 → Sidecar 代理执行 SQL → 审计记录 → 通知完成
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 数据库审核 · 交互图
|
||
|
||
<div class="mt-4" style="transform: scale(0.9); transform-origin: top left;">
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
actor Dev as 开发/运维
|
||
participant XINFRA as XINFRA
|
||
participant CloudDM as CloudDM
|
||
participant DB as 目标数据库
|
||
|
||
Dev->>XINFRA: 提交 SQL 工单
|
||
XINFRA->>CloudDM: 转发至 CloudDM 审核
|
||
actor Reviewer as 审核人
|
||
Reviewer->>CloudDM: 审批通过
|
||
CloudDM->>DB: 执行 SQL
|
||
CloudDM-->>XINFRA: 返回执行结果
|
||
XINFRA-->>Dev: 通知完成
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 用户故事 — 业务线切换
|
||
|
||
<div class="mt-8 space-y-6 text-lg">
|
||
|
||
**场景**：XINFRA 以业务线作为核心隔离维度，不同角色登录后默认看到自己负责的业务线数据，支持一键切换。系统运维可查看全局，业务 SRE 聚焦本业务线，只读用户仅能查看授权范围。
|
||
|
||
**角色**：系统运维（全局视角）、业务 SRE（本业务线）、跨业务线运维（按需切换）、只读用户（受限查看）
|
||
|
||
</div>
|
||
|
||
|
||
---
|
||
section: 关键决策
|
||
layout: center
|
||
---
|
||
|
||
# 三、关键决策
|
||
|
||
<div class="text-gray-400 mt-2">入口聚合 · 业务线隔离 · Ansible 编排 · 对接夜莺</div>
|
||
|
||
---
|
||
|
||
# 关键决策 — 入口聚合而非替代
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 决策
|
||
|
||
XINFRA 做**入口聚合**，不替代 Wayne、CloudDM、Apollo、CacheCloud、Grafana、Superset 等专业系统。
|
||
|
||
### 背景
|
||
|
||
| 现状 | 问题 |
|
||
|------|------|
|
||
| 运维需要登录 7+ 个系统 | 入口分散，效率低 |
|
||
| 各系统独立认证 | 重复登录，体验差 |
|
||
| 操作记录分散在各系统 | 审计困难，无法追溯 |
|
||
| 新人不知道该用哪个系统 | 上手门槛高 |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 方案对比
|
||
|
||
| 方案 | 优点 | 缺点 |
|
||
|------|------|------|
|
||
| **入口聚合（选定）** | 开发量小，复用现有系统能力 | 依赖子系统稳定性 |
|
||
| 全量自研替代 | 完全可控 | 开发周期长，团队人力不足 |
|
||
| 仅做文档指引 | 零开发成本 | 无法解决认证和审计问题 |
|
||
|
||
### 预期收益
|
||
|
||
- 运维人员**一个入口**完成所有操作
|
||
- **SSO 免登录**跳转子系统
|
||
- **统一审计**记录所有跨系统操作
|
||
- **降低新人上手门槛**
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 关键决策 — 业务线作为核心隔离维度
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 决策
|
||
|
||
以**业务线**作为资源、权限、监控的核心隔离维度。
|
||
|
||
### 背景
|
||
|
||
| 现状 | 问题 |
|
||
|------|------|
|
||
| 资源按机房/集群管理 | 无法按业务视角查看成本 |
|
||
| 权限按系统独立管理 | 跨系统权限不一致 |
|
||
| 监控按技术栈分散 | 排障时需要多系统切换 |
|
||
| 业务线有 5+ 条 | Kodo、LAS、灵矽、LTOKEN、MAAS |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 隔离模型
|
||
|
||
```mermaid
|
||
graph TB
|
||
BL["业务线<br/>Kodo / LAS / 灵矽 / ..."]
|
||
BL --> NS["K8s Namespace<br/>ResourceQuota"]
|
||
BL --> Perm["权限隔离<br/>RBAC 业务线维度"]
|
||
BL --> Monitor["监控隔离<br/>告警按业务线展示"]
|
||
BL --> Resource["资源台账<br/>按业务线统计成本"]
|
||
|
||
style BL fill:#e0f2fe,stroke:#0284c7
|
||
```
|
||
|
||
### 预期收益
|
||
|
||
- 资源成本**按业务线可视**
|
||
- 权限**一次配置，全系统生效**
|
||
- 监控告警**按业务线隔离展示**
|
||
- 运维人员**聚焦自己负责的业务线**
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 关键决策 — 基础服务交付自动化
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 决策
|
||
|
||
引入**自动化部署引擎**（Ansible Playbook），打通交付全流程。
|
||
|
||
### 痛点背景
|
||
|
||
| 现状 | 问题 |
|
||
|------|------|
|
||
| 业务上线依赖员工手动操作 | 交付效率低，周期长 |
|
||
| 工具链复杂，命令行门槛高 | 新人上手慢，培训成本高 |
|
||
| 操作方式因人而异 | 缺少标准化，易出错 |
|
||
| 部署过程不可见 | 排障困难 |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 方案对比
|
||
|
||
| 方案 | 优点 | 缺点 |
|
||
|------|------|------|
|
||
| **Ansible 编排（选定）** | 运维团队熟悉，生态成熟 | 需要自建任务队列 |
|
||
| 自研部署引擎 | 完全可控 | 开发周期长，重复造轮子 |
|
||
|
||
### 执行模型
|
||
|
||
```mermaid
|
||
graph LR
|
||
XINFRA["XINFRA<br/>任务提交"] --> Queue["任务队列"]
|
||
Queue --> Ansible["Ansible 控制中心"]
|
||
Ansible -->|SSH| Host1["机房 A 主机"]
|
||
Ansible -->|SSH| Host2["机房 B 主机"]
|
||
Ansible -.->|WebSocket| XINFRA
|
||
|
||
style XINFRA fill:#e0f2fe,stroke:#0284c7
|
||
```
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 关键决策 — 引入统一监控引擎整合分散数据
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 决策
|
||
|
||
引入**可对接多种业务线、多种场景、多种数据源的监控引擎**，整合分散的监控数据，而非自建。
|
||
|
||
### 背景
|
||
|
||
| 现状 | 问题 |
|
||
|------|------|
|
||
| 监控数据散落在不同服务和渠道 | 缺少统一的数据整合 |
|
||
| 告警分散在基础资源和业务系统 | 排障时信息割裂 |
|
||
| 夜莺已有告警聚合能力 | 重复建设浪费资源 |
|
||
| 业务线需要隔离查看告警 | 缺少统一看板视图 |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 方案对比
|
||
|
||
| 方案 | 优点 | 缺点 |
|
||
|------|------|------|
|
||
| **对接夜莺（选定）** | 支持多数据源多场景，生态成熟 | 依赖夜莺稳定性 |
|
||
| 仅做文档指引 | 零成本 | 无法统一视图 |
|
||
|
||
### 数据流
|
||
|
||
```mermaid
|
||
graph LR
|
||
VM["VictoriaMetrics<br/>指标存储"] --> Nightingale["夜莺<br/>告警聚合"]
|
||
Zabbix["Zabbix<br/>硬件监控"] --> Nightingale
|
||
Nightingale --> XINFRA["XINFRA<br/>按业务线展示"]
|
||
|
||
style XINFRA fill:#e0f2fe,stroke:#0284c7
|
||
```
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 关键决策 — 按需资源纳管
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 痛点
|
||
|
||
资源无法统一规划、查看和控制成本——数据散落在多个渠道，缺少全局视图。
|
||
|
||
| 渠道 | 数据范围 |
|
||
|------|----------|
|
||
| CMDB | 主机资产信息 |
|
||
| K8s 集群 | 节点与工作负载 |
|
||
| 容器运行时 | 容器状态信息 |
|
||
| 服务注册中心 | 服务状态信息 |
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 决策
|
||
|
||
建设**资源纳管平台**，统一汇聚以上多渠道数据，提供：
|
||
|
||
- 资源台账与统一视图
|
||
- 业务线关联与成本归属
|
||
- 容量统计与配额管理
|
||
|
||
### 纳管边界
|
||
|
||
以下能力**不做**：
|
||
|
||
- **虚拟机创建** — 已有内部系统实现，避免影响现有管理方案的稳定性
|
||
|
||
</div>
|
||
</div>
|
||
|
||
|
||
---
|
||
section: 架构设计
|
||
layout: center
|
||
---
|
||
|
||
|
||
# 四、架构设计
|
||
|
||
---
|
||
|
||
# 平台分层架构 — 总体分层
|
||
|
||
<div class="mt-4" style="transform: scale(1.0); transform-origin: top left;">
|
||
|
||
```mermaid
|
||
graph LR
|
||
User["用户层<br/>LDAP SSO 统一认证"] --> Main["XINFRA 主系统层<br/>统一入口 + 资源纳管 + 交付 + 审计"]
|
||
Main --> Sub["专业子系统层<br/>Wayne / Apollo / CloudDM / 夜莺"]
|
||
Main --> Auto["自动化执行层<br/>Ansible 控制中心"]
|
||
Main --> Infra["基础设施层<br/>计算 · 网络 · 存储 · 监控源"]
|
||
Sub --> Infra
|
||
Auto --> Infra
|
||
|
||
style User fill:#f3e8fd,stroke:#9333ea
|
||
style Main fill:#e0f2fe,stroke:#0284c7
|
||
style Sub fill:#e8f0fe,stroke:#4285f4
|
||
style Auto fill:#ecfdf5,stroke:#059669
|
||
style Infra fill:#fff7ed,stroke:#f97316
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 平台分层架构 — 主系统功能架构
|
||
|
||
<div class="mt-4">
|
||
|
||
```mermaid
|
||
mindmap
|
||
root((统一入口))
|
||
SSO 登录
|
||
菜单聚合
|
||
资源纳管
|
||
K8s 集群管理
|
||
基础服务交付
|
||
数据库审核
|
||
任务中心
|
||
审计中心
|
||
监控概览
|
||
权限中心
|
||
配置接入
|
||
业务交付
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 自动化执行架构
|
||
|
||
<div class="mt-4">
|
||
|
||
```mermaid
|
||
graph TB
|
||
Main["XINFRA 主系统"]
|
||
AC["Ansible 控制中心<br/>独立部署"]
|
||
|
||
subgraph 各区域
|
||
RegionA["区域 A"]
|
||
RegionB["区域 B"]
|
||
RegionC["区域 C"]
|
||
end
|
||
|
||
Main -->|任务提交 / 结果查询| AC
|
||
AC -->|SSH / Playbook| RegionA
|
||
AC -->|SSH / Playbook| RegionB
|
||
AC -->|SSH / Playbook| RegionC
|
||
```
|
||
|
||
</div>
|
||
|
||
|
||
---
|
||
|
||
|
||
|
||
# 监控与数据流
|
||
|
||
<div class="mt-4">
|
||
|
||
```mermaid
|
||
graph LR
|
||
subgraph 资源层
|
||
K8s["K8s 集群"]
|
||
Node["物理机 / 虚机"]
|
||
end
|
||
|
||
subgraph 监控源
|
||
Nightingale["夜莺"]
|
||
end
|
||
|
||
subgraph 展示层
|
||
Main["XINFRA 监控概览"]
|
||
end
|
||
|
||
K8s -.->|指标| Nightingale
|
||
Node -.->|指标| Nightingale
|
||
Nightingale --> Main
|
||
```
|
||
|
||
</div>
|
||
|
||
---
|
||
section: 对接子系统
|
||
layout: center
|
||
---
|
||
|
||
# 五、对接子系统
|
||
|
||
<div class="text-gray-400 mt-2">Wayne · CloudDM · CacheCloud · Apollo · qpass · Grafana · Superset</div>
|
||
|
||
---
|
||
|
||
# 子系统 — Wayne（多集群容器管理）
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 定位
|
||
**多租户 K8s 资源管理平台**，提供命名空间与资源配额管理。RKE2 集群和 GitLab CI 通过 Wayne 进行 K8s 资源管控与业务容器发布。
|
||
|
||
### 核心能力
|
||
- **业务容器发布** — Deployment、StatefulSet 等工作负载的部署与回滚
|
||
- **命名空间管理** — 按业务线创建 Namespace，隔离资源边界
|
||
- **配额管理** — 为每个 Namespace 设置 ResourceQuota，控制 CPU / 内存上限
|
||
- **多租户隔离** — 复用 Wayne 原生租户模型，业务线 ↔ Namespace 自动映射
|
||
- **CI/CD 集成** — 对外提供 APIKey，GitLab CI 自动触发部署
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 关键对接
|
||
|
||
```mermaid
|
||
graph LR
|
||
BL["业务线"] -->|租户映射| Wayne["Wayne"]
|
||
Wayne -->|Namespace + Quota| RKE2["RKE2 集群"]
|
||
CI["GitLab CI"] -->|APIKey| Wayne
|
||
Main["XINFRA 主系统"] -.->|SSO| Wayne
|
||
```
|
||
|
||
### 说明
|
||
- 独立 WebUI + API 服务
|
||
- XINFRA 负责"哪个业务线用哪些资源"，Wayne 负责"怎么发布和管理容器"
|
||
- APIKey 遵循最小权限原则，主系统通过 SSO 跳转
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 子系统 — CloudDM（数据库 SQL 审核）
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 定位
|
||
数据库 SQL 上线**统一审核平台**，所有数据库变更必须经过 CloudDM 审批才能执行。
|
||
|
||
### 核心能力
|
||
- **SQL 审核** — 上线前自动检查 SQL 语句的合规性、语法风险和性能影响
|
||
- **LDAP 角色映射** — 支持 LDAP 用户组到 CloudDM 角色的自动映射，无需手动配权限
|
||
- **变更执行** — 审核通过后通过 Sidecar SQL 代理安全执行变更
|
||
- **操作审计** — 所有 SQL 操作全程记录，可追溯谁在什么时候改了什么
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 关键对接
|
||
|
||
```mermaid
|
||
graph LR
|
||
LDAP["企业 LDAP"] -->|用户组映射| CloudDM["CloudDM"]
|
||
User["DBA / 开发"] --> CloudDM
|
||
CloudDM -->|Sidecar 代理| MySQL[("MySQL")]
|
||
Deploy["服务部署完成"] -.->|自动注册| CloudDM
|
||
Main["XINFRA 主系统"] -.->|SSO| CloudDM
|
||
```
|
||
|
||
### 说明
|
||
- 基础服务交付流程中，MySQL 部署完成后自动注册至 CloudDM
|
||
- LDAP 用户组映射：运维组 → DBA 角色，开发组 → 只读角色，入职即有权限
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 子系统 — CacheCloud（Redis 全生命周期管理）
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 定位
|
||
Redis 实例**全生命周期管理平台**，从创建到下线一站式管理，登录与监控运维统一入口。
|
||
|
||
### 核心能力
|
||
- **全生命周期** — 实例创建、扩缩容、版本升级、下线销毁全覆盖
|
||
- **统一入口** — 登录、监控、运维操作统一在 CacheCloud 内完成
|
||
- **Agent 模式** — 通过 Agent 远程管理各机房 Redis 实例
|
||
- **诊断工具** — 大 Key / 热 Key 检测，慢查询分析，内存碎片率监控
|
||
- **监控集成** — 实例指标上报至 VictoriaMetrics，Grafana 仪表盘展示
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 关键对接
|
||
|
||
```mermaid
|
||
graph LR
|
||
User["运维人员"] --> CacheCloud["CacheCloud"]
|
||
CacheCloud -->|Agent| Redis[("Redis")]
|
||
CacheCloud -->|指标上报| VM["VictoriaMetrics"]
|
||
Deploy["服务部署完成"] -.->|自动注册| CacheCloud
|
||
Main["XINFRA 主系统"] -.->|SSO| CacheCloud
|
||
```
|
||
|
||
### 说明
|
||
- 基础服务交付流程中，Redis 部署完成后自动注册至 CacheCloud
|
||
- 运维人员无需 SSH 到机器上操作，所有运维操作在 Web 界面完成
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 子系统 — Apollo（统一配置中心）
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 定位
|
||
携程开源的分布式配置中心，**统一管理各业务线应用配置**，按机房 Cluster 隔离部署。
|
||
|
||
### 核心能力
|
||
- **按机房隔离** — 每个机房独立 Cluster，配置就近读取，降低跨机房延迟
|
||
- **灰度发布** — 配置变更可先推送给部分实例验证，确认无误后再全量发布
|
||
- **版本回滚** — 每次配置变更自动保存历史版本，出问题可一键回滚
|
||
- **变更审计** — 谁改了什么配置、什么时候改的、改之前是什么值，全程可追溯
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 关键对接
|
||
|
||
```mermaid
|
||
graph LR
|
||
App["业务应用"] -->|ConfigService| Apollo["Apollo"]
|
||
Apollo -->|按机房 Cluster 隔离| IDC1["机房 A"]
|
||
Apollo -->|按机房 Cluster 隔离| IDC2["机房 B"]
|
||
Main["XINFRA 主系统"] -.->|SSO| Apollo
|
||
```
|
||
|
||
### 说明
|
||
- 本地缓存降级：Apollo 服务不可用时，应用使用本地缓存的配置继续运行
|
||
- 灰度发布流程：先推 1 台 → 观察指标 → 确认无异常 → 全量推送
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 子系统 — qpass（七牛统一运维平台）
|
||
|
||
<div class="mt-8 text-lg leading-relaxed">
|
||
|
||
七牛云内部**统一运维平台**，提供基础设施运维操作的标准化入口。
|
||
|
||
XINFRA 通过 SSO 对接 qpass，运维人员从统一入口跳转即可使用，无需单独登录。
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
# 子系统 — Grafana（指标可视化平台）
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 定位
|
||
**K8s / 容器 / 业务指标统一仪表盘**，对接 VictoriaMetrics 数据源，提供多维度监控可视化。
|
||
|
||
### 核心能力
|
||
- **统一仪表盘** — K8s 集群、容器、业务指标集中展示，一个页面看全局
|
||
- **VictoriaMetrics 对接** — 作为主数据源，PromQL 直接查询指标数据
|
||
- **多维度监控** — 节点资源、Pod 状态、应用 QPS / 延迟 / 错误率
|
||
- **告警可视化** — 告警规则配置与历史趋势展示
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 关键对接
|
||
|
||
```mermaid
|
||
graph LR
|
||
VM["VictoriaMetrics<br/>指标存储"] -->|PromQL| Grafana["Grafana"]
|
||
K8s["RKE2 集群"] -->|Metrics| VM
|
||
Main["XINFRA 主系统"] -.->|SSO| Grafana
|
||
```
|
||
|
||
### 说明
|
||
- 直接复用现有 Grafana 仪表盘，无需主系统重建监控视图
|
||
- 主系统资源状态看板侧重告警聚合，Grafana 侧重指标深度可视化
|
||
|
||
</div>
|
||
</div>
|
||
|
||
---
|
||
|
||
# 子系统 — Superset（日志数据可视化）
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-4">
|
||
<div>
|
||
|
||
### 定位
|
||
**日志数据探索与可视化分析平台**，支持多数据源接入和丰富的图表展示。
|
||
|
||
### 核心能力
|
||
- **日志数据探索** — 交互式查询日志数据，支持筛选、聚合、下钻
|
||
- **多数据源接入** — 支持 ClickHouse、Elasticsearch、MySQL 等多种数据源
|
||
- **丰富图表** — 折线图、柱状图、饼图、热力图、表格等 40+ 图表类型
|
||
- **仪表盘** — 拖拽式组合图表，构建业务专属的日志分析大盘
|
||
|
||
</div>
|
||
<div>
|
||
|
||
### 关键对接
|
||
|
||
```mermaid
|
||
graph LR
|
||
Log["日志数据<br/>ClickHouse / ES"] --> Superset["Superset"]
|
||
User["运维 / 开发"] --> Superset
|
||
Main["XINFRA 主系统"] -.->|SSO| Superset
|
||
```
|
||
|
||
|
||
</div>
|
||
</div>
|
||
|
||
--- |