xinfra/docs/ref/平台需求文档-v3.md

XINFRA 平台需求文档

概述

XINFRA 是面向多业务线、七机房混合云的统一基础设施管理平台，为 Kodo、LAS、灵矽、LTOKEN、MAAS 等业务线提供容器资源调度、基础服务交付、资源台账、监控告警、配置管理的一站式操作面。

核心目标：

#	目标	说明
1	统一纳管	所有基础设施操作收敛到平台化界面，屏蔽多机房、多云差异，降低命令行直接操作风险
2	多机房资源池化	七机房 RKE2 集群统一纳管，实现跨机房调度与服务发现
3	标准化交付	基础组件（MySQL、Redis 等）通过服务卡片 + Ansible Playbook 实现一键标准化部署
4	安全合规	主系统登录与运维操作全程审计、SQL 上线必须经过审核、LDAP 统一认证与 SSO
5	效率提升	CD 自动化部署，Ansible 实现基础设施即代码，任务中心实时追踪
6	可观测性	整合 Zabbix + VictoriaMetrics + Nightingale + qpass，资源大盘与监控告警全局可见

设计原则：

• 最小权限：子系统操作默认走 RBAC，主系统以 LDAP 身份 + 管理员角色区分权限，APIKey 遵循最小授权范围
• 审计留痕：主系统记录登录事件和运维操作日志，子系统各自维护操作审计
• 机房就近：服务部署和数据访问遵循机房就近原则，降低跨机房延迟
• 平台化自治：自助申请资源、自助发布、自助诊断，减少人工工单流转
• 复用优先：监控、告警等能力优先复用已有基础设施（VictoriaMetrics / Grafana / Zabbix / Nightingale），主系统只自建无法被替代的能力
• 数据一致性：资源同步采用"已存在跳过更新"策略，保护人工维护的资产数据，防止被云平台同步覆盖

---

角色模型

主系统采用二维角色模型：权限维度 × 业务线维度。

权限维度

权限角色	权限范围
超级管理员	全平台所有模块的读写权限，包括集群管理、运维终端、账号权限管理、审计全局查看
业务操作员	本业务线内资源的申请、部署、配置变更；可操作 Wayne/CloudDM/CacheCloud/Apollo 中本业务线的资源
日志操作员	本业务线的日志查看、告警查看、审计记录查看；无写入/变更权限
访客	只读查看资源大盘、服务目录、告警概览；不可执行任何操作

业务线维度

业务线	说明
Kodo	七牛云存储
LAS	七牛云直播
灵矽	七牛云 IoT
LTOKEN	七牛云 Token 服务
MAAS	七牛云模型即服务

权限矩阵

模块	超级管理员	业务操作员	日志操作员	访客
资源大盘	✓ 全局	✓ 本业务线	✓ 本业务线	✓ 全局只读
告警看板	✓ 全局	✓ 本业务线	✓ 本业务线	✓ 只读
集群与节点管理	✓ 读写	○ 只读	○ 只读	✗
多租户管理	✓ 读写	✗	✗	✗
Wayne 部署	✓ 读写	✓ 本业务线	○ 只读	✗
CloudDM SQL 审核	✓ 读写	✓ 本业务线	○ 只读	✗
CacheCloud 缓存	✓ 读写	✓ 本业务线	○ 只读	✗
Apollo 配置	✓ 读写	✓ 本业务线	○ 只读	✗
任务中心	✓ 全局	✓ 本业务线	✓ 本业务线	✗
资源台账	✓ 读写	○ 只读	○ 只读	✗
审计面板	✓ 全局	✗	✓ 本业务线	✗
运维终端	✓ 仅管理员	✗	✗	✗

✓ = 读写权限，○ = 只读权限，✗ = 无权限

---

功能需求

Phase 1 — MVP（当前阶段）

最小可用集：多租户认证 + 子系统对接

1.1 平台基础能力

统一子系统导航

作为所有相关子系统的单一入口门户，利用 LDAP 统一账号实现 SSO，用户无需记忆多个地址和重复认证。

• P0 — 已集成系统卡片展示：系统图标、名称、简要说明及 LDAP/SSO 接入状态（已接入/改造中），预留打开链接
• P0 — 已集成系统包括：Wayne、CloudDM、CacheCloud、qpass、Grafana、Apollo
• P0 — SSO 跳转：点击卡片通过 LDAP SSO 跳转至对应子系统，无需重复登录

---

审计面板（主系统）

记录主系统自身的登录事件和运维操作日志，不聚合子系统操作审计。

• P0 — 登录审计：记录每次 LDAP SSO 登录事件（操作人、时间、来源 IP、目标子系统），支持按时间/操作人/子系统筛选查询
• P0 — 运维操作审计：记录主系统运维终端的操作（Ansible Playbook 执行、节点加入、配置变更等），支持按时间/操作人/操作类型筛选
• P0 — 权限控制：管理员角色可查看全局；普通用户仅查看自身登录记录
• P0 — 审计面板集成到主系统统一门户，无需独立部署

---

1.2 子系统对接

Wayne — 容器编排与多集群管理

底层基于 RKE2 构建七机房 K8s 集群，上层通过 Wayne 平台提供统一的容器管理入口。开发人员通过 Wayne UI 或 API 完成服务部署，无需直接操作 kubectl。

RKE2 集群约束（基础设施依赖）：

约束项	说明
CNI 插件	Calico BGP（每集群独立 AS 号）
容器运行时	containerd（不依赖 Docker）
离线部署	支持 Air-gap 环境
集群规模	七机房各一套独立集群
安全加固	已通过 CIS Benchmark，默认启用加密和审计

Wayne 多集群管理：

• P0 — 支持多集群统一管理，通过 Client-Go 连接各机房 RKE2 集群
• P0 — 提供表单式（基础模式）和 YAML/JSON 编辑（高级模式）两种 K8s 对象创建方式
• P0 — 发布历史记录与一键回滚能力
• P0 — 完整审计模块，每次操作留痕，支持自定义 Webhook 回调
• P0 — APIKey 开放接口，支持 CI/CD 流水线调用
• P0 — 认证支持 DB 内置 + LDAP 混合模式

---

CloudDM / open-cdm — 数据库管理与 SQL 审核

覆盖数据查询、权限管控、SQL 审核、数据脱敏的全链路能力。所有生产库 SQL 操作必须经过工单流程，无直连通道。

• P0 — 支持 Console + Sidecar 集群部署模式，保证高可用
• P0 — 支持 20+ 数据源类型（MySQL、Oracle、PG、ClickHouse、Redis、MongoDB 等）
• P0 — 内置 54 条 SQL 审核规则，支持规则脚本自定义扩展
• P0 — SQL 上线工单流程：编写 → 预检 → DBA 审核 → 执行，支持手动/立即/定时三种执行方式
• P0 — 权限控制：资源权限（实例/库/Schema/表粒度）+ 功能权限（RBAC），支持申请/赋予/临时权限
• P1 — 数据脱敏能力，对查询结果中的敏感字段进行隐藏或转换
• P1 — 数据库 CI/CD：支持 Git Push / WebHook / HttpCall 三种触发方式
• P0 — 统一认证：对接企业 LDAP
• P0 — 全程审计留痕，工单流转记录可追溯

---

CacheCloud — 缓存管理

支持 Standalone、Sentinel、Cluster 三种 Redis 架构的一站式管理。所有 Redis 场景通过 CacheCloud 统一实例申请和管理。

• P0 — 支持三种 Redis 架构：Standalone（测试）、Sentinel（生产常规，内存 ≤ 6GB）、Cluster（大数据量，内存 > 6GB）
• P0 — Agent 代理部署在每个宿主机上，管理 Redis 实例生命周期
• P0 — 接入层 Nginx 双机房部署 + Virtual IP 双向漂移，保证高可用
• P0 — 客户端接入支持 REST API（通用）、Java Jedis/Lettuce SDK、Python 接入
• P1 — 跨机房部署（Cross-Room）：支持双活，客户端 SDK 自动双写双读和机房切换
• P0 — 运维能力：全局统计、工单审批、应用运维、实例运维、数据迁移
• P1 — 诊断工具：慢查询分析、连接数诊断、Bigkey 检测
• P0 — 报警组件：支持邮件、微信、HTTP 接口集成
• P1 — 临时实例自动回收策略，防止资源浪费

---

Apollo — 配置中心管理

对 Apollo 配置中心进行统一接入和管理，实现在单一 Portal 管理所有机房的配置，确保配置的灰度发布、回滚与变更审计。

• P0 — 核心指标展示：已接入机房数、Apollo Cluster 数量、配置项总数、Namespace 数、接入业务线及同步状态
• P0 — 统一入口：提供 Apollo Portal 快捷入口（内部域名 apollo.xinfra.internal），LDAP SSO 单点登录
• P0 — 机房列表：展示每个机房的 Apollo Cluster、Config Service 地址、承载方式（容器化 K8s Service）、接入业务线和配置项数、运行状态（运行中/灰度接入/建设中/待启动）

部署架构约束：

• Portal + Admin Service：YZH 主中心统一部署
• Config Service：按机房独立部署（yzh/xs/jf/dallas 等），容器化运行在 K8s 内
• 数据同步：ConfigDB/PortalDB 部署在 YZH，各机房 Config Service 本地缓存全量配置，网络抖动时降级提供本地缓存

---

CD 自动化部署

通过 API 接口触发 Wayne 平台执行自动化部署，CI 部分由团队已有 CI 系统负责。

• P0 — 提供 REST API 接口，供外部 CI 系统调用触发 Wayne 部署，传入镜像 tag 和目标环境
• P0 — 部署支持多环境（dev / staging / prod），生产环境需审批卡点
• P1 — 部署失败时支持自动回滚到上一个稳定版本
• P1 — 部署状态回调：支持 Webhook 回调通知外部 CI 系统部署结果

[!info] CI 编译构建由团队已有 CI 系统负责，本平台仅提供 CD 部署接口。

---

Phase 2 — 完整版

监控、配置、任务、基础服务交付的完整能力

2.1 监控与可观测性

资源大盘

为平台管理员及业务负责人提供跨机房、多云容器资源的全局快照与健康视图。

• P0 — 展示核心指标：RKE2 集群数量、在线机房数、节点总数及近期增量、CPU 总核数/已分配/分配率、组件实例总数及分类（MySQL、Redis、其他）、进行中的自动化任务数量
• P0 — 集群拓扑：以机房为维度，显示各机房节点池方格图（node grid），每个方格代表一台物理机/节点，颜色区分业务线（Kodo、LAS 等），空闲节点用虚线框表示
• P0 — 最近任务：列表展示最近 5 条 ansible-playbook 任务的执行状态（成功/执行中/失败）和耗时，快速跳转至任务中心
• P1 — 刷新机制：页面自动显示"最近更新于 xx 秒前"，支持手动刷新

---

资源状态看板与告警

整合物理机、虚机、基础服务三层的健康状态，通过夜莺（Nightingale）统一告警引擎将多源告警标准化展示，提供自上而下的故障定位入口。

数据源：

• 物理机硬件 & 网络设备健康：Zabbix（IPMI/温度/电源/风扇/存储）

• 虚机 & 容器 & 业务层指标：VictoriaMetrics（K8s/主机指标/服务可用性探活）

• Nightingale 作为统一告警聚合层，负责去重、收敛、分级（P0/P1/…），按 disaster/high/average 等原始级别映射，推送至 qpass 告警通道

• P0 — 核心统计：物理机总数、虚机总数、基础组件实例总数；P0(Disaster)、P1(High) 及 average 级别告警数量，标注来自 Zabbix 或 VictoriaMetrics

• P0 — 物理机状态：按机房汇总在线数、健康率（带进度条），标识正常/告警/严重状态

• P0 — 虚机状态：按业务线展示 LAS 资源池中的虚机数、CPU 均值及告警状态

• P0 — 基础服务状态：覆盖 MySQL、Redis（CacheCloud）、PostgreSQL、openresty 网关等，显示实例数、异常数、可用率

• P0 — 当前告警详情：表格列出所有 P0/P1 及 average 级别的实时告警，含级别标签、来源、原始级别、目标对象、告警内容、发生时间

---

监控、日志与告警集成

集成公司现有监控与日志基础设施的状态和主要入口，方便从平台直接掌握各子系统健康度。

• P0 — VictoriaMetrics 指标概览：展示七机房采集节点数、活跃时序数量、Prometheus 接口状态、已建 Grafana 仪表盘数
• P0 — Zabbix 硬件监控：物理机监控覆盖率、当前告警数、网络设备健康度、存储健康度
• P1 — 统一日志与告警流水：以实时日志流形式展示关键系统事件（CMDB 同步、Zabbix 告警、VictoriaMetrics 抓取、ELK 日志接入、qpass 合并推送），类似运维公告板

---

2.2 配置与任务管理

任务中心与自动化执行

集中展现所有通过 xinfra 发起的 Ansible Playbook 任务或 Wayne 发布任务的执行历史，提供实时日志输出。

• P0 — 任务列表：任务状态（执行中/成功/失败）、任务名称、所用 playbook 名称或任务描述；执行中的任务高亮显示
• P0 — 实时日志：通过 WebSocket 流式输出 ansible-playbook 的执行日志，格式包含时间戳、TASK 名称和结果状态（ok/changed/failed），模拟终端输出效果，支持自动滚动
• P0 — 历史查询：任务列表支持分页，可查看过往所有任务的执行结果，便于审计和排障

---

2.3 基础服务与资源管理

集群与节点管理

管理全平台 RKE2 集群的生命周期及节点信息，支持新节点的自动加入。

• P0 — 集群列表：展示集群名称、所在机房/区域、健康状态、节点数、CPU 使用率（进度条）、RKE2 版本、Calico 配置（AS 号等）；对存在告警的集群高亮提醒
• P0 — 节点列表（集群内）：节点主机名、内网 IP、业务线标签（如 business-line=kodo）及对应 Taint、节点规格（CPU/内存）、CPU/Mem 使用率（进度条）、节点状态（Ready/资源告警/空闲）
• P0 — 节点加入向导：通过弹窗交互完成新节点加入——选择目标集群 → 输入节点 IP → 指定归属业务线（自动注入 node-label 和 taint）→ 提交后后台调用 roles/rke2-node-join playbook，完成内核参数初始化、containerd 安装、标签/污点写入、加入集群并等待 Ready

---

资源台账管理（CMDB 多云同步）

以 SINA CMDB 为基础数据底座，统一纳管物理机与虚机资源，并通过阿里云、AWS、七牛 LAS 的 OpenAPI 同步云上虚机，形成全量、唯一、可追溯的资源台账。

• P0 — 资源来源统计：资源总数（物理机 + 虚机），各来源（SINA CMDB、阿里云同步、AWS 同步、七牛 LAS 同步）的数量及最近一次同步状态
• P0 — 资源台账列表：主机名、资产编号、资源类型（物理机/虚机）、机房/区域、内网 IP、规格、归属业务线、数据来源标签、生命周期状态（production/idle/retired）
• P0 — 组合筛选：支持按资源类型、数据来源、业务线、状态等条件组合筛选，以及关键字搜索
• P0 — 同步与去重策略：各云平台定时增量同步，已存在记录跳过更新（保护 CMDB 人工维护字段），不存在则新增并标记来源
• P1 — 创建虚机入口：提供"+ 创建虚机"按钮，跳转或触发七牛 LAS 平台的虚机申请/创建流程（对接 LAS API）

---

服务目录管理（Consul 同步）

聚合各机房已有的 Consul 注册中心服务信息，提供跨机房的服务名、IP、业务标签、健康状态的统一检索视图，不改变各机房 Consul 自身的注册发现链路。

• P0 — 同步机制：定时调用各机房 Consul Catalog API（/v1/catalog/services、/v1/health/service），按 Datacenter 维度拉取全量服务并汇总入库。同步间隔采用差异化策略：国内机房（YZH/XS/JF）30 秒，海外机房（达拉斯/新加坡/香港/东南亚）根据网络延迟适当延长（建议 60-120 秒），具体间隔待实测后确定
• P0 — 服务台账：服务名、所在机房/Datacenter、业务标签、总实例数、健康实例数、示例 IP、整体健康状态
• P0 — 筛选与搜索：支持按机房、业务标签、健康状态筛选，以及服务名/IP 搜索
• P0 — 统计面板：接入 Consul Datacenter 数量、服务总数（去重）、服务实例总数、健康实例占比、最近同步状态

---

基础服务目录与一键部署

将标准化基础组件封装为服务卡片，用户通过界面选择参数，后台调用 Ansible Playbook 自动完成部署和子系统注册。

服务卡片规格：

服务	可配参数	部署后自动注册
MySQL	业务线、架构模式（一主两从/一主一从/单实例）、规格（CPU/内存/磁盘）、版本（8.0/5.7）、实例名称	open-cdm 数据源
Redis	业务线、架构模式（Cluster/Sentinel/Standalone）、规格（8G/16G 等）、版本（7.2）、实例名称	CacheCloud 应用创建 API
openresty	业务线、规格、路由规则	—
dpvs	业务线、规格、负载策略	—
PgSQL	业务线、架构模式（流复制主从）、规格、版本	open-cdm（二期）

• P0 — 服务卡片展示：每个基础组件以卡片形式展示，点击弹出多步骤向导（基础信息 → 规格网络 → 确认部署）
• P0 — 参数预览：底部实时预览生成的 playbook 调用参数（YAML 格式）
• P0 — 自动注册：部署完成后自动调用子系统 API 完成注册（MySQL → open-cdm，Redis → CacheCloud）
• P1 — 扩展性：预留"接入新服务"卡片，允许通过封装新的 Ansible Playbook 并注册到平台扩展服务目录

---

组件实例台账

提供所有已部署基础组件的统一台账，展示实例与子系统的关联关系，支持快速检索和运维管理。

• P0 — 列表信息：实例名、组件类型及版本、归属业务线、所在集群、运行状态、子系统注册状态（如 open-cdm ✓、CacheCloud ✓ 或同步中）
• P0 — 管理操作：提供"管理"快捷操作，可跳转至对应子系统或发起运维任务
• P0 — 分页与搜索：支持按实例名称、类型等过滤，分页能力

---

2.4 Phase 2 验收标准

• 资源大盘：页面加载后 3s 内展示全局指标数据；节点方格图能正确反映各业务线的资源分布
• 告警看板：告警数据与 Nightingale 实时同步，延迟 < 30s；支持按级别、来源、机房筛选告警
• 集群管理：集群列表数据实时刷新，告警集群高亮标识
• 节点加入：节点加入向导从提交到 Ready < 10 分钟
• CMDB 同步：同步后资源台账与各云平台实际资源一致，去重逻辑验证通过
• Consul 同步：7 个 Datacenter 全部接入；国内机房数据 30 秒内同步
• 基础服务部署：MySQL 一键部署单实例 < 5 分钟；Redis 一键部署 Standalone < 3 分钟
• 任务中心：执行中任务日志实时推送，延迟 < 1s
• 部署回滚：回滚操作可在 1 分钟内完成

---

Phase 3 — 运维增强

etcd 集群运维、高级监控、运维工具

3.1 etcd 集群运维

etcd 集群部署（kubeadm + etcd operator）

• P0 — 集群模板：支持按规格（3/5/7 节点）、磁盘类型（NVMe/SSD）、存储配额生成部署配置
• P0 — 部署流程：调用 kubeadm init / etcd-operator API，支持滚动部署和健康检查
• P1 — 故障恢复：检测到节点故障时自动替换，数据从健康节点同步
• P1 — 滚动升级：支持 etcd 版本升级，逐节点替换并验证
• P2 — 自动扩缩：根据集群负载自动调整节点数

---

3.2 高级监控

• P1 — 告警规则自定义：支持用户自定义监控告警规则
• P2 — 异常检测：基于历史数据的智能异常检测
• P2 — 容量预测：基于趋势预测资源使用峰值

---

3.3 运维工具

• P2 — 可视化拓扑：服务依赖关系可视化
• P1 — 批量操作：支持批量节点管理、批量配置下发
• P2 — 运维工作流：复杂运维操作的流程编排

---

3.4 Phase 3 验收标准

• etcd 部署：3 节点集群部署 < 15 分钟
• 故障恢复：节点故障后自动替换，数据不丢失
• 滚动升级：升级过程零停机
• 告警规则：用户可自定义告警规则并生效

---

非功能需求

性能

指标	要求
资源大盘加载	P95 < 3s
Wayne 页面操作响应	P95 < 2s
CloudDM SQL 审核预检	单条 SQL < 3s
CacheCloud 实例创建	Sentinel < 5min，Cluster < 10min
基础服务一键部署	MySQL/Redis < 15min
任务中心日志推送延迟	< 1s
CI/CD 流水线端到端（代码提交到部署完成）	< 10min（dev 环境）

可用性

指标	要求
平台核心服务（Wayne、CloudDM、CacheCloud）	SLA ≥ 99.9%
单集群控制面	SLA ≥ 99.95%
跨机房网络互联	SLA ≥ 99.99%
Apollo Config Service（单机房故障不影响其他机房）	本地缓存降级可用

多租户隔离

• 通过节点标签 + Taint + ResourceQuota 实现业务线间的资源强隔离和配额限制
• 同一业务线内通过 LimitRange 限制单 Pod 资源上限

安全

• 平台强制 LDAP 认证，所有子系统通过 SSO 统一入口
• 主系统登录事件与运维操作全程记录审计日志
• 敏感数据（Secret、密码）加密存储
• 生产环境禁止使用默认凭证
• RKE2 默认启用安全审计和加密
• 网络平面通过 BGP 和防火墙控制

高可用与容灾

• 每个机房独立 RKE2 集群和 Apollo Config Service，单机房故障不影响其他机房
• 配置下发依赖本地缓存降级
• 监控告警具备跨机房聚合能力

可观测性

• 各子系统暴露 Metrics 接口，接入 VictoriaMetrics + Grafana
• 关键操作日志统一收集到 ELK 日志平台
• 告警通道统一（Nightingale → qpass → 企业 IM）

可扩展性

• 基础服务目录支持通过封装新 Playbook 快速接入新组件
• 资源管理支持新增云平台同步源
• 服务管理可横向扩展至更多 Consul 数据中心
• 新机房接入时，RKE2 集群部署和 Wayne 注册可在 1 天内完成

实时性

• 任务日志通过 WebSocket 实时推送
• 监控指标和告警近实时更新
• 服务同步间隔 30 秒