wonder/slide

Fork 0

Files

T

wonder 7f599ffd62

Deploy Slides / build-and-deploy (push) Has been cancelled

Details

docs: update team member name in xinfra deck

2026-07-17 23:07:49 +08:00

22 KiB

Raw Blame History

theme, title, author, infoLine, transition, mdc, drawings

theme

title

author

infoLine

transition

mdc

drawings

frankfurt

XINFRA 平台需求与架构

实训小组

true

slide-left

true

persist
false

XINFRA 平台需求与架构

统一基础设施管理平台 · 总体架构设计

实训小组

layout: default

小组介绍

团队成员

角色	姓名
导师	秦秀科（Adam）
助教	张少坡
组长	汪大炜
组员	郭永昊
组员	何朝晖
组员	刘家辉
组员	邹婷

项目背景

XINFRA 统一基础设施管理平台

本项目旨在解决各业务线长期独立建设导致的资源分散、交付效率低、权限过大、监控割裂等问题，通过统一入口整合资源、服务、任务、审计和监控能力。

layout: default

一、系统需求

系统边界 · 做什么 vs 不做什么

一句话概括需求

背景： 各业务线长期独立建设，资源分散、交付效率低、权限过大、监控割裂、基础服务交付不标准。

需求： XINFRA 以机房容器资源为核心，把资源、服务、任务、审计和监控统一纳管，配套容器发布、SQL 审核、Redis 管理、配置中心、指标可视化、日志分析等子系统，完成多种运维场景下的需求。

系统边界 — 做什么 vs 不做什么

✅ 做什么

范围	说明
统一入口	一个入口登录，集中展示各子系统和平台能力
资源台账	统一查看物理机、虚机、云主机、K8s 资源
容器纳管	管理 K8s 集群、Namespace、配额和业务线归属
业务交付	跳转 Wayne、CloudDM、Apollo、Superset 等系统
基础服务交付	标准化模板 + Ansible 编排
数据库审核	SQL 工单、审批、审计
监控纳管	对接夜莺，按业务线展示告警
权限管理	业务线维度授权、子系统角色管理
审计	记录登录、跳转、审批和自动化执行

❌ 不做什么

范围	不做原因
替代 Wayne、Apollo、CloudDM、CacheCloud、Grafana、Superset 等	专业系统继续保留
全量自研监控和告警引擎	成本高，非当前重点
复杂 AI 排障	由其他项目负责
虚机创建主流程	统一走线下流程
大而全的运维平台	两个月内不现实，也不必要

section: 用户故事 layout: center

二、用户故事

资源查看 · 业务交付 · 基础服务交付 · 数据库审核 · 业务线切换

用户故事 — 资源查看

场景：运维人员登录 XINFRA 后，直接看到全量资源分布、业务线归属、节点状态和容量概览，不需要在多个 CMDB 和云平台之间来回切换。

链路：业务 SRE 登录 XINFRA → 选择业务线 → 平台同步 CMDB / 云平台 / RKE2 数据 → 展示全量资源大盘

用户故事 — 资源查看 · 交互图

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/>业务线归属 · 节点状态 · 容量概览

用户故事 — 业务交付

场景：业务 SRE 在 XINFRA 中进入"业务交付"，选择对应业务线后跳转到 Wayne、CloudDM、Apollo 或 Superset 完成实际操作，平台保留入口、上下文和审计。

链路：业务 SRE 登录 → 进入业务交付 → 选择业务线 → 展示子系统入口 → SSO 跳转至目标系统 → 记录审计日志

用户故事 — 业务交付 · 交互图

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: 记录跳转审计日志

用户故事 — 基础服务交付

场景：运维人员在 XINFRA 中提交 MySQL、Redis 等基础服务交付任务，平台调用 Ansible 控制中心执行标准化部署，并在任务中心查看日志和结果。

链路：运维人员登录 → 选择服务卡片 → 填写业务线和规格 → 提交任务 → Ansible 执行部署 → 自动注册至子系统 → 部署完成通知

用户故事 — 基础服务交付 · 交互图

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: 部署完成通知

用户故事 — 数据库审核

场景：开发或运维提交 SQL 工单后，审核人可以在 XINFRA 中完成审批、查看执行记录和审计信息，减少线下沟通和手工操作。

链路：开发/运维提交 SQL 工单 → 转发至 CloudDM → 审核人审批 → 执行变更 → Sidecar 代理执行 SQL → 审计记录 → 通知完成

用户故事 — 数据库审核 · 交互图

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: 通知完成

用户故事 — 业务线切换

场景：XINFRA 以业务线作为核心隔离维度，不同角色登录后默认看到自己负责的业务线数据，支持一键切换。系统运维可查看全局，业务 SRE 聚焦本业务线，只读用户仅能查看授权范围。

角色：系统运维（全局视角）、业务 SRE（本业务线）、跨业务线运维（按需切换）、只读用户（受限查看）

section: 关键决策 layout: center

三、关键决策

入口聚合 · 业务线隔离 · Ansible 编排 · 对接夜莺

关键决策 — 入口聚合而非替代

决策

XINFRA 做入口聚合，不替代 Wayne、CloudDM、Apollo、CacheCloud、Grafana、Superset 等专业系统。

背景

现状	问题
运维需要登录 7+ 个系统	入口分散，效率低
各系统独立认证	重复登录，体验差
操作记录分散在各系统	审计困难，无法追溯
新人不知道该用哪个系统	上手门槛高

方案对比

方案	优点	缺点
入口聚合（选定）	开发量小，复用现有系统能力	依赖子系统稳定性
全量自研替代	完全可控	开发周期长，团队人力不足
仅做文档指引	零开发成本	无法解决认证和审计问题

预期收益

运维人员一个入口完成所有操作
SSO 免登录跳转子系统
统一审计记录所有跨系统操作
降低新人上手门槛

关键决策 — 业务线作为核心隔离维度

决策

以业务线作为资源、权限、监控的核心隔离维度。

背景

现状	问题
资源按机房/集群管理	无法按业务视角查看成本
权限按系统独立管理	跨系统权限不一致
监控按技术栈分散	排障时需要多系统切换
业务线有 5+ 条	Kodo、LAS、灵矽、LTOKEN、MAAS

隔离模型

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

预期收益

资源成本按业务线可视
权限一次配置，全系统生效
监控告警按业务线隔离展示
运维人员聚焦自己负责的业务线

关键决策 — 基础服务交付自动化

决策

引入自动化部署引擎（Ansible Playbook），打通交付全流程。

痛点背景

现状	问题
业务上线依赖员工手动操作	交付效率低，周期长
工具链复杂，命令行门槛高	新人上手慢，培训成本高
操作方式因人而异	缺少标准化，易出错
部署过程不可见	排障困难

方案对比

方案	优点	缺点
Ansible 编排（选定）	运维团队熟悉，生态成熟	需要自建任务队列
自研部署引擎	完全可控	开发周期长，重复造轮子

执行模型

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

关键决策 — 引入统一监控引擎整合分散数据

决策

引入可对接多种业务线、多种场景、多种数据源的监控引擎，整合分散的监控数据，而非自建。

背景

现状	问题
监控数据散落在不同服务和渠道	缺少统一的数据整合
告警分散在基础资源和业务系统	排障时信息割裂
夜莺已有告警聚合能力	重复建设浪费资源
业务线需要隔离查看告警	缺少统一看板视图

方案对比

方案	优点	缺点
对接夜莺（选定）	支持多数据源多场景，生态成熟	依赖夜莺稳定性
仅做文档指引	零成本	无法统一视图

数据流

graph LR
    VM["VictoriaMetrics<br/>指标存储"] --> Nightingale["夜莺<br/>告警聚合"]
    Zabbix["Zabbix<br/>硬件监控"] --> Nightingale
    Nightingale --> XINFRA["XINFRA<br/>按业务线展示"]

    style XINFRA fill:#e0f2fe,stroke:#0284c7

关键决策 — 按需资源纳管

痛点

资源无法统一规划、查看和控制成本——数据散落在多个渠道，缺少全局视图。

渠道	数据范围
CMDB	主机资产信息
K8s 集群	节点与工作负载
容器运行时	容器状态信息
服务注册中心	服务状态信息

决策

建设资源纳管平台，统一汇聚以上多渠道数据，提供：

资源台账与统一视图
业务线关联与成本归属
容量统计与配额管理

纳管边界

以下能力不做：

虚拟机创建 — 已有内部系统实现，避免影响现有管理方案的稳定性

section: 架构设计 layout: center

四、架构设计

平台分层架构 — 总体分层

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

平台分层架构 — 主系统功能架构

mindmap
  root((统一入口))
    SSO 登录
    菜单聚合
    资源纳管
    K8s 集群管理
    基础服务交付
    数据库审核
    任务中心
    审计中心
    监控概览
    权限中心
    配置接入
    业务交付

自动化执行架构

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

监控与数据流

graph LR
    subgraph 资源层
        K8s["K8s 集群"]
        Node["物理机 / 虚机"]
    end

    subgraph 监控源
        Nightingale["夜莺"]
    end

    subgraph 展示层
        Main["XINFRA 监控概览"]
    end

    K8s -.->|指标| Nightingale
    Node -.->|指标| Nightingale
    Nightingale --> Main

section: 对接子系统 layout: center

五、对接子系统

Wayne · CloudDM · CacheCloud · Apollo · qpass · Grafana · Superset

子系统 — Wayne（多集群容器管理）

定位

多租户 K8s 资源管理平台，提供命名空间与资源配额管理。RKE2 集群和 GitLab CI 通过 Wayne 进行 K8s 资源管控与业务容器发布。

核心能力

业务容器发布 — Deployment、StatefulSet 等工作负载的部署与回滚
命名空间管理 — 按业务线创建 Namespace，隔离资源边界
配额管理 — 为每个 Namespace 设置 ResourceQuota，控制 CPU / 内存上限
多租户隔离 — 复用 Wayne 原生租户模型，业务线 ↔ Namespace 自动映射
CI/CD 集成 — 对外提供 APIKey，GitLab CI 自动触发部署

关键对接

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 跳转

子系统 — CloudDM（数据库 SQL 审核）

定位

数据库 SQL 上线统一审核平台，所有数据库变更必须经过 CloudDM 审批才能执行。

核心能力

SQL 审核 — 上线前自动检查 SQL 语句的合规性、语法风险和性能影响
LDAP 角色映射 — 支持 LDAP 用户组到 CloudDM 角色的自动映射，无需手动配权限
变更执行 — 审核通过后通过 Sidecar SQL 代理安全执行变更
操作审计 — 所有 SQL 操作全程记录，可追溯谁在什么时候改了什么

关键对接

graph LR
    LDAP["企业 LDAP"] -->|用户组映射| CloudDM["CloudDM"]
    User["DBA / 开发"] --> CloudDM
    CloudDM -->|Sidecar 代理| MySQL[("MySQL")]
    Deploy["服务部署完成"] -.->|自动注册| CloudDM
    Main["XINFRA 主系统"] -.->|SSO| CloudDM

说明

基础服务交付流程中，MySQL 部署完成后自动注册至 CloudDM
LDAP 用户组映射：运维组 → DBA 角色，开发组 → 只读角色，入职即有权限

子系统 — CacheCloud（Redis 全生命周期管理）

定位

Redis 实例全生命周期管理平台，从创建到下线一站式管理，登录与监控运维统一入口。

核心能力

全生命周期 — 实例创建、扩缩容、版本升级、下线销毁全覆盖
统一入口 — 登录、监控、运维操作统一在 CacheCloud 内完成
Agent 模式 — 通过 Agent 远程管理各机房 Redis 实例
诊断工具 — 大 Key / 热 Key 检测，慢查询分析，内存碎片率监控
监控集成 — 实例指标上报至 VictoriaMetrics，Grafana 仪表盘展示

关键对接

graph LR
    User["运维人员"] --> CacheCloud["CacheCloud"]
    CacheCloud -->|Agent| Redis[("Redis")]
    CacheCloud -->|指标上报| VM["VictoriaMetrics"]
    Deploy["服务部署完成"] -.->|自动注册| CacheCloud
    Main["XINFRA 主系统"] -.->|SSO| CacheCloud

说明

基础服务交付流程中，Redis 部署完成后自动注册至 CacheCloud
运维人员无需 SSH 到机器上操作，所有运维操作在 Web 界面完成

子系统 — Apollo（统一配置中心）

定位

携程开源的分布式配置中心，统一管理各业务线应用配置，按机房 Cluster 隔离部署。

核心能力

按机房隔离 — 每个机房独立 Cluster，配置就近读取，降低跨机房延迟
灰度发布 — 配置变更可先推送给部分实例验证，确认无误后再全量发布
版本回滚 — 每次配置变更自动保存历史版本，出问题可一键回滚
变更审计 — 谁改了什么配置、什么时候改的、改之前是什么值，全程可追溯

关键对接

graph LR
    App["业务应用"] -->|ConfigService| Apollo["Apollo"]
    Apollo -->|按机房 Cluster 隔离| IDC1["机房 A"]
    Apollo -->|按机房 Cluster 隔离| IDC2["机房 B"]
    Main["XINFRA 主系统"] -.->|SSO| Apollo

说明

本地缓存降级：Apollo 服务不可用时，应用使用本地缓存的配置继续运行
灰度发布流程：先推 1 台 → 观察指标 → 确认无异常 → 全量推送

子系统 — qpass（七牛统一运维平台）

七牛云内部统一运维平台，提供基础设施运维操作的标准化入口。

XINFRA 通过 SSO 对接 qpass，运维人员从统一入口跳转即可使用，无需单独登录。

子系统 — Grafana（指标可视化平台）

定位

K8s / 容器 / 业务指标统一仪表盘，对接 VictoriaMetrics 数据源，提供多维度监控可视化。

核心能力

统一仪表盘 — K8s 集群、容器、业务指标集中展示，一个页面看全局
VictoriaMetrics 对接 — 作为主数据源，PromQL 直接查询指标数据
多维度监控 — 节点资源、Pod 状态、应用 QPS / 延迟 / 错误率
告警可视化 — 告警规则配置与历史趋势展示

关键对接

graph LR
    VM["VictoriaMetrics<br/>指标存储"] -->|PromQL| Grafana["Grafana"]
    K8s["RKE2 集群"] -->|Metrics| VM
    Main["XINFRA 主系统"] -.->|SSO| Grafana

说明

直接复用现有 Grafana 仪表盘，无需主系统重建监控视图
主系统资源状态看板侧重告警聚合，Grafana 侧重指标深度可视化

子系统 — Superset（日志数据可视化）

定位

日志数据探索与可视化分析平台，支持多数据源接入和丰富的图表展示。

核心能力

日志数据探索 — 交互式查询日志数据，支持筛选、聚合、下钻
多数据源接入 — 支持 ClickHouse、Elasticsearch、MySQL 等多种数据源
丰富图表 — 折线图、柱状图、饼图、热力图、表格等 40+ 图表类型
仪表盘 — 拖拽式组合图表，构建业务专属的日志分析大盘

关键对接

graph LR
    Log["日志数据<br/>ClickHouse / ES"] --> Superset["Superset"]
    User["运维 / 开发"] --> Superset
    Main["XINFRA 主系统"] -.->|SSO| Superset

22 KiB Raw Blame History Unescape Escape

XINFRA 平台需求与架构

layout: default

小组介绍

团队成员

项目背景

layout: default

目录

一、系统需求

二、用户故事

三、关键决策

四、架构设计

五、对接子系统

section: 系统需求 layout: center

一、系统需求

一句话概括需求

系统边界 — 做什么 vs 不做什么

✅ 做什么

❌ 不做什么

section: 用户故事 layout: center

二、用户故事

用户故事 — 资源查看

用户故事 — 资源查看 · 交互图

用户故事 — 业务交付

用户故事 — 业务交付 · 交互图

用户故事 — 基础服务交付

用户故事 — 基础服务交付 · 交互图

用户故事 — 数据库审核

用户故事 — 数据库审核 · 交互图

用户故事 — 业务线切换

section: 关键决策 layout: center

三、关键决策

关键决策 — 入口聚合而非替代

决策

背景

方案对比

预期收益

关键决策 — 业务线作为核心隔离维度

决策

背景

隔离模型

预期收益

关键决策 — 基础服务交付自动化

决策

痛点背景

方案对比

执行模型

关键决策 — 引入统一监控引擎整合分散数据

决策

背景

方案对比

数据流

关键决策 — 按需资源纳管

痛点

决策

纳管边界

section: 架构设计 layout: center

四、架构设计

平台分层架构 — 总体分层

平台分层架构 — 主系统功能架构

自动化执行架构

监控与数据流

section: 对接子系统 layout: center

五、对接子系统

子系统 — Wayne（多集群容器管理）

定位

核心能力

关键对接

说明

子系统 — CloudDM（数据库 SQL 审核）

定位

核心能力

关键对接

说明

子系统 — CacheCloud（Redis 全生命周期管理）

定位

核心能力

关键对接

说明

子系统 — Apollo（统一配置中心）

22 KiB

Raw Blame History