资产拓扑与关联关系

在现代企业 IT 基础设施中，配置资产绝非孤立存在。从底层的机房机柜、网络交换机、物理宿主机，到上层的虚拟机、容器集群、中间件及微服务应用，资产之间存在紧密的承载与依赖关系。

ECMDB 通过图拓扑关联引擎将离散资产打通，提供三层拓扑契约约束与双向递归穿透能力，构建出清晰严谨的配置关系网络。

---

1. 三层拓扑契约体系

为了防止拓扑关系无序膨胀或产生无业务语义的脏连线，ECMDB 将关系建模自顶向下划分为三层抽象契约：

┌──────────────────────────────────────────────────────────┐
│ 1. 语义层：关联类型                                      │
│    定义关系语义与双向描述 (如 run: 运行于 / 运行)              │
└────────────────────────────┬─────────────────────────────┘
                             │ 绑定
┌────────────────────────────▼─────────────────────────────┐
│ 2. 规则层：模型拓扑规则                                  │
│    约束允许建立连接的模型与映射基数 (如 虚拟机 -> 宿主机, 多对一) │
└────────────────────────────┬─────────────────────────────┘
                             │ 准入预检与一致性校验
┌────────────────────────────▼─────────────────────────────┐
│ 3. 实例层：资产实例连线                                  │
│    记录资产实体间的真实拓扑边 (如 某虚拟机 -> 某物理机)          │
└──────────────────────────────────────────────────────────┘

1.1 语义层：关联类型

关联类型用于赋予拓扑连接明确的方向含义与展示文案。

注入与维护机制：

• 系统数据库层面保持轻量纯粹，默认不写死私有业务类型；
• 关联类型支持通过控制台按需创建，或随业务系统、插件元数据动态注入注册；
• 标识命名推荐：建议使用简短英文字词，尽量避免使用下划线（如使用 run 而非 hosted_on）。

核心基础与常见推荐关联类型如下表所示：

关系标识	关系名称	源端动作	目标端动作	典型应用场景
default	默认关系	关联	关联	通用无方向偏向的基础互联关系
run	运行关系	运行于	运行	虚拟机、容器实例运行在指定物理机或节点
belong	归属关系	属于	包含	主机归属于业务线、计算节点归属于指定集群
group	分组关系	组成	组成于	资源池、可用区或逻辑组与子资源的聚合关联
connect	连接关系	连接至	接入	服务器网卡与网络交换机端口之间的互联
depend	依赖关系	依赖于	支撑	业务微服务依赖底层数据库、缓存或下游接口
locate	位置关系	部署于	容纳	物理服务器或网络设备部署于指定机房机柜

1.2 规则层：模型拓扑规则

仅有语义尚不足以防错。若允许任意资产随意相连（如将“物理机”错误连接为运行于“微服务”之上），图谱将迅速失真。

因此，ECMDB 在模型级别建立了严格的拓扑准入规则：

• 模型规则绑定：显式声明源模型、关联类型与目标模型的绑定规则；
• 映射基数控制：严格约束端到端的拓扑数量对应关系：
  • 一对一：如主备高可用专属配对；
  • 一对多：如一台物理宿主机承载多台虚拟机；
  • 多对多：如微服务集群与共享分布式存储实例。
• 拓扑准入防线：未在管理台显式注册规则的模型之间，系统层面一律禁止建立实例连线。

1.3 实例层：资产实例连线

记录真实生产环境中资产实体之间的实际拓扑连接：

• 强一致性校验：创建或修改连线前，核心服务自动核验两端资产是否存在、所属模型是否满足准入规则以及映射基数限制；
• 级联生命周期管控：当某项资产实例被注销或删除时，系统自动清理与其相关的所有出入连线，彻底杜绝孤儿悬空边。

---

2. 图谱遍历与查询机制

在资产详情或拓扑看板中，前端需要快速呈现当前资产的上下文关系。ECMDB 针对不同场景提供了两组图谱查询能力：

2.1 双向直接关联查询

以目标资产为中心锚点，单步双向提取与其直接相连的拓扑节点：

• 上游依赖：
  • 查询所有依赖或依附于当前资产的上层实例；
  • 典型场景：查询某台物理宿主机上正在承载哪些虚拟机、或某台数据库正在被哪些业务微服务调用；
• 下游支撑：
  • 查询当前资产所依赖的底层基础设施；
  • 典型场景：查询某台虚拟机实际运行在哪个物理节点、或某个微服务依赖了哪些底层中间件；
• 模型分组统计：
  • 接口返回数据按模型自动聚合统计，便于前端直观呈现“上游 12 个微服务、下游 2 个存储卷”的分组视图。

2.2 多级链路递归穿透

针对端到端的全链路追溯需求，引擎提供多级图遍历能力：

• 最大层级限制：
  • 客户端可指定穿透深度（如展开 2 层、3 层或全量展开）；
  • 严格限制递归层级，避免大规模基础设施集群导致无界扩散与展示卡顿；
• 有向无环保护：
  • 引擎在遍历过程中自动进行环路检测与节点去重，防止循环依赖导致死循环，输出结构清晰的调用链子图。

---

3. 典型运维分析场景

构建资产拓扑关系的核心价值，在于将静态资产转化为立体的基础设施支撑链：

3.1 变更影响面评估

在计划对底层网络交换机、物理宿主机或核心数据库执行割接、升级或停机维护前：

1. 向上追溯业务：以待维护资产为起点发起拓扑遍历，逐层获取上层受波及的虚拟机、容器节点与业务微服务；
2. 锁定责任团队：自动提取受影响业务线的系统归属与负责人，为维护窗口审批与业务通知提供准确依据；
3. 防范非预期中断：提前识别隐性依赖，避免因单点维护造成非预期的级联停机。

3.2 故障根因逐级排查

当业务层出现不可用、调用超时或批量连接重置等告警时：

1. 向下排查设施：以受影响的应用系统为起点发起穿透排查；
2. 逐层追踪支撑链：层层检查微服务依赖的中间件、所在的虚拟机、底层的物理宿主机以及接入的网络交换机；
3. 消除信息孤岛：帮助运维团队快速判断故障究竟源于应用自身异常，还是底层网络或物理硬件故障导致的级联传导，大幅缩短排障定位时长。

---

TIP

掌握了资产属性与拓扑关联后，资产中枢还可通过 微服务插件体系 挂载在线运维工作台（WebSSH、SFTP 与 Redis 控制台），实现从“看资产”到“操作资产”的直接闭环。