Method and apparatus for determining dependency degree

Abstract

The application discloses a dependency degree determination method and device. The method comprises the following steps: obtaining a to-be-processed dependency relationship; wherein the to-be-processed dependency relationship describes a calling relationship between a calling party and a called party; determining a calling link and a service function indicated by the calling party and the called party; injecting a fault into the calling link by using an interceptor function of a preset remote procedure call framework, so that the called party appears a calling exception based on a simulated fault; executing a test case corresponding to the service function; and determining a dependency degree of the to-be-processed dependency relationship based on an execution result of the test case. The application simulates a fault of a dependent service by injecting a fault into the calling link by using the interceptor function of the remote procedure call framework, so that the dependency degree is determined based on the execution result of the test case of the related service. In this way, the determination efficiency of the dependency degree is improved, the system risk is reduced by controlling the fault influence range, and the stability of the system is ensured.

Description

Technical Field

[0001] This application relates to the field of Internet communication technology, and in particular to a method and apparatus for determining the degree of dependence. Background Technology

[0002] Microservice architecture achieves componentization through services, breaking down monolithic applications into multiple highly cohesive, loosely coupled small services. This improves development efficiency and scalability, making the development and maintenance of large projects easier. As business functions increase, business complexity rises, and the number of microservices increases, the dependencies between microservices also become increasingly complex, making it quite difficult to determine the degree of dependency (strong or weak dependency).

[0003] In related technologies, dependency levels are determined by manually examining the source code logic (configuration) of the main application to obtain direct service dependencies, and then inferring the strength of dependencies based on exception / error handling logic in the source code. However, relying on manual source code review is inefficient and costly. Therefore, an efficient dependency level determination scheme is needed. Summary of the Invention

[0004] To address the inefficiency of existing technologies in determining dependency levels, this application provides a method and apparatus for determining dependency levels:

[0005] According to a first aspect of this application, a method for determining the degree of dependence is provided, the method comprising:

[0006] Obtain the dependencies to be processed; wherein, the dependencies to be processed describe the calling relationship between the caller and the callee;

[0007] Determine the call chain and service functions indicated by the caller and the callee;

[0008] The interceptor function of the preset remote procedure call framework is used to inject faults into the call chain, so that the callee will experience a call exception based on the simulated fault.

[0009] Execute the test cases corresponding to the service function;

[0010] The degree of dependency of the dependency to be processed is determined based on the execution results of the test cases.

[0011] According to a second aspect of this application, a dependency determination apparatus is provided, the apparatus comprising:

[0012] Acquisition module: used to acquire dependencies to be processed; wherein, the dependencies to be processed describe the calling relationship between the caller and the callee;

[0013] Determining module: used to determine the call chain and service function indicated by the caller and the callee;

[0014] Fault injection module: used to inject faults into the call chain using the interceptor function of the preset remote procedure call framework, so that the callee will experience a call exception based on the simulated fault;

[0015] Test case execution module: Used to execute the test cases corresponding to the service functions;

[0016] Dependency Determination Module: Used to determine the dependency degree of the dependency relationship to be processed based on the execution results of the test cases.

[0017] According to a third aspect of this application, an electronic device is provided, the electronic device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the dependency determination method as described in the first aspect.

[0018] According to a fourth aspect of this application, a computer-readable storage medium is provided, the storage medium storing at least one instruction or at least one program segment, the at least one instruction or the at least one program segment being loaded and executed by a processor to implement the dependency determination method as described in the first aspect.

[0019] According to a fifth aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the dependency determination method as described in the first aspect.

[0020] The method and apparatus for determining the degree of dependence provided in this application have the following technical effects:

[0021] This application obtains the dependencies to be processed; then determines the call chain and service functions indicated by the caller and callee; next, it uses the interceptor function of a pre-defined remote procedure call framework to inject faults into the call chain, causing the callee to experience call anomalies based on simulated faults; thereby executing test cases corresponding to the service functions, and determining the degree of dependency based on the execution results of the test cases. The dependencies to be processed describe the call relationship between the caller and callee. This application uses the interceptor function of the remote procedure call framework to inject faults to simulate faults in dependent services, thereby determining the degree of dependency based on the execution results of the test cases for related services. This not only improves the efficiency of determining the degree of dependency, but also reduces system risk and ensures system stability by controlling the scope of fault impact. Furthermore, the dependencies addressed in this application are not limited to direct dependencies, but can also include indirect dependencies, expanding the scope of objects for determining the degree of dependency. Attached Figure Description

[0022] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application;

[0024] Figure 2 This is a flowchart illustrating a method for determining the degree of dependency provided in an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of a process for injecting faults into the call chain using the interceptor function of a preset remote procedure call framework, as provided in an embodiment of this application.

[0026] Figure 4 This is an application diagram of the end-to-end telemetry system and interceptor provided in the embodiments of this application;

[0027] Figure 5 This is a schematic diagram of the interface for performing dependency queries provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the interface for setting the type information of simulated faults provided in an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of the interface for setting the effective conditions of a simulated fault, provided in an embodiment of this application.

[0030] Figure 8 This is also a flowchart illustrating a method for determining the degree of dependency provided in an embodiment of this application;

[0031] Figure 9 This is a schematic diagram illustrating the application of the interceptor function of the remote procedure call framework provided in this application embodiment;

[0032] Figure 10 This is a block diagram of a dependency determination device provided in an embodiment of this application;

[0033] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0035] It should be noted that the terms "comprising" and "having" and any variations thereof in the specification, claims and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such processes, methods, products or devices.

[0036] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0037] A database (DB) can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, capable of being shared by multiple users, with minimal redundancy, and independent of application programs.

[0038] Remote Dictionary Server (Redis): A key-value (KV) database.

[0039] Strong and weak dependencies: In a microservice system, if the failure of a dependent service or middleware (service / DB / Redis / message queue) does not affect the core business process of the system, then the degree of dependency that does not affect the availability of the business system is called a weak dependency, and vice versa.

[0040] Indirect dependency: If microservice A directly depends on microservice B, and microservice B directly depends on microservice C, then microservice A is said to indirectly depend on microservice C. In this embodiment, the dependency relationship between the producer and consumer located at opposite ends of the message queue is defined as indirect dependency.

[0041] Graph database: A type of non-relational database that uses graph theory to store information about relationships between entities.

[0042] Please see Figure 1 , Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application. This application environment may include a client 10 and a server 20, which can be directly or indirectly connected via wired or wireless communication. The client 10 and server 20 are components of a testing platform (or a strong / weak dependency analysis system), which can be used to determine the degree of dependency in a microservice system. Users can send a fault injection request to the server 20 through the client 10. The server 20, based on the fault injection request, injects a fault into the call chain corresponding to a dependency in the microservice system to simulate a fault in the dependent service, thereby determining the degree of dependency based on the execution results of the test cases for the relevant services. It should be noted that... Figure 1 This is just one example.

[0043] Clients can include physical devices such as smartphones, desktop computers, tablets, laptops, augmented reality (AR) / virtual reality (VR) devices, digital assistants, smart speakers, and smart wearable devices. They can also include software running on these physical devices, such as computer programs. The operating systems that support the client can include Android, iOS (a mobile operating system developed by Apple), Linux, and Microsoft Windows.

[0044] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The server may include network communication units, processors, and memory, etc. The server can provide backend services to the corresponding clients.

[0045] In practical applications, the dependency determination scheme provided in this application can be used to comprehensively analyze strong and weak dependencies in a microservice system, thereby guiding subsequent microservice governance work.

[0046] The following describes a specific embodiment of a method for determining the degree of dependency according to this application. Figure 2 This is a flowchart illustrating a method for determining dependency level according to an embodiment of this application. This application provides the operational steps described in the embodiments or flowchart, but based on conventional or non-inventive methods, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 2 As shown, the method may include:

[0047] S201: Obtain the dependencies to be processed; wherein, the dependencies to be processed describe the calling relationship between the caller and the callee;

[0048] In this embodiment, the server obtains pending dependencies, which describe the calling relationship between the caller and the callee. The server can obtain these pending dependencies from a dependency set, which can be stored locally or remotely. In practical applications, the target object (e.g., a user or simulator) can send a fault injection request to the server via a client. This fault injection request can carry information indicating the pending dependency, allowing the server to obtain it based on the request. Alternatively, the target object can also directly send an instruction to the server via a client to obtain the pending dependency.

[0049] The dependencies here are not limited to direct dependencies; indirect dependencies are also possible. For example, dependency 1 describes the call relationship between caller 1A and callee 1B, where caller 1A directly depends on callee 1B. Dependency 2 describes the call relationship between caller 2C and callee 2E, where caller 2C indirectly depends on callee 2E. Specifically, caller 2C directly depends on 2D, and 2D directly depends on callee 2E. It should be noted that the caller and callee involved in this embodiment are not limited to services (microservices, applications) in a microservice system; they can also be middleware, such as application servers, databases, Redis, message queues, etc.

[0050] In one exemplary implementation, the server can obtain the dependencies to be processed from the dependency topology graph; wherein, the dependency topology graph is obtained by processing the tracking data using a preset graph database, and the tracking data is obtained by tracing the call requests involved in the preset business system using a preset full-link telemetry system; the dependencies to be processed are indirect dependencies or direct dependencies.

[0051] The preset business system here can be a preset microservice system. A preset end-to-end telemetry system is used to trace the call requests involved in the preset business system, obtaining tracing data. Then, a preset graph database is used to process the tracing data to obtain a dependency topology graph. By using the end-to-end telemetry system to capture the dependencies involved in the microservice system, the description objects of the dependencies can be extended from services to middleware, and the types of dependencies can be extended from direct dependencies to indirect dependencies. Utilizing the graph database's query and analysis capabilities for complex relationships, the dependencies established based on the call dimension in the tracing data can be aggregated, revealing objects involving multiple dependencies, thus aiding in the identification of strong and weak dependencies in the microservice system. Simultaneously, the graph database supports querying and storage; it can store the aforementioned dependency topology graph, and the server can use the query functions supported by the graph database to retrieve the dependencies to be processed from the dependency topology graph. Through the end-to-end telemetry system and the graph database, not only direct service and middleware dependencies can be obtained, but also indirect service dependencies. This ensures that the obtained dependency topology graph provides comprehensiveness and accuracy in indicating the dependencies of the preset business system, providing a reliable data source for subsequent determination of dependency levels.

[0052] The following sections will describe the processes of obtaining tracking data using a full-link telemetry system and obtaining a dependency topology graph using a graph database.

[0053] 1) The process of “obtaining tracking data using a full-link telemetry system” includes the following steps: using the preset full-link telemetry system to obtain the tracking data by setting the tracking points for the preset business system; wherein, the tracking point settings for the preset business system include at least one of the following: tracking point settings for service objects in the preset business system, and tracking point settings for middleware objects in the preset business system.

[0054] A pre-defined end-to-end telemetry system can be a distributed end-to-end telemetry system implemented based on the OpenTelemetry standard (an observability project aimed at providing standardized solutions in the observability domain). OpenTelemetry integrates observations of metrics (such as CPU usage, request latency, and user access counts), tracing (tracing data indicating the entire lifecycle of a request from receipt to processing completion; this typically involves a single request passing through N systems, also known as distributed tracing), and logging (providing accurate system records). In essence, a pre-defined end-to-end telemetry system can be used to capture relevant metrics, tracing, and logging for a pre-defined business system.

[0055] For obtaining tracing data, the pre-defined end-to-end telemetry system can primarily focus on capturing tracing data. The pre-defined end-to-end system can be used to embed tracking points in the pre-defined business system, specifically at service objects and middleware objects. The resulting tracing data records related dependencies along the call dimension, such as the dependency relationship of the call chain involved in request 1 (service 1-middleware 2-service 3), and the dependency relationship of the call chain involved in request 2 (service 4-service 5-middleware 6-service 7). Dependencies related to middleware and indirect dependencies can also be recorded. Based on the end-to-end telemetry system, the dependencies between services, storage, and message queues can be obtained, and their tracing data can be stored in a graph database. The tracking settings for the pre-defined business system can be architecturally comprised of three parts: a tracking reporting SDK (Software Development Kit), a telemetry system Collect (collection) end, and a storage end. The telemetry system Collect end can be considered the interface between the pre-defined end-to-end telemetry system and the pre-defined business system, which is the actual production system. The event tracking and reporting part of the SDK can be implemented based on the interceptor function of the RPC framework. Internal RPC calls, storage, message middleware, etc. can all be automatically tracked and reported based on the interceptor function, and each call can be collected by the telemetry system's Collect terminal.

[0056] 2) The process of “obtaining a dependency topology graph using a graph database” includes the following steps: First, the tracking data is analyzed for entity type and action attribute using the preset graph database; wherein, the entity type is used to describe the objects on the link corresponding to the call request, and the action attribute is used to describe the execution actions involved in the call request; then, the analysis results are modeled using the preset graph database to obtain the dependency topology graph.

[0057] Dependencies are derived from tracking data in the aforementioned telemetry system, and a graph database is used for storage and retrieval. Graph databases are convenient for modeling; services, databases, Redis, etc., during the call process can be stored as different entity types, and different execution actions such as RPC (Remote Procedure Call) calls, storage, and queries can be treated as different action attributes. Graph databases allow for in-depth hierarchical mining of dependencies based on tracking data. Graph databases can perform complex relationship queries and analysis, suitable for query scenarios with long call chains and different entity types; graph databases also support massive relationship storage, with total data volumes reaching hundreds of millions or more, and offer high query efficiency. In practical applications, the strong and weak dependency analysis system, based on the main application of interest to the user, can obtain comprehensive dependencies of the main application (including multi-level RPC calls, databases, Redis, etc.) from the graph database. See also Figure 5 You can view a panoramic view of the topology of the call relationships of a specified service through a web page, which supports finding both direct and indirect dependencies.

[0058] S202: Determine the call chain and service function indicated by the caller and the callee;

[0059] In this embodiment, the server determines the call chain and service function indicated by the caller and callee. Taking the above examples of "caller 1A directly depends on callee 1B" and "caller 2C indirectly depends on callee 2E", 1) "caller 1A directly depends on callee 1B", call chain 1 is caller 1A-callee 1B, and the service function can be the business function 1 of the caller 1A calling the callee 1B, such as "requesting virtual resources"; 2) "caller 2C indirectly depends on callee 2E", call chain 2 is caller 2C-2D-callee 2E, and the service function can be the business function 2 of the call request triggered by caller 2C that needs to call the callee 2E, such as "viewing the status of a process". By determining the call chain as a subsequent injected fault, the candidate scope of action is determined. By determining the service function as a subsequent test case, the candidate test case scope is determined. Of course, route modifications can also be made based on the call chain to simulate call anomalies. Although modifying routes carries high operational risks and a large blast radius in the event of a failure, in scenarios where system stability requirements are not high, it can be used to simulate a failed call by modifying the routes of dependent applications in the routing system (using invalid routes as substitutes) after identifying the direct dependent applications (callees) of the main application (caller). This allows us to check whether the core functions of the main application are working properly and determine the degree of strong or weak dependencies.

[0060] S203: Utilize the interceptor function of the preset remote procedure call framework to inject faults into the call chain, so that the callee experiences a call exception based on a simulated fault;

[0061] In this embodiment, the server uses the interceptor function of a preset remote procedure call framework to inject faults into the call chain, causing the callee to experience a call exception based on a simulated fault. Referring to the example in step S202 above, the server uses the interceptor function of the preset remote procedure call framework to inject faults into call chain 1, causing callee 1B to experience a call exception based on a simulated fault. The server also uses the interceptor function of the preset remote procedure call framework to inject faults into call chain 2, causing callee 2E to experience a call exception based on a simulated fault. The purpose of simulating faults is to cause the callee corresponding to the pending dependency to experience a call exception.

[0062] Fault injection implemented using the interceptor function of the Remote Procedure Call (RPC) framework can be regarded as in-application fault injection. After attaching an interceptor with fault injection capability to a specified application, it can intercept the sending and receiving of all requests.

[0063] In one exemplary implementation, such as Figure 3As shown, the step of injecting faults into the call chain using the interceptor function of a preset remote procedure call framework, so that the callee experiences a call exception based on a simulated fault, includes:

[0064] S301: Receive a fault injection request indicating the simulated fault; wherein the fault injection request carries information including at least one of the following: the type information, scope of action, and activation conditions of the simulated fault;

[0065] S302: Based on the information carried in the fault injection request, the interceptor function of the preset remote procedure call framework is used to inject faults into the call chain, so that the callee will experience a call exception based on the simulated fault.

[0066] The client sends a fault injection request to the server, indicating the simulated fault. This request carries at least one of the following information: the type of simulated fault, its scope, and the conditions for its activation. Based on the information in the fault injection request, the server uses the interceptor function of a pre-defined remote procedure call (RPC) framework to inject faults into the call chain, causing the callee to experience call anomalies due to the simulated fault. Utilizing the interceptor function of the RPC framework to simulate call faults allows for plugin mounting within the RPC framework, thus avoiding intrusion into business logic code and offering advantages such as low operational risk and low cost. The fault injection request indicating the simulated fault provides a mechanism for the client to trigger the server to initiate fault injection, improving the ease of operation for users.

[0067] The information carried in the fault injection request ensures more granular and precise simulated fault injection. The following sections will describe the types, scope, and effective conditions of the simulated faults:

[0068] 1) Regarding "Information on the type of simulated fault":

[0069] The step of receiving a fault injection request indicating the simulated fault includes: receiving a first type of fault injection request for the simulated fault, wherein the first type of fault injection request carries type information indicating a timeout; or, receiving a second type of fault injection request for the simulated fault, wherein the second type of fault injection request carries type information indicating unreachable access; or, receiving a third type of fault injection request for the simulated fault, wherein the third type of fault injection request carries type information indicating an error return.

[0070] See Figure 6Users can specify the type of simulated fault to be injected via fault injection requests, such as request processing timeout (service timeout), request processing delay (service delay), access unreachable (connection unavailable), simulated error return, etc. Supporting multiple fault types allows users to select the appropriate fault type as needed, more closely mimicking real-world unexpected situations. This enables more granular and accurate simulated fault injection, while also refining the fault dimensions for dependency analysis and improving the accuracy and reliability of dependency determination.

[0071] Different types of failures often require different high-availability strategies, which has significant practical implications for further dependency management. The implementation principles for various failure types are as follows: 1) Timeout failure: The timeout setting of the upstream service (caller) can be obtained from the request header, and the system can sleep for the time indicated by that timeout setting to ensure the upstream service times out; that is, intercepting the response and actively waiting for the timeout to exceed the time indicated by the timeout setting to achieve the effect of timeout access; 2) Connection unavailable failure: For intercepted requests, a service unreachable error is simulated, for example, a custom exception can be returned directly to the upstream service (caller); 3) Simulated error return failure: The intercepted request response is replaced with an error response and returned to the upstream service (caller); that is, intercepting the response and setting various error returns in the response structure.

[0072] 2) Regarding "the scope of the simulated fault":

[0073] Before receiving the fault injection request, the method further includes: in response to the received first parameter setting request, determining a fault injection object at the interface level based on the first parameter setting request; wherein the fault injection object is located on the call chain; and obtaining the scope of the simulated fault based on the fault injection object.

[0074] like Figure 7As shown, users can set the first parameter to indicate the fault injection object at the interface level. This fault injection object is located on the call chain, allowing the callee to experience call anomalies by simulating fault injection into relevant interfaces on the call chain. Limiting the fault injection object to the interface level can further narrow the scope of the fault's impact, achieving precise fault injection. The scope of the simulated fault is obtained based on the fault injection object, and the simulated fault acts on that fault injection object. Ideally, only probe traffic through relevant interfaces can be intercepted, without causing any loss of operation to other normal traffic. Taking "caller 2C indirectly depends on callee 2E" as an example, call chain 2 is caller 2C-2D-callee 2E. The fault injection object at the interface level can be at 2D, preventing traffic from reaching callee 2E via 2D. The fault injection object at the interface level can also be at callee 2E, allowing traffic to reach 2D normally from caller 2C, but encountering problems during the journey to caller 2E.

[0075] For example, see Figure 7 If the service name is "Aaa.bbb.default" and the interface name is "Get", then the injected simulated fault will only intercept traffic through the Get interface and will not intercept traffic through other interfaces (such as the Search interface). During the fault command issuance process, the attack target will be precisely matched based on the interface level, and traffic from non-matching interfaces in the service will not undergo any lossy operations.

[0076] 3) Regarding "the effective conditions for simulated faults":

[0077] Before receiving the fault injection request, the method further includes: in response to the received second parameter setting request, determining a coloring field for matching with feature information in the test case based on the second parameter setting request; and obtaining the activation condition of the simulated fault based on the coloring field.

[0078] See Figure 7Users can set a coloring field in the request indication via a second parameter to match the feature information in the test case. This ensures that the simulated fault takes effect after the feature information in the test case matches the coloring field. There can be at least one coloring field. The feature information in the test case can come from the parameters carried in the request indicated by the test case. For example, in the case of "Caller 1A directly depends on Callee 1B," the service function can be business function 1, such as "requesting virtual resources," which is the call request from Caller 1A to Callee 1B. The test case corresponding to this service function can be test case ac. The parameters carried in the request indicated by each test case can be different. For example, the parameter carried in request a of test case a is business scenario parameter A, and the parameter carried in request b of test case b is user identifier C. Therefore, when the coloring field is "user identifier C," the injected simulated fault takes effect for test case b, but not for test case a.

[0079] Setting coloring fields for matching can further reduce the detrimental effects of faults on normal traffic and the blast radius of faults, thereby achieving precise fault injection. For example, user-defined coloring fields could be user id: 12345, username: jack. Each coloring field can be considered a tag. When multiple tag matching is supported, the injected simulated fault only takes effect if all tags in the request header match the user-defined tags. During the fault command issuance process, custom field coloring (username, Uid, etc.) is supported. If the probe traffic header from the test case matches these colors, the injected simulated fault takes effect. This better distinguishes probe traffic from other normal traffic, avoiding the influence of normal traffic.

[0080] In one exemplary embodiment, before injecting faults into the call chain using the interceptor function of a preset remote procedure call framework, the method further includes: starting a process for listening for fault injection requests;

[0081] Accordingly, the step of injecting faults into the call chain using the interceptor function of the preset remote procedure call framework includes: first, in response to a fault injection request listened to by the process, determining the corresponding interceptor configuration information based on the fault injection request; and then, based on the interceptor configuration information, injecting faults into the call chain using the interceptor function of the preset remote procedure call framework.

[0082] like Figure 4 , 9As shown, based on the chained interceptor functionality of the RPC framework, users can configure interceptors for telemetry systems and injection functions. The RPC framework's interceptor functionality supports different internal languages ​​(such as Java, Golang, C++, Python, and Rust), and often includes a plugin with in-application fault injection capabilities by default to facilitate interceptor implementation. The RPC framework can start an additional process when starting a business service for dependency determination or fault injection. This process listens for fault injection requests and determines the corresponding interceptor configuration information based on these requests to perform fault injection. In practical applications, this process listens for both user requests to start and stop fault injection. Essentially, the interceptor's fault injection function supports start and stop commands, translating injection commands into interceptor configurations and managing the overall fault injection state. This allows users to effectively control fault injection, reducing interference with normal service functionality.

[0083] S204: Execute the test cases corresponding to the service function;

[0084] In this embodiment, the server executes test cases corresponding to the service function. Test cases can be probing test cases, used to determine the degree of dependency. The server can obtain test cases corresponding to the service function from a probing test case set, which can be stored locally or remotely. Test cases have hierarchical types, with P0 representing core test cases and P1 representing general test cases. See [link to relevant documentation] for practical applications. Figure 8 Users can invoke the automated system to perform probing by service name and P0 use case level, and simultaneously obtain the probing results of P0 core use cases, thereby analyzing the strength of dependencies. For each dependency, we sequentially perform in-application fault injection, and simultaneously use the automated system to probing the core use cases, determining the strength of the dependency based on the probing results.

[0085] S205: Determine the degree of dependency of the dependency to be processed based on the execution results of the test cases.

[0086] In this embodiment, the server determines the dependency level of the pending dependency based on the execution result of the test case. When the test case executes successfully, the pending dependency is considered a weak dependency. When the test case executes unsuccessfully, the pending dependency is considered a strong dependency. See [link to relevant documentation] for practical applications. Figure 8Users can use the automated system to probe the core functions of corresponding services. The request traffic can be replays of live network traffic or automated test scripts for the service. A success rate below 100% indicates a strong dependency; otherwise, a weak dependency. For each dependency (whether direct or indirect), fault injection needs to be performed separately, followed by core function probes on the main application. The degree of dependency between the main application (caller) and related services (callees) is recorded. Furthermore, the automated platform supports custom fields in RPC / HTTP headers for requests, combined with precise fault injection coloring functionality; refer to the relevant description in step S203 above.

[0087] For a microservice system as a whole, a problem with a dependency between any one microservice does not necessarily render the entire system unavailable. Therefore, identifying the degree of dependency between microservices is crucial for the governance of the entire microservice system. For the terms "strong dependency" and "weak dependency," please refer to the aforementioned explanation of terms and concepts, which will not be repeated here. It can be understood that dependencies that would render the entire system unavailable (or severely impair the user experience) are strong dependencies, while dependencies that, even if they themselves fail, will not cause the entire system to become unavailable (or severely impair the user experience) are weak dependencies.

[0088] As can be seen from the technical solutions provided in the above embodiments of this application, this application obtains the dependencies to be processed; then determines the call chain and service functions indicated by the caller and the callee; next, it uses the interceptor function of a preset remote procedure call framework to inject faults into the call chain, so that the callee experiences call anomalies based on simulated faults; thereby executing test cases corresponding to the service functions, and determining the degree of dependency based on the execution results of the test cases. Here, the dependencies to be processed describe the call relationship between the caller and the callee. This application uses the interceptor function of the remote procedure call framework to inject faults to simulate faults in dependent services, thereby determining the degree of dependency based on the execution results of the test cases for related services. This not only improves the efficiency of determining the degree of dependency, but also reduces system risk and ensures system stability by controlling the scope of fault impact. Furthermore, the dependencies targeted by this application are not limited to direct dependencies, but can also be indirect dependencies, increasing the scope of objects for determining the degree of dependency.

[0089] This application also provides a device for determining the degree of dependence, such as... Figure 10 As shown, the device 1000 for determining the degree of dependence includes:

[0090] Acquisition module 1001: used to acquire dependencies to be processed; wherein, the dependencies to be processed describe the calling relationship between the caller and the callee;

[0091] Determining module 1002: used to determine the call chain and service function indicated by the caller and the callee;

[0092] Fault injection module 1003: used to inject faults into the call chain using the interceptor function of a preset remote procedure call framework, so that the callee will experience a call exception based on a simulated fault;

[0093] Test case execution module 1004: used to execute test cases corresponding to the service function;

[0094] Dependency Determination Module 1005: Used to determine the dependency degree of the dependency relationship to be processed based on the execution result of the test case.

[0095] It should be noted that the apparatus and method embodiments described in the device embodiments are based on the same inventive concept.

[0096] This application provides an electronic device including a processor and a memory. The memory stores at least one instruction or at least one program segment, which is loaded and executed by the processor to implement the dependency determination method provided in the above method embodiments.

[0097] Furthermore, Figure 11 A schematic diagram of the hardware structure of an electronic device for implementing the dependency determination method provided in the embodiments of this application is shown. The electronic device may participate in or include the dependency determination apparatus provided in the embodiments of this application. Figure 11 As shown, the electronic device 110 may include one or more processors 1102 (shown as 1102a, 1102b, ..., 1102n in the figure) (processor 1102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 1104 for storing data, and a transmission device 1106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 11 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device 110 may also include... Figure 11 The more or fewer components shown, or having the same Figure 11 The different configurations shown.

[0098] It should be noted that the aforementioned one or more processors 1102 and / or other data processing circuitry are generally referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be wholly or partially integrated into any other element within the electronic device 110 (or mobile device). As involved in the embodiments of this application, the data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0099] The memory 1104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the dependency determination method described in the embodiments of this application. The processor 1102 executes various functional applications and data processing by running the software programs and modules stored in the memory 114, thereby implementing the aforementioned dependency determination method. The memory 1104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1104 may further include memory remotely located relative to the processor 1102, and these remote memories can be connected to the electronic device 110 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0100] The transmission device 1106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 110. In one example, the transmission device 1106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In one embodiment, the transmission device 1106 may be a radio frequency (RF) module for wireless communication with the Internet.

[0101] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of the electronic device 110 (or mobile device).

[0102] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a dependency determination method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the dependency determination method provided in the above method embodiments.

[0103] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0104] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0105] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and electronic device embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0106] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0107] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining the degree of dependence, characterized in that, The method includes: Obtain the dependencies to be processed in the preset business system from the dependency topology graph; the dependencies to be processed describe the calling relationship between the caller and the callee, wherein the caller is a service or middleware, and the callee is a service or middleware; the dependency topology graph is obtained by processing the tracing data using the preset graph database; the tracing data is obtained by performing link tracing on the call requests involved in the preset business system using the preset full-link telemetry system. Determine the call chain and service function indicated by the caller and the callee; the service function is the business function requested by the callee and invoked by the caller. Based on the information carried in the fault injection request, the interceptor function of the preset remote procedure call framework is used to inject faults into the fault injection object at the interface level by attaching an interceptor with fault injection capability, so as to intercept the traffic passing through the interface corresponding to the fault injection object; the fault injection object is located on the call chain, and the interceptor with fault injection capability is used to intercept the sending and receiving of requests. The information carried in the fault injection request includes the type information and scope of the simulated fault. The type information indicates timeout, access unreachable, or error return, and the scope of the fault is obtained based on the fault injection object. Execute the test cases corresponding to the service function; The degree of dependency of the dependencies to be processed is determined based on the execution results of the test cases; The method further includes: acquiring the tracking data by using the preset full-link telemetry system to set up tracking points for the preset business system; the tracking point settings for the preset business system include at least one of the following: tracking point settings for services in the preset business system, and tracking point settings for middleware in the preset business system. The method further includes: using the preset graph database to analyze the tracking data for entity type and action attributes; the entity type is used to describe the object on the link corresponding to the call request, and the action attribute is used to describe the execution action involved in the call request; The analysis results are modeled using the preset graph database to obtain the dependency topology graph.

2. The method according to claim 1, characterized in that, Before injecting faults into the interface-level fault injection object by attaching an interceptor with fault injection capability through the interceptor function of the preset remote procedure call framework based on the information carried in the fault injection request, the method further includes: Receive a fault injection request indicating the simulated fault; the fault injection request also carries information including effective conditions.

3. The method according to claim 2, characterized in that, Before receiving the fault injection request indicating the simulated fault, the method further includes: In response to the received first parameter setting request, the fault injection object is determined based on the first parameter setting request.

4. The method according to claim 2, characterized in that, Before receiving the fault injection request indicating the simulated fault, the method further includes: In response to the received second parameter setting request, a coloring field for matching with the feature information in the test case is determined based on the second parameter setting request; The effective conditions are obtained based on the coloring field.

5. The method according to claim 1, characterized in that, The method further includes: A process for listening to fault injection requests is started; the fault injection requests listened to by the process are used to determine the corresponding interceptor configuration information.

6. The method according to claim 1, characterized in that, The dependencies to be processed are either indirect or direct dependencies.

7. A device for determining the degree of dependence, characterized in that, The device includes: Acquisition Module: Used to acquire pending dependencies in a preset business system from a dependency topology graph; the pending dependencies describe the call relationship between the caller and the callee, wherein the caller is a service or middleware, and the callee is a service or middleware; the dependency topology graph is obtained by processing tracing data using a preset graph database; the tracing data is obtained by tracing the call requests involved in the preset business system using a preset full-link telemetry system. Determining module: used to determine the call chain and service function indicated by the caller and the callee; the service function is the business function requested by the caller and the callee. Fault Injection Module: Based on the information carried in the fault injection request, this module utilizes the interceptor function of a pre-defined remote procedure call framework to inject faults into a fault injection object at the interface level by attaching an interceptor with fault injection capabilities. This intercepts traffic passing through the interface corresponding to the fault injection object. The fault injection object is located on the call chain, and the interceptor with fault injection capabilities is used to intercept the sending and receiving of requests. The information carried in the fault injection request includes the type information and scope of the simulated fault. The type information indicates timeout, unreachable access, or error return, and the scope is obtained based on the fault injection object. Test case execution module: Used to execute the test cases corresponding to the service functions; Dependency Determination Module: Used to determine the dependency degree of the dependency relationship to be processed based on the execution results of the test cases; The device is further configured to: acquire the tracking data by using the preset full-link telemetry system to set up the tracking points for the preset business system; the tracking point settings for the preset business system include at least one of the following: tracking point settings for services in the preset business system, and tracking point settings for middleware in the preset business system. The device is further configured to: perform entity type and action attribute analysis on the tracking data using the preset graph database; the entity type is used to describe the object on the link corresponding to the call request, and the action attribute is used to describe the execution action involved in the call request; and use the preset graph database to model the analysis results to obtain the dependency topology graph.

8. The apparatus according to claim 7, characterized in that, The fault injection module is also used for: Receive a fault injection request indicating the simulated fault; the fault injection request also carries information including effective conditions.

9. The apparatus according to claim 8, characterized in that, The device is also used for: Before receiving the fault injection request indicating the simulated fault, in response to the received first parameter setting request, the fault injection target is determined based on the first parameter setting request.

10. The apparatus according to claim 8, characterized in that, The device is also used for: Before receiving the fault injection request indicating the simulated fault, in response to the received second parameter setting request, a coloring field for matching with feature information in the test case is determined based on the second parameter setting request; The effective conditions are obtained based on the coloring field.

11. The apparatus according to claim 7, characterized in that, The device is also used for: A process for listening to fault injection requests is started; the fault injection requests listened to by the process are used to determine the corresponding interceptor configuration information.

12. The apparatus according to claim 7, characterized in that, The dependencies to be processed are either indirect or direct dependencies.

13. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the method for determining the degree of dependency as described in any one of claims 1-6.

14. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the method for determining the degree of dependency as described in any one of claims 1-6.

15. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, wherein a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the dependency determination method as described in any one of claims 1-6.

Images