CN111913818B - 一种确定服务间依赖关系的方法及相关装置 - Google Patents

Abstract

本申请实施例公开了一种确定服务间依赖关系的方法及相关装置，该方法应用于业务系统，所述业务系统部署了全链路监控系统jaeger，所述方法包括：通过全链路监控系统jaeger获取调用接口时的追踪信息span；将所述追踪信息span传入分布式消息队列kafka中；消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定父span对应的服务；根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系。采用本申请实施例，能够灵活获取服务间依赖关系。

Description

一种确定服务间依赖关系的方法及相关装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种确定服务间依赖关系的方法及相关装置。

背景技术

jaeger是由uber公司开源，基于opentracing协议的分布式全链路监控系统，用户在自己的业务系统接入jaeger后，可以在调用接口时，产生追踪信息并记录接口处理的状态信息及上游调用组件信息，并上报到jaeger中。一般用户接入全链路监控系统jaeger的业务系统是分布式或微服务架构的复杂系统，因此会产生非常多的追踪信息，而这些追踪信息可以帮助用户了解到业务系统内各个组件间的使用状况。但是用户在使用的过程中，由于接入了jaeger的业务系统的规模很复杂，链路追踪信息数据量很大，从运维人员的使用需求来看，通常希望先从宏观的角度了解当前业务系统中各组件的接口服务情况，从而确认当前业务系统的健康状态乃至异常组件。

然而，jaeger的依赖关系计算组件spark-dependency只能计算一整天内的服务依赖关系，无法满足任意时间段内的依赖关系查询需求，如何在接入了jaeger的业务系统中灵活获取服务依赖关系是本领域技术人员正在研究的技术问题。

发明内容

本申请实施例公开了一种确定服务间依赖关系的方法及相关装置，能够灵活获取服务间依赖关系。

第一方面，本申请实施例提供了一种确定服务间依赖关系的方法，应用于业务系统，所述业务系统部署了全链路监控系统jaeger，所述方法包括：

通过全链路监控系统jaeger获取调用接口时的追踪信息span；

将所述追踪信息span传入分布式消息队列kafka中；

消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务；

根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系。

第二方面，本申请实施例提供了一种确定服务间依赖关系的装置，应用于业务系统，所述业务系统部署了全链路监控系统jaeger，所述装置包括：

获取模块，用于通过全链路监控系统jaeger获取调用接口时的追踪信息span；

传输模块，用于将所述追踪信息span传入分布式消息队列kafka中；

消费模块，用于消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务；

生成模块，用于根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系。

第三方面，本申请实施例提供了一种电子设备，所述电子设备包括处理器、存储器、通信接口以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置由所述处理器执行，所述程序包括用于执行本申请第一方面任一方法中的步骤的指令。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行以实现本申请第一方面任一方法中所描述的部分或全部步骤。

通过实施本申请实施例，在不破坏全链路监控系统jaeger的原生数据处理逻辑的情况下，额外引入分布式消息队列kafka作为数据收集过程的缓冲中间件，然后消费(例如，通过自研的dependency-plugin组件进行消费)kafka中的数据，定时批处理span，采用这种方法，由于额外引入分布式消息队列kafka，因此计算服务间依赖关系不需要依赖于jaeger的原生数据处理逻辑来一天计算一次，而是基于kafka定时批处理的特性实时计算span所代表的服务间依赖关系。

此外，由于计算服务依赖关系的组件以费者组的形式连接分布式消息队列kafka，因此可实现分布式计算服务间依赖关系，分布式的架构可满足业务高峰的容量要求，并且，通过分布式消息队列kafka的解耦作用，在业务峰值时，本申请新提出的服务集依赖关系计算流程基本不影响原有jaeger的性能。

另外，通过引入循环队列的LRU淘汰算法及缓存的定时过期机制，实时清楚过期的span，在满足峰值流量时，可保障计算服务的可用性。

并且，上述方法可兼容多种链路追踪协议，例如opentracing、zipkin等协议。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种接入了jaeger的业务系统的架构示意图；

图2是本申请实施例提供的又一种接入了jaeger的业务系统的架构示意图；

图3是本申请实施例提供的一种确定服务间依赖关系的方法的流程示意图；

图4是本申请实施例提供的一种确定服务间依赖关系的方法的流程示意图；

图5是本申请实施例提供的一种确定服务间依赖关系的装置的结构示意图；

图6是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行描述。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

请参见图1，图1是本申请实施例提供的一种接入了jaeger的业务系统的架构示意图，业务系统包括用户应用、jeager-collector和存储组件(storage)，其中：

用户应用，用于直接将链路追踪信息(span)推送到jaeger-collector中，其中，用户应用可以是一个也可以是多个，图1中n个为例进行示意。

分布式全链路监控系统端口jaeger-collector，用于将链路追踪信息(span)存入当前配置的存储组件storage中，完成数据的处理和落地。

图1是一种常规的接入了jaeger的业务系统，其只能计算一整天内的服务依赖关系，无法满足任意时间段内的依赖关系查询需求，因此，本申请申请人在图1所示的业务系统的基础上进行了优化，在jaeger-collector收集到数据之后，新增一条计算服务间依赖关系的处理逻辑，新增的处理逻辑需要基于新的业务系统架构来实现，请参见图2，是本申请实施例提供的又一种接入了jaeger的业务系统的架构示意图，该业务系统除了包括图1中的用户应用、jeager-collector和存储组件之外，还包括分布式消息队列kafka和计算组件(dependency-plugin)，其中：

jaeger-collector，用于将数据(如span)进行处理并传入分布式消息队列kafka中。

分布式消息队列kafka，用于作为中间件缓存待处理数据，保障数据传输的可靠性。

计算组件(dependency-plugin)，用于以消费组的形式连接分布式消息队列kafka，再从分布式消息队列kafka中消费相关数据并计算得出每个span的所代表的服务依赖关系，并保存服务依赖关系到相关的存储组件中。

当然，上述接入了jaeger的业务系统中还可以包括其他组件，例如，包括jaeger中的某些组件；再如，包括业务系统中除jaeger外的部分中的常规组件。

需要说明的是，上述图1所示的业务系统、图2所示的业务系统所依托的硬件设备可以为一台服务器，或者由多台服务器组成的服务器集群，或者其他具有计算能力的设备。后续相应操作的执行主体如果是电子设备，则应当理解可以等同替换为服务器，或者服务器集群，或者其他具有计算能力的设备。

请参见图3，图3是本申请实施例提供的一种全链路监控系统服务间依赖关系确定方法的流程示意图，该方法可以基于图2所示的架构来实现，也可以基于其他接入了jaeger的业务系统来实现，该方法包括但不限于如下步骤：

步骤S301：电子设备通过jaeger获取调用接口时的追踪信息span。

其中，该电子设备部署了业务系统，该业务系统用于支持用户完成相应的业务。本申请实施例中，该业务系统中部署了分布式全链路监控系统jaeger，因此，该电子设备可以通过jaeger获取调用接口的追踪信息span。

需要说明的是，在接入了分布式全链路监控系统jaeger的业务系统中，发生接口调用请求时，会产生全局唯一的追踪标识traceID，代表此次接口调用请求在jaeger中的唯一性，而接口调用请求过程中的组件进行处理时会产生一条追踪信息span，通过spanID来区分不同的span，这里的span会记录此次接口请求的全局追踪标识traceID、当前的追踪标识spanID(即当次接口请求的追踪标识)、服务名、接口名、调用耗时等信息，如果是上游有其他的组件参与了本次调用，还会记录上游其他的组件调用的traceID、spanID等信息。traceID相同的span表示它们属于同一次接口调用请求中的不同调用处理。

步骤S302：所述电子设备将所述追踪信息span传入分布式消息队列kafka中。

可选的，电子设备通过jaeger-collector将追踪信息span传入分布式消息队列kafka中。

步骤S303：所述电子设备消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务。

具体地，遍历所有span，获取spanID、service_name(服务名)的映射关系，这个过程可以获得每个span对应的服务；以及遍历所有span，通过parent_span_id(即parentID)查找service_name，即确定父span对应的服务。

针对新的数据流，按照parent+child进行分组

可选的，步骤S303可以具体由上述计算组件(dependency-plugin)来实现。

步骤S304：所述电子设备根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系。

本申请实施例中，parent_service_name+child_service_name(即父span对应的服务的名称+子span对应的服务的名称)为一条边，表示一条服务依赖关系。

在一种可选的方案中，从分布式消息队列kafka中消费到span时，可以考虑jaeger的span采集兼容分布式跟踪系统zipkin协议，为达到这个目的，本申请实施例会判断span中是否存在跟踪类别(spanKind)字段，以处理zipkin在远程过程调用(Remote ProcedureCall，RPC)调用情况下，父子spanID相同的特殊场景，这种场景下，本申请实施例会以父span的服务名来更新子span的依赖关系，以子span的服务名(或者spanID)来更新依赖于此子span的所有span的依赖关系。

下面结合图4例举一种兼容zipkin协议的计算服务间依赖关系的方法。

步骤1：电子设备向分布式消息队列kafka集群订阅主题(topic)，并从分布式消息队列kafka集群消费取回span。

可以理解，通过这种方式通常可以从分布式消息队列kafka中取回多个span。

步骤2：对于每一个span，电子设备判断span中是否存在spanKind字段。针对不同的判断结果，该电子设备执行的后续操作存在差异，为了便于描述，下面以第一span为例进行说明，该第一span为从分布式消息队列kafka中取回多个span中的任意一个，电子设备针对该第一span的操作如下：

A、第一span中不存在spanKind字段，则更新所有以第一span的spanID为parentID(即父标识，也可以称为上一次请求的追踪标识)的span依赖关系信息。

B、第一span中存在spanKind字段，并且spanKind字段为客户

(client)，则更新与第一span的spanID相同、且spanKind为主机(server)的span依赖关系信息。

C、第一span中存在spanKind字段，并且spanKind字段为server，则更新所有以第一span的spanID为parentID的span依赖关系信息。

步骤3：将第一span的spanID放入最近最最少使用(Least Recently Used，LRU)淘汰算法的循环队列中，并且将该第一span放入固定淘汰时间的缓存中。

步骤4：定时从循环队列中取出其中的spanID，当取出了第一span的spanID后，查看该第一span是否在缓存中过期，针对过期和不过期的两种结果分别对应两种不同的后续操作，具体如下：

A、若第一span未过期，则将将执行流程切换到上述步骤2，针对该第一span循环执行上述步骤2～4，直至最终判断出第一span过期，才结束对第一span的依赖关系计算处理流程。

B、若第一span已过期，则结束对第一span的依赖关系计算处理流程。

可选的，上述步骤1～3可以具体由业务系统中的计算组件dependency-plugin来完成。当然，也可以由业务系统中的其他组件辅助计算组件dependency-plugin来完全上述步骤1～3中的一个步骤或者多个步骤。

以上列举了一种兼容zipkin协议的计算服务间依赖关系的方法，同样的，本申请实施例中引入了jaeger的业务系统还可以兼容其他协议，例如，opentracing。兼容其他协议时的赖关系计算处理流程可以参照兼容zipkin协议的计算服务间依赖关系计算流程，此处不再一一赘述。

可选的，本申请实施例虽然针对接入了全链路监控系统jaeger的业务系统提出了一种全新的服务依赖关系计算处理流程，但是该业务系统中的jaeger可以正常地按照其本来的处理逻辑进行服务依赖关系的计算，例如，采用本申请实施例提出的全新的服务依赖关系计算处理流程实时地计算服务依赖关系，并且，每天(即以天为单位)按照jaeger本来的处理逻辑计算服务依赖关系。

在图3所示的方法中，在不破坏全链路监控系统jaeger的原生数据处理逻辑的情况下，额外引入分布式消息队列kafka作为数据收集过程的缓冲中间件，然后消费(例如，通过自研的dependency-plugin组件进行消费)kafka中的数据，定时批处理span，采用这种方法，由于额外引入分布式消息队列kafka，因此计算服务间依赖关系不需要依赖于jaeger的原生数据处理逻辑来一天计算一次，而是基于kafka定时批处理的特性实时计算span所代表的服务间依赖关系。

此外，由于计算服务依赖关系的组件以费者组的形式连接分布式消息队列kafka，因此可实现分布式计算服务间依赖关系，分布式的架构可满足业务高峰的容量要求，并且，通过分布式消息队列kafka的解耦作用，在业务峰值时，本申请新提出的服务集依赖关系计算流程基本不影响原有jaeger的性能。

另外，通过引入循环队列的LRU淘汰算法及缓存的定时过期机制，实时清楚过期的span，在满足峰值流量时，可保障计算服务的可用性。

并且，上述方法可兼容多种链路追踪协议，例如opentracing、zipkin等协议。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的装置。

请参见图5，图5是本申请实施例提供的一种确定服务间依赖关系的装置50的结构示意图，该装置50可以为上述方法实施例中的电子设备或者该电子设备中的模块，该装置中搭载了业务系统(也可以描述为应用于业务系统)，该业务系统部署了全链路监控系统jaeger，所述装置50包括获取模块501、传输模块502、消费模块503和生成模块504。各个模块的描述具体如下：

获取模块501，用于通过全链路监控系统jaeger获取调用接口时的追踪信息span；

传输模块502，用于将所述追踪信息span传入分布式消息队列kafka中；

消费模块503，用于消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务；

生成模块504，用于根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系。

其中，获取模块501可以为方法实施例中提及的全链路监控系统jaeger中的jaeger-collector。传输模块502和消费模块503可以为方法实施例中提及的计算组件(dependency-plugin)中的两个子模块。

在一种可选的方案中，所述业务系统部署了辅助系统，所述辅助系统包括所述分布式消息队列kafka和计算组件；在所述消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务方面，所述消费模块503，具体用于：

通过所述计算组件消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务。

在又一种可选的方案中，所述jaeger用于基于所述span生成每个span所代表的服务间调用依赖关系。也即是说，除了通过本申请新增的流程来获取服务间依赖关系外，所述jaeger也会基于其现有的机制获取服务间依赖关系。

在又一种可选的方案中，在所述根据所述每个span对应的服务和所述父span对应的服务，得到每个span所代表的服务间调用依赖关系方面，所述消费模块503具体用于：

判断第一span中是否存在spanKind字段，其中，所述第一span为消费的所述分布式消息队列kafka中的任意一个span；

根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系。

在又一种可选的方案中，在所述根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系，所述消费模块503具体用于：

若第一span中不存在spanKind字段，则更新所有以第一span的spanID为parentID的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为client，则更新与第一span的spanID相同、且spanKind为server的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为server，则更新所有以第一span的spanID为parentID的span依赖关系信息。

在又一种可选方案中，在所述根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系之后，所述消费单元503还用于：

将第一span的spanID放入最近最最少使用LRU淘汰算法的循环队列中，并且将该第一span放入固定淘汰时间的缓存中；

定时从所述循环队列中取出spanID，当取到所述第一span的spanID时，判断所述第一span在所述固定淘汰时间的缓存中是否过期；

若过期，则结束对所述第一span的依赖关系的计算处理。

在又一种可选的方案中，调用接口时的追踪信息包括接口调用请求的traceID、spanID、服务名、接口名、调用耗时中的一项或多项。

需要说明的是，在本申请实施例中，各个单元的具体实现还可以对应参照图3所示的方法实施例的相应描述。

在图5所描述的装置中，在不破坏全链路监控系统jaeger的原生数据处理逻辑的情况下，额外引入分布式消息队列kafka作为数据收集过程的缓冲中间件，然后消费(例如，通过自研的dependency-plugin组件进行消费)kafka中的数据，定时批处理span，采用这种方法，由于额外引入分布式消息队列kafka，因此计算服务间依赖关系不需要依赖于jaeger的原生数据处理逻辑来一天计算一次，而是基于kafka定时批处理的特性实时计算span所代表的服务间依赖关系。

此外，由于计算服务依赖关系的组件以费者组的形式连接分布式消息队列kafka，因此可实现分布式计算服务间依赖关系，分布式的架构可满足业务高峰的容量要求，并且，通过分布式消息队列kafka的解耦作用，在业务峰值时，本申请新提出的服务集依赖关系计算流程基本不影响原有jaeger的性能。

另外，通过引入循环队列的LRU淘汰算法及缓存的定时过期机制，实时清楚过期的span，在满足峰值流量时，可保障计算服务的可用性。

并且，上述方法可兼容多种链路追踪协议，例如opentracing、zipkin等协议。

参见图6，图6为本申请实施例涉及的硬件运行环境的电子设备结构60示意图。该电子设备60中搭载了业务系统(也可以描述为应用于业务系统)，该业务系统部署了全链路监控系统jaeger，其中，如图6所示，本申请的实施例涉及的硬件运行环境的电子设备可以包括：

处理器601，处理器601可以是一个或多个中央处理器(central processingunit，CPU)，在处理器601是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

存储器602，包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmableread only memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)，该存储器602用于相关计算机程序及数据。。

通信接口603，用于实现电子设备与其他设备进行通信。

本领域技术人员可以理解，图6中示出的电子设备的结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图6所示，存储器602中可以包括操作系统、网络通信模块以及文本处理程序。操作系统是管理和控制电子设备硬件和软件资源的程序，支持文本处理程序以及其他软件或程序的运行。网络通信模块用于实现存储器602内部各组件之间的通信，以及与电子设备中其他硬件和软件之间通信。

在图6所示的电子设备中，处理器601用于执行存储器602中存储的计算机程序，来执行如下操作：

通过全链路监控系统jaeger获取调用接口时的追踪信息span；

将所述追踪信息span传入分布式消息队列kafka中；

消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务；

根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系。

在一种可选的方案中，所述业务系统部署了辅助系统，所述辅助系统包括所述分布式消息队列kafka和计算组件；在所述消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务方面，所述处理器601，具体用于：

通过所述计算组件消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务。

在又一种可选的方案中，所述处理器还用于：

通过所述jaeger基于所述span生成每个span所代表的服务间调用依赖关系。也即是说，除了通过本申请新增的流程来获取服务间依赖关系外，所述jaeger也会基于其现有的机制获取服务间依赖关系。

在又一种可选的方案中，在根据所述每个span对应的服务和所述父span对应的服务，得到每个span所代表的服务间调用依赖关系方面，所述处理器601具体用于：

判断第一span中是否存在spanKind字段，其中，所述第一span为消费的所述分布式消息队列kafka中的任意一个span；

根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系。

在又一种可选的方案中，在所述根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系方面，所述处理器601具体用于：

若第一span中不存在spanKind字段，则更新所有以第一span的spanID为parentID的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为client，则更新与第一span的spanID相同、且spanKind为server的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为server，则更新所有以第一span的spanID为parentID的span依赖关系信息。

在又一种可选方案中，在所述根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系之后，所述处理器601还用于：

将第一span的spanID放入最近最最少使用LRU淘汰算法的循环队列中，并且将该第一span放入固定淘汰时间的缓存中；

定时从所述循环队列中取出spanID，当取到所述第一span的spanID时，判断所述第一span在所述固定淘汰时间的缓存中是否过期；

若过期，则结束对所述第一span的依赖关系的计算处理。

在又一种可选的方案中，调用接口时的追踪信息包括接口调用请求的traceID、spanID、服务名、接口名、调用耗时中的一项或多项。

需要说明的是，各个操作的实现还可以对应参照图3所示的方法实施例的相应描述。

在图6所描述的电子设备60中，在不破坏全链路监控系统jaeger的原生数据处理逻辑的情况下，额外引入分布式消息队列kafka作为数据收集过程的缓冲中间件，然后消费(例如，通过自研的dependency-plugin组件进行消费)kafka中的数据，定时批处理span，采用这种方法，由于额外引入分布式消息队列kafka，因此计算服务间依赖关系不需要依赖于jaeger的原生数据处理逻辑来一天计算一次，而是基于kafka定时批处理的特性实时计算span所代表的服务间依赖关系。

此外，由于计算服务依赖关系的组件以费者组的形式连接分布式消息队列kafka，因此可实现分布式计算服务间依赖关系，分布式的架构可满足业务高峰的容量要求，并且，通过分布式消息队列kafka的解耦作用，在业务峰值时，本申请新提出的服务集依赖关系计算流程基本不影响原有jaeger的性能。

另外，通过引入循环队列的LRU淘汰算法及缓存的定时过期机制，实时清楚过期的span，在满足峰值流量时，可保障计算服务的可用性。

并且，上述方法可兼容多种链路追踪协议，例如opentracing、zipkin等协议。

本发明实施例还提供一种芯片系统，所述芯片系统包括至少一个处理器，存储器和接口电路，所述存储器、所述收发器和所述至少一个处理器通过线路互联，所述至少一个存储器中存储有计算机程序；所述计算机程序被所述处理器执行时，实现图3所示的方法。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当其在处理器上运行时，实现图3所示的方法流程。

本发明实施例还提供一种计算机程序产品，当所述计算机程序产品在终端上运行时，实现图3所示的方法流程。

综上所述，在不破坏全链路监控系统jaeger的原生数据处理逻辑的情况下，额外引入分布式消息队列kafka作为数据收集过程的缓冲中间件，然后消费(例如，通过自研的dependency-plugin组件进行消费)kafka中的数据，定时批处理span，采用这种方法，由于额外引入分布式消息队列kafka，因此计算服务间依赖关系不需要依赖于jaeger的原生数据处理逻辑来一天计算一次，而是基于kafka定时批处理的特性实时计算span所代表的服务间依赖关系。

此外，由于计算服务依赖关系的组件以费者组的形式连接分布式消息队列kafka，因此可实现分布式计算服务间依赖关系，分布式的架构可满足业务高峰的容量要求，并且，通过分布式消息队列kafka的解耦作用，在业务峰值时，本申请新提出的服务集依赖关系计算流程基本不影响原有jaeger的性能。

另外，通过引入循环队列的LRU淘汰算法及缓存的定时过期机制，实时清楚过期的span，在满足峰值流量时，可保障计算服务的可用性。

并且，上述方法可兼容多种链路追踪协议，例如opentracing、zipkin等协议。

还需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (8)

1.一种确定服务间依赖关系的方法，其特征在于，应用于业务系统，所述业务系统部署了全链路监控系统jaeger，所述方法包括：

通过全链路监控系统jaeger获取调用接口时的追踪信息span；

将所述追踪信息span传入分布式消息队列kafka中；

消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务；

根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系；

其中，所述根据所述每个span对应的服务和所述父span对应的服务，得到每个span所代表的服务间调用依赖关系，包括：

判断第一span中是否存在跟踪类别spanKind字段，其中，所述第一span为消费的所述分布式消息队列kafka中的任意一个span；

若第一span中不存在spanKind字段，则更新所有以第一span的spanID为上一次请求的追踪标识parentID的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为客户client，则更新与第一span的spanID相同、且spanKind为主机server的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为server，则更新所有以第一span的spanID为parentID的span依赖关系信息。

2.根据权利要求1所述的方法，其特征在于，所述业务系统部署了辅助系统，所述辅助系统包括所述分布式消息队列kafka和计算组件；所述消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务，包括：

通过所述计算组件消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务。

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

通过所述jaeger基于所述span生成每个span所代表的服务间调用依赖关系。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述根据判断结果基于所述第一span对应的服务和所述父span对应的服务生成所述第一span代表的服务间调用依赖关系之后，还包括：

将第一span的spanID放入最近最少使用LRU淘汰算法的循环队列中，并且将该第一span放入固定淘汰时间的缓存中；

定时从所述循环队列中取出spanID，当取到所述第一span的spanID时，判断所述第一span在所述固定淘汰时间的缓存中是否过期；

若过期，则结束对所述第一span的依赖关系的计算处理。

5.根据权利要求1-3任一项所述的方法，其特征在于，调用接口时的追踪信息包括接口调用请求的全局追踪标识traceID、当前的追踪标识spanID、服务名、接口名、调用耗时中的一项或多项。

6.一种确定服务间依赖关系的装置，其特征在于，应用于业务系统，所述业务系统部署了全链路监控系统jaeger，所述装置包括：

获取模块，用于通过全链路监控系统jaeger获取调用接口时的追踪信息span；

传输模块，用于将所述追踪信息span传入分布式消息队列kafka中；

消费模块，用于消费所述分布式消息队列kafka中的每个追踪信息span，得到每个span对应的服务和父span，以及确定所述父span对应的服务；

生成模块，用于根据所述每个span对应的服务和所述父span对应的服务得到每个span所代表的服务间调用依赖关系；

其中，所述生成模块具体用于：

判断第一span中是否存在跟踪类别spanKind字段，其中，所述第一span为消费的所述分布式消息队列kafka中的任意一个span；

若第一span中不存在spanKind字段，则更新所有以第一span的spanID为上一次请求的追踪标识parentID的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为客户client，则更新与第一span的spanID相同、且spanKind为主机server的span依赖关系信息；

若第一span中存在spanKind字段，并且spanKind字段为server，则更新所有以第一span的spanID为parentID的span依赖关系信息。

7.一种电子设备，其特征在于，所述电子设备包括处理器、存储器、通信接口以及一个或多个计算机程序，其中，所述一个或多个计算机程序被存储在所述存储器中，并且被配置由所述处理器执行，所述计算机程序被所述处理器执行时，实现权利要求1-5任一项所述的方法。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，其在处理器上运行时，实现权利要求1-5任意一项所述的方法。

Images