CN113810234A - 微服务链路拓扑处理方法、装置及可读存储介质 - Google Patents

Abstract

本公开涉及一种微服务链路拓扑处理方法、装置及可读存储介质，其中，该方法通过预先将微服务系统中各微服务对应的链路拓扑存储至链路拓扑数据库中，且为微服务对应的链路拓扑配置相应的标识；当用户查询目标微服务对应的目标链路拓扑时，可输入针对目标微服务的查询条件，基于该查询条件能够获取目标微服务对应的标识，并通过目标微服务对应的标识查询链路拓扑数据库，快速获取目标微服务对应的链路拓扑。本方案是通过预先分析获得微服务系统中各微服务对应的链路拓扑，用户可以快速获得要查询的目标微服务的链路拓扑，无需进行“节点订阅‑拓扑生成”的等待，从而提高微服务链路拓扑处理效率。

Description

微服务链路拓扑处理方法、装置及可读存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种微服务链路拓扑处理方法、装置及可读存储介质。

背景技术

在微服务架构下，随着业务功能不断增多，微服务的数量也不断增加，且微服务之间的调用依赖关系也极为复杂。在一些场景下，例如，梳理微服务之间的关联、微服务出现故障或者异常等等场景，用户需要查询微服务的链路拓扑关系。

现有技术中，在构建微服务链路拓扑关系时，通常采用“订阅-生成”的方式实时消费微服务间的链路追踪信息。这种方式，用户需要使用链路拓扑时，需要先进行服务订阅，且经过一段时间的等待以后，才能够获得相应的链路拓扑图，效率较低。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种微服务链路拓扑处理方法、装置及可读存储介质。

第一方面，本公开提供了一种微服务链路拓扑处理方法，包括：

获取用户输入的针对目标微服务的查询条件；所述查询条件用于指示所述目标微服务的标识；

根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑；所述链路拓扑数据库用于存储一个或多个微服务分别对应的链路拓扑，所述一个或多个微服务包括所述目标微服务；

向所述用户返回所述目标链路拓扑。

在一些可能的实施方式中，所述根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑，包括：

根据所述目标微服务的标识，查询所述链路拓扑数据库，获取与所述目标微服务关联的调用边；所述链路拓扑数据库中用于生成所述目标链路拓扑的所述目标微服务以及所述调用边具有相同的标识；

根据所述调用边对应的源微服务节点信息和目标微服务节点信息，确定第一微服务，以及所述目标微服务与所述第一微服务之间的连接顺序；其中，所述第一微服务包括与所述目标微服务具有调用关系的微服务；

根据所述目标微服务与所述第一微服务之间的连接顺序，生成所述目标微服务对应的目标链路拓扑。

在一些可能的实施方式中，所述查询条件包括所述目标微服务对应的第一节点属性信息；所述目标微服务的标识是通过对所述查询条件包括的第一节点属性信息进行哈希计算获得的。

在一些可能的实施方式中，所述查询条件包括所述目标微服务对应的第一节点属性信息；

所述目标微服务的标识是通过对所述目标微服务的第二节点属性信息进行哈希计算获得的；所述第二节点属性信息是根据所述查询条件包括的第一节点属性信息以及所述目标微服务对应的预设索引获得的，所述预设索引用于将所述第一节点属性信息映射为所述第二节点属性信息。

在一些可能的实施方式中，若所述查询条件还包括：第一指示信息，所述第一指示信息用于指示查询所述目标微服务对应的流量信息；所述方法还包括：

根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标微服务对应的流量信息，其中，所述目标微服务对应的流量信息包括所述目标链路拓扑中每条调用边上的流量信息；所述链路拓扑数据库包括所述目标链路拓扑对应的流量信息。

在一些可能的实施方式中，若所述查询条件还包括：第二指示信息，所述第二指示信息用于指示查询所述目标微服务对应的目标请求延时信息；所述方法还包括：

根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标微服务对应的目标请求延时信息，其中，所述目标微服务对应的目标请求延时信息包括所述目标链路拓扑中每条调用边分别对应的目标请求延时信息；所述链路拓扑数据库包括所述目标链路拓扑对应的目标请求延时信息。

在一些可能的实施方式中，所述获取用户输入的针对目标微服务的查询条件之前，还包括：

获取一个或多个微服务分别基于预设时长内的用户请求生成的链路追踪信息；

根据所述链路追踪信息，获取每个所述用户请求对应的调用图；所述调用图包括：所述用户请求调用的各微服务和用于表示微服务之间的调用关系的调用边；

针对每个所述微服务，遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑；

根据每个所述微服务对应的链路拓扑，获取所述链路拓扑数据库，其中，所述每个所述微服务包括所述目标微服务。

在一些可能的实施方式中，所述根据每个所述微服务对应的链路拓扑，获取所述链路拓扑数据库之前，还包括：

对每个所述微服务对应的链路拓扑进行聚合处理，以去除重复的链路拓扑。

在一些可能的实施方式中，所述方法还包括：

针对每个所述微服务对应的链路拓扑，根据所述微服务的第一节点属性信息，配置所述微服务对应的链路拓扑包括所有微服务和调用边的标识；和/或

针对每个所述微服务对应的链路拓扑，根据所述微服务的第二节点属性信息，配置所述微服务对应的链路拓扑包括所有微服务和调用边的标识。

在一些可能的实施方式中，针对每个所述微服务对应的目标链路拓扑，获取预设索引，其中，所述预设索引用于将所述第一节点属性信息映射为所述第二节点属性信息。

在一些可能的实施方式中，每个所述微服务对应的链路拓扑采用基准微服务、源微服务节点以及目标微服务节点的数据格式存储于所述链路拓扑数据库中。

在一些可能的实施方式中，所述针对每个所述微服务，遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑之前，还包括：

对具有相同结构的调用图进行聚合处理，以将具有相同结构的调用图合并。

在一些可能的实施方式中，所述对具有相同结构的调用图进行聚合处理，包括：

根据所述调用图的标识，对具有相同结构的调用图进行聚合处理，其中，具有相同结构的调用图的标识相同。

在一些可能的实施方式中，所述方法还包括：

针对每个所述微服务对应的链路拓扑，根据所述链路拓扑的入口微服务以及流量路径，拆分所述链路拓扑，获取所述微服务对应的至少一个子链路拓扑；

针对每个所述子链路拓扑，根据所述子链路拓扑中包括的每个微服务的采样率和所述链路拓扑的入口微服务的调用次数，获取所述子链路拓扑包括的每条调用边的第一流量信息；其中，所述链路拓扑的入口微服务的调用次数是根据所述链路追踪信息获得；

将所有所述子链路拓扑中相同调用边的第一流量信息进行相加，获取所述链路拓扑中每条调用边分别对应的流量信息。

在一些可能的实施方式中，所述根据所述子链路拓扑中包括的每个微服务的采样概率和所述目标链路拓扑的入口微服务的调用次数，获取所述子链路拓扑包括的每条调用边的第一流量信息，包括：

针对所述微服务的上游调用边，根据所述调用边的调用次数与所述微服务的上游微服务中的最大采样率之间的比值，获取所述调用边的第一流量信息；

针对所述微服务的下游调用边，根据所述调用边的调用次数与所述微服务的采样率之间的比值，获取所述调用边的第一流量信息。

在一些可能的实施方式中，所述方法还包括：

针对每个所述微服务对应的链路拓扑包括的每条调用边，获取所述调用边在每次调用分别对应的请求延时；

根据所述调用边在每次调用分别对应的请求延时、以及所述调用边对应的调用次数，获取请求延时平均值；

根据所述请求延时平均值，获取所述调用边对应的请求时延信息。

第二方面，本公开提供一种微服务链路拓扑处理装置，包括：

获取模块，用于获取用户输入的针对目标微服务的查询条件；所述查询条件用于指示所述目标微服务的标识；

处理模块，用于根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑；所述链路拓扑数据库用于存储一个或多个微服务对应的链路拓扑的信息，所述一个或多个微服务包括所述目标微服务；

发送模块，用于向所述用户返回所述目标链路拓扑。

第三方面，本公开提供一种电子设备，包括：存储器和处理器；

所述存储器被配置为存储计算机程序指令；

所述处理器被配置为执行所述计算机程序指令，以实现第一方面任一项所述的微服务链路拓扑处理方法。

第四方面，本公开还提供一种可读存储介质，包括：计算机程序指令；所述计算机程序指令被电子设备的至少一个处理器执行时，以实现第一方面任一项所述的微服务链路拓扑处理方法。

第五方面，本公开还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面任一项所述的微服务链路拓扑处理方法。

本公开提供一种微服务链路拓扑处理方法、装置及可读存储介质，其中，该方法通过预先将微服务系统中各微服务对应的链路拓扑存储至链路拓扑数据库中，且为微服务对应的链路拓扑配置相应的标识；当用户需要查询目标微服务对应的目标链路拓扑时，可输入针对目标微服务的查询条件，基于该查询条件能够获取目标微服务对应的标识，并通过目标微服务对应的标识查询链路拓扑数据库，获取目标微服务对应的链路拓扑。本方案是通过预先分析获得微服务系统中各微服务对应的链路拓扑，用户可以快速获得要查询的目标微服务的链路拓扑，无需进行“节点订阅-拓扑生成”的等待，从而提高微服务链路拓扑处理效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1A为本公开提供的用于建立链路拓扑数据库的系统框架图；

图1B为本公开提供的微服务调用、跨度数据以及链路追踪之间的关系示意图；

图1C为本公开提供的链路追踪、调用图以及合并后的调用图之间的关系示意图；

图1D为本公开提供的链路拓扑数据库中对链路拓扑的存储方式示意图；

图1E为本公开提供的查询微服务的流程示意图；

图1F为本公开提供的基于粗粒度节点属性信息查询细粒度的链路拓扑的流程示意图一；

图1G为本公开提供的基于粗粒度节点属性信息查询细粒度的链路拓扑的流程示意图二；

图1H为本公开提供的对链路拓扑进行预聚合时，链路拓扑的结构示意图；

图1I为本公开提供的链路拓扑示意图；

图1J为对图1I所示的链路拓扑基于不同流量路径进行拆分，获得的其中一个子链路拓扑的结构示意图；

图1K为对图1I所示的链路拓扑基于不同流量路径进行拆分，获得的另一个子链路拓扑的结构示意图；

图1L为图1I所示的链路拓扑的目标流量的示意图；

图2为本公开一实施例提供的微服务链路拓扑处理方法的流程图；

图3为本公开一实施例提供的微服务链路拓扑处理方法的流程图；

图4为本公开一实施例提供的微服务链路拓扑处理方法的流程图；

图5为本公开一实施例提供的微服务链路拓扑处理方法的流程图；

图6为本公开一实施例提供的微服务链路拓扑处理方法的流程图；

图7为本公开一实施例提供的微服务链路拓扑处理方法的流程图；

图8为本公开一实施例提供的微服务链路拓扑处理装置的结构示意图；

图9为本公开一实施例提供的电子设备的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

本实施例提供一种微服务链路拓扑处理方法、装置、电子设备、可读存储介质以及计算机程序产品，其中，该方法通过预先将微服务系统中各微服务对应的链路拓扑存储至链路拓扑数据库中，且为微服务对应的链路拓扑配置相应的标识；当用户需要查询目标微服务对应的目标链路拓扑时，可输入针对目标微服务的查询条件，基于该查询条件能够获取目标微服务对应的标识，并通过目标微服务对应的标识查询链路拓扑数据库，获取目标微服务对应的链路拓扑。本方案是通过预先分析获得微服务系统中各微服务对应的链路拓扑，用户可以快速获得需要查询的目标微服务的链路拓扑，无需进行“节点订阅-拓扑生成”的等待，从而提高微服务链路拓扑处理效率。

本公开提供的微服务链路拓扑处理方法可以由本公开提供的微服务链路拓扑处理装置执行，该微服务链路拓扑处理装置可以通过任意的软件和/或硬件的方式实现。示例性地，微服务链路拓扑处理装置可以包括但不限于包括：计算机、笔记本电脑、服务器、云服务器、服务器集群等电子设备。

下面通过几个具体的实施例对本公开提供的微服务链路拓扑处理方法进行详细介绍。且下述实施例中，以电子设备执行微服务链路拓扑处理方法为例进行举例说明。

本公开提供的微服务链路拓扑处理方法是基于微服务关联的链路拓扑数据库实现的。下面，首先通过几个具体实施例，并结合场景以及附图、相关图表等，详细介绍如何建立链路拓扑数据库。

示例性地，图1A示出了用于建立链路拓扑数据库的系统框架图。参照图1A所示，该系统框架100主要包括：采集模块101、计算模块102、存储模块103和查询模块104。

一、采集模块101，用于获取并存储微服务系统中各微服务基于用户请求产生的链路追踪信息。

示例性地，可在微服务系统的各个微服务框架和组件中设置埋点。当微服务间发生调用时，埋点能够采集本次调用的相关信息，(例如，数据包大小、请求延时、服务名、调用发生的时间戳等信息)；埋点将采集到的相关信息组织成预设数据格式上报至采集模块101。其中，上述预设数据格式的信息即为链路追踪信息。

在一个具体的实施例中，微服务间发生调用时，埋点可以采集调用相关的信息，并将这些信息组织成名为跨度(span)，且符合预设数据格式的信息(即链路追踪信息，也可以称为span数据)进行上报。其中，微服务产生的span数据被写入到一个span消息队列中；span消费者服务从span消息队列中读取span数据，并将读取的span数据写入到hive数据库中进行保存，以供计算模块102使用。

当然，采集模块101也可以将读取的span数据存储至其他类型数据库，并不限于hive数据库。本公开对于数据库的类型、数据库的容量以及数据库的其他相关参数等等不作限定。

二、计算模块102，用于对链路追踪信息进行建模和计算，得到微服务系统中各微服务分别对应的链路拓扑。

计算模块102通过分析链路追踪信息，首选得到用户请求级别的调用图(callgraph)，基于对调用图进行拆分、剪枝、聚合等等处理，以每个微服务作为基准微服务，获得每个微服务对应的链路拓扑。

在一个具体的实施例中，埋点上报的span数据存储在hive数据库中，计算模块102可以使用spar计算引擎对hive数据库存储的span数据进行建模和计算，以得到每个微服务对应的链路拓扑。其中，在计算过程涉及到的具体算法模型以及算法细节将在后文中详细描述。

微服务对应的链路拓扑的数据以hive表的形式从hive数据库中导出；其中，hive表中每行记录的点边数据以json格式的字符串进行编码，并写入到链路拓扑消息队列中，以供存储模块以及其他模块消费数据。

其中，微服务对应的链路拓扑采用的具体数据格式，并不限于hive表的形式，本公开对此不作限定。

且计算模块还可以获取各微服务对应链路拓扑的链路统计信息。其中，链路统计信息可以包括流量信息、请求延时信息等等。

三、存储模块103，用于存储各微服务分别对应的链路拓扑以及相关的链路统计信息。

在一个具体实施例中，链路拓扑数据库可以使用图数据库，即存储模块可使用图数据库以点、边的形式存储各微服务分别对应的链路拓扑以及相关的链路统计信息。

具体地，存储模块103可使用一个链路拓扑消费者服务从链路拓扑消息队列中获取点边数据，并使用图数据库语言(Gremlin)按照预定的数据模型写入到链路拓扑数据库中进行保存。

四、查询模块104，用于向用户提供查询接口，该查询接口可以接收用户输入的查询条件，并基于用户输入的查询条件，从存储模块103中获取要查询的目标微服务的链路拓扑的数据，并对目标微服务的链路拓扑的数据进行处理和聚合后返回给用户。

在一个具体的实施例中，查询模块104中，查询API服务接收用户输入的查询条件，并根据查询条件生成相应的Gremlin查询语句，使用Gremlin查询语句从链路拓扑数据库中拉取要查询的目标微服务对应的链路拓扑，并对获取目标微服务的链路拓扑的数据进行处理和聚合后返回给用户。

下面对采集模块101、计算模块102、存储模块103以及查询模块104分别涉及到的具体算法模型以及算法细节进行详细介绍。

结合前述图1A实施例中关于采集模块101的介绍可知，基于用户请求，微服务间可以发生调用。其中，微服务系统在处理一次用户请求时，多个微服务之间常常会发生一些链式调用。在这个过程中，发生链式调用的微服务均会通过上报span数据以记录调用的过程。

具体地，微服务接收到用户请求时，埋点会生成一个服务端span数据(serverspan)；微服务向下一个微服务发送请求时，埋点会生成一个客户端span数据(clientspan)。整个调用链路上所有的span数据构成了该次调用的追踪链路，且每个span数据记录相同的追踪标识(如：trace ID)。

相应地，计算模块102，可以通过分析追踪标识生成用户请求对应的调用图。

其中，图1B示例性地示出了微服务调用、跨度数据以及链路追踪之间的关系示意图。参照图1B所示，外部针对微服务系统的用户请求调用微服务A，微服务A分别调用了微服务B和微服务C，微服务C调用了微服务D。微服务A中设置埋点1，微服务B中设置埋点2，微服务C中设置埋点3，微服务D中设置埋点4为例进行举例说明。

在上述示例的调用过程中，微服务A接收到用户请求时，埋点1首先产生服务端跨度数据1；微服务A分别调用微服务B和微服务C时，埋点1生成客户端跨度数据1和客户端跨度数据2，其中，客户端跨度数据1用于指示微服务A调用微服务B，客户端跨度数据2用于指示微服务A调用微服务C；类似地，微服务B和微服务C在接收到用户请求时，埋点2和埋点3分别生成服务端跨度数据2和服务端跨度数据3；微服务B调用微服务D时，埋点2生成客户端跨度数据3，埋点2生成的客户端跨度数据3用于指示微服务B调用微服务D；类似地，微服务D接收到用户请求时，埋点4生成相应的服务端跨度数据4。

请继续参照图1B所示，客户端跨度数据1至3，以及，服务端跨度数据1至4，构成一条追踪链路。且客户端跨度数据1至3，以及，服务端跨度数据1至4，具有相同的追踪标识。

在图1B所示实施例中，符号

表示埋点，实线框表示服务端跨度数据，虚线框表示客户端跨度数据。

结合前文中图1A中的介绍，采集模块101可以将这些跨度数据存储至数据库中，如hive数据库。示例性地，以将跨度数据存储至hive数据库为例，针对用户请求产生的链路追踪信息的数据格式可如下表1所示，表1中的每一行表示一条链路追踪信息，其中，链路追踪信息包括追踪标识(即trace ID)、JSON格式编码的跨度数据，链路追踪产生的时间信息。

表1

当然，在实际应用中，数据库中跨度数据也可以采用其他数据格式存储，本公开对此不作限定，表1中所示仅为示例。此外，链路追踪信息还可以包括其他调用相关的信息，本公开对此不做限定。

结合前述图1A实施例中关于计算模块102的介绍可知，计算模块102可通过分析数据库中存储的跨度数据，进行建模和分析，获得各微服务的链路拓扑。

由于跨度数据无法直观地反映链路拓扑，因此，需要进行抽象和处理，得到用户请求对应的调用图(调用图也可以称为：调用图模型、调用数据模型、调用数据图等其他名称)。

本公开，调用图由节点和边组成，其中，节点表示微服务，边表示微服务间的调用关系。此外，调用图包括：微服务的节点属性信息、边属性信息以及链路统计信息等等。

其中，微服务的节点属性信息包括：服务标识、接口标识、集群标识以及机房标识中的一项或多项。边的属性信息包括：源微服务信息、目标微服务信息、链路统计信息中的一个或多项。链路统计信息例如包括流量信息、数据包大小信息、请求延时信息等等。

示例性地，调用图的数据格式可如下表2所示，表2中的每一行表示一个调用图的数据，其中，调用图标识可以通过对调用图包括的节点和调用边对应的字段，进行哈希计算获得。Edgelist表示调用图对应的边列表。表2中的“日期(date)”表示调用发生的日期，“小时(hour)”表示调用发生的具体时间。

表2

当然，在实际应用中，调用图也可以采用其他数据格式存储，本公开对此不作限定，表2中所示仅为示例。

其中，获取调用图标识时，节点对应的字段可以包括：节点的服务标识、接口标识、集群标识以及机房标识中的一项或多项分别对应的字段；调用边对应的字段可以包括：源微服务节点对应的字段、目标微服务节点对应的字段，其中，源服务节点对应的字段可以包括：源微服务节点对应的服务标识、接口标识、集群标识以及机房标识中的一项或多项分别对应的字段，目标微服务节点对应的字段可以包括：目标微服务节点对应的服务标识、接口标识、集群标识以及机房标识中的一项或多项分别对应的字段。

由于调用图对应的调用标识是基于调用图包括的节点和调用边对应的字段进行哈希计算获得的，因此，若两个调用图具有相同的调用标识，则表示这两个调用图具有相同的调用链路模式，调用链路模式即表示调用图的结构，因此，本公开还可以对具有相同调用链路模式的调用图进行合并，使每个调用边上的链路统计信息得到叠加，从而减小数据冗余。

示例性地，图1C示例性示出了链路追踪、调用图以及合并后的调用图之间的关系示意图；在图1C所示的场景中，微服务a调用了微服务b和微服务c，微服务b调用了微服务d；其中，微服务c包括了两个子服务，分别为子服务c1和子服务c2，微服务a分别调用了子服务c1和子服务c2。在上述调用的过程中，设置在各微服务的埋点生成服务端跨度数据和客户端跨度数据，与前述图1B所示实施例类似，简明起见，此处不再赘述。

参照图1C所示，分别设置在微服务a至微服务d的埋点生成的跨度数据构成的链路追踪如图1C中所示，对链路追踪中的跨度数据进行聚合，得到本次调用的调用图。其中，调用图中包括节点1至节点4，节点1至节点4分别用于表示微服务a至微服务d。调用图还包括调用边1至3，调用边1至3则分别表示相应微服务之间的调用关系。

例如，节点1和节点2之间的调用边1表示微服务a和微服务b之间的调用关系，调用边1的方向由微服务a指向微服务b，即，表示微服务a是源微服务节点，微服务b是目标微服务节点，且调用边1对应的链路统计信息包括调用次数时，调用次数等于1。

又如，节点1和节点3之间的调用边2表示微服务a和微服务c之间的调用关系，该调用边21的方向由微服务a指向微服务c，即，表示微服务a是源微服务节点，微服务c是目标微服务节点，由于微服务a分别调用了子服务c1和子服务c2，因此，调用边2对应的链路统计信息包括调用次数时，调用次数等于2。

调用边3与上述调用边1和调用边2类似，此处不再赘述。

对于调用图，若调用图标识相同，则调用图具有相同的链路拓扑模式，因此，计算模块102可以基于调用图标识，将具有相同链路拓扑模式的调用图进行合并，且合并时可将相同结构的调用图中，相同调用边上的链路统计信息进行叠加。

示例性地，参照图1C所示，合并之后的调用图的结构与合并之前的调用图的结构式相同的，但合并之后的调用图中各调用边对应的链路统计信息发生了变化，如，调用边1对应的链路统计信息包括调用次数时，调用次数等于n1；调用边2对应的链路统计信息包括调用次数时，调用次数等于n2；调用边3对应的链路统计信息包括调用次数时，调用次数等于n3。上述n1、n2、n3表示将相同调用边上的调用次数相加之后的结果。

执行了合并操作之后的调用图包括了链路拓扑信息和链路统计信息，为了能够提供单个微服务的链路拓扑，因此，还需要对调用图进行进一步地拆分、剪枝以及聚合等操作，以获得各微服务分别对应的链路拓扑。

其中，对调用图进行拆分时，以调用图中每个节点分别作为基准节点进行拆分，以实现对调用图中的每个节点都能够生成相关联的子调用图。

且在拆分调用图时，对于选择的某个基准节点，可以通过保留该基准节点相关联的调用图中，与该基准节点的直接上游调用边以及所有下游调用边，以剔除调用图中与基准节点不存在依赖关系的调用边。

对于这样的调用边选择策略，也可以称为调用图的剪枝。通过调用图的剪枝，可以选择性剔除与基准节点无关的链路拓扑，即选择性剔除与基准节点(即基准微服务)无关的节点和调用边。

示例性地，图1C中的调用图为例，假设节点2为基准节点，即微服务b为基准微服务；对微服务b的上游调用边，保留微服务a到微服务b的调用边1，剔除微服务a到微服务c的调用边2；对于微服务b的下游调用边，保留微服务b到微服务d的调用边3。

其中，直接上游调用边可以理解为与基准节点具有直接调用关系的上游调用边。例如图1C所示实施例中，对于节点2来说，微服务a到微服务b的调用边1即属于节点2的直接上游调用边，微服务a到微服务c的调用边2则不属于节点2的直接上游调用边。

在一些情况下，微服务系统中可能存在一些被众多服务依赖的服务，这些被依赖的服务通常会被频繁调用，因此，被依赖的服务相关的调用图数量也较大。例如，在微服务系统中会设置中台服务(也可以称为其他名称，例如，通用服务)，中台服务用于为上游的微服务提供通用能力；同时，中台服务因为被这些微服务所依赖，因此，与中台服务相关的调用图数量较大。若直接将与中台服务相关的调用图进行存储，则会造成大量数据冗余，降低存储资源利用率，更会导致查询中台服务对应的链路拓扑时，需要遍历大量以中台服务为基准节点的子调用图，并进行聚合才能够得到中台服务对应的完整的链路拓扑，但是这样查询效率极低。

此外，调用图是代表了一个微服务间调用链路的拓扑结构。为了能生成每一个微服务节点的上下游依赖拓扑图，我们需要对调用图进行拆分，生成不同的<点，边>组合，从而能将其保存在图存储数据库中，以供查询时使用。

下面详细介绍调用图拆分算法：

在对调用图进行拆分时，本方案采用回溯的方式遍历整个调用图的结构，并在遍历的过程中产生多个<点，边>组合。算法在初始化时创建了一个数组变量edgePath，用于记录回溯过程中从调用图的根节点到当前访问节点的路径上的边。算法从调用图的根节点开始，使用深度优先搜索的方式逐渐遍历其各个子节点。算法在访问到某一个节点n时，对于edgePath中的每一条边e，分别生成<n，e>以及<e的from节点，n的上游调用边>两种不同的<点，边>组合。在递归n的某个子节点c前，把n到c之间的边加入到edgePath中；递归完成时，再将这条边从数组变量edgePath中删除。

该算法采用回溯(back tracking)的方式对调用图进行遍历，由于调用图通常是一颗多叉树的结构，因此，本公开使用的算法能够实现在O(NlogN)的时间复杂度和O(logN)的空间复杂度下完成调用图拆分，其中N表示调用图中的节点数目。

存储拆分后的各基准节点分别对应的子调用图。

示例性地，以将子调用图保存在hive数据库中为例，拆分后的各基准节点分别对应的子调用图可以“基准节点+源微服务节点+目标微服务节点”的数据格式存储。

示例性地，如下表3所示，在表3中，每一行表示一条调用边，包括基准节点、源微服务节点、目标微服务节点以及该调用边对应的链路统计信息。表3中还可以包括每个节点的节点属性信息，如服务标识、接口标识、集群标识、机房标识等等。

表3

表3中，省略号“…”表示相应的数据，例如，基准节点A的集群标识处的省略号“…”表示微服务A对应的集群标识。在表3中仅是为了方便示例，因此采用省略号进行示例。

且实际应用中，调用图可以包括更多的调用边。且调用边也可以采用其他数据格式进行存储，表3仅是示例，本公开对于调用边在数据库中的数据格式不作限定。

可选地，计算模块102可以对拆分之后获得的子调用图进行聚合处理，以去除重复的子调用图。由于不同的调用图进行拆分之后有可能产出相同的“基准节点+源微服务节点+目标微服务节点”组合，即相同的子调用图，因此，计算模块102可以通过对子调用图进行聚合，去除重复的子调用图，从而减小数据量。

对子调用图进行聚合处理之后，保留下来的所有子调用图则可以存入链路拓扑数据库中，以供用户进行查询。

其中，链路拓扑数据库是一种图数据库，使用点(vertex)和边(edge)作为数据模型存储微服务对应的链路拓扑。这里所指的“点”即表示微服务的节点，“边”即表示微服务间的调用关系，即本公开中的调用边。

因此，在链路拓扑数据库中，针对点和边分别配置不同的类型(type)和身份标识(ID)进行唯一标识。

示例性地，针对点配置的类型可以为第一类型，例如，第一类型可以为node；针对边配置的类型可以第二类型，例如，第二类型可以为edge。在实际应用中，第一类型和第二类型也可以通过其他方式实现，例如，通过数字标识、字符标识等等区分不同类型。

示例性地，针对点和边分别配置的身份标识可以通过以下方式实现：首先，对子调用图中的每个节点进行哈希计算，获得每个节点的ID值。接着，在进行存储时，以基准微服务(也可以称为基准节点)的属的ID值作为调用边的ID值进行存储，并存储调用边的链路统计信息。

图1D示例性地示出了链路拓扑数据库中对链路拓扑的存储方式。参照图1D中所示，节点A至节点D分别经过哈希计算后得到各自对应的ID值，依次记为A-ID、B-ID、C-ID、D-ID。且对所有节点A相关联的调用边，即节点A至节点B之间的调用边、节点A至节点C之间的调用边、节点B至节点D之间的调用边，均以节点A的ID值，即A_ID作为各调用边的ID值进行存储，从而连接各个节点。

这样配置调用边的身份标识的目的是为了使链路拓扑数据库能够提供服务链路级别的链路拓扑查询能力。

在上述配置了节点的标识以及调用边的身份标识的基础上，链路拓扑数据库已经具备针对单个节点的查询能力。

其中，图1E示例性地示出了用户查询微服务A的过程。参照图1E所示，用户可以输入微服务A的查询条件，基于该查询条件进行哈希计算，可以获得微服务A的ID值，即A_ID；基于A_ID在链路拓扑数据库中进行查询获得微服务A对应的节点A；在将A_ID作为调用边ID，在链路拓扑数据库中进行查询，获得相关的调用边，基于这些相关的调用边分别对应的源微服务节点和目标微服务节点进行聚合，获得微服务A对应的链路拓扑。

请继续参照图1E所示，微服务C同时是微服务A和微服务B的下游，也是微服务D和微服务E的上游。在实际的业务中，至存储A-C-D的调用链路，即微服务E对于微服务A来说，并不构成依赖关系，由于不存在调用边ID＝A_ID的调用边连接微服务C对应的节点C和微服务E对应的节点E，因此，在本次查询过程中节点E不会出现。

微服务系统发生调用时，埋点能够采集微服务的为了使链路拓扑数据库能够支持不同粒度的链路拓扑的查询能力。因此，还可以建立能够实现粗粒度节点属性信息与细粒度节点属性信息之间映射的索引。当用户基于粗粒度节点属性信息查询链路拓扑时，能够通过该索引，获得细粒度节点属性信息，再基于细粒度节点属性信息，查询链路拓扑数据库，获取细粒度的链路拓扑。

示例性地，粗粒度节点属性信息与细粒度节点属性信息之间的索引可以使用索引边的形式，即“index_edge_type”的形式表示。

例如，假设用户想要查找的是细粒度节点属性信息包括“接口标识”，因此，可在索引的末端拼接“_operation”的后缀，其中，“operation”表示接口标识，从而得到能够映射至包括接口标识的细粒度节点属性信息的索引“index_edge_type_operation”。类似地，还可以通过在索引的末端拼接“_cluster”、“_dc”的后缀查询包含“集群标识”、“机房标识”的细粒度节点属性信息。

图1F示例性地示出了基于粗粒度节点属性信息查询细粒度的链路拓扑的实现过程。参照图1F所示，微服务A对应两个接口，分别为接口1和接口2；索引用于实现包括微服务A的服务标识的粗粒度节点属性信息，与，包括微服务A的服务标识、接口1的标识以及接口2的标识的细粒度节点属性信息之间的映射。

假设，用户查询微服务A的链路拓扑时，用户输入微服务A的服务标识，例如，微服务A的服务标识为“A”；基于微服务A的服务标识以及索引，确定微服务A对应的细粒度节点属性信息包括：微服务A的服务标识、接口1的标识以及接口2的标识，例如，接口1的标识为“Foo”，接口2的标识为“Bar”。

该过程，相当于基于服务标识“A”和索引，确定了微服务A的n个下游节点。

基于微服务A对应的细粒度节点属性信息，将服务标识“A”与接口1的标识“Foo”进行拼接，并进行哈希计算，得到微服务A对应的接口1的ID值，记为A：：Foo_ID；将服务标识“A”与接口2的标识“Bar”进行拼接，并进行哈希计算，得到微服务A对应的接口2的ID值，记为A：：Bar_ID。

基于接口1的ID值A：：Foo_ID、接口2的ID值A：：Bar_ID，分别查询链路拓扑数据库，获取接口1和接口2分别对应的调用边。

在图1F所示实施例中，微服务A包括了2个接口。在一些情况下，微服务可能包括更多的接口，参照图1G中所示，微服务A包括n个接口，分别记为接口1至接口n，n为大于或等于2的整数。类似地，若用户输入微服务A的服务标识“A”，以查询微服务A的链路拓扑，基于服务标识“A”以及索引，则可以获得细粒度节点属性信息包括：服务标识“A”以及接口1至接口n分别对应的标识。

该过程，相当于基于服务标识“A”和索引，确定了微服务A的n个下游节点。

请继续参照图1G所示，假设，接口1的标识为：Foo，接口1的ID值为A：：Foo_ID＝123，其中，获取接口1的实现方式可参照图1E中所示。类似地，接口n的标识为：Bar，接口n的ID值为A：：Bar_ID＝456。

接口2至接口n-1也分别对应各自的ID值，且获取接口2至接口n-1分别对应的ID值也可以采用类似与接口1类似的方式，简明起见，此处不再赘述。

以接口1为例，以A：：Foo_ID＝123作为查询条件，在链路拓扑数据库中进行查询，获取ID值为123的调用边，其中，ID值为123的调用边即为接口1对应的链路拓扑中包括的调用边；再以接口n为例，以A：：Bar_ID＝456作为查询条件，在链路拓扑数据库中进行查询，获取ID值为456的调用边，其中，ID值为456的调用边即为接口n对应的链路拓扑中包括的调用边；其他接口采用类似的方式进行查询，简明起见，此处不再赘述。

为了能够进一步优化上述由粗粒度节点到细粒度节点的查询过程，本公开提出对不同粒度的链路拓扑进行预聚合的算法，通过在离线计算环境中预先生成不同粒度之间的节点之间的调用边，从而提高查询效率。

具体地，可在离线计算环境中，基于不同节点属性信息进行组合，获得多个不同粒度的节点属性信息组合；基于多个不同粒度的节点属性信息组合，获得基准节点在每个粒度下的ID值；再基于基准节点在不同粒度的ID值分别聚合相应调用边；并将不同粒度下，分别聚合的调用边均存储至链路拓扑数据库中，以供用户使用。

接下来，以粗粒度节点属性信息包括服务标识，细粒度节点属性信息包括服务标识和接口标识的链路拓扑为例说明预聚合的实现方式。其中，以“基准节点的服务标识+源微服务节点+目标微服务节点+接口标识”的组合作为预聚合的关键值。

在对细粒度的链路拓扑进行预聚合时，首先，基于基准节点的服务标识和接口标识，计算基准节点对应的细粒度的ID值；再以基准节点对应的细粒度的ID值配置基准节点的细粒度的链路拓扑包括的各调用边。

且在基准节点对应的细粒度的ID上可以增加用于指示细粒度节点属性信息的指示符，这样设置的目的能够清楚表示调用边的粒度。本公开对于指示符的具体类型不作限定。

示例性地，参照图1H所示，假设，微服务A对应1个接口，分别为接口1和接口2，其中，接口1的标识为：Foo，接口2的标识为：Bar。用户输入的查询条件为微服务A的服务标识，则基于索引确定细粒度的节点属性信息包括：服务标识和接口标识。基于细粒度的节点属性信息，即服务标识和接口标识进行计算，获取微服务A对应的细粒度的ID值，例如，微服务A对应的细粒度的ID值为999，可以表示为A_ID_s_o＝999，其中，后缀“_s_o”即指示细粒度的节点属性信息，“s”表示服务标识，“o”表示接口标识。

再以A_ID_s_o＝999作为查询条件，从链路拓扑数据库中获取匹配的调用边，其中，这些匹配的调用边即为细粒度的链路拓扑包括的调用边；基于这些调用边对应的边属性信息，则可以聚合获得微服务A对应的细粒度的链路拓扑。

上述示例均以粗粒度节点属性信息包括服务标识，细粒度节点属性信息包括服务标识和接口标识为例进行说明。在实际应用中，粗粒度节点属性信息和细粒度节点属性信息均可以包括服务标识、接口标识、集群标识以及机房标识中的一项或者多项，且粗粒度节点属性信息的信息量少于细粒度节点属性信息的信息量。

例如，粗粒度节点属性信息可以包括：服务标识和集群标识；细粒度节点属性信息包括：服务标识、接口标识和集群标识。又如，粗粒度的节点属性信息包括：服务标识；细粒度的节点属性信息包括：服务标识、接口标识和集群标识。当然，还可以有更多的情况，此处不一一示例。

本公开通过对不同粒度的链路拓扑进行预聚合，当用户查询细粒度的链路拓扑时，以基准节点对应的细粒度的ID值作为查询条件，即可从链路拓扑数据库中获取所有相关的数据。假设细粒度节点数量为n时，用于查询的调用边的ID数目由n²变为n，使整个查询过程的时间复杂度也由O(n²)变为O(n)。

可选地，计算模块还可以通过结合得到的链路追踪信息和每个微服务的采样率，获得链路级别的流量预估值。

本公开中，对于微服务系统中的每个微服务来说，遵循如下的采样规则：

1、每个微服务都可以发起采样；

2、如果上游微服务采样一个用户请求，则下游微服务跟随采样，并上报跨度数据；

3、每个微服务对应的采样率可以调节。

对于微服务系统来说，每个微服务可以自由调节采样率，从而能够灵活控制链路追踪信息的数量。但由于每个微服务的采样率可能不完全相同，因此，本公开采用如下方式获得流量预估值。

具体地，对于某个基准微服务来说，对于其上游的调用边，采用调用边出现的次数除以上游微服务中最大采样率来预估流量；对于下游的调用边，采用调用边出现的次数除以该基准微服务的采样率来预估流量。本方案中，流量可以通过调用次数表示。

在计算获得链路拓扑中每条调用边对应的流量预估值之后，可将每条调用边对应的流量预估值可以作为边属性信息中的一项存储在链路拓扑数据库中，供用户查询。

下面通过几个具体示例说明获得流量预估值的实现方式。

假设有A、B、C、D、E五个微服务，链路拓扑如图1I所示，入口层有A和B两个微服务。A、B、C、D、E五个微服务的采样率依次为：1％、1％、2％、4％、3％，来自A和B入口的流量具有不同的放大比例。

参照图1I所示，微服务A的入口流量为10000，微服务B的入口流量为20000；以微服务A为入口的流量路径沿黑色实线所指，以微服务B为入口的流量路径沿黑色虚线所指。微服务A至E分别对流量的放大比例如调用箭头所示。

在进行流量预估时，先对图1I所示的调用图进行拆分，对每条以微服务C为基准微服务的调用边，如果该调用边为微服务C的上游调用边，则采用调用流量除以源微服务节点的采样率计算；如果该调用边为微服务C的上游调用边，则采用调用流量除以微服务C的采样率计算。

示例性地，图1I中所示的链路拓扑拆分后，可以获得2个调用图，可参照图1J和图1K所示。其中，图1J中示出的是以微服务A为入口时，且各调用边采样得到的调用次数，具体可参照图1J中各边所标记的数值；图1K中示出的是以微服务B为入口时，且各调用边采样得到的调用次数，具体可参照图1K中各边所标记的数值。

需要说明的是，在图1J和图1K所示的情况，均考虑了放大比例。

基于前述的计算方式，进行流量预估，分别获取图1J中各调用边的流量预估值、图1K中各调用边的流量预估值。在最后生成微服务C的链路拓扑中各调用边的流量预估值时，需要将图1J和图1K中相同调用边上的流量预估值进行聚合，从而得到最终的流量预估值。

最终的流量预估值如图1L所示，微服务A至微服务C这条调用边的流量预估值为10000，微服务B至微服务C这条调用边的流量预估值为20000，微服务C至微服务D这条调用边的流量预估值为30000，微服务C至微服务E这条调用边的流量预估值为25000。

可选地，计算模块还可以通过结合得到的链路追踪信息，获得链路级别的请求延时预估值。

示例性地，计算模块可以通过链路拓扑中每条调用边的调用次数以及每次调用分别对应的请求延时，计算获得请求延时平均值，并将该请求延时平均值作为链路拓扑中相应调用边对应的请求延时预估值。

计算模块可对链路拓扑中每条调用边计算请求延时平均值，从而获得链路拓扑中每条调用边的请求延时预估值。调用边对应的请求延时预估值可以作为边属性信息中的一项存储在链路拓扑数据库中，供用户查询。

在应用场景中，若用户查询条件指示返回链路拓扑的流量预估值和/或请求延时信息，则从链路拓扑数据库中从相应调用边的边属性信息中读取流量预估值和/或请求延时信息，并返回给用户即可。

实际应用中，在建立链路拓扑数据库时，还可以根据链路追踪信息，获取预估更多与链路拓扑相关的信息。

图2为本公开一实施例提供的微服务链路拓扑处理方法的流程图。参照图2所示，本实施例提供的方法可以包括：

S201、获取用户输入的针对目标微服务的查询条件；其中，所述查询条件用于指示所述目标微服务的标识。

目标微服务可以为任意的微服务。例如，微服务系统可以包括一个或者多个微服务，其中，每个微服务可以提供不同的功能或者功能集合，目标微服务可以为微服务系统中的任意一个微服务。本公开对于微服务系统以及目标微服务的类型、提供的功能等参数不作限制。

电子设备可以获取用户输入的针对目标微服务的查询条件；其中，查询条件用于指示目标微服务的标识。示例性地，查询条件可以包括：目标微服务的第一节点属性信息，其中，第一节点属性信息可以包括：服务标识、接口标识、集群标识以及机房标识中的一项或多项。

一些实施例中，电子设备可以采用预设算法，并基于查询条件包括的第一节点属性信息，获得目标微服务的标识。

示例性地，预设算法为哈希算法，假设，第一节点属性信息包括目标微服务的服务标识，则电子设备可以对目标微服务的服务标识所对应的字段进行哈希计算，获得第一哈希计算结果，该第一哈希计算结果即为目标微服务的标识。

这里的第一哈希计算结果相当于前文中的A_ID。

另一些实施例中，电子设备可以基于查询条件包括第一节点属性信息，获取目标微服务对应的第二节点属性信息；并采用预设算法，基于第二节点属性信息，获得目标微服务的标识。其中，本公开对于第一节点属性信息和第二节点属性信息包括的哪些具体的属性信息不做限定，例如，第一节点属性信息可以包括粗粒度的节点属性信息，第二节点属性信息可以为细粒度的节点属性信息，即第一节点属性信息的信息量少于第二节点属性信息的信息量。

示例性地，假设，预设算法为哈希算法，第一节点属性信息包括目标微服务的服务标识，第二节点属性信息包括目标微服务的服务标识和接口标识，对比可知，第一节点属性信息为粗粒度节点属性信息，第二节点属性信息为细粒度节点属性信息；结合前述实施例中所示的方式，电子设备可以基于目标微服务的服务标识以及预先创建的索引，获得目标微服务的服务标识和接口标识；再对目标微服务的服务标识和接口标识分别对应的字段按照预设顺序进行拼接，再对拼接后的字段进行哈希计算，获得第二哈希计算结果，该第二哈希计算结果即为目标微服务的标识。

这里的第二哈希计算结果相当于前文中的A_ID_s_o。

当然，电子设备还可以采用其他预设算法基于查询条件包括的第一节点属性信息获取目标微服务的标识，并不限于前述示例的哈希算法。

S202、根据目标微服务的标识，查询链路拓扑数据库，获取目标微服务对应的目标链路拓扑。

其中，链路拓扑数据库用于存储一个或多个微服务分别对应的链路拓扑的信息，所述一个或多个微服务包括上述目标微服务。可选地，若链路拓扑数据库包括多个微服务时，该多个微服务可以属于不同的微服务系统，且每个微服务属于多个微服务系统中的一个。

接下来，以目标微服务为例，说明链路拓扑数据库包括的各微服务对应的链路拓扑的信息。示例性地，目标微服务对应的链路拓扑的信息可以包括：目标微服务、第一微服务以及调用边，其中，第一微服务包括与目标微服务之间存在调用关系的其他微服务，调用边用于表示微服务之间的调用关系，如两个微服务之间发生调用时，可通过调用边表示源微服务节点和目标微服务节点分别是哪个微服务。

一种可能的实现方式，电子设备根据目标微服务的标识查询链路拓扑数据库，首先获取目标微服务；接着，以目标微服务的标识作为查询条件，在链路拓扑数据库中进行查询，获取与目标微服务相关的调用边；由于这些调用边包括了源微服务节点和目标微服务节点的信息，这些调用边所包括源微服务节点和目标微服务节点即为第一微服务；电子设备基于调用边确定目标微服务与第一微服务之间的连接顺序(即上下游关系)；根据目标微服务与第一微服务之间的连接顺序，生成目标微服务对应的目标链路拓扑。

S203、向所述用户返回所述目标链路拓扑。

电子设备可向用户返回从链路拓扑数据库查询得到的目标链路拓扑。示例性地，电子设备可以通过显示单元将目标链路拓扑以图表的形式显示在电子设备的显示屏幕，以将目标链路拓扑展示给用户，供用户查看。

本实施例提供的方法，通过预先将微服务系统中各微服务对应的链路拓扑存储至链路拓扑数据库中，且为微服务对应的链路拓扑配置相应的标识；当用户需要查询目标微服务对应的目标链路拓扑时，可输入针对目标微服务的查询条件，基于该查询条件能够获取微服务对应的标识，并通过目标微服务对应的标识查询链路拓扑数据库，快速获取目标微服务对应的链路拓扑。本方案是通过预先分析获得微服务系统中各微服务对应的链路拓扑，用户可以快速获得要查询的目标微服务的链路拓扑，无需进行“节点订阅-拓扑生成”的等待，从而提高微服务链路拓扑处理效率。

图3为本公开另一实施例提供的微服务链路拓扑处理方法的流程图。参照图3所示，本实施例的方法包括：

S301、获取用户输入的针对目标微服务的查询条件；其中，所述查询条件用于指示所述目标微服务的标识。

S302、根据目标微服务的标识，查询链路拓扑数据库，获取目标微服务对应的目标链路拓扑。

S303、根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标链路拓扑对应的流量信息。

目标微服务对应的流量信息包括目标链路拓扑中每条调用边分别对应的流量信息。其中，流量信息表示调用次数，即，调用边对应的流量信息表示调用边对应的调用次数。

链路拓扑数据库中存储目标微服务对应的目标链路拓扑包括的每条调用边对应的流量信息。

一些实施例中，电子设备可根据用户输入的针对目标微服务的查询条件确定需要查询目标微服务对应的流量信息。例如，查询条件可以包括：第一指示信息，其中，第一指示信息用于指示查询目标微服务对应的流量信息。

示例性地，电子设备可以向用户提供第一指示信息对应的选择控件(也可以称为：流量查询控件)；当电子设备检测到用户针对该流量查询控件的选中操作时，电子设备根据选中操作确定需要查询目标微服务对应的流量信息，并根据目标微服务的标识查询目标链路拓扑包括的调用边，并获取每条调用边对应的流量信息。

其中，用户输入针对目标微服务的查询条件可以是通过手动操作电子设备的触摸屏幕输入，或者，也可以是通过操作外部输入设备(如键鼠设备)输入，或者，还可以是通过语音的方式输入，本公开对于输入方式不作限定。

S304、向所述用户返回所述目标服务对应的目标链路拓扑以及目标链路拓扑对应的流量信息。

电子设备可向用户返回从链路拓扑数据库查询得到的目标链路拓扑以及目标链路拓扑中每条调用边对应的流量信息。其中，每条调用边对应的流量信息即为前述实施例中的流量预估值，计算流量预估值的算法细节，可参照前述中的描述，简明起见，此处不再赘述，

示例性地，电子设备可以通过显示屏幕将目标链路拓扑以图表的形式展示给用户，且将目标链路拓扑中每条调用边对应的流量信息显示在所述调用边对应的位置，供用户查看。

本实施例提供的方法，通过预先将微服务系统中各微服务对应的链路拓扑以及各链路拓扑信息的流量信息存储至链路拓扑数据库中，且为微服务对应的链路拓扑配置相应的标识；当用户需要查询目标微服务对应的目标链路拓扑时，可输入针对目标微服务的查询条件，基于该查询条件能够获取微服务对应的标识，并通过目标微服务对应的标识查询链路拓扑数据库，快速获取目标微服务对应的链路拓扑以及相应的流量信息。本方案是通过预先分析获得微服务系统中各微服务对应的链路拓扑，用户可以快速获取要查询的目标微服务的链路拓扑，无需进行“节点订阅-拓扑生成”的等待，从而提高微服务链路拓扑处理效率。且预先对链路拓扑的流量进行了预估，用户还可以查询链路拓扑的流量信息，满足了用户多样化的查询需求，且为微服务系统的调整提供依据。

图4为本公开另一实施例提供的微服务链路拓扑处理方法的流程图。参照图4所示，本实施例的方法包括：

S401、获取用户输入的针对目标微服务的查询条件；其中，所述查询条件用于指示所述目标微服务的标识。

S402、根据目标微服务的标识，查询链路拓扑数据库，获取目标微服务对应的目标链路拓扑。

S403、根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标链路拓扑对应的请求延时信息。

目标微服务对应的请求延时信息包括目标链路拓扑中每条调用边分别对应的请求延时信息。

链路拓扑数据库中存储目标微服务对应的目标链路拓扑包括的每条调用边对应的请求延时信息。

其中，请求延时信息即为前述实施例中的请求延时预估值。

一些实施例中，电子设备可根据用户输入的针对目标微服务的查询条件确定需要查询目标微服务对应的请求延时信息。例如，查询条件可以包括：第二指示信息，其中，第二指示信息用于指示查询目标微服务对应的请求延时信息。

示例性地，电子设备可以向用户提供第二指示信息对应的选择控件(也可以称为：请求延时查询控件)；当电子设备检测到用户针对该请求延时查询控件的选中操作时，电子设备根据选中操作确定需要查询目标微服务对应的请求延时信息，并根据目标微服务的标识查询目标链路拓扑包括的调用边，并获取每条调用边对应的请求延时信息。

其中，用户输入针对目标微服务的查询条件可以是通过手动操作电子设备的触摸屏幕输入，或者，也可以是通过操作外部输入设备(如键鼠设备)输入，或者，还可以是通过语音的方式输入，本公开对于输入方式不作限定。

S404、向所述用户返回所述目标服务对应的目标链路拓扑以及目标链路拓扑对应的请求延时信息。

电子设备可向用户返回从链路拓扑数据库查询得到的目标链路拓扑以及目标链路拓扑中每条调用边对应的请求延时信息。

示例性地，电子设备可以通过显示单元将目标链路拓扑以图表的形式展示给用户，且将目标链路拓扑中每条调用边对应的请求延时信息显示在所述调用边对应的位置，供用户查看。

本实施例提供的方法，通过预先将微服务系统中各微服务对应的链路拓扑以及各链路拓扑信息的请求延时信息存储至链路拓扑数据库中，且为微服务对应的链路拓扑配置相应的标识；当用户需要查询目标微服务对应的目标链路拓扑时，可输入针对目标微服务的查询条件，基于该查询条件能够获取微服务对应的标识，并通过目标微服务对应的标识查询链路拓扑数据库，快速获取目标微服务对应的链路拓扑以及相应的请求延时信息。本方案是通过预先分析获得微服务系统中各微服务对应的链路拓扑，用户可以直接查询目标微服务的链路拓扑，无需进行“节点订阅-拓扑生成”的等待，提高微服务链路拓扑处

理效率。且预先对链路拓扑的请求延时情况进行了预估，用户还可以查询链路拓扑的请求延时信息，满足了用户多样化的查询需求，且为微服务系统的调整提供依据。

图5为本公开另一实施例提供的微服务链路拓扑处理方法的流程图。参照图5所示，本实施例提供的方法包括：

S501、获取一个或多个微服务分别基于预设时长内的用户请求生成的链路追踪信息。

电子设备可获取微服务系统中微服务间实时调用产生的链路追踪信息。

一种可能的实现方式，可在微服务系统中的各个微服务框架和组件中设置埋点。当微服务间发生调用时，埋点能够采集本次调用的相关信息，(例如数据包大小、请求延时、服务名、时间等信息)，并将采集到的相关信息组织成预设数据格式上报至电子设备。其中，上述预设数据格式的信息即为链路追踪信息。

结合前述图1A所示实施例的描述，在微服务系统中，当发生调用时，埋点会在接收到用户请求时产生一个服务端跨度数据，当微服务向其他微服务送用户请求时产生一个客户端跨度数据；所有的服务端跨度数据和客户端跨度数据构成了本次调用的链路追踪，且这些服务端跨度数据和客户端跨度数据中记录相同的链路追踪标识，电子设备基于链路追踪标识，可以确定用户请求调用的所有微服务以及微服务之间的调用关系。

在实际应用中，埋点也可以实时采集微服务的链路追踪信息，并上报给电子设备。

S502、根据所述链路追踪信息，获取每个所述用户请求对应的调用图；所述调用图包括：所述用户请求调用的各微服务和用于表示微服务之间的调用关系的调用边。

如前所述，链路追踪信息包括链路追踪标识，电子设备可通过分析链路追踪标识，确定具有相同链路追踪标识的微服务；再通过分析具有相同链路追踪标识的链路追踪信息中服务端跨度数据和客户端跨度数据，确定微服务之间的调用关系；基于调用关系，电子设备可以生成每个用户请求对应的调用图。

在实际应用中，埋点可以实时采集微服务的链路追踪信息，并上报给电子设备。相应地，电子设备可以实时地对链路追踪信息进行分析，不断更新数据。

可选地，电子设备还可以对具有相同调用链路模式的调用图进行聚合，去除重复的调用图，减少数据冗余。示例性地，可根据调用图标识(即调用图ID)进行聚合，调用图ID可以是通过对调用图包括的微服务的节点属性信息和调用边的边属性信息对应的字段进行哈希计算获得。若调用图ID相同，则表示调用图具有相同的结构，即调用链路模式相同；若调用图ID不同，则表示调用图具有不同的结构，即调用链路模式不同。

对具有相同调用链路模式的调用图进行聚合处理的具体方式，可参照上述图1C所示实施例的描述。

S503、针对每个所述调用图中的每个微服务，遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑。

针对每个调用图中的每个微服务，电子设备将该微服务作为基准微服务(也可以理解为基准节点)，遍历其所属的调用图，保留与基准微服务相关的直接上游调用边和所有下游调用边，剔除与基准微服务无依赖关系的调用边，从而获得基准微服务对应的链路拓扑。

例如前文中图1C所示实施例，采用回溯的方式对调用图进行遍历，获得各基准微服务对应的链路拓扑，简明起见，此处不再赘述。

一些情况下，电子设备还可以进一步对各微服务分别对应的链路拓扑进行聚合处理，去除重复的链路拓扑。其中，对微服务的链路拓扑进行聚合处理，可以根据“基准节点+源微服务节点+目标微服务节点”的组合进行聚合，去除处重复的链路拓扑，提高存储资源利用率。

由于用户的查询需求不同，一些情况下可能需要查询粗粒度的链路拓扑；一些情况下可能需要基于粗粒度的查询条件，查询细粒度的链路拓扑。

一些实施例中，电子设备可以通过基准微服务对应的第一节点属性信息计算基准微服务的标识；根据基准微服务的标识，配置该基准微服务对应的链路拓扑包括的所有调用边的标识。

例如，微服务A为基准微服务，基于微服务A的服务标识、接口标识、集群标识以及机房标识中的一项或者多项对应的字段，进行哈希计算，确定微服务A的标识为A_ID；则根据A_ID配置微服务A对应的目标链路拓扑中所有调用边的标识。其中，基准微服务对应的链路拓扑包括的其他微服务，可根据各自的节点属性信息进行计算，获得各自的标识，并以各自的标识进行存储。

这样的方式能够使链路拓扑数据库具备粗粒度的查询能力，能够较快地返回查询结果，满足用户的查询需求。

另一些实施例中，电子设备还可以基于微服务对应的细粒度节点，对微服务对应的链路拓扑进行进一步的拆分，获得微服务对应的细粒度的链路拓扑。相应地，电子设备还可以通过基准微服务的第二节点属性信息计算基准微服务对应的细粒度的标识；根据基准微服务对应的细粒度的标识，配置该基准微服务对应的细粒度的链路拓扑包括的所有调用边的标识。

且为了满足用户基于粗粒度的查询条件，查询细粒度的链路拓扑的需求，还可以建立预设索引，实现查询条件所包括的粗粒度节点属性信息(即第一节点属性信息)到细粒度节点属性信息(即第二节点属性信息)的映射。

关于预设索引的具体实现方式，可以参照前述实施例中的详细描述，简明起见，此处不再赘述。

为了保证链路拓扑数据库能够提供基于粗粒度的节点属性信息以及预设索引，查询细粒度的链路拓扑的能力，需要对各微服务对应的链路拓扑进行一些相关的配置。因此，可以通过下述两种情形进行配置：

情形1：针对不同的细粒度节点的下游调用边，配置不同的标识。

可针对不同接口的下游调用边基于接口的标识进行配置，不同的接口的下游调用边的标识不同。

例如，前述图1F和图1G所示实施例，针对接口1的下游调用边，配置标识为A_ID＝123；针对接口2对应的下游调用边，配置标识A_ID＝456。

情形2：针对不同的细粒度节点的下游调用边，基于基准微服务的细粒度标识配置相同的标识。

可基于基准微服务对应的细粒度节点，计算基准微服务对应细粒度标识，再根据基准微服务对应细粒度标识配置所有细粒度节点的下游调用边。

例如，前述图1H所示实施例，针对微服务A对应的接口1和接口2，均根据微服务A的细粒度标识，即A_ID_s_o＝999，配置接口1对应的下游调用边和接口2对应的下游调用边。参照图1H可知，接口1和接口2分别对应的下游调用边的标识相同。

这样的方式能够使链路拓扑数据库具备细粒度的查询能力，能够较快地返回细粒度的查询结果，满足用户的查询需求。

S504、根据每个所述微服务对应的链路拓扑，获取所述链路拓扑数据库，其中，所述每个所述微服务包括所述目标微服务。

电子设备将每个微服务对应的链路拓扑存储至链路拓扑数据库中，当用户需要查询某个微服务的链路拓扑时，可根据用户输入的查询条件从链路拓扑数据库中读取相应的数据，聚合之后，以图表的形式返回给用户即可。

本实施例提供的方法，通过采集微服务的链路追踪信息，并分析链路追踪信息获得用户请求级别的调用图；再对调用图进行拆分、剪枝、聚合等等处理，获取微服务对应的链路拓扑；将各微服务对应的链路拓扑存储至链路拓扑数据库，以供用户查询。由于链路拓扑数据库中存储的各微服务对应的链路拓扑是预先生成的，用户可以快速获取想要查询的目标微服务对应的链路拓扑，无需进行“节点订阅-拓扑生成”的等待，从而有效提高微服务链路拓扑处理效率。

图6为本公开另一实施例提供的微服务链路拓扑处理方法的流程图。在图5所示实施例的基础上，本公开还可以对链路拓扑的流量进行分析，以满足用户查询链路拓扑的流量的需求。其中，本实施例的方法可以在图5所示实施例之后执行。

参照图6所示，本实施例的方法包括：

S601、针对每个所述微服务对应的链路拓扑，根据所述链路拓扑的入口微服务以及流量路径，拆分所述链路拓扑，获取所述微服务对应的至少一个子链路拓扑。

具体地，针对每个微服务对应的链路拓扑，可基于入口微服务以及流量路径，对链路拓扑进行拆分，获得每条流量路径对应的子链路拓扑。由于不同入口微服务对应的流量路径不同，会影响每条调用边的调用次数，因此，本方案需要先依据流量路径，对目标链路拓扑进行拆分。

例如，图1I、图1J以及图1K所示的情况，分别以微服务A和微服务B为入口，进行拆分，获得2个子拓扑链路。

S602、针对每个所述子链路拓扑，根据所述子链路拓扑中包括的每个微服务的采样率和所述链路拓扑的入口微服务的调用次数，获取所述子链路拓扑包括的每条调用边的第一流量信息。

具体地，本公开计算每条调用边的流量预估值时，上游调用边和下游调用边所采用的计算方式不同。

若调用边为所述微服务的上游调用边，则根据所述调用边的调用次数与所述微服务的上游微服务中的最大采样率之间的比值，获取所述调用边的第一流量信息；

若所述调用边为所述微服务的下游调用边，则根据所述调用边的调用次数与所述微服务的采样率之间的比值，获取所述调用边的第一流量信息。

例如图1I所示的情况，针对微服务C的上游调用边，则采用调用次数除以源微服务节点的采样率计算；如果该调用边为微服务C的上游调用边，则采用调用次数除以微服务C的采样率计算。

其中，调用次数可以依据入口流量、调用边的流量放大比例以及源微服务节点的采样率进行计算。

S603、将所有所述子链路拓扑中相同调用边的第一流量信息进行，获取所述链路拓扑中每条调用边分别对应的流量信息。

示例性地，参照图1I至图1K所示实施例中的方式，将各调用边的流量预估值进行相加，获得每条调用边最终的流量预估值，即调用边对应的流量信息。

将各调用边对应的流量信息作为调用边的边属性信息中的一项，存储在链路拓扑数据库中，以供用户查询。

本实施例通过分析链路追踪信息，并结合各微服务的采样率，获得较为准确的流量预估值，能够满足用户对于链路拓扑的流量信息查询的需求，为用户对微服务系统的系统容量进行调整提供依据。

图7为本公开另一实施例提供的微服务链路拓扑处理方法的流程图。在图5所示实施例的基础上，本公开还可以对链路拓扑的请求延时进行分析，以满足用户查询链路拓扑的请求延时的需求。其中，本实施例的方法可以在图5所示实施例之后执行。

参照图7所示，本实施例的方法包括：

S701、针对所述链路拓扑中每条调用边，获取所述调用边在每次调用分别对应的请求延时。

S702、根据所述调用边在每次调用分别对应的请求延时以及所述调用边对应的调用次数，获取请求延时平均值。

S703、根据所述请求延时平均值，获取所述调用边对应的请求时延信息。

具体地，电子设备可通过链路追踪信息，获得调用边在每次调用时的请求延时；针对每条调用边，根据调用次数以及每次调用的请求延时，计算请求延时平均值；该请求延时平均值即为调用边的请求延时预估信息，即调用边对应的请求延时信息。

本实施例通过分析链路追踪信息包括的请求延时信息，并结合微服务间的调用次数，获得较为准确的请求延时预估信息，能够满足用户对于链路拓扑的请求延时查询的需求，为用户对微服务系统的系统容量进行调整提供依据。

示例性地，本公开还提供一种微服务链路拓扑处理装置。

图8为本公开一实施例提供的微服务链路拓扑处理装置的结构示意图。参照图8所示，本实施例提供的微服务链路拓扑处理装置800包括：

获取模块801，用于获取用户输入的针对目标微服务的查询条件；所述查询条件用于指示所述目标微服务的标识；

处理模块802，用于根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑；所述链路拓扑数据库用于存储一个或多个微服务对应的链路拓扑的信息，所述一个或多个微服务包括所述目标微服务；

发送模块803，用于向所述用户返回所述目标链路拓扑。

在一些可能的实施方式中，处理模块，具体用于根据所述目标微服务的标识，查询所述链路拓扑数据库，获取与所述目标微服务关联的调用边；所述链路拓扑数据库中用于生成所述目标链路拓扑的所述目标微服务以及所述调用边具有相同的标识；根据所述调用边对应的源微服务节点信息和目标微服务节点信息，确定所述第一微服务，以及所述目标微服务与所述第一微服务之间的连接顺序；其中，所述第一微服务包括与所述目标微服务具有调用关系的微服务；根据所述目标微服务与所述第一微服务之间的连接顺序，生成所述目标微服务对应的目标链路拓扑。

在一些可能的实施方式中，查询条件包括所述目标微服务对应的第一节点属性信息；所述目标微服务的标识是通过对所述查询条件包括的第一节点属性信息进行哈希计算获得的。

在一些可能的实施方式中，查询条件包括所述目标微服务对应的第一节点属性信息；所述目标微服务的标识是通过对所述目标微服务的第二节点属性信息进行哈希计算获得的；所述第二节点属性信息是根据所述查询条件包括的第一节点属性信息以及所述目标微服务对应的预设索引获得的，所述预设索引用于将所述第一节点属性信息映射为所述第二节点属性信息。

在下一些可能的实施方式中，若所述查询条件还包括：第一指示信息，所述第一指示信息用于指示查询所述目标微服务对应的流量信息；处理模块，还用于根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标微服务对应的流量信息，其中，所述目标微服务对应的流量信息包括所述目标链路拓扑中每条调用边上的流量信息；所述链路拓扑数据库包括所述目标链路拓扑对应的流量信息。

在一些可能的实施方式中，若所述查询条件还包括：第二指示信息，所述第二指示信息用于指示查询所述目标微服务对应的目标请求延时信息；处理模块，还用于根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标微服务对应的目标请求延时信息，其中，所述目标微服务对应的目标请求延时信息包括所述目标链路拓扑中每条调用边分别对应的目标请求延时信息；所述链路拓扑数据库包括所述目标链路拓扑对应的目标请求延时信息。

在一些可能的实施方式中，微服务链路拓扑处理装置800还包括：采集模块804、计算模块805以及存储模块806。

其中，采集模块804，用于获取一个或多个微服务分别基于预设时长内的用户请求生成的链路追踪信息。

计算模块805，用于根据所述链路追踪信息，获取每个所述用户请求对应的调用图；所述调用图包括：所述用户请求调用的各微服务和用于表示微服务之间的调用关系的调用边；针对每个所述微服务，遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑。

存储模块806，用于存储微服务对应的链路拓扑，其中，所述一个或者多个微服务包括所述目标微服务。

其中，存储模块806可以为链路拓扑数据库。本公开对于链路拓扑数据库的容量、类型以及其他相关参数不做限定。

在一些可能的实施方式中，计算模块805，还用于对每个所述微服务对应的链路拓扑进行聚合处理，以去除重复的链路拓扑。

在一些可能的实施方式中，计算模块805，还用于针对每个所述微服务对应的链路拓扑，根据所述微服务的第一节点属性信息，配置所述微服务对应的链路拓扑包括所有微服务和调用边的标识；和/或

针对每个所述微服务对应的链路拓扑，根据所述微服务的第二节点属性信息，配置所述微服务对应的链路拓扑包括所有微服务和调用边的标识。

在一些可能的实施方式中，计算模块805，还用于针对每个所述微服务对应的目标链路拓扑，获取预设索引，其中，所述预设索引用于将所述第一节点属性信息映射为所述第二节点属性信息。

在一些可能的实施方式中，每个所述微服务对应的链路拓扑采用基准微服务、源微服务节点以及目标微服务节点的数据格式存储于所述存储模块806。

在一些可能的实施方式中，针对每个所述微服务遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑之前，计算模块805，还用于对具有相同结构的调用图进行聚合处理，以将具有相同结构的调用图合并。

在一些可能的实施方式中，计算模块805，具体用于根据所述调用图对应的调用图标识，对具有相同结构的调用图进行聚合处理，其中，具有相同结构的调用图的调用图标识相同。

在一些可能的实施方式中，计算模块805，还用于针对每个所述微服务对应的链路拓扑，根据所述链路拓扑的入口微服务以及流量路径，拆分所述链路拓扑，获取所述微服务对应的至少一个子链路拓扑；针对每个所述子链路拓扑，根据所述子链路拓扑中包括的每个微服务的采样率和所述链路拓扑的入口微服务的调用次数，获取所述子链路拓扑包括的每条调用边的第一流量信息；其中，所述链路拓扑的入口微服务的调用次数是根据所述链路追踪信息获得；将所有所述子链路拓扑中相同调用边的第一流量信息进行相加，获取所述链路拓扑中每条调用边分别对应的流量信息。

在一些可能的实施方式中，计算模块805，具体用于通过下述方式获取子链路拓扑包括的每条调用边的第一流量信息：

针对所述微服务的上游调用边，根据所述调用边的调用次数与所述微服务的上游微服务中的最大采样率之间的比值，获取所述调用边的第一流量信息；针对所述微服务的下游调用边，根据所述调用边的调用次数与所述微服务的采样率之间的比值，获取所述调用边的第一流量信息。

在一些可能的实施方式中，计算模块805，还用于针对每个所述微服务对应的链路拓扑包括的每条调用边，获取所述调用边在每次调用分别对应的请求延时；根据所述调用边在每次调用分别对应的请求延时、以及所述调用边对应的调用次数，获取请求延时平均值；根据所述请求延时平均值，获取所述调用边对应的请求时延信息。

本实施例提供的微服务链路拓扑处理装置可以用于执行前述任一实施例提供的微服务链路拓扑处理方法，其实现原理以及技术效果类似，可参照前述方法实施例的详细描述，简明起见，此处不再赘述。

示例性地，本公开还提供一种电子设备。

图9为本公开一实施例提供的电子设备的结构示意图。参照图9所示，本实施例提供的电子设备900包括：存储器901和处理器902。

其中，存储器901可以是独立的物理单元，与处理器902可以通过总线903连接。存储器901、处理器902也可以集成在一起，通过硬件实现等。

存储器901用于存储程序指令，处理器902调用该程序指令，执行以上任一方法实施例提供的微服务链路拓扑处理方法。

可选地，当上述实施例的方法中的部分或全部通过软件实现时，上述电子设备900也可以只包括处理器902。用于存储程序的存储器901位于电子设备900之外，处理器902通过电路/电线与存储器连接，用于读取并执行存储器中存储的程序。

处理器902可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。

处理器902还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmablelogic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gatearray，FPGA)，通用阵列逻辑(generic array logic，GAL)或其任意组合。

存储器901可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器也可以包括非易失性存储器(non-volatilememory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器还可以包括上述种类的存储器的组合。

本公开还提供一种可读存储介质，包括：计算机程序指令，所述计算机程序指令被电子设备的至少一个处理器执行时，使得所述电子设备实现如上任一方法实施例提供的微服务链路拓扑处理方法。

本公开还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机实现如上任一方法实施例提供的微服务链路拓扑处理方法。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (20)

1.一种微服务链路拓扑处理方法，其特征在于，包括：

获取用户输入的针对目标微服务的查询条件；所述查询条件用于指示所述目标微服务的标识；

根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑；所述链路拓扑数据库用于存储一个或多个微服务分别对应的链路拓扑，所述一个或多个微服务包括所述目标微服务；

向所述用户返回所述目标链路拓扑。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑，包括：

根据所述目标微服务的标识，查询所述链路拓扑数据库，获取与所述目标微服务关联的调用边；所述链路拓扑数据库中用于生成所述目标链路拓扑的所述目标微服务以及所述调用边具有相同的标识；

根据所述调用边对应的源微服务节点信息和目标微服务节点信息，确定第一微服务，以及所述目标微服务与所述第一微服务之间的连接顺序；其中，所述第一微服务包括与所述目标微服务具有调用关系的微服务；

根据所述目标微服务与所述第一微服务之间的连接顺序，生成所述目标微服务对应的目标链路拓扑。

3.根据权利要求1所述的方法，其特征在于，所述查询条件包括所述目标微服务对应的第一节点属性信息；

所述目标微服务的标识是通过对所述查询条件包括的第一节点属性信息进行哈希计算获得的。

4.根据权利要求1所述的方法，其特征在于，所述查询条件包括所述目标微服务对应的第一节点属性信息；

所述目标微服务的标识是通过对所述目标微服务的第二节点属性信息进行哈希计算获得的；所述第二节点属性信息是根据所述查询条件包括的第一节点属性信息以及所述目标微服务对应的预设索引获得的，所述预设索引用于将所述第一节点属性信息映射为所述第二节点属性信息。

5.根据权利要求1所述的方法，其特征在于，若所述查询条件还包括：第一指示信息，所述第一指示信息用于指示查询所述目标微服务对应的流量信息；所述方法还包括：

根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标微服务对应的流量信息，其中，所述目标微服务对应的流量信息包括所述目标链路拓扑中每条调用边上的流量信息；所述链路拓扑数据库包括所述目标链路拓扑对应的流量信息。

6.根据权利要求1所述的方法，其特征在于，若所述查询条件还包括：第二指示信息，所述第二指示信息用于指示查询所述目标微服务对应的目标请求延时信息；所述方法还包括：

根据所述目标微服务的标识，从所述链路拓扑数据库中获取所述目标微服务对应的目标请求延时信息，其中，所述目标微服务对应的目标请求延时信息包括所述目标链路拓扑中每条调用边分别对应的目标请求延时信息；所述链路拓扑数据库包括所述目标链路拓扑对应的目标请求延时信息。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述获取用户输入的针对目标微服务的查询条件之前，还包括：

获取一个或多个微服务分别基于预设时长内的用户请求生成的链路追踪信息；

根据所述链路追踪信息，获取每个所述用户请求对应的调用图；所述调用图包括：所述用户请求调用的各微服务和用于表示微服务之间的调用关系的调用边；

针对每个所述微服务，遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑；

根据每个所述微服务对应的链路拓扑，获取所述链路拓扑数据库，其中，所述一个或者多个微服务包括所述目标微服务。

8.根据权利要求7所述方法，其特征在于，所述根据每个所述微服务对应的链路拓扑，获取所述链路拓扑数据库之前，还包括：

对每个所述微服务对应的链路拓扑进行聚合处理，以去除重复的链路拓扑。

9.根据权利要求7所述的方法，其特征在于，所述方法还包括：

针对每个所述微服务对应的链路拓扑，根据所述微服务的第一节点属性信息，配置所述微服务对应的链路拓扑包括所有微服务和调用边的标识；和/或

针对每个所述微服务对应的链路拓扑，根据所述微服务的第二节点属性信息，配置所述微服务对应的链路拓扑包括所有微服务和调用边的标识。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

针对每个所述微服务对应的目标链路拓扑，获取预设索引，其中，所述预设索引用于将所述第一节点属性信息映射为所述第二节点属性信息。

11.根据权利要求7所述的方法，其特征在于，每个所述微服务对应的链路拓扑采用基准微服务、源微服务节点以及目标微服务节点的数据格式存储于所述链路拓扑数据库中。

12.根据权利要求7所述的方法，其特征在于，所述针对每个所述微服务，遍历所述微服务所属的调用图，获取所述微服务对应的链路拓扑之前，还包括：

对具有相同结构的调用图进行聚合处理，以将具有相同结构的调用图合并。

13.根据权利要求12所述的方法，其特征在于，所述对具有相同结构的调用图进行聚合处理，包括：

根据所述调用图对应的调用图标识，对具有相同结构的调用图进行聚合处理，其中，具有相同结构的调用图的调用图标识相同。

14.根据权利要求7所述的方法，其特征在于，所述方法还包括：

针对每个所述微服务对应的链路拓扑，根据所述链路拓扑的入口微服务以及流量路径，拆分所述链路拓扑，获取所述微服务对应的至少一个子链路拓扑；

针对每个所述子链路拓扑，根据所述子链路拓扑中包括的每个微服务的采样率和所述链路拓扑的入口微服务的调用次数，获取所述子链路拓扑包括的每条调用边的第一流量信息；其中，所述链路拓扑的入口微服务的调用次数是根据所述链路追踪信息获得；

将所有所述子链路拓扑中相同调用边的第一流量信息进行相加，获取所述链路拓扑中每条调用边分别对应的流量信息。

15.根据权利要求14所述的方法，其特征在于，所述根据所述子链路拓扑中包括的每个微服务的采样概率和所述目标链路拓扑的入口微服务的调用次数，获取所述子链路拓扑包括的每条调用边的第一流量信息，包括：

针对所述微服务的上游调用边，根据所述调用边的调用次数与所述微服务的上游微服务中的最大采样率之间的比值，获取所述调用边的第一流量信息；

针对所述微服务的下游调用边，根据所述调用边的调用次数与所述微服务的采样率之间的比值，获取所述调用边的第一流量信息。

16.根据权利要求7所述的方法，其特征在于，所述方法还包括：

针对每个所述微服务对应的链路拓扑包括的每条调用边，获取所述调用边在每次调用分别对应的请求延时；

根据所述调用边在每次调用分别对应的请求延时、以及所述调用边对应的调用次数，获取请求延时平均值；

根据所述请求延时平均值，获取所述调用边对应的请求时延信息。

17.一种微服务链路拓扑处理装置，其特征在于，包括：

获取模块，用于获取用户输入的针对目标微服务的查询条件；所述查询条件用于指示所述目标微服务的标识；

处理模块，用于根据所述目标微服务的标识，查询链路拓扑数据库，获取所述目标微服务对应的目标链路拓扑；所述链路拓扑数据库用于存储一个或多个微服务对应的链路拓扑的信息，所述一个或多个微服务包括所述目标微服务；

发送模块，用于向所述用户返回所述目标链路拓扑。

18.一种电子设备，其特征在于，包括：存储器和处理器；

所述存储器被配置为存储计算机程序指令；

所述处理器被配置为执行所述计算机程序指令，以实现如权利要求1至16任一项所述的微服务链路拓扑处理方法。

19.一种可读存储介质，其特征在于，包括：计算机程序指令；

所述计算机程序指令被电子设备的至少一个处理器执行，以实现如权利要求1至16任一项所述的微服务链路拓扑处理方法。

20.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1至16任一项所述的微服务链路拓扑处理方法。

Images