CN115098154A - 服务间依赖关系的管理方法、装置及电子设备 - Google Patents

Abstract

本申请提出了一种服务间依赖关系的管理方法、装置及电子设备，涉及服务间依赖关系分析技术领域，该方法包括：针对待处理的多个服务中的每个服务，获取服务的源文件；从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息；根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。由此利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

Description

服务间依赖关系的管理方法、装置及电子设备

技术领域

本申请涉及服务间依赖关系分析技术领域，尤其涉及一种服务间依赖关系的管理方法、装置及电子设备。

背景技术

目前，随着业务的发展，涉及的组件越来越多，通过划分服务来区分不同的业务，不同的服务之间存在一定的依赖关系，当依赖的接口发生变更时，被调用方需要了解自己的接口被哪些服务调用，以便提醒调用方适当变更。

相关技术中，服务间的依赖关系可以通过微服务体系下的注册中心获取，但需要建立在已经部署运行的环境上的数据，无法很好的体现不同属性的服务之间的依赖关系，应用范围小。

发明内容

本申请的目的旨在至少在一定程度上解决上述技术问题之一。

为此，本申请提出了一种服务间依赖关系的管理方法，通过获取服务的源文件，从源文件的调用逻辑中提取依赖参数信息，根据依赖参数信息包括的服务的属性信息，以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。由此可以利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

本申请第一方面实施例提出了一种服务间依赖关系的管理方法，包括：针对待处理的多个服务中的每个服务，获取所述服务的源文件；从所述源文件的调用逻辑中提取依赖参数信息，其中，所述依赖参数信息包括：所述服务的属性信息，以及被调用服务的属性信息；根据所述服务的属性信息以及所述被调用服务的属性信息，确定所述服务与所述被调用服务之间的依赖关系。

可选地，所述从所述源文件的调用逻辑中提取依赖参数信息，包括：针对待处理的多个服务中的每个服务，根据所述服务的地址信息，从数据库中所述地址信息对应的存储位置读取所述服务的源文件；从所述服务的源文件中获取所述服务的调用逻辑；从所述调用逻辑中提取所述依赖参数信息。

可选地，所述调用逻辑中封装有依赖参数提取策略；所述从所述调用逻辑中提取所述依赖参数信息，包括：按照所述依赖参数提取策略，从所述调用逻辑中提取所述依赖参数信息。

可选地，所述依赖参数提取策略中包括：所述依赖参数信息的依赖参数名称，以及所述依赖参数名称所在位置与对应的依赖参数特征的所在位置的对应关系；所述按照所述依赖参数提取策略，从所述调用逻辑中提取所述依赖参数信息，包括：根据所述依赖参数名称，获取所述调用逻辑中所述依赖参数名称所在位置；按照所述对应关系以及所述依赖参数名称所在位置，确定所述调用逻辑中所述依赖参数特征的所在位置；根据所述依赖参数特征的所在位置，从所述调用逻辑中提取所述依赖参数特征；根据所述依赖参数名称以及对应的所述依赖参数特征，确定所述依赖参数信息。

可选地，在从所述源文件的调用逻辑中提取依赖参数信息之前，所述方法包括：在devops工作流中增加依赖分析节点，用于从所述服务的源文件的调用逻辑中提取依赖参数信息；所述针对待处理的多个服务中的每个服务，获取所述服务的源文件，从所述源文件的调用逻辑中提取依赖参数信息，包括：将所述服务的地址信息传输给所述devops工作流的所述依赖分析节点，获取所述devops工作流输出的所述依赖参数信息。

可选地，所述方法还包括：将多个所述服务中任意两个服务之间的依赖关系，存储至数据库中。

可选地，所述方法还包括：接收第一依赖关系查询请求，其中，所述第一依赖关系查询请求包括：第一被调用服务的第一属性信息；根据所述第一属性信息查询所述数据库，获取所述数据库中的第一依赖关系，其中，所述第一依赖关系中被调用服务的属性信息中包括所述第一属性信息；根据所述第一依赖关系，确定所述依赖关系查询结果。

可选地，所述依赖参数信息包括：被调用接口描述信息，所述方法还包括：接收第二依赖关系查询请求，其中，所述第二依赖关系查询请求包括：第二被调用服务的第二属性信息和第二被调用接口描述信息，其中，所述被调用接口描述信息对应的接口存在更新；根据所述第二属性信息查询所述数据库，获取所述数据库中的第二依赖关系，其中，所述第二依赖关系中被调用服务的属性信息包括所述第二属性信息，且所述第二依赖关系中被调用服务的被调用接口描述信息包括所述第二被调用接口描述信息；针对所述第二依赖关系中的服务进行接口更新提醒处理。

本申请实施例的服务间依赖关系的管理方法，通过针对待处理的多个服务中的每个服务，获取服务的源文件；从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息；根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。由此可以利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

本申请第二方面实施例提出了一种服务间依赖关系的管理装置，包括：第一获取模块，用于针对待处理的多个服务中的每个服务，获取所述服务的源文件；提取模块，用于从所述源文件的调用逻辑中提取依赖参数信息，其中，所述依赖参数信息包括：所述服务的属性信息，以及被调用服务的属性信息；第一确定模块，用于根据所述服务的属性信息以及所述被调用服务的属性信息，确定所述服务与所述被调用服务之间的依赖关系。

可选地，所述提取模块具体用于，针对待处理的多个服务中的每个服务，根据所述服务的地址信息，从数据库中所述地址信息对应的存储位置读取所述服务的源文件；从所述服务的源文件中获取所述服务的调用逻辑；从所述调用逻辑中提取所述依赖参数信息。

可选地，所述调用逻辑中封装有依赖参数提取策略；所述提取模块具体用于，按照所述依赖参数提取策略，从所述调用逻辑中提取所述依赖参数信息。

可选地，所述依赖参数提取策略中包括：所述依赖参数信息的依赖参数名称，以及所述依赖参数名称所在位置与对应的依赖参数特征的所在位置的对应关系；所述提取模块具体用于，根据所述依赖参数名称，获取所述调用逻辑中所述依赖参数名称所在位置；按照所述对应关系以及所述依赖参数名称所在位置，确定所述调用逻辑中所述依赖参数特征的所在位置；根据所述依赖参数特征的所在位置，从所述调用逻辑中提取所述依赖参数特征；根据所述依赖参数名称以及对应的所述依赖参数特征，确定所述依赖参数信息。

可选地，所述装置还包括：增加模块；所述增加模块，用于在devops工作流中增加依赖分析节点，用于从所述服务的源文件的调用逻辑中提取依赖参数信息；所述提取模块具体用于，将所述服务的地址信息传输给所述devops工作流的所述依赖分析节点，获取所述devops工作流输出的所述依赖参数信息。

可选地，所述装置还包括：存储模块，用于将多个所述服务中任意两个服务之间的依赖关系，存储至数据库中。

可选地，所述装置还包括：第一接收模块、第二获取模块和第二确定模块；所述第一接收模块，用于接收第一依赖关系查询请求，其中，所述第一依赖关系查询请求包括：第一被调用服务的第一属性信息；所述第二获取模块，用于根据所述第一属性信息查询所述数据库，获取所述数据库中的第一依赖关系，其中，所述第一依赖关系中被调用服务的属性信息中包括所述第一属性信息；所述第二确定模块，用于根据所述第一依赖关系，确定所述依赖关系查询结果。

可选地，所述依赖参数信息包括：被调用接口描述信息，所述装置还包括：第二接收模块、第一处理模块和第二处理模块；所述第二接收模块，用于接收第二依赖关系查询请求，其中，所述第二依赖关系查询请求包括：第二被调用服务的第二属性信息和第二被调用接口描述信息，其中，所述被调用接口描述信息对应的接口存在更新；第一处理模块，用于根据所述第二属性信息查询所述数据库，获取所述数据库中的第二依赖关系，其中，所述第二依赖关系中被调用服务的属性信息包括所述第二属性信息，且所述第二依赖关系中被调用服务的被调用接口描述信息包括所述第二被调用接口描述信息；第二处理模块，用于针对所述第二依赖关系中的服务进行接口更新提醒处理。

本申请实施例的服务间依赖关系的管理装置，通过针对待处理的多个服务中的每个服务，获取服务的源文件；从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息；根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。由此可以利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

本申请第三方面实施例提出了一种电子设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如第一方面所述的服务间依赖关系的管理方法。

本申请第四方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面所述的服务间依赖关系的管理方法。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例提供的一种服务间依赖关系的管理方法的流程示意图；

图2为本申请实施例提供的另一种服务间依赖关系的管理方法的流程示意图；

图3为本申请实施例提供的一种服务间依赖关系的获取流程示意图；

图4为根据本申请一个实施例的一种服务间依赖关系的管理装置的结构示意图；

图5为根据本申请一个实施例的电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

目前，随着业务的发展，涉及的组件越来越多，通过划分服务来区分不同的业务，不同的服务之间存在一定的依赖关系，当依赖的接口发生变更时，被调用方需要了解自己的接口被哪些服务调用，以便提醒调用方适当变更。

相关技术中，服务间的依赖关系可以通过微服务体系下的注册中心获取，但需要建立在已经部署运行的环境上的数据，无法很好的体现不同属性的服务之间的依赖关系，应用范围小。

针对上述问题，本申请实施例提出一种服务间依赖关系的管理方法、装置及电子设备。

下面结合图1，对本申请提供的服务间依赖关系的管理方法进行详细说明。

图1为本申请实施例提供的一种服务间依赖关系的管理方法的流程示意图。

本申请实施例的服务间依赖关系的管理方法可应用于服务间依赖关系的管理装置，该装置可被配置于电子设备中，以使该电子设备可以执行服务间依赖关系的管理功能。

其中，电子设备可以为任一具有计算能力的设备，该设备或者该设备中的应用能够执行文档样式生成功能。其中，具有计算能力的设备例如可以为个人电脑(PersonalComputer，简称PC)、移动终端、服务器等，移动终端例如可以为车载设备、手机、平板电脑、个人数字助理、穿戴式设备等具有各种操作系统、触摸屏和/或显示屏的硬件设备。

如图1所示，该服务间依赖关系的管理方法包括以下步骤：

步骤101，针对待处理的多个服务中的每个服务，获取服务的源文件。

其中，待处理的多个服务可以包括：数据接入、数据处理、数据开发、数据共享、数据门户。其中，被调用服务可以包括：用户认证、用户鉴权。

步骤102，从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息。

其中，所述属性信息用于对服务进行描述。同一服务可能会有不同的属性信息。例如，数据开发服务可能会有不同的服务名称、服务版本。被调用的用户认证服务也可能会有不同的服务名称、服务版本。

在一些实施例中，服务的属性信息可以包括：服务名称、服务版本等信息。其中，被调用服务的属性信息可以包括：被调用服务名称、被调用服务版本等信息。由此可以维护服务和被调用服务的服务名称、服务版本等信息之间的依赖关系。

在一些实施例中，服务间依赖关系的管理装置获取服务的源文件的地址信息，根据地址信息，从源文件的调用逻辑中提取依赖参数信息。

其中，调用逻辑可以为SDK调用逻辑，SDK调用逻辑中依赖参数信息可以预先设置。

在一些实施例中，服务间依赖关系的管理装置执行步骤102的过程例如可以为，针对待处理的多个服务中的每个服务，根据服务的地址信息，从数据库中地址信息对应的存储位置读取服务的源文件；从服务的源文件中获取服务的调用逻辑；从调用逻辑中提取依赖参数信息。

其中，根据服务的地址信息，从数据库中地址信息对应的存储位置读取服务的源文件，例如数据接入的源文件，从数据接入的源文件中获取调用逻辑，从调用逻辑中提取依赖参数信息，例如，被调用服务名称为用户认证，被调用服务版本为V1.0，调用方法为Post，调用url为/authorize。

在一些实施例中，根据服务的地址信息，读取服务的源文件，从服务的源文件中获取调用逻辑，从调用逻辑中提取依赖参数信息，以便根据依赖参数信息确定不同属性的服务之间的依赖关系，具有普适性。

其中，调用逻辑中封装有依赖参数提取策略；服务间依赖关系的管理装置从调用逻辑中提取依赖参数信息的过程可以为，按照依赖参数提取策略，从调用逻辑中提取依赖参数信息。

在一些实施例中，依赖参数提取策略中包括：依赖参数信息的依赖参数名称，以及依赖参数名称所在位置与对应的依赖参数特征的所在位置的对应关系；按照依赖参数提取策略，从调用逻辑中提取依赖参数信息，包括：根据依赖参数名称，获取调用逻辑中依赖参数名称所在位置；按照对应关系以及依赖参数名称所在位置，确定调用逻辑中依赖参数特征的所在位置；根据依赖参数特征的所在位置，从调用逻辑中提取依赖参数特征；根据依赖参数名称以及对应的依赖参数特征，确定依赖参数信息。

其中，依赖参数特征可以包括：调用url(统一资源定位系统，uniform resourcelocator)、调用方法。

其中，按照调用逻辑中封装的依赖参数提取策略，可以准确的提取依赖参数信息，从而能够准确获取服务与被调用服务之间的依赖关系。

在一些实施例中，在从源文件的调用逻辑中提取依赖参数信息之前，服务间依赖关系的管理装置可以执行以下过程：在devops工作流中增加依赖分析节点，用于从服务的源文件的调用逻辑中提取依赖参数信息；服务间依赖关系的管理装置执行步骤102的过程还可以为，将服务的地址信息传输给devops工作流的依赖分析节点，获取devops输出的依赖参数信息。

其中，引入devops工作流，各个模块开发只需要按照规范编写代码并合入代码库即可。devops工作流可以定期自动获取最新代码，更新接口依赖关系，不需要人为介入。也就是说，按照规范设置依赖参数信息，devops工作流可以定期自动获取最新的依赖参数信息，根据依赖参数信息，更新接口依赖关系。

在一些实施例中，服务间依赖关系的管理装置将服务的地址信息传输给devops工作流的依赖分析节点，利用devops工作流中增加的依赖分析节点，从服务的源文件的调用逻辑中提取依赖参数信息。也就是说，devops工作流能够将接收到的地址信息传递给具体的执行模块，该模块自动根据地址信息，从源文件的调用逻辑中提取依赖参数信息。从而能够利用devops工作流，自动提取依赖参数信息，以根据依赖参数信息确定不同属性的服务之间的依赖关系，提高依赖关系的获取效率。

步骤103，根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。

其中，服务与被调用服务之间的依赖关系可以如表1所示，在表1中，服务为数据接入，服务版本为V1.0时，被调用服务为用户认证，调用url可以为/authorize、/user，调用方法可以为Post、Get。

表1

服务名称	服务版本	被调用服务名称	调用url	调用方法
					数据接入	V1.0	用户认证	/authorize	Post
数据接入	V1.0	用户认证	/user	Get
					数据接入	V1.1	用户认证	/authorize	Post
数据接入	V1.1	用户认证	/user1	Get

本申请实施例提供的服务间依赖关系的管理方法，通过针对待处理的多个服务中的每个服务，获取服务的源文件；从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息；根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。由此可以利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

为了将服务间依赖关系存储到数据库中，实现服务间依赖关系的管理，如图2所示，对本申请提供的服务间依赖关系的管理方法进行进一步说明。

图2为本申请实施例提供的另一种服务间依赖关系的管理方法的流程示意图。如图2所示，该方法可以包括以下步骤：

步骤201，针对待处理的多个服务中的每个服务，获取服务的源文件。

步骤202，从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息。

步骤203，根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。

步骤204，将多个服务中任意两个服务之间的依赖关系，存储至数据库中。

在一些实施例中，服务间依赖关系的管理装置还可以执行以下过程：接收第一依赖关系查询请求，其中，第一依赖关系查询请求包括：第一被调用服务的第一属性信息；根据第一属性信息查询数据库，获取数据库中的第一依赖关系，其中，第一依赖关系中被调用服务的属性信息中包括第一属性信息；根据第一依赖关系，确定依赖关系查询结果。

其中，第一被调用服务可以为用户认证，第一属性信息可以包括以下信息的至少一种：第一被调用服务名称、第一被调用服务版本。

其中，服务间依赖关系的管理装置接收第一依赖关系查询请求，根据第一依赖关系查询请求中的第一属性信息查询数据库，获取数据库中的第一依赖关系，根据第一依赖关系，确定依赖关系查询结果，从而能够准确的确定服务间的依赖关系。

其中，依赖关系查询结果可以如表2所示。

表2

被调用服务名称	调用url	调用方法	服务名称	服务版本
					用户认证	/authorize	Post	数据接入	V1.0，V1.1
用户认证	/user	Get	数据接入	V1.0
					用户认证	/user1	Get	数据接入	V1.1

在一些实施例中，依赖参数信息包括：被调用接口描述信息，服务间依赖关系的管理装置还可以执行以下过程：接收第二依赖关系查询请求，其中，第二依赖关系查询请求包括：第二被调用服务的第二属性信息和第二被调用接口描述信息，其中，被调用接口描述信息对应的接口存在更新；根据第二属性信息查询数据库，获取数据库中的第二依赖关系，其中，第二依赖关系中被调用服务的属性信息包括第二属性信息，且第二依赖关系中被调用服务的被调用接口描述信息包括第二被调用接口描述信息；针对第二依赖关系中的服务进行接口更新提醒处理。

其中，被调用接口描述信息可以包括：调用url、调用方法。

其中，服务间依赖关系的管理装置接收第二依赖关系查询请求，根据第二依赖关系查询请求中的第二属性信息查询数据库，获取数据库中的第二依赖关系，其中，被调用接口描述信息对应的接口存在更新，能够针对第二依赖关系中的服务，及时进行接口更新提醒处理，从而能够减少接口更新的影响。

其中，需要说明的是，步骤201、步骤202和步骤203的详细内容，可以参考图1所示实施例中的步骤102、步骤102和步骤103，此处不在进行详细的说明。

本申请实施例中的服务间依赖关系的管理方法，针对待处理的多个服务中的每个服务，获取服务的源文件；从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息；根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系；将多个服务中任意两个服务之间的依赖关系，存储至数据库中。由此可以利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，在接口存在更新时，及时提醒，以减少接口更新的影响，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

举例说明，图3为服务间依赖关系的获取流程示意图，在图3中，devops工作流可以包括以下节点：自动代码下载、自动版本部署、自动版本测试、自动依赖分析。接收devops工作流调度任务，触发“自动依赖分析”节点执行，该“自动依赖分析”节点负责收集“代码依赖分析模块”运行需要的参数，例如，代码的位置、代码的地址(源文件的地址信息)等，并将该参数传递给“代码依赖分析模块”(具体的执行模块)，以触发“代码依赖分析模块”启动。“代码依赖分析模块”根据devops工作流的“自动依赖分析”节点传递的代码的地址从git仓库下载代码(源文件)，从源文件中获取SDK调用逻辑(调用SDK的代码)，从SDK调用逻辑中提取依赖参数信息(SDK规范标准配置信息)，其中，SDK规范标准配置信息包括：(1)调用方模块名称(服务名称)、调用方模块版本(服务版本)，比如，数据接入、数据共享，版本为V1.0，版本号需要与真实版本一致，要求取自一个配置；(2)被调用方模块名称(被调用服务)，比如，用户认证；(3)被调用方接口描述信息：包括调用url、调用方法。通过调用“代码依赖存储查询模块”提供的接口，将SDK规范标准配置信息存储到数据库中，用户可以通过“代码依赖存储查询模块”提供的页面服务，查询数据库中调用方模块与被调用方模块之间的依赖关系。

与上述几种实施例提供的服务间依赖关系的管理方法相对应，本申请的一种实施例还提供一种服务间依赖关系的管理装置。由于本申请实施例提供的服务间依赖关系的管理装置与上述几种实施例提供的服务间依赖关系的管理方法相对应，因此在服务间依赖关系的管理方法的实施方式也适用于本实施例提供的服务间依赖关系的管理装置，在本实施例中不再详细描述。

图4为根据本申请一个实施例的服务间依赖关系的管理装置的结构示意图。

如图4所示，该服务间依赖关系的管理装置400，可以包括：第一获取模块410、提取模块420和第一确定模块430。

其中，所述第一获取模块410，用于针对待处理的多个服务中的每个服务，获取所述服务的源文件；

所述提取模块420，用于从所述源文件的调用逻辑中提取依赖参数信息，其中，所述依赖参数信息包括：所述服务的属性信息，以及被调用服务的属性信息；

所述第一确定模块430，用于根据所述服务的属性信息以及所述被调用服务的属性信息，确定所述服务与所述被调用服务之间的依赖关系。

作为本申请实施例的一种可能实现方式，所述提取模块420具体用于，针对待处理的多个服务中的每个服务，根据所述服务的地址信息，从数据库中所述地址信息对应的存储位置读取所述服务的源文件；从所述服务的源文件中获取所述服务的调用逻辑；从所述调用逻辑中提取所述依赖参数信息。

作为本申请实施例的一种可能实现方式，所述调用逻辑中封装有依赖参数提取策略；所述提取模块420具体用于，按照所述依赖参数提取策略，从所述调用逻辑中提取所述依赖参数信息。

作为本申请实施例的一种可能实现方式，所述依赖参数提取策略中包括：所述依赖参数信息的依赖参数名称，以及所述依赖参数名称所在位置与对应的依赖参数特征的所在位置的对应关系；所述提取模块420具体用于，根据所述依赖参数名称，获取所述调用逻辑中所述依赖参数名称所在位置；按照所述对应关系以及所述依赖参数名称所在位置，确定所述调用逻辑中所述依赖参数特征的所在位置；根据所述依赖参数特征的所在位置，从所述调用逻辑中提取所述依赖参数特征；根据所述依赖参数名称以及对应的所述依赖参数特征，确定所述依赖参数信息。

作为本申请实施例的一种可能实现方式，所述装置还包括：增加模块；所述增加模块，用于在devops工作流中增加依赖分析节点，用于从所述服务的源文件的调用逻辑中提取依赖参数信息；所述提取模块420具体用于，将所述服务的地址信息传输给所述devops工作流的所述依赖分析节点，获取所述devops工作流输出的所述依赖参数信息。

作为本申请实施例的一种可能实现方式，所述装置还包括：存储模块，用于将多个所述服务中任意两个服务之间的依赖关系，存储至数据库中。

作为本申请实施例的一种可能实现方式，所述装置还包括：第一接收模块、第二获取模块和第二确定模块；所述第一接收模块，用于接收第一依赖关系查询请求，其中，所述第一依赖关系查询请求包括：第一被调用服务的第一属性信息；所述第二获取模块，用于根据所述第一属性信息查询所述数据库，获取所述数据库中的第一依赖关系，其中，所述第一依赖关系中被调用服务的属性信息中包括所述第一属性信息；所述第二确定模块，用于根据所述第一依赖关系，确定所述依赖关系查询结果。

作为本申请实施例的一种可能实现方式，所述依赖参数信息包括：被调用接口描述信息，所述装置还包括：第二接收模块、第一处理模块和第二处理模块；所述第二接收模块，用于接收第二依赖关系查询请求，其中，所述第二依赖关系查询请求包括：第二被调用服务的第二属性信息和第二被调用接口描述信息，其中，所述被调用接口描述信息对应的接口存在更新；第一处理模块，用于根据所述第二属性信息查询所述数据库，获取所述数据库中的第二依赖关系，其中，所述第二依赖关系中被调用服务的属性信息包括所述第二属性信息，且所述第二依赖关系中被调用服务的被调用接口描述信息包括所述第二被调用接口描述信息；第二处理模块，用于针对所述第二依赖关系中的服务进行接口更新提醒处理。

本申请实施例中的服务间依赖关系的管理装置，针对待处理的多个服务中的每个服务，获取服务的源文件，从源文件的调用逻辑中提取依赖参数信息，其中，依赖参数信息包括：服务的属性信息，以及被调用服务的属性信息；根据服务的属性信息以及被调用服务的属性信息，确定服务与被调用服务之间的依赖关系。由此可以利用源文件存储的服务调用逻辑和服务属性信息和来维护不同属性的服务与被调用服务之间的依赖关系，与相关技术相比，一方面，能获取不同属性的服务之间的依赖关系，具有普适性，另一方面，可以在无需开发大量代码的情形下，利用源文件中存储的信息，便利地完成依赖关系的维护。

为了实现上述实施例，本申请还提出一种电子设备，图5为本申请实施例提供的一种电子设备的结构示意图。该电子设备包括：

存储器501、处理器502及存储在存储器501上并可在处理器502上运行的计算机程序。

处理器502执行所述程序时实现上述实施例中提供的服务间依赖关系的管理方法。

进一步地，电子设备还包括：

通信接口503，用于存储器501和处理器502之间的通信。

存储器501，用于存放可在处理器502上运行的计算机程序。

存储器501可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

处理器502，用于执行所述程序时实现上述实施例所述的服务间依赖关系的管理方法。

如果存储器501、处理器502和通信接口503独立实现，则通信接口503、存储器501和处理器502可以通过总线相互连接并完成相互间的通信。所述总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(PeripheralComponent，简称为PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，简称为EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器501、处理器502及通信接口503，集成在一块芯片上实现，则存储器501、处理器502及通信接口503可以通过内部接口完成相互间的通信。

处理器502可能是一个中央处理器(Central Processing Unit，简称为CPU)，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。

为了实现上述实施例，本申请实施例还提出一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述实施例中提供的服务间依赖关系的管理方法。

为了实现上述实施例，本申请实施例还提出一种计算机程序产品，当所述计算机程序产品中的指令处理器执行时，实现上述实施例中提供的服务间依赖关系的管理方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (11)

1.一种服务间依赖关系的管理方法，其特征在于，包括：

针对待处理的多个服务中的每个服务，获取所述服务的源文件；

从所述源文件的调用逻辑中提取依赖参数信息，其中，所述依赖参数信息包括：所述服务的属性信息，以及被调用服务的属性信息；

根据所述服务的属性信息以及所述被调用服务的属性信息，确定所述服务与所述被调用服务之间的依赖关系。

2.根据权利要求1所述的方法，其特征在于，所述从所述源文件的调用逻辑中提取依赖参数信息，包括：

针对待处理的多个服务中的每个服务，根据所述服务的地址信息，从数据库中所述地址信息对应的存储位置读取所述服务的源文件；

从所述服务的源文件中获取所述服务的调用逻辑；

从所述调用逻辑中提取所述依赖参数信息。

3.根据权利要求2所述的方法，其特征在于，所述调用逻辑中封装有依赖参数提取策略；

所述从所述调用逻辑中提取所述依赖参数信息，包括：

按照所述依赖参数提取策略，从所述调用逻辑中提取所述依赖参数信息。

4.根据权利要求3所述的方法，其特征在于，所述依赖参数提取策略中包括：所述依赖参数信息的依赖参数名称，以及所述依赖参数名称所在位置与对应的依赖参数特征的所在位置的对应关系；

所述按照所述依赖参数提取策略，从所述调用逻辑中提取所述依赖参数信息，包括：

根据所述依赖参数名称，获取所述调用逻辑中所述依赖参数名称所在位置；

按照所述对应关系以及所述依赖参数名称所在位置，确定所述调用逻辑中所述依赖参数特征的所在位置；

根据所述依赖参数特征的所在位置，从所述调用逻辑中提取所述依赖参数特征；

根据所述依赖参数名称以及对应的所述依赖参数特征，确定所述依赖参数信息。

5.根据权利要求1所述的方法，其特征在于，在从所述源文件的调用逻辑中提取依赖参数信息之前，所述方法包括：

在devops工作流中增加依赖分析节点，用于从所述服务的源文件的调用逻辑中提取依赖参数信息；

所述针对待处理的多个服务中的每个服务，获取所述服务的源文件，从所述源文件的调用逻辑中提取依赖参数信息，包括：

将所述服务的地址信息传输给所述devops工作流的所述依赖分析节点，获取所述devops工作流输出的所述依赖参数信息。

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

将多个所述服务中任意两个服务之间的依赖关系，存储至数据库中。

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

接收第一依赖关系查询请求，其中，所述第一依赖关系查询请求包括：第一被调用服务的第一属性信息；

根据所述第一属性信息查询所述数据库，获取所述数据库中的第一依赖关系，其中，所述第一依赖关系中被调用服务的属性信息中包括所述第一属性信息；

根据所述第一依赖关系，确定所述依赖关系查询结果。

8.根据权利要求6所述的方法，其特征在于，所述依赖参数信息包括：被调用接口描述信息，所述方法还包括：

接收第二依赖关系查询请求，其中，所述第二依赖关系查询请求包括：第二被调用服务的第二属性信息和第二被调用接口描述信息，其中，所述被调用接口描述信息对应的接口存在更新；

根据所述第二属性信息查询所述数据库，获取所述数据库中的第二依赖关系，其中，所述第二依赖关系中被调用服务的属性信息包括所述第二属性信息，且所述第二依赖关系中被调用服务的被调用接口描述信息包括所述第二被调用接口描述信息；

针对所述第二依赖关系中的服务进行接口更新提醒处理。

9.一种服务间依赖关系的管理装置，其特征在于，包括：

第一获取模块，用于针对待处理的多个服务中的每个服务，获取所述服务的源文件，

提取模块，用于从所述源文件的调用逻辑中提取依赖参数信息，其中，所述依赖参数信息包括：所述服务的属性信息，以及被调用服务的属性信息；

第一确定模块，用于根据所述服务的属性信息以及所述被调用服务的属性信息，确定所述服务与所述被调用服务之间的依赖关系。

10.一种电子设备，其特征在于，包括：

存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如权利要求1-8中任一项所述的服务间依赖关系的管理方法。

11.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如如权利要求1-8中任一项所述的服务间依赖关系的管理方法。

Images