--- tags: [xinfra, requirements, infra] create time: 2026-07-08 13:54 --- # XINFRA 平台需求文档 ## 概述 XINFRA 是面向多业务线、七机房混合云的统一基础设施管理平台，为 Kodo、LAS、灵矽、LTOKEN、MAAS 等业务线提供**容器资源调度、基础服务交付、资源台账、监控告警、配置管理**的一站式操作面。平台以 RKE2 集群为计算底座，通过 Calico BGP 构建扁平容器网络，向上整合 SINA CMDB、Consul、Apollo、Nightingale、CacheCloud 等已有系统，通过统一的 LDAP 认证和可视化界面，屏蔽底层多机房、多云差异，实现**统一纳管、标准化交付、自助使用**。 当前版本为 v3 一期，已覆盖国内华北（YZH）、华东（XS）、华南（JF）及阿里云华南共四个容器化机房和海外若干 IDC，后续将逐步扩展海外区域。 **核心目标**： | # | 目标 | 说明 | |---|------|------| | 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），主系统只自建无法被替代的能力 - **数据一致性**：资源同步采用"已存在跳过更新"策略，保护人工维护的资产数据，防止被云平台同步覆盖 --- ## 核心概念 ### 组内约定 | 概念 | 定义 | |------|------| | 主系统 | XINFRA 平台自身的统管层，负责子系统无法覆盖的能力：统一门户（SSO 跳转入口）、资源大盘、登录审计与运维操作审计、资源指标面板、运维终端 | | 子系统 | XINFRA 纳管的专项平台（有独立 WebUI 和 API 服务），各司其职：**Wayne**（多集群容器管理）、**CloudDM / open-cdm**（数据库管理与 SQL 审核）、**CacheCloud**（Redis 缓存管理）、**Apollo**（配置中心）、**Nightingale**（统一告警引擎） | | 工具层 | 纳管的 CLI / IaC 工具，无常驻 WebUI，由运维人员通过命令行或脚本触发：**Ansible Playbook**（自动化部署与基础设施即代码） | | 业务线租户 | 基于 LDAP 组织信息自动生成的多租户隔离单元，每个业务线拥有独立的命名空间、节点池和资源配额 | ### 通用术语 | 概念 | 定义 | |------|------| | APIKey | Wayne 平台对外提供的 API 认证密钥，用于 CI/CD 流水线等自动化场景的身份认证，遵循最小权限原则 | | RBAC | 基于角色的访问控制（Role-Based Access Control），通过角色分配权限，用户与角色关联实现权限隔离 | | 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），定义服务可用性的承诺指标 | | IaC | 基础设施即代码（Infrastructure as Code），通过 Ansible Playbook 等工具实现基础设施自动化管理 | | SINA CMDB | 公司内部 CMDB 系统，物理机与虚机资产数据的基础来源 | | open-cdm | SQL 审核与变更平台，数据库上线统一审核 | | qpass | 统一告警与值班通知平台 | | SSO | 单点登录（Single Sign-On），主系统通过 LDAP 统一认证后跳转至各子系统 | --- ## 平台分层架构 ### 总体分层 ```mermaid graph TB User["用户层
LDAP SSO 统一认证"] --> Main["主系统层
统一门户 + 功能模块"] Main --> Sub["子系统层
独立部署，各自授权"] Main --> Infra["基础设施层
计算 · 网络 · 存储 · 自动化"] 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["统一门户
LDAP SSO 跳转入口"] subgraph 全局视图 DashBoard["资源大盘
集群拓扑 · 节点方格图"] MonitorView["资源状态看板
物理机/虚机/服务三层告警"] end subgraph 运维能力 TaskCenter["任务中心
Ansible/Wayne 实时日志"] OpsTerminal["运维终端
Ansible / SSH
仅管理员"] end subgraph 治理能力 AuditDash["审计面板
登录记录 · 运维操作日志"] CMDB["资源台账
CMDB 多云同步"] SvcDir["服务目录
Consul 只读聚合"] end Portal --> DashBoard & MonitorView & TaskCenter & AuditDash & CMDB & SvcDir SRE["SRE"] --> OpsTerminal ``` > [!tip] 主系统不替代子系统，只自建子系统无法覆盖的能力：全局视图、运维兜底、登录与运维审计、资源台账。 --- ### 子系统集成关系 ```mermaid graph LR Portal["XINFRA 主系统"] subgraph 子系统 Wayne["Wayne
多集群容器管理"] CloudDM["open-cdm
SQL 审核"] CacheCloud["CacheCloud
Redis 管理"] Apollo["Apollo
配置中心"] 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 机房
CIS 安全加固"] end subgraph 网络 Calico["Calico BGP
每集群独立 AS 号
跨机房扁平互通"] end subgraph 存储 Ceph["Ceph RBD
MySQL/Redis 有状态服务 PV"] end subgraph 自动化 Ansible["Ansible Playbook
节点初始化 · 服务部署
WebSocket 实时日志"] end RKE2 --> Calico RKE2 --> Ceph Ansible -->|SSH| RKE2 ``` > [!tip] RKE2 是计算底座，Calico BGP 构建跨机房扁平网络，Ceph RBD 提供有状态服务的持久化存储，Ansible 贯穿自动化运维。 --- ## 监控告警数据流 ```mermaid graph LR subgraph 采集源 RKE2["RKE2 集群"] Zabbix["Zabbix
硬件监控"] end subgraph 指标存储 VM[("VictoriaMetrics
容器/业务指标")] end subgraph 可视化 Grafana["Grafana 仪表盘"] end subgraph 告警链路 Nightingale["夜莺
去重 · 收敛 · 分级"] QPass["qpass
企业 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/...）
填写业务线、规格、架构模式 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["业务线租户
（Kodo / LAS / 灵矽 / ...）"] BL --> NS["Kubernetes Namespace
+ ResourceQuota + LimitRange"] BL --> NP["物理节点池
node-label + taint"] NS -.->|Pod 只能调度到
本业务线节点| 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 限制资源用量上限。 --- ## 干系人与角色 | 角色 | 职责 | 平台交互模块 | |------|------|-------------| | 开发人员 | 编写代码、提交发布、申请数据库/缓存资源 | Wayne、CD、CloudDM、CacheCloud | | DBA | SQL 审核、数据库性能优化、容量规划 | CloudDM / open-cdm | | SRE / 运维 | 集群维护、自动化部署、故障响应 | Wayne、Ansible、RKE2、任务中心 | | 业务负责人 | 查看本业务线资源使用情况、告警状态 | 资源大盘、资源状态看板、多租户管理 | | 平台管理员 | 账号权限管理、资源配置、平台运维、节点纳管 | 全模块管理后台、集群管理、运维终端 | | 安全团队 | WAF 策略制定、安全审计、合规检查 | WAF、审计面板 | --- ## 功能需求 ### 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-13.1 RKE2 集群（基础设施依赖） RKE2 集群部署和配置由基础设施团队负责，平台开发团队只需确保 Wayne 能通过 Client-Go 连接各集群。核心约束： | 约束项 | 说明 | |--------|------| | CNI 插件 | Calico BGP（每集群独立 AS 号） | | 容器运行时 | containerd（不依赖 Docker） | | 离线部署 | 支持 Air-gap 环境 | | 集群规模 | 七机房各一套独立集群 | | 安全加固 | 已通过 CIS Benchmark，默认启用加密和审计 | #### FR-13.2 Wayne 多集群管理 | 编号 | 需求描述 | 优先级 | |------|---------|--------| | 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 中选择目标集群完成服务部署 - 每次部署操作有完整审计日志 - CI/CD 流水线可通过 APIKey 调用 Wayne API 触发部署 - 回滚操作可在 1 分钟内完成 --- ### FR-14 数据库管理与 SQL 审核（CloudDM / open-cdm） > 覆盖数据查询、权限管控、SQL 审核、数据脱敏的全链路能力。 **目标**：所有生产库 SQL 操作必须经过工单流程，无直连通道。 | 编号 | 需求描述 | 优先级 | |------|---------|--------| | 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 操作必须经工单流程，无直连通道 - 审核规则可按需配置白名单豁免 - 生产部署已替换默认 JWT 密钥和管理员密码 - Console 多实例部署，单实例故障不影响服务可用性 --- ### FR-15 缓存管理（CacheCloud） > 支持 Standalone、Sentinel、Cluster 三种 Redis 架构的一站式管理。 **目标**：所有 Redis 场景通过 CacheCloud 统一实例申请和管理。 | 编号 | 需求描述 | 优先级 | |------|---------|--------| | 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 架构均可正常创建和访问 - Agent 心跳正常，实例生命周期管理（启停、备份恢复）功能可用 - 跨机房双活场景下故障切换时间 < 30s --- ### FR-16 CD 自动化部署 > 通过 API 接口触发 Wayne 平台执行自动化部署，CI 部分由团队已有 CI 系统负责。 **目标**：提供 CD 部署接口，供外部 CI 系统调用触发部署。 | 编号 | 需求描述 | 优先级 | |------|---------|--------| | 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 | **验收标准**： - 外部 CI 系统可通过 API 触发 Wayne 部署 - prod 环境部署必须经过审批 - 部署失败自动回滚，回滚时间 < 2 分钟 > [!info] CI 编译构建由团队已有 CI 系统负责，本平台仅提供 CD 部署接口。 --- ### FR-17 审计面板（主系统） > 记录主系统自身的登录事件和运维操作日志，不聚合子系统操作审计。 | 编号 | 需求描述 | 优先级 | |------|---------|--------| | 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 | **验收标准**： - 登录事件和运维操作实时记录，查询延迟 < 5s - 普通用户只能看到自身登录记录，无越权 - 审计面板可从统一门户直接访问 --- ## 基础设施依赖（非平台开发范围） 以下模块由基础设施团队负责，XINFRA 平台在此基础上构建。平台开发团队需了解其约束，但不负责实施。 ### 自动化部署（Ansible Playbook） 通过 Ansible Playbook 实现 MySQL、PostgreSQL、Redis Cluster 等中间件的自动化部署。核心要求： - Playbook 纳入 Git 版本管理，变更可追溯 - 使用 Ansible 模块保证幂等性 - Inventory 按环境分层管理（dev / test / prod） > [!info] 详细 Playbook 编写规范（Dry Run、Jinja2 模板等）参见运维 SOP 文档。 ### 安全防护（WAF） WAF 作为基础设施层的安全防护入口，覆盖所有对外暴露的 HTTP/HTTPS 入口。安全事件实时告警，支持与企业 IM 集成。安全日志可查询和分析，支持审计追溯。 ### 大内网互联 七机房之间的网络互通由网络团队负责搭建和维护。核心 SLA：同城机房间 Pod 通信延迟 < 2ms，跨机房服务调用成功率 > 99.99%。 ### 监控告警基础设施 | 组件 | 职责 | 维护方 | |------|------|--------| | VictoriaMetrics | 容器/业务指标时序存储，七机房 128 节点、42.6M 活跃时序 | 基础设施团队 | | Zabbix | 物理机硬件监控（IPMI/温度/电源/风扇/存储） | 基础设施团队 | | Nightingale（夜莺） | 统一告警聚合引擎，接入 VM + Zabbix，去重/收敛/分级，推送至 qpass | 基础设施团队 | | Grafana | 指标可视化，对接 VictoriaMetrics | 基础设施团队 | | ELK | 日志收集（Filebeat → Kafka → Elasticsearch → Kibana） | 基础设施团队 | --- ## 非功能需求 ### 性能 | 指标 | 要求 | |------|------| | 资源大盘加载 | 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 秒 --- ## 系统集成关系 **关键集成点**： | 源 | 目标 | 接口方式 | 说明 | |----|------|---------|------| | 企业 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 / open-cdm | MySQL / PG 等 | Sidecar SQL 代理 | SQL 审核执行 | | CacheCloud | Redis | Agent | 实例生命周期管理 | | Apollo | 各业务线 | Config Service API | 配置下发与灰度发布 | | Ansible | 各主机 | SSH | 基础设施初始化部署 | | 企业 LDAP | 主系统 | LDAP Bind | 登录事件记录至审计面板 | | 各子系统 + 基础设施 | VictoriaMetrics | HTTP / Exporter | Metrics 采集 | | VictoriaMetrics | Grafana | PromQL | 监控指标可视化（直接复用） | | Nightingale | qpass | 告警推送 | 统一告警通知 | --- ## 风险与约束 | 风险 | 影响 | 缓解措施 | |------|------|---------| | RKE2 版本升级可能引入不兼容变更 | 集群稳定性 | 先在测试环境验证，灰度发布 | | Wayne 开源版本维护活跃度不确定 | 功能迭代受限 | 内部 Fork 并保持核心模块可维护 | | 七机房网络链路故障 | 跨机房服务中断 | 网络冗余 + BGP 自动切换 + 告警监控 | | SQL 审核规则误判 | 合法 SQL 被拦截 | 白名单机制 + 规则持续调优 | | Redis 大 Key / 热 Key | 性能劣化 | CacheCloud 诊断工具 + 应用侧治理 | | Apollo 多机房配置一致性 | 配置下发错误 | 本地缓存降级 + 灰度发布验证 | | Consul 跨机房同步延迟 | 服务发现不一致 | 30 秒轮询 + 健康状态标注 | | 云平台 API 限流/不可用 | 资源同步中断 | 增量同步 + 重试机制 + 状态告警 | --- ## 运维分层模型 > 故障按层级自愈，跨层操作需主系统管理员权限。 | 故障层级 | 处理方 | 工具链 | 权限要求 | |---------|--------|--------|---------| | 应用发布异常 | 子系统自愈 | Wayne 一键回滚 | 项目成员 | | 中间件故障 | 子系统自恢复 | CacheCloud / CloudDM 内置运维能力 | 子系统运维角色 | | 配置变更异常 | Apollo 回滚 | Apollo 版本回滚 + 灰度发布 | 配置管理员 | | 基础设施故障 | 主系统管理员 | Ansible Playbook / SSH 终端 | 仅主系统管理员 | | 机房级故障 | 主系统管理员 | Ansible + 大内网链路切换 | 仅主系统管理员 | > [!warning] 安全约束 > Ansible / SSH 终端等基础设施级操作仅对主系统管理员角色可见，普通用户菜单中不包含此项。所有跨层操作全程审计留痕。 --- ## 一期范围与后续规划 ### 一期已实现 - 国内三大自建机房 + 阿里云华南共 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]] - [[technical/xinfra-preview/k8s-rke2-fundamentals]] - [[technical/xinfra-preview/wayne-overview]] - [[technical/xinfra-preview/cloud-dm-overview]] - [[technical/xinfra-preview/cachecloud-overview]] - [[technical/xinfra-preview/ansible-playbook-basics]]