CN115705190A - 依赖程度的确定方法及装置 - Google Patents

Abstract

本申请公开了一种依赖程度的确定方法及装置。该方法包括：获取待处理的依赖关系；其中，待处理的依赖关系描述了调用方和被调用方之间的调用关系；确定调用方和被调用方所指示的调用链路和服务功能；利用预设远程过程调用框架的拦截器功能向调用链路进行故障注入，以使得被调用方基于模拟故障出现调用异常；执行服务功能对应的测试用例；基于测试用例的执行结果确定待处理的依赖关系的依赖程度。本申请利用远程过程调用框架的拦截器功能进行故障注入以模拟依赖服务的故障，从而基于相关服务的测试用例的执行结果来确定依赖程度。这样不仅提高了依赖程度的确定效率，还通过对故障影响范围的控制降低了系统风险、保证了系统的稳定性。

Description

依赖程度的确定方法及装置

技术领域

本申请涉及互联网通信技术领域，尤其涉及一种依赖程度的确定方法及装置。

背景技术

微服务架构通过服务实现组件化，将单体应用拆成多个高内聚、低耦合的小服务，提高了开发效率和扩展性，使得大型项目的开发和维护更加容易。随着业务功能增多，业务复杂度提升，微服务的数量增加，微服务间的依赖关系也变得越来越复杂，对于依赖程度(强依赖或者弱依赖)的确定也具有相当难度。

相关技术中，通过下述方式进行依赖程度确定：通过人工查看主应用的原代码逻辑(配置)来获取服务的直接依赖关系，然后通过源代码中的异常/错误处理逻辑来推断强弱依赖程度。然而，依靠人工查看源代码，效率低且成本高。因此，需要提供高效的依赖程度确定方案。

发明内容

为了解决现有技术应用在进行依赖程度确定时，效率低等问题，本申请提供了一种依赖程度的确定方法及装置：

根据本申请的第一方面，提供了一种依赖程度的确定方法，所述方法包括：

获取待处理的依赖关系；其中，所述待处理的依赖关系描述了调用方和被调用方之间的调用关系；

确定所述调用方和所述被调用方所指示的调用链路和服务功能；

利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常；

执行所述服务功能对应的测试用例；

基于所述测试用例的执行结果确定所述待处理的依赖关系的依赖程度。

根据本申请的第二方面，提供了一种依赖程度的确定装置，所述装置包括：

获取模块：用于获取待处理的依赖关系；其中，所述待处理的依赖关系描述了调用方和被调用方之间的调用关系；

确定模块：用于确定所述调用方和所述被调用方所指示的调用链路和服务功能；

故障注入模块：用于利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常；

测试用例执行模块：用于执行所述服务功能对应的测试用例；

依赖程度确定模块：用于基于所述测试用例的执行结果确定所述待处理的依赖关系的依赖程度。

根据本申请的第三方面，提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如第一方面所述的依赖程度的确定方法。

根据本申请的第四方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如第一方面所述的依赖程度的确定方法。

根据本申请的第五方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如第一方面所述的依赖程度的确定方法。

本申请提供的一种依赖程度的确定方法及装置，具有如下技术效果：

本申请通过获取待处理的依赖关系；然后确定调用方和被调用方所指示的调用链路和服务功能；接着利用预设远程过程调用框架的拦截器功能向调用链路进行故障注入，以使得被调用方基于模拟故障出现调用异常；从而执行服务功能对应的测试用例，以基于测试用例的执行结果确定依赖程度。其中，待处理的依赖关系描述了调用方和被调用方之间的调用关系。本申请利用远程过程调用框架的拦截器功能进行故障注入以模拟依赖服务的故障，从而基于相关服务的测试用例的执行结果来确定依赖程度。这样不仅提高了依赖程度的确定效率，还通过对故障影响范围的控制降低了系统风险、保证了系统的稳定性。此外，本申请所针对的依赖关系可以不局限于直接依赖关系，还可以是间接依赖关系，提高了进行依赖程度确定的对象范围。

附图说明

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

图1是本申请实施例提供的一种应用环境的示意图；

图2是本申请实施例提供的一种依赖程度的确定方法的流程示意图；

图3是本申请实施例提供的利用预设远程过程调用框架的拦截器功能向调用链路进行故障注入的一种流程示意图；

图4是本申请实施例提供的全链路遥测系统和拦截器的应用示意图；

图5是本申请实施例提供的进行依赖关系查询的界面示意图；

图6是本申请实施例提供的进行模拟故障的类型信息设置的界面示意图；

图7是本申请实施例提供的进行模拟故障的生效条件设置的界面示意图；

图8也是本申请实施例提供的一种依赖程度的确定方法的流程示意图；

图9是本申请实施例提供的远程过程调用框架的拦截器功能的应用示意图；

图10是本申请实施例提供的一种依赖程度的确定装置的组成框图；

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

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

数据库(DataBase，DB)：它可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

远程字典服务(Remote Dictionary Server，Redis)：一种键值(Key-Value，KV)数据库。

强弱依赖：在微服务系统中，若依赖服务或者中间件(service/DB/Redis/消息队列)发生故障时，不影响系统核心业务流程，那么不影响业务系统可用性的依赖程度称为弱依赖，反之，则称为强依赖。

间接依赖：微服务A直接依赖于微服务B，微服务B直接依赖于微服务C，那么称微服务A间接依赖于微服务C。在本申请实施例中，将分别位于消息队列两端的生产者与消费者间的依赖关系定义为间接依赖。

图数据库：一种非关系型数据库，可以应用图形理论存储实体之间的关系信息。

请参阅图1，图1是本申请实施例提供的一种应用环境的示意图，该应用环境中可以包括客户端10和服务端20，客户端10与服务端20可以通过有线或无线通信方式进行直接或间接地连接。客户端10和服务端20作为一测试平台(或者说强弱依赖分析系统)的构成部分，该测试平可以用于对微服务系统中的依赖关系进行程度确定。用户可以通过客户端10向服务端20发送故障注入请求，服务端20基于该故障注入请求向微服务系统中一依赖关系对应的调用链路进行故障注入以模拟依赖服务的故障，从而基于相关服务的测试用例的执行结果来确定依赖程度。需要说明的是，图1仅仅是一种示例。

客户端可以包括智能手机、台式电脑、平板电脑、笔记本电脑、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、数字助理、智能音箱、智能可穿戴设备等类型的实体设备，也可以包括运行于实体设备中的软体，比如计算机程序。客户端所对应的操作系统可以包括安卓系统(Android系统)、iOS系统(由苹果公司开发的移动操作系统)、linux系统(一种操作系统)、Microsoft Windows系统(微软视窗操作系统)等。

服务端可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。其中服务器可以包括有网络通信单元、处理器和存储器等等。服务端可以为对应的客户端提供后台服务。

在实际应用中，本申请实施例提供的依赖程度的确定方案可以用于微服务系统中全面的强弱依赖关系梳理，从而指导后续的微服务治理工作。

以下介绍本申请一种依赖程度的确定方法的具体实施例，图2是本申请实施例提供的一种依赖程度的确定方法的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，所述方法可以包括：

S201：获取待处理的依赖关系；其中，所述待处理的依赖关系描述了调用方和被调用方之间的调用关系；

在本申请实施例中，服务端获取待处理的依赖关系，该待处理的依赖关系描述了调用方和被调用方之间的调用关系。服务端可以从依赖关系集中获取该待处理的依赖关系，依赖关系集可以本地存储，也可以异地存储。在实际应用中，目标对象(比如用户、模拟器)可以通过客户端向服务端发送故障注入请求，该故障注入请求可以携带指示该待处理的依赖关系的信息，从而服务端基于该故障注入请求获取该待处理的依赖关系。当然，目标对象也可以通过客户端向服务端直接发送获取该待处理的依赖关系的指令。

这里的依赖关系不局限于直接依赖关系，还可以是间接依赖关系。示例性的，依赖关系1描述了调用方1A和被调用方1B之间的调用关系，调用方1A直接依赖于被调用方1B。依赖关系2描述了调用方2C和被调用方2E之间的调用关系，调用方2C间接依赖于被调用方2E。其中，调用方2C直接依赖于2D，2D直接依赖于被调用方2E。需要说明的是，本申请实施例涉及的调用方和被调用方，也不局限于微服务系统中的服务(微服务、应用)，还可以是中间件，比如service(应用服务器)、DB、Redis、消息队列等。

在一示例性的实施方式中，服务端可以从依赖关系拓扑图中获取所述待处理的依赖关系；其中，所述依赖关系拓扑图是利用预设图数据库对追踪数据进行处理得到的，所述追踪数据是利用预设全链路遥测系统对预设业务系统涉及的调用请求进行链路追踪得到的；所述待处理的依赖关系为间接依赖关系或者直接依赖关系。

这里的预设业务系统可以是预设的微服务系统。利用预设全链路遥测系统对预设业务系统涉及的调用请求进行链路追踪得到追踪数据，再利用预设图数据库对追踪数据进行处理得到依赖关系拓扑图。这样利用全链路遥测系统捕获微服务系统中涉及的依赖关系，可以将依赖关系的描述对象从服务扩展至了中间件，可以将依赖关系的类型从直接依赖关系扩展至了间接依赖关系。利用图数据库对于复杂关系的查询和分析能力，可以对追踪数据中基于调用维度建立的依赖关系进行聚合，挖掘出其中涉及多个依赖关系的对象，从而为针对微服务系统的强弱依赖关系梳理提供帮助。同时，图形数据库支持查询和存储，图形数据库可以保存上述依赖关系拓扑图，服务端可以借助图形数据库所支持的查询功能从上述依赖关系拓扑图获取待处理的依赖关系。通过全链路遥测系统和图数据库，不仅能获取直接的服务和中间件依赖，还可以获取间接服务依赖，保证了所得到的依赖关系拓扑图可以提供指示预设业务系统的依赖关系的全面性和准确性，为后续进行依赖程度确定提供了可靠的数据源。

下面将分别介绍利用全链路遥测系统得到追踪数据，以及利用图数据库得到依赖关系拓扑图的过程。

1)“利用全链路遥测系统得到追踪数据”的过程包括下述步骤：利用所述预设全链路遥测系统针对所述预设业务系统的埋点设置获取所述追踪数据；其中，所述针对所述预设业务系统的埋点设置包括以下至少一个：针对所述预设业务系统中服务对象的埋点设置、针对所述预设业务系统中中间件对象的埋点设置。

预设全链路遥测系统可以是一套基于OpenTelemetry(一个可观测性项目，旨在提供可观测性领域的标准化方案)标准规范实现的分布式全链路遥测系统。OpenTelemetry实现了对于Metrics(指标，例如cpu、请求延迟、用户访问数等指标)、Tracing(追踪数据，指示一个请求从接收到处理完成整个生命周期的跟踪路径。其中，该一次请求通常过经过N个系统，也被称为分布式链路追踪)、Logging(日志，可提供精确的系统记录)进行观测的融合。可以理解，利用预设全链路遥测系统可以针对预设业务系统进行相关Metrics、Tracing和Logging捕获。

对于追踪数据的得到，预设全链路遥测系统可以主要关注Tracing的捕获。可以利用预设全链路系统对预设业务系统进行埋点，可以在其中的服务对象处埋点、在中间件对象处埋点。以此得到的追踪数据中以调用维度记录着相关的依赖关系，比如请求1涉及的调用链路(服务1-中间件2-服务3)的依赖关系，请求2涉及的调用链路(服务4-服务5-中间件6-服务7)的依赖关系。可以记录有关中间件的依赖关系，可以记录间接依赖关系。基于全链路遥测系统可以获取服务、存储、消息队列之间的依赖关系，并将它们的追踪数据存储到图数据库中。该针对预设业务系统的埋点设置在架构上可以包括3部分，埋点上报SDK(Software Development Kit，软件开发工具包)、遥测系统Collect(采集)端以及存储端。遥测系统Collect端可以视作预设全链路遥测系统与作为实际生产系统的预设业务系统的对接对象。埋点上报SDK中调用关系的埋点上报部分可以基于RPC框架的拦截器功能实现。内部RPC调用、存储、消息中间件等都可以基于拦截器功能进行自动的埋点上报，每一次调用都可以被遥测系统Collect端采集。

2)“利用图数据库得到依赖关系拓扑图”的过程包括下述步骤：首先，利用所述预设图数据库对所述追踪数据进行实体类型、动作属性分析；其中，所述实体类型用于描述所述调用请求对应的链路上的对象，所述动作属性用于描述所述调用请求涉及的执行动作；然后，利用所述预设图数据库对分析结果进行建模处理，得到所述依赖关系拓扑图。

依赖关系取自前述遥测系统中的追踪数据，这里采用图数据库进行存储和查询。图数据库建模方便，调用过程中的服务、DB、Redis等可以被作为不同的实体类型进行存储，RPC(Remote Procedure Call，远程过程调用)调用、存储、查询等不同的执行动作可以被作为不同的动作属性的。利用图数据库可以基于追踪数据进行依赖关系的层级深度挖掘。图数据库能够进行复杂关系查询和分析，适合长调用链且不同实体类型的查询场景；图数据还支持海量关系存储，总数据量可达亿级以上，且查询效率高。在实际应用中，强弱依赖分析系统基于用户关心的主应用，可以从图数据库中获取主应用全面的依赖关系(包括多层RPC调用，DB，Redis等)。参见图5，可以通过Web页面查看指定服务调用关系拓扑全景图，可以支持直接依赖关系查找和间接依赖关系查找。

S202：确定所述调用方和所述被调用方所指示的调用链路和服务功能；

在本申请实施例中，服务端确定调用方和被调用方所指示的调用链路和服务功能。以上述“调用方1A直接依赖于被调用方1B”以及“调用方2C间接依赖于被调用方2E”为例，1)“调用方1A直接依赖于被调用方1B”，调用链路1为调用方1A-被调用方1B，服务功能可以是调用方1A调用被调用方1B的调用请求的业务功能1，比如“申请虚拟资源”；2)“调用方2C间接依赖于被调用方2E”，调用链路2为调用方2C-2D-被调用方2E，服务功能可以是调用方2C触发的需要调用到被调用方2E的调用请求的业务功能2，比如“查看某进程的状态”。通过确定调用链路为后续注入的故障确定了候选作用范围。通过确定服务功能为后续测执行的试用例确定了候选用例范围。当然，也可以基于调用链路进行路由修改来模拟调用异常。虽然进行路由修改的方式存在操作风险高、故障发生时爆炸半径大的问题，但在对系统稳定性要求不高的场景下，也可以在确定主应用(调用方)的直接依赖应用(被调用方)之后，通过修改路由系统中依赖应用的路由(利用无效路由替代)来模拟失败调用，从而查看主应用核心功能是否正常以确定强弱依赖程度。

S203：利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常；

在本申请实施例中，服务端利用预设远程过程调用框架的拦截器功能向调用链路进行故障注入，以使得被调用方基于模拟故障出现调用异常。结合前述步骤S202中的示例，利用预设远程过程调用框架的拦截器功能向调用链路1进行故障注入，以使得被调用方1B基于模拟故障出现调用异常。利用预设远程过程调用框架的拦截器功能向调用链路2进行故障注入，以使得被调用方2E基于模拟故障出现调用异常。模拟故障的目的是使得待处理的依赖关系对应的被调用方出现调用异常。

基于远程过程调用(Remote Procedure Call，RPC)框架的拦截器功能来实现的故障注入，可以视作应用内故障注入，在为指定应用挂载具有故障注入能力的拦截器后，能够拦截所有请求的发送和接收。

在一示例性的实施方式中，如图3所示，所述利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常，包括：

S301：接收指示所述模拟故障的故障注入请求；其中，所述故障注入请求携带的信息包括以下至少一个：所述模拟故障的类型信息、作用范围和生效条件；

S302：基于所述故障注入请求携带的信息，利用所述预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于所述模拟故障出现调用异常。

客户端向服务端发送指示所述模拟故障的故障注入请求，该故障注入请求携带的信息包括以下至少一个：模拟故障的类型信息、作用范围和生效条件。服务端基于故障注入请求携带的信息，利用预设远程过程调用框架的拦截器功能向调用链路进行故障注入，以使得被调用方基于模拟故障出现调用异常。利用RPC框架的拦截器功能来模拟调用故障，在实现上可以在RPC框架进行插件挂载，由此无需侵入业务代码，具备操作风险小、成本低等特点。指示模拟故障的故障注入请求，提供了客户端触发服务端开启故障注入的机制，提高了用户进行故障注入触发的操作便捷性。

故障注入请求携带的信息则为实现更细粒度、更精准的模拟故障注入提供了保证。下面将分别介绍有关模拟故障的类型信息、作用范围和生效条件的情况：

1)有关“有关模拟故障的类型信息的情况”：

所述接收指示所述模拟故障的故障注入请求，包括：接收针对所述模拟故障的第一类故障注入请求；其中，所述第一类故障注入请求携带有指示超时的类型信息；或者，接收针对所述模拟故障的第二类故障注入请求；其中，所述第二类故障注入请求携带有指示访问不可达的类型信息；或者，接收针对所述模拟故障的第三类故障注入请求；其中，所述第三类故障注入请求携带有指示错误返回的类型信息。

参见图6，用户可以通过故障注入请求指示待注入的模拟故障的类型，比如请求处理超时(服务超时)、请求处理延时(服务延时)、访问不可达(链接不可用)、模拟错误返回等。对于多种故障类型的支持，用户可以根据需要进行选择对应的故障类型，可以更加贴近真实世界的突发异常状况，在实现更细粒度、更精准的模拟故障注入的同时，也细化了进行依赖程度分析的故障维度、提高了进行依赖程度确定的准确性和可靠性。

不同故障类型往往需要不同的高可用策略来应对，这对于进一步的依赖治理具备很多现实意义。以下是多种故障类型实现原理如下：1)超时故障：可以从请求头部获取上游服务(调用方)的超时设置，并睡眠该超时设置指示的时间，以确保上游服务超时；也即拦截回包，主动超时等待超过该超时设置指示的时间，实现超时访问效果；2)链接不可用故障：对于拦截到的请求，模拟服务不可达错误，比如可以直接给上游服务(调用方)返回其自定义异常；3)模拟错误返回故障：将拦截到的请求响应替换为错误响应并返回给上游服务(调用方)；也即拦截回包，设置回包结构中的各种错误返回。

2)有关“有关模拟故障的作用范围的情况”：

在所述接收故障注入请求之前，所述方法还包括：响应于接收到的第一参数设置请求，基于所述第一参数设置请求确定接口维度的故障注入对象；其中，所述故障注入对象位于所述调用链路上；基于所述故障注入对象得到所述模拟故障的作用范围。

如图7所示，用户可以通过第一参数设置请求指示接口维度的故障注入对象，该接口维度的故障注入对象位于调用链路上，以使得通过对调用链路上相关接口的模拟故障注入实现被调用方出现调用异常。限定接口维度的故障注入对象，可以进一步缩小故障的影响范围，实现精准故障注入。基于故障注入对象得到模拟故障的作用范围，模拟故障作用于该故障注入对象。在理想情况下，可以只拦截通过相关接口的探测流量，不给其他的正常流量带来任何有损操作。以“调用方2C间接依赖于被调用方2E”为例，调用链路2为调用方2C-2D-被调用方2E，接口维度的故障注入对象可以在2D处，这样可以使得流量不能经2D到达被调用方2E。接口维度的故障注入对象也可以在被调用方2E处，这样可以使得流量可以正常由不能调用方2C到达2D，但在到达调用方2E过程中出现问题。

示例性的，参见图7，服务名填写了“Aaa.bbb.default”，接口名填写了“Get”，那么所注入的模拟故障只拦截通过Get接口的流量，不会对通过其他接口(比如Search接口)的流量进行拦截。故障命令下发过程中，攻击的对象会基于接口级别进行精准匹配，服务中非匹配接口的流量不会进行任何有损操作。

3)有关“有关模拟故障的生效条件的情况”：

在所述接收故障注入请求之前，所述方法还包括：响应于接收到的第二参数设置请求，基于所述第二参数设置请求确定用于与所述测试用例中的特征信息进行匹配的染色字段；基于所述染色字段得到所述模拟故障的生效条件。

参见图7，用户可以通过第二参数设置请求指示用于与测试用例中的特征信息进行匹配的染色字段，以使得模拟故障在确定测试用例中的特征信息与染色字段相匹配之后生效。染色字段可以有至少一个。测试用例中的特征信息可以来自测试用例所指示的请求所携带的参数。以“调用方1A直接依赖于被调用方1B”为例，服务功能可以是调用方1A调用被调用方1B的调用请求的业务功能1，比如“申请虚拟资源”。该服务功能所对应的测试用例可以由用例a-c，每个用例所指示的请求所携带的参数可以不同，用例a所指示的请求a所携带的参数为业务场景参数甲，用例b所指示的请求b所携带的参数为用户标识丙。那么当染色字段为“用户标识丙”时，那么所注入的模拟故障针对用例b生效，所注入的模拟故障针对用例a不生效。

设置用于匹配的染色字段，可以进一步减少故障对于正常流量的有损操作以及故障的爆炸半径，从而实现精准故障注入。示例性的，用户设置的染色字段可以是用户id：12345，用户名：jack。可以将每个染色字段视作一个tag(标签)，在支持多tag匹配时，只有请求头中的tag与用户设置的tag全部匹配，所注入的模拟故障才生效。故障命令下发过程中，支持自定义字段染色(username，Uid等)，来自测试用例的探测流量头部能够与之相匹配，则所注入的模拟故障生效，这样能够更好的将探测流量和其他正常流量区分开，以避免正常流量的影响。

在一示例性的实施方式中，在所述利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入之前，所述方法还包括：启动用于监听故障注入请求的进程；

相应的，所述利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，包括：首先，响应于所述进程监听到的故障注入请求，基于所述故障注入请求确定对应的拦截器配置信息；然后，基于所述拦截器配置信息，利用所述预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入。

如图4、9所示，基于RPC框架框架的链式拦截器功能，用户可以通过配置手段挂载遥测系统和注入功能的拦截器。RPC框架的拦截器功能支持不同内部语言(比如Java、Golang、C++、Python、Rust)，常默认加上具有应用内故障注入能力的插件以帮助拦截器功能的实现。RPC框架可以在进行依赖程度确定或者故障注入的业务服务启动时额外启动一个进程，该进程用于监听故障注入请求，从而基于故障注入请求确定对应的拦截器配置信息以进行故障注入。在实际应用中，该进程负责监听除了监听用户启动故障注入的请求(比如故障注入请求)，也负责监听用户停止故障注入的请求。可以理解，拦截器的故障注入功能支持启动和关停命令，将注入命令翻译为拦截器的配置，同时也负责整个故障注入的状态管理。这样可以实现用户对于故障注入的有效控制，从而降低对正常服务功能实现的干扰。

S204：执行所述服务功能对应的测试用例；

在本申请实施例中，服务端执行服务功能对应的测试用例。测试用例可以是拨测用例，通过拨测来确定依赖程度。服务端可以从拨测用例集中获取该服务功能对应的测试用例，拨测用例集可以本地存储，也可以异地存储。用例具备等级类型，P0代表核心用例，P1代表一般用例。在实际应用中，参见图8，用户可以按照服务名称和P0用例等级来调用自动化系统进行拨测，同时获取P0核心用例的拨测结果，从而分析出依赖关系的强弱程度。针对每一条依赖关系，我们依次进行应用内故障注入，同时利用自动化系统进行核心用例的拨测，根据拨测的结果以确定这一条依赖关系的强弱程度。

S205：基于所述测试用例的执行结果确定所述待处理的依赖关系的依赖程度。

在本申请实施例中，服务端基于测试用例的执行结果确定待处理的依赖关系的依赖程度。当测试用例的执行结果为成功时，该待处理的依赖关系的依赖程度为弱依赖。当测试用例的执行结果为失败时，该待处理的依赖关系的依赖程度为强依赖。在实际应用中，参见图8，用户可以使用自动化系统进行对应服务核心功能的探测，这里的请求流量可以是现网的流量回放，也可以是服务对应的自动化测试脚本。如果成功率低于100％则为强依赖，否则为弱依赖。针对每一个依赖关系(不论直接依赖关系还是间接依赖关系)，需要分别进行故障注入，然后对主应用进行核心功能探测，分别记录下主应用(调用方)和关联服务(被调用方)间依赖关系的依赖程度。此外，自动化平台支持在rpc/http头部自定义字段进行请求，配合精准故障注入的染色功能，可参考前述步骤S203中的相关记载。

对于整个微服务系统而言，并不是任何一个微服务间的依赖出问题，都会导致整个微服务系统不可用。因此，识别出微服务间的依赖程度对整个微服务系统的治理有着重要作用。对于描述依赖程度的“强弱依赖”，可以参见前述名词、术语解释，不再赘述。可以理解，那些会影响到整个系统不可用(或者体验受损很严重)的依赖为强依赖，那些即使自身出故障也不会导致整个系统不可用(或者体验受损不严重)的依赖为弱依赖。

由以上本申请实施例提供的技术方案可见，本申请实施例中通过获取待处理的依赖关系；然后确定调用方和被调用方所指示的调用链路和服务功能；接着利用预设远程过程调用框架的拦截器功能向调用链路进行故障注入，以使得被调用方基于模拟故障出现调用异常；从而执行服务功能对应的测试用例，以基于测试用例的执行结果确定依赖程度。其中，待处理的依赖关系描述了调用方和被调用方之间的调用关系。本申请利用远程过程调用框架的拦截器功能进行故障注入以模拟依赖服务的故障，从而基于相关服务的测试用例的执行结果来确定依赖程度。这样不仅提高了依赖程度的确定效率，还通过对故障影响范围的控制降低了系统风险、保证了系统的稳定性。此外，本申请所针对的依赖关系可以不局限于直接依赖关系，还可以是间接依赖关系，提高了进行依赖程度确定的对象范围。

本申请实施例还提供了一种依赖程度的确定装置装置，如图10所示，该依赖程度的确定装置1000包括：

获取模块1001：用于获取待处理的依赖关系；其中，所述待处理的依赖关系描述了调用方和被调用方之间的调用关系；

确定模块1002：用于确定所述调用方和所述被调用方所指示的调用链路和服务功能；

故障注入模块1003：用于利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常；

测试用例执行模块1004：用于执行所述服务功能对应的测试用例；

依赖程度确定模块1005：用于基于所述测试用例的执行结果确定所述待处理的依赖关系的依赖程度。

需要说明的，所述装置实施例中的装置与方法实施例基于同样的发明构思。

本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的依赖程度的确定方法。

进一步地，图11示出了一种用于实现本申请实施例所提供的依赖程度的确定方法的电子设备的硬件结构示意图，所述电子设备可以参与构成或包含本申请实施例所提供的依赖程度的确定装置。如图11所示，电子设备110可以包括一个或多个(图中采用1102a、1102b，……，1102n来示出)处理器1102(处理器1102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1104、以及用于通信功能的传输装置1106。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图11所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备110还可包括比图11中所示更多或者更少的组件，或者具有与图11所示不同的配置。

应当注意到的是上述一个或多个处理器1102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到电子设备110(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器1104可用于存储应用软件的软件程序以及模块，如本申请实施例中所述的依赖程度的确定方法对应的程序指令/数据存储装置，处理器1102通过运行存储在存储器114内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种依赖程度的确定方法。存储器1104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1104可进一步包括相对于处理器1102远程设置的存储器，这些远程存储器可以通过网络连接至电子设备110。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置1106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括电子设备110的通信供应商提供的无线网络。在一个实例中，传输装置1106包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实施例中，传输装置1106可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与电子设备110(或移动设备)的用户界面进行交互。

本申请的实施例还提供了一种计算机可读存储介质，所述存储介质可设置于电子设备之中以保存用于实现方法实施例中一种依赖程度的确定方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的依赖程度的确定方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

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

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种依赖程度的确定方法，其特征在于，所述方法包括：

获取待处理的依赖关系；其中，所述待处理的依赖关系描述了调用方和被调用方之间的调用关系；

确定所述调用方和所述被调用方所指示的调用链路和服务功能；

利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常；

执行所述服务功能对应的测试用例；

基于所述测试用例的执行结果确定所述待处理的依赖关系的依赖程度。

2.根据权利要求1所述的方法，其特征在于，所述利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常，包括：

接收指示所述模拟故障的故障注入请求；其中，所述故障注入请求携带的信息包括以下至少一个：所述模拟故障的类型信息、作用范围和生效条件；

基于所述故障注入请求携带的信息，利用所述预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于所述模拟故障出现调用异常。

3.根据权利要求2所述的方法，其特征在于，所述接收指示所述模拟故障的故障注入请求，包括：

接收针对所述模拟故障的第一类故障注入请求；其中，所述第一类故障注入请求携带有指示超时的类型信息；或者，

接收针对所述模拟故障的第二类故障注入请求；其中，所述第二类故障注入请求携带有指示访问不可达的类型信息；或者，

接收针对所述模拟故障的第三类故障注入请求；其中，所述第三类故障注入请求携带有指示错误返回的类型信息。

4.根据权利要求2所述的方法，其特征在于，在所述接收故障注入请求之前，所述方法还包括：

响应于接收到的第一参数设置请求，基于所述第一参数设置请求确定接口维度的故障注入对象；其中，所述故障注入对象位于所述调用链路上；

基于所述故障注入对象得到所述模拟故障的作用范围。

5.根据权利要求2所述的方法，其特征在于，在所述接收故障注入请求之前，所述方法还包括：

响应于接收到的第二参数设置请求，基于所述第二参数设置请求确定用于与所述测试用例中的特征信息进行匹配的染色字段；

基于所述染色字段得到所述模拟故障的生效条件。

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

在所述利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入之前，所述方法还包括：

启动用于监听故障注入请求的进程；

所述利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，包括：

响应于所述进程监听到的故障注入请求，基于所述故障注入请求确定对应的拦截器配置信息；

基于所述拦截器配置信息，利用所述预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入。

7.根据权利要求1所述的方法，其特征在于，所述获取待处理的依赖关系，包括：

从依赖关系拓扑图中获取所述待处理的依赖关系；

其中，所述依赖关系拓扑图是利用预设图数据库对追踪数据进行处理得到的，所述追踪数据是利用预设全链路遥测系统对预设业务系统涉及的调用请求进行链路追踪得到的；所述待处理的依赖关系为间接依赖关系或者直接依赖关系。

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

利用所述预设全链路遥测系统针对所述预设业务系统的埋点设置获取所述追踪数据；

其中，所述针对所述预设业务系统的埋点设置包括以下至少一个：针对所述预设业务系统中服务对象的埋点设置、针对所述预设业务系统中中间件对象的埋点设置。

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

利用所述预设图数据库对所述追踪数据进行实体类型、动作属性分析；其中，所述实体类型用于描述所述调用请求对应的链路上的对象，所述动作属性用于描述所述调用请求涉及的执行动作；

利用所述预设图数据库对分析结果进行建模处理，得到所述依赖关系拓扑图。

10.一种依赖程度的确定装置，其特征在于，所述装置包括：

获取模块：用于获取待处理的依赖关系；其中，所述待处理的依赖关系描述了调用方和被调用方之间的调用关系；

确定模块：用于确定所述调用方和所述被调用方所指示的调用链路和服务功能；

故障注入模块：用于利用预设远程过程调用框架的拦截器功能向所述调用链路进行故障注入，以使得所述被调用方基于模拟故障出现调用异常；

测试用例执行模块：用于执行所述服务功能对应的测试用例；

依赖程度确定模块：用于基于所述测试用例的执行结果确定所述待处理的依赖关系的依赖程度。

Images