CN115203050A - Method and device for determining dependency relationship of services - Google Patents
Method and device for determining dependency relationship of services Download PDFInfo
- Publication number
- CN115203050A CN115203050A CN202210892335.3A CN202210892335A CN115203050A CN 115203050 A CN115203050 A CN 115203050A CN 202210892335 A CN202210892335 A CN 202210892335A CN 115203050 A CN115203050 A CN 115203050A
- Authority
- CN
- China
- Prior art keywords
- dependency relationship
- calling
- service
- class
- determining
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
- G06F8/433—Dependency analysis; Data or control flow analysis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
One or more embodiments of the present specification provide a method for determining inter-service dependency, the method including: responding to a service calling request for calling the class method, and performing distributed link tracking on the service calling request to generate a calling link corresponding to the service calling request; determining the dependency relationship among the class methods based on the calling relationship among the class methods in the calling link; automatically generating a class inter-method calling script corresponding to the class method based on calling data in the calling link; fault code injection is carried out on the class method of the called party, a calling script between the called party and the class method is executed after the fault code injection is finished, and the strength degree of the dependency relationship between the class methods is determined according to the execution result; and determining the dependency relationship between the services corresponding to the class methods based on the strength degree of the dependency relationship between the class methods.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method and an apparatus for determining a dependency relationship of a service, an electronic device, and a machine-readable storage medium.
Background
The single-body architecture application means that all presentation layers, business logic layers and data access layers of business scenes are placed in one project, and can be deployed in an application program on one server after being compiled and packaged. However, with the development of business, business logic becomes more and more complex, and new codes need to be continuously added to original codes, so that the code amount in the project is suddenly increased, the readability and maintainability of the codes are low, and the data maintenance of the application in the later period is not facilitated. Based on this, microservice architecture applications are proposed.
Microservice architecture refers to the splitting of one large single application and service into multiple smaller services, each running in its own independent process. And a program corresponding to one service is completed through mutual calling among a plurality of services. The microservice architecture generally adopts a multilayer structure, and calls a service node program layer by layer to provide services. The microservice architecture can satisfy service level agreements by extending individual components. Each service comprises at least one class method, and the call to the service is actually the call to the class method. Therefore, when a service is extended, it may be practical to extend class methods in the service.
By utilizing the characteristic, when a new service or a new function needs to be expanded in the application of the micro-service architecture, the new service or the new function can be realized only by adding a required function in a specific certain service or adding a certain service, and the architecture of the whole application process cannot be influenced.
Disclosure of Invention
The application provides a method for determining dependency relationship among services, which is applied to a distributed service system adopting a microservice architecture, wherein the distributed service system comprises at least two services, the services comprise at least one class method, and the method comprises the following steps:
responding to a service calling request for calling the class method, and performing distributed link tracking on the service calling request to generate a calling link corresponding to the service calling request; the calling link comprises calling data generated in the process that the class method of the calling party calls the class method of the called party and a calling relation between the class methods;
determining the dependency relationship among the class methods based on the calling relationship among the class methods in the calling link;
automatically generating a class inter-method calling script corresponding to the class method based on calling data in the calling link;
fault code injection is carried out on the class method of the called party, a calling script between the called party and the class method is executed after the fault code injection is finished, and the strength degree of the dependency relationship between the class methods is determined according to the execution result;
and determining the dependency relationship between the services corresponding to the class methods based on the strength degree of the dependency relationship between the class methods.
Optionally, the inter-class method call script includes a test script; the determining the strength degree of the dependency relationship between the class methods according to the execution result includes: determining whether the test script is executed successfully; if the test script is successfully executed, determining that the dependency relationship among the class methods is a weak dependency relationship; if the test script is not successfully executed, the fault code is cleared, and the inter-class method calling script is executed again; and if the test script is successfully executed, determining that the dependency relationship between the class methods is a strong dependency relationship.
Optionally, the fault code comprises a timeout fault code; the determining whether the test script is executed successfully includes: after the test script is executed, determining whether the execution result of the test script is obtained within a preset delay time; if so, determining that the test script is successfully executed; otherwise, determining that the test call script fails to execute.
Optionally, an execution code of the class method of the called party includes the fault code, where an execution state of the fault code defaults to an unexecutable state; the fault code injection of the class method of the called party comprises the step of updating the execution state of the fault code from a non-executable state to an executable state; said clearing said fault code comprising: in response to an instruction to clear the fault code, updating an execution state of the fault code from an executable state to a non-executable state.
Optionally, the class method of the caller is included in the caller service; the called party class method is contained in the called party service; the determining the dependency relationship between the services corresponding to the class methods based on the strength degree of the dependency relationship between the class methods comprises: if the caller service and the callee service are in a direct calling relationship, determining whether the dependency relationship between the class methods respectively contained by the caller service and the callee service contains a strong dependency relationship; if so, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship; otherwise, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship.
Optionally, the method further includes: if the caller service and the callee service are in an indirect calling relationship, determining whether a weak dependency relationship exists between services in a direct calling relationship in a calling link between the caller service and the callee service; if yes, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship; and otherwise, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship.
Optionally, the method further includes: and constructing a dependency relationship graph among the services based on the dependency relationship among the services, and outputting and displaying the dependency relationship graph to a tester.
The present application further provides a device for determining a dependency relationship between services, which is applied to a distributed service system adopting a microservice architecture, where the distributed service system includes at least two services, and the services include at least one class method, and the device includes:
the class method calling link generation module is used for responding to a service calling request for calling the class method, and performing distributed link tracking on the service calling request to generate a calling link corresponding to the service calling request; the calling link comprises calling data generated in the process that the class method of the calling party calls the class method of the called party and a calling relation between the class methods;
the dependency relationship determining module is used for determining the dependency relationship among the class methods based on the calling relationship among the class methods in the calling link;
the inter-class-method calling script generation module is used for automatically generating an inter-class-method calling script corresponding to the class method based on the calling data in the calling link;
the determining module of the strength degree of the dependency relationship among the class methods is used for injecting fault codes into the class methods of the called party, executing the calling scripts among the class methods after the fault codes are injected, and determining the strength degree of the dependency relationship among the class methods according to the execution result;
the determining module of the degree of the strength of the dependency relationship among the services is used for determining the dependency relationship among the services corresponding to the class methods based on the degree of the dependency relationship among the class methods;
and the dependency relationship display module is used for constructing a dependency relationship graph among the services based on the dependency relationship among the services and outputting and displaying the dependency relationship graph to a tester.
The application also provides an electronic device, which comprises a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are mutually connected through the bus;
the memory stores machine-readable instructions, and the processor executes the method by calling the machine-readable instructions.
The present application also provides a machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, implement the above-described method.
The technical scheme has the following technical effects:
in the first aspect, since a calling link composed of at least two class methods can be generated through a distributed link tracing technology, and the dependency relationship between the class methods on the link is determined based on the calling link, the dependency relationship between the class methods can not be analyzed based on calling data generated by mutual calling between the class methods; therefore, the technical scheme of the application not only can improve the efficiency when determining the dependency relationship between the class methods, but also can reduce the difficulty when determining the dependency relationship between the class methods. Moreover, the calling links of the class methods obtained based on distributed link tracking can cover the dependency relationship among the class methods of all the services, so that the problem of omission of the dependency relationship possibly caused when the dependency relationship among the class methods of the services is determined by manually analyzing based on calling data can be avoided, and the accuracy in determining the dependency relationship among the class methods is improved.
In the second aspect, because the inter-class-method call script corresponding to the class method having the dependency relationship may be automatically generated based on the call data included in the call link of the class method, and the fault-related fault code for determining the strength of the dependency relationship may be injected into the class method of the called party, and then the strength of the dependency relationship may be determined according to the execution result of the inter-class-method call script by executing the inter-class-method call script after the fault code injection is completed, not only may the efficiency in determining the strength of the dependency relationship between the class methods be improved, but also the strength of the dependency relationship between the class methods may be determined based on the injected fault code in the call layer of the class method, so that the accuracy in determining the strength of the dependency relationship may be improved.
And in the third aspect, based on the accurate and rapid determination of the strength of the dependency relationship between the class methods, the dependency relationship between the services corresponding to the class methods is further determined, and the strength of the dependency relationship between the services can be determined more simply, accurately and rapidly.
Drawings
FIG. 1 is a flow diagram illustrating a method for determining dependencies of a service in accordance with an illustrative embodiment;
FIG. 1a is a diagram of a relationship example of the dependencies of a service, shown in an exemplary embodiment;
FIG. 1b is a relational example diagram illustrating another service dependency relationship in an exemplary embodiment;
FIG. 1c is a diagram of a relationship example of another service's dependencies, shown in an exemplary embodiment;
FIG. 1d is a diagram of a relationship example of another service's dependencies, shown in an exemplary embodiment;
FIG. 2 is a diagram illustrating an exemplary embodiment of a hardware configuration of an electronic device in which a device for confirming dependency of a service is located;
fig. 3 is a block diagram of an apparatus for validating dependencies of a service in accordance with an illustrative embodiment.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims that follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
The micro-service architecture is used for splitting a large single application program and service into a plurality of small support services, and a service function is realized through mutual cooperation and cooperation among the plurality of services. Because the services can be independently developed, managed and iterated, when a new service function is added, the new service function can be realized by developing the new service and/or constructing a calling relationship between the services corresponding to the new service function on the basis of not influencing the original service function. Compared with a single-body architecture system, the micro-service architecture system can reduce the service complexity and improve the resource utilization rate, and has extremely strong transverse expansion capability; therefore, except for a few more special systems, the design of many current complex service systems has abandoned the monomer architecture and transformed to the design of the micro service architecture, especially in the application of the industrial internet.
When testing and verifying system functions in a distributed system carrying a micro-service framework, particularly, the complex calling relationship and the strength degree of the complex calling relationship among services need to be verified, so that obtaining the calling relationship among the services becomes very important. In the prior art, the calling information among the services is searched and retrieved manually from the source code, and the dependency relationship among the services is determined based on the retrieved calling information. In the process of manual retrieval, because one service may be called by other services, the dependency relationship between the services is complex, and thus the efficiency of sorting the dependency relationship between the services manually is low and the error rate is high. Meanwhile, the degree of the dependency relationship between services is not clear, which may cause uncertainty in the system functional stability and potential functional defects.
Therefore, it becomes very important to accurately and efficiently obtain the calling relationship and the strength of the calling relationship between services.
The service may contain at least one class method; in actual practice, the call to the service may actually be a call to a class method contained in the service. Therefore, the calling relationship and the strength degree thereof between the acquisition services may actually be the calling relationship and the strength degree thereof between class methods included in the acquisition services.
In view of this, the present specification aims to provide a technical solution for accurately and quickly determining the dependency relationship and the strength of the dependency relationship between services in which the dependency relationship exists, without paying attention to the source code of the service.
When the method is implemented, in a distributed service system adopting a micro-service architecture, the distributed service system can comprise at least two services with a calling relationship, the services comprise at least one class method, a service calling request which can enable the class method to carry out calling between the class methods according to a preset calling sequence is triggered, and distributed link tracking can be carried out on the service calling request; in the tracking process, a preset calling sequence among the methods and calling data generated in the process of calling the methods according to the calling sequence can be collected, and the calling data form a calling link of the methods according to the calling sequence, so that the calling relation among the methods can be determined according to the calling sequence in the calling link of the methods, and the dependency relation among the methods can be further determined.
Based on the calling data and the dependency relationship contained in the calling link of the class method, the inter-class method calling script for enabling the class method of the calling party in the class method to call the class method of the called party can be automatically generated; then, a fault code related to a fault for determining the strength of the dependency relationship may be injected into the class method of the called party, and the inter-class-method call script may be executed.
In the above solution, in the first aspect, since a call link composed of at least two class methods may be generated by a distributed link tracing technique, and a dependency relationship between the class methods on the link is determined based on the call link, the dependency relationship between the class methods may no longer be analyzed based on call data generated by mutual call between the class methods; therefore, the technical scheme of the application not only can improve the efficiency when determining the dependency relationship between the class methods, but also can reduce the difficulty when determining the dependency relationship between the class methods. Moreover, the calling links of the class methods obtained based on distributed link tracking can cover the dependency relationship among all the class methods of the service, so that the problem of missing of the dependency relationship possibly caused when the dependency relationship among the class methods of the service is determined by manually analyzing based on calling data can be avoided, and the accuracy in determining the dependency relationship among the class methods is improved.
In the second aspect, because the inter-class-method call script corresponding to the class method having the dependency relationship may be automatically generated based on the call data included in the call link of the class method, and the fault-related fault code for determining the strength of the dependency relationship may be injected into the class method of the called party, and then the strength of the dependency relationship may be determined according to the execution result of the inter-class-method call script by executing the inter-class-method call script after the fault code injection is completed, not only may the efficiency in determining the strength of the dependency relationship between the class methods be improved, but also the strength of the dependency relationship between the class methods may be determined based on the injected fault code in the call layer of the class method, so that the accuracy in determining the strength of the dependency relationship may be improved.
And in the third aspect, based on the accurate and rapid determination of the strength of the dependency relationship between the class methods, the dependency relationship between the services corresponding to the class methods is further determined, and the strength of the dependency relationship between the services can be determined more simply, accurately and rapidly.
The present application is described below by using specific embodiments and in conjunction with specific application scenarios.
Referring to fig. 1, fig. 1 is a flowchart illustrating a method for determining dependency relationships of services according to an exemplary embodiment, where the distributed service system includes at least two services, and the services include at least one class method, the method includes the following steps:
s102, responding to a service calling request for calling the class method, and performing distributed link tracking on the service calling request to generate a calling link corresponding to the service calling request; the calling link comprises calling data generated in the process that the class method of the calling party calls the class method of the called party and a calling relation between the class methods.
The distributed service system refers to a system in which service programs of the system are respectively deployed on different machines (may be deployed on different physical machines or may be deployed on different virtual machines), and the machines and services deployed on the machines are jointly composed. Wherein, the service program can be a small service program with single function and independent process; the plurality of services may be used to collectively form a system service. The service call request may be a request for making a mutual call between class methods of services in the system to implement a certain function in the system, and further, the service call request may be a call request of a class method of a service; the class method may refer to a class method of a service for implementing the certain function, where a call relationship exists between class methods of the service, and a specific class method may include a class method of a caller and a class method of a callee.
It should be noted that there may be multiple sets of calling and called relationships between the class methods, so that the class methods may have at least one class method as a caller and at least one class method as a callee.
For example, in the case of a liquid,
type one, only one call relation exists between class methods of different services
When there is only one set of calling relationships between the class methods, please refer to fig. 1a, where fig. 1a is a diagram illustrating an example of a relationship between dependency relationships of a service according to an exemplary embodiment, where the service a includes a class method 1, the service B includes a class method 1 (hereinafter, referred to as A1 and B1), and a calling order between the class methods of the service is that A1 calls B1, the class methods may include A1 as a calling party class method and B1 as a called party class method;
type two, there are multiple call relations between class methods of different services
When there are multiple sets of call relations among the methods of the service, taking 3 sets of call relations among the methods of the service as an example, please refer to fig. 1b, where fig. 1b is a diagram illustrating a relationship example of a dependency relation of a service according to another exemplary embodiment, where the service C includes class method 1, class method 2, and class method 3, the service D includes class method 1 and class method 2 (hereinafter referred to as C1, C2, C3, D1, and D2), and the call sequence among the class methods is that C1 calls D1, C2 calls D1, and C3 calls D2, then the class methods may include C1, C2, and C3 as the caller class methods and D1 and D2 as the callee class methods.
The distributed link tracing means tracing a call link between class methods of the service in the distributed service system; the tracking of the call link of the class methods may specifically be to obtain a call sequence between the class methods of the service and call data generated in a call process by tracking a service call request in the system. The preset calling sequence refers to a calling sequence for realizing the functions by calling the class methods of the services according to the preset calling sequence, wherein the class methods are set for realizing certain system functions in the development stage of the system. The calling data may be calling data generated in the process that the class method calls between class methods according to the preset calling sequence, and the specific calling data may include a class method as a calling party and a service name of the class method as a called party, a class method name of the class method, and output and input parameters in the class method.
In this step, by using the method of distributed link tracing, the calling sequence and the calling data between the class methods can be directly obtained from the calling link of the class methods, and the dependency relationship between the class methods of the service can be analyzed no longer based on the calling data generated by mutual calling between the class methods of the service; therefore, not only can the efficiency in determining the dependency relationship between the class methods of the services be improved, but also the difficulty in determining the dependency relationship between the class methods of the services can be reduced. Moreover, the calling links of the service class methods obtained based on distributed link tracking can cover the dependency relationship among all the service class methods, so that the problem of omission of the dependency relationship possibly caused when the dependency relationship among the service class methods is determined by manually analyzing based on calling data can be avoided, and the accuracy in determining the dependency relationship among the service class methods is improved.
S104, determining the dependency relationship among the class methods based on the calling relationship among the class methods in the calling link.
In this step, the dependency relationship between at least some of the class methods may be determined according to the call link of the class method obtained in step 102. The dependency relationship may specifically be a calling relationship between at least some of the class methods. And the dependency relationship among the methods can be quickly and accurately determined according to the calling relationship in the calling link.
And S106, automatically generating a class inter-method calling script corresponding to the class method based on the calling data in the calling link.
The above-mentioned automatic generation of the inter-class-method call script corresponding to the class method based on the call data in the call link may be an automatic generation of the inter-class-method call script corresponding to the class method having the dependency relationship based on the call data included in the call link, and the above-mentioned call data may include a service name of a service corresponding to the class method as the calling party and the class method as the called party, a method name of the above-mentioned class method, and an output and input parameter of the above-mentioned class method. The inter-class-method call script may be an execution code for causing the class method to perform inter-class-method call according to the preset call order.
It should be noted that the inter-class method call script may be automatically generated by the system according to the call data, or may be automatically generated by other software according to the call data; the other software may be other tool software, other test software for testing the dependency relationship, and the like, and the generation method of the inter-class-method call script is not limited herein, as long as the call script for causing the class method as the caller to call the class method as the callee can be automatically generated.
And S108, fault code injection is carried out on the class method of the called party, a script is called between the called party and the class method after the fault code injection is finished, and the strength degree of the dependency relationship between the class methods is determined according to the execution result.
The fault code injection for the called party class method may be fault injection for an execution code included in the called party class method; the fault for determining the strength of the dependency relationship may be a fault that causes the class method as the caller not to normally call the class method as the callee.
In this step, a fault code relating to a fault that causes the class method as the caller not to normally call the class method as the callee is injected into the execution code included in the class method as the callee, so that the inter-class-method call script automatically generated in step 106 is executed, and the degree of the dependency relationship between the class method as the caller and the class method as the callee is determined based on the execution result of the inter-class-method call script.
In this step, fault-related fault codes for determining the strength of the dependency relationship are injected into the execution codes included in the class methods as the called parties, and then the script is called among the class methods by executing the class methods after the fault codes are injected, and the strength of the dependency relationship is determined according to the execution result of the script called among the class methods, so that the efficiency in determining the strength of the dependency relationship among the class methods of the service can be improved, and the strength of the dependency relationship among the class methods of the service can be judged on the basis of the injected fault codes in the calling layer of the class methods, thereby improving the accuracy in determining the strength of the dependency relationship.
Optionally, the inter-method call script may be a test script; the determining the strength of the dependency relationship between the class methods according to the execution result may further include:
determining whether the test script is executed successfully;
if the test script is successfully executed, determining that the dependency relationship between the class methods is a weak dependency relationship;
if the test script is not successfully executed, the fault code is cleared, and the inter-class method calling script is executed again; and if the test script is successfully executed, determining that the dependency relationship among the class methods is a strong dependency relationship.
The weak dependency relationship refers to the weak dependency relationship between the class methods, and the influence that the calling program is terminated because the class method as the called party cannot be normally called does not exist; correspondingly, the strong dependency relationship means that the class methods with the strong dependency relationship have an influence that the calling program is terminated because the class method as the called party cannot be normally called; the clearing of the fault code means that the fault code injected in step 108 is removed so that the fault code is not included in the execution code included in the class method to be called into which the fault code is injected.
And after fault codes are injected into the execution codes contained in the class method as the called party, executing the automatically generated test script and determining whether the test script is successfully executed. If the test script is executed, a result of successful execution is returned, specifically, the result of successful execution may be a final correct result of successfully outputting the system function cooperatively implemented by the methods, or a result of "successful execution" is returned. If the script is successfully executed, it may be said that the injected fault that may cause the class method as the called party to be unable to be normally called may be indicated, and for the system function cooperatively implemented by the class method, there is no influence on the program that causes the program to terminate due to the inability to be normally called, and therefore, the dependency relationship is a weak dependency relationship;
if the test script after the fault injection is executed returns the results of 'unsuccessful execution' and the like for indicating unsuccessful execution, the results can be specifically displayed on an interface in a prompt box form without excessive limitation; the test script is unsuccessfully executed or the test script is executed and then a result inconsistent with a normal result is returned, if the script is unsuccessfully executed, the dependency relationship among the methods can be determined not to be a weak dependency relationship;
further, it is necessary to perform fault code clearing on the execution code included in the class method as the called party, and execute the test script after the fault code clearing, and if the test script is successfully called, it is determined that the reason why the execution of the inter-class method call script after the fault is injected is unsuccessful is because: the above-mentioned fault that can make the class method as the called party unable to be called normally has an effect of making the program terminate due to the inability to call normally for the system function cooperatively realized by the class method, and therefore, the above-mentioned dependency relationship is a strong dependency relationship.
Optionally, the injected fault may be an overtime fault, where the overtime fault is that a system injected into the fault cannot obtain a normal response within a certain delay time. The determining whether the test script is successfully executed may be determining whether the execution result of the test script is obtained within a preset delay time after the test script is executed; if yes, determining that the test script is successfully executed; otherwise, determining that the test script fails to be executed.
If the calling script between the class methods is not successfully executed after the fault code is cleared, namely the output result is an error result, the test script can be determined to be an error script. Further, the error script can be marked as an invalid script, discarded, and other test scripts can be selected for testing.
Optionally, in step 108, the called party class method may include the fault code; that is, the execution code included in the class method as the called party may include the fault code that may prevent the class method as the called party from being normally called when the program is designed, and the fault code may be used to determine the strength of the dependency between the class methods; and, the execution state of the above-mentioned trouble code defaults to the unexecutable state.
When a fault code needs to be injected into the execution code included in the class method as the called party, the execution state of the fault code may be updated from the non-executable state to the executable state in response to an instruction for fault code injection with respect to the execution code included in the class method as the called party.
Specifically, the instruction for injecting the fault code into the execution code included in the class method as the called party may be an instruction for injecting the fault code issued by the user in the system, for example, a user option for triggering the fault injection in the system interface by the user, or a user option for triggering the fault injection in the three-way software interface by the user, and the description herein is not specifically explained and limited.
Correspondingly, the performing fault code cleaning on the fault code included in the execution code included in the class method as the called party may include: and in response to an instruction for fault code clearing for the execution code contained in the class method as the called party after fault code injection, updating the execution state of the fault code from the executable state to a non-executable state.
When the fault code contained in the class method as the callee needs to be cleared, the execution state of the fault code may be updated from the executable state to the non-executable state in response to an instruction for performing fault code clearing on the execution code contained in the class method as the callee, and clearing of the fault code may be completed.
The dependency relationship and the strength degree of the method can be determined based on the method.
And S110, determining the dependency relationship between the services corresponding to the class methods based on the strength degree of the dependency relationship between the class methods.
Based on the dependency relationship and the strength degree of the class methods, the strength degree of the dependency relationship between the services corresponding to the class methods can be further determined according to the dependency relationship between the class methods.
Optionally, the method for determining the dependency between services corresponding to the class methods based on the strength of the dependency between the class methods includes: if the caller service and the callee service are in a direct calling relationship, determining whether the dependency relationship between the class methods respectively contained by the caller service and the callee service contains a strong dependency relationship; if yes, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship; otherwise, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship.
The direct calling relationship between the caller service and the callee service means that the caller service can directly call the callee service and can directly call the callee service without other services in the calling process.
If the caller service and the callee service are in a direct calling relationship, determining whether all the dependency relationships between the caller method and the callee method respectively contained by the caller service and the callee service contain strong dependency relationships;
if all the dependency relationships among the class methods can contain strong dependency relationships, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship; otherwise, if all the dependencies between the class methods may include at least one weak dependency, it may be determined that the dependency between the caller service and the callee service is a weak dependency.
For example, a direct call relationship is provided between a first service and a second service, please refer to fig. 1c, fig. 1c is a diagram illustrating an example of a relationship of a dependency relationship of another service according to an exemplary embodiment, where the first service includes a class method 1, a class method 2, and a class method 3, the second service includes a class method 1, a class method 2, and a class method 3, and the class method 1 in the first service directly calls the class method 1 in the second service, the class method 2 in the first service directly calls the class method 2 in the second service, the class method 3 in the first service directly calls the class method 3 in the second service, and the strength of the dependency relationship between the class methods can be determined by using the methods in steps 102 to 108;
(1) In case one, if there is a strong dependency relationship between the class method 1 in the first service and the class method 1 in the second service, there is a weak dependency relationship between the class method 2 in the first service and the class method 2 in the second service, and there is also a weak dependency relationship between the class method 3 in the first service and the class method 3 in the second service, then there is a strong dependency relationship between the first service and the second service.
(2) In the second case, if there are weak dependencies between the class method 1 in the first service and the class method 1 in the second service, between the class method 2 in the first service and the class method 2 in the second service, and between the class method 3 in the first service and the class method 3 in the second service, there is a weak dependency between the first service and the second service.
Optionally, the method further includes: if the caller service and the callee service are in an indirect calling relationship, determining whether a weak dependency relationship exists between services in a calling link between the caller service and the callee service, wherein the services are in a direct calling relationship; if so, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship; and otherwise, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship.
The indirect calling relationship between the caller service and the callee service means that the caller service can call the callee service through other services, and the callee service can be called only through other services in the calling process.
If the caller service and the callee service are in an indirect calling relationship, determining whether a weak dependency relationship exists between services in a direct calling relationship in a calling link between the caller service and the callee service;
if at least one weak dependency exists between services which are in a direct calling relationship in a calling link between the caller service and the callee service, determining that the dependency between the caller service and the callee service is a weak dependency; on the contrary, if the services in the direct calling relationship in the calling link between the caller service and the called service are all strong dependency relationships, the dependency relationship between the caller service and the called service is determined to be a strong dependency relationship.
For example, a first service and a second service are in an indirect call relationship, and a third service also exists, referring to fig. 1d, fig. 1d is a diagram illustrating an example of a relationship of a dependency relationship of another service according to an exemplary embodiment, where the first service includes a class method 4, the second service includes a class method 4, the third service includes a class method 4, the class method 4 in the first service directly calls the class method 4 in the third service, and the class method 4 in the third service directly calls the class method 4 in the second service; by using the methods from step 102 to step 108, the strength of the dependency relationship between the above methods can be determined;
(3) In a third case, if there are strong dependencies between the class method 4 in the first service and the class method 4 in the third service, and between the class method 4 in the third service and the class method 4 in the second service, there is a strong dependency between the first service and the second service;
(4) In case four, if there is a weak dependency relationship between the class method 4 in the first service and the class method 4 in the third service, and there is a weak dependency relationship between the class method 4 in the third service and the class method 4 in the second service, there is a weak dependency relationship between the first service and the second service.
Optionally, the method may further include constructing a dependency graph based on the dependency between the services, and outputting and displaying the dependency graph to a tester.
In particular, the dependency graph can be used for clearly and accurately describing the dependencies among the services in which the dependencies exist. The dependency graph may be a dependency between services corresponding to target functions to be tested, may be a dependency between all services corresponding to a plurality of target functions to be tested, and may be a dependency between services corresponding to all or part of functions of the distributed service system. And, the dependency graph can be output and displayed to a tester. The output display can be performed in the system interface, and the output display can be performed in the test interface of the three-party test software, and the specific display mode and the output mode are not explained and limited too much. By outputting and displaying the dependency relationship graph among the services with the dependency relationship to a tester, the dependency relationship among the services can be more clear. Further, the dependency graph may further include a dependency graph between services and class methods included in the services.
Optionally, the dependency graph may also be a topological graph constructed according to the dependency.
Corresponding to the embodiment of the method for confirming the dependency relationship of the service, the present specification also provides an embodiment of a device for confirming the dependency relationship of the service.
Referring to fig. 2, fig. 2 is a hardware structure diagram of an electronic device where a device for confirming a dependency relationship of a service is located according to an exemplary embodiment. On the hardware level, the device includes a processor 202, an internal bus 204, a network interface 206, a memory 208, and a non-volatile memory 210, although it may include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by processor 202 reading corresponding computer programs from non-volatile storage 210 into memory 208 and then running. Of course, besides the software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combination of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 3, fig. 3 is a block diagram illustrating an apparatus for confirming a dependency relationship of a service according to an exemplary embodiment. The dependency relationship apparatus of the service may be applied to the electronic device shown in fig. 2 to implement the technical solution of the present specification. The device for confirming the dependency relationship of the service is applied to a distributed service system adopting a microservice architecture, the distributed service system comprises at least two services, the service comprises at least one class method, and the device may include:
a class method call link generation module 302, configured to perform distributed link tracking on a service call request for calling the class method in response to the service call request, so as to generate a call link corresponding to the service call request; the calling link comprises calling data generated in the process that the class method of the calling party calls the class method of the called party and a calling relation between the class methods;
a dependency relationship determining module 304, configured to determine a dependency relationship between class methods in the call link based on a call relationship between the class methods;
the inter-class-method script generation module 306 is configured to automatically generate an inter-class-method call script corresponding to the class method based on the call data in the call link;
a module 308 for determining the strength of the dependency relationship between class methods, configured to perform fault code injection on the class method of the called party, execute a call script between class methods after the fault code injection is completed, and determine the strength of the dependency relationship between class methods according to an execution result;
a module 310 for determining the strength of the inter-service dependency relationship, configured to determine the dependency relationship between the services corresponding to the class method based on the strength of the inter-service dependency relationship.
Optionally, the inter-class method call script includes a test script; the strength determining module 308 of the dependency relationship between the class methods is used to determine whether the test script is executed successfully; if the test script is successfully executed, determining that the dependency relationship among the class methods is a weak dependency relationship; if the test script is not successfully executed, the fault code is cleared, and the inter-class method calling script is executed again; and if the test script is successfully executed, determining that the dependency relationship among the class methods is a strong dependency relationship.
Optionally, the fault code comprises a timeout fault code; the strength determining module 308 of the inter-class method dependency relationship is configured to determine whether an execution result of the test script is obtained within a preset delay time after the test script is executed; if so, determining that the test script is successfully executed; otherwise, determining that the test call script fails to execute.
Optionally, an execution code of the called party class method includes the fault code, where an execution state of the fault code defaults to an unexecutable state; the fault code injection of the class method of the called party comprises the step of updating the execution state of the fault code from a non-executable state to an executable state; the module 308 for determining the strength of the inter-class method dependency relationship is used for updating the execution state of the fault code from the executable state to the non-executable state in response to the instruction for clearing the fault code.
Optionally, the class method of the caller is included in the caller service; the called party class method is contained in the called party service; the strength determining module 310 of the inter-service dependency relationship is configured to determine whether a strong dependency relationship is included in the dependency relationships between class methods respectively included in the caller service and the callee service if the caller service and the callee service are in a direct call relationship; if so, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship; otherwise, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship.
Optionally, the module 310 for determining the strength of the inter-service dependency relationship further determines whether a weak dependency relationship exists between services that are in a direct calling relationship in a calling link between the caller service and the callee service if the caller service and the callee service are in an indirect calling relationship; if so, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship; otherwise, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship. For
Optionally, the apparatus further comprises: and the dependency relationship display module 312 is configured to construct a dependency relationship diagram between the services based on the dependency relationship between the services, and output and display the dependency relationship diagram to a tester.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are only illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of other like elements in a process, method, article, or apparatus comprising the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at" \8230; "or" when 8230; \8230; "or" in response to a determination ", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.
Claims (10)
1. A method for determining dependency relationship between services, applied to a distributed service system adopting a microservice architecture, wherein the distributed service system comprises at least two services, and the services comprise at least one class method, the method comprising:
responding to a service calling request for calling the class method, and performing distributed link tracking on the service calling request to generate a calling link corresponding to the service calling request; the calling link comprises calling data generated in the process that the class method of the calling party calls the class method of the called party and a calling relation between the class methods;
determining the dependency relationship among the class methods based on the calling relationship among the class methods in the calling link;
automatically generating a class inter-method calling script corresponding to the class method based on calling data in the calling link;
fault code injection is carried out on the class method of the called party, a calling script between the called party and the class method is executed after the fault code injection is finished, and the strength degree of the dependency relationship between the class methods is determined according to the execution result;
and determining the dependency relationship between the services corresponding to the class methods based on the strength degree of the dependency relationship between the class methods.
2. The method of claim 1, wherein the class inter-method call script comprises a test script;
the determining the strength degree of the dependency relationship between the class methods according to the execution result comprises:
determining whether the test script is executed successfully;
if the test script is successfully executed, determining that the dependency relationship between the class methods is a weak dependency relationship;
if the test script is not successfully executed, the fault code is cleared, and the inter-class method calling script is executed again; and if the test script is successfully executed, determining that the dependency relationship between the class methods is a strong dependency relationship.
3. The method of claim 2, wherein the fault code comprises a timeout fault code;
the determining whether the test script is successfully executed includes:
after the test script is executed, determining whether the execution result of the test script is obtained within a preset delay time; if so, determining that the test script is successfully executed; otherwise, determining that the test call script fails to execute.
4. The method according to claim 2, characterized in that the fault code is contained in the execution code of the class method of the called party, wherein the execution state of the fault code defaults to a non-executable state;
the fault code injection of the class method of the called party comprises the step of updating the execution state of the fault code from a non-executable state to an executable state;
said clearing said fault code comprising: in response to an instruction to clear the fault code, updating an execution state of the fault code from an executable state to a non-executable state.
5. The method of claim 1, wherein the caller's class method is included in a caller service; the class method of the called party is contained in the called party service;
the determining the dependency relationship between the services corresponding to the class methods based on the strength degree of the dependency relationship between the class methods includes:
if the caller service and the callee service are in a direct calling relationship, determining whether the dependency relationship between class methods respectively contained by the caller service and the callee service contains a strong dependency relationship;
if so, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship;
otherwise, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship.
6. The method of claim 5, further comprising:
if the caller service and the callee service are in an indirect calling relationship, determining whether a weak dependency relationship exists between services in a calling link between the caller service and the callee service, wherein the services are in a direct calling relationship;
if yes, determining that the dependency relationship between the caller service and the callee service is a weak dependency relationship;
and otherwise, determining that the dependency relationship between the caller service and the callee service is a strong dependency relationship.
7. The method of claim 1, further comprising:
and constructing a dependency relationship graph among the services based on the dependency relationship among the services, and outputting and displaying the dependency relationship graph to a tester.
8. An apparatus for determining inter-service dependency relationship, applied in a distributed service system adopting a microservice architecture, the distributed service system including at least two services, the services including at least one class method, the apparatus comprising:
the class method calling link generation module is used for responding to a service calling request for calling the class method, and performing distributed link tracking on the service calling request to generate a calling link corresponding to the service calling request; the calling link comprises calling data generated in the process that the class method of the calling party calls the class method of the called party and a calling relation between the class methods;
the dependency relationship determining module is used for determining the dependency relationship among the class methods based on the calling relationship among the class methods in the calling link;
the inter-class-method script generation module is used for automatically generating an inter-class-method calling script corresponding to the class method based on the calling data in the calling link;
the determining module of the strength degree of the dependency relationship among the class methods is used for injecting fault codes into the class methods of the called party, executing the calling scripts among the class methods after the fault codes are injected, and determining the strength degree of the dependency relationship among the class methods according to the execution result;
the determining module of the strength degree of the dependency relationship among the services is used for determining the dependency relationship among the services corresponding to the class methods based on the strength degree of the dependency relationship among the class methods;
and the dependency relationship display module is used for constructing a dependency relationship graph among the services based on the dependency relationship among the services and outputting and displaying the dependency relationship graph to a tester.
9. An electronic device is characterized by comprising a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are connected with each other through the bus;
the memory has stored therein machine-readable instructions, the processor executing the method of any of claims 1 to 7 by calling the machine-readable instructions.
10. A machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, carry out the method of any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210892335.3A CN115203050A (en) | 2022-07-27 | 2022-07-27 | Method and device for determining dependency relationship of services |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210892335.3A CN115203050A (en) | 2022-07-27 | 2022-07-27 | Method and device for determining dependency relationship of services |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115203050A true CN115203050A (en) | 2022-10-18 |
Family
ID=83584613
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210892335.3A Pending CN115203050A (en) | 2022-07-27 | 2022-07-27 | Method and device for determining dependency relationship of services |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115203050A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116107777A (en) * | 2023-04-12 | 2023-05-12 | 霖济智云科技(苏州)有限公司 | Service dependency mining method and service calling method of micro service |
-
2022
- 2022-07-27 CN CN202210892335.3A patent/CN115203050A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116107777A (en) * | 2023-04-12 | 2023-05-12 | 霖济智云科技(苏州)有限公司 | Service dependency mining method and service calling method of micro service |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109598407B (en) | Method and device for executing business process | |
| CN110597730B (en) | Automatic test case generation method and system based on scene method | |
| US20230367701A1 (en) | Code testing method and apparatus | |
| CN110334012B (en) | Risk assessment method and device | |
| CN113704117A (en) | Algorithm testing system, method and device | |
| CN115203050A (en) | Method and device for determining dependency relationship of services | |
| CN109271453B (en) | Method and device for determining database capacity | |
| CN114528054A (en) | Third-party SDK initialization method, device, equipment and medium based on service module | |
| CN111949297A (en) | Block chain intelligent contract upgrading method and device and electronic equipment | |
| CN116610568A (en) | Method, device, equipment and medium for identifying dependency relationship of codes | |
| CN116993519A (en) | Bill generation method and device | |
| Winzinger et al. | Automatic test case generation for serverless applications | |
| CN110471828A (en) | A kind of operating system testing method, apparatus and its equipment | |
| CN111367796B (en) | Application program debugging method and device | |
| CN114691496A (en) | Unit testing method, unit testing device, computing equipment and medium | |
| CN113626333A (en) | Automatic interface testing method and device | |
| CN113656290A (en) | Mock point automatic identification method, device and equipment | |
| CN110750271B (en) | Service aggregation, method and device for executing aggregated service and electronic equipment | |
| CN110297625B (en) | Application processing method and device | |
| CN108712284B (en) | Fault service positioning method and device and service server | |
| CN109656805B (en) | Method and device for generating code link for business analysis and business server | |
| CN111258873B (en) | Test method and device | |
| CN112199399A (en) | Data processing method and device | |
| CN110688430A (en) | Method and device for obtaining data bypass and electronic equipment | |
| EP4346191A1 (en) | Data processing method, and apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |