vault backup: 2026-07-13 13:42:21
This commit is contained in:
+590
-219
@@ -7,25 +7,29 @@ create time: 2026-07-08 13:54
|
||||
|
||||
## 概述
|
||||
|
||||
XINFRA 是七牛云的统一基础设施平台，以**开源子系统集成 + 主系统统管**为核心架构，提供容器编排、数据库治理、缓存管理、CI/CD 自动化和资源开销管控等一站式能力。
|
||||
XINFRA 是面向多业务线、七机房混合云的统一基础设施管理平台，为 Kodo、LAS、灵矽、LTOKEN、MAAS 等业务线提供**容器资源调度、基础服务交付、资源台账、监控告警、配置管理**的一站式操作面。平台以 RKE2 集群为计算底座，通过 Calico BGP 构建扁平容器网络，向上整合 SINA CMDB、Consul、Apollo、Nightingale、CacheCloud 等已有系统，通过统一的 LDAP 认证和可视化界面，屏蔽底层多机房、多云差异，实现**统一纳管、标准化交付、自助使用**。
|
||||
|
||||
当前版本为 v3 一期，已覆盖国内华北（YZH）、华东（XS）、华南（JF）及阿里云华南共四个容器化机房和海外若干 IDC，后续将逐步扩展海外区域。
|
||||
|
||||
**核心目标**：
|
||||
|
||||
| # | 目标 | 说明 |
|
||||
|---|------|------|
|
||||
| 1 | 统一入口 | 所有基础设施操作收敛到平台化界面，降低命令行直接操作风险 |
|
||||
| 1 | 统一纳管 | 所有基础设施操作收敛到平台化界面，屏蔽多机房、多云差异，降低命令行直接操作风险 |
|
||||
| 2 | 多机房资源池化 | 七机房 RKE2 集群统一纳管，实现跨机房调度与服务发现 |
|
||||
| 3 | 安全合规 | 数据库操作全程审计、SQL 上线必须经过审核、WAF 防护常态化 |
|
||||
| 4 | 效率提升 | CI/CD 流水线自动触发部署，Ansible 实现基础设施即代码 |
|
||||
| 5 | 指标面板 | 按部门/项目/机房维度呈现资源开销 |
|
||||
| 3 | 标准化交付 | 基础组件（MySQL、Redis 等）通过服务卡片 + Ansible Playbook 实现一键标准化部署 |
|
||||
| 4 | 安全合规 | 主系统登录与运维操作全程审计、SQL 上线必须经过审核、LDAP 统一认证与 SSO |
|
||||
| 5 | 效率提升 | CD 自动化部署，Ansible 实现基础设施即代码，任务中心实时追踪 |
|
||||
| 6 | 可观测性 | 整合 Zabbix + VictoriaMetrics + Nightingale + qpass，资源大盘与监控告警全局可见 |
|
||||
|
||||
**设计原则**：
|
||||
|
||||
- **最小权限**：子系统操作默认走 RBAC，主系统以 LDAP 身份 + 管理员角色区分权限，APIKey 遵循最小授权范围
|
||||
- **审计留痕**：数据库变更、容器发布、权限申请等关键操作全程可追溯
|
||||
- **审计留痕**：主系统记录登录事件和运维操作日志，子系统各自维护操作审计
|
||||
- **机房就近**：服务部署和数据访问遵循机房就近原则，降低跨机房延迟
|
||||
- **平台化自治**：自助申请资源、自助发布、自助诊断，减少人工工单流转
|
||||
- **复用优先**：监控、告警等能力优先复用已有基础设施（Prometheus / Grafana），主系统只自建无法被替代的能力
|
||||
- **复用优先**：监控、告警等能力优先复用已有基础设施（VictoriaMetrics / Grafana / Zabbix / Nightingale），主系统只自建无法被替代的能力
|
||||
- **数据一致性**：资源同步采用"已存在跳过更新"策略，保护人工维护的资产数据，防止被云平台同步覆盖
|
||||
|
||||
---
|
||||
|
||||
@@ -35,9 +39,10 @@ XINFRA 是七牛云的统一基础设施平台，以**开源子系统集成 +
|
||||
|
||||
| 概念 | 定义 |
|
||||
|------|------|
|
||||
| 主系统 | XINFRA 平台自身的统管层，负责子系统无法覆盖的能力：统一门户（SSO 跳转入口）、审计日志聚合、资源指标面板、运维终端 |
|
||||
| 子系统 | XINFRA 纳管的专项平台（有独立 WebUI 和 API 服务），各司其职：**CloudDM**（数据库管理与 SQL 审核）、**Wayne**（多集群容器管理）、**CacheCloud**（Redis 缓存管理） |
|
||||
| 主系统 | XINFRA 平台自身的统管层，负责子系统无法覆盖的能力：统一门户（SSO 跳转入口）、资源大盘、登录审计与运维操作审计、资源指标面板、运维终端 |
|
||||
| 子系统 | XINFRA 纳管的专项平台（有独立 WebUI 和 API 服务），各司其职：**Wayne**（多集群容器管理）、**CloudDM / open-cdm**（数据库管理与 SQL 审核）、**CacheCloud**（Redis 缓存管理）、**Apollo**（配置中心）、**Nightingale**（统一告警引擎） |
|
||||
| 工具层 | 纳管的 CLI / IaC 工具，无常驻 WebUI，由运维人员通过命令行或脚本触发：**Ansible Playbook**（自动化部署与基础设施即代码） |
|
||||
| 业务线租户 | 基于 LDAP 组织信息自动生成的多租户隔离单元，每个业务线拥有独立的命名空间、节点池和资源配额 |
|
||||
|
||||
### 通用术语
|
||||
|
||||
@@ -45,132 +50,222 @@ XINFRA 是七牛云的统一基础设施平台，以**开源子系统集成 +
|
||||
|------|------|
|
||||
| APIKey | Wayne 平台对外提供的 API 认证密钥，用于 CI/CD 流水线等自动化场景的身份认证，遵循最小权限原则 |
|
||||
| RBAC | 基于角色的访问控制（Role-Based Access Control），通过角色分配权限，用户与角色关联实现权限隔离 |
|
||||
| RKE2 | Rancher 发行的轻量级 Kubernetes 发行版，专为生产环境设计，支持离线安装和安全加固 |
|
||||
| CI/CD | 持续集成/持续部署，自动化代码构建、测试和部署的流水线 |
|
||||
| RKE2 | Rancher 发行的 Kubernetes 发行版，已通过 CIS Benchmark 安全加固，支持离线 air-gap 安装，默认启用加密和审计 |
|
||||
| Calico BGP | Calico 采用纯路由模式（BGP），无隧道开销，每个集群配置独立 AS 号，构建跨机房扁平大二层网络 |
|
||||
| Ceph RBD | 分布式块存储，供给 K8s PV 给 MySQL、Redis 等有状态服务 |
|
||||
| Nightingale | 夜莺，统一告警聚合引擎，支持接入 Zabbix、VictoriaMetrics 等异构告警源，负责去重、收敛、分级，推送至 qpass |
|
||||
| Apollo | 携程开源配置中心，支持多机房 Cluster 部署、配置灰度、版本回滚和操作审计 |
|
||||
| Consul | 各机房已有的服务注册发现系统，xinfra 通过 Catalog API 做只读聚合展示 |
|
||||
| CD | 持续部署（Continuous Deployment），自动化服务上线的流水线；CI（持续集成）由团队已有 CI 系统负责 |
|
||||
| WAF | Web 应用防火墙（Web Application Firewall），防护 SQL 注入、XSS、CSRF 等常见 Web 攻击 |
|
||||
| SLA | 服务等级协议（Service Level Agreement），定义服务可用性的承诺指标，如 99.9% 可用率 |
|
||||
| SLA | 服务等级协议（Service Level Agreement），定义服务可用性的承诺指标 |
|
||||
| IaC | 基础设施即代码（Infrastructure as Code），通过 Ansible Playbook 等工具实现基础设施自动化管理 |
|
||||
| 运维分层 | 故障按层级自愈：子系统处理应用与中间件故障，主系统管理员通过 Ansible / SSH 兜底基础设施层故障，跨层操作需管理员权限 |
|
||||
| 统一认证 | 主系统和所有子系统共用企业 LDAP 做身份认证（SSO），主系统负责跳转入口，各子系统自行管理授权（RBAC） |
|
||||
| SINA CMDB | 公司内部 CMDB 系统，物理机与虚机资产数据的基础来源 |
|
||||
| open-cdm | SQL 审核与变更平台，数据库上线统一审核 |
|
||||
| qpass | 统一告警与值班通知平台 |
|
||||
| SSO | 单点登录（Single Sign-On），主系统通过 LDAP 统一认证后跳转至各子系统 |
|
||||
|
||||
---
|
||||
|
||||
## 平台架构总览
|
||||
## 平台分层架构
|
||||
|
||||
### 总体分层
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph 用户层
|
||||
Dev[开发人员]
|
||||
DBA[DBA]
|
||||
SRE[SRE / 运维]
|
||||
Sec[安全团队]
|
||||
User["用户层<br/>LDAP SSO 统一认证"] --> Main["主系统层<br/>统一门户 + 功能模块"]
|
||||
Main --> Sub["子系统层<br/>独立部署，各自授权"]
|
||||
Main --> Infra["基础设施层<br/>计算 · 网络 · 存储 · 自动化"]
|
||||
Sub --> Infra
|
||||
|
||||
style User fill:#f3e8fd,stroke:#9333ea
|
||||
style Main fill:#e0f2fe,stroke:#0284c7
|
||||
style Sub fill:#e8f0fe,stroke:#4285f4
|
||||
style Infra fill:#ecfdf5,stroke:#059669
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 主系统功能架构
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
Portal["统一门户<br/>LDAP SSO 跳转入口"]
|
||||
|
||||
subgraph 全局视图
|
||||
DashBoard["资源大盘<br/>集群拓扑 · 节点方格图"]
|
||||
MonitorView["资源状态看板<br/>物理机/虚机/服务三层告警"]
|
||||
end
|
||||
|
||||
subgraph 主系统["主系统（XINFRA 统管层）"]
|
||||
Portal["统一门户<br/>LDAP SSO 跳转入口"]
|
||||
AuditDash["审计面板<br/>聚合子系统审计日志"]
|
||||
CostBoard["资源指标面板<br/>自建机房开销归集"]
|
||||
subgraph 运维能力
|
||||
TaskCenter["任务中心<br/>Ansible/Wayne 实时日志"]
|
||||
OpsTerminal["运维终端<br/>Ansible / SSH<br/>仅管理员"]
|
||||
end
|
||||
|
||||
subgraph 子系统["子系统（独立部署，各自授权）"]
|
||||
Wayne["Wayne<br/>多集群容器管理"]
|
||||
CloudDM["CloudDM<br/>SQL 审核与数据库治理"]
|
||||
CacheCloud["CacheCloud<br/>Redis 缓存管理"]
|
||||
subgraph 治理能力
|
||||
AuditDash["审计面板<br/>登录记录 · 运维操作日志"]
|
||||
CMDB["资源台账<br/>CMDB 多云同步"]
|
||||
SvcDir["服务目录<br/>Consul 只读聚合"]
|
||||
end
|
||||
|
||||
subgraph 工具层
|
||||
Ansible["Ansible Playbook<br/>基础设施即代码"]
|
||||
end
|
||||
|
||||
subgraph 基础设施层["基础设施层（非平台开发范围）"]
|
||||
WAF["WAF / Ingress"]
|
||||
RKE2["RKE2 集群 × 7 机房"]
|
||||
Network["大内网互联"]
|
||||
end
|
||||
|
||||
subgraph 监控告警["监控告警（已有基础设施）"]
|
||||
Prometheus[("Prometheus")]
|
||||
Grafana["Grafana<br/>监控指标直接复用"]
|
||||
Alert["告警路由<br/>邮件 / 企业 IM"]
|
||||
end
|
||||
|
||||
subgraph 数据层
|
||||
MySQL[("MySQL")]
|
||||
PG[("PostgreSQL")]
|
||||
Oracle[("Oracle")]
|
||||
CH[("ClickHouse")]
|
||||
Redis[("Redis")]
|
||||
Harbor[("Harbor 镜像仓库")]
|
||||
end
|
||||
|
||||
%% 用户 → 主系统（LDAP SSO 跳转）
|
||||
Dev -->|LDAP SSO| Portal
|
||||
DBA -->|LDAP SSO| Portal
|
||||
SRE -->|LDAP SSO| Portal
|
||||
Sec -->|LDAP SSO| Portal
|
||||
|
||||
%% 主系统 → 子系统（跳转入口，不做用户映射）
|
||||
Portal -->|跳转| Wayne
|
||||
Portal -->|跳转| CloudDM
|
||||
Portal -->|跳转| CacheCloud
|
||||
SRE --> OpsTerminal
|
||||
|
||||
%% 子系统 → 主系统（审计上报）
|
||||
Wayne -.->|审计 Webhook| AuditDash
|
||||
CloudDM -.->|审计 Webhook| AuditDash
|
||||
CacheCloud -.->|审计 Webhook| AuditDash
|
||||
|
||||
%% 子系统 → 基础设施
|
||||
Wayne -->|Client-Go| RKE2
|
||||
CloudDM -->|SQL 审核| MySQL
|
||||
CacheCloud --> Agent["Agent 管理"] --> Redis
|
||||
|
||||
%% CI/CD 流水线
|
||||
GitLab["GitLab CI"] -->|镜像推送| Harbor
|
||||
GitLab -->|APIKey 触发部署| Wayne
|
||||
|
||||
%% 工具层
|
||||
Ansible -->|SSH| RKE2
|
||||
Ansible -->|SSH| MySQL
|
||||
Ansible -->|SSH| Redis
|
||||
OpsTerminal -->|兜底操作| RKE2
|
||||
|
||||
%% 基础设施层
|
||||
WAF --> RKE2
|
||||
RKE2 --> Network
|
||||
|
||||
%% 监控（子系统直连 Prometheus，Grafana 直接复用）
|
||||
Wayne -.->|Metrics| Prometheus
|
||||
CloudDM -.->|Metrics| Prometheus
|
||||
CacheCloud -.->|Metrics| Prometheus
|
||||
Prometheus --> Grafana
|
||||
Prometheus --> Alert
|
||||
|
||||
%% 资源指标面板
|
||||
Prometheus -->|节点/网络指标| CostBoard
|
||||
|
||||
classDef mainsys fill:#f3e8fd,stroke:#9333ea,stroke-width:2px
|
||||
classDef subsystem fill:#e8f0fe,stroke:#4285f4,stroke-width:2px
|
||||
classDef tool fill:#fef3c7,stroke:#d97706,stroke-width:2px
|
||||
classDef monitor fill:#fff7ed,stroke:#ea580c,stroke-width:2px
|
||||
classDef infra fill:#ecfdf5,stroke:#059669,stroke-width:2px
|
||||
classDef data fill:#fce7f3,stroke:#db2777,stroke-width:2px
|
||||
class Portal,AuditDash,CostBoard,OpsTerminal mainsys
|
||||
class Wayne,CloudDM,CacheCloud subsystem
|
||||
class Ansible tool
|
||||
class Prometheus,Grafana,Alert monitor
|
||||
class WAF,RKE2,Network infra
|
||||
class MySQL,PG,Oracle,CH,Redis,Harbor data
|
||||
Portal --> DashBoard & MonitorView & TaskCenter & AuditDash & CMDB & SvcDir
|
||||
SRE["SRE"] --> OpsTerminal
|
||||
```
|
||||
|
||||
> [!tip] 图例说明
|
||||
> - **紫色** = 主系统（统一门户、审计面板、资源指标面板、运维终端）
|
||||
> - **蓝色** = 子系统（Wayne、CloudDM、CacheCloud，各自独立部署和授权）
|
||||
> - **黄色** = 工具层（Ansible Playbook，CLI/IaC 脚本）
|
||||
> - **绿色** = 基础设施层（WAF、RKE2 集群、大内网，由基础设施团队维护，非平台开发范围）
|
||||
> - **橙色** = 监控告警（Prometheus + Grafana + Alertmanager，已有基础设施，直接复用）
|
||||
> - **粉色** = 数据层
|
||||
> [!tip] 主系统不替代子系统，只自建子系统无法覆盖的能力：全局视图、运维兜底、登录与运维审计、资源台账。
|
||||
|
||||
---
|
||||
|
||||
### 子系统集成关系
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
Portal["XINFRA 主系统"]
|
||||
|
||||
subgraph 子系统
|
||||
Wayne["Wayne<br/>多集群容器管理"]
|
||||
CloudDM["open-cdm<br/>SQL 审核"]
|
||||
CacheCloud["CacheCloud<br/>Redis 管理"]
|
||||
Apollo["Apollo<br/>配置中心"]
|
||||
end
|
||||
|
||||
Portal -.->|SSO 跳转| Wayne & CloudDM & CacheCloud & Apollo
|
||||
|
||||
Wayne -->|Client-Go| RKE2["RKE2 集群"]
|
||||
CloudDM -->|SQL 审核| MySQL[("MySQL")]
|
||||
CacheCloud -->|Agent| Redis[("Redis")]
|
||||
Apollo -->|ConfigService| RKE2
|
||||
```
|
||||
|
||||
> [!tip] 子系统各自独立部署和授权，主系统只做 SSO 跳转入口，各子系统自行维护操作审计。
|
||||
|
||||
---
|
||||
|
||||
### 基础设施层
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph 计算
|
||||
RKE2["RKE2 集群 × 7 机房<br/>CIS 安全加固"]
|
||||
end
|
||||
|
||||
subgraph 网络
|
||||
Calico["Calico BGP<br/>每集群独立 AS 号<br/>跨机房扁平互通"]
|
||||
end
|
||||
|
||||
subgraph 存储
|
||||
Ceph["Ceph RBD<br/>MySQL/Redis 有状态服务 PV"]
|
||||
end
|
||||
|
||||
subgraph 自动化
|
||||
Ansible["Ansible Playbook<br/>节点初始化 · 服务部署<br/>WebSocket 实时日志"]
|
||||
end
|
||||
|
||||
RKE2 --> Calico
|
||||
RKE2 --> Ceph
|
||||
Ansible -->|SSH| RKE2
|
||||
```
|
||||
|
||||
> [!tip] RKE2 是计算底座，Calico BGP 构建跨机房扁平网络，Ceph RBD 提供有状态服务的持久化存储，Ansible 贯穿自动化运维。
|
||||
|
||||
---
|
||||
|
||||
## 监控告警数据流
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph 采集源
|
||||
RKE2["RKE2 集群"]
|
||||
Zabbix["Zabbix<br/>硬件监控"]
|
||||
end
|
||||
|
||||
subgraph 指标存储
|
||||
VM[("VictoriaMetrics<br/>容器/业务指标")]
|
||||
end
|
||||
|
||||
subgraph 可视化
|
||||
Grafana["Grafana 仪表盘"]
|
||||
end
|
||||
|
||||
subgraph 告警链路
|
||||
Nightingale["夜莺<br/>去重 · 收敛 · 分级"]
|
||||
QPass["qpass<br/>企业 IM 推送"]
|
||||
end
|
||||
|
||||
RKE2 -.->|Metrics| VM
|
||||
VM --> Grafana
|
||||
VM --> Nightingale
|
||||
Zabbix --> Nightingale
|
||||
Nightingale --> QPass
|
||||
```
|
||||
|
||||
> [!tip] VictoriaMetrics 承载容器和业务指标，Zabbix 覆盖物理机硬件监控，夜莺作为统一告警聚合层，最终推送至 qpass 通知。
|
||||
|
||||
---
|
||||
|
||||
## 技术选型与架构决策
|
||||
|
||||
| 层级 | 选型 | 说明 |
|
||||
|------|------|------|
|
||||
| **前端框架** | Vue 3 + Element Plus | 企业级 UI 方案，与七牛内部技术栈一致 |
|
||||
| **后端框架** | Go + Gin | 高性能 HTTP 框架，与 Wayne/Open-CDM 生态一致 |
|
||||
| **前后端通信** | 混合模式 | 前端 REST/JSON，服务间 gRPC；API 版本管理采用 URL 路径版本 `/api/v1/...` |
|
||||
| **主系统数据库** | MySQL 8.0 | 存储任务记录、审计日志、资源台账、用户会话等 |
|
||||
| **缓存** | Redis | 分布式缓存和会话存储 |
|
||||
| **前端部署** | Nginx | 托管前端静态文件 + 反向代理后端 API |
|
||||
| **主系统部署** | K8s 内部署 | 以 Deployment 方式运行在 RKE2 集群内 |
|
||||
| **SSO 协议** | SAML | 企业统一认证，主系统做 SSO 跳转入口 |
|
||||
| **告警数据源** | 仅 Nightingale API | 主系统不直接对接 Zabbix/VictoriaMetrics，统一通过夜莺获取告警数据 |
|
||||
| **Ansible 调度** | AWX | 通过 AWX API 提交 Playbook 任务，由 AWX 管理执行和日志 |
|
||||
| **实时推送** | 原生 WebSocket | 任务日志实时推送，基于 gorilla/websocket 库 |
|
||||
| **接口文档** | Swagger/OpenAPI | 后端生成 Swagger 文档供前端开发 |
|
||||
| **界面语言** | 纯中文 | 不需要国际化 |
|
||||
| **测试策略** | 后端测试为主 | 单元测试 + 集成测试 |
|
||||
|
||||
---
|
||||
|
||||
## 基础服务交付流程
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor User as 业务人员
|
||||
participant Portal as XINFRA 服务目录
|
||||
participant Ansible as Ansible Playbook
|
||||
participant Infra as RKE2 / 主机
|
||||
participant Sub as 子系统注册
|
||||
|
||||
User->>Portal: 选择服务卡片（MySQL/Redis/...）<br/>填写业务线、规格、架构模式
|
||||
Portal->>Portal: 实时预览 playbook 参数（YAML）
|
||||
User->>Portal: 确认部署
|
||||
Portal->>Ansible: 提交 playbook 任务
|
||||
Ansible->>Infra: 内核初始化 · containerd · 加入集群
|
||||
Ansible-->>Portal: 任务状态 → WebSocket 实时日志
|
||||
Portal->>Sub: 自动注册（open-cdm / CacheCloud）
|
||||
Portal-->>User: 部署完成，跳转任务中心
|
||||
```
|
||||
|
||||
> [!tip] 用户通过服务卡片填参 → 后台 Ansible 自动化部署 → 部署完成后自动注册到对应子系统，全程任务日志可在任务中心实时查看。
|
||||
|
||||
---
|
||||
|
||||
## 多租户隔离模型
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
LDAP["企业 LDAP"] -->|部门 DN| BL["业务线租户<br/>（Kodo / LAS / 灵矽 / ...）"]
|
||||
|
||||
BL --> NS["Kubernetes Namespace<br/>+ ResourceQuota + LimitRange"]
|
||||
BL --> NP["物理节点池<br/>node-label + taint"]
|
||||
|
||||
NS -.->|Pod 只能调度到<br/>本业务线节点| NP
|
||||
|
||||
style LDAP fill:#f3e8fd,stroke:#9333ea
|
||||
style BL fill:#e0f2fe,stroke:#0284c7
|
||||
style NS fill:#ecfdf5,stroke:#059669
|
||||
style NP fill:#fef3c7,stroke:#d97706
|
||||
```
|
||||
|
||||
> [!tip] 双重隔离：**节点层**通过 `business-line=xxx` 标签 + Taint 确保 Pod 只调度到本业务线节点；**命名空间层**通过 ResourceQuota / LimitRange 限制资源用量上限。
|
||||
|
||||
---
|
||||
|
||||
@@ -178,49 +273,280 @@ graph TB
|
||||
|
||||
| 角色 | 职责 | 平台交互模块 |
|
||||
|------|------|-------------|
|
||||
| 开发人员 | 编写代码、提交发布、申请数据库/缓存资源 | Wayne、CI/CD、CloudDM、CacheCloud |
|
||||
| DBA | SQL 审核、数据库性能优化、容量规划 | CloudDM |
|
||||
| SRE / 运维 | 集群维护、自动化部署、故障响应 | Wayne、Ansible、RKE2 |
|
||||
| 开发人员 | 编写代码、提交发布、申请数据库/缓存资源 | Wayne、CD、CloudDM、CacheCloud |
|
||||
| DBA | SQL 审核、数据库性能优化、容量规划 | CloudDM / open-cdm |
|
||||
| SRE / 运维 | 集群维护、自动化部署、故障响应 | Wayne、Ansible、RKE2、任务中心 |
|
||||
| 业务负责人 | 查看本业务线资源使用情况、告警状态 | 资源大盘、资源状态看板、多租户管理 |
|
||||
| 平台管理员 | 账号权限管理、资源配置、平台运维、节点纳管 | 全模块管理后台、集群管理、运维终端 |
|
||||
| 安全团队 | WAF 策略制定、安全审计、合规检查 | WAF、审计面板 |
|
||||
| 平台管理员 | 账号权限管理、资源配置、平台运维 | 全模块管理后台、审计面板 |
|
||||
|
||||
---
|
||||
|
||||
## 功能需求
|
||||
|
||||
### FR-1 容器编排与多集群管理（RKE2 + Wayne）
|
||||
### FR-1 资源大盘
|
||||
|
||||
> 为平台管理员及业务负责人提供跨机房、多云容器资源的全局快照与健康视图。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-1.1 | 展示核心指标：RKE2 集群数量、在线机房数、节点总数及近期增量、CPU 总核数/已分配/分配率、组件实例总数及分类（MySQL、Redis、其他）、进行中的自动化任务数量 | P0 |
|
||||
| FR-1.2 | 集群拓扑：以机房为维度，显示各机房节点池方格图（node grid），每个方格代表一台物理机/节点，颜色区分业务线（Kodo、LAS 等），空闲节点用虚线框表示 | P0 |
|
||||
| FR-1.3 | 最近任务：列表展示最近 5 条 ansible-playbook 任务的执行状态（成功/执行中/失败）和耗时，快速跳转至任务中心 | P0 |
|
||||
| FR-1.4 | 刷新机制：页面自动显示"最近更新于 xx 秒前"，支持手动刷新 | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- 页面加载后 3s 内展示全局指标数据
|
||||
- 节点方格图能正确反映各业务线的资源分布
|
||||
- 最近任务状态与任务中心实时同步
|
||||
|
||||
---
|
||||
|
||||
### FR-2 资源状态看板与告警
|
||||
|
||||
> 整合物理机、虚机、基础服务三层的健康状态，通过夜莺（Nightingale）统一告警引擎将多源告警标准化展示，提供自上而下的故障定位入口。
|
||||
|
||||
**数据源**：
|
||||
- 物理机硬件 & 网络设备健康：Zabbix（IPMI/温度/电源/风扇/存储）
|
||||
- 虚机 & 容器 & 业务层指标：VictoriaMetrics（K8s/主机指标/服务可用性探活）
|
||||
- Nightingale 作为统一告警聚合层，负责去重、收敛、分级（P0/P1/…），按 disaster/high/average 等原始级别映射，推送至 qpass 告警通道
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-2.1 | 核心统计：物理机总数、虚机总数、基础组件实例总数；P0(Disaster)、P1(High) 及 average 级别告警数量，标注来自 Zabbix 或 VictoriaMetrics | P0 |
|
||||
| FR-2.2 | 物理机状态：按机房汇总在线数、健康率（带进度条），标识正常/告警/严重状态 | P0 |
|
||||
| FR-2.3 | 虚机状态：按业务线展示 LAS 资源池中的虚机数、CPU 均值及告警状态 | P0 |
|
||||
| FR-2.4 | 基础服务状态：覆盖 MySQL、Redis（CacheCloud）、PostgreSQL、openresty 网关等，显示实例数、异常数、可用率 | P0 |
|
||||
| FR-2.5 | 当前告警详情：表格列出所有 P0/P1 及 average 级别的实时告警，含级别标签、来源、原始级别、目标对象、告警内容、发生时间 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 告警数据与 Nightingale 实时同步，延迟 < 30s
|
||||
- 支持按级别、来源、机房筛选告警
|
||||
- 点击告警可跳转至对应子系统或 Nightingale 详情页
|
||||
|
||||
---
|
||||
|
||||
### FR-3 集群与节点管理
|
||||
|
||||
> 管理全平台 RKE2 集群的生命周期及节点信息，支持新节点的自动加入。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-3.1 | 集群列表：展示集群名称、所在机房/区域、健康状态、节点数、CPU 使用率（进度条）、RKE2 版本、Calico 配置（AS 号等）；对存在告警的集群高亮提醒 | P0 |
|
||||
| FR-3.2 | 节点列表（集群内）：节点主机名、内网 IP、业务线标签（如 `business-line=kodo`）及对应 Taint、节点规格（CPU/内存）、CPU/Mem 使用率（进度条）、节点状态（Ready/资源告警/空闲） | P0 |
|
||||
| FR-3.3 | 节点加入向导：通过弹窗交互完成新节点加入——选择目标集群 → 输入节点 IP → 指定归属业务线（自动注入 node-label 和 taint）→ 提交后后台调用 `roles/rke2-node-join` playbook，完成内核参数初始化、containerd 安装、标签/污点写入、加入集群并等待 Ready | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 集群列表数据实时刷新，告警集群高亮标识
|
||||
- 节点加入向导从提交到 Ready < 10 分钟
|
||||
- 节点标签和 Taint 信息与 kubectl 输出一致
|
||||
|
||||
---
|
||||
|
||||
### FR-4 多租户业务线管理
|
||||
|
||||
> 基于 LDAP 组织信息自动生成业务线租户，为每个业务线分配独立的命名空间和资源配额，结合节点亲和性与 ResourceQuota 实现双重隔离。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-4.1 | 业务线列表：业务线标识/名称、对应的 LDAP 部门 DN、归属的物理节点数、CPU 总配额及已用比例（进度条）、绑定的 Kubernetes 命名空间、负责人信息 | P0 |
|
||||
| FR-4.2 | 隔离策略：通过节点标签（`business-line=xxx`）配合 NodeAffinity 和 Taint，确保 Pod 只能调度到本业务线的物理节点上 | P0 |
|
||||
| FR-4.3 | 配额管理：在命名空间内施加 ResourceQuota / LimitRange，避免单一业务线无限占用资源 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 新业务线可在平台自助创建，自动完成 Namespace + 标签 + Taint + ResourceQuota 配置
|
||||
- 跨业务线 Pod 调度隔离验证通过
|
||||
- 配额超限告警正常触发
|
||||
|
||||
---
|
||||
|
||||
### FR-5 资源台账管理（CMDB 多云同步）
|
||||
|
||||
> 以 SINA CMDB 为基础数据底座，统一纳管物理机与虚机资源，并通过阿里云、AWS、七牛 LAS 的 OpenAPI 同步云上虚机，形成全量、唯一、可追溯的资源台账。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-5.1 | 资源来源统计：资源总数（物理机 + 虚机），各来源（SINA CMDB、阿里云同步、AWS 同步、七牛 LAS 同步）的数量及最近一次同步状态 | P0 |
|
||||
| FR-5.2 | 资源台账列表：主机名、资产编号、资源类型（物理机/虚机）、机房/区域、内网 IP、规格、归属业务线、数据来源标签、生命周期状态（production/idle/retired） | P0 |
|
||||
| FR-5.3 | 组合筛选：支持按资源类型、数据来源、业务线、状态等条件组合筛选，以及关键字搜索 | P0 |
|
||||
| FR-5.4 | 同步与去重策略：各云平台定时增量同步，已存在记录跳过更新（保护 CMDB 人工维护字段），不存在则新增并标记来源 | P0 |
|
||||
| FR-5.5 | 创建虚机入口：提供"+ 创建虚机"按钮，跳转或触发七牛 LAS 平台的虚机申请/创建流程（对接 LAS API） | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- 同步后资源台账与各云平台实际资源一致，去重逻辑验证通过
|
||||
- 支持多条件组合筛选，搜索响应 < 1s
|
||||
- 人工在 CMDB 侧修改的字段不被同步覆盖
|
||||
|
||||
---
|
||||
|
||||
### FR-6 服务目录管理（Consul 同步）
|
||||
|
||||
> 聚合各机房已有的 Consul 注册中心服务信息，提供跨机房的服务名、IP、业务标签、健康状态的统一检索视图，不改变各机房 Consul 自身的注册发现链路。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-6.1 | 同步机制：定时调用各机房 Consul Catalog API（`/v1/catalog/services`、`/v1/health/service`），按 Datacenter 维度拉取全量服务并汇总入库。同步间隔采用差异化策略：国内机房（YZH/XS/JF）30 秒，海外机房（达拉斯/新加坡/香港/东南亚）根据网络延迟适当延长（建议 60-120 秒），具体间隔待实测后确定 | P0 |
|
||||
| FR-6.2 | 服务台账：服务名、所在机房/Datacenter、业务标签、总实例数、健康实例数、示例 IP、整体健康状态 | P0 |
|
||||
| FR-6.3 | 筛选与搜索：支持按机房、业务标签、健康状态筛选，以及服务名/IP 搜索 | P0 |
|
||||
| FR-6.4 | 统计面板：接入 Consul Datacenter 数量、服务总数（去重）、服务实例总数、健康实例占比、最近同步状态 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 7 个 Datacenter（国内 3 + 海外 4）全部接入
|
||||
- 国内机房数据 30 秒内同步，海外机房同步延迟 < 120 秒（具体待实测确定）
|
||||
- 不影响各机房 Consul 自身注册发现链路（只读聚合）
|
||||
- 健康状态与 Consul Health API 一致
|
||||
|
||||
---
|
||||
|
||||
### FR-7 基础服务目录与一键部署
|
||||
|
||||
> 将标准化基础组件封装为服务卡片，用户通过界面选择参数，后台调用 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（二期） |
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-7.1 | 服务卡片展示：每个基础组件以卡片形式展示，点击弹出多步骤向导（基础信息 → 规格网络 → 确认部署） | P0 |
|
||||
| FR-7.2 | 参数预览：底部实时预览生成的 playbook 调用参数（YAML 格式） | P0 |
|
||||
| FR-7.3 | 自动注册：部署完成后自动调用子系统 API 完成注册（MySQL → open-cdm，Redis → CacheCloud） | P0 |
|
||||
| FR-7.4 | 扩展性：预留"接入新服务"卡片，允许通过封装新的 Ansible Playbook 并注册到平台扩展服务目录 | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- MySQL 一键部署：单实例 < 5 分钟，一主一从 < 10 分钟，一主两从 < 15 分钟
|
||||
- Redis 一键部署：Standalone < 3 分钟，Sentinel < 5 分钟，Cluster < 10 分钟
|
||||
- 部署后自动注册到对应子系统，状态可查
|
||||
- PgSQL 二期正式接入并集成 open-cdm SQL 审核
|
||||
|
||||
---
|
||||
|
||||
### FR-8 组件实例台账
|
||||
|
||||
> 提供所有已部署基础组件的统一台账，展示实例与子系统的关联关系，支持快速检索和运维管理。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-8.1 | 列表信息：实例名、组件类型及版本、归属业务线、所在集群、运行状态、子系统注册状态（如 `open-cdm ✓`、`CacheCloud ✓` 或同步中） | P0 |
|
||||
| FR-8.2 | 管理操作：提供"管理"快捷操作，可跳转至对应子系统或发起运维任务 | P0 |
|
||||
| FR-8.3 | 分页与搜索：支持按实例名称、类型等过滤，分页能力 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 实例状态与实际部署一致，子系统注册状态实时更新
|
||||
- 点击"管理"可正确跳转至对应子系统
|
||||
|
||||
---
|
||||
|
||||
### FR-9 任务中心与自动化执行
|
||||
|
||||
> 集中展现所有通过 xinfra 发起的 Ansible Playbook 任务或 Wayne 发布任务的执行历史，提供实时日志输出。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-9.1 | 任务列表：任务状态（执行中/成功/失败）、任务名称、所用 playbook 名称或任务描述；执行中的任务高亮显示 | P0 |
|
||||
| FR-9.2 | 实时日志：通过 WebSocket 流式输出 ansible-playbook 的执行日志，格式包含时间戳、TASK 名称和结果状态（ok/changed/failed），模拟终端输出效果，支持自动滚动 | P0 |
|
||||
| FR-9.3 | 历史查询：任务列表支持分页，可查看过往所有任务的执行结果，便于审计和排障 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 执行中任务日志实时推送，延迟 < 1s
|
||||
- 日志格式清晰可读，支持终端式滚动
|
||||
- 历史任务可按时间/状态/名称筛选
|
||||
|
||||
---
|
||||
|
||||
### FR-10 配置中心管理（Apollo）
|
||||
|
||||
> 对 Apollo 配置中心进行统一接入和管理，实现在单一 Portal 管理所有机房的配置，确保配置的灰度发布、回滚与变更审计。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-10.1 | 核心指标展示：已接入机房数、Apollo Cluster 数量、配置项总数、Namespace 数、接入业务线及同步状态 | P0 |
|
||||
| FR-10.2 | 统一入口：提供 Apollo Portal 快捷入口（内部域名 `apollo.xinfra.internal`），LDAP SSO 单点登录 | P0 |
|
||||
| FR-10.3 | 机房列表：展示每个机房的 Apollo Cluster、Config Service 地址、承载方式（容器化 K8s Service）、接入业务线和配置项数、运行状态（运行中/灰度接入/建设中/待启动） | P0 |
|
||||
|
||||
**部署架构约束**：
|
||||
- Portal + Admin Service：YZH 主中心统一部署
|
||||
- Config Service：按机房独立部署（yzh/xs/jf/dallas 等），容器化运行在 K8s 内
|
||||
- 数据同步：ConfigDB/PortalDB 部署在 YZH，各机房 Config Service 本地缓存全量配置，网络抖动时降级提供本地缓存
|
||||
|
||||
**验收标准**：
|
||||
- YZH、XS 机房正式运行，JF 灰度接入
|
||||
- 配置变更支持灰度发布和一键回滚
|
||||
- 海外机房（达拉斯、新加坡、香港、东南亚）按三期规划陆续建设
|
||||
|
||||
---
|
||||
|
||||
### FR-11 监控、日志与告警集成
|
||||
|
||||
> 集成公司现有监控与日志基础设施的状态和主要入口，方便从平台直接掌握各子系统健康度。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-11.1 | VictoriaMetrics 指标概览：展示七机房采集节点数、活跃时序数量、Prometheus 接口状态、已建 Grafana 仪表盘数 | P0 |
|
||||
| FR-11.2 | Zabbix 硬件监控：物理机监控覆盖率、当前告警数、网络设备健康度、存储健康度 | P0 |
|
||||
| FR-11.3 | 统一日志与告警流水：以实时日志流形式展示关键系统事件（CMDB 同步、Zabbix 告警、VictoriaMetrics 抓取、ELK 日志接入、qpass 合并推送），类似运维公告板 | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- 监控数据与各子系统实时同步
|
||||
- 告警流水可按时间、类型筛选
|
||||
- Grafana 仪表盘快捷入口可直接跳转
|
||||
|
||||
---
|
||||
|
||||
### FR-12 统一子系统导航
|
||||
|
||||
> 作为所有相关子系统的单一入口门户，利用 LDAP 统一账号实现 SSO，用户无需记忆多个地址和重复认证。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-12.1 | 已集成系统卡片展示：系统图标、名称、简要说明及 LDAP/SSO 接入状态（已接入/改造中），预留打开链接 | P0 |
|
||||
| FR-12.2 | 已集成系统包括：Wayne、open-cdm、CacheCloud、qpass、Grafana、Apollo | P0 |
|
||||
| FR-12.3 | SSO 跳转：点击卡片通过 LDAP SSO 跳转至对应子系统，无需重复登录 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 所有已集成系统卡片正确展示，SSO 跳转正常
|
||||
- 未接入系统标注"改造中"状态
|
||||
|
||||
---
|
||||
|
||||
### FR-13 容器编排与多集群管理（RKE2 + Wayne）
|
||||
|
||||
> 底层基于 RKE2 构建七机房 K8s 集群，上层通过 Wayne 平台提供统一的容器管理入口。
|
||||
|
||||
**目标**：开发人员通过 Wayne UI 或 API 完成服务部署，无需直接操作 kubectl。
|
||||
|
||||
#### FR-1.1 RKE2 集群（基础设施依赖）
|
||||
#### FR-13.1 RKE2 集群（基础设施依赖）
|
||||
|
||||
RKE2 集群部署和配置由基础设施团队负责，平台开发团队只需确保 Wayne 能通过 Client-Go 连接各集群。核心约束：
|
||||
|
||||
| 约束项 | 说明 |
|
||||
|--------|------|
|
||||
| CNI 插件 | Canal（Calico + Flannel） |
|
||||
| CNI 插件 | Calico BGP（每集群独立 AS 号） |
|
||||
| 容器运行时 | containerd（不依赖 Docker） |
|
||||
| 离线部署 | 支持 Air-gap 环境 |
|
||||
| 集群规模 | 七机房各一套独立集群 |
|
||||
| 安全加固 | 已通过 CIS Benchmark，默认启用加密和审计 |
|
||||
|
||||
> [!info] 详细部署规范（cluster-cidr、service-cidr、节点注册模式、Systemd 服务管理等）参见运维 SOP 文档，此处不展开。
|
||||
|
||||
#### FR-1.2 Wayne 多集群管理
|
||||
#### FR-13.2 Wayne 多集群管理
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-1.2.1 | 支持多集群统一管理，通过 Client-Go 连接各机房 RKE2 集群 | P0 |
|
||||
| FR-1.2.2 | RBAC 权限管理，部门角色与项目角色分离（Project → Environment → Namespace 三级结构） | P0 |
|
||||
| FR-1.2.3 | 提供表单式（基础模式）和 YAML/JSON 编辑（高级模式）两种 K8s 对象创建方式 | P0 |
|
||||
| FR-1.2.4 | 发布历史记录与一键回滚能力 | P0 |
|
||||
| FR-1.2.5 | 完整审计模块，每次操作留痕，支持自定义 Webhook 回调；审计数据上报主系统审计面板 | P0 |
|
||||
| FR-1.2.6 | Web Shell 远程终端（基于权限校验的 Pod Exec） | P1 |
|
||||
| FR-1.2.7 | 资源报表（资源使用占比、上线频次图表） | P1 |
|
||||
| FR-1.2.8 | APIKey 开放接口，支持 CI/CD 流水线调用 | P0 |
|
||||
| FR-1.2.9 | 认证支持 DB 内置 + LDAP 混合模式 | P0 |
|
||||
| FR-1.2.10 | YAML 模板版本锁定，纳入代码仓库管理 | P1 |
|
||||
| FR-13.2.1 | 支持多集群统一管理，通过 Client-Go 连接各机房 RKE2 集群 | P0 |
|
||||
| FR-13.2.2 | RBAC 权限管理，部门角色与项目角色分离（Project → Environment → Namespace 三级结构） | P0 |
|
||||
| FR-13.2.3 | 提供表单式（基础模式）和 YAML/JSON 编辑（高级模式）两种 K8s 对象创建方式 | P0 |
|
||||
| FR-13.2.4 | 发布历史记录与一键回滚能力 | P0 |
|
||||
| FR-13.2.5 | 完整审计模块，每次操作留痕，支持自定义 Webhook 回调 | P0 |
|
||||
| FR-13.2.6 | Web Shell 远程终端（基于权限校验的 Pod Exec） | P1 |
|
||||
| FR-13.2.7 | 资源报表（资源使用占比、上线频次图表） | P1 |
|
||||
| FR-13.2.8 | APIKey 开放接口，支持 CI/CD 流水线调用 | P0 |
|
||||
| FR-13.2.9 | 认证支持 DB 内置 + LDAP 混合模式 | P0 |
|
||||
| FR-13.2.10 | YAML 模板版本锁定，纳入代码仓库管理 | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- 开发人员可在 Wayne 中选择目标集群完成服务部署
|
||||
@@ -230,49 +556,49 @@ RKE2 集群部署和配置由基础设施团队负责，平台开发团队只需
|
||||
|
||||
---
|
||||
|
||||
### FR-2 数据库管理与 SQL 审核（CloudDM）
|
||||
### FR-14 数据库管理与 SQL 审核（CloudDM / open-cdm）
|
||||
|
||||
> 基于 ClouGence 开源的 CloudDM，覆盖数据查询、权限管控、SQL 审核、数据脱敏的全链路能力。
|
||||
> 覆盖数据查询、权限管控、SQL 审核、数据脱敏的全链路能力。
|
||||
|
||||
**目标**：所有生产库 SQL 操作必须经过 CloudDM 工单流程，无直连通道。
|
||||
**目标**：所有生产库 SQL 操作必须经过工单流程，无直连通道。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-2.1 | 支持 Console + Sidecar 集群部署模式，保证高可用 | P0 |
|
||||
| FR-2.2 | 支持 20+ 数据源类型（MySQL、Oracle、PG、ClickHouse、Redis、MongoDB 等） | P0 |
|
||||
| FR-2.3 | 内置 54 条 SQL 审核规则，支持规则脚本自定义扩展 | P0 |
|
||||
| FR-2.4 | SQL 上线工单流程：编写 → 预检 → DBA 审核 → 执行，支持手动/立即/定时三种执行方式 | P0 |
|
||||
| FR-2.5 | 权限控制：资源权限（实例/库/Schema/表粒度）+ 功能权限（RBAC），支持申请/赋予/临时权限 | P0 |
|
||||
| FR-2.6 | 数据脱敏能力，对查询结果中的敏感字段进行隐藏或转换 | P1 |
|
||||
| FR-2.7 | 数据库 CI/CD：支持 Git Push / WebHook / HttpCall 三种触发方式 | P1 |
|
||||
| FR-2.8 | 统一认证：对接企业 LDAP | P0 |
|
||||
| FR-2.9 | 全程审计留痕，工单流转记录可追溯；审计数据上报主系统审计面板 | P0 |
|
||||
| FR-14.1 | 支持 Console + Sidecar 集群部署模式，保证高可用 | P0 |
|
||||
| FR-14.2 | 支持 20+ 数据源类型（MySQL、Oracle、PG、ClickHouse、Redis、MongoDB 等） | P0 |
|
||||
| FR-14.3 | 内置 54 条 SQL 审核规则，支持规则脚本自定义扩展 | P0 |
|
||||
| FR-14.4 | SQL 上线工单流程：编写 → 预检 → DBA 审核 → 执行，支持手动/立即/定时三种执行方式 | P0 |
|
||||
| FR-14.5 | 权限控制：资源权限（实例/库/Schema/表粒度）+ 功能权限（RBAC），支持申请/赋予/临时权限 | P0 |
|
||||
| FR-14.6 | 数据脱敏能力，对查询结果中的敏感字段进行隐藏或转换 | P1 |
|
||||
| FR-14.7 | 数据库 CI/CD：支持 Git Push / WebHook / HttpCall 三种触发方式 | P1 |
|
||||
| FR-14.8 | 统一认证：对接企业 LDAP | P0 |
|
||||
| FR-14.9 | 全程审计留痕，工单流转记录可追溯 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 所有生产库 SQL 操作必须经 CloudDM 工单流程，无直连通道
|
||||
- 所有生产库 SQL 操作必须经工单流程，无直连通道
|
||||
- 审核规则可按需配置白名单豁免
|
||||
- 生产部署已替换默认 JWT 密钥和管理员密码
|
||||
- Console 多实例部署，单实例故障不影响服务可用性
|
||||
|
||||
---
|
||||
|
||||
### FR-3 缓存管理（CacheCloud）
|
||||
### FR-15 缓存管理（CacheCloud）
|
||||
|
||||
> 基于搜狐开源的 CacheCloud，支持 Standalone、Sentinel、Cluster 三种 Redis 架构的一站式管理。
|
||||
> 支持 Standalone、Sentinel、Cluster 三种 Redis 架构的一站式管理。
|
||||
|
||||
**目标**：所有 Redis 场景通过 CacheCloud 统一实例申请和管理，降低大规模 Redis 运维成本。
|
||||
**目标**：所有 Redis 场景通过 CacheCloud 统一实例申请和管理。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-3.1 | 支持三种 Redis 架构：Standalone（测试）、Sentinel（生产常规，内存 ≤ 6GB）、Cluster（大数据量，内存 > 6GB） | P0 |
|
||||
| FR-3.2 | Agent 代理部署在每个宿主机上，管理 Redis 实例生命周期 | P0 |
|
||||
| FR-3.3 | 接入层 Nginx 双机房部署 + Virtual IP 双向漂移，保证高可用 | P0 |
|
||||
| FR-3.4 | 客户端接入支持 REST API（通用）、Java Jedis/Lettuce SDK、Python 接入 | P0 |
|
||||
| FR-3.5 | 跨机房部署（Cross-Room）：支持双活，客户端 SDK 自动双写双读和机房切换 | P1 |
|
||||
| FR-3.6 | 运维能力：全局统计、工单审批、应用运维、实例运维、数据迁移 | P0 |
|
||||
| FR-3.7 | 诊断工具：慢查询分析、连接数诊断、Bigkey 检测 | P1 |
|
||||
| FR-3.8 | 报警组件：支持邮件、微信、HTTP 接口集成；告警事件同步至主系统审计面板 | P0 |
|
||||
| FR-3.9 | 临时实例自动回收策略，防止资源浪费 | P1 |
|
||||
| FR-15.1 | 支持三种 Redis 架构：Standalone（测试）、Sentinel（生产常规，内存 ≤ 6GB）、Cluster（大数据量，内存 > 6GB） | P0 |
|
||||
| FR-15.2 | Agent 代理部署在每个宿主机上，管理 Redis 实例生命周期 | P0 |
|
||||
| FR-15.3 | 接入层 Nginx 双机房部署 + Virtual IP 双向漂移，保证高可用 | P0 |
|
||||
| FR-15.4 | 客户端接入支持 REST API（通用）、Java Jedis/Lettuce SDK、Python 接入 | P0 |
|
||||
| FR-15.5 | 跨机房部署（Cross-Room）：支持双活，客户端 SDK 自动双写双读和机房切换 | P1 |
|
||||
| FR-15.6 | 运维能力：全局统计、工单审批、应用运维、实例运维、数据迁移 | P0 |
|
||||
| FR-15.7 | 诊断工具：慢查询分析、连接数诊断、Bigkey 检测 | P1 |
|
||||
| FR-15.8 | 报警组件：支持邮件、微信、HTTP 接口集成 | P0 |
|
||||
| FR-15.9 | 临时实例自动回收策略，防止资源浪费 | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- 三种 Redis 架构均可正常创建和访问
|
||||
@@ -281,69 +607,43 @@ RKE2 集群部署和配置由基础设施团队负责，平台开发团队只需
|
||||
|
||||
---
|
||||
|
||||
### FR-4 CI/CD 流水线
|
||||
### FR-16 CD 自动化部署
|
||||
|
||||
> 基于 GitLab CI，实现代码提交到服务上线的全自动化。
|
||||
> 通过 API 接口触发 Wayne 平台执行自动化部署，CI 部分由团队已有 CI 系统负责。
|
||||
|
||||
**目标**：CI 编译 → 镜像推送 → 触发 Wayne API 部署，全流程自动化。
|
||||
**目标**：提供 CD 部署接口，供外部 CI 系统调用触发部署。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-4.1 | CI 阶段：代码编译、单元测试、镜像构建并推送到 Harbor 镜像仓库 | P0 |
|
||||
| FR-4.2 | CD 阶段：CI 成功后自动调用 Wayne API，传入镜像 tag 触发部署 | P0 |
|
||||
| FR-4.3 | 部署支持多环境（dev / staging / prod），生产环境需审批卡点 | P0 |
|
||||
| FR-4.4 | 部署失败时支持自动回滚到上一个稳定版本 | P1 |
|
||||
| FR-16.1 | 提供 REST API 接口，供外部 CI 系统调用触发 Wayne 部署，传入镜像 tag 和目标环境 | P0 |
|
||||
| FR-16.2 | 部署支持多环境（dev / staging / prod），生产环境需审批卡点 | P0 |
|
||||
| FR-16.3 | 部署失败时支持自动回滚到上一个稳定版本 | P1 |
|
||||
| FR-16.4 | 部署状态回调：支持 Webhook 回调通知外部 CI 系统部署结果 | P1 |
|
||||
|
||||
**验收标准**：
|
||||
- 代码提交后 10 分钟内完成 dev 环境自动部署
|
||||
- 外部 CI 系统可通过 API 触发 Wayne 部署
|
||||
- prod 环境部署必须经过审批
|
||||
- 部署失败自动回滚，回滚时间 < 2 分钟
|
||||
|
||||
> [!info] 流水线执行状态和日志查看直接复用 GitLab CI 原生 Pipeline 页面，平台不自建查看界面。
|
||||
> [!info] CI 编译构建由团队已有 CI 系统负责，本平台仅提供 CD 部署接口。
|
||||
|
||||
---
|
||||
|
||||
### FR-5 资源指标面板
|
||||
### FR-17 审计面板（主系统）
|
||||
|
||||
> 按部门、项目、机房维度归集和呈现自建机房的资源开销。
|
||||
|
||||
**目标**：管理层和团队负责人可按维度查看自建机房资源开销，识别闲置资源。
|
||||
> 记录主系统自身的登录事件和运维操作日志，不聚合子系统操作审计。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-5.1 | 按部门 / 项目 / 机房三个维度聚合展示资源开销，支持下钻到具体资源粒度 | P0 |
|
||||
| FR-5.2 | 数据源：Prometheus 节点指标 + SNMP 网络指标，按 Namespace → Project → Department 路径归属 | P0 |
|
||||
| FR-5.3 | 支持月度/季度资源开销趋势对比 | P1 |
|
||||
| FR-5.4 | 资源闲置告警，识别利用率过低的资源 | P2 |
|
||||
| FR-17.1 | 登录审计：记录每次 LDAP SSO 登录事件（操作人、时间、来源 IP、目标子系统），支持按时间/操作人/子系统筛选查询 | P0 |
|
||||
| FR-17.2 | 运维操作审计：记录主系统运维终端的操作（Ansible Playbook 执行、节点加入、配置变更等），支持按时间/操作人/操作类型筛选 | P0 |
|
||||
| FR-17.3 | 安全事件面板：异常登录检测、敏感操作告警 | P1 |
|
||||
| FR-17.4 | 权限控制：管理员角色可查看全局；普通用户仅查看自身登录记录 | P0 |
|
||||
| FR-17.5 | 审计面板集成到主系统统一门户，无需独立部署 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 数据延迟 < 24 小时
|
||||
- 支持按维度下钻到具体资源粒度
|
||||
|
||||
> [!tip] 多云厂商（AWS、阿里云、腾讯云等）账单接入推至后续迭代，初期聚焦自建机房。
|
||||
|
||||
---
|
||||
|
||||
### FR-6 审计面板（主系统）
|
||||
|
||||
> 聚合各子系统的审计日志到主系统，提供统一查询入口，减少跨系统跳转。
|
||||
|
||||
**目标**：管理员和安全团队在主系统即可查看全平台审计记录，无需逐个进入子系统。
|
||||
|
||||
> [!info] 监控指标（集群状态、Pod 异常数、Redis 健康度等）直接在 Grafana 中查看，主系统不做二次聚合。
|
||||
|
||||
| 编号 | 需求描述 | 优先级 |
|
||||
|------|---------|--------|
|
||||
| FR-6.1 | 聚合子系统审计日志（Wayne 操作审计、CloudDM 工单审计、CacheCloud 操作审计），支持按时间/操作人/子系统/操作类型筛选查询 | P0 |
|
||||
| FR-6.2 | 安全事件面板：WAF 拦截事件聚合、异常登录检测、敏感操作告警 | P1 |
|
||||
| FR-6.3 | 统一告警概览：汇总各子系统告警，按严重级别（Critical / Warning / Info）分组展示 | P1 |
|
||||
| FR-6.4 | 数据源接入规范：子系统通过 HTTP Webhook 上报审计日志 | P0 |
|
||||
| FR-6.5 | 权限控制：管理员角色可查看全局；普通用户仅查看所属项目/部门范围内的审计数据 | P0 |
|
||||
| FR-6.6 | 审计面板集成到主系统统一门户，无需独立部署 | P0 |
|
||||
|
||||
**验收标准**：
|
||||
- 子系统审计日志实时上报，查询延迟 < 5s
|
||||
- 普通用户只能看到自身权限范围内的数据，无越权
|
||||
- 登录事件和运维操作实时记录，查询延迟 < 5s
|
||||
- 普通用户只能看到自身登录记录，无越权
|
||||
- 审计面板可从统一门户直接访问
|
||||
|
||||
---
|
||||
@@ -370,6 +670,16 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
|
||||
七机房之间的网络互通由网络团队负责搭建和维护。核心 SLA：同城机房间 Pod 通信延迟 < 2ms，跨机房服务调用成功率 > 99.99%。
|
||||
|
||||
### 监控告警基础设施
|
||||
|
||||
| 组件 | 职责 | 维护方 |
|
||||
|------|------|--------|
|
||||
| VictoriaMetrics | 容器/业务指标时序存储，七机房 128 节点、42.6M 活跃时序 | 基础设施团队 |
|
||||
| Zabbix | 物理机硬件监控（IPMI/温度/电源/风扇/存储） | 基础设施团队 |
|
||||
| Nightingale（夜莺） | 统一告警聚合引擎，接入 VM + Zabbix，去重/收敛/分级，推送至 qpass | 基础设施团队 |
|
||||
| Grafana | 指标可视化，对接 VictoriaMetrics | 基础设施团队 |
|
||||
| ELK | 日志收集（Filebeat → Kafka → Elasticsearch → Kibana） | 基础设施团队 |
|
||||
|
||||
---
|
||||
|
||||
## 非功能需求
|
||||
@@ -378,9 +688,12 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
|
||||
| 指标 | 要求 |
|
||||
|------|------|
|
||||
| 资源大盘加载 | P95 < 3s |
|
||||
| Wayne 页面操作响应 | P95 < 2s |
|
||||
| CloudDM SQL 审核预检 | 单条 SQL < 3s |
|
||||
| CacheCloud 实例创建 | Sentinel < 5min，Cluster < 10min |
|
||||
| 基础服务一键部署 | MySQL/Redis < 15min |
|
||||
| 任务中心日志推送延迟 | < 1s |
|
||||
| CI/CD 流水线端到端（代码提交到部署完成） | < 10min（dev 环境） |
|
||||
|
||||
### 可用性
|
||||
@@ -390,24 +703,46 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
| 平台核心服务（Wayne、CloudDM、CacheCloud） | SLA ≥ 99.9% |
|
||||
| 单集群控制面 | SLA ≥ 99.95% |
|
||||
| 跨机房网络互联 | SLA ≥ 99.99% |
|
||||
| Apollo Config Service（单机房故障不影响其他机房） | 本地缓存降级可用 |
|
||||
|
||||
### 多租户隔离
|
||||
|
||||
- 通过节点标签 + Taint + ResourceQuota 实现业务线间的资源强隔离和配额限制
|
||||
- 同一业务线内通过 LimitRange 限制单 Pod 资源上限
|
||||
|
||||
### 安全
|
||||
|
||||
- 子系统操作经过 RBAC 权限校验，主系统以 LDAP 身份 + 管理员角色区分权限
|
||||
- 数据库操作全程审计留痕
|
||||
- 平台强制 LDAP 认证，所有子系统通过 SSO 统一入口
|
||||
- 主系统登录事件与运维操作全程记录审计日志
|
||||
- 敏感数据（Secret、密码）加密存储
|
||||
- 生产环境禁止使用默认凭证
|
||||
- RKE2 默认启用安全审计和加密
|
||||
- 网络平面通过 BGP 和防火墙控制
|
||||
|
||||
### 高可用与容灾
|
||||
|
||||
- 每个机房独立 RKE2 集群和 Apollo Config Service，单机房故障不影响其他机房
|
||||
- 配置下发依赖本地缓存降级
|
||||
- 监控告警具备跨机房聚合能力
|
||||
|
||||
### 可观测性
|
||||
|
||||
- 各子系统暴露 Metrics 接口，接入 Prometheus + Grafana
|
||||
- 关键操作日志统一收集到日志平台
|
||||
- 告警通道统一（邮件 + 企业 IM）
|
||||
- 各子系统暴露 Metrics 接口，接入 VictoriaMetrics + Grafana
|
||||
- 关键操作日志统一收集到 ELK 日志平台
|
||||
- 告警通道统一（Nightingale → qpass → 企业 IM）
|
||||
|
||||
### 可扩展性
|
||||
|
||||
- 基础服务目录支持通过封装新 Playbook 快速接入新组件
|
||||
- 资源管理支持新增云平台同步源
|
||||
- 服务管理可横向扩展至更多 Consul 数据中心
|
||||
- 新机房接入时，RKE2 集群部署和 Wayne 注册可在 1 天内完成
|
||||
- CloudDM / CacheCloud 支持水平扩展（Console + 多 Sidecar）
|
||||
|
||||
### 实时性
|
||||
|
||||
- 任务日志通过 WebSocket 实时推送
|
||||
- 监控指标和告警近实时更新
|
||||
- 服务同步间隔 30 秒
|
||||
|
||||
---
|
||||
|
||||
@@ -418,16 +753,23 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
| 源 | 目标 | 接口方式 | 说明 |
|
||||
|----|------|---------|------|
|
||||
| 企业 LDAP | 各子系统 + 主系统 | LDAP Bind / SSO | 统一身份认证，主系统做 SSO 跳转入口 |
|
||||
| SINA CMDB | 资源台账 | REST API | 物理机/虚机基础数据来源 |
|
||||
| 阿里云 / AWS / 七牛 LAS | 资源台账 | OpenAPI | 云上虚机增量同步 |
|
||||
| Consul × 7 DC | 服务目录 | Catalog API | 只读聚合，不改变原有链路 |
|
||||
| Nightingale | 资源状态看板 | API | 统一告警数据源 |
|
||||
| Zabbix | Nightingale | 告警接入 | 硬件监控告警 |
|
||||
| VictoriaMetrics | Nightingale | 告警接入 | 容器/业务指标告警 |
|
||||
| GitLab CI | Wayne | REST API（APIKey 认证） | 自动触发部署 |
|
||||
| GitLab CI | Harbor | Docker Push | 镜像推送 |
|
||||
| Wayne | RKE2 | Client-Go（K8s API） | 容器编排操作 |
|
||||
| CloudDM | MySQL | Sidecar SQL 代理 | SQL 审核执行 |
|
||||
| CloudDM / open-cdm | MySQL / PG 等 | Sidecar SQL 代理 | SQL 审核执行 |
|
||||
| CacheCloud | Redis | Agent | 实例生命周期管理 |
|
||||
| Apollo | 各业务线 | Config Service API | 配置下发与灰度发布 |
|
||||
| Ansible | 各主机 | SSH | 基础设施初始化部署 |
|
||||
| 各子系统 | 审计面板 | HTTP Webhook | 审计日志统一归集 |
|
||||
| 各子系统 + 基础设施 | Prometheus | HTTP / Exporter | Metrics 采集 |
|
||||
| Prometheus | Grafana | PromQL | 监控指标可视化（直接复用） |
|
||||
| Prometheus | 告警路由 | Alertmanager | 统一告警（邮件 / 企业 IM） |
|
||||
| 企业 LDAP | 主系统 | LDAP Bind | 登录事件记录至审计面板 |
|
||||
| 各子系统 + 基础设施 | VictoriaMetrics | HTTP / Exporter | Metrics 采集 |
|
||||
| VictoriaMetrics | Grafana | PromQL | 监控指标可视化（直接复用） |
|
||||
| Nightingale | qpass | 告警推送 | 统一告警通知 |
|
||||
|
||||
---
|
||||
|
||||
@@ -437,9 +779,12 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
|------|------|---------|
|
||||
| RKE2 版本升级可能引入不兼容变更 | 集群稳定性 | 先在测试环境验证，灰度发布 |
|
||||
| Wayne 开源版本维护活跃度不确定 | 功能迭代受限 | 内部 Fork 并保持核心模块可维护 |
|
||||
| 七机房网络链路故障 | 跨机房服务中断 | 网络冗余 + 自动切换 + 告警监控 |
|
||||
| 七机房网络链路故障 | 跨机房服务中断 | 网络冗余 + BGP 自动切换 + 告警监控 |
|
||||
| SQL 审核规则误判 | 合法 SQL 被拦截 | 白名单机制 + 规则持续调优 |
|
||||
| Redis 大 Key / 热 Key | 性能劣化 | CacheCloud 诊断工具 + 应用侧治理 |
|
||||
| Apollo 多机房配置一致性 | 配置下发错误 | 本地缓存降级 + 灰度发布验证 |
|
||||
| Consul 跨机房同步延迟 | 服务发现不一致 | 30 秒轮询 + 健康状态标注 |
|
||||
| 云平台 API 限流/不可用 | 资源同步中断 | 增量同步 + 重试机制 + 状态告警 |
|
||||
|
||||
---
|
||||
|
||||
@@ -451,6 +796,7 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
|---------|--------|--------|---------|
|
||||
| 应用发布异常 | 子系统自愈 | Wayne 一键回滚 | 项目成员 |
|
||||
| 中间件故障 | 子系统自恢复 | CacheCloud / CloudDM 内置运维能力 | 子系统运维角色 |
|
||||
| 配置变更异常 | Apollo 回滚 | Apollo 版本回滚 + 灰度发布 | 配置管理员 |
|
||||
| 基础设施故障 | 主系统管理员 | Ansible Playbook / SSH 终端 | 仅主系统管理员 |
|
||||
| 机房级故障 | 主系统管理员 | Ansible + 大内网链路切换 | 仅主系统管理员 |
|
||||
|
||||
@@ -459,6 +805,31 @@ WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTT
|
||||
|
||||
---
|
||||
|
||||
## 一期范围与后续规划
|
||||
|
||||
### 一期已实现
|
||||
|
||||
- 国内三大自建机房 + 阿里云华南共 4 个 RKE2 集群的纳管
|
||||
- 物理机、虚机资源台账（CMDB + 阿里云/AWS/七牛 LAS 同步）
|
||||
- 基础服务交付：MySQL、Redis、openresty、dpvs 一键部署
|
||||
- Consul 服务目录同步与查看
|
||||
- Apollo 配置中心 YZH、XS 两机房正式运行，JF 灰度接入
|
||||
- 监控告警整合 Zabbix + VictoriaMetrics + Nightingale + qpass
|
||||
- 任务中心实时日志
|
||||
- 系统导航面板与 LDAP 单点登录
|
||||
|
||||
### 后续规划（二期/三期）
|
||||
|
||||
- PgSQL 服务正式接入基础服务目录，并集成 open-cdm SQL 审核
|
||||
- 海外机房（达拉斯、新加坡、香港、东南亚）Apollo Config Service 建设
|
||||
- CacheCloud LDAP 接入改造完成
|
||||
- 更多业务线（灵矽、LTOKEN、MAAS）全面接入 Apollo 配置中心
|
||||
- 服务拓扑与依赖可视化（增强可观测性）
|
||||
- 告警自愈能力探索：部分 P1 告警联动 Ansible Playbook 自动处理
|
||||
- 成本分析：各业务线资源使用费用归集与报表
|
||||
|
||||
---
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[technical/xinfra-preview]]
|
||||
|
||||
Reference in New Issue
Block a user