Information extraction method and apparatus, and computing device cluster

By constructing an abstract syntax tree and utilizing a large language model to analyze calls and provide information, the accuracy and cost issues of obtaining service cluster dependencies in cloud computing are solved, enabling efficient dependency identification during the release phase.

CN121918980APending Publication Date: 2026-04-24SHENZHEN HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411498477.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-24
Publication Date
2026-04-24

AI Technical Summary

Technical Problem

In the field of cloud computing, existing technologies struggle to accurately obtain dependencies in complex service clusters, especially during the deployment phase. Static analysis cannot comprehend the business logic of the code, resulting in high costs and inaccuracies in dependency acquisition.

Method used

By employing information extraction methods, we acquire the code files of the service cluster, construct an abstract syntax tree (AST), and utilize graph structures and large language models (LLM) to analyze call and provision information, generate call chains and provision chains, identify dependencies, reduce the cost of dependency acquisition, and improve accuracy.

Benefits of technology

It enables accurate acquisition of service cluster dependencies without requiring a runtime environment, reducing costs and improving the accuracy of dependency acquisition, making it suitable for complex cloud service clusters.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121918980A_ABST
    Figure CN121918980A_ABST
Patent Text Reader

Abstract

The information extraction method comprises the steps that a plurality of code files are obtained, and the code files are codes of cloud services in a code bin of a service cluster in a release stage; obtaining calling information and providing information according to the plurality of code files; storing the calling information and the providing information in a graph to obtain a graph structure; traversing the graph structure to obtain a plurality of call chains and a plurality of provision chains; and obtaining a dependency relationship of the plurality of code files according to the plurality of call chains and the plurality of provision chains. According to the method, a plurality of call chains and a plurality of provision chains are obtained from a graph structure, and the dependency relationship is obtained according to the call chains and the provision chains. Compared with the prior art that a static analysis technology is adopted to obtain the dependency relationship, the method does not need to depend on the completeness of the detection case and a running state environment constructed at high cost, the cost of obtaining the dependency relationship is reduced, and the application scene is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to an information extraction method, apparatus, and computing device cluster. Background Technology

[0002] In the field of cloud computing, users can combine resources from various cloud services into a service cluster of a complex software stack product to execute related business operations. Service clusters can be Huawei Cloud Stack (HCS) or Huawei Cloud Stack Online (HCSO), among others. Service clusters typically feature a large number of cloud services that rely on mutual calls (dependencies) to provide services. For example, HCS may contain over 100 cloud services, with dependency chains forming more than 5 nodes and nearly 20 dependency methods (such as representational state transfer (REST), application programming interfaces (APIs), software development kits (SDKs), remote procedure calls (RPCs), publish-subscribe patterns, scripts, and domain-specific languages ​​(DSLs)). Therefore, the dependency relationships within a service cluster are quite complex. Since the dependencies in a service cluster are related to service development progress, product upgrades and evolution, and fault delimitation and localization, it is essential to accurately obtain the dependencies in the service cluster. Summary of the Invention

[0003] To address the aforementioned problems, embodiments of this application provide an information extraction method that can reduce the cost of acquiring dependencies and expand application scenarios. Furthermore, this application also provides an information extraction device and a computing device cluster corresponding to this information extraction method.

[0004] Therefore, the following technical solutions are adopted in the embodiments of this application:

[0005] In a first aspect, this application provides an information extraction method, comprising: acquiring multiple code files, wherein the code files are cloud service code in the code repository of a service cluster during the release phase; obtaining call information and provision information based on the multiple code files; wherein the call information includes inter-function calls and dependency calls in the multiple code files, and the provision calls include at least one of class definitions, function definitions, variable definitions, and representational state transition REST application programming interface (API) definitions in the multiple code files; storing the call information and the provision information in a graph to obtain a graph structure; traversing the graph structure to obtain multiple call chains and multiple provision chains; obtaining the dependency relationships of the multiple code files based on the multiple call chains and the multiple provision chains; wherein the dependency relationships of the multiple code files indicate the relationship between the caller and provider of the interface in the multiple call chains.

[0006] In this implementation, the method extracts call and provision information from the code repository during the release phase, and then stores this information in a graph to construct a graph structure. This method obtains multiple call chains and multiple provision chains from the graph structure, and derives dependencies based on these chains. Compared to related technologies that use static analysis to obtain dependencies, this method does not require the completeness of probing use cases or the costly construction of a runtime environment, thus reducing the cost of obtaining dependencies and expanding its application scenarios.

[0007] In one implementation, obtaining the invocation information and provision information based on the plurality of code files specifically includes: converting the plurality of code files into a syntax tree to obtain an abstract syntax tree (AST) of the plurality of code files; and obtaining the invocation information and provision information based on the AST of the plurality of code files.

[0008] In this implementation, the method converts multiple code files into an Abstract Syntax Tree (AST) of the code files, which can capture hidden calling and provisioning information from the AST, thereby improving the accuracy of dependency acquisition.

[0009] In one implementation, obtaining the dependency relationship of the multiple code files based on the multiple call chains and the multiple provider chains specifically includes: generating a second vector for each of the multiple call chains; calculating the similarity between the second vectors of the multiple call chains and a plurality of first vectors, wherein the plurality of first vectors are obtained based on the multiple provider chains; selecting first vectors with similarity greater than a set threshold for the multiple call chains to obtain first vectors corresponding to the multiple call chains; and obtaining the dependency relationship of the multiple code files based on the second vectors of the multiple call chains and the first vectors corresponding to the multiple call chains.

[0010] In this implementation, the method can convert the call chain and the provider chain into vector form for matching, which can improve the accuracy of matching and thus improve the accuracy of obtaining dependencies.

[0011] In one embodiment, generating a second vector for the plurality of call chains specifically includes: obtaining functional information of the interfaces of the plurality of call chains based on the identifiers of the interfaces of the plurality of call chains; obtaining summary information of the interfaces of the plurality of call chains based on the functional information of the interfaces of the plurality of call chains; and generating a second vector for the plurality of call chains based on the identifiers of the interfaces of the plurality of call chains, the functional information of the interfaces of the plurality of call chains, and the summary information of the interfaces of the plurality of call chains.

[0012] In this implementation, the method can analyze the business logic of the call implementation based on the identifier of the call chain structure and the call chain context to analyze the functional information of the interface in the call chain, and generate a relevant summary based on the interface's function. The second vector generated by this method based on the relevant summary of the interface's function is more representative of the interface's function, thereby improving the accuracy of matching.

[0013] In one embodiment, before generating a second vector of the plurality of call chains based on the plurality of call chains, the method further includes: obtaining interface definitions from the plurality of provider chains to obtain interface definitions of the plurality of provider chains; obtaining functional information of the interfaces of the plurality of provider chains based on the interface definitions of the plurality of provider chains; and obtaining a first vector of the plurality of provider chains based on the identifiers of the interfaces of the plurality of provider chains and the functional information of the interfaces of the plurality of provider chains.

[0014] In this implementation, the method can identify the functionality provided by the interface based on the interface definition, including its context and comments. The first vector generated by this method based on the identified functionality more accurately represents the interface's function, thereby improving matching accuracy.

[0015] In one implementation, traversing the graph structure to obtain multiple call chains and multiple provider chains specifically includes: initiating a request to determine multiple endpoint calls in the graph structure; executing from the multiple endpoint calls to the starting call according to the association between the calls to obtain the multiple call chains; and extracting providers from the starting calls to the endpoint calls of the multiple call chains to obtain the multiple provider chains.

[0016] Secondly, this application provides an information extraction device, comprising: an AST generation module for acquiring multiple code files, wherein the code files are cloud service code in the code repository of a service cluster during the release phase; a graph generation module for obtaining call information and provision information based on the multiple code files; wherein the call information includes inter-function calls and dependency calls in the multiple code files, and the provision calls include at least one of class definitions, function definitions, variable definitions, and representational state transition REST application programming interface (API) definitions in the multiple code files; storing the call information and the provision information in a graph to obtain a graph structure; traversing the graph structure to obtain multiple call chains and multiple provision chains; and a processing module for obtaining the dependency relationships of the multiple code files based on the multiple call chains and the multiple provision chains; wherein the dependency relationships of the multiple code files indicate the relationship between the caller and provider of the interface in the multiple call chains.

[0017] In one implementation, the AST generation module is specifically used to convert the plurality of code files into a syntax tree to obtain the abstract syntax tree (AST) of the plurality of code files; the graph generation module is specifically used to obtain the calling information and the providing information based on the AST of the plurality of code files.

[0018] In one implementation, the processing module is specifically configured to: generate second vectors for the plurality of call chains; calculate similarity between the second vectors of the plurality of call chains and a plurality of first vectors, respectively; the plurality of first vectors are obtained based on the plurality of providing chains; select first vectors with similarity greater than a set threshold for the plurality of call chains to obtain first vectors corresponding to the plurality of call chains; and obtain the dependency relationships of the plurality of code files based on the second vectors of the plurality of call chains and the first vectors corresponding to the plurality of call chains.

[0019] In one embodiment, the processing module is specifically configured to obtain functional information of the interfaces of the plurality of call chains based on the identifiers of the interfaces of the plurality of call chains; obtain summary information of the interfaces of the plurality of call chains based on the functional information of the interfaces of the plurality of call chains; and generate a second vector of the plurality of call chains based on the identifiers of the interfaces of the plurality of call chains, the functional information of the interfaces of the plurality of call chains, and the summary information of the interfaces of the plurality of call chains.

[0020] In one embodiment, before generating the second vector of the plurality of call chains based on the plurality of call chains, the processing module is further configured to obtain interface definitions from the plurality of provider chains to obtain interface definitions of the plurality of provider chains; obtain functional information of the interfaces of the plurality of provider chains based on the interface definitions of the plurality of provider chains; and obtain the first vector of the plurality of provider chains based on the identifiers of the interfaces of the plurality of provider chains and the functional information of the interfaces of the plurality of provider chains.

[0021] In one implementation, the graph generation module is specifically used to initiate a request, determine multiple endpoint calls in the graph structure, execute from the multiple endpoint calls to the starting call according to the association between the calls, and obtain the multiple call chains; extract providers from the starting calls to the endpoint calls of the multiple call chains to obtain the multiple provider chains.

[0022] Thirdly, embodiments of this application provide a computing device, including: at least one memory; and at least one processor, the processor being configured to execute instructions stored in the memory to cause the computing device to perform the various possible implementations of the first aspect.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium including computer program instructions, which, when executed by a computing device, perform the various possible implementations of the first aspect.

[0024] Fifthly, this application provides a computer program product containing instructions, characterized in that the computer program product stores instructions that, when executed by a computing device, cause the computing device to implement various possible implementations of the first aspect.

[0025] In a sixth aspect, embodiments of this application provide a computing device cluster, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster performs the various possible implementations of the first aspect.

[0026] In a seventh aspect, embodiments of this application provide a computer-readable storage medium including computer program instructions that, when executed by a cluster of computing devices, perform the various possible implementations of the first aspect.

[0027] Eighthly, this application provides a computer program product containing instructions, characterized in that the computer program product stores instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to implement various possible implementations of the first aspect. Attached Figure Description

[0028] The accompanying drawings used in the description of the embodiments or prior art are briefly introduced below.

[0029] Figure 1 This is a schematic diagram illustrating the entire software development process for service clusters in related technologies.

[0030] Figure 2 This is a schematic diagram of the structure of an information extraction system provided in an embodiment of this application;

[0031] Figures 3(a)-3(b) This is a schematic diagram illustrating the process of the AST generation module obtaining the call chain in the embodiments of this application;

[0032] Figures 4(a)-4(b) A schematic diagram illustrating the process of obtaining the provided chain for the AST generation module provided in this application embodiment;

[0033] Figure 5 This is a schematic diagram illustrating the process of the processing module extracting dependencies in the embodiments of this application;

[0034] Figure 6(a) is a flowchart of the functions provided by the HCCTunKey service in the embodiments of this application, which is derived from the interface providing the chain.

[0035] Figure 6(b) is a flowchart of the HCCTunKey service interface for obtaining the call chain provided in the embodiments of this application;

[0036] Figure 7 This is a schematic diagram of a user information extraction system provided in the embodiments of this application.

[0037] Figure 8 This is a flowchart of an information extraction method provided in the embodiments of this application;

[0038] Figure 9 This is a schematic diagram of the software layer structure of the information extraction system provided in the embodiments of this application;

[0039] Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0040] Figure 11 This is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of this application;

[0041] Figure 12 This is a schematic diagram of another computing device cluster architecture provided in the embodiments of this application. Detailed Implementation

[0042] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0043] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0044] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0045] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0046] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0047] Before introducing the technical solution protected by this application, several technical terms involved in the technical solution protected by this application will be explained in advance, namely:

[0048] An abstract syntax tree (AST) is a data structure used to represent the abstract syntactic structure of source code. An AST organizes the syntactic elements of code (such as variables, operators, and statements) in a tree structure, making it easier for compilers and interpreters to analyze and process the code.

[0049] Large language model (LLM) is an artificial intelligence model based on deep learning technology, specifically designed for processing and generating natural language.

[0050] A graph is a data structure used to represent a set of objects and the relationships between them. A graph consists of vertices (or nodes) and edges (lines connecting vertices) and is widely used in computer science, mathematics, network analysis, and other fields.

[0051] Next, the technical solution provided in this application will be introduced.

[0052] Generally, such as Figure 1 As shown, the service cluster process can be divided into five stages: requirements analysis, design, development, testing, and release. The specific work processes of each stage are as follows:

[0053] Requirements Analysis Phase: Communicate with stakeholders (such as clients, users, project managers, etc.) to understand their expectations and needs. Write a requirements specification document, detailing functional requirements, non-functional requirements, and technical constraints. Ensure all stakeholders agree on the requirements and obtain approval.

[0054] Design Phase: Define the overall system structure, including components, modules, and their interactions. Detailed design is performed for each module, including data structures, interfaces, and algorithms. Sometimes, user interface prototypes are created for later validation and feedback.

[0055] Development Phase: Developers begin writing code based on the design documents, building the various modules of the system. Version control systems (such as Git) are used to manage code changes and versions. Continuous integration tools are integrated into the project to ensure continuous testing and delivery of the code.

[0056] Testing Phase: Developers independently test each module or function to ensure it functions correctly. They also test the interactions between modules to ensure the system works properly as a whole. A comprehensive system-wide test is then conducted, including functional testing, performance testing, and security testing. Finally, testing is performed in the user's environment to verify that the software meets user requirements.

[0057] Release Phase: Install the software into the production environment and ensure it functions correctly in the target environment. Provide user manuals, online help documentation, and necessary training to enable users to effectively use the software. Monitor the software's operational status and promptly address any potential issues. Provide technical support to users, fix bugs, and perform necessary upgrades and maintenance.

[0058] During the release phase, dependencies can be extracted from the generated code repository through static analysis. However, due to a lack of contextual information, this method cannot understand the business logic or semantics of the code. If the code uses complex control flow, conditional logic, or exception handling mechanisms, the statically analyzed dependencies may be missed. Furthermore, static analysis cannot parse or analyze dependencies of external services called in the code, nor can it capture dynamically generated dependencies or runtime code behavior.

[0059] In view of this, embodiments of this application provide an information extraction system. Throughout the software development process of a service cluster, this system can obtain code files from the code repository during the release phase. Then, using AST parsing and graph structure combination techniques with the ability to identify call features and provide features, it analyzes the call relationships and providers of services to obtain dependencies. This system can capture complex calls such as external calls without needing to utilize runtime conditions, thereby reducing the cost of obtaining dependencies and improving application scenarios. The system can obtain dependencies through intelligent code analysis methods, improving the accuracy of dependency extraction.

[0060] Figure 2 This is a schematic diagram of the structure of an information extraction system provided in an embodiment of this application. Figure 2 As shown, the information extraction system 200 may include an AST generation module 210, a graph generation module 220, and a processing module 230.

[0061] After receiving the code files of multiple cloud services from the service cluster, the AST generation module 210 can convert the multiple code files into ASTs respectively to construct the ASTs of the multiple code files.

[0062] Code files refer to the code for a cloud service within the code repository of the service cluster during the release phase. Each code file contains the code for one cloud service within the code repository of the service cluster during the release phase. The code in the code files can be in programming languages ​​such as Python, Java, and JavaScript.

[0063] For example, taking Python code in a code file as an example, the AST generation module 210 can create a Python example code file, such as example.py. The AST generation module 210 provides a built-in AST module that converts the Python code in the code file into an AST structure to obtain the AST of the code file. The AST generation module 210's conversion of the code file into its AST provides developers and tools with a powerful and structured way to analyze, understand, and transform code, playing a significant role in code quality assurance, refactoring, optimization, and security testing.

[0064] The graph generation module 220 is used to parse the AST of multiple code files to obtain call information and supply information, and then obtain at least one call chain and at least one supply chain based on the call information and supply information.

[0065] The call information includes inter-function calls and dependency calls within the code, such as software development kit (SDK) calls, REST API calls, and whether a function sends a request (with the corresponding request URL, request method, and request body). For example, the graph generation module 220 can identify the programming language type of the code in the AST of each code file and select different AST parsers for code files in different programming languages. For instance, if the code in the AST of a code file is Python code, the AST parser selected by the graph generation module 220 could be static code analysis. If the code in the AST of a code file is JavaScript, the AST parser selected by the graph generation module 220 could support multiple JavaScript syntaxes.

[0066] Graph generation module 220 can select a specified AST parser, allowing the AST parser to traverse the AST of the code file by recursively visiting each node in the AST. During the traversal of the AST, the AST parser can recursively traverse the AST to parse the dimante structure point by point and extract key information. For example, when the AST parser encounters an import node, it can record the imported modules. When it encounters an assign node, it can extract the variable names from assignment statements. When it encounters a call node, it can obtain the name of the function call and its associated module or object. Based on the key information recorded each time, graph generation module 220 can construct an inter-function call or dependency call, thereby obtaining call information.

[0067] The provided information includes class definitions, function definitions, variable definitions, REST API definitions, and other information from the code. For example, during the AST traversal of the code file, the AST parser can record data such as parameter passing, variable usage, and possible return values ​​each time it encounters a function call node. The graph generation module 220 can then construct the provided information based on the recorded data regarding parameter passing, variable usage, and possible return values.

[0068] In this embodiment, the graph generation module 220 can store call information and provider information in a graph to represent the relationships between calls, functions, and cloud services. Edges in the graph represent function calls, and nodes represent functions or cloud services. The graph generation module 220 can use graph algorithms (such as depth-first search, breadth-first search, etc.) to mine the total number of REST API calls made by each cloud service and their corresponding request methods from the graph. The graph generation module 220 can initiate requests (such as HTTP requests), determine the endpoint call in the graph, and then, according to the relationships between calls, reverse the process back to the starting call, recording all calls throughout the process to form multiple call chains. The graph generation module 220 can analyze each call chain from its starting call, forward to the endpoint call, and record the provider of each analyzed call to form multiple provider chains.

[0069] In one embodiment, as shown in Figure 3(a), the graph generation module 220 obtains n call chains, where n is a positive integer greater than 1. Call chain 1 starts by sending a request from service 1 (i.e., the code file corresponding to cloud service 1) and continues until it ends at an interface; the entire process is "service 1 → function 1 → function 2 → ... → function i → interface". Call chain 2 starts by sending a request from service 2 (i.e., the code file corresponding to cloud service 2) and continues until it ends at an interface; the entire process is "service 2 → function j → SDK → ... → tool → interface".

[0070] As shown in Figure 3(b), in the AST of multiple code files, call chain 1 indicates that the request corresponding to code file 1 is sent to the REST API interface through functions Cls.1, Func.1, Func.j, and Func.o. Call chain 3 indicates that the request corresponding to code file 3 is sent to the SDK through functions Cls.k, Func.q, and Func.p, and the SDK then calls the internally provided interface to send the request. Call chain n indicates that the request corresponding to code file N is sent to the remote procedure call (RPC) interface asynchronously through function Cls.l.

[0071] In another embodiment, as shown in Figure 4(a), the graph generation module 220 obtains n provider chains. Provider chain 1 starts by sending a request from service 1 (i.e., the code file corresponding to cloud service 1) and continues until it ends at an interface; the entire process is "service 1 → interface". Provider chain 2 starts by sending a request from service 2 (i.e., the code file corresponding to cloud service 2) and continues until it ends at an interface; the entire process is "service 2 → SDK → interface".

[0072] As shown in Figure 4(b), in the AST of multiple code files, Provider Chain 1 represents the name of the process in which the request corresponding to code file 1 is sent to the REST API interface via functions Cls.1 and Func.1. Provider Chain 2 represents the name of the process in which the request corresponding to code file 2 is sent to the REST API interface. Provider Chain n represents the name of the process in which the request corresponding to the code file in the SDK is sent to the API via various functions. When the SDK is called, it internally converts the request parameters into the required format according to the defined logic and calls the specific API interface or service.

[0073] The processing module 230 is used to identify the provider corresponding to the interface called in each call chain based on at least one call chain and at least one provider chain, and obtain the dependency relationship of multiple code files.

[0074] For example, after receiving at least one provider chain, the processing module 230 can obtain interface definitions from the provider chains to obtain the interface definition for each provider chain. The processing module 230 can input the interface definition of each provider chain into a large model (such as an LLM), leveraging the large model's ability to understand code and identify the functional information of each interface through the context, comments, and other information of the interface definition. The processing module 230 can construct a provider vector library for storing vectors. Based on the identifier and functional information of each interface, the processing module 230 can generate an interface vector (hereinafter referred to as the "first vector") in the form of "identifier:functional information," and then store it in the provider vector library. The identifier of the interface can be the name of the interface, a unique identifier for the interface, etc.

[0075] In one embodiment, the identifier is used as the interface name. For example... Figure 5 As shown, the interface named " / v3 / auth / tokens" has the function of "IAM authentication, obtaining the corresponding token through user ID and password". The processing module 230 can generate the first vector " / v3 / auth / tokens: IAM authentication, obtaining the corresponding token through user ID and password" in the form of "identifier: function information".

[0076] The interface named " / v3-huawei / create aksk" has the function of "IAM service, creating an AK / SK key pair that can identify the sender of the request by calling the API and perform an encrypted signature on the request". The processing module 230 can generate a first vector in the form of "identifier: function information" that reads " / v3-huawei / create aksk: IAM service, creating an AK / SK key pair that can identify the sender of the request by calling the API and perform an encrypted signature on the request".

[0077] After receiving at least one call chain, processing module 230 inputs the identifier of the interface called by each call chain into a large model (such as an LLM). Leveraging the large model's ability to understand code, it first analyzes the functionality implemented by the call chain to determine what information is obtained after calling the API interface. Then, based on how this information assists the call chain in completing its own function, the large model infers the functionality provided by the interface. Processing module 230 can generate a summary of the interface's functionality based on the interface's identifier, functional information, and summary information. Processing module 230 can then generate a vector (hereinafter referred to as the "second vector") based on the interface's identifier, functional information, and summary information.

[0078] In one embodiment, as shown in Figure 6(a), the next node in the code file "hce_turnkey_docking_kms.py" in the HCCTunKey service is the node "DockKmsUtil" and the node "HCCIAMUtil". The next node in "DockKmsUtil" is the node "_init_" and the node "_create_op_svc_iaas_account". The next node in "HCCIAMUtil" is the node "get_ak_sk" and the node "create_user_ak_sk". The next node in "create_user_ak_sk" is the node "requests.get(url,headers=headers)" and the node "url:{HCCHAMUtil#url_base) / v3-huawei / create_aksk / {HCCHAMUtil#user_id}".

[0079] In the call chain corresponding to the HCCTunKey service, the function in node "_init_" calls the function in node "_create_op_svc_iaas_account". The function in node "_create_op_svc_iaas_account" calls the function in node "get_ak_sk". The function in node "get_ak_sk" calls the function in node "create_user_ak_sk". The function in node "create_user_ak_sk" calls the function in node "requests.get(url,headers=headers)". The function in node "requests.get(url,headers=headers)" calls the function in node "url:{HCCHAMUtil#url_base) / v3-huawei / create_aksk / {HCCHAMUtil#user_id}".

[0080] As shown in Figure 6(b), the HCCTunKey service implements the function of creating and retrieving AccessKey (AK) and SecretKey (SK) through a call chain. The specific process is as follows:

[0081] 'DockKmsUtil#_init_': Initializes the DockKmsUtil class, passing in project_id, pod_id, and region_id. Then, it creates the IaaS account for the OperationService using the '_create_op_svc_iaas_account' method.

[0082] 'DockKmsUtil#_create_op_svc_iaas_account': Creates an HCCIIAMUtil object using the passed-in parameters. Then calls the 'get ak sk' method to retrieve the AK and SK.

[0083] 'HCCIAMUtil#get_ak_sk': First, it attempts to obtain the IAM (Identity and Access Management) token and project user ID. If a 401 (Unauthorized) status code is returned, an operations service account is created, and the token is retrieved again. If successful, the token is parsed, and the X-Auth-Token is set in the request header. Then, the 'create user ak sk' method is called to create and return the AK and SK.

[0084] 'HCCIAMUtil#ereate_user_ak_sk': Constructs a URL that points to an HCCIIAM interface used to create AK and SK, and then sends a GET request. Parses the AK and SK from the response content and returns them.

[0085] The primary purpose of the HCCTunKey service's call chain is to provide users with an AK and SK pair, which can be used for authentication and authorization to access and manage HCC (Huawei Cloud Container Service) resources. AK and SK are typically used to sign API requests, ensuring the request origin is reliable and that the requested operation is within authorized scope.

[0086] Processing module 230 can perform similarity matching in the provider vector library based on the second vector of the interface, and match the first vector of at least one interface with a similarity greater than a set threshold for the second vector of the interface. Processing module 230 can obtain the summary information corresponding to the second vector of the interface, as well as the identifier and functional information of the provider corresponding to the first vector of at least one interface, based on the second vector of the interface and the first vector of at least one interface. Processing module 230 can input the summary information, the identifier of at least one interface, and the functional information of at least one interface into a large model (such as an LLM), and use the analytical capabilities of the large model to analyze which provider's interface best matches the functionality in the call chain, thus obtaining the optimal provider. After analyzing and determining the optimal provider for each call chain, processing module 230 can obtain the dependency relationship between the caller and provider corresponding to each interface based on each call chain and its optimal provider.

[0087] After the information extraction system 200 identifies dependencies, it can display them on the HCC Factory. The interface personnel for each service can confirm the identified dependencies on the Factory. If the dependencies identified by the information extraction system 200 do not match the actual dependencies, the interface personnel can make the necessary modifications.

[0088] Testers perform compatibility testing based on the dependencies identified by the information extraction system 200. If the dependencies identified by the information extraction system 200 are incorrect, the error can be displayed on the Factory. If the service interface provider discovers an error in the dependencies displayed on the Factory, they can manually verify the dependencies to ensure their correctness.

[0089] The information extraction system 200 correctly identifies the dependency relationship. This dependency relationship can be used as training data and input into the large model for training, enabling the large model to better understand the code and more deeply explore the dependencies in the code.

[0090] It should be understood that the functional modules and devices involved in the aforementioned information extraction system 200 can all be implemented through software or hardware, depending on the actual situation, and are not limited here. Furthermore, the functional modules and devices involved in the aforementioned information extraction system 200 can be arranged individually or integrated, and are not limited here.

[0091] The above is a description of the information extraction system 200 provided in this application embodiment. It is understood that the information extraction system 200 can be configured on a cloud computing platform, for example, deployed on at least one virtual machine or container instance, so that the cloud computing platform can provide information extraction services. Of course, the information extraction system 200 can also be configured on nodes other than the cloud computing platform, for example, deployed in at least one data center or on at least one server, depending on the actual situation, and is not limited here. The cloud computing platform can provide pages related to public cloud services for users to remotely access public cloud services. In this embodiment, users can pre-purchase the information extraction services provided by the information extraction system 200 on the cloud computing platform. For ease of understanding, the interaction between the user and the cloud computing platform is described below.

[0092] like Figure 7 As shown, the interaction between the user and the cloud computing platform mainly includes: the user logs into the cloud computing platform 700 through a web page on the client side, selects and purchases cloud services (i.e., information extraction services) related to the information extraction system 200 on the cloud computing platform 700. After purchase, the user can generate the information extraction system 200 on the cloud computing platform 700 based on the functions provided by the information extraction service. The cloud computing platform 700 is primarily used to manage the infrastructure for running the information extraction service. For example, the infrastructure for the information extraction service may include multiple data centers located in different regions, each data center including multiple servers. The data centers can provide basic resources for the information extraction service, such as computing resources and storage resources. Therefore, when purchasing and using the information extraction service, the user mainly pays for the resources used. When using the information extraction service, the user can input their needs for the information extraction service through the configuration interface, API, or user interaction interface provided by the cloud computing platform 700. The cloud computing platform 700 can then generate an information extraction service matching the user's (or other software / hardware, etc.) input needs.

[0093] Alternatively, some modules in the information extraction system 200 can be configured on the cloud side and others on the edge side, thereby realizing information extraction services through edge-cloud collaboration. Furthermore, the information extraction system 200 can also be entirely configured on the edge side, depending on the actual situation; no specific limitation is made here.

[0094] The above is an introduction to the information extraction system provided in the embodiments of this application. Next, based on the above content, the simulation method provided in the embodiments of this application will be introduced.

[0095] For example, Figure 8 A flowchart illustrating an information extraction method provided in an embodiment of this application is shown. It can be understood that this information extraction method can be executed by the aforementioned information extraction system 200, and the specific implementation process is as follows:

[0096] Step S801: Obtain multiple code files.

[0097] Code files refer to the code for a cloud service within the code repository of the service cluster during the release phase. Each code file contains the code for one cloud service within the code repository of the service cluster during the release phase. The code in the code files can be in programming languages ​​such as Python, Java, and JavaScript.

[0098] For example, taking Python code in a code file as an example, the information extraction system 200 can create a Python example code file, such as example.py. The information extraction system 200 can provide a built-in AST module to convert the Python code in the code file into an AST structure, thus obtaining the AST of the code file. By converting multiple code files into their ASTs, the information extraction system 200 can capture hidden calling and provisioning information from the AST, thereby improving the accuracy of dependency retrieval.

[0099] Step S802: Obtain calling information and provided information based on multiple code files.

[0100] The call information includes inter-function calls and dependency calls within the code. For example, the information extraction system 200 can identify the programming language type of the code in the AST of each code file and select different AST parsers for code files in different programming languages. For instance, if the code in the AST of a code file is Python code, the information extraction system 200 can select an AST parser that supports multiple JavaScript syntaxes.

[0101] The information extraction system 200 can select a specified AST parser, allowing the AST parser to traverse the AST of a code file by recursively visiting each node in the AST. During the traversal, the AST parser can recursively traverse the AST to parse the dimante structure point by point and extract key information. For example, when the AST parser encounters an `import` node, it can record the imported modules. When it encounters an `assign` node, it can extract variable names from assignment statements. When it encounters a `call` node, it can obtain the name of the function call and its associated module or object. Based on the key information recorded each time, the information extraction system 200 can construct an inter-function call or dependency call, thereby obtaining call information.

[0102] The information provided includes class definitions, function definitions, variable definitions, REST API definitions, and other information from the code. For example, during the AST traversal of the code file, the AST parser can record data such as parameter passing, variable usage, and possible return values ​​each time it encounters a function call node. The information extraction system 200 can then construct the provided information based on the recorded data regarding parameter passing, variable usage, and possible return values.

[0103] Step S803: Store the calling information and the provided information in the graph to obtain the graph structure.

[0104] Step S804: Traverse the graph structure to obtain multiple call chains and multiple provider chains.

[0105] Specifically, the information extraction system 200 can store call information and provider information in a graph, using a graph structure to represent the relationships between calls, functions, and cloud services. Edges in the graph represent function calls, and nodes represent functions or cloud services. The information extraction system 200 can use graph algorithms (such as depth-first search, breadth-first search, etc.) to extract the total number of REST API calls made by each cloud service and their corresponding request methods from the graph. The information extraction system 200 can initiate requests (such as HTTP requests) to determine the endpoint call in the graph, and then, according to the relationships between calls, execute backwards to the starting call, recording all calls throughout the process to form multiple call chains. The information extraction system 200 can analyze each call chain from its starting call forwards to the endpoint call, recording the provider of each analyzed call to form multiple provider chains.

[0106] Step S805: Based on multiple call chains and multiple provider chains, obtain the dependency relationships of multiple code files.

[0107] For example, after receiving at least one provider chain, the information extraction system 200 can obtain interface definitions from the provider chains, thus obtaining the interface definition for each provider chain. The information extraction system 200 can input the interface definition of each provider chain into a large model (such as an LLM), leveraging the large model's ability to understand code and identify the functional information of each interface through the context, comments, and other information of the interface definition. The information extraction system 200 can construct a provider vector library for storing vectors. Based on the identifier and functional information of each interface, the information extraction system 200 can generate a first vector for the interface in the form of "identifier: functional information," and then store it in the provider vector library. The identifier of the interface can be the name of the interface, a unique identifier of the interface, etc. The first vector generated by the information extraction system 200 based on the identified functions provided by the interface is more representative of the interface's function, thereby improving the accuracy of matching.

[0108] After receiving at least one call chain, the information extraction system 200 inputs the identifier of the interface called by each call chain into a large model (such as an LLM). Leveraging the large model's ability to understand code, it first analyzes the functionality implemented by the call chain to determine what information is obtained after calling the API interface. Then, based on how this information assists the call chain in completing its function, the large model infers the functionality provided by the interface. The information extraction system 200 can generate a summary of the interface based on the functionality provided by each interface. The information extraction system 200 can also generate a second vector based on the identifier of each interface, the interface's functional information, and the interface's summary information. The second vector generated by the information extraction system 200, based on the interface's functionality, more accurately represents the interface's function, thereby improving matching accuracy.

[0109] The information extraction system 200 can perform similarity matching in a provider vector library based on the second vector of an interface, matching at least one first vector of an interface with a similarity greater than a set threshold for the second vector of the interface. The information extraction system 200 can obtain the summary information corresponding to the second vector of the interface, as well as the identifier and functional information of the provider corresponding to the first vector of at least one interface, based on the second vector of the interface and the first vector of at least one interface. The information extraction system 200 can input the summary information, the identifier of at least one interface, and the functional information of at least one interface into a large model (such as an LLM), and utilize the analytical capabilities of the large model to analyze which provider's interface best matches the functionality in the call chain, thus obtaining the optimal provider. After analyzing and identifying the optimal provider for each call chain, the information extraction system 200 can obtain the dependency relationship between the caller and provider corresponding to each interface based on each call chain and its optimal provider.

[0110] In this embodiment, the information extraction system 200 extracts call information and provision information from the code repository during the release phase, and stores the call information and provision information in a graph to construct a graph structure. The information extraction system 200 obtains multiple call chains and multiple provision chains from the graph structure, and derives dependencies based on these chains. Compared to related technologies that use static analysis techniques to obtain dependencies, the information extraction system 200 does not require the completeness of dependency probe cases or the costly construction of a runtime environment, thus reducing the cost of obtaining dependencies and expanding application scenarios.

[0111] This application provides an information extraction device that can be divided into categories based on execution functions, such as... Figure 2 The information extraction system 200 shown includes an AST generation module 210, a graph generation module 220, and a processing module 230.

[0112] The information extraction device can be an application, software code, etc., deployed and executed on a computing device or a cluster of computing devices. The computing device can be a server, computer, laptop, tablet, smartphone, etc. The information extraction device can be deployed on a cloud server. If the information extraction device is deployed on a cloud service, the designer can use a local device to call the cloud server to use the information extraction device to complete the corresponding task. The specific implementation process of the information extraction device is as follows:

[0113] AST generation module 210 is used to obtain multiple code files, which are the cloud service code in the code repository of the service cluster during the release phase. Graph generation module 220 is used to obtain call information and provision information based on the multiple code files. The call information includes inter-function calls and dependency calls in the multiple code files, and the provision calls include at least one of the class definitions, function definitions, variable definitions, and representational state transition REST application programming interface (API) definitions in the multiple code files. Graph generation module 220 is used to store the call information and provision information in a graph to obtain a graph structure. Graph generation module 220 is used to traverse the graph structure to obtain multiple call chains and multiple provision chains. Processing module 230 is used to obtain the dependencies of the multiple code files based on the multiple call chains and multiple provision chains. The dependencies of the multiple code files indicate the relationship between the callers and providers of the interfaces in the multiple call chains.

[0114] In one implementation, the AST generation module 210 is specifically used to convert multiple code files into a syntax tree to obtain an abstract syntax tree (AST) of the multiple code files; the graph generation module 220 is specifically used to obtain calling information and providing information based on the ASTs of the multiple code files.

[0115] In one implementation, the processing module 230 is specifically used to generate a second vector of multiple call chains based on multiple call chains; the processing module 230 is specifically used to calculate the similarity between the second vector of the multiple call chains and a multiple first vector respectively; the multiple first vectors are obtained based on multiple call chains; the processing module 230 is specifically used to select the first vector with a similarity greater than a set threshold for the multiple call chains, thereby obtaining the first vector corresponding to the multiple call chains; the processing module 230 is specifically used to obtain the dependency relationship of multiple code files based on the second vector of the multiple call chains and the first vector corresponding to the multiple call chains.

[0116] In one embodiment, the processing module 230 is specifically used to obtain functional information of the interfaces of the multiple call chains based on the identifiers of the interfaces of the multiple call chains; the processing module 230 is specifically used to obtain summary information of the interfaces of the multiple call chains based on the functional information of the interfaces of the multiple call chains; the processing module 230 is specifically used to generate a second vector of the multiple call chains based on the identifiers of the interfaces of the multiple call chains, the functional information of the interfaces of the multiple call chains, and the summary information of the interfaces of the multiple call chains.

[0117] In one embodiment, before generating a second vector of multiple call chains based on multiple call chains, the processing module 230 is further configured to obtain interface definitions from multiple provider chains to obtain interface definitions of multiple provider chains; the processing module 230 is further configured to obtain functional information of the interfaces of multiple provider chains based on the interface definitions of multiple provider chains; the processing module 230 is further configured to obtain a first vector of multiple provider chains based on the identifiers of the interfaces of multiple provider chains and the functional information of the interfaces of multiple provider chains.

[0118] In one implementation, the graph generation module 220 is specifically used to initiate a request and determine multiple endpoint calls in the graph structure; the graph generation module 220 is specifically used to execute from the multiple endpoint calls to the starting call according to the association between the calls, to obtain multiple call chains; the graph generation module 220 is specifically used to extract providers from the starting calls to the endpoint calls of the multiple call chains, to obtain multiple provider chains.

[0119] The AST generation module 210, graph generation module 220, and processing module 230 can all be implemented in software or in hardware. For example, the implementation of the AST generation module 210 will be described below. Similarly, the implementation of the graph generation module 220 and processing module 230 can refer to the implementation of the AST generation module 210.

[0120] As an example of a software functional unit, the AST generation module 210 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the AST generation module 210 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0121] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0122] As an example of a hardware functional unit, the AST generation module 210 may include at least one computing device, such as a server. Alternatively, the AST generation module 210 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0123] The AST generation module 210 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the AST generation module 210 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the AST generation module 210 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0124] It should be noted that, in other embodiments, the AST generation module 210 can be used to execute any step in the information extraction method, the graph generation module 220 can be used to execute any step in the information extraction method, and the processing module 230 can be used to execute any step in the information extraction method. The steps implemented by the AST generation module 210, the graph generation module 220, and the processing module 230 can be specified as needed. The AST generation module 210, the graph generation module 220, and the processing module 230 respectively implement different steps in the information extraction method to realize all the functions of the information extraction device.

[0125] Figure 9 This is a schematic diagram of the software layer structure of the information extraction system provided in the embodiments of this application. For example... Figure 9 As shown, this software layer includes the application layer, model layer, business layer, and data layer.

[0126] The application layer includes service dependency analysis tools. These tools enable the information extraction system to perform its functions.

[0127] The model layer includes an LLM. An LLM can be used for the large model described above, and its functionality includes:

[0128] Upon receiving the interface definition for each providing chain, LLM leverages its understanding of the code to identify the functional information of each interface through the context, comments, and other information in the interface definition.

[0129] Upon receiving the identifier of the interface called by each call chain, LLM uses its understanding of the code to first analyze the functionality implemented by the call chain to obtain the information that can be obtained after calling the API interface. Then, based on how this information assists the call chain in completing its own functionality, it deduces the functionality provided by the interface.

[0130] Upon receiving summary information, the identifier of at least one interface, and the functional information of at least one interface, LLM uses its analytical capabilities to determine which provider's interface best matches the functionality in the call chain, thus obtaining the optimal provider.

[0131] The business layer interacts with the data layer to obtain dependency relationships, and the specific functions implemented are as follows:

[0132] The data layer retrieves the code repositories of each service. The business layer can retrieve code files from the code repositories. The business layer can convert the code files into an Abstract Syntax Tree (AST). The business layer can use graph algorithms to store the AST in a graph to construct a graph structure. The data layer can store the ASTs of each service. The business layer can combine call feature recognition modules and provider feature recognition modules to analyze the caller, call chain, and provider chain. The data layer can store each service, call chain, and provider chain. The business layer can use an LLM (Local Management Model) to identify the functional information of each interface based on the call chain and then calculate the second vector of each call chain. The business layer can use an LLM to deduce the functionality provided by each interface based on the provider chain and then calculate the first vector of each provider chain. The data layer can store information such as the functional information of each interface through the provider chain and the functionality provided by each interface in the provider chain. The business layer can use an LLM, based on summary information, the identifier of at least one interface, and the functional information of at least one interface, and using its own analytical capabilities, to analyze which provider's interface best matches the functionality in the call chain, thus obtaining the optimal provider. The data layer can store the dependencies between services.

[0133] Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Figure 10 As shown, the computing device 1000 includes a bus 1010, a processor 1020, a memory 1030, and a communication interface 1040. The processor 1020, memory 1030, and communication interface 1040 communicate with each other via the bus 1010. The computing device 1000 can be a server, computer, laptop, server rack, etc. It should be understood that this application does not limit the number of processors and memory in the computing device 1000.

[0134] Bus 1010 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 10 The bus 1010 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1010 may include a path for transmitting information between various components of the computing device 1000 (e.g., processor 1020, memory 1030, communication interface 1040).

[0135] The processor 1020 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0136] The memory 1030 may include volatile memory, such as random access memory (RAM). The memory 1030 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0137] The memory 1030 stores executable program code, which the processor 1020 executes to implement the functions of the aforementioned modules, such as the AST generation module 210, the graph generation module 220, and the processing module 230, thereby realizing the information extraction method. In other words, the memory 1030 stores instructions for executing the information extraction method.

[0138] Alternatively, the memory 1030 may store executable code, which the processor 1020 executes to implement the functions of the aforementioned modules, thereby realizing the information extraction method. That is, the memory 1030 stores instructions for executing the information extraction method.

[0139] The communication interface 1040 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1000 and other devices or communication networks.

[0140] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0141] like Figure 11 As shown, the computing device cluster includes at least one computing device 1000. The memory 1030 of one or more computing devices 1000 in the computing device cluster may store the same instructions for executing information extraction methods.

[0142] In some possible implementations, the memory 1030 of one or more computing devices 1000 in the computing device cluster may also store partial instructions for executing the information extraction method. In other words, a combination of one or more computing devices 1000 can jointly execute the instructions for executing the information extraction method.

[0143] It should be noted that the memory 1030 in different computing devices 1000 within the computing device cluster can store different instructions, which are used to execute parts of the functions of the AST generation module 210, graph generation module 220, and processing module 230 described above. That is, the instructions stored in the memory 1030 of different computing devices 1000 can implement the functions of one or more modules of the AST generation module 210, graph generation module 220, and processing module 230 described above.

[0144] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 12 One possible implementation is shown. For example... Figure 12 As shown, computing devices 1000A and 1000B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 1030 in computing device 1000A stores instructions for performing the functions of some modules of the aforementioned AST generation module 210, graph generation module 220, and processing module 230. Simultaneously, the memory 1030 in computing device 1000B stores instructions for performing the functions of another portion of the aforementioned AST generation module 210, graph generation module 220, and processing module 230.

[0145] Figure 12 The connection method between the computing device clusters shown can be such that, considering the information extraction method provided in this application requires a large amount of data storage, the functions implemented by another part of the above-mentioned AST generation module 210, graph generation module 220 and processing module 230 are handed over to the computing device 1000B for execution.

[0146] It should be understood that Figure 12 The functions of computing device 1000A shown can also be performed by multiple computing devices 1000. Similarly, the functions of computing device 1000B can also be performed by multiple computing devices 1000.

[0147] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 10 and Figure 11 The connection method of the computing device cluster. The difference is that the memory 1030 of one or more computing devices 1000 in the computing device cluster can store the same instructions for executing the information extraction method.

[0148] In some possible implementations, the memory 1030 of one or more computing devices 1000 in the computing device cluster may also store partial instructions for executing the information extraction method. In other words, a combination of one or more computing devices 1000 can jointly execute the instructions for executing the information extraction method.

[0149] It should be noted that the memory 1030 in different computing devices 1000 within the computing device cluster can store different instructions for executing some functions of the computing device 1000. That is, the instructions stored in the memory 1030 of different computing devices 1000 can implement the functions of one or more modules of the AST generation module 210, graph generation module 220, and processing module 230 described above.

[0150] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform an information extraction method.

[0151] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct a computing device to perform an information retrieval method.

[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. An information extraction method, characterized in that, include: Obtain multiple code files, which are the cloud service code in the code repository of the service cluster during the release phase; Based on the multiple code files, call information and provision information are obtained; the call information includes inter-function calls and dependency calls in the multiple code files, and the provision calls include at least one of class definitions, function definitions, variable definitions, and Representational State Transition (REST) ​​application programming interface (API) definitions in the multiple code files; The calling information and the provided information are stored in the graph to obtain a graph structure; Traverse the graph structure to obtain multiple call chains and multiple provider chains; Based on the multiple call chains and the multiple provider chains, the dependency relationships of the multiple code files are obtained; The dependencies between the multiple code files indicate the relationship between the callers and providers of the interfaces in the multiple call chains.

2. The method according to claim 1, characterized in that, The process of obtaining the calling information and providing information based on the multiple code files specifically includes: The multiple code files are converted into syntax trees to obtain the abstract syntax tree (AST) of the multiple code files; The calling information and the providing information are obtained based on the AST of the multiple code files.

3. The method according to claim 1 or 2, characterized in that, The step of obtaining the dependency relationships of the multiple code files based on the multiple call chains and the multiple provider chains specifically includes: Based on the multiple call chains, generate a second vector for the multiple call chains; The similarity between the second vectors of the plurality of call chains and the plurality of first vectors is calculated respectively; the plurality of first vectors are obtained based on the plurality of providing chains; Select a first vector whose similarity is greater than a set threshold from the multiple call chains to obtain the first vector corresponding to the multiple call chains; The dependency relationships of the multiple code files are obtained based on the second vector of the multiple call chains and the first vector corresponding to the multiple call chains.

4. The method according to claim 3, characterized in that, The step of generating a second vector for the multiple call chains specifically includes: Based on the identifiers of the interfaces of the multiple call chains, the functional information of the interfaces of the multiple call chains is obtained; Based on the functional information of the interfaces of the multiple call chains, the summary information of the interfaces of the multiple call chains is obtained; A second vector for the multiple call chains is generated based on the identifiers of the interfaces of the multiple call chains, the functional information of the interfaces of the multiple call chains, and the summary information of the interfaces of the multiple call chains.

5. The method according to claim 3 or 4, characterized in that, Before generating the second vector of the plurality of call chains based on the plurality of call chains, the method further includes: Obtain the interface definition from the plurality of provider chains to obtain the interface definition of the plurality of provider chains; Based on the interface definitions of the multiple supply chains, the functional information of the interfaces of the multiple supply chains is obtained; Based on the identifiers of the interfaces of the plurality of providing chains and the functional information of the interfaces of the plurality of providing chains, a first vector of the plurality of providing chains is obtained.

6. The method according to any one of claims 1-5, characterized in that, The traversal of the graph structure to obtain multiple call chains and multiple provider chains specifically includes: Initiate a request to determine multiple endpoint calls in the graph structure; Based on the relationships between the calls, the execution proceeds from the multiple endpoint calls to the starting call, resulting in the multiple call chains; Provider extraction is performed from the start call to the end call of the multiple call chains to obtain the multiple provider chains.

7. An information extraction device, characterized in that, include: The AST generation module is used to obtain multiple code files, which are the cloud service code in the code repository of the service cluster during the release phase. The graph generation module is used to obtain call information and provision information based on the multiple code files; the call information includes inter-function calls and dependency calls in the multiple code files, and the provision calls include at least one of class definitions, function definitions, variable definitions, and Representational State Transition (REST) ​​application programming interface (API) definitions in the multiple code files; The calling information and the provided information are stored in the graph to obtain a graph structure; Traverse the graph structure to obtain multiple call chains and multiple provider chains; The processing module is used to obtain the dependency relationships of the multiple code files based on the multiple call chains and the multiple provider chains; The dependencies between the multiple code files indicate the relationship between the callers and providers of the interfaces in the multiple call chains.

8. The apparatus according to claim 7, characterized in that, The AST generation module is specifically used to convert the multiple code files into a syntax tree to obtain the abstract syntax tree (AST) of the multiple code files. The graph generation module is specifically used to obtain the calling information and the providing information based on the AST of the multiple code files.

9. The apparatus according to claim 7 or 8, characterized in that, The processing module is specifically used to generate a second vector of the multiple call chains based on the multiple call chains; The similarity between the second vectors of the plurality of call chains and the plurality of first vectors is calculated respectively; the plurality of first vectors are obtained based on the plurality of providing chains; Select a first vector whose similarity is greater than a set threshold from the multiple call chains to obtain the first vector corresponding to the multiple call chains; The dependency relationships of the multiple code files are obtained based on the second vector of the multiple call chains and the first vector corresponding to the multiple call chains.

10. The apparatus according to claim 9, characterized in that, The processing module is specifically used to obtain the functional information of the interfaces of the multiple call chains based on the identifiers of the interfaces of the multiple call chains; Based on the functional information of the interfaces of the multiple call chains, the summary information of the interfaces of the multiple call chains is obtained; A second vector for the multiple call chains is generated based on the identifiers of the interfaces of the multiple call chains, the functional information of the interfaces of the multiple call chains, and the summary information of the interfaces of the multiple call chains.

11. The apparatus according to claim 9 or 10, characterized in that, Before generating the second vector of the multiple call chains based on the multiple call chains, the processing module is further configured to... Obtain the interface definition from the plurality of provider chains to obtain the interface definition of the plurality of provider chains; Based on the interface definitions of the multiple supply chains, the functional information of the interfaces of the multiple supply chains is obtained; Based on the identifiers of the interfaces of the plurality of providing chains and the functional information of the interfaces of the plurality of providing chains, a first vector of the plurality of providing chains is obtained.

12. The apparatus according to any one of claims 7-11, characterized in that, The graph generation module is specifically used to initiate a request and determine multiple endpoint calls in the graph structure. Based on the relationships between the calls, the execution proceeds from the multiple endpoint calls to the starting call, resulting in the multiple call chains; Provider extraction is performed from the start call to the end call of the multiple call chains to obtain the multiple provider chains.

13. A computing device cluster, characterized in that, include: At least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-6.

14. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a computing device, cause the computing device to perform the method as described in any one of claims 1-6.

15. A computer program product containing instructions, characterized in that, The computer program product stores instructions that, when executed by a computing device, cause the computing device to perform the method according to any one of claims 1-6.