CN113014674B - 服务依赖关系图的绘制方法及装置 - Google Patents

Abstract

本公开公开了一种服务依赖关系图的绘制方法，涉及计算机技术领域，尤其涉及云计算、智能搜索等技术领域。具体实现方案为：将多个服务实例映射为服务依赖关系图中对应的多个节点；针对多个节点，确定与各节点关联的源节点数和目标节点数；基于与各节点关联的源节点数和目标节点数，确定各节点在画布中的位置；基于各节点在画布中的位置，在画布上绘制多个节点；以及在画布上绘制多个节点之间的服务依赖关系，以完成服务依赖关系图的绘制。

Description

服务依赖关系图的绘制方法及装置

技术领域

本公开涉及计算机技术领域，尤其涉及云计算、智能搜索等技术领域。具体涉及一种服务依赖关系图的绘制方法、一种服务依赖关系图的绘制装置、一种电子设备、一种存储有计算机指令的非瞬时计算机可读存储介质及一种计算机程序产品。

背景技术

目前，软件系统多采用微服务系统架构，分布式部署多个应用实例(服务实例)。具体地，通过拆分组件，可以将软件系统中的不同功能组件进行解耦，拆分为一个个单体服务。每个单体服务可以作为一个微服务。微服务与微服务之间可以通过应用程序接口API进行交互，并产生对应的依赖关系。

发明内容

本公开提供了一种服务依赖关系图的绘制方法、装置、设备、存储介质以及计算机程序产品。

根据本公开的一方面，提供了一种服务依赖关系图的绘制方法，包括：将多个服务实例映射为服务依赖关系图中对应的多个节点；针对所述多个节点，确定与各节点关联的源节点数和目标节点数；基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置；基于所述各节点在所述画布中的位置，在所述画布上绘制所述多个节点；以及在所述画布上绘制所述多个节点之间的服务依赖关系，以完成所述服务依赖关系图的绘制。

根据本公开的另一方面，提供了一种服务依赖关系图的绘制装置，包括：映射模块，用于将多个服务实例映射为服务依赖关系图中对应的多个节点；第一确定模块，用于针对所述多个节点，确定与各节点关联的源节点数和目标节点数；第二确定模块，用于基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置；第一绘制模块，用于基于所述各节点在所述画布中的位置，在所述画布上绘制所述多个节点；以及第二绘制模块，用于在所述画布上绘制所述多个节点之间的服务依赖关系，以完成所述服务依赖关系图的绘制。

根据本公开的另一方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开实施例所述的方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据本公开实施例所述的方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据本公开实施例所述的方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1示例性示出了适于本公开实施例的服务依赖关系图的绘制方法的系统架构；

图2示例性示出了根据本公开实施例的服务依赖关系图的绘制方法的流程图；

图3示例性示出了根据本公开实施例的绘制服务依赖关系图的原理图；

图4示例性示出了根据本公开实施例的服务依赖关系图的绘制装置的框图；以及

图5示例性示出了用来实现本公开实施例的服务依赖关系图的绘制方法及装置的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

应该理解，微服务系统架构通常包含数以千计的微服务，各微服务间的依赖关系也非常复杂。相关技术中，描述微服务系统架构中各微服务间的依赖关系，通常采用如下方案。

方案1，采用表格模式描述微服务间的依赖关系。表格中记录的是单点/单边的相关信息，用户需要自主查看表格中的有关数据，自主进行依赖关系的关联。

方案2，针对每个单体服务，分别绘制对应的直接依赖关系图。

方案3，对于大规模微服务节点的绘制，简单使用力矩导向图进行依赖关系的绘制。

应该理解，方案1中，用户可以迅速找到表格中记录的各单点/单边的基本信息，但是这种方案不利于用户快速理解微服务间的依赖关系。

还应该理解，方案2中，只能查看各微服务间的直接依赖关系，无法查看各微服务间的间接依赖关系和循环依赖关系。并且，方案2中，基本都是采用开源前端框架进行绘图的，因各开源前端框架的绘图能力参差不齐，并且在绘制算法和视图展示算法上也都有一定局限性，由此导致采用方案2绘制的微服务依赖关系图展示效果不佳。

也应该理解，方案3中，由于涉及的微服务节点较多，目前的绘图框架或多或少都面临性能瓶颈问题。同时，受绘图框架算法本身的影响，力矩导向图中会缺失一些信息，由此导致用户查寻信息困难，进而导致用户的可视化体验和交互体验较低。

对此，本公开实施例提出了一种改进后的微服务依赖关系图的绘制方案，可以解决上述方案中存在的相关技术问题。

以下将结合具体实施例详细阐述本公开。

适于本公开实施例的服务依赖关系图的绘制方法和装置的系统架构介绍如下。

图1示例性示出了适于本公开实施例的服务依赖关系图的绘制方法的系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他环境或场景。

如图1所示，系统架构100可以包括：微服务系统架构101、数据库102和客户端103。

微服务系统架构101中可以部署多个应用实例(服务实例)，如N个应用实例，即应用实例1～应用实例N，其中N为整数。应该理解，在本公开实施例中，对于微服务系统架构101而言，一个微服务可以包括一个或者多个应用实例。

在一个实施例中，可以通过数据采集装置如底层探针采集微服务系统架构101中各应用实例的相关数据，并将采集到的数据发送给客户端103，使得客户端103能够基于数据采集装置采集到的数据绘制对应的微服务依赖关系图。

或者，在另一个实施例中，还可以通过数据采集装置如底层探针采集微服务系统架构101中各应用实例的相关数据，并将采集到的数据发送给数据库102。客户端103可以从数据库102中读取由数据采集装置采集的数据，并基于读取到的数据绘制对应的微服务依赖关系图。

示例性的，在本公开实施例中，针对微服务系统架构101中各应用实例，采集的微服务节点数据(节点对象数据)可以如表1所示，采集的微服务间的依赖关系数据(连线对象数据)可以如表2所示。本公开的技术方案中，所涉及的节点对象数据和连线对象数据的记录，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。

表1

值	含义	示例	备注
				appId	应用ID	10223	节点基本信息
appDesc	应用描述	account-service	节点基本信息
				appName	应用名称	account	节点基本信息
inPv	输入流量	123	节点基本信息
				outPv	输出流量	3452	节点基本信息
productLineDesc	产品线描述	网盟检索端	节点基本信息
				productLineId	产品线ID	10004	节点基本信息
productLineName	产品线名称	NOVA	节点基本信息
				sourceNum	关联的source应用数	12	通过基础数据计算得到
targetNum	关联的target应用数	2	通过基础数据计算得到
				size	节点大小	21	通过基础数据计算得到
style	节点样式属性	-	通过基础数据配置得到
				isLeaf	叶子节点	true	通过基础数据计算得到

表2

应该理解，表1中，sourceNum表示关联的source应用数(源应用数)；targetNum表示关联的target应用数(目标应用数)；size表示节点大小，可以基于sourceNum和targetNum计算得到；style表示节点样式属性，可以基于节点基本信息确定；isLeaf表示叶子节点，可以基于sourceNum和targetNum计算得到。

示例性的，对于节点A，微服务系统架构101中直接依赖于节点A的所有节点者可以称为节点A的源节点，这些源节点的总数可以记为sourceNum；微服务系统架构101中直接被节点A依赖的所有节点都可以称为节点A的目标节点，这些目标节点的总数可以记为targetNum。在该示例中，假设sourceNum＝10，targetNum＝1，那么sizeA(节点A的大小)＝(sourceNum+targetNum)＝11；或者，由于10≤sizeA≤15，则将sizeA记为15。在该示例中，继续假设sourceNum＝10，targetNum＝1，由于sourceNum和targetNum均不为0，因此节点A不是叶子节点。而如果假设sourceNum＝0或者targetNum＝0，则节点A是叶子节点。

也应该理解，表2中，source表示依赖关系中的源应用；target表示依赖关系中的目标应用。

示例性的，在节点C依赖于节点B这一依赖关系中，对于节点C而言，节点B是节点C的目标节点，对于节点B而言，节点C是节点B的源节点。

此外，linkDistance表示两个节点之间的连线距离，linkDistance可以根据两个节点的大小来确定。

示例性的，对于节点D和节点E而言，这两个节点之间的linkDistanceDE的计算原理可以与节点的大小的计算原理类似，本公开实施例在此不再赘述。

应该理解，图1中的微服务系统架构包含的应用实例的数目，以及图1中的数据库和客户端的数目仅仅是示意性的。根据实现需要，微服务系统架构可以具有任意数目的应用实例。根据实现需要，也可以具有任意数目的数据库和客户端。

适于本公开实施例的服务依赖关系图的绘制方法和装置的应用场景介绍如下。

应该理解，本公开实施例可以适于任何针对微服务系统架构的依赖关系描述场景，尤其可以适于针对包含大规模微服务节点的微服务系统架构的依赖关系描述场景。

根据本公开的实施例，本公开提供了一种服务依赖关系图的绘制方法。

图2示例性示出了根据本公开实施例的服务依赖关系图的绘制方法的流程图。

如图2所示，服务依赖关系图的绘制方法200可以包括：操作S210～S250。

在操作S210，将多个服务实例映射为服务依赖关系图中对应的多个节点。

在操作S220，针对多个节点，确定与各节点关联的源节点数和目标节点数。

在操作S230，基于与各节点关联的源节点数和目标节点数，确定各节点在画布中的位置。

在操作S240，基于各节点在画布中的位置，在画布上绘制多个节点。

在操作S250，在画布上绘制多个节点之间的服务依赖关系，以完成服务依赖关系图的绘制。

在一个实施例中，用户每次查询微服务之间的依赖关系，都可以执行上述的操作S210～S250，从而绘制并展示微服务之间的依赖关系。

在一个实施例中，可以根据用户的查询条件，绘制全局微服务依赖关系图。或者，在另一个实施例中，还可以根据用户的查询条件，绘制局部微服务依赖关系图。在绘制全局微服务依赖关系图的情况下，操作S210中，可以将预设服务实例集中包含的所有服务实例一一映射为待绘制微服务依赖关系图中对应的多个节点。在绘制局部微服务依赖关系图的情况下，可以将预设服务实例集中包含的且被用户选中的一个或者多个服务实例一一映射为待绘制的微服务依赖关系图中对应的一个或者多个节点。

应该理解，在绘制微服务依赖关系图的过程中，对图中涉及的节点进行合理布局，既可以方便用户迅速找到单点/单边(“单点”表示单个节点；“单边”表示两个节点之间的连线)的基本信息，又可以方便用户快速理解各节点之间的直接、间接或循环依赖关系，而且还可以提供较佳的微服务依赖关系图展示效果，进而可以提供用户的可视化体验。

因而，在本公开实施例中，通过执行操作S220～S240，可以实现各节点的合理布局。具体地，对于待绘制的微服务依赖关系图，可以先确定其中涉及的每个节点，再计算与每个节点关联的源节点的数目和目标节点的数目，最后根据计算结果确定每个节点的位置，从而实现对各节点的合理布局。

在完成各节点的合理布局之后，可以执行操作S240～S250，即按照各节点的布局，绘制各节点，并在具有依赖关系的两两节点之间绘制对应的依赖关系。示例性的，例如节点X与节点Y之间存在依赖关系，且节点X依赖于节点Y，可以在节点X与节点Y之间绘制一条箭头由节点X指向节点Y的连线，该连线也称为节点X与节点Y之间的边。

此外，需要说明的是，在本公开实施例中，可以选择在已有的开源绘图框架基础上，自定义节点布局算法，从而在绘制微服务依赖关系图的过程中实现各节点的合理布局。示例性的，在本公开实施例中，可以选择开源的Ant G6、Echarts、D3等作为底层绘图框架。

通过本公开实施例，在面对大规模节点绘制任务时，采用自定义的微服务节点布局自适应算法，可以对微服务系统架构中的各个微服务对应的节点进行合理布局，得到可视化展示效果更佳的依赖关系图。而通过提供可视化展示效果更佳的依赖关系图，可以提高用户的可视化体验，便于用户快速查找自己关注的信息，比如单边/单点的基本信息，节点间的依赖关系，全局依赖关系，局部依赖关系，等等。

作为一种可选的实施例，基于与各节点关联的源节点数和目标节点数，确定各节点在画布中的位置，可以包括：针对待绘制的微服务依赖关系图中涉及的各节点中的每个节点，响应于与当前节点关联的源节点数和目标节点数中的任意一个为0或者都为0，确定该当前节点位于画布的边缘位置。

示例性的，可以根据依赖关系确定与任意节点关联的源节点数和目标节点数。比如，对于节点1而言，可以将依赖于节点1的所有节点统计为与其关联的源节点，将被节点1依赖的所有节点统计为与其关联的目标节点。

在一个实施例中，如果与某个节点关联的源节点数和目标节点数中的任意一个为0，另一个不为0，则表示该节点为叶子节点。考虑到叶子节点涉及的依赖关系可能比较少，因而可以将叶子节点绘制在整个画布的边缘位置。

在另一个实施例中，如果与某个节点关联的源节点数和目标节点数都为0，则表示该节点与任何节点都不存在依赖关系，且这样的节点可以称为孤岛节点。考虑到孤岛节点不涉及任何依赖关系，至少暂时是孤立存在的，因而也可以将孤岛节点绘制在整个画布的边缘位置。

通过本公开实施例，对于涉及依赖关系较少的叶子节点和不涉及任何依赖关系的孤岛节点，可以将其绘制在整个画布的边缘位置，以便用户查看。同时，将以上两类节点绘制在整个画布的边缘位置，还可以疏散画布中间位置处的节点，以便用户查看信息。

应该理解，在本公开实施例中，微服务依赖关系图中的每个节点可以定义为一个节点对象，记为node对象；每个依赖关系可以定义为一个连线对象，记为link对象。每个node对象和每个link对象都可以通过一个对应的数组来描述。示例性的，描述node对象的数组可以包括如表1中描述的相关信息；描述link对象的数组可以包括如表2中描述的相关信息。

或者，作为另一种可选的实施例，基于与各节点关联的源节点数和目标节点数，确定各节点在画布中的位置，可以包括：针对各节点中的每个节点，响应于与当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个为1，确定当前节点位于画布的边缘位置；或者，响应于与当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个不为1，基于与当前节点关联的源节点数和目标节点数，确定当前节点的大小，并基于当前节点的大小，确定当前节点位于画布中的位置。

应该理解，如果与某个节点关联的源节点数和目标节点数中的任意一个为0，另一个不为0，则表示该节点为叶子节点。叶子节点通常涉及的依赖关系都比较少，但是也有些叶子节点涉及的依赖关系比较多。而将涉及依赖关系较多的叶子节点绘制在画布的边缘位置，可能导致节点的某些信息缺失或者无法展示出来，进而影响用户查看。

因而，在一个实施例中，可以将涉及依赖关系较少的叶子节点绘制在画布的边缘位置。在另一个实施例中，可以将涉及依赖关系较多的叶子节点绘制在画布的中间位置。

在本公开实施例中，节点的大小可以根据与其关联的源节点数和目标节点数之和来确定。示例性的，在一个实施例中，可以直接将与节点关联的源节点数和目标节点数之和定义为节点的大小。或者，在另一个实施例中，还可以根据与节点关联的源节点数和目标节点数之和所在的数域区间，定义节点的大小。比如，假设与某节点关联的源节点数和目标节点数之和为Z1，且Z1∈(a，b]，则该节点的大小可以被确定为b。

应该理解，在本公开实施例中，一个叶子节点越大，表示该叶子节点涉及的依赖关系越多。反之，一个叶子节点越小，表示该叶子节点涉及的依赖关系越少。因而，叶子节点越大的，可以越往画布中心位置绘制，叶子节点越大的，可以越往画布边缘位置绘制。

示例性的，在本公开实施例中，可以将只有一个依赖关系即只连接有一条连线的叶子节点绘制在画布的边缘位置，而将除此之外的叶子节点都绘制在画布的中间位置。比如，对于节点1，如果有且仅有节点1依赖于节点2，或者有且仅有节点3依赖于节点1，则可以将节点1绘制在画布的边缘位置。再比如，对于节点4，存在以下依赖关系：节点4依赖于节点5，节点4依赖于节点6，节点4依赖于节点7，节点4依赖于节点8，......，则可以将节点4绘制在画布的中间位置。

通过本公开实施例，对于大小不同的叶子节点，在进行节点布局时可以区分对待。比如，将较小的叶子节点，即涉及依赖关系较少的叶子节点绘制在画布的边缘位置，而将较大的叶子节点，即涉及依赖关系较多的叶子节点绘制在画布的中间位置。由此可以避免因将涉及依赖关系较多的叶子节点绘制在画布的边缘位置而导致节点的某些信息缺失或者无法展示出来。

或者，作为另一种可选的实施例，基于与各节点关联的源节点数和目标节点数，确定各节点在画布中的位置，可以包括：针对各节点中的每个节点，执行以下操作。

响应于与当前节点关联的源节点数和目标节点数都不为0，基于与当前节点关联的源节点数和目标节点数，确定当前节点的大小。

基于当前节点的大小，确定当前节点位于画布中的位置。

应该理解，在本公开实施例中，微服务依赖关系图中涉及的节点除了叶子节点和孤岛节点之外，还包括大量的其他节点。而这些节点中有的可能涉及较少的依赖关系，有的则可能涉及较多的依赖关系。因而，也可以根据这些节点的大小对其进行布局。其中，确定这些节点的大小的方法与上述实施例中确定叶子节点的大小的方法类似，同时基于这些节点的大小确定其在画布中的位置的方法也与上述实施例中基于叶子节点的大小确定叶子节点在画布中的位置的方法类似，本公开实施例在此不再赘述。

通过本公开实施例，对于大小不同的非叶子节点非孤岛节点，在进行节点布局时也可以区分对待。比如，将较小的节点，即涉及依赖关系较少的节点绘制在画布的边缘位置，而将较大的节点，即涉及依赖关系较多的节点绘制在画布的中间位置。由此可以避免因将涉及依赖关系较多的节点绘制在画布的边缘位置而导致节点的某些信息缺失或者无法展示出来，从而影响展示效果的问题。

进一步，在本公开实施例中，当前节点越大，绘图时当前节点的位置可以越靠近画布的中心。反之则反之，即当前节点越小，绘图时当前节点的位置可以越靠近画布的边缘。

需要说明的是，在本公开实施例中，可以通过封装底层绘图框架中提供的绘图算法和开源的fruchterman算法、force算法来实现自定义的节点自适应布局算法，以便优化节点的布局算法，改善节点的布局效果，满足对应的实际业务需求。

此外，作为一种可选的实施例，在画布上绘制多个节点之间的服务依赖关系，可以包括：针对多个节点中具有服务依赖关系的任意两个节点，执行以下操作。

确定两个节点中每个节点的大小。

基于两个节点中每个节点的大小，确定连接于两个节点之间的有向线段的长度。

应该理解，越大的节点涉及的依赖关系越多，越小的节点涉及的依赖关系越少。对于存在依赖关系的任意两个节点而言，如果这两个节点各自涉及的依赖关系较多，或者其中的一个涉及的依赖关系较多，则在绘制依赖关系图时，可以使这样的两个节点之间隔开较大的距离，即，使连接于这样两个节点之间的有向线段的长度较长，以防止两个节点距离太近而导致有些信息无法正常展示。

在本公开实施例中，确定两个具有依赖关系的节点之间的有向线段的长度的方法与确定单个节点的大小的方法类似。

示例性的，节点的大小可以根据与其关联的源节点数和目标节点数之和来确定，进一步两个节点之间的有向线段的长度可以基于这两个节点的大小之和来确定。具体地，可以基于两个节点的大小之和所在的数域区间，定义连接于这两个节点之间的有向线段的长度。比如，假设某有向线段连接的两个节点的大小之和为Z2，且Z2∈(c，d]，则该有向线段连的长度可以被确定为d。

通过本公开实施例，无论对于分布在画布边缘的叶子节点和孤岛节点，还是对于分布在画布中间的叶子节点和其他节点，都可应用上述方法确定连接于两个有依赖关系的节点之间的有向线段的长度。由此可以更精确地进行节点布局，从而实现更好的视觉展示效果。

进一步，在本公开实施例中，具有依赖关系的任意两个节点中的每个节点越大，连接于这两个节点之间的有向线段越长。反之则反之，即，具有依赖关系的任意两个节点中的每个节点越小，连接于这两个节点之间的有向线段越短。

需要说明的是，在本公开实施例中，可以通过封装底层绘图框架中提供的绘图算法和开源的节点布局算法、连线规划算法来实现自定义的节点自适应布局算法，以便优化节点的布局算法，使得节点的布局更精确、更合理。

此外，作为一种可选的实施例，该方法还可以包括如下操作。

确定待绘制的微服务依赖关系图中涉及的各节点各自的样式。

在画布上绘制该微服务依赖关系图中涉及的多个节点的过程中，基于上述的各节点各自的样式进行绘制。

示例性的，描述节点对象的信息可以包括但不限于：应用ID、应用描述、应用名称、输入流量、输出流量、产品线描述、产品线ID、产品线名称、关联的源应用数、关联的目标应用数、节点大小、节点样式属性和是否是叶子节点等。其中，节点的样式属性可以根据节点的基本信息确定。比如，可以使用不同颜色描述属于不同产品线的节点的样式属性，即，在依赖关系图中，可以使用不同的颜色区分不同产品线上的服务，以便与用户快速找到自己关注的信息。

通过本公开实施例，在绘制微服务的依赖关系图时，增加对应的节点样式属性，可以提升节点的渲染效果，便于用户查看自己关注的信息。

此外，作为一种可选的实施例，上述实施例中提及的多个服务实例可以包括：预设服务实例集中包含的所有服务实例，或者该预设服务实例集中包含的且被用户选中的服务实例。

在一个实施例中，可以根据用户的查询条件，绘制全局微服务依赖关系图。或者，在另一个实施例中，还可以根据用户的查询条件，绘制局部微服务依赖关系图。在绘制全局微服务依赖关系图的情况下，可以将预设服务实例集中包含的所有服务实例一一映射为待绘制微服务依赖关系图中对应的多个节点。在绘制局部微服务依赖关系图的情况下，可以将预设服务实例集中包含的且被用户选中的一个或者多个服务实例一一映射为待绘制的微服务依赖关系图中对应的一个或者多个节点。

在本公开实施例中，可以在底层绘图框架的基础上，增加自定义的数据筛选算法。比如，可以增加节点信息筛选算法，从而使得客户端可以根据用户输入的查询条件，更新前端展示的微服务依赖关系视图。

应该理解，数据筛选在客户端前端层面上主要是指对nodes对象即nodes数组进行过滤筛选。具体地，可以根据节点的属性信息(如节点所属的产品线，节点的大小，等等)进行筛选。比如，用户选择了某一个产品线A，通过对nodes数组进行遍历匹配，可以筛选出属于产品线A的所有节点，从而达到改变数据源，更新依赖关系视图的目的。

需要说明的是，在本公开实施例中，如果用户查询时没有输入任何筛选条件，则可以默认绘制对应的全局微服务依赖关系图。如果用户查询时输入了对应的筛选条件，则可以根据用户输入的筛选条件绘制用户实际关注的局部微服务依赖关系图。由此可以满足不同用户的查询需求。

通过本公开实施例，用户可以通过浏览器窗口，查阅关于微服务系统架构的微服务全局依赖关系和微服务局部依赖关系。

此外，作为一种可选的实施例，该方法还可以包括：基于待绘制的微服务依赖关系图中涉及的多个节点的节点个数，确定画布的尺寸。

需要说明的是，在本公开实施例中，微服务依赖关系图中涉及的节点数目越多，画布的尺寸越大。反之则反之，即，微服务依赖关系图中涉及的节点数目越少，画布的尺寸越小。

应该理解，节点数目越多，用户分辨信息的能力就越低。因此，本公开实施例还提出了一个页面自适应算法(即画布尺寸自适应算法)。可以根据节点数目计算画布的大小。示例性的，在本公开实施例中，关于画布尺寸的自适应算法可以定义如下：

(1)节点总数小于50时，与电子设备的屏幕大小一致的画布尺寸就能够展示所有信息供用户查阅。因此，这种情况下，可以将画布尺寸配置为与电子设备的屏幕尺寸相一致。此种情况下，浏览器画布窗口尺寸与电子设备的屏幕尺寸大小一致。

(2)节点总数K大于50时，可以先确定节点数目为K乘以a(如a＝5)时所需的画布尺寸x，再将x和浏览器窗口尺寸y比较。如果x大于y，则取画布尺寸为x。如果x小于y，则取浏览器窗口尺寸y的100％作为画布尺寸。如果画布尺寸溢出电子设备的屏幕尺寸，则为浏览器窗口添加对应的滑动条，即采用滚动屏来解决屏幕大小问题。

通过本公开实施例，可以解决大规模节点绘制导致的性能问题和画布尺寸自适应问题，使得在面对大规模节点绘制时，也可以保证用户查看到全面的、清晰的信息。

此外，作为一种可选的实施例，可以利用web worker在画布上绘制待绘制的微服务依赖关系图中涉及的多个节点和/或这多个节点之间的服务依赖关系(如这多个节点之间的连线)。

需要说明的是，在本公开实施例中，大规模节点绘制中遇到的页面性能问题，如页面卡顿等，可能是浏览器在绘制节点时本身性能低效导致的。因此，本公开实施例还提出了以下用于提升页面大规模节点渲染能力的方法。

具体地，绘制微服务的依赖关系图时，可以使用Web后台提供的Web Worker进程，即使用浏览器自带的算力资源，而不使用底层绘图框架自身的算力资源。因而，可以解决节点布局计算时间过长以及节点渲染时间过长而阻塞页面交互的问题，避免页面卡顿。

此外，需要说明的是，在本公开实施例中，大规模节点绘制中遇到的页面性能问题，如页面卡顿等，也可能是因为数据量大导致的接口请求数据速度慢或客户端前端解析数据速度慢。因此，本公开实施例还提出了其他用于提升页面大规模节点渲染能力的方法。

示例性的，可以使用客户端前端缓存(即浏览器本地缓存)来改善因请求大规模节点数据导致的查询速度慢、数据解析速度慢等问题，以及网络层面的请求慢、请求容易失败等问题，进而解决绘图过程中的页面卡顿问题。

示例性的，还可以通过增加页面加载效果，即为节点数据加载、渲染等操作增加等待缓冲的效果，以便解决绘图过程中的页面卡顿问题。比如，在加载节点数据的过程中，先显示其他图形信息，直到绘图所需的节点数据全部加载完成为止。

以下结合图3和具体实施例详细阐述本公开。

在操作S310，获取元数据并进行数据处理。

需要说明的是，操作S310中，可以通过特定接口请求所需的元数据。如果通过特定接口请求元数据失败或者请求元数据的速度过慢，还可以从客户端前端缓存中获取所需的元数据。

操作S310中，对获取的元数据进行处理，可以生成如图所示的节点对象301(nodes)和连线对象302(links)。

在操作S320，计算与节点关联的源节点数和目标节点数。

具体地，操作S320中，可以基于节点对象301和连线对象302，计算与各节点关联的源节点数和目标节点数。示例性的，可以遍历连线对象302中的每条连线，统计与节点对象301中的每个节点关联的源节点数和目标节点数。

在操作S330，计算连线的长度(linkDistance)。

具体地，操作S330中，可以基于操作S320得到的与各节点关联的源节点数和目标节点数，结合连线对象302中的每条连线两端连接的两个节点，计算每条连线的长度。

在操作S340，定义节点的样式属性、确定是否是叶子节点、以及节点的大小。

具体地，操作S340中，可以基于操作S320得到的与各节点关联的源节点数和目标节点数，确定各节点是否是叶子节点、孤岛节点、以及各节点的大小。其中，各节点的样式可以基于操作S330得到的连线的长度并结合是否是叶子节点、孤岛节点、以及各节点的大小确定，比如可以根据实际业务需求绑定动画、事件等。

在操作S350，进行可视化配置。

在操作S360，生成微服务的依赖关系图。

具体地，操作S360中，可以基于前述操作S350给出的可视化配置，结合在底层绘图框架基础上增加的自定义算法，并使用浏览器自带的web worker进程绘制对应的微服务的依赖关系图。

在本公开实施例中，在面对大规模节点的图形绘制时，可以通过自定义节点的样式、大小、布局以及节点之间的连线的长度，使得微服务全局依赖关系图的布局更加合理，展示效果更好，且便于用户查看直接的、间接的和循环的依赖关系。此外，用户还可以根据节点的属性筛选自己关注的节点信息或连线信息。即可以根据用户的实际业务需求，仅显示局部的微服务依赖关系图供用户查看。此外，还可以根据节点数目，调整浏览器画布的尺寸，从而能够提高用户的可视化体验，便于用户查询信息。

通过本公开实施例，可以轻松应对大规模节点的渲染，上千微服务节点的自适应视图展示，因而更符合用户的使用习惯。

需要说明的是，在本公开实施例中，完成自定义节点布局算法和节点绘制算法及相关配置后，即可使用绘图引擎如G6绘制分布式微服务系统架构的全局依赖关系。用户通过Web控制台即可使用该功能来查看服务间的依赖。

根据本公开的实施例，本公开还提供了一种服务依赖关系图的绘制装置。

图4示例性示出了根据本公开实施例的服务依赖关系图的绘制装置的框图。

如图4所示，服务依赖关系图的绘制装置400包括：映射模块410、第一确定模块420、第二确定模块430、第一绘制模块440和第二绘制模块450。

具体地，映射模块410，用于将多个服务实例映射为服务依赖关系图中对应的多个节点。

第一确定模块420，用于针对该多个节点，确定与各节点关联的源节点数和目标节点数。

第二确定模块430，用于基于与该各节点关联的源节点数和目标节点数，确定该各节点在画布中的位置。

第一绘制模块440，用于基于该各节点在该画布中的位置，在该画布上绘制该多个节点。

第二绘制模块450，用于在该画布上绘制该多个节点之间的服务依赖关系，以完成该服务依赖关系图的绘制。

作为一种可选的实施例，该第二确定模块还用于针对该各节点中的每个节点，执行以下操作：响应于与当前节点关联的源节点数和目标节点数中的任意一个为0或者都为0，确定该当前节点位于该画布的边缘位置。

作为一种可选的实施例，该第二确定模块还用于针对该各节点中的每个节点，执行以下操作：响应于与当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个为1，确定该当前节点位于该画布的边缘位置；或者，响应于与该当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个不为1，基于与该当前节点关联的源节点数和目标节点数，确定该当前节点的大小，并基于该当前节点的大小，确定该当前节点位于该画布中的位置。

作为一种可选的实施例，该第二确定模块还用于针对该各节点中的每个节点，执行以下操作：响应于与当前节点关联的源节点数和目标节点数都不为0，基于与该当前节点关联的源节点数和目标节点数，确定该当前节点的大小；以及基于该当前节点的大小，确定该当前节点位于该画布中的位置。

作为一种可选的实施例，该当前节点越大，该当前节点的位置越靠近该画布的中心；以及该当前节点越小，该当前节点的位置越靠近该画布的边缘。

作为一种可选的实施例，该第二绘制模块还用于针对该多个节点中具有服务依赖关系的任意两个节点，执行以下操作：确定该两个节点中每个节点的大小；以及基于该两个节点中每个节点的大小，确定连接于该两个节点之间的有向线段的长度。

作为一种可选的实施例，该两个节点中每个节点越大，连接于该两个节点之间的有向线段越长；以及该两个节点中每个节点越小，连接于该两个节点之间的有向线段越短。

作为一种可选的实施例，该装置还包括：第三确定模块，用于确定该各节点各自的样式；以及该第一绘制模块，还用于在该画布上绘制该多个节点的过程中，基于该各节点各自的样式进行绘制。

作为一种可选的实施例，该多个服务实例包括：预设服务实例集中包含的所有服务实例，或者该预设服务实例集中包含的且被用户选中的服务实例。

作为一种可选的实施例，该装置还包括：第四确定模块，用于基于该多个节点的节点个数，确定该画布的尺寸。

作为一种可选的实施例，该第一绘制模块利用web worker在该画布上绘制该多个节点；和/或该第二绘制模块利用web worker在该画布上绘制该多个节点之间的服务依赖关系。

应该理解，本公开装置部分的实施例与方法部分的实施例对应相同或类似，所解决的技术问题及达到的技术效果也对应相同或类似，本公开在此不再赘述。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图5示出了可以用来实施本公开的实施例的示例电子设备500的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图5所示，电子设备500包括计算单元501，其可以根据存储在只读存储器(ROM)502中的计算机程序或者从存储单元508加载到随机访问存储器(RAM)503中的计算机程序，来执行各种适当的动作和处理。在RAM 503中，还可存储电子设备500操作所需的各种程序和数据。计算单元501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

电子设备500中的多个部件连接至I/O接口505，包括：输入单元506，例如键盘、鼠标等；输出单元507，例如各种类型的显示器、扬声器等；存储单元508，例如磁盘、光盘等；以及通信单元509，例如网卡、调制解调器、无线通信收发机等。通信单元509允许设备500通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元501可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元501的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元501执行上文所描述的各个方法和处理，例如服务依赖关系图的绘制方法。例如，在一些实施例中，服务依赖关系图的绘制方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元508。在一些实施例中，计算机程序的部分或者全部可以经由ROM 502和/或通信单元509而被载入和/或安装到设备500上。当计算机程序加载到RAM 503并由计算单元501执行时，可以执行上文描述的服务依赖关系图的绘制方法的一个或多个步骤。备选地，在其他实施例中，计算单元501可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行服务依赖关系图的绘制方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (25)

1.一种服务依赖关系图的绘制方法，包括：

将多个服务实例映射为服务依赖关系图中对应的多个节点；

针对所述多个节点，确定与各节点关联的源节点数和目标节点数；

基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置；

基于所述各节点在所述画布中的位置，在所述画布上绘制所述多个节点；以及

在所述画布上绘制所述多个节点之间的服务依赖关系，以完成所述服务依赖关系图的绘制。

2.根据权利要求1所述的方法，其中，基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置，包括：针对所述各节点中的每个节点，

响应于与当前节点关联的源节点数和目标节点数中的任意一个为0或者都为0，确定所述当前节点位于所述画布的边缘位置。

3.根据权利要求1所述的方法，其中，基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置，包括：针对所述各节点中的每个节点，

响应于与当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个为1，确定所述当前节点位于所述画布的边缘位置；

或者，

响应于与所述当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个不为1，基于与所述当前节点关联的源节点数和目标节点数，确定所述当前节点的大小；并基于所述当前节点的大小，确定所述当前节点位于所述画布中的位置。

4.根据权利要求1所述的方法，其中，基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置，包括：针对所述各节点中的每个节点，

响应于与当前节点关联的源节点数和目标节点数都不为0，基于与所述当前节点关联的源节点数和目标节点数，确定所述当前节点的大小；以及

基于所述当前节点的大小，确定所述当前节点位于所述画布中的位置。

5.根据权利要求3或4所述的方法，其中：

所述当前节点越大，所述当前节点的位置越靠近所述画布的中心；以及

所述当前节点越小，所述当前节点的位置越靠近所述画布的边缘。

6.根据权利要求1所述的方法，其中，在所述画布上绘制所述多个节点之间的服务依赖关系，包括：针对所述多个节点中具有服务依赖关系的任意两个节点，

确定所述两个节点中每个节点的大小；以及

基于所述两个节点中每个节点的大小，确定连接于所述两个节点之间的有向线段的长度。

7.根据权利要求6所述的方法，其中：

所述两个节点中每个节点越大，连接于所述两个节点之间的有向线段越长；以及

所述两个节点中每个节点越小，连接于所述两个节点之间的有向线段越短。

8.根据权利要求1至7中任一项所述的方法，还包括：

确定所述各节点各自的样式；以及

在所述画布上绘制所述多个节点的过程中，基于所述各节点各自的样式进行绘制。

9.根据权利要求1所述的方法，其中，所述多个服务实例包括：预设服务实例集中包含的所有服务实例，或者所述预设服务实例集中包含的且被用户选中的服务实例。

10.根据权利要求1所述的方法，还包括：

基于所述多个节点的节点个数，确定所述画布的尺寸。

11.根据权利要求1所述的方法，其中：

利用web worker在所述画布上绘制所述多个节点，和/或所述多个节点之间的服务依赖关系。

12.一种服务依赖关系图的绘制装置，包括：

映射模块，用于将多个服务实例映射为服务依赖关系图中对应的多个节点；

第一确定模块，用于针对所述多个节点，确定与各节点关联的源节点数和目标节点数；

第二确定模块，用于基于与所述各节点关联的源节点数和目标节点数，确定所述各节点在画布中的位置；

第一绘制模块，用于基于所述各节点在所述画布中的位置，在所述画布上绘制所述多个节点；以及

第二绘制模块，用于在所述画布上绘制所述多个节点之间的服务依赖关系，以完成所述服务依赖关系图的绘制。

13.根据权利要求12所述的装置，其中，所述第二确定模块还用于针对所述各节点中的每个节点，执行以下操作：

响应于与当前节点关联的源节点数和目标节点数中的任意一个为0或者都为0，确定所述当前节点位于所述画布的边缘位置。

14.根据权利要求12所述的装置，其中，所述第二确定模块还用于针对所述各节点中的每个节点，执行以下操作：

响应于与当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个为1，确定所述当前节点位于所述画布的边缘位置；

或者，

响应于与所述当前节点关联的源节点数和目标节点数中的任意一个为0，且另一个不为1，基于与所述当前节点关联的源节点数和目标节点数，确定所述当前节点的大小；并基于所述当前节点的大小，确定所述当前节点位于所述画布中的位置。

15.根据权利要求12所述的装置，其中，所述第二确定模块还用于针对所述各节点中的每个节点，执行以下操作：

响应于与当前节点关联的源节点数和目标节点数都不为0，基于与所述当前节点关联的源节点数和目标节点数，确定所述当前节点的大小；以及

基于所述当前节点的大小，确定所述当前节点位于所述画布中的位置。

16.根据权利要求14或15所述的装置，其中：

所述当前节点越大，所述当前节点的位置越靠近所述画布的中心；以及

所述当前节点越小，所述当前节点的位置越靠近所述画布的边缘。

17.根据权利要求12所述的装置，其中，所述第二绘制模块还用于针对所述多个节点中具有服务依赖关系的任意两个节点，执行以下操作：

确定所述两个节点中每个节点的大小；以及

基于所述两个节点中每个节点的大小，确定连接于所述两个节点之间的有向线段的长度。

18.根据权利要求17所述的装置，其中：

所述两个节点中每个节点越大，连接于所述两个节点之间的有向线段越长；以及

所述两个节点中每个节点越小，连接于所述两个节点之间的有向线段越短。

19.根据权利要求12至18中任一项所述的装置，还包括：

第三确定模块，用于确定所述各节点各自的样式；以及

所述第一绘制模块，还用于在所述画布上绘制所述多个节点的过程中，基于所述各节点各自的样式进行绘制。

20.根据权利要求12所述的装置，其中，所述多个服务实例包括：预设服务实例集中包含的所有服务实例，或者所述预设服务实例集中包含的且被用户选中的服务实例。

21.根据权利要求12所述的装置，还包括：

第四确定模块，用于基于所述多个节点的节点个数，确定所述画布的尺寸。

22.根据权利要求12所述的装置，其中：

所述第一绘制模块利用web worker在所述画布上绘制所述多个节点；和/或

所述第二绘制模块利用web worker在所述画布上绘制所述多个节点之间的服务依赖关系。

23.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-11中任一项所述的方法。

24.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-11中任一项所述的方法。

25.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-11中任一项所述的方法。

Images