优维「架构可视化(视图)」：能力联动让系统架构看得见摸得着-CSDN博客

本文链接：https://blog.csdn.net/EasyOps_DevOps/article/details/141319950

撰文：鹿小U / 制图：脾气超好

在优维的产品方法论中，在探讨架构视图的管理时，我们首先需要理解架构视图的整体目标。我们在服务的过程中发现，很多客户目前仍然采用手动绘制架构视图的方式，这种方式存在几个明显的问题：

首先，手动绘制的架构图往往比较零散，难以进行统一管理。这种手工架构图难以支撑一些特定的消费场景，例如在监控发现故障时，需要通过架构视图排查是哪个资源或服务出现问题。手绘图很难与线上监控数据实现有效联动。

其次，随着客户应用系统的增多，针对每个系统手动梳理架构的工作量变得极为庞大。

此外，架构本身会经历频繁的变化，手动梳理无法及时更新架构变化，也无法有效记录架构的历史版本。

针对这些或棘手或鸡肋的问题，优维推出了「架构可视化（视图）」细分化产品，并将产品目标聚焦如下：

首先，这是一个线上视图库，能有效支撑上层数据消费。我们可以将这个视图库嵌入到需要的页面中进行展示。

其次，我们结合CMDB的资源和资源关系数据基础，支撑架构图的快速生成，从而免去了手动绘制的繁琐工作。

最后，我们基于CMDB数据实现了自动更新和变化检查的逻辑，确保视图能够实时反映系统的最新状态。

优维架构可视化（视图）产品能力主要可以分为四大板块：

我们来看一下产品在绘图方面的能力。

首先，我们提供了一种直观的可视化绘制方式。在界面的左侧，用户可以找到各种元素，这些元素可以直接拖动到图表中。这些元素包括但不限于资源元素和一些额外的绘制元素。此外，我们也支持常见的绘制操作。

其次，我们的产品具备与CMDB绑定的能力。用户可以将拖出的资源元素绑定到对应的CMDB实例上，既可以是单个实例，也可以是一组实例，充分满足不同的绑定需求。同时，我们还提供了配置的跳转、图表布局等辅助功能，以增强绘制体验。

对于视图绘制产品能力，我们可以短平快地理解如下：

直观的拖拽式可视化绘制
丰富的元素库供用户选择和拖动
支持快速绘图操作，如一键添加线条和删除元素
CMDB实例的灵活绑定，支持单个或批量绑定
提供配置跳转和图表布局等辅助功能

为了减轻手动绘制图表的工作量，我们为架构可视化（视图）设计了一些小亮点：

首先，我们引入了架构模板功能。目前，系统已内置了四种模板，用户可以通过选择合适的模板来简化绘图过程；接下来，用户只需填写模板所需的一些参数，这些参数通常来源于CMDB的数据。例如，如果需要绘制一个系统的运行架构，用户需要指定要绘制的系统以及该系统所在的环境。通过这种仅需少量参数定义的方式，用户可以快速生成系统运行架构视图。

使用模板的好处在于，用户无需逐一将资源拖入视图，并手动进行服务之间的关联的繁琐操作。只需在系统自动生成的视图基础上，进行手动微调即可。这样，就避免了繁琐的操作，大大提高了绘图效率。

在视图快速生成能力的使用上，我们也做到了极简的“三步走”：

选择合适的内置架构模版；
根据模板要求填写相关参数，如系统名称和环境等；
点击确认，一键生成系统运行架构视图。

除了使用内置模板来生成视图外，优维架构可视化（视图）还支持通过CMDB关系快速添加相关的点。具体操作如下：

用户可以先将一个点拖入图表中；
在这个点上，用户会看到一个小的加号图标。如果这个点是一个与CMDB关联的实例，用户可以通过点击这个加号图标来添加其相关的关联资源和关系；
例如，用户可以选择添加系统下的所有应用，平台将自动在视图中添加应用的资源点，并且自动连线；
通过这种方式，用户可以一键快速选择和绘制大量点，无需额外确认资源数据直接的关系，从而简化了绘图过程。

接下来，我们讨论视图的检查逻辑。优维架构可视化（视图）的一个重要功能特点是与CMDB数据的联动。在进行视图检查时，我们也是基于CMDB数据来执行检查操作，其逻辑流程是：

视图检查是自动触发的，无需用户进行任何配置；
只要视图中的点与CMDB数据建立了关联，系统就会自动执行检查；
检查的过程是对比现网CMDB数据与图中绘制的点，以识别两者之间的差异。

这样的自动化检查确保了视图与CMDB数据的实时同步，维护了视图的准确性和时效性。

支持对多种变化进行检查，包括：

①图中的资源与CMDB数据之间的变化。②相关的关联关系的变化。③支持配置变化的识别。例如，原本在CMDB中关联的某个实例被删除了，我们也能够识别这种配置异常，并将其展示在配置异常列表中。

前面我们讨论了视图的检查逻辑。我们的检查机制仅会暴露出异常或差异信息，而不会自动修改图表。这是因为某些架构视图可能需要人工确认后，才能被认为是可靠和可消费的。因此，在默认情况下，我们不会执行自动更新的操作。

然而，有些情况下，用户可能不希望每次都手动维护图表，而是希望完全依赖于CMDB的数据。对于这种情况，我们提供了自动更新的功能。例如，通过加号关联到图中的点，实际上是来源于该节点的关联关系。我们可以利用这种关联关系来设置自动更新。

以系统关联的应用为例，如果从CMDB中，系统下的应用从四个增加到五个，在设置了自动更新后，图中的应用也将根据CMDB实例的变化而更新，从而在图表上从四个应用变为五个。同样，如果CMDB中删除了某个实例，图中相应的关联也会被自动移除。

什么是视图版本控制？

在平台上，我们有两个主要的菜单项：架构广场和工作台。

架构广场的场景是针对架构消费的，因此在这里用户只能看到可消费的视图版本。而在工作台中，用户可以看到并维护自己绘制过的所有视图版本，这是一个全量的视图版本展示。

那么，架构视图版本何时会从维护状态转变为可消费状态呢？我们默认采用一个审批逻辑。可以配置架构视图平台的管理人员，当视图版本在个人工作台中发布后，它会进入审批页面。管理人员审批通过后，该视图版本就被认为是一个符合标准规范的、可消费的架构视图，并会出现在架构广场中。

两边平台都支持回溯历史视图版本。特别是当系统视图发生变更时，这通常源于系统能力的变更，可能确实涉及到架构的变动。如果发现新的视图版本存在问题或bug，我们可以通过回溯比较与之前版本的差异，来进一步分析。

这可能涉及到检查新版本中有差异的点是否存在异常。这就是我们经常提到的历史版本在消费场景中的应用。

优维架构可视化（视图）还支持更多种类的架构视图消费场景。

架构视图本身的小产品页面主要专注于架构视图的绘制、维护，以及将其识别为可消费版本进行简单的视图展示。然而，架构视图的实际消费场景不仅仅局限在产品内部进行视图查看，更支持上层场景的消费。

目前，我们有以下四个场景的支持：

▎低代码构件：

我们已经将可消费的视图封装成低代码构件，允许通过低代码开发使用这些视图。其特点是能够对视图进行数据渲染，例如监控数据和告警数据，并进行二次加工后嵌入第三方平台。

▎数字化架构自定义视图：

我们考虑在数字化架构平台中增加一个自定义视图的入口，以便不仅维护既定视图，还能根据需求自定义网络架构视图，并将其集成到数字化架构中进行查看。

▎系统态势感知与监控：

系统态势感知和监控平台将支持渲染架构视图，并在图上的资源点展示指标信息和告警信息。这一块已有初步的demo能力，并将进一步支持更灵活的配置和展示。

▎Dashboard集成：

将架构视图封装成构建，以便在我们的Dashboard中直接消费。

对于如何使用低代码构件，我们来看一个简单的示例：

首先，架构视图将提供一份绘制好的图的数据，包括点、边和拓扑布局。其次，需要接入额外的待渲染数据，如指标数据或告警数据。将这些指标数据与视图数据结合，基于视图上的关联资源，根据资源实例的ID进行匹配。这样，在渲染构件上，我们能够展示视图的点边布局，并在这些点边上渲染样式效果，如颜色变化和数字展示，甚至可以自定义点击事件。这样的整个渲染构件可以灵活地嵌入到各个页面，包括第三方平台的页面，或者用于低代码开发的微应用中。

以上是对架构视图能力的介绍。接下来，我们将简要说明架构视图与数字化架构这两者的关系。

在架构视图和数字化架构中，你会发现同时存在的关键架构：系统运行架构、系统逻辑架构以及相关的应用部署架构。这些图在两个产品中都可以绘制，但我们应该如何理解这两个产品在绘制能力上的差异，以及它们各自支持的产品能力呢？

我们的定位如下：

架构视图：

这是一个在线的视图库，主要支持视图的绘制和管理。通过绘制出的视图，它可以支撑一些上层消费场景。在架构视图中，即使是绘制系统逻辑架构或系统运行架构，也是基于CMDB关系进行首次视图绘制。后续，用户可以灵活地绘制图表，不会限制图中内容。例如，如果用户希望将所有主机放入图表中，也是允许的。
数字化架构：

这个产品不仅包含这两张图的维护，而是涵盖了整个系统架构的全生命周期的管理能力。数字化架构中包含了对这两张图的绘制能力，但在此基础上，它会进一步叠加基于架构管理的小能力点。因此，数字化架构中的视图会有一定的绘制限制。例如，逻辑架构中只能展示应用及其调用关系，运行架构中只能展示服务及其调用关系。如果用户想要查看主机，则只能通过下钻方式跳转到服务的部署架构进行查看。

在视图的消费场景上，架构视图提供了对应的构件，同时也支持内部平台的一些视图消费场景。数字化架构目前主要服务于这两态的管理，后续还将在这个基础上叠加一些对比能力，如运行态与设计态的对比等。