CN115481040A - 基于微服务平台的循环依赖检测方法及装置 - Google Patents

Abstract

本申请提供基于微服务平台的循环依赖检测方法及装置，其中所述基于微服务平台的循环依赖检测方法包括：响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果，不仅避免了人工漏检的问题，还提高了循环依赖检测的准确率，降低系统缺陷修复、回退的成本。

Description

基于微服务平台的循环依赖检测方法及装置

技术领域

本申请涉及计算机技术领域，特别涉及基于微服务平台的循环依赖检测方法。本申请同时涉及基于微服务平台的循环依赖检测装置，一种计算设备，以及一种计算机可读存储介质。

背景技术

微服务通过将一个完整的系统拆分为若干个粒度较小的服务单元，每个服务单元通过网络接口与其他服务单元相互调用，共同完成业务功能。大部分业务需求是需要多个服务单元一起配合才能完成，这种相互配合的过程中就可能会发生循环依赖调用的问题。

为了避免服务之间出现循环依赖，导致服务异常的情况，可以对整个微服务系统进行循环依赖检测。目前，除了人工检测的方式以外，还可在系统测试阶段或者运维阶段，对发生过的执行请求、服务调用的各个路径进行检测，以排查微服务系统中的循环依赖问题。但随着微服务系统中服务单元的数量不断增加，仅对服务调用的过程进行循环依赖检测，可能会出现漏检的情况，进而较大地影响了对微服务系统的循环检测的准确率。

发明内容

有鉴于此，本申请实施例提供了基于微服务平台的循环依赖检测方法。本申请同时涉及基于微服务平台的循环依赖检测装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的上述问题。

根据本申请实施例的第一方面，提供了一种基于微服务平台的循环依赖检测方法，包括：

响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；

解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；

基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；

基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

根据本申请实施例的第二方面，提供了一种基于微服务平台的循环依赖检测装置，包括：

源文件获取模块，被配置为响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；

源文件解析模块，被配置为解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；

第一构建模块，被配置为基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

第二构建模块，被配置为根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；

依赖检测模块，被配置为基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现所述基于微服务平台的循环依赖检测方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现所述基于微服务平台的循环依赖检测方法的步骤。

本申请提供的基于微服务平台的循环依赖检测方法，响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

本申请一实施例，通过获取微服务平台中每个微服务单元的服务源文件，并对服务源文件进行解析，以确定每个微服务单元中提供服务的服务节点，并将每个微服务单元中的服务节点构建相应的简化有向图，最后，将微服务平台中每个微服务单元对应的简化有向图进行合并，获得目标有向图，进而能够从目标有向图中，对整个微服务平台是否出现循环依赖进行检测；通过该种方式，通过静态代码扫描的方式在对整个微服务平台的现有代码无侵入性的情况下，及在微服务平台的开发阶段，微服务平台不需要请求服务即可完成对服务调用循环依赖的检测，不仅避免了人工漏检的问题，还提高了循环依赖检测的准确率，降低系统缺陷修复、回退的成本。

附图说明

图1是本申请一实施例提供的一种基于微服务平台的循环依赖检测方法的场景示意图；

图2是本申请一实施例提供的一种基于微服务平台的循环依赖检测方法的流程图；

图3a是本申请一实施例提供的一种应用于电商平台的基于微服务平台的循环依赖检测方法生成账户模块简化有向图的示意图；

图3b是本申请一实施例提供的一种应用于电商平台的基于微服务平台的循环依赖检测方法生成订单模块简化有向图的示意图；

图3c是本申请一实施例提供的一种应用于电商平台的基于微服务平台的循环依赖检测方法生成库存模块简化有向图的示意图；

图4是本申请一实施例提供的一种应用于电商平台的基于微服务平台的循环依赖检测方法生成合并有向图的示意图；

图5是本申请一实施例提供的一种基于微服务平台的循环依赖检测装置的结构示意图；

图6是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

微服务：一种软件开发技术-面向服务的体系结构(SOA)架构样式的一种变体，将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTfulAPI)。

有向图：有向图是一幅具有方向性的图，是由一个顶点和一组有方向的边组成的，每条方向的边都连着一对有序的顶点。

有向环：一条至少含有一条边，且起点和终点相同的有向路径。

有向路径：由一系列顶点组成，对于其中的每个顶点都存在一条有向边，从它指向序列的下一个顶点。

抽象语法树：或简称语法树(Syntax tree)，是源代码语法结构的一种抽象表示。它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。

微服务是当前非常流行的软件架构，普遍应用于分布式系统的开发之中。微服务通过将一个完整的系统拆分为若干个粒度较小的服务单元，每个服务单元通过网络接口与其他服务单元相互调用，共同完成业务功能。微服务架构提倡把服务拆小而独立，一个软件系统往往会有很多服务单元，大部分业务需求是需要多个服务单元一起配合才能完成，微服务架构提倡把服务单元拆的小而独立，一个软件系统往往会有很多服务单元，大部分业务需求是需要多个服务单元一起配合才能完成。微服务的主要优势都来源于一个原则，即独立可部署性；独立可部署性要求每个服务可以完全自主的控制自身的开发、部署和运维，要想达到这一点，最重要的是避免服务之间出现循环依赖的情况发生。假设服务A和服务B产生了循环依赖，当A和B任何一方需要发布新功能或者因为异常情况宕机时，都会影响到对方的功能，以至于两个服务必须协调出一致的生命周期操作。

微服务之间的循环依赖类似于类之间的循环依赖，当依赖关系形成了环，会有很多危害。目前为了实现对微服务之间的循环依赖进行检测，大多数的实现方式是在微服务系统运行期间，获取微服务系统中执行请求任务的各个服务上报的调用信息，再基于各个服务上报的调用信息，生成各个服务调用的有向图，再根据有向图确定请求任务是否存在循环依赖；该种方式，因为在系统运行期检测循环依赖，所以只能在测试阶段或者运维阶段发现问题，进而使得系统修复、回退成本较高；另外，上述方法是对执行过请求的服务进行分析，如果存在某些服务没有被调用过，则无法检测出循环依赖，造成漏检的情况发生；进一步地，上述方法发现循环依赖时，不能直接定位到源码文件，对于后续系统排查时也会带来较大的麻烦。

基于此，本申请实施例提供的一种基于微服务平台的循环依赖检测方法，通过对微服务平台的源文件进行处理，即可实现在开发阶段就能完成依赖检测，能够尽早发现为服务平台的系统缺陷，降低修复成本；另外，开发阶段不需要请求服务即可完成检测，不仅避免了人为原因造成的漏检情况，还能提高循环依赖检测的准确率；同时，该种方式发现循环依赖能直接定位到源码文件或者是代码行号，更快地帮助开发人员修复缺陷。

在本申请中，提供了基于微服务平台的循环依赖检测方法，本申请同时涉及基于微服务平台的循环依赖检测装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种基于微服务平台的循环依赖检测方法的场景示意图。

图1中包括微服务平台100和微服务平台的循环依赖检测系统200；其中，微服务平台100包括多个微服务单元，包括微服务单元1、微服务单元2、微服务单元3、微服务单元4，各个微服务单元之间进行服务调用，如图1中微服务平台100的箭头表示服务调用过程。微服务平台的循环依赖检测系统200用于检测上述微服务平台100中是否出现服务调用的循环依赖问题。

具体的，循环依赖检测系统200可获取上述微服务平台100中的各个微服务单元的服务源文件，并通过解析服务源文件，确定各个微服务单元的服务节点；根据各个微服务单元的服务节点构建各个微服务单元的简化有向图，并根据每个微服务单元的简化有向图生成目标有向图；最后，根据目标有向图实现循环依赖检测，获得循环依赖检测结果。

本实施例提供的基于微服务平台的循环依赖检测方法，通过获取每个微服务单元的源文件，能够在微服务平台开发阶段即可完成对循环依赖的检测，同时，不需要依赖服务调用执行过程就能够获得微服务平台中所有微服务单元的服务调用过程，也提高了循环检测的准确率，避免人工漏检的问题出现。

图2示出了根据本申请一实施例提供的一种基于微服务平台的循环依赖检测方法的流程图，具体包括以下步骤：

需要说明的是，本实施例提供的微服务平台的循环依赖检测方法的执行主体可为额外的循环检测系统，还可为微服务平台本身，下述实施例中仅对具体的循环依赖检测过程进行描述，对执行主体不作任何限定。

步骤202：响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件。

其中，微服务平台可以理解为需要多个服务单元一起配合才能完成业务需求的系统架构，且该平台中各个服务单元是通过服务调用实现相互配合的。

微服务单元可以理解为微服务平台中划分的多个服务单元，执行某一业务需求时，各微服务单元通过相互服务调用，实现对业务的处理；比如在电商平台中，账户管理模块、订单管理模块以及库存管理模块等，均可理解为微服务单元。

服务源文件可以理解为开发微服务平台的各个微服务单元的开发源文件，包括源码文件、各种配置文件等等。

实际应用中，执行主体可响应于对某一微服务平台的循环依赖检测请求，开启执行循环依赖检测的过程，需要说明的是，整个微服务平台当前还在系统开发阶段，并未在系统测试或运维阶段；进而，执行主体可扫描该微服务平台中所有微服务单元的服务源文件，以便于对各个微服务单元是否存在循环依赖进行检测。

步骤204：解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

其中，服务节点可以理解为微服务单元的源码中能够提供服务调用方法的方法节点，

实际应用中，执行主体可对扫描得到的所有微服务单元的服务源文件进行解析，以确定每个微服务单元中的各个服务节点，该服务节点的数量可以为至少一个，具体可根据系统开发需求而定，本实施例对此不作具体限定。

进一步地，为了避免对微服务平台的循环依赖检测出现漏检的情况，执行主体可扫描所有微服务单元中各种类型的服务源文件，进而确定每个微服务单元的服务节点；具体的，所述解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

确定所述每个微服务单元的服务源文件的文件类型；

基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

其中，文件类型可以理解为执行主体扫描服务源文件的文件类型，比如源码文件类型、配置文件类型等。

文件解析规则可以理解为针对不同的服务源文件的文件类型，确定的不同的解析规则。

实际应用中，执行主体将扫描的所有微服务单元的服务源文件进行分类，确定多个文件类型，进而，对不同类型的服务源文件进行分类解析处理；再确定每种文件类型对应的文件解析规则，然后根据相应的文件解析规则解析各个微服务单元的服务源文件，确定每个微服务单元的服务节点。

需要说明的是，不同类型的源文件采取不同的文件解析规则，不仅能够提高文件解析的效率，还能减少较多的冗余计算，节省计算资源。

本实施例提供了对服务代码文件类型的服务源文件进行解析处理的过程，其中，所述文件类型为服务代码文件类型；

相应地，基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

基于所述服务代码文件类型确定语法结构解析规则；

根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

其中，服务代码文件类型可以理解为微服务单元中的源码文件，比如java源文件等。

语法结构解析规则可以理解为对微服务单元开发代码的语法结构进行解析的规则，比如抽象语法树技术等。

实际应用中，执行主体在确定服务源文件A为服务代码文件类型时，即可确定服务源文件A对应的文件解析规则为语法结构解析规则，并根据语法结构解析规则解析该服务源文件A，进而确定该微服务单元中的各个服务节点。

具体的，所述根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定每个服务源文件的方法节点树；

将每个方法节点树中带有服务标识的方法节点，确定为所述每个微服务单元的服务节点，其中，所述服务标识包括服务声明标识和服务引用标识。

其中，服务源文件的方法节点树可以理解为根据抽象语法树技术对代码文件进行解析后，获得的语法结构树，该语法结构树中包括多个方法节点，各个方法节点之间存在调用、以及被调用的关系。

实际应用中，执行主体在对服务代码文件类型的服务源文件时，利用抽象语法树技术解析java源文件，将每个微服务单元的服务源文件中执行的方法均构建为方法节点树的形式，该方法节点树中的每个节点可以理解为一个方法节点，可标识为方法标识，其中，方法标识生成策略：类名+方法名+参数数量；若该方法被重写且方法标识相同，则被认为是同一个方法；由于本实施例中需要确定微服务单元中各个方法节点是否为服务提供者的角色，因此，需要对服务源文件中所有的方法节点进行遍历，以确定带有服务标识的方法节点，并将带有服务标识的方法节点确定为每个微服务单元的服务节点；另外，还可为确定的服务节点进行打标，标识为带有“服务提供者”的标识。

需要说明的是，服务标识可以理解为方法中包含服务功能的标识，比如方法含有服务声明的标识、被调用的方法含有服务引用的标识。

基于此，本实施例中通过对服务代码文件类型的服务源文件进行解析，确定方法中包含服务功能的方法节点，并将该方法节点作为微服务单元的服务节点，以便于后续确定该微服务单元在整个微服务平台的服务调用过程所充当的服务角色，以准确地确定循环依赖调用的方法节点。

本申请另一实施例还提供了对服务配置类型的服务源文件进行解析处理的过程，具体的，所述文件类型为服务配置文件类型；

相应地，基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

基于所述服务配置文件类型确定配置项解析规则；

根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

其中，配置项解析规则可以理解为对每个微服务单元中的项目配置文件进行解析的规则，以获得每类方法对应的配置项信息等。

实际应用中，执行主体在确定服务源文件A为服务配置文件类型时，即可确定服务源文件A对应的文件解析规则为配置项解析规则，并根据配置项解析规则解析该服务源文件A，进而确定该微服务单元中的各个服务节点。

进一步地，执行主体仅需要遍历所有的配置文件信息，确定是否包含服务声明的配置项，进而确定各个微服务单元的服务节点；具体的，所述根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定每个服务源文件中带有服务声明的配置项信息；

将所述每个服务源文件中的配置项信息对应的方法，标识为所述每个微服务单元的服务节点。

实际应用中，执行主体可根据配置项解析规则对每个微服务单元的服务源文件进行解析，其中，该服务源文件可以为项目配置文件，因此，执行主体可遍历项目配置文件中所有的信息内容，找到具有服务声明的配置项信息，并将该配置项信息对应的方法，标识为每个微服务单元的服务节点；需要说明的是，项目配置文件中包括各种方法对应的声明、配置、参数等信息，因此，在项目配置文件中是可以找到具有服务声明的配置项，以确定提供服务的方法，进而确定每个微服务单元的服务节点。

需要强调的是，上述在所有的微服务单元中扫描两种服务源文件进行解析处理，获得对应的服务节点，这两种解析方式可以并列执行，也可顺序执行，这两种确定服务节点的结果可以进行相互补充，也就是说，从服务代码文件类型的服务源文件中确定的服务节点，和从服务配置文件类型的服务源文件中确定的服务节点可进行相互补充，为的是更加全面地确定微服务单元的所有服务节点，避免后续出现循环依赖检测漏检的情况发生。

步骤206：基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图。

其中，有向图为具有顶点和有方向的边组成的有向图，在本实施例中的简化有向图可以理解为将每个微服务单元的服务节点作为顶点，各个服务单元之间的服务调用关系作为边组成的有向图。

实际应用中，为了能够检测到微服务单元中各个服务节点之间出现的循环依赖调用的情况，执行主体通过上述方式确定了每个微服务单元的服务节点之后，可针对每个微服务单元的服务节点构建微服务单元的简化有向图，便于后续根据每个微服务单元的简化有向图，确定各个微服务单元中之间是否出现循环依赖调用关系。

进一步地，每个微服务单元的简化有向图均是通过微服务单元所有方法节点构建的调用关系有向图简化而来；具体的，所述基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图，包括：

解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的初始调用关系有向图；

基于所述每个微服务单元的初始调用关系有向图以及所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

其中，所述初始调用关系有向图包括每个微服务单元中的方法节点、方法节点之间的调用关系，所述方法节点包括服务节点以及非服务节点，所述简化有向图包括每个微服务单元中的服务节点以及服务节点之间的调用关系。

其中，初始调用关系有向图可以理解为各个微服务单元中所有方法节点以及方法节点之间的调用关系组成的有向图。

实际应用中，执行主体通过解析每个微服务单元的服务源文件，可以确定每个服务源文件中各个方法节点，以及各个方法节点之间的调用关系，进而生成服务源文件的初始调用关系有向图。进一步地，复制每个微服务单元的初始调用关系有向图中的服务节点，以及服务节点之间的调用关系，构建每个微服务单元的简化有向图；其中，初始调用关系有向图中包括多个方法节点，以及方法节点之间的调用关系，另外，方法节点中具有服务标识的节点可标识为服务节点，没有服务标识的节点可标识为非服务节点；简化有向图中仅包含带有服务标识的方法节点，即服务节点，以及各个服务节点之间的调用关系。

需要说明的是，根据初始调用关系有向图生成简化有向图的过程，将保留初始调用关系有向图中的所有服务节点，以及所有服务节点之间的调用关系，若两个服务节点在初始调用关系有向图中具有调用关系，则在简化有向图中同样保留对应的调用关系。

更进一步地，所述基于所述每个微服务单元的初始调用关系有向图以及所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图，包括：

遍历所述每个微服务单元的初始调用关系有向图中的各个方法节点，提取所述每个微服务单元中带有服务标识的服务节点以及服务调用关系；

基于所述服务节点以及所述服务调用关系，构建所述每个微服务单元的简化有向图。

实际应用中，执行主体可通过遍历每个微服务单元对应的初始调用关系有向图中的各个方法节点，确定是否为带有服务标识的服务节点，以提取相应的服务节点以及各个服务节点之间的服务调用关系，进而构建每个微服务单元的简化有向图。

例如，选取初始调用关系有向图中任意一个方法节点A，从该方法节点A开始深度遍历，若访问到的方法节点B有服务标识，即为服务节点B，那么可将该服务节点B复制到简化有向图中，若存在最近访问到的带有服务标识的服务节点C，且服务节点C到服务节点B具有调用关系，则创建服务节点C到服务节点B的有向边插入到简化有向图中，保存服务节点B为最近访问到的服务标识的服务节点，若访问到的方法节点没有服务标识则跳过，访问过的方法节点标记为已访问，重复上述操作，直至所有方法节点标识为已访问。

下述参见图3a、图3b以及图3c，分别为应用于电商平台的微服务平台的循环依赖检测过程生成简化有向图过程的示意，包括生成账户模块简化有向图、订单模块简化有向图以及库存模块简化有向图。

具体的，图3a为基于微服务平台的循环依赖检测方法生成账户模块简化有向图的示意图。

图3a上半部分为账户模块有向图，即初始调用关系有向图，包括账户模块微服务单元的所有方法节点，其中user#query、user#modify和order#modify这三个方法节点中具有“服务提供者”标识，因此这三个方法节点为服务节点，另外三个方法节点为非服务节点，箭头指示关系表示服务调用关系。图3a下半部分为账户模块简化有向图，其中仅保留了三个带有“服务提供者标识”的服务节点，以及保留了服务节点之间的服务调用关系。

具体的，图3b为基于微服务平台的循环依赖检测方法生成订单模块简化有向图的示意图。

图3b上半部分为订单模块有向图，即初始调用关系有向图，包括订单模块微服务单元的所有方法节点，其中order#save、user#query、user#modify、order#modify和stock#modify这五个方法节点中具有“服务提供者”标识，因此这五个方法节点为服务节点，另外两个方法节点为非服务节点，箭头指示关系表示服务调用关系。图3b下半部分为订单模块简化有向图，其中仅保留了五个带有“服务提供者”标识的服务节点，以及保留了服务节点之间的服务调用关系。

具体的，图3c为基于微服务平台的循环依赖检测方法生成库存模块简化有向图的示意图。

图3c上半部分为库存模块有向图，即初始调用关系有向图，包括库存模块微服务单元的所有方法节点，其中stock#query、stock#modify和user#modify这三个方法节点中具有“服务提供者”标识，因此这三个方法节点为服务节点，另外两个方法节点为非服务节点，箭头指示关系表示服务调用关系。图3c下半部分为库存模块简化有向图，其中仅保留了三个带有“服务提供者”标识的服务节点，以及保留了服务节点之间的服务调用关系。

通过上述三种简化有向图的示意，可知每个简化有向图中仅包含服务节点，以及服务节点之间的调用关系。

步骤208：根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图。

其中，目标有向图可以理解为将多个简化有向图进行合并处理后的合并有向图。

实际应用中，执行主体可将每个微服务单元的简化有向图进行合并生成微服务平台的目标有向图，进而实现了将微服务平台中所有的服务节点以及服务节点之间的调用关系进行可视化表达的过程。

具体的，所述根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图，包括：

读取所述每个微服务单元的简化有向图，确定所述微服务平台的目标服务节点以及目标服务调用关系；

基于所述目标服务节点以及所述目标服务调用关系，生成所述微服务平台的目标有向图。

实际应用中，执行主体可遍历读取每个微服务单元的简化有向图，选取包含服务节点数量较多的简化有向图作为待处理有向图，进而，比对每一张简化有向图中的服务节点以及服务节点之间的调用关系，若待处理有向图中存在对应的服务节点，则跳过，若待处理有向图中不存在对应的服务节点，则将该服务几点复制在待处理有向图中，相应地服务节点之间的调用关系也可采用该方式进行获取，最后，完成对所有的简化有向图进行合并的过程，生成微服务平台的目标有向图。

需要说明的是，上述合并方式仅为一种实施方式，还可包括其他对多个简化有向图进行合并的处理方式，本实施例对此不作任何限定。

参见图4，图4示出了本实施例提供的应用于电商平台的基于微服务平台的循环依赖检测方法生成合并有向图的示意图。

图4为上述图3a、图3b以及图3c三个简化有向图进行合并后的合并有向图。其中，包括上述三个简化有向图的所有服务节点，以及所有服务节点之间的调用关系；需要说明的是，图4中的stock#query的服务节点在上述三个简化有向图中并没有与其他服务节点之间有服务调用关系，那么在合并简化有向图之后的合并有向图中，当然也不会与其他服务节点之间具有调用关系。此外，其他服务节点之间可根据相应的调用关系生成合并后的有向图，后续即可根据合并有向图进行循环依赖检测。

步骤210：基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

实际应用中，为了检测到微服务平台中的各个服务节点之间是否具有循环依赖关系，就可通过目标有向图进行检测，以确定各个服务节点之间的调用关系，即目标有向图中各个边的关系，进而获得对该微服务平台的循环依赖检测结果。

进一步地，所述基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果，包括：

基于预设节点环路径检测规则对所述目标有向图进行环路径检测，获得所述目标有向图的目标环路径；

基于所述目标环路径生成所述微服务平台的循环依赖检测结果，其中，所述循环依赖检测结果包括所述目标环路径的环服务节点以及环服务调用关系。

其中，预设节点环路径检测规则可以理解为对目标有向图中的有向环进行检测的规则，即寻找环的算法，比如johnson算法，本实施例对此不作任何限定。

实际应用中，执行主体利用预设节点换路径检测规则对目标有向图进行环路径检测，以确定目标有向图中是否存在目标环路径，若存在目标环路径，则说明微服务平台中存在循环调用依赖，若不存在目标环路径，则说明微服务平台中不存在循环调用依赖；需要说明的是，环路径可以理解为目标有向图中组成有向环的各个服务节点组成的路径；进一步地，在获得目标有向图的目标环路径之后，根据目标环路径生成微服务平台的循环依赖检测结果，即可得到微服务平台中所有存在的循环依赖。

此外，为了便于开发人员发现循环依赖调用之后，可以直接定位到源码文件或者是代码行号，能够更快地帮助开发人员修改系统缺陷，还可将循环依赖检测结果进行存储；具体的，所述基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果之后，还包括：

将所述目标环路径的环服务节点以及环服务调用关系进行存储。

实际应用中，执行主体可将目标环路径中的环服务节点以及环服务调用关系存储至数据库，其中，环服务节点可以理解为发生循环依赖调用关系的服务节点，环服务调用关系可以理解为服务节点之间发生循环依赖调用关系。

综上，本申请实施例提供的基于微服务平台的循环依赖检测装置，通过获取微服务平台中每个微服务单元的服务源文件，并对服务源文件进行解析，以确定每个微服务单元中提供服务的服务节点，并将每个微服务单元中的服务节点构建相应的简化有向图，最后，将微服务平台中每个微服务单元对应的简化有向图进行合并，获得目标有向图，进而能够从目标有向图中，对整个微服务平台是否出现循环依赖进行检测；通过该种方式，在对整个微服务平台的现有代码无侵入性的情况下，在微服务平台的开发阶段，微服务平台不需要请求服务即可完成对服务调用循环依赖的检测，不仅避免了人工漏检的问题，还提高了循环依赖检测的准确率，降低系统缺陷修复、回退的成本。

与上述方法实施例相对应，本申请还提供了基于微服务平台的循环依赖检测装置实施例，图5示出了本申请一实施例提供的一种基于微服务平台的循环依赖检测装置的结构示意图。

如图5所示，该装置包括：

源文件获取模块502，被配置为响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；

源文件解析模块504，被配置为解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；

第一构建模块506，被配置为基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

第二构建模块508，被配置为根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；

依赖检测模块510，被配置为基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

可选地，所述源文件解析模块504，进一步被配置为：

确定所述每个微服务单元的服务源文件的文件类型；

基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

可选地，所述文件类型为服务代码文件类型；

可选地，所述源文件解析模块504，进一步被配置为：

基于所述服务代码文件类型确定语法结构解析规则；

根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

可选地，所述源文件解析模块504，进一步被配置为：

根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定每个服务源文件的方法节点树；

将每个方法节点树中带有服务标识的方法节点，确定为所述每个微服务单元的服务节点，其中，所述服务标识包括服务声明标识和服务引用标识。

可选地，所述文件类型为服务配置文件类型；

可选地，所述源文件解析模块504，进一步被配置为：

基于所述服务配置文件类型确定配置项解析规则；

根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

可选地，所述源文件解析模块504，进一步被配置为：

根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定每个服务源文件中带有服务声明的配置项信息；

将所述每个服务源文件中的配置项信息对应的方法，标识为所述每个微服务单元的服务节点。

可选地，所述第一构建模块506，进一步被配置为：

解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的初始调用关系有向图；

基于所述每个微服务单元的初始调用关系有向图以及所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

其中，所述初始调用关系有向图包括每个微服务单元中的方法节点、方法节点之间的调用关系，所述方法节点包括服务节点以及非服务节点，所述简化有向图包括每个微服务单元中的服务节点以及服务节点之间的调用关系。

可选地，所述第一构建模块506，进一步被配置为：

遍历所述每个微服务单元的初始调用关系有向图中的各个方法节点，提取所述每个微服务单元中带有服务标识的服务节点以及服务调用关系；

基于所述服务节点以及所述服务调用关系，构建所述每个微服务单元的简化有向图。

可选地，第二构建模块508，进一步被配置为：

读取所述每个微服务单元的简化有向图，确定所述微服务平台的目标服务节点以及目标服务调用关系；

基于所述目标服务节点以及所述目标服务调用关系，生成所述微服务平台的目标有向图。

可选地，所述依赖检测模块510，进一步被配置为：

基于预设节点环路径检测规则对所述目标有向图进行环路径检测，获得所述目标有向图的目标环路径；

基于所述目标环路径生成所述微服务平台的循环依赖检测结果，其中，所述循环依赖检测结果包括所述目标环路径的环服务节点以及环服务调用关系。

可选地，所述装置，还包括存储模块，进一步被配置为：

将所述目标环路径的环服务节点以及环服务调用关系进行存储。

本申请实施例提供的基于微服务平台的循环依赖检测装置，通过获取微服务平台中每个微服务单元的服务源文件，并对服务源文件进行解析，以确定每个微服务单元中提供服务的服务节点，并将每个微服务单元中的服务节点构建相应的简化有向图，最后，将微服务平台中每个微服务单元对应的简化有向图进行合并，获得目标有向图，进而能够从目标有向图中，对整个微服务平台是否出现循环依赖进行检测；通过该种方式，在对整个微服务平台的现有代码无侵入性的情况下，在微服务平台的开发阶段，微服务平台不需要请求服务即可完成对服务调用循环依赖的检测，不仅避免了人工漏检的问题，还提高了循环依赖检测的准确率，降低系统缺陷修复、回退的成本。

上述为本实施例的一种基于微服务平台的循环依赖检测装置的示意性方案。需要说明的是，该基于微服务平台的循环依赖检测装置的技术方案与上述的基于微服务平台的循环依赖检测方法的技术方案属于同一构思，基于微服务平台的循环依赖检测装置的技术方案未详细描述的细节内容，均可以参见上述基于微服务平台的循环依赖检测方法的技术方案的描述。

图6示出了根据本申请一实施例提供的一种计算设备600的结构框图。该计算设备600的部件包括但不限于存储器610和处理器620。处理器620与存储器610通过总线630相连接，数据库650用于保存数据。

计算设备600还包括接入设备640，接入设备640使得计算设备600能够经由一个或多个网络660通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备640可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备600的上述部件以及图6中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图6所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备600可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备600还可以是移动式或静止式的服务器。

其中，处理器620执行所述计算机指令时实现所述的基于微服务平台的循环依赖检测方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的基于微服务平台的循环依赖检测方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述基于微服务平台的循环依赖检测方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现如前所述基于微服务平台的循环依赖检测方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的基于微服务平台的循环依赖检测方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于微服务平台的循环依赖检测方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种基于微服务平台的循环依赖检测方法，其特征在于，包括：

响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；

解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；

基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；

基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

2.根据权利要求1所述的方法，其特征在于，所述解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

确定所述每个微服务单元的服务源文件的文件类型；

基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

3.根据权利要求2所述的方法，其特征在于，所述文件类型为服务代码文件类型；

相应地，基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

基于所述服务代码文件类型确定语法结构解析规则；

根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

4.根据权利要求3所述的方法，其特征在于，所述根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

根据所述语法结构解析规则解析所述每个微服务单元的服务源文件，确定每个服务源文件的方法节点树；

将每个方法节点树中带有服务标识的方法节点，确定为所述每个微服务单元的服务节点，其中，所述服务标识包括服务声明标识和服务引用标识。

5.根据权利要求2所述的方法，其特征在于，所述文件类型为服务配置文件类型；

相应地，基于所述文件类型确定文件解析规则，根据所述文件解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

基于所述服务配置文件类型确定配置项解析规则；

根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点。

6.根据权利要求5所述的方法，其特征在于，所述根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点，包括：

根据所述配置项解析规则解析所述每个微服务单元的服务源文件，确定每个服务源文件中带有服务声明的配置项信息；

将所述每个服务源文件中的配置项信息对应的方法，标识为所述每个微服务单元的服务节点。

7.根据权利要求1所述的方法，其特征在于，所述基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图，包括：

解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的初始调用关系有向图；

基于所述每个微服务单元的初始调用关系有向图以及所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

其中，所述初始调用关系有向图包括每个微服务单元中的方法节点、方法节点之间的调用关系，所述方法节点包括服务节点以及非服务节点，所述简化有向图包括每个微服务单元中的服务节点以及服务节点之间的调用关系。

8.根据权利要求7所述的方法，其特征在于，所述基于所述每个微服务单元的初始调用关系有向图以及所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图，包括：

遍历所述每个微服务单元的初始调用关系有向图中的各个方法节点，提取所述每个微服务单元中带有服务标识的服务节点以及服务调用关系；

基于所述服务节点以及所述服务调用关系，构建所述每个微服务单元的简化有向图。

9.根据权利要求1所述的方法，其特征在于，所述根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图，包括：

读取所述每个微服务单元的简化有向图，确定所述微服务平台的目标服务节点以及目标服务调用关系；

基于所述目标服务节点以及所述目标服务调用关系，生成所述微服务平台的目标有向图。

10.根据权利要求1所述的方法，其特征在于，所述基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果，包括：

基于预设节点环路径检测规则对所述目标有向图进行环路径检测，获得所述目标有向图的目标环路径；

基于所述目标环路径生成所述微服务平台的循环依赖检测结果，其中，所述循环依赖检测结果包括所述目标环路径的环服务节点以及环服务调用关系。

11.根据权利要求10所述的方法，其特征在于，所述基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果之后，还包括：

将所述目标环路径的环服务节点以及环服务调用关系进行存储。

12.一种基于微服务平台的循环依赖检测装置，其特征在于，包括：

源文件获取模块，被配置为响应于对所述微服务平台的循环依赖检测请求，获取所述微服务平台中每个微服务单元的服务源文件；

源文件解析模块，被配置为解析所述每个微服务单元的服务源文件，确定所述每个微服务单元的服务节点；

第一构建模块，被配置为基于所述每个微服务单元的服务节点，构建所述每个微服务单元的简化有向图；

第二构建模块，被配置为根据所述每个微服务单元的简化有向图，生成所述微服务平台的目标有向图；

依赖检测模块，被配置为基于所述目标有向图对所述微服务平台进行循环依赖检测，获得循环依赖检测结果。

13.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述计算机指令时实现权利要求1-11任意一项所述方法的步骤。

14.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该计算机指令被处理器执行时实现权利要求1-11任意一项所述方法的步骤。

Images