Method and apparatus for repairing call chain, and device and product

Abstract

Provided are a method and apparatus for repairing a call chain, and a device and a product. The method comprises: acquiring a source code of a first service in a call chain, wherein the call chain further comprises a second service, and the calling relationship between the first service and the second service is unknown (202); acquiring an interface input parameter of the first service (204); on the basis of the source code and the interface input parameter, determining the calling relationship between the first service and the second service (206); and on the basis of the calling relationship, generating a repaired call chain (208).

Description

Methods, apparatus, devices, and products for repairing call chains. Technical Field

[0001] This disclosure relates to the field of software development, and more specifically to methods, apparatus, devices, and products for repairing call chains. Background Technology

[0002] In distributed systems, call tracing is a crucial technology used to track and record the call relationships between various services and components. By passing tracing information between services, call tracing helps development and operations engineers monitor system behavior in real time, analyze request flow and processing, thereby identifying performance bottlenecks, locating problems, and optimizing system performance. Commonly used call tracing technologies include Jaeger and Zipkin. They provide cross-service tracing capabilities to ensure the effective tracking of the lifecycle of each request in complex distributed architectures, thus improving system observability and reliability. Summary of the Invention

[0003] In a first aspect of the embodiments of this disclosure, a method for repairing a call chain is provided. The method includes obtaining the source code of a first service in the call chain, the call chain also including a second service, and the call relationship between the first service and the second service is unknown. The method also includes obtaining interface input parameters of the first service. The method further includes determining the call relationship between the first service and the second service based on the source code and the interface input parameters. Furthermore, the method includes generating a repaired call chain based on the call relationship.

[0004] In a second aspect of the embodiments of this disclosure, an apparatus for repairing a call chain is provided. The apparatus includes a source code acquisition module configured to acquire the source code of a first service in the call chain, the call chain also including a second service, and the call relationship between the first and second services is unknown. The apparatus also includes an input parameter acquisition module configured to acquire interface input parameters of the first service. The apparatus further includes a call relationship determination module configured to determine the call relationship between the first and second services based on the source code and the interface input parameters. Furthermore, the apparatus includes a call chain repair module configured to generate a repaired call chain based on the call relationship.

[0005] In a third aspect of embodiments of this disclosure, an electronic device is provided. The electronic device includes one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement a method for repairing a call chain. The method includes obtaining the source code of a first service in the call chain, the call chain also including a second service, and the call relationship between the first service and the second service is unknown. The method also includes obtaining interface input parameters of the first service. The method further includes determining the call relationship between the first service and the second service based on the source code and the interface input parameters. Furthermore, the method includes generating a repaired call chain based on the call relationship.

[0006] In a fourth aspect of embodiments of this disclosure, a computer program product is provided. The computer program product is tangibly stored on a non-transitory computer-readable medium and includes machine-executable instructions that, when executed, cause a machine to implement a method for repairing a call chain. The method includes obtaining the source code of a first service in the call chain, the call chain also including a second service, and the call relationship between the first and second services is unknown. The method also includes obtaining interface input parameters of the first service. The method further includes determining the call relationship between the first and second services based on the source code and the interface input parameters. Furthermore, the method includes generating a repaired call chain based on the call relationship.

[0007] The summary section is provided to present the chosen concepts in a simplified form, which will be further described in the detailed description below. The summary section is not intended to identify key or principal features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0008] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0009] Figure 1 illustrates a schematic diagram of an example environment in which various embodiments of the present disclosure may be implemented;

[0010] Figure 2 shows a flowchart of a method for repairing a call chain according to some embodiments of the present disclosure;

[0011] Figure 3 shows a schematic diagram of an example system architecture for repairing call chains according to some embodiments of the present disclosure;

[0012] Figures 4A to 4F illustrate schematic diagrams of example processes for repairing call chains according to some embodiments of the present disclosure;

[0013] Figure 5 illustrates a schematic diagram of an example of interaction between a processing device and a client according to some embodiments of the present disclosure;

[0014] Figure 6 shows a block diagram of an apparatus for repairing a call chain according to some embodiments of the present disclosure; and

[0015] Figure 7 shows a block diagram of a device capable of implementing several embodiments of the present disclosure. Detailed Implementation

[0016] It is understood that all user-related data involved in this technical solution should be obtained and used only after authorization from the user. This means that if it is necessary to use a user's personal information in this technical solution, the user's explicit consent and authorization are required before obtaining this data; otherwise, no related data collection and use will be carried out. It should also be understood that when implementing this technical solution, relevant laws and regulations should be strictly followed in the process of data collection, use, and storage, and necessary technical measures should be taken to protect user data security and ensure the secure use of data.

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects unless explicitly stated. Other explicit and implicit definitions may also be included below.

[0019] In modern distributed systems, call chain tracing helps developers and operations engineers gain a comprehensive understanding of system behavior and performance by tracking the flow of requests across various services. Based on call chain tracing, development teams can accurately identify system performance bottlenecks, diagnose potential problems, and even predict system load and stress, allowing for optimization or adjustments before issues occur. Furthermore, systems like Jaeger and Zipkin provide complete tracing capabilities, ensuring accurate path tracking for each request in complex microservice architectures, thereby improving system observability and reliability.

[0020] In practical applications, by integrating multiple tracing call chains from the same business scenario, a complete business call chain can be formed. For example, in business scenarios such as live streaming, social networking, or e-commerce, tracing call chains not only helps engineers track the calls made by each service but also analyzes the dependencies between services. In this way, engineers can more clearly understand the interactions between different services, quickly locate the source of problems, analyze the potential impact of system changes, or optimize business logic. Furthermore, business call chains can support in-depth dependency analysis and fault localization, thereby improving system reliability and user experience.

[0021] However, to achieve a complete call tracing chain, each service in the system needs to correctly integrate the call tracing chain component and properly pass context information in its code. Only by passing tracing data for each request upstream and downstream across multiple services can the completeness of the tracing information for these requests be ensured. If a service fails to correctly pass context information to downstream services, it will cause a break in the call chain, meaning that call information is missing at some point in the tracing chain. This break in the chain may be caused by reasons such as the service not properly integrating the call tracing chain component, lost context, or misconfiguration.

[0022] To fix call chain breaks, engineers were pushed to integrate call chain tracing components into their code and ensure proper transmission of context information. However, this approach requires integrating call chain tracing components into every service, which increases performance overhead. Some performance-critical applications may not be able to afford the performance overhead of adding call chain tracing components. Some related technologies supplement call chain information by statically analyzing call relationships between services. For example, these technologies can automatically infer call chains by analyzing call graphs between services. However, while these technologies achieve a degree of automation, their accuracy is low and they cannot achieve business-level call chain analysis.

[0023] To address this, embodiments of this disclosure propose a scheme for repairing call chains. In this scheme, a processing device can obtain the source code of a first service in the call chain, which also includes a second service, and the call relationship between the first and second services is unknown. Furthermore, the processing device can also obtain the interface input parameters of the first service. Then, the processing device can determine the call relationship between the first and second services based on the source code and the interface input parameters. Finally, the processing device can generate a repaired call chain based on this call relationship.

[0024] In this way, the processing device can perform dynamic and static combined program analysis based on the service's source code and dynamically acquired interface input parameters, thereby improving the accuracy of the repaired call chain. When the value of the interface input parameter is changed, the processing device can repair the call chain for different business scenarios, thus enabling business-level call chain analysis.

[0025] Figure 1 illustrates a schematic diagram of an example environment 100 in which various embodiments of the present disclosure may be implemented. As shown in Figure 1, environment 100 includes a processing device 102. The processing device 102 can be any device with processing or computing capabilities. For example, the processing device 102 can be a cloud server, a local server, a virtual server, a desktop computer, or a laptop computer, etc.

[0026] In environment 100, processing device 102 can acquire a broken call chain 104. Call chain 104 includes business request 106, service 108, service 110, and service 112. Service 108 may integrate a call chain tracing component and pass context information to its downstream service (i.e., service 110). Therefore, in the example shown in environment 100, the call relationship between business request 106, service 108, and service 110 is known; that is, business request 106 calls service 108, and service 108 calls service 110. However, call chain 104 is broken at service 110, and the reason for the break could be, for example, that service 110 does not integrate a call chain tracing component or fails to pass context information to its downstream service. Furthermore, service 112 may also be included in the broken call chain 104. In the example shown in environment 100, service 110 actually calls service 112. However, because service 110 does not integrate a call chain tracing component or does not pass context information to service 112, the system cannot recognize the call relationship between service 110 and service 112. Therefore, the call relationship between service 110 and service 112 is unknown (also known as unrecognized).

[0027] In environment 100, to repair the disconnection at service 110, processing device 102 can obtain the source code 114 of service 110. Source code 114 is the code and logic implementation used to build service 110, and it can be written by developers using programming languages ​​(e.g., C, C++, Java, Python, Go, etc.). Source code 114 can define the functions, data processing logic, etc., of service 110. Furthermore, processing device 102 can also obtain the interface input parameters 116 of service 110. In some embodiments, processing device 102 can capture the interface input parameters 116 through dynamic interception during the operation of service 110. In some embodiments, processing device 102 can obtain the enumerated values ​​of user-configured business parameters as the interface input parameters 116 to simulate the dynamic input parameters of service 110. In some embodiments, the interface input parameters 116 may include business scenario parameters, which can be enumerated values ​​indicating the current business type, such as live streaming, social networking, e-commerce, etc. In some embodiments, the interface input parameter 116 may also include business logic parameters, which may be associated with business logic executed on the data in a specific business scenario, such as data storage method.

[0028] In environment 100, processing device 102 can determine the call relationship between service 110 and service 112 based on the source code 114 of service 110 and dynamically obtained interface input parameters 116. For example, the source code 114 may include multiple data streams corresponding to multiple business scenarios. Processing device 102 can identify the corresponding business scenario by parsing the interface input parameters 116. In addition, the processing device can also identify conditional statements (e.g., "if" statements, "switch" statements, etc.) in the source code 114. Then, processing device 102 can determine the actual flow direction of data at the conditional statement based on the interface input parameters 116. By analyzing the data flow path, processing device 102 can identify that in a specific business scenario, data flows from service 110 to service 112 (i.e., service 110 calls service 112). Therefore, processing device 102 can determine that in this business scenario, there exists a call relationship from service 110 to service 112.

[0029] After determining the call relationship between service 110 and service 112, processing device 102 can supplement this call relationship into call chain 104 to generate a repaired call chain. In environment 100, service 112 can be a node where the call chain is not broken or a node where the call chain is broken. If service 112 is a node where the call chain is broken, processing device 102 can obtain the source code and interface input parameters of service 112 and perform a process similar to the one described above to repair the call chain at service 112.

[0030] It should be understood that although a specific number of services and specific calling relationships between services are shown in environment 100, it is not intended to limit the number of services or the calling relationships between services. In some embodiments, the call chain may have more or fewer services, and there may be various calling relationships between services. For example, in addition to service 110, service 108 may also call other services simultaneously.

[0031] In this way, processing device 102 can perform dynamic and static combined program analysis based on the source code 114 of service 110 and dynamically obtained interface input parameters 116, thereby improving the accuracy of the repaired call chain 104. When the value of interface input parameter 116 is changed, processing device 102 can repair call chain 104 for different business scenarios, thereby enabling business link-level call chain analysis.

[0032] Figure 2 illustrates a flowchart of a method 200 for repairing a call chain according to some embodiments of the present disclosure. Method 200 can be executed by a processing device. For example, method 200 can be executed by processing device 102 in Figure 1. As shown in Figure 2, at block 202, the processing device can obtain the source code of a first service in the call chain, which also includes a second service, and the call relationship between the first and second services is unknown. For example, in environment 100 as shown in Figure 1, although service 110 calls service 112, because service 110 does not integrate a call chain tracing component or does not pass context information to service 112, the system cannot recognize the call relationship between service 110 and service 112, therefore the call relationship between service 110 and service 112 is unknown. In other words, call chain 104 is broken at service 110. To repair the broken chain at service 110, processing device 102 can obtain the source code 114 of service 110.

[0033] In box 204, the processing device can also obtain the interface input parameters of the first service. For example, in environment 100 as shown in FIG. 1, the processing device 102 can also obtain the interface input parameters 116 of service 110. In some embodiments, the processing device 102 can capture the interface input parameters 116 by dynamic interception during the operation of service 110. In some embodiments, the processing device 102 can obtain the enumerated value of the business parameters configured by the user as the interface input parameters 116 to simulate the dynamic input parameters of service 110. In some embodiments, the interface input parameters 116 may include business scenario parameters, which may be enumerated values ​​indicating the current business type. In some embodiments, the interface input parameters 116 may also include business logic parameters, which may be associated with business logic executed on data in a specific business scenario.

[0034] In box 206, the processing device can determine the call relationship between the first service and the second service based on the source code and interface input parameters. For example, in environment 100 as shown in Figure 1, processing device 102 can determine the call relationship between service 110 and service 112 based on the source code 114 of service 110 and dynamically obtained interface input parameters 116. For example, the source code 114 may include multiple data streams corresponding to multiple business scenarios. Processing device 102 can identify the corresponding business scenario by parsing the interface input parameters 116. In addition, the processing device can also identify the conditional statements in the source code 114 and determine the actual flow direction of data at the conditional statement based on the interface input parameters 116. By analyzing the data flow path, processing device 102 can identify that data flows from service 110 to service 112 in a specific business scenario. Therefore, processing device 102 can determine that a call relationship exists from service 110 to service 112 in this business scenario.

[0035] In box 208, the processing device can generate a repaired call chain based on the call relationship. For example, in environment 100 as shown in FIG1, after determining the call relationship between service 110 and service 112, processing device 102 can supplement the call relationship into call chain 104 to generate a repaired call chain.

[0036] In this way, the processing device can perform dynamic and static combined program analysis based on the service's source code and dynamically acquired interface input parameters, thereby improving the accuracy of the repaired call chain. When the value of the interface input parameter is changed, the processing device can repair the call chain for different business scenarios, thus enabling business-level call chain analysis.

[0037] Figure 3 illustrates a schematic diagram of an example 300 of a system architecture for repairing a call chain according to some embodiments of the present disclosure. As shown in Figure 3, example 300 includes a call chain repair system 302. The call chain repair system 302 may include a base layer 304 and a core layer 306. Base layer 304. In example 300, a call chain 308 with a broken chain can be input to the call chain repair system 302. The call chain repair system 302 can determine that a break has occurred at a specific service (also called a target service) in the call chain 308 (e.g., service 110 in Figure 1). The call chain repair system 302 can then obtain the source code of the target service and the interface input parameters 310 of the target service.

[0038] In some embodiments, to obtain the interface input parameter 310 of the target service, the processing device can dynamically intercept the incoming data of the target service during its operation to obtain the interface input parameter 310. This method allows data collection through interceptors, proxy patterns, etc., without directly modifying the business logic code of the target service. This approach enables data collection without affecting normal service operation, reducing interference with existing systems. Furthermore, in complex business scenarios, dynamic interception can collect parameter information more comprehensively, reducing the possibility of missing input parameter values. In addition, this method can improve the authenticity and reliability of the analyzed data.

[0039] In some embodiments, to obtain the interface input parameter 310 of the target service, the processing device can obtain parameters input by the user as the interface input parameter of the first service. The user can be an engineer performing data flow analysis or a maintenance engineer of the target service. In this way, the user can simulate various input scenarios and configure different input parameters according to test requirements, thereby ensuring that the system can cope with various scenarios. This approach also improves the accuracy and controllability of chain break repair when repairing the call chain of interest.

[0040] In Example 300, the base layer 304 of the chain break repair system 302 can provide low-level analysis capabilities. The base layer 304 can generate a static abstract syntax tree and a static call chain based on the source code. The base layer 304 can also perform dynamic parameter collection to obtain dynamic input parameters of the service. The base layer 304 can also parse the collected interface input parameters to determine their meaning (e.g., whether the interface input parameter is a business scenario parameter or a business logic parameter). The base layer 304 can also include a constraint solver, which can solve constraints on data flow nodes with incomplete meanings to determine the complete meaning of the data flow nodes (e.g., solving for the value of a string constant). The base layer 304 can also perform data flow analysis within methods to determine the data flow path within the method.

[0041] In Example 300, the core layer 306 can provide chain break repair capabilities for business links. The core layer 306 can perform data flow analysis between methods or services. The core layer 306 can also perform combined dynamic and static control flow analysis based on static call chains within services and dynamically collected interface input parameters. The core layer 306 can solve constraints on control flow nodes (e.g., corresponding to conditional statements) based on interface input parameters to determine the direction of data flow at the control flow nodes.

[0042] In Example 300, by leveraging the various capabilities provided by the base layer 304 and the core layer 306, the broken chain repair system 302 can repair the broken chain in the call chain 308 based on the static abstract syntax tree of the target service, the static call chain, and the interface input parameters 310 to generate a repaired call chain 312, wherein the repaired call chain 312 can indicate the in-application call chain for a given dynamic interface input parameter.

[0043] In some embodiments, to determine the call relationship between a first service and a second service, the processing device can determine the intra-service call chain of the first service based on the source code and interface input parameters. The intra-service call chain includes the call relationships between multiple methods within a single service. Then, the processing device can determine the call relationship between the first service and the second service based on the intra-service call chain. In some embodiments, the processing device can generate an abstract syntax tree corresponding to the source code. Then, the processing device can generate a static call chain for the first service based on the abstract syntax tree. Then, the processing device can determine the intra-service call chain based on the static call chain and interface input parameters. In some embodiments, the processing device can identify the control flow nodes in the source code. Then, the processing device can determine the intra-service call chain based on the static call chain, the control flow nodes, and the interface input parameters.

[0044] In some embodiments, the interface input parameters include business scenario parameters and business logic parameters. In some embodiments, the control flow node includes a business scenario control flow node associated with the business scenario and a business logic control flow node associated with the business logic. To determine the intra-service call chain, the processing device can solve for the business scenario control flow node using the business scenario parameters to determine a first data flow node in the static call chain, wherein the first data flow node is associated with the business logic control flow node. In some embodiments, the processing device can solve for the business logic control flow node using the business logic parameters to determine a second data flow node in the static call chain. Then, the processing device can determine the intra-service call chain based on the first and second data flow nodes. In some embodiments, the processing device can determine that a second service is called at a target data flow node based on the intra-service call chain. Then, the processing device can determine that a call relationship exists between the first and second services based on determining that the second service is called.

[0045] Figures 4A to 4F illustrate schematic diagrams of example processes for repairing call chains according to some embodiments of the present disclosure. Figure 4A shows a schematic diagram of an example call chain 400 to be repaired. Figure 4B shows a schematic diagram of an example static call chain 410 within a target service. Figure 4C shows a schematic diagram of an example business call chain 420 for a pair of business scenario parameters and business logic parameters. Figure 4D shows a schematic diagram of another example business call chain 430 for another pair of business scenario parameters and business logic parameters. Figure 4E shows a schematic diagram of another example business call chain 440 for another pair of business scenario parameters and business logic parameters. Figure 4F shows a schematic diagram of a repaired example call chain 450.

[0046] As shown in Figure 4A, call chain 400 includes business request 402, service A, service B, service C, service D, and database 404, and call chain 400 can indicate the call relationships between these services. As shown in Figure 4A, in call chain 400, business request 402 calls service A, service A calls service B, and service D calls database 404. However, because service B does not integrate a call chain tracing component or does not pass upstream and downstream information to downstream services, a break occurs at service B. At this time, call chain 400 does not indicate whether service B called service C or service D. Therefore, a processing device (e.g., processing device 102 in Figure 1) can obtain the source code of service B. Example source code for service B is shown below (in pseudocode form for ease of understanding).

[0047] After obtaining the source code of service B, the processing device can generate an abstract syntax tree (AST) corresponding to that source code. An AST is a tree-like data structure used to represent the syntactic structure of the source code. It is an intermediate representation generated by compilers and code analysis tools during the parsing of the source code. In an AST, key elements of the code (e.g., functions, variables, operators, control flow, etc.) can be transformed into hierarchical nodes, each representing a syntactic element. By generating an AST, a clear logical structure of the code can be obtained. Then, the processing device can generate a static call chain (also known as a static full call chain) for service B based on its AST.

[0048] A static call chain is a call path model constructed by analyzing the call relationships between methods in the source code without running the program. Using static analysis techniques, the processing device can identify the code-level dependencies and call paths of multiple methods within service B. Figure 4B illustrates the static call chain 410 within service B.

[0049] As shown in Figure 4B, by analyzing the source code (or abstract syntax tree) of service B, the processing device can determine that in the service entry method, methods A and B are called respectively according to different business types (i.e., business scenario parameters). Method B calls method C, and method C calls the cloud storage service to store data in cloud storage. Furthermore, method D is called in method A. In method D, database (DB) service and remote dictionary service (REDIS) are called respectively according to different storage types (i.e., business logic parameters) to store data in the database or REDIS. After generating the static call chain 410, the processing device can determine the actual business call chain within service B based on the static call chain 410 and the specific values ​​of the interface input parameters (i.e., business type and storage type) of service B. Then, the processing device can determine the call relationship between service B and service C or service D based on the actual business call chain within service B.

[0050] For example, by dynamically acquiring the values ​​of parameters passed to the interface, the processing device can determine that the business type is "e-commerce" and the storage type is "cloud storage". Figure 4C shows an example business call chain 420 for service B in this case. In the source code of service B, the interface parameters passed to the service entry method include the business type and the storage type. By parsing the interface parameters, the processing device can identify that the business type is a business scenario parameter and the storage type is a business logic parameter. The processing device can identify the control flow nodes in the service entry method. The identified control flow nodes may correspond to conditional statements such as "if" or "switch" statements in the source code.

[0051] In the source code of service B, the control flow node in the service entry method can include "if the business type equals 'e-commerce'" and "if the business type equals 'live streaming'". The processing device can solve the constraints of the control flow node based on the values ​​of the interface input parameters. Since the value of the business type is "e-commerce" in the example shown in Figure 4C, the condition "business type equals 'e-commerce'" is satisfied, and data flows into the corresponding data flow node (i.e., method B (storage type)). At this data flow node, the service entry method calls method B and passes the value of the storage type (i.e., "cloud storage") to method B. Method C is called in method B, and the value of the storage type is passed into method C. In method C, service C is called, and the data is stored in cloud storage. Thus, by analyzing the business call chain 420 of service B, the processing device can determine that service B calls service C when the value of the business scenario parameter is "e-commerce" and the value of the business logic parameter is "cloud storage". Therefore, the processing device can repair the call relationship between service B and service C in this business scenario.

[0052] Figure 4D illustrates an example business call chain 430 generated when the value of the business type is "Live Streaming" and the value of the storage type is "Database". In the example shown in Figure 4D, at the control flow node in the service entry method, the processing device can solve the constraints of the control flow node based on the values ​​of the interface input parameters. Since the value of the business type is "Live Streaming", the business type being equal to "Live Streaming" is satisfied, and data flows into the corresponding data flow node (i.e., method A (storage type)). At this data flow node, the service entry method calls method A, passing the value of the storage type (i.e., "Database") to method A. Method D is called in method A, passing the value of the storage type to method D. In method D, service D is called, and then data flows into the control flow node (i.e., if the storage type is equal to "REDIS"). Since the actual value of the storage type is "Database", the processing device can determine that the condition is not satisfied after solving the constraints of this control flow node, so data flows into the corresponding data flow node (i.e., storing the data in the database). At this data flow node, method D calls the database to store the data. Thus, by analyzing the business call chain 430 of service B, the processing device can determine that when the value of the business scenario parameter is "live streaming" and the value of the business logic parameter is "database," service B called service D. Therefore, the processing device can repair the call relationship between service B and service D under this business scenario.

[0053] Figure 4E illustrates an example business call chain 440 generated when the value of the business type is "Live" and the value of the storage type is "REDIS". In the example shown in Figure 4E, at the control flow node in the service entry method, the processing device can solve the constraints of the control flow node based on the values ​​of the interface input parameters. Since the value of the business type is "Live", the business type being equal to "Live" is satisfied, and data flows into the corresponding data flow node (i.e., method A (storage type)). At this data flow node, the service entry method calls method A, passing the value of the storage type (i.e., "REDIS") to method A. Method D is called in method A, passing the value of the storage type to method D. In method D, service D is called, and then data flows into the control flow node (i.e., if the storage type is equal to "REDIS"). Since the actual value of the storage type is "REDIS", the processing device can determine that the condition can be satisfied after solving the constraints of this control flow node, so data flows into the corresponding data flow node (i.e., storing the data in REDIS). At this data flow node, method D calls REDIS to store the data. Thus, by analyzing the business call chain 440 of service B, the processing device can determine that service B called service D when the value of the business scenario parameter was "live broadcast" and the value of the business logic parameter was "REDIS". Therefore, the processing device can repair the call relationship between service B and the service in this business scenario.

[0054] Figure 4F illustrates a schematic diagram of the repaired example call chain 450. In the example shown in Figure 4F, the processing device can repair the call relationship from service B to service C based on the business call chain 420 within service B. Furthermore, the processing device can also repair the call relationships from service B to service D and from service B to database 456 based on the business call chains 430 and 440 within service B.

[0055] In this way, the processing device can generate the actual business call chain within a service under a specified business scenario based on the static call chain. This allows it to repair the call chain between services based on the business call chain within the service, reducing the number of call relationships that do not conform to the business scenario and improving the accuracy of the repaired call chain.

[0056] In some embodiments, the processing device may send data associated with the call chain to the client for display on the client. In some embodiments, the processing device may generate a first node corresponding to a first service and a second node corresponding to a second service. The processing device may also generate edges between the first and second nodes, indicating call relationships. The processing device may then generate a call graph based on the first node, the second node, and the edges, the call graph indicating the repaired call chain. In some embodiments, the call graph corresponds to a specific business scenario. In some embodiments, the processing device may send the call graph to the client for display on the client.

[0057] Figure 5 illustrates a schematic diagram of an example 500 of an interaction between a processing device and a client according to some embodiments of the present disclosure. As shown in Figure 5, example 500 includes a processing device 502 (e.g., processing device 102 in Figure 1) and a client 504. An engineer can send a request 506 to the processing device 502 to repair a call chain via the client 504. Request 506 may include a broken call chain 508 and source code 510 (or the storage address of source code 510). Where the engineer can determine the service where the chain broke, source code 510 may include only the source code of the service where the chain broke. The processing device 502 can then generate a repaired call chain 512 based on call chain 508 and source code 510. The processing device 502 can then send the repaired call chain 512 to the client 504 for display on the client 504's display.

[0058] Processing device 502 can generate a corresponding call graph based on the repaired call chain 512. The call graph can include multiple nodes and multiple edges connecting the nodes, where the nodes represent multiple services and each edge indicates the call relationship between two services. In this way, the call graph can indicate the repaired call relationships. Furthermore, the call graph can also identify business scenarios corresponding to the interface input parameters dynamically collected during the repair process. In this way, engineers can view the call graph on the monitor of client 504, improving the efficiency of program analysis.

[0059] Figure 6 shows a block diagram of an apparatus 600 for repairing a call chain according to some embodiments of the present disclosure. The apparatus 600 includes a source code acquisition module 602 configured to acquire the source code of a first service in a call chain, the call chain also including a second service, and the call relationship between the first and second services is unknown. The apparatus 600 also includes an input parameter acquisition module 604 configured to acquire interface input parameters of the first service. The apparatus 600 further includes a call relationship determination module 606 configured to determine the call relationship between the first and second services based on the source code and the interface input parameters. Furthermore, the apparatus 600 includes a call chain repair module 608 configured to generate a repaired call chain based on the call relationship.

[0060] In some embodiments, the input parameter acquisition module 604 includes a parameter interception module, configured to acquire interface input parameters by dynamically intercepting the input data of the first service during the operation of the first service.

[0061] In some embodiments, the input parameter acquisition module 604 includes a user input acquisition module configured to acquire parameters input by the user as interface input parameters for the first service.

[0062] In some embodiments, the call chain is an inter-service call chain, and the call relationship determination module 606 includes: an intra-service call chain determination module, configured to determine the intra-service call chain of a first service based on source code and interface input parameters, the intra-service call chain including the call relationship between multiple methods within a single service; and an intra-service call chain usage module, configured to determine the call relationship between the first service and the second service based on the intra-service call chain.

[0063] In some embodiments, the in-service call chain determination module includes: an abstract syntax tree generation module configured to generate an abstract syntax tree corresponding to the source code based on the source code; a static call chain generation module configured to generate a static call chain for the first service based on the abstract syntax tree; and a static call chain usage module configured to determine the in-service call chain based on the static call chain and the interface input parameters.

[0064] In some embodiments, the in-service call chain determination module includes: a control flow node determination module configured to determine control flow nodes in the source code; and a control flow node usage module configured to determine the in-service call chain based on the static call chain, control flow nodes, and interface input parameters.

[0065] In some embodiments, the interface input parameters include business scenario parameters and business logic parameters.

[0066] In some embodiments, the control flow node includes a business scenario control flow node associated with a business scenario and a business logic control flow node associated with business logic. The control flow node usage module includes: a first data flow node determination module configured to determine a first data flow node in the static call chain by solving the business scenario control flow node using business scenario parameters, wherein the first data flow node is associated with the business logic control flow node; and a first data flow node usage module configured to determine an intra-service call chain based on the first data flow node, the business logic control flow node, and business logic parameters, wherein the intra-service call chain is associated with the business scenario.

[0067] In some embodiments, the first data flow node using module includes: a second data flow node determining module, configured to determine a second data flow node in a static call chain by solving a business logic control flow node using business logic parameters; and a second data flow node using module, configured to determine an intra-service call chain based on the first data flow node and the second data flow node.

[0068] In some embodiments, the in-service call chain usage module includes: a second service determination module configured to determine, based on the in-service call chain, that a second service is invoked at a target data stream node; and a second service usage module configured to determine, based on the determination that the second service is invoked, that a call relationship exists between the first service and the second service.

[0069] In some embodiments, the apparatus 600 further includes: a node generation module configured to generate a first node corresponding to a first service and a second node corresponding to a second service; an edge generation module configured to generate an edge between the first node and the second node, the edge indicating a call relationship; and a call graph generation module configured to generate a call graph based on the first node, the second node, and the edge, the call graph indicating a repaired call relationship.

[0070] In some embodiments, the call graph corresponds to a specific business scenario.

[0071] In some embodiments, the apparatus 600 further includes a call graph sending module configured to send a call graph to a client for displaying the call graph at the client.

[0072] It is understood that, by utilizing the apparatus 600 of this disclosure, at least one of the many advantages achievable by the methods or processes described above can be realized. For example, apparatus 600 can perform dynamic and static combined program analysis based on the service's source code and dynamically acquired interface input parameters, thereby improving the accuracy of the repaired call chain. When the value of the interface input parameters is changed, apparatus 600 can repair the call chain for different business scenarios, thereby enabling business-link level call chain analysis.

[0073] Figure 7 shows a block diagram of a device 700 capable of implementing various embodiments of the present disclosure. Device 700 may, for example, be a processing device 102 as shown in Figure 1. As shown in Figure 7, device 700 includes a central processing unit (CPU) and / or a graphics processing unit (GPU) 701, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 702 or loaded from storage unit 708 into random access memory (RAM) 703. Various programs and data required for the operation of device 700 may also be stored in RAM 703. The CPU / GPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704. Although not shown in Figure 7, device 700 may also include a coprocessor.

[0074] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0075] The various methods or processes described above can be executed by CPU / GPU 701. For example, in some embodiments, the methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by CPU / GPU 701, one or more steps or actions in the methods or processes described above can be performed.

[0076] In some embodiments, the methods and processes described above can be implemented as a computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of this disclosure.

[0077] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0078] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, fiber optic cables, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0079] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and conventional procedural programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0080] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0081] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0082] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0083] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for repairing a call chain, comprising: Obtain the source code of the first service in the call chain, the call chain also includes a second service, and the call relationship between the first service and the second service is unknown; Obtain the interface input parameters of the first service; The calling relationship between the first service and the second service is determined based on the source code and the interface input parameters; as well as The repaired call chain is generated based on the call relationship.

2. The method according to claim 1, wherein obtaining the interface input parameters of the first service includes: During the operation of the first service, the incoming data of the first service is dynamically intercepted to obtain the interface input parameters.

3. The method according to claim 1, wherein obtaining the interface input parameters of the first service includes: The parameters input by the user are obtained as the interface input parameters of the first service.

4. The method according to claim 1, wherein the call chain is an inter-service call chain, and determining the call relationship between the first service and the second service based on the source code and the interface input parameters includes: The service call chain of the first service is determined based on the source code and the interface input parameters. The service call chain includes the call relationship between multiple methods within a single service. as well as The call relationship between the first service and the second service is determined based on the in-service call chain.

5. The method of claim 4, wherein determining the intra-service call chain of the first service based on the source code comprises: Generate an abstract syntax tree corresponding to the source code based on the source code; The static call chain of the first service is generated based on the abstract syntax tree; as well as The in-service call chain is determined based on the static call chain and the interface input parameters.

6. The method according to claim 5, wherein determining the intra-service call chain based on the static call chain and the interface input parameters comprises: Identify the control flow nodes in the source code; as well as The in-service call chain is determined based on the static call chain, the control flow node, and the interface input parameters.

7. The method according to claim 6, wherein the interface input parameters include business scenario parameters and business logic parameters.

8. The method according to claim 7, wherein the control flow node includes a business scenario control flow node associated with the business scenario and a business logic control flow node associated with the business logic, and determining the in-service call chain based on the static call chain, the control flow node, and the interface input parameters includes: The first data flow node in the static call chain is determined by solving the business scenario control flow node using the business scenario parameters, wherein the first data flow node is associated with the business logic control flow node. as well as The service call chain is determined based on the first data flow node, the business logic control flow node, and the business logic parameters, wherein the service call chain is associated with the business scenario.

9. The method according to claim 8, wherein determining the in-service call chain based on the first data flow node, the business logic control flow node, and the business logic parameters comprises: The second data flow node in the static call chain is determined by solving the business logic control flow node using the business logic parameters. as well as The in-service call chain is determined based on the first data flow node and the second data flow node.

10. The method of claim 4, wherein determining the call relationship between the first service and the second service based on the intra-service call chain comprises: Based on the in-service call chain, it is determined that the second service is invoked at the target data stream node; as well as The existence of the calling relationship between the first service and the second service is determined based on the fact that the second service is called.

11. The method according to claim 1, further comprising: Generate a first node corresponding to the first service and a second node corresponding to the second service; Generate an edge between the first node and the second node, the edge indicating the calling relationship; as well as A call graph is generated based on the first node, the second node, and the edges, the call graph indicating the repaired call relationships.

12. The method according to claim 11, wherein the call graph corresponds to a specific business scenario.

13. The method of claim 12, further comprising: The call graph is sent to the client for display at the client.

14. An apparatus for repairing a call chain, comprising: The source code acquisition module is configured to acquire the source code of the first service in the call chain, the call chain also includes a second service, and the call relationship between the first service and the second service is unknown; The input parameter acquisition module is configured to acquire the interface input parameters of the first service; The call relationship determination module is configured to determine the call relationship between the first service and the second service based on the source code and the interface input parameters; as well as The call chain repair module is configured to generate a repaired call chain based on the call relationship.

15. An electronic device comprising: processor; as well as A memory coupled to the processor, the memory having instructions stored therein, which, when executed by the processor, cause the electronic device to perform the method according to any one of claims 1 to 13.

16. A computer program product tangibly stored on a non-transitory computer-readable medium and comprising machine-executable instructions that, when executed, cause a machine to perform the method according to any one of claims 1 to 13.

Images