依赖关系可视化方法、装置、设备和存储介质

摘要

本发明实施例提供一种依赖关系可视化方法、装置、设备和存储介质，该方法包括：处理设备获取包含不同服务实例之间的依赖关系的配置文件，并对文件中的依赖关系进行合并处理。接着，响应于用户对处理结果触发的选择操作，处理设备再从合并处理结果中确定目标依赖关系，并按照不同服务实例各自的预设展示样式展示目标依赖关系。可见，上述方法是一种依赖关系可视化的方法。并且配置文件中的依赖关系同时包含服务实体之间的调用关系或引用关系，依赖关系是全面的。同时，响应于选择操作得到的目标依赖关系所包含的服务实例，又会按照其各自对应的预设展示样式展示，使得用户能够清晰地了解服务实例之间的依赖关系。

说明书

技术领域

本发明涉及互联网技术领域，尤其涉及一种依赖关系可视化方法、装置、设备和存储介质。

背景技术

随着互联网和终端设备的不断发展，人们可以借助不同的应用程序(Application，简称APP)来提出各种需求，比如外卖需求、保洁需求、货物运输需求等等，APP会对用户的需求生成一个订单。

以家政保洁场景为例，与保洁APP存在交互过程的服务器内会设置有多种服务实例，比如订单服务实例、交易服务实例、日志服务实例、缓存服务实例等等，通过这些服务实例之间的调用或引用，可以保证保洁APP的正常使用，即用户通过保洁APP下单，并最终享受到保洁服务。

在保洁APP的实际开发、升级或定期维护过程中，需要对服务器内不同服务实例之间依赖关系的复杂度、合理性进行优化。为了便于优化，如何实现不同的服务实例之间依赖关系的可视化就成为一个亟待解决的问题。

发明内容

有鉴于此，本发明实施例提供一种依赖关系可视化方法、装置、设备和存储介质，用以实现服务实例之间依赖关系的可视化。

第一方面，本发明实施例提供一种依赖关系可视化方法，包括：

获取包含不同服务实例之间依赖关系的配置文件，所述依赖关系包括所述不同服务实体之间的调用关系或者引用关系；

对所述配置文件中的依赖关系进行合并处理，以得到处理结果；

响应于用户触发的选择操作，在所述处理结果中确定目标依赖关系；

根据不同服务实例各自的预设展示样式，展示所述目标依赖关系。

第二方面，本发明实施例提供一种依赖关系可视化装置，包括：

获取模块，用于获取包含不同服务实例之间依赖关系的配置文件，所述依赖关系包括所述不同服务实体之间的调用关系或者引用关系；

合并模块，用于对所述配置文件中的依赖关系进行合并处理，以得到处理结果；

确定模块，用于响应于用户触发的操作，在所述处理结果中确定目标依赖关系；

展示模块，用于根据不同服务实例各自的预设展示样式，展示所述目标依赖关系。

第三方面，本发明实施例提供一种电子设备，包括：存储器，以及与所述存储器连接的处理器；

所述存储器，用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令供所述处理器调用执行；

所述处理器，用于执行所述一条或多条计算机指令以上述第一方面中的依赖关系可视化方法。

第四方面，本发明实施例提供了一种计算机存储介质，用于储存存储计算机程序，所述计算机程序使计算机执行时实现上述第一方面中的依赖关系可视化方法。

本发明实施例提供的依赖关系可视化方法、装置、设备和存储介质，该方法包括：处理设备获取配置文件，此文件中包括不同服务实例之间的依赖关系，依赖关系包括服务实体之间的调用关系和引用关系。然后，对配置文件中记录的依赖关系进行合并处理，以得到处理结果。接着，响应于用户对处理结果触发的选择操作，以从上述的处理结果中确定目标依赖关系，此目标依赖关系中可以包括相同或不同级别的服务实例之间的依赖关系。最终，按照不同服务实例各自的预设展示样式，对目标依赖关系中的服务实例进行展示。

可见，上述方法是一种依赖关系的可视化方法。配置文件中的依赖关系同时包含服务实例之间的调用关系和引用关系，获取的依赖关系更全面。同时，响应于选择操作得到的目标依赖关系所包含的服务实例又会按照其各自对应的预设展示样式进行展示，使得用户能够清晰地了解服务实例之间的依赖关系。

附图说明

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

图1为本发明实施例提供的一种依赖关系可视化方法的流程图；

图2为本发明实施例提供的一种依赖关系可视化结果的示意图；

图3为本发明实施例提供的另一种依赖关系可视化方法的流程图；

图4为本发明实施例提供的另一种依赖关系可视化结果的示意图；

图5为本发明实施例提供的一种依赖关系可视化装置的结构示意图；

图6为与图5所示实施例提供的依赖关系可视化装置对应的电子设备的结构示意图。

具体实施方式

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

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于测试”。类似地，取决于语境，短语“如果确定”或“如果测试(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当测试(陈述的条件或事件)时”或“响应于测试(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

承接上述背景技术中的描述，日常生活中已经存在为用户提供不同类型服务的多款APP，不同的APP可以生成不同类型的订单，比如外卖订单，货物运输订单、家政保洁订单等等，再将订单分配给服务商家，从而实现为用户提供相应的服务。

在实际中，APP与服务器之间通过交互可以实现订单的支付、接收、分配等过程，并最终实现为用户提供某种服务。而上述对订单的不同处理又需要借助服务器中配置的多个服务实例以及多个服务实例之间的依赖关系来实现。其中，服务实例之间的依赖关系通常表现为服务实例之间的调用关系或者引用关系。并且服务实例之间的依赖关系通常是复杂的，当然也有可能是不合理的。

在APP的升级或者开发阶段，服务器也需要配合进行优化，也即是需要对服务器中不同服务实例之间的依赖关系进行优化，以降低依赖关系之间的复杂度，提高依赖关系之间的合理性。在依赖关系调整之前，若能清晰地将服务实例之间的依赖关系展示处理，以使用户清晰地了解到当前依赖关系中存在的问题，则可以大大降低依赖关系调整的难度。对于依赖关系的可视化过程，则可以使用本发明下述各实施例提供方法。

需要说明的有，本发明各实施例提供的依赖关系可视化方法的使用场景不限定于上述场景，任何存在依赖关系可视化需求的场景都可以使用本发明各实施例提供的可视化方法。

图1为本发明实施例提供的一种依赖关系可视化方法的流程图。本实施例提供的该依赖关系可视化方法的执行主体可以为处理设备，处理设备具体来说可以是与APP存在交互的服务器中的插件。如图1所示，该方法包括如下步骤：

S101，获取包含不同服务实例之间依赖关系的配置文件，依赖关系包括不同服务实体之间的调用关系或者引用关系。

处理设备可以获取包含不同服务实例之间依赖关系的配置文件。其中，服务实例以及不同服务实例之间的依赖关系进行以下理解：

不同服务实例之间的依赖关系具体可以包括引用关系或者调用关系。这些关系已经被预先写入配置文件中。

对于服务实例，每个服务实例都提供一定的功能，多个服务实例结合使用，则可以为用户完整的提供一种服务。按照功能不同，可选地，常见的服务实例可以包括订单服务实例、交易服务实例、日志服务实例、缓存服务实例等等。

具体来说，订单服务实例用于提供订单的接收和分配功能，订单可以由用户借助APP产生。交易服务实例用于提供订单的支付功能。日志服务实例用于提供不同服务实例各自的运行情况的记录功能。其记录的内容比如可以包括服务实例的接口使用情况，服务实例之间的调用情况等等。缓存服务实例用于为订单服务实例、交易服务实例等其他服务实例提供缓存机制。

S102，对配置文件中的依赖关系进行合并处理，以得到处理结果。

在实际中，上述获取到的配置文件的数量可以是多个，并且配置文件中包含的依赖关系可能存在重复，因此，还需要对上述文本形式的依赖关系进行合并处理，此合并处理也可以认为是去重处理。处理结果同样可以以文本形式保存于处理设备本地。

S103，响应于用户触发的操作，在处理结果中确定目标依赖关系。

S104,根据不同服务实例各自的预设展示样式，展示目标依赖关系。

在得到处理结果后，用户还可以在处理设备提供的界面上触发对服务实例的操作，比如可以是对服务实例的选择或者输入操作，以得到用户想要重点关注的服务实例，重点关注的服务实例可以是全部服务实例中的至少一个。

若用户触发的是输入操作，则处理设备可以根据用户输入的服务实例的身份标识，在处理结果中查询所有与用户选中的服务实例有关的依赖关系，即目标依赖关系。最终，处理设备可以按照不同服务实例各自对应的预设展示样式对包含服务实例的目标依赖关系进行展示。

可选地，预设展示样式可以包括：不同的服务实例可以以不同形状、不同的颜色进行展示，并且服务实例之间依赖关系的方向性也可以通过有向线段表示，此内容可以结合图2理解。这样用户可以直观地了解到不同服务实例的依赖关系的复杂度和合理性。

在图2中，订单服务实例与日志服务实例和缓存服务实例存在依赖关系，每个服务实例可以表示为不同的形状，并且订单服务实例能够分别引用日志服务实例和缓存服务实例。

本实施例中，处理设备获取配置文件，此文件中包括不同服务实例之间的依赖关系。然后，对配置文件中记录的依赖关系进行合并处理，以得到处理结果。接着，响应于用户对处理结果触发的选择操作，以从上述的处理结果中确定目标依赖关系，此目标依赖关系中可以包括相同或不同级别的服务实例之间的依赖关系。最终，按照不同服务实例各自的预设展示样式，对目标依赖关系中的服务实例进行展示。

可见，上述方法是一种依赖关系的可视化方法。配置文件中的依赖关系同时包含服务实例之间的调用关系和引用关系，获取到的依赖关系更全面。同时，响应于选择操作得到的目标依赖关系所包含的服务实例又会按照其各自对应的预设展示样式进行展示，使得用户能够清晰地了解服务实例之间的依赖关系。

根据上述描述可知，依赖关系具体可以包括服务实例之间的引用关系或者调用关系。然而，日志服务实例也可以记录有服务实例之间的调用关系，若直接对日志中记录的调用关系并进行可视化容易出现以下问题：

假设一个预设时间段，日志服务实例记录的只是在此预设时间段内，实际产生的服务实例之间的调用关系，其不会记录服务实例之间的引用关系，也不会记录在预设时间段内没有产生实际调用的服务实例之间引用关系、调用关系。因此，通过日志获取到的依赖关系是不完整的，进行可视化显然也不能显示出完整的依赖关系。

而图1所示实施例中配置文件包含的依赖关系是预先设置好的、全部的依赖关系，配置文件中包含的依赖关系不依赖于在预设时间段内服务实例之间是否真正发生调用或引用，也就不会出现上述问题。

可选地，在实际中，服务实例也可以具有级别。基于不同服务实例的级别，图3为本发明实施例提供的另一种依赖关系可视化方法的流程图。如图3所示，该方法包括如下步骤：

S201，获取多个最高级别的服务实例各自对应的第一配置文件。

S202，获取第二配置文件，第二配置文件中包括其他级别的服务实例之间的引用关系。

可以先对服务实例的级别进行说明：在多个服务实例中，为保证用户能够正常享受服务所必须的服务实例具有最高级别。为优化服务器和APP各自的对订单的处理流程，进一步提高用户的使用体验，所需要的服务实例可以具有次高级别，甚至更低级别。也就是说，其他级别的服务实例可以为最高级别的服务实例提供辅助支持。则承接上述举例，订单服务实例、交易服务实例具有的级别最高，日志服务实例和缓存服务实例具有的级别次高。

可选地，基于不同服务实例各自的级别，不同服务实例之间的依赖关系具体也即是：最高级别的多个服务实例之间的调用关系；最高级别的服务实例与其他级别的服务实例之间的引用关系；多个其他级别的服务实例之间的引用关系。其中，与最高级别的服务实例相关的引用关系和调用关系可以保存于第一配置文件中，其他级别的服务实例之间的引用关系可以保存于第二配置文件中。

并且可选地，第一配置文件的数量可以与最高级别的服务实例的数量相等。则对于最高级别的服务实例中的任一个服务实例，即目标服务实例来说，此目标服务实例与其他最高级别服务实例之间的直接调用关系，以及与其他级别的服务实例之间的直接引用关系会被存储到一个单独的第一配置文件中。

S203,对第一配置文件和第二配置文件中的依赖关系进行合并处理，以得到处理结果。

一条依赖关系在配置文件可以表现为“服务实例A—服务实例B”，若此依赖关系保存于第一配置文件中，则表明服务实例A与服务实例B之间存在调用或者引用关系。若此依赖关系保存于第二配置文件中，则表明服务实例A与服务实例B之间存在引用关系，服务实例A、服务实例B均不是最高级别的服务实例。

基于上述描述，则在得到第一配置文件后，可选地，处理设备对依赖关系的合并处理可以包括：

若第一调用关系包含的被调用方与第二调用关系包含的调用方相同，则将第一调用关系与第二调用关系合并，其中，第一调用关系和第二调用关系包含于不同的第一配置文件中，即两条调用关系的调用方是两个不同的最高级别的服务实例。

举例来说，若第一调用关系为“服务实例A—服务实例B”，其表明服务实例A调用服务实例B，服务实例A是调用方，服务实例B是被调动方。第二调用关系为“服务实例B—服务实例C”，具体解释与上述的第一调用关系类似，在此不再赘述。这两条关系的都包含相同的服务实例B，则二者可以合并为一条依赖关系“服务实例A—服务实例B—服务实例C”。其中，服务实例A、服务实例B为最高级别的服务实例，上述两条调用关系可以分别存储于服务实例A、服务实例B对应的第一配置文件中。

类似的，对于同一第一配置文件中的调用关系和引用关系，也可以按照上述方式进行合并。即若调用关系包含的被调用方与引用关系包含的引用方相同，则将调用关系和引用关系合并。比如调用关系为“服务实例a—服务实例b”，其表明服务实例a调用服务实例b，服务实例a是调用方，服务实例b是被调动方。引用关系为“服务实例b—服务实例c”，其表明服务实例b引用服务实例c，服务实例b是引用方，服务实例c是被引用方。则合并结果后的依赖关系为“服务实例a—服务实例b--服务实例c”。

在得到第二配置文件后，可选地，对依赖关系的合并处理可以包括：

若第一引用关系包含的被引用方与第二引用关系包含的被引用方相同，则将第一引用关系与第二引用关系合并。其中，第一引用关系和第二引用关系包含于第二配置文件中。

经过上述合并处理后到的合并结果描述的是至少两个服务实例之间的依赖关系。经过合并后还可以将多条深度较浅的依赖关系整合成一条深度较深的依赖关系。其中，一条依赖关系中包含的服务实例数量越多，该依赖关系的深度越深。可见，上述依赖关系的合并处理实际上就是对多个配置文件中依赖关系的去重、整合处理的过程。

S204，响应于用户触发的操作，在处理结果中确定目标依赖关系。

S205，根据不同服务实例各自的预设展示样式，展示目标依赖关系。

可选地，用户可以进一步在处理设备提供的界面上触发对目标级别的选择操作。处理设备响应于此选择操作，在处理结果中，将包含此目标级别的服务实例的依赖关系确定为目标依赖关系。之后，对此目标依赖关系进行可视化，也即是实现级别维度的依赖关系的可视化。

可选地，在选择目标级别后，用户还可以进一步输入服务实例的目标身份标识。服务设备会从处理结果中，将包含目标级别以及目标身份标识的服务实例的依赖关系确定为目标依赖关系，并对其进行可视化。此时，也即是实现了服务实例维度的依赖关系的可视化。

并且对于依赖关系的可视化，在实际中相同级别的服务实例通常使用相同的形状、颜色来展示。

本实施例中，用户可以触发不同粒度的操作，比如目标级别的选择操作获取身份标识的输入操作。响应于此操作，处理设备可以实现不同维度的依赖关系的可视化，使得服务实例的可视化更加灵活。

在实际中，在对服务实例进行合并处理后得到的处理结果中，可能会出现环形依赖关系或者深度依赖关系。这两种依赖关系都是需要被重点关注的，也是需要被重点优化的依赖关系。

因此，可选地，响应于用户的操作，若处理设备筛选出的目标依赖关系包含环形依赖关系，则突出显示此环形依赖关系。举例来说，此环形依赖关系为“服务实例A—服务实例B—服务实例C—服务实例A”，则对环形依赖关系的突出显示可以是将目标依赖关系中的环形依赖关系的背景设置为预设颜色，如图4中的(a)所示。

可选地，响应于用户的操作，处理设备可以筛选出目标依赖关系。之后，处理设备可以进一步获取目标依赖关系中服务实例的数量。当目标依赖关系的数量为一条时，则判断此条目标依赖关系中包含的服务实例的数量。若数量大于预设值，表明此条目标依赖关系是深度依赖关系，则会将其突出显示。当目标依赖关系为多条依赖关系时，处理设备可以分别统计每条依赖关系中包含的服务实例的数量，并确定每条依赖关系是否时深度依赖关系，以确定是否需要对其进行突出显示。

举例来说，一条深度依赖关系可以为“服务实例A—服务实例B—服务实例C—服务实例D—服务实例E”，将其突出展示的结果可以如图4中的(b)所示。

图4所示的展示形式中既包含依赖关系的突出展示，又包括根据服务实例各自对应的预设展示样式，对不同的服务实例进行展示。在实际中这两种展示形式也可以单独使用。

以下将详细描述本发明的一个或多个实施例的依赖关系可视化装置。本领域技术人员可以理解，这些依赖关系可视化装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图5为本发明实施例提供的一种依赖关系可视化装置的结构示意图，如图5所示，该订单分配装置包括：

获取模块11，用于获取包含不同服务实例之间依赖关系的配置文件，所述依赖关系包括所述不同服务实体之间的调用关系或者引用关系。

合并模块12，用于对所述配置文件中的依赖关系进行合并处理，以得到处理结果。

确定模块13，用于响应于用户触发的操作，在所述处理结果中确定目标依赖关系。

展示模块14，用于根据不同服务实例各自的预设展示样式，展示所述目标依赖关系。

可选地，所述获取模块11，用于获取多个最高级别的服务实例各自对应的第一配置文件，其中，目标服务实例为最高级别的服务实例中的任一个，所述目标服务实例对应的第一配置文件中包含所述目标服务实例与其他最高级别的服务实例之间的调用关系，以及所述目标服务实例与其他级别的服务实例之间的引用关系；以及获取第二配置文件，所述第二配置文件中包括其他级别的服务实例之间的引用关系。

可选地，所述合并模块12，用于若第一调用关系包含的被调用方与第二调用关系包含的调用方相同，则将所述第一调用关系与所述第二调用关系合并，所述第一调用关系和所述第二调用关系包含于不同的第一配置文件中。

可选地，所述合并模块12，用于若第一引用关系包含的被引用方与第二引用关系包含的被引用方相同，则将所述第一引用关系与所述第二引用关系合并，所述第一引用关系和所述第二引用关系包含于所述第二配置文件中。

可选地，所述确定模块13，用于响应于所述用户对目标级别的选择操作，将包含所述目标级别的服务实例的依赖关系确定为所述目标依赖关系。

可选地，所述确定模块13，还用于响应于所述用户输入的目标身份标识，将包含所述目标级别标识以及所述目标身份标识的服务实例的依赖关系，确定为所述目标依赖关系。

可选地，所述展示模块14，还用于若所述目标依赖关系中包含环形依赖关系，则突出展示所述环形依赖关系。

可选地，所述展示模块14，还用于获取所述目标依赖关系中包含的服务实体的数量；以及若所述数量大于预设值，则突出展示所述目标依赖关系。

图5所示装置可以执行图1～图4所示实施例的方法，本实施例未详细描述的部分，可参考对图1～图4所示实施例的相关说明。该技术方案的执行过程和技术效果参见图1～图4所示实施例中的描述，在此不再赘述。

以上描述了依赖关系可视化装置的内部功能和结构，在一个可能的设计中，依赖关系可视化装置的结构可实现为一电子设备，例如计算机。图6为本发明实施例提供的电子设备实施例一的结构示意图，如图6所示，该电子设备包括：存储器21，以及与存储器连接的处理器22，存储器21用于存储电子设备执行上述任一实施例中提供的依赖关系可视化方法的程序，处理器22被配置为用于执行存储器21中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被处理器22执行时能够实现如下步骤：

获取包含不同服务实例之间依赖关系的配置文件，所述依赖关系包括所述不同服务实体之间的调用关系或者引用关系；

对所述配置文件中的依赖关系进行合并处理，以得到处理结果；

响应于用户触发的选择操作，在所述处理结果中确定目标依赖关系；

根据不同服务实例各自的预设展示样式，展示所述目标依赖关系。

可选地，处理器22还用于执行前述各方法步骤中的全部或部分步骤。

其中，电子设备的结构中还可以包括通信接口23，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存上述电子设备所用的计算机软件指令，其包含用于执行上述图1～图4所示方法实施例中依赖关系可视化方法所涉及的程序。

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