Micro-service partitioning method and electronic device

Abstract

The application discloses a micro-service division method and electronic equipment, and relates to the technical field of servers, comprising the following steps: obtaining multi-dimensional data of source code, performance, historical changes and semantics of the source code of an original service, constructing a multi-layer graph network and hypergraph joint model, the multi-layer graph network presenting the association relationship of entity nodes from multiple dimensions, the hypergraph aggregating related entity nodes with a business process as a hyperedge, realizing comprehensive integration of technical and business characteristics, dividing closely associated entity nodes into clusters through feature extraction and clustering with constraints, and forming a micro-service division result, so that the calling and dependency relationship in the technical layer is retained, the integrity of the business process is ensured, the division result is more in line with actual business requirements, and the micro-service division accuracy and delivery efficiency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of servers, and particularly relates to a micro-service division method and an electronic device. BACKGROUND

[0002] Cloud computing and mobile internet promote explosive growth of enterprise business, and systems need higher flexibility, scalability and high concurrency capability. Micro-service architecture becomes mainstream due to "division and autonomy", and through division of the system into independent units, delivery efficiency and stability are improved, but the granularity and boundary of division directly affect system performance, maintenance cost and business continuity. However, the micro-service division scheme in the related art has a dilemma of too fine or too coarse division, resulting in poor division accuracy. SUMMARY

[0003] The present application provides a micro-service division method and an electronic device to at least solve the problem of poor micro-service division accuracy in the related art.

[0004] The present application provides a micro-service division method, including: obtaining multi-dimensional data of an original service, the multi-dimensional data being used to represent source code of the original service, performance in a running process, historical change conditions and semantics of the source code; based on the multi-dimensional data, constructing a multi-layer graph network and a hypergraph, the multi-layer graph network including a plurality of graph layers, the graph layers including a plurality of entity nodes corresponding to the original service and an association relationship between the plurality of entity nodes, the hypergraph including a plurality of hyperedges, the hyperedges indicating entity nodes belonging to a same business process implemented by the original service, the entity nodes being nodes corresponding to functions, classes or interfaces; performing node feature extraction on the multi-layer graph network and the hypergraph to obtain node features of the plurality of entity nodes; based on a preset node constraint condition and the node features of the plurality of entity nodes, clustering the plurality of entity nodes to obtain node cluster information, the node cluster information including a plurality of node clusters and entity nodes contained in the node clusters; based on the node cluster information, generating a micro-service division result, the micro-service division result indicating a plurality of micro-services divided from the original service and entity nodes belonging to the plurality of micro-services.

[0005] The present application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above micro-service division methods.

[0006] The micro-service division method and the electronic device provided by the embodiments of the present application, by obtaining multi-dimensional data such as source code, performance, historical changes and semantics of the source code of the original service, constructing a multi-layer graph network and a hypergraph joint model, the multi-layer graph network presents the association relationship of the entity nodes from multiple dimensions, and the hypergraph aggregates related entity nodes with a business process as a hyperedge, realizing comprehensive integration of technology and business characteristics, through feature extraction and clustering with constraints, closely associated entity nodes are divided into clusters to form a micro-service division result, in this way, both the calling and dependency relationship in the technical layer are retained, and the integrity of the business process is ensured, so that the division result is more in line with actual business requirements, and the micro-service division accuracy and delivery efficiency are improved. BRIEF DESCRIPTION OF DRAWINGS

[0007] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0008] Figure 1 A micro-service division system provided by the embodiments of the present application;

[0009] Figure 2 A flowchart of the micro-service division method provided by the embodiments of the present application Figure 1 ;

[0010] Figure 3 A flowchart of the micro-service division method provided by the embodiments of the present application Figure 2 ;

[0011] Figure 4 A flowchart of obtaining fusion features provided by the embodiments of the present application Figure 1 ;

[0012] Figure 1 A flowchart of obtaining hypergraph features provided by the embodiments of the present application Figure 6 ;

[0013] Figure 1 A flowchart of obtaining node features of entity nodes provided by the embodiments of the present application Figure 7 ;

[0014] Figure 1 A flowchart of generating a micro-service division result provided by the embodiments of the present application Figure 8 ;

[0015] Figure 3 A flowchart of the micro-service division method provided by the embodiments of the present application Figure 9 ;

[0016] Figure 1 A schematic diagram of the process for obtaining unified embedding of nodes provided in the embodiments of this application. Figure 10 ;

[0017] Figure 1 A flowchart illustrating the process of obtaining the final decision provided in this application embodiment. Figure 11 ;

[0018] Figure 12 This is a schematic diagram of the microservice partitioning device provided in an embodiment of this application;

[0019] Figure 1 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

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

[0021] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0022] Cloud computing and mobile internet are driving explosive growth in enterprise businesses, requiring systems with higher flexibility, scalability, and high concurrency capabilities. Microservice architecture has become mainstream due to its "divide and conquer" principle, improving delivery efficiency and stability by dividing the system into independent units. However, the granularity and boundaries of this division directly impact system performance, maintenance costs, and business continuity. However, existing microservice partitioning schemes face the dilemma of being either too fine-grained or too coarse-grained, leading to poor partitioning accuracy. This application provides an adaptive microservice decomposition method based on hypergraph-multi-layer graph joint modeling, which can simultaneously utilize the integrity of the hypergraph and the heterogeneous information of the multi-layer graph, taking into account business integrity, multi-dimensional coupling, and runtime governance, achieving "accurate, fast, stable, and sustainable decomposition." To enable those skilled in the art to better understand this application, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, further illustrates this application.

[0023] This section describes the specific application environment architecture or hardware architecture upon which the microservice partitioning method depends. (References) Figure 1 , Figure 2 A microservice partitioning system is provided, comprising a first server 101 and a second server 102, which establish a communication connection. The first server 101 deploys the original service and stores the corresponding data. The second server 102 retrieves multi-dimensional data of the original service from the first server 101, generates a microservice partitioning result for the original service, and sends the result to the first server 101. This allows the first server 101 to partition the original service based on the partitioning result, obtaining a microservice cluster. Subsequently, the microservice cluster is deployed and its related data is stored.

[0024] Figure 1 A flowchart illustrating the microservice partitioning method provided in this application embodiment. Figure 2 ,like Figure 2 As shown, embodiments of this application provide a microservice partitioning method, which is described in detail below:

[0025] S201. Obtain multidimensional data of the original service. The multidimensional data is used to represent the source code of the original service, its performance during operation, historical changes, and the semantics of the source code.

[0026] In this embodiment, the original service may be a service corresponding to an application or platform, used to provide corresponding services to the application or platform to ensure its normal operation. The original service is a complete service to be partitioned, or a cluster of microservices that has been initially partitioned. Multidimensional data is used to describe the original service from multiple dimensions, and multidimensional data can be represented in any form. By obtaining the multidimensional data of the original service, the original service can be partitioned based on the multidimensional data and combined with the joint modeling method of multi-layer graph network and hypergraph to obtain a more accurate microservice partitioning result. The source code is the code used to implement the operation of the original service. For example, the source code is contained in a source code file. By executing the source code file, the source code can be run, thereby enabling the original service to run. The performance during the operation of the original server can reflect the call situation between various sub-services during the operation of the original service, which can be used as a basis for subsequent microservice partitioning. Historical changes can reflect the modification of the code files or other files corresponding to the original service. The semantics of the source code refers to the semantics related to the class or API (Application Programming Interface) corresponding to the original server.

[0027] S202. Based on multidimensional data, construct a multi-layer graph network and a hypergraph. The multi-layer graph network includes multiple layers, each layer including multiple entity nodes corresponding to the original service and the relationships between multiple entity nodes. The hypergraph includes multiple hyperedges, each hyperedge indicating entity nodes belonging to the same business process implemented by the original service. Entity nodes are nodes corresponding to functions, classes, or interfaces.

[0028] In this embodiment, since multidimensional data can describe the original service from multiple dimensions, a multi-layer graph network is constructed based on the multidimensional data. The multiple layers in the multi-layer graph network correspond one-to-one with the multiple dimensions of the multidimensional data, so that each layer in the multi-layer graph network can reflect the original service described by one dimension of the multidimensional data. This fully illustrates the relationship between the various entity nodes corresponding to the original service in different dimensions, enriching the basis for microservice partitioning. Considering that the implementation of the same business process during the operation of the original service involves multiple different entity nodes, which also reflects the association between different entity nodes, a hypergraph is constructed based on the multidimensional data to fully illustrate the entity nodes involved in implementing each business process. This allows for consideration of the microservices to which related entity nodes belong when partitioning microservices, enriching the basis for microservice partitioning. In the multi-layer graph network, multiple layers correspond to the same entity nodes. In the hypergraph, each hyperedge can connect any number of entity nodes; different hyperedges may contain the same or different numbers of entity nodes. The entity node corresponding to the original service is the node corresponding to the business entity in the original service. The business entity is a method, class, API, or sub-service in the original service. The business process defines a series of actions to be performed in a business process.

[0029] S203. Extract node features from the multi-layer graph network and hypergraph to obtain node features of multiple entity nodes.

[0030] In this embodiment, feature extraction is performed on the multi-layer graph network and hypergraph to fully consider the relationships between various entity nodes in the original service, thereby obtaining the node features of each entity node. These node features can be represented in any form; for example, they can be represented as embedding vectors.

[0031] S204. Based on preset node constraints and node characteristics of multiple entity nodes, cluster the multiple entity nodes to obtain node cluster information, which includes multiple node clusters and the entity nodes contained in the node clusters.

[0032] In this embodiment, considering that different nodes may need different layouts in actual business operations, for example, some entity nodes need to be deployed in the same microservice while some nodes need to be deployed in different microservices, node constraints are pre-set according to actual business needs. In order to combine the node constraints and the node characteristics of multiple entity nodes, multiple entity nodes are clustered to achieve entity node clustering by combining the association between entity nodes and node constraints. The node cluster information obtained by clustering can reflect the situation of entity nodes contained in each node cluster. Entity nodes in the same node cluster can be deployed in the same microservice. Then, multiple node clusters are equivalent to entity nodes corresponding to multiple microservices.

[0033] S205. Based on node cluster information, generate microservice partitioning results. The microservice partitioning results indicate multiple microservices partitioned from the original service and entity nodes belonging to multiple microservices.

[0034] In this embodiment of the application, based on the node clusters indicated by the node cluster information, the entity nodes that can be deployed on each microservice can be determined, and then the microservice partitioning result can be generated according to the node cluster information, so that the microservice partitioning can be performed according to the microservice partitioning result in the future, ensuring that the partitioned microservices can achieve the original service functions while improving delivery efficiency.

[0035] In the solution provided in this application embodiment, multi-dimensional data such as the source code, performance, historical changes, and semantics of the original service are obtained to construct a joint model of multi-layer graph network and hypergraph. The multi-layer graph network presents the relationship between entity nodes from multiple dimensions, and the hypergraph aggregates related entity nodes with business processes as hyperedges to achieve a comprehensive integration of technical and business features. Through feature extraction and constrained clustering, closely related entity nodes are divided into clusters to form microservice partitioning results. In this way, the technical call and dependency relationships are preserved while ensuring the integrity of business processes, making the partitioning results more in line with actual business needs and improving the accuracy and delivery efficiency of microservice partitioning.

[0036] In the above Figure 3 Based on the embodiments shown, this application provides a detailed description of the microservice partitioning process, as detailed in the following embodiments. Figure 2 A flowchart illustrating the microservice partitioning method provided in this application embodiment. Figure 3 ,like Figure 4 As shown, embodiments of this application provide a microservice partitioning method, which is described in detail below:

[0037] S301. Obtain multidimensional data of the original service. Multidimensional data includes code data, link tracing data, historical change data, and semantic data. Code data includes source code, link tracing data is used to represent performance, historical change data is used to represent historical change situations, and semantic information is used to represent the semantics of the source code.

[0038] In this application, multidimensional data consists of multiple data sets, each used to describe the original service from different dimensions. For example, code data refers to the source code files of the original service; trace data refers to trace data automatically generated and reported during the operation of the original service using OpenTelemetry (an open-source observability framework), which includes service names, operation names, call relationships, start / end timestamps, and execution time in the original service; historical change data refers to historical modification records in the Git repository; and semantic data refers to the annotation documentation for classes, APIs, interfaces, methods, etc., in the original service.

[0039] S302. Based on code data, link tracing data, historical change data, and semantic data, construct a multi-layer graph network. The multi-layer graph network includes multiple layers, each containing multiple entity nodes corresponding to the original service and the relationships between these entity nodes.

[0040] In this embodiment of the application, code data, link tracing data, historical change data, and semantic data can describe the original service from different dimensions. Based on these four types of data, a multi-layer graph network is constructed so that each layer in the multi-layer graph network can describe the original service from different dimensions.

[0041] In one possible implementation, step S302 includes: parsing the code data, link tracing data, historical change data, and semantic data respectively to obtain layers corresponding to the code data, link tracing data, historical change data, and semantic data; and overlaying these layers to obtain a multi-layer graph network. In this embodiment, code data, link tracing data, historical change data, and semantic data can describe the original service from different dimensions. Therefore, parsing these four types of data separately allows for a thorough understanding of the original service according to each dimension, resulting in layers corresponding to each dimension. These multiple layers are then overlaid to obtain a multi-layer graph network, ensuring the accuracy of the obtained multi-layer graph network.

[0042] Optionally, the process of obtaining the layer corresponding to the code data includes: identifying multiple business entities and callers among the multiple business entities from the code data, whereby business entities include functions, classes, or interfaces; determining the callee corresponding to the caller from the multiple business entities based on the code data and the caller; and constructing the layer corresponding to the code data based on the multiple business entities, the caller, and the callee. In this embodiment, since the code data includes the source code of the original service, by identifying the code data, the types, methods, or interfaces defined in the source code can be identified from the code data, so as to use them as the business entities corresponding to the original service; by identifying from the code data, the callers among each business entity can also be identified, for example, identifying methods or function calls to other classes, and then determining the callee corresponding to the caller, for example, determining the called class, method, or function. Then, according to the multiple business entities, the callers among the multiple business entities, and the callees, the layer corresponding to the code data is constructed so that the layer can fully illustrate the static call dependency relationships between the various business entities.

[0043] Optionally, the further process of constructing the layer corresponding to the code data includes: determining the number of calls between the caller and the corresponding callee based on the code data; identifying multiple business entities as entity nodes in the layer corresponding to the code data; and constructing the layer corresponding to the code data based on the multiple business entities, the caller, the callee, and the number of calls. In this embodiment, in the source code corresponding to the original service, there may be multiple calls between various classes or methods. Therefore, the number of calls between the caller and the callee is determined based on the code data, and then the layer corresponding to the code data is constructed in combination with the number of calls to fully illustrate the call relationship between the caller and the callee, thereby improving the accuracy of the layer corresponding to the code data. It should be noted that this embodiment is illustrated using the number of calls as an example. In another embodiment, other methods can also be used to represent this. For example, the layer corresponding to the code data can be constructed by combining the caller, the callee, and the call relationship identifier. The call relationship identifier is 0 or 1. When the call relationship identifier is 0, it indicates that there is no call relationship between the two business entities. When the call relationship identifier is 1, it indicates that there is a call relationship between the two business entities.

[0044] Optionally, taking source code files as the code data as an example, the process of obtaining the layer corresponding to the code data includes: parsing the source code file into an AST using Understand or Tree-sitrer; traversing the AST to identify the classes, methods, or functions defined in the code, as well as the call points (i.e., callers) inside the methods; determining the callee (i.e., the target class or target method) for each call point; creating a sparse matrix, where the rows of the sparse matrix represent callers, the columns of the sparse matrix represent callees, and the values ​​in the matrix are the number of calls or call relationship identifiers; and constructing a directed layer based on the sparse matrix, which is the layer corresponding to the code data. In this embodiment, during the process of constructing a directed layer based on the sparse matrix, the sparse matrix is ​​parsed; low-frequency calls are filtered, for example, call relationships with a call frequency less than a threshold, such as a threshold of 3 times per day; and a quality pre-check is performed on the sparse matrix, such as verification of the call frequency distribution (power-law distribution) and detection of isolated nodes (in-degree + out-degree = 0). Next, the graph construction algorithm is implemented: 1) Directed weighted graph construction: Business entities are used as entity nodes, call relationships are used as edges between nodes, and call frequency is used as the edge weight; 2) Hierarchical folding optimization: When the call depth is greater than 5, intermediate entity nodes are folded to solve the graph structure complexity problem caused by deep call chains. A graph traversal algorithm (such as DFS) is used to find a linear path with a length greater than 5. All intermediate entity nodes except the first and last entity nodes on the path are removed, and a new edge is added between the first and last entity nodes, i.e., an aggregate edge is created; the weight of the generated aggregate edge is equal to the sum of the weights of the path, that is, the weight of the new edge is equal to the sum of the weights of all edges on the original path. For example, if the original path A→B→C→D (depth 3) has edge weights of 0.2, 0.3, and 0.1 respectively, then after folding, the generated edge A→D has a weight of 0.2 + 0.3 + 0.1 = 0.6. In this way, the graph complexity is reduced, the number of entity nodes and edges is reduced, key call relationships are highlighted, and analysis interference caused by deep nesting is avoided. 3) Weight normalization: Weight normalization is performed using the following relationship:

[0045]

[0046] in, Used to represent nodes To the node The edge weights after normalization. Used to represent nodes To the node The edge weight is also equivalent to the node weight. To the node The number of times it is called; Used to represent the set of weights for all edges; Used to represent logarithms Used to indicate taking the maximum value.

[0047] In this embodiment, when normalizing the weights according to the above relationship, logarithmic scaling is used to handle the long-tail distribution. For cases with huge differences in call frequency (1 time vs. 100,000 times) and where the original weights exhibit a power law distribution, logarithmic scaling is employed. The original weights are retained as edge attributes, and the normalized weights are used for graph computation. However, the original weights are retained as an edge attribute (e.g., named `raw_weight`) for later scenarios requiring the original values ​​(such as display or detailed analysis). This solves the problem of uneven weight distribution, making the graph algorithm more stable without losing original information and ensuring sufficient flexibility. For example, if the original weight is 1 and the normalized weight is 0.08, the compression rate is 92%; if the original weight is 10 and the normalized weight is 0.25, the compression rate is 75%.

[0048] Optionally, the process of obtaining the layer corresponding to the link tracing data includes: extracting at least one call information from the link tracing data, the call information including the calling service, the called service, the operation, the execution time, and the timestamp; based on the at least one call information, determining at least one service group and the performance parameters corresponding to the at least one service group, the performance parameters indicating the call situation between the calling service and the called service in the same service group; and constructing the layer corresponding to the link tracing data based on the at least one service group and the performance parameters corresponding to the at least one service group. In this embodiment, the link tracing data can reflect the call situation during the operation of the original service. Therefore, at least one call information is extracted from the link tracing data. Each call information can reflect the calling service, the called service, the operation performed, the execution time, the start timestamp or end timestamp, etc., in the original service. Then, performance parameters are calculated to represent the original service, so as to construct the layer corresponding to the link tracing data in combination with the performance parameters, measure the concurrency throughput of the original service, reflect the runtime dynamic relationship between the call frequency and performance of services, so as to fully explain the call relationship and performance during the operation of the original service and ensure the accuracy of the layer corresponding to the link tracing data. The performance parameters can be of any type. For example, performance parameters include QPS (Queries Per Second) and RT (Response Time). QPS is calculated by grouping services by caller and callee, and counting within a sliding time window. For example, the sliding time window might be per second, per 10 seconds, etc., and QPS is calculated as Count (number of calls) / window size (seconds). RT is calculated by grouping services along the same dimension and calculating statistical values ​​within the time window, such as calculating the average RT, taking the 99th percentile of RT, or taking the maximum RT value.

[0049] Optionally, taking trace data as an example, the process of obtaining the layer corresponding to the trace data includes: the application automatically generates and reports trace data during the runtime of the original service by integrating the Open Telemetry SDK (a software development kit for a distributed trace data acquisition and stream processing architecture) or the Open Telemetry Agent (a proxy for a distributed trace data acquisition and stream processing architecture); the trace data is sent to a message queue (such as Kafka) or directly entered into Flink for subsequent real-time processing. During Flink's real-time processing, the trace data is parsed to consume the trace data stream; key information is extracted, such as the calling service, the called service, the operation name, the execution time, and the timestamp; then, the QPS and RT are calculated using aggregation calculation; Flink outputs the real-time streaming aggregation results to form a matrix, where the rows represent the calling service, the columns identify the called service, and the values ​​in the matrix are the QPS and RT. Then, a directed layer with multi-dimensional weights is constructed based on this matrix, thus obtaining the layer corresponding to the trace data. In this embodiment, a directed layer with multi-dimensional weights is constructed based on the matrix: 1) Input processing: QPS / RT monitoring data is converted into a directed graph with multi-dimensional weights. Data is tracked through Open Telemetry, and Flink real-time streams (Kafka Topic) are consumed; window aggregation (5-minute rolling window) is used to segment the continuous data stream into meaningful segments for analysis. In dynamic layer processing, a 5-minute window means calculating key metrics for service calls every 5 minutes. 2) Graph construction algorithm: A multi-dimensional edge attribute approach is adopted. For each service pair, the edges not only have call relationships but also store performance metrics such as RT, P99 (99th percentile response time), and error rate; then, the basic weight QPS is normalized using the following relationship:

[0050]

[0051] in, Used to represent the normalized weights, Used to represent the QPS that is currently to be normalized. Used to represent the minimum QPS within the statistical range, This is used to represent the maximum QPS within the statistical range. In the above relationship, the deviation between the current value and the minimum value... This measures the improvement in QPS relative to the "worst performance" (minimum value); a higher value indicates better current performance. The overall fluctuation range of the data is also considered. , representing the maximum fluctuation range of QPS within the statistical range (i.e., the difference between "best performance" and "worst performance"), serves as the benchmark for normalization; the formula converts any range of QPS into a weight between [0,1] through the calculation of "(current value - minimum value) ÷ total fluctuation range": when QPS = min(QPS), w norm =0 (corresponds to worst performance); when QPS=max(QPS), w norm =1 (corresponding to the best performance). In this embodiment, according to the above relationship, QPS can be mapped to [0,1]. For example, for a service pair including service A and service B, the original QPS is 120, and after normalization it is 0.85; for a service pair including service C and service D, the original QPS is 25, and after normalization it is 0.18. After the above graph construction algorithm, 3) dynamic graph update mechanism is performed: using the time decay model, the weight of the graph changes dynamically with time, reflecting that new data is more important, old data gradually becomes invalid, and the old weight will "exponentially decay" with time, ensuring that the weight of the graph focuses more on "recent data" and reflects the real-time changes of service calls. The time decay model satisfies the following relationship:

[0052]

[0053] in, The weight value used to represent time t, after decay; Used to indicate time The weight value (initial value before decay); e is used to represent the natural constant; λ = 0.1 decay coefficient (10-minute half-life); Used to represent the difference between the current time and the last update time; half-life calculation. , where ln(2): natural logarithm operation (logarithm of 2 to the base e, value is approximately 0.693). After the above dynamic graph update mechanism, 4) anomaly handling strategy: when real-time data shows "outliers" (such as a sudden spike or drop in QPS, which may be a monitoring error / sudden anomaly), it needs to be automatically downgraded to "historical baseline" to avoid abnormal data from damaging the accuracy of the graph. Among them, for outlier detection: the MAD algorithm (median absolute deviation) is used to identify data that "deviations greatly from the historical trend" (such as a sudden jump in QPS from 100 to 10000, which may be an anomaly); then, the historical baseline is calculated: take the data of the same period (±15 minutes) of the past 7 days and calculate the "weighted average" according to the weight: In this way, the weight allocation reflects the principle that "recent data is more important," and the stability of the graph is ensured through automatic degradation: if an outlier is detected, the current weight is directly replaced with the "historical baseline value."

[0054] Optionally, the process of obtaining the layer corresponding to historical change data includes: extracting at least one change record from the historical change data, the change record indicating at least one code file that has undergone a historical change; generating at least one file pair and the common modification count corresponding to the at least one file pair based on the at least one change record, the common modification count corresponding to the file pair indicating the number of change records including the two code files in the file pair; and constructing the layer corresponding to the historical change data based on the at least one file pair and the common modification count corresponding to the at least one file pair. In this embodiment, the change record can reflect the historical changes to the code files, and there may be a relationship between multiple files that have undergone a change. Therefore, by extracting the change record from the historical change data and then determining the common modification count of each file pair according to the change record, the relationship between the file pairs can be reflected by the common modification count, thereby constructing the layer corresponding to the historical change data to ensure the accuracy of the layer. A change may involve multiple code files, and a change corresponds to one change record, where the common modification count for each pair of code files in this change record is 1. By traversing at least one change record in the above manner, the common modification count for each file pair can be obtained.

[0055] Optionally, taking files in a Git repository as examples of historical change data, the process of obtaining the layer corresponding to the historical change data includes: accessing the Git repository and using GitPython / JGit to locate and open the target code repository; obtaining change records from the target code repository within the last 90 days; traversing each change record, and for each change record, extracting a list of modified files, including the modified files indicated by the change record; creating an empty co-modification matrix based on the file list corresponding to the change record; the rows and columns of the matrix are files from the file list corresponding to the change record; traversing the file list corresponding to each change record to determine the number of common modifications for each pair of files; after traversing all change records, the co-modification matrix is ​​obtained, and the values ​​in the co-modification matrix are the number of common modifications for each file pair; then, an undirected weighted graph is constructed based on the co-modification matrix, thus obtaining the layer corresponding to the historical change data. This reflects the logical or functional coupling between different files. Specifically, for a file pair containing two code files, the more common modifications, the closer the relationship between the two code files. In this embodiment, an undirected weighted graph is constructed based on the shared modification matrix: 1) Input processing: The shared modification matrix generated by GitPython includes code files and the number of shared modifications for each pair of code files. 2) Core transformation logic: Using the code files in the shared modification matrix as nodes, edges are constructed between nodes with shared modification relationships. The number of shared modifications between pairs of code files is used as the original weight of the edge. Then, the weights are normalized using the following relationship:

[0056]

[0057] in, Used to represent the weight after edge normalization, used to measure the relative co-modification strength, with a value range of [0,1]; The largest original value among all weights represents the largest number of common modifications. After the core transformation logic described above, 3) Graph structure characteristics: The constructed layer is also equivalent to a symmetric adjacency matrix. The rows and columns in this matrix are the same, representing each code file. In the symmetric adjacency matrix, the weights of file 1 and file 2 are the same as the weights of file 2 and file 1, and the weight of file 1 and itself is 0, meaning that the file will not be modified together with itself.

[0058] Optionally, the process of obtaining the layer corresponding to the semantic data includes: extracting descriptive information of multiple business entities from the semantic data, whereby business entities include functions, classes, or interfaces; performing feature extraction on the descriptive information of the multiple business entities to obtain semantic features of the multiple business entities; determining the similarity between every two business entities based on the semantic features of the multiple business entities; and constructing the layer corresponding to the semantic data based on the multiple business entities and the similarity between every two business entities. In this embodiment, by extracting descriptive information of each business entity from the semantic data, which can fully describe the meaning of the business entity, a similarity calculation method is adopted. Combined with the descriptive information of each business entity, the similarity between each business entity is determined, which can reflect the correlation between the various business entities. This is then used as the basis to construct the layer corresponding to the semantic data, ensuring the accuracy of the layer corresponding to the semantic data. The descriptive information can be represented in any form, for example, in the form of text. The semantic features can be represented in any form, for example, in the form of feature vectors.

[0059] Optionally, taking semantic data as annotation documents as an example, the text description corresponding to each class, method, or interface is determined from the semantic data. For example, the annotation documents of classes or interfaces, the annotation documents of methods, and related interface document fragments are determined. The extracted text is preprocessed to remove irrelevant characters or stop words and to standardize the text. Then, using a pre-trained SBERT, the text corresponding to each class / interface is input into the model, and a fixed-dimensional semantic feature (i.e., embedding vector) is output. Then, for all the semantic features of the obtained text descriptions, the cosine similarity between the semantic features of each pair of text descriptions is calculated. The cosine similarity can measure the similarity of two semantic features in a direction. The value of the cosine similarity is in the range of [-1, 1]. The closer the cosine similarity value is to 1, the more similar the two semantic features are, that is, the more similar the two text descriptions are. Then, each class, method, or interface is used as the row and column of a matrix, and the cosine similarity is used as the value in the matrix to obtain a cosine similarity matrix. An undirected weighted graph is constructed based on the cosine similarity matrix, that is, the layer corresponding to the semantic data is obtained. In this embodiment, during the construction of an undirected weighted graph based on the cosine similarity matrix: 1) Input processing: Input the similarity matrix generated by SBERT; 2) Core transformation logic: Treat each method, class, or interface in the similarity matrix as entity nodes, and construct edges between entity nodes with semantic similarity; Use the cosine similarity between entity nodes as the original value of the edge weights; Then, the edge weights are enhanced using the following relationship:

[0060] in, Used to represent the updated edge weights, which are normalized weights after Sigmoid activation, and have a value range of (0,1). Used to represent similarity value, i.e., the original cosine similarity, its value ranges from [0,1], the larger the value, the more similar the two objects are; This is used to represent the activation function, and its corresponding mathematical expression is: The activation function is used to map any input value to the (0,1) interval and has a "non-linear characteristic of being flat in the middle and steep at both ends". After the above core transformation logic, 3) Graph structure characteristics: There are edges between all nodes in the constructed layer, that is, there is an edge between any two nodes, and the edges with a weight less than 0.3 are removed to obtain the updated layer, that is, the updated layer is the layer corresponding to the semantic data.

[0061] It should be noted that the above embodiment illustrates the construction of multiple layers separately. In another embodiment, the process of constructing multiple layers can be combined. For example, a multi-dimensional data acquisition module obtains the sparse matrix, the matrix corresponding to the link tracing data, the covariance matrix, and the cosine similarity matrix. Then, a multi-layer graph construction module constructs each layer based on the sparse matrix, the matrix corresponding to the link tracing data, the covariance matrix, and the cosine similarity matrix, and superimposes multiple layers to obtain a multi-layer graph network. The main function of the data acquisition module is to understand the static structure and call relationships of the code, and to construct a call relationship matrix of "class-method-table call matrix". The data acquisition module includes an input layer, a processing layer, and an output layer. The processing layer includes a static layer, a dynamic layer, a change layer, and a semantic layer. The characteristics and processing procedures of each layer are as follows: a) Static layer (Understand / Tree-sitter): Examines how the code is written / connected (static structure, call dependencies), used to obtain the sparse matrix as described above; b) Dynamic layer (O Tel + Flink): Examines how the code runs / performs (runtime behavior, performance metrics), used to obtain the matrix corresponding to the link tracing data as described above; c) Change layer (GitPython / jGit): Examines how the code is modified (historical maintenance mode, logical coupling), used to obtain the co-modification matrix as described above; d) Semantic layer (SBERT): Examines what the code says / does (functional semantic similarity of the document description), used to obtain the cosine similarity matrix as described above. The multi-layer construction module's function is to construct a multi-layer graph network containing four independent layers, each layer having one analysis dimension (static calls, dynamic metrics, change coupling, semantic similarity), while maintaining the consistency of node identifiers. The core of the multi-layer graph construction module lies in the unified identification of nodes and the normalization of weights within each layer. Then, it integrates four layers into a single multi-layer graph structure, outputting a JSON file containing node mappings and edge lists for all four layers. The multi-layer graph module includes an input layer, a processing layer, and an output layer. The input layer is used to input sparse matrices, matrices corresponding to link tracing data, covariance matrices, and cosine similarity matrices. It also performs data cleansing, spatiotemporal alignment, and quality baseline establishment on the input data to build a high-quality data foundation. During this process, the input layer performs the following steps: A) Node coverage check: The coverage rate is calculated using a formula to ensure that the alignment of nodes in each layer is >95%. The warning threshold is 95%; if the coverage rate is <95%, a node mapping check is triggered. The error threshold is 85%; if the coverage rate is <85%, the construction process is terminated. This probability satisfies the following relationship:

[0062]

[0063]

[0064]

[0065] in, Used to represent static layer nodes (such as classes or methods). Used to represent dynamic layer nodes (such as services); Used to represent change layer nodes (such as files); Used to represent semantic layer nodes (such as API entities); Used to represent intersection; Used to represent a union; Used to represent a set of nodes that exist simultaneously in four layers; This represents the set of all unique nodes that appear in the four layers. For example, nodes in the static layer include {service A, class B, method C}, nodes in the dynamic layer include {service A, service D}, nodes in the change layer include {file E, file F}, and nodes in the semantic layer include {service A, class B, interface}. .

[0066] B. Data Freshness Verification: Alarms are issued based on the timestamp difference (data acquisition time, graph construction completion time) to ensure dynamic layer data latency is less than 5 minutes. For example, if the latency is 3-4 minutes, an alert strategy is implemented, increasing Flink parallelism; if the latency is 4-5 minutes, a degradation strategy is implemented, skipping integrity checks; if the latency is greater than 5 minutes, an alert strategy is implemented, switching to a backup data source and automatically rolling back to a historical snapshot. C. Matrix Integrity Verification: Based on historical data imputation, missing values ​​are automatically filled. First, missing value type identification is performed through matrix scanning and threshold filtering to identify missing cells (single zero value / null value); then, row and column summation statistics are performed to identify missing rows and columns (entire row / column blank); sliding window detection is used to identify block-like missing values ​​(continuous area blank); and density calculation (non-zero values / total number) is used to identify sparse missing values ​​(randomly scattered null values). Next, hierarchical interpolation is performed. Static hierarchical interpolation is performed by calling the relation matrix to address missing relations using the interpolation method. Dynamic hierarchical interpolation is performed on the QPS / RT matrix to monitor missing data in real time. Finally, a historical data utilization mechanism is implemented, based on historical data warehouses and pattern matching algorithms (such as matrix fingerprints and similarity calculations) to interpolate the matrix integrity.

[0067] After preprocessing the data through the input layer in the multi-layer construction module, the processing layer in the multi-layer construction module processes the sparse matrix, the matrix corresponding to the link tracing data, the covariance matrix, and the cosine similarity matrix in the manner described above to construct each layer. Then, the processing layer adopts cross-layer integration technology: 1) First, the layers are aligned to align the nodes in the layers. For example, a mapping rule engine is used, such as mapping file name similarity to class name, mapping API document keywords to service name, etc.; or, special marking of unmatched nodes is adopted. When a mismatch is detected, automatic mapping is attempted first. If successful, the mapping is updated. Otherwise, a mark and notification are given for manual review and rule recording. For non-matched static layers, the bridging method connects to the system entry point, with a weight rule of w = 0.3 × system average. For non-matched dynamic layers, the bridging method connects to the gateway node, with a weight rule of w = 50% of the nearest neighbor average. For non-matched change layers, the bridging method connects to the version control node, with a weight rule of w = 0.1 (fixed). For non-matched semantic layers, the bridging method connects to the knowledge graph root, with a weight rule of w = 0.05 (fixed). Cross-layer node verification is also performed to check whether a static layer node has a dynamic layer mapping. If so, all edges are created; otherwise, it is marked as an isolated node. 2) Weight Unification Framework: For static layers, a logarithmic scaling normalization method is used with a threshold of [0,1], retaining the original call count as the attribute; for dynamic layers, a Z-score normalization method is used with a threshold of [-3,3], retaining QPS / RT / P99 as the attributes; for change layers, a Min-Max normalization method is used with a threshold of [0,1], retaining the total number of modifications as the attribute; for semantic layers, a Sigmoid normalization method is used with a threshold of (0,1), retaining the original similarity as the attribute. 3) Sparse Storage Optimization: Hierarchical adjacency list storage and CSR format compression are adopted, such as storage by node pointers (sorted by global node ID) or by edge list (target, weight); this reduces memory usage and improves computational efficiency through sparse storage. Finally, the output layer in the multi-layer construction module belongs to a multi-layer graph network, which can be represented in the form of a MultiG.json structure.

[0068] S303. Based on link tracing data, construct a hypergraph. The hypergraph includes multiple hyperedges, which indicate entity nodes belonging to the same business process.

[0069] In this embodiment, tracing data reflects the entity nodes involved in implementing each business process. Therefore, a hypergraph is constructed based on the tracing data to illustrate the entity nodes involved in each business process, thereby reflecting the relationships between these entity nodes. The hypergraph treats a complete business use case (i.e., a business process) as an indivisible edge. Through distributed tracing and hypergraph modeling, business use cases (rather than individual call pairs) are used as the basic building blocks (hyperedges) of the hypergraph, which is closer to the requirements of business semantics and integrity.

[0070] In one possible implementation, step S303 includes: extracting operation information corresponding to at least one business process and the occurrence count of at least one business process from the link tracing data, wherein the operation information indicates the operation performed when implementing the business process; traversing the operations in the link tracing data to determine the service to which the operation belongs; constructing a hyperedge by assigning the service to which the operation belongs in the operation information corresponding to the same business process, and determining the occurrence count of the business process as the weight of the hyperedge corresponding to the business process to obtain a hypergraph. In this embodiment, based on the link tracing data, an operation identification method is adopted to determine the operations involved in the business process, thereby determining the services involved in each business process, and combining the occurrence count of the business process to construct a hypergraph to enrich the content contained in the hypergraph and improve the accuracy of the hypergraph. Here, the occurrence count refers to the number of times the business process occurs. Here, the hyperedge represents a set of nodes, not a call sequence.

[0071] Optionally, a hypergraph is constructed using a hypergraph construction module. The process of constructing the hypergraph includes: extracting key information from the input Trace logs using the hypergraph construction module; grouping all Spans belonging to the same business use case by Trace ID; traversing all Spans in the Trace; extracting the service node identifier represented by each Span (usually a service name, host / instance identifier, or a more granular component name); deduplicating the service node identifier represented by each Span in the Trace so that the same service may be called multiple times in the Trace (recursive calls, loop calls), but only the node is recorded once in the hyperedge; constructing a hyperedge and assigning the deduplicated set of nodes to the hyperedge; and calculating the weight of the hyperedge based on the number of calls corresponding to each hyperedge, where the weight of the hyperedge is (w(h) = 1 / number of calls). The number of calls refers to the total number of times the specific business use case (i.e., the use case type represented by the Trace) occurs within the sampling period. The hypergraph, constructed from hyperedges and their weights, is then output. This hypergraph can be represented in hMETIS / KaHyPar format. When extracting key information, it identifies each operation (Span) based on the Trace ID representing a complete business call chain. It identifies all operational units constituting the Trace (typically services, functions, database calls, etc.) and also extracts Span Relationships, i.e., the parent-child / follower relationships between Spans, for reconstructing the call tree. The essence of the weight design lies in… This cleverly transforms the execution frequency of business use cases into the importance of maintaining their integrity during partitioning. Low-frequency critical business processes are given more "protection" in the partitioning process.

[0072] It should be noted that the embodiments of this application take multidimensional data including multiple types of data as an example, and on this basis, different data are used to construct multi-layer graph networks or hypergraphs. In another embodiment, multidimensional data can be used in other ways to indicate the source code of the original service, its performance during operation, its historical changes and business meaning; thus, multi-layer graph networks and hypergraphs can be constructed based on multidimensional data in other ways.

[0073] S304. Extract features from multiple layers in a multilayer graph network to obtain the layer features corresponding to each layer.

[0074] In this embodiment of the application, feature extraction is performed on each layer in the multi-layer graph network to obtain the layer features corresponding to each layer, so that the layer features of each layer can reflect the features of each entity node.

[0075] In one possible implementation, step S304 includes: for each layer in the multi-layer graph network, feature extraction is performed on the layer based on the intra-layer attention mechanism to obtain the layer features corresponding to the layer. In this embodiment, meta-path design (e.g., static → dynamic: code entity → service mapping, change → semantic: file → document association) guides attention learning, enabling the model to understand the "business association between nodes in different layers". Optionally, feature extraction is performed on each node in the layer to obtain the node features of each node; then, for each node in the layer, the attention weight of the node to its neighboring nodes is determined based on the intra-layer attention mechanism; then, based on the attention weights and node features of each neighboring node, the current node is weighted and fused to obtain the updated features of the node. It should be noted that the above is only an example of updating a certain node. In another embodiment, each node in the layer can be updated in the above manner to obtain the layer features corresponding to the layer. The attention weights of the node to its neighboring nodes satisfy the following relationship:

[0076]

[0077] in, Used to represent nodes Attention weights for node j Used to represent learnable attention vectors; Used to represent the characteristic transformation matrix The feature vector used to represent node i; The feature vector used to represent node j The feature vector used to represent node k; Used to represent the set of neighboring nodes of node i. Used to represent vector concatenation operations; Used to represent activation functions.

[0078] S305. Perform weighted fusion of the layer features corresponding to multiple layers to obtain the fused features.

[0079] In this embodiment, after obtaining the layer features corresponding to each layer, the layer features corresponding to multiple layers are weighted and fused to obtain fused features. This fully considers the correlation between different layers to ensure the accuracy of the fused features. For example, the process of obtaining fused features is as follows: Figure 5 As shown.

[0080] S306. Perform feature extraction on the hypergraph to obtain hypergraph features.

[0081] In this embodiment, the hypergraph features can characterize the relationships between nodes in the hypergraph. Each hyperedge in the hypergraph includes at least 3 nodes. For each hyperedge, hypergraph convolution is performed to obtain the hypergraph features, ensuring the accuracy of the hypergraph. The hypergraph convolution formula satisfies the following relationship:

[0082]

[0083] Where Dv represents the node degree matrix; De represents the hyperedge degree matrix; H represents the hypergraph association matrix; θ represents the learnable parameters; and W is the edge weight matrix. and These are node representations from two different layers; It is a learnable parameter matrix. For example, the process of obtaining hypergraph features is as follows: Figure 6 As shown.

[0084] S307. The fused features are concatenated with the hypergraph features to obtain the concatenated features.

[0085] In this embodiment, a feature fusion technique is employed. First, the fused features corresponding to the multi-layer graph network are concatenated with the hypergraph features. Then, based on an MLP (Multi-Layer Perceptron), the concatenated features are fused to obtain the node features of each entity node, ensuring the accuracy of the node features. The MLP architecture satisfies the following relationship:

[0086]

[0087] Where Z represents the node features of each entity node; W1 and W2 represent the learnable weight matrices; b1 and b2 represent the biases; hHAN represents the hypergraph features; and hHyperGCN represents the fused features. ReLU is used to represent concatenation; ReLU is used to represent the activation function. The introduction of non-linearity through ReLU activation allows the model to learn more complex fusion rules. In this embodiment, the Multiplex-Hyper Graph Embedding (MHGE) algorithm is used to solve the problem of heterogeneous information fusion in multi-layer networks; nodes are mapped to a unified low-dimensional vector space, preserving intra-layer and inter-layer structural information, thus solving the problem of heterogeneous information fusion in multi-layer networks; and HAN (Heterogeneous Graph Attention) is used to perform inter-layer attention on the multi-layer graph to fully consider the correlation between different layers.

[0088] S308. Perform a linear transformation on the splicing features to obtain the node features of multiple entity nodes.

[0089] In this embodiment, the dimension of the node features is controlled during linear transformation. For example, the input dimension is 1024 and the output dimension is 512 to achieve feature compression; the input dimension is 512 and the output dimension is 256 to achieve information extraction; the input dimension is 256 and the output dimension is 128 to achieve final embedding, i.e., the obtained node features are 128-dimensional vectors. For example, the process of obtaining the node features of each entity node is as follows: Figure 7 As shown. It should be noted that the embodiments of this application are illustrated by taking the method of feature extraction, feature concatenation and linear transformation of multi-layer graph networks and hypergraphs to obtain node features. In another embodiment, it is not necessary to perform the above steps S304-S308. Instead, other methods are used to extract features from multi-layer graph networks and hypergraphs to obtain node features of multiple entity nodes.

[0090] S309. Based on the list of nodes in the same cluster and compliance boundary constraints, multiple entity nodes are divided to obtain at least one node cluster, and the node cluster includes at least one entity node.

[0091] In this embodiment, node constraints include a list of node pairs within the same cluster, a list of isolated node pairs, and compliance boundary constraints. The list of node pairs within the same cluster indicates node pairs belonging to the same node cluster, while the list of isolated node pairs indicates node pairs belonging to different node clusters. The compliance boundary constraints indicate the clustering method of entity nodes that meet the conditions. The list of node pairs within the same cluster can be constrained using a must-link approach; for example, payment transaction-related classes need to be set in the same cluster. The list of isolated node pairs can be constrained using a cannot-link approach; for example, modules maintained by different teams need to be isolated and can be set in different clusters. The compliance boundary constraints are used to set special labels for certain nodes, constraining them using a compliance boundary approach; for example, GDPR requires user privacy data-related modules (such as UserInfoService) to be isolated from other business modules. Based on the list of node pairs within the same cluster and the compliance boundary constraints, multiple entity nodes are divided to obtain at least one node cluster. These node clusters are equivalent to the initialized node clusters, ensuring that the divided node clusters meet the preset requirements and guaranteeing the accuracy of the node clusters.

[0092] S310. Based on the node characteristics of multiple entity nodes, calculate the modularity gain of moving the target entity node from its current node cluster to another node cluster. The target entity node is any one of the multiple entity nodes.

[0093] In this embodiment, given at least one node cluster, each node cluster can be updated based on its node characteristics to maximize modularity. This is achieved through iterative "node movement (transferring a node to a neighboring node cluster) → calculating the modularity gain ΔQ. If the modularity gain ΔQ > 0, the node is moved, ultimately making the edges within each node cluster denser and the edges between node clusters sparser, thus partitioning microservices. To ensure the algorithm conforms to "business-mandated rules," COP-Louvain modifies the modularity gain and node movement logic: for the list of nodes within the same cluster, preprocessing node merging is performed based on Must-Link. "Must-link" nodes must belong to the same node cluster; for example, "payment transaction related classes" must be split into the same microservice. Before the algorithm starts, "must-link node pairs" are preprocessed and merged to "logically treat these nodes as a whole" (equivalent to "supernodes"). During subsequent "node movement" processes, these "supernodes" are treated as individual nodes, thus forcing them to always remain in the same node cluster. Modularity gain is a core metric for measuring the quality of node cluster partitioning in a graph structure, used to evaluate the "density of node associations within a node cluster" and the "sparseness of node associations between node clusters."

[0094] S311. Update the modularity gain based on the list of isolated nodes.

[0095] In this embodiment, for the isolated node pair list, "Cannot-linked" nodes must belong to different node clusters. For example, modules maintained by different teams must be split into different microservices. Cannot-link constraints are adopted to add a "penalty term" to the modularity gain calculation; the calculation method of "modularity gain ΔQ" is modified by introducing a penalty term to make node movement behavior that "violates the Cannot-link constraint" "unprofitable." The optimized objective function changes as follows:

[0096]

[0097] in, Used to represent the updated modularity gain; The variable λ represents the "pure technical modularity change" (the benefit without constraints) brought about by node movement; λ represents the penalty coefficient, the larger the value, the higher the cost of violating the constraints. Used to indicate indicator functions; Used to represent the total number of Cannot-link constraints.

[0098] S312. Based on the updated modularity gain, update the node cluster to which the target entity node belongs.

[0099] In this embodiment, the module degree is updated based on the target entity node's modified module degree gain after moving from its current node cluster to another node cluster. If the updated module degree gain is greater than 0, the target entity node is moved from its current node cluster to another node cluster to update the node cluster. If the updated module degree gain is less than or equal to 0, the node cluster to which the target entity node belongs remains unchanged. It should be noted that the target entity node is only any node in multiple node clusters. By updating the node cluster to which each node belongs in the above manner, the updated node clusters can be obtained, thus updating the node cluster information. In this embodiment, during the process of updating node clusters in the above manner, if the module degree no longer increases after all entity nodes are moved, the supernode is folded, that is, the node cluster is treated as a new node, and the next iteration begins, until the algorithm converges.

[0100] It should be noted that the embodiments of this application are illustrated by taking the node constraint conditions including the list of nodes in the same cluster, the list of isolated nodes, and compliance boundary constraints as an example. In another embodiment, it is not necessary to perform the above steps S309-S312. Instead, other methods are adopted to cluster multiple entity nodes based on the node constraint conditions and the node characteristics of multiple entity nodes to obtain node cluster information. The node cluster information includes multiple node clusters and the entity nodes contained in the node clusters.

[0101] S313. Based on a multi-objective optimization strategy, update the node cluster information. The multi-objective optimization strategy is used to optimize the dependency and interaction costs between microservices, optimize the microservice partitioning and the responsibilities of the teams to which they belong, and optimize the difference between the current partitioning result and the ideal partitioning result.

[0102] In this embodiment, the core objective of microservice decomposition is to achieve a "high cohesion, low coupling" architectural design, while also considering team collaboration efficiency and long-term system evolution capabilities. After treating classes and services as nodes and obtaining an initial cluster structure through clustering, the aforementioned multi-objective optimization model, starting from three key dimensions—architectural coupling, team collaboration efficiency, and system evolution stability—guides iterative optimization of the cluster structure through a combination of quantitative indicators and optimization objectives, ultimately yielding a more reasonable microservice decomposition scheme. A multi-objective optimization strategy is pre-set to define various optimization objectives. Based on this strategy, the node cluster information is updated so that the updated information indicates each node cluster that conforms to the multi-objective optimization strategy. Specifically, cross-service transaction count focuses on "low coupling" at the architectural level, reducing dependencies and interaction costs between services; team cross-domain capability focuses on "collaboration efficiency" at the organizational level, aligning service decomposition with team responsibility boundaries; and future drift risk focuses on "stability" at the evolution level, reducing deviations between the decomposition scheme and the long-term ideal architecture. The three objectives need to be optimized simultaneously, and a "Pareto optimal solution" (i.e. a solution that cannot improve any objective without worsening the other objectives) needs to be found through multi-objective optimization algorithms (such as NSGA-II, MOEA / D, etc.).

[0103] The calculation method for cross-service transaction count is as follows: Where T represents the set of all transactions; t represents a single transaction; C t Represents the set of clusters involved in transaction t; |C t | indicates the number of clusters involved in the transaction; the optimization direction for cross-service transaction count is to minimize it. The team cross-domain degree is calculated as follows: ,in, This represents a set of team-specific nodes. The set is used to represent all nodes in the system; |•| is used to represent the cardinality (number of elements) of the set. The optimization direction for team cross-domain degree is to minimize it. The calculation method for future drift risk is as follows: ,in, Represent the current and ideal cluster structures, respectively; ‖•‖ 嵌入 This represents the distance metric (cosine distance) in the embedding space, and the optimization direction for future drift risk is to minimize it.

[0104] In this embodiment, Pareto front generation is a key step in multi-objective optimization, used to find the optimal set of compromise solutions among multiple conflicting objectives (such as the number of cross-service transactions in microservice decomposition, team cross-domain degree, and future drift risk). 1) Candidate clusters are generated by using constraint space sampling and cluster mutation; for example, using the Louvain algorithm with resolution parameters r∈[0.5,1.5], such as r=0.8 can divide into 40 microservice clusters, and r=1.2 can divide into 25 clusters. Constraints guide mutation; if the random mutation is less than 0.3, Must-link guides merging; otherwise, Cannot-link guides splitting, and constraint repair is returned. For example, constraint-guided mutation is adopted. If the random mutation is less than 0.3, Must-link guides merging; otherwise, Cannot-link guides splitting, returning to constraint repair. The mutation operation is used to adjust the existing cluster partitions and explore new possibilities. A smart sampling strategy is adopted, with 40% random mutation (exploring new regions) used to explore new, untouched solution space regions, increasing the diversity of solutions; 30% domain search (local optimization) is used to perform local optimization around the currently better cluster partitions, fine-tuning existing solutions and improving solution quality; and 30% elite retention (maintaining the best) retains the previously obtained optimal cluster partitions to prevent excellent solutions from being lost during evolution, ensuring that the algorithm can converge to a good result. 2) Target space mapping: This step maps the candidate cluster schemes to a target space composed of three optimization objectives (number of cross-service transactions, team cross-domain degree, and future drift risk), and normalizes it for subsequent comparison and processing. The three-dimensional objective calculation is: according to the formula in the multi-objective optimization part, the number of cross-service transactions f1, team cross-domain degree f2, and future drift risk f3 of each candidate cluster scheme are calculated respectively. The normalization process employs the typical Min-Max standardization method, as shown in the following formula:

[0105]

[0106] in, Used to represent the normalized index value; Used to represent the original index value, Used to represent indicators The minimum value, Used to represent indicators The maximum value.

[0107] 3) Non-dominated sorting: This step sorts the candidate solutions in the target space, distinguishing solutions of different "levels" and finding the "frontier" solutions that are not dominated by other solutions. Dominance determination: For two solutions s and s′, if s is not inferior to s′ on all objectives and is superior to s′ on at least one objective, then s is said to dominate s′. A non-dominated solution is a solution that is not dominated by any other solution. Hierarchical sorting algorithm: Find the first-level non-dominated solutions (the best level) from all solutions, then find the second-level non-dominated solutions from the remaining solutions, and so on, completing the hierarchical sorting of all solutions. Sorting optimization technique: The crowding degree calculation algorithm is used to calculate the crowding degree of solution s. It represents the difference between adjacent solutions at the i-th objective. Crowding reflects the "density" of solutions in the objective space. Higher crowding indicates fewer surrounding solutions and a sparser distribution of solutions, which helps maintain solution diversity. Elite retention strategy: During sorting, prioritize higher-level frontiers (i.e., solutions with lower levels and better performance); for solutions at the same level, prioritize solutions with higher crowding. This preserves excellent solutions while maintaining solution diversity and preventing the algorithm from prematurely converging to a local optimum. The crowding calculation algorithm satisfies the following relationship:

[0108]

[0109] in, Used to represent the congestion of solution s; i is the index of the target; Used to represent adjacent solutions for the i-th objective ( and The difference between the objective function values; Used to represent the maximum value of the i-th objective function; Used to represent the minimum value of the i-th objective function; Used to represent the next adjacent solution of solution s in the target space; This is used to represent the previous adjacent solution of solution s in the target space.

[0110] 4) Front Extraction: This step extracts the Pareto front solutions from the sorted solutions, which are the best, non-dominant set of solutions. Front Definition: Where ≺ represents dominance, and P is the Pareto front, containing all non-dominated solutions. Extraction strategies: Strict front: When there are many high-quality candidate solutions, extracting 5-10 solutions is sufficient; these are the best front solutions. Relaxed front: When there are few candidate solutions, to obtain more valuable solutions, the extraction range is extended to the second-level front solutions. Balanced sampling: When good solution diversity is required, solution points are selected evenly according to the distribution of the target space. Front optimization techniques: Target weight preferences are used to calculate the comprehensive score. By assigning weights to different targets (here, the number of transactions is weighted at 0.4, and cross-domain degree and drift risk are each weighted at 0.3), the front solutions can be weighted and sorted according to actual needs (such as focusing more on reducing the number of transactions or focusing more on reducing drift risk), selecting solutions that meet specific preferences. Clustering dimensionality reduction: K-means clustering is performed on the front solutions. Similar solutions are clustered into a single class, and then a representative solution is selected from each class. This reduces the number of solutions while maintaining diversity, facilitating subsequent analysis and selection. Through these steps, a Pareto front is generated, providing multiple optimal trade-offs for microservice decomposition, allowing decision-makers to choose according to their specific needs. The formula for the objective weight preference is as follows:

[0111]

[0112] in, The final comprehensive score is the target weight preference. Used to represent the weight vector, corresponding to the weights of the number of transactions, cross-domain degree, and drift risk, respectively; It is the normalized value of the i-th indicator.

[0113] S314. Based on the updated node cluster information, generate microservice partitioning results. The microservice partitioning results indicate multiple microservices partitioned from the original service and entity nodes belonging to multiple microservices.

[0114] In this embodiment, node cluster information indicates the nodes contained in each node cluster. Each node cluster can be divided into a microservice, and therefore, multiple microservices can be divided based on the node cluster information, thus obtaining the microservice partitioning result. In one possible implementation, such as... Figure 8As shown, starting from the optimal solution for microservice architecture (Pareto optimal solution), the microservice partitioning results are generated through an architecture resolver, repository scaffolding generation, database splitting, API facade generation, and deployment orchestrator, resulting in runnable code. The architecture resolver takes Pareto deconstruction as input and uses intelligent resolution techniques to rebuild dependencies and detect boundary conflicts (circular dependency identification, cross-cluster strong coupling warning). The repository scaffolding generation employs an intelligent generation process to achieve template matching (selecting a base template based on node type, e.g., selecting the Spring Web template for Web services), dependency injection (injection in the pom file), and configuration optimization (e.g., thread pool size). The database vertical splitter is an intelligent splitting engine that performs data lineage analysis, tracks table and service mapping relationships, identifies shared tables, and selects splitting strategies. Dedicated tables can be directly split, shared tables require dual-write synchronization, and related tables require foreign key conversion. Data consistency is ensured by generating incremental migration scripts and automatically adding validation triggers. The API compatibility facade generation uses intelligent adaptation technology to generate compatible API facades, ensuring that externally called APIs function correctly before and after microservice splitting. Semantic Preservation Transformation: Automatically maps API parameters and transforms response structures, allowing callers to adapt to new microservice architectures with minimal code modifications. Traffic Routing: Routes external requests to the correct microservices. Circuit Breaking and Degradation: Implements circuit breaking and degradation mechanisms when microservices fail, ensuring the stability of the entire system.

[0115] It should be noted that the embodiments of this application are illustrated by taking the generation of microservice partitioning results after updating the node cluster information. In another embodiment, it is not necessary to perform the above steps S313-S314. Instead, other methods are adopted to generate microservice partitioning results based on node cluster information.

[0116] In the solution provided in this application embodiment, multi-dimensional data such as the source code, performance, historical changes, and semantics of the original service are obtained to construct a joint model of multi-layer graph network and hypergraph. The multi-layer graph network presents the relationship between entity nodes from multiple dimensions, and the hypergraph aggregates related entity nodes with business processes as hyperedges to achieve a comprehensive integration of technical and business features. Through feature extraction and constrained clustering, closely related entity nodes are divided into clusters to form microservice partitioning results. In this way, the technical call and dependency relationships are preserved while ensuring the integrity of business processes, making the partitioning results more in line with actual business needs and improving the accuracy and delivery efficiency of microservice partitioning.

[0117] It should be noted that the above embodiments are illustrated using microservice splitting as an example. In another embodiment, after splitting microservices, data can be continuously collected during the operation of the microservice cluster to perform drift detection and rollback merging, ensuring the operational performance of the microservice cluster. This application provides an adaptive microservice splitting method based on hypergraph-multi-layer graph joint modeling. This method can simultaneously utilize hypergraph integrity and multi-layer graph heterogeneous information, and supports online drift detection and rollback for microservice splitting. It balances business integrity, multi-dimensional coupling, and runtime governance, achieving "accurate splitting, fast splitting, stable splitting, and sustainable splitting." Through two technical routes—hypergraph-multi-layer graph joint modeling and runtime adaptive governance—microservice splitting is upgraded from a "one-time static algorithm" to a fully lifecycle-based, observable, and rollback-enabled automated architecture governance platform. This platform includes a multi-dimensional data collection module, a multi-layer construction module, a hyperlayer construction module, an MHGE joint embedding module, a clustering decision & constraint engine module, and a code generation & drift governance module, such as... Figure 9 As shown, the method includes: collecting four types of data—static, dynamic, change-related, and semantic—through a multi-dimensional acquisition module; constructing a multi-layer graph and hypergraph joint model through a multi-layer construction module and a hyper-layer construction module; obtaining unified node embedding using the MHGE algorithm through an MHGE joint embedding module; performing constrained clustering based on the embedding results and constraints through a clustering decision & constraint engine module, outputting a splitting scheme; and continuously collecting data during runtime through a code generation & drift governance module, performing drift detection and rollback merging. The MHGE joint embedding module employs the following methods: Figure 10 The process shown is used to obtain the unified embedding of nodes. The clustering decision & constraint engine module adopts the following approach: Figure 11 The process shown is used to obtain the final decision. Through the above description of the implementation methods, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented using software plus necessary general-purpose hardware platforms. Of course, they can also be implemented using hardware, but in many cases the former is a better implementation method.

[0118] Figure 12 This is a schematic diagram of the microservice partitioning device provided in an embodiment of this application. Figure 12As shown, embodiments of this application also provide a microservice partitioning apparatus, which includes: an acquisition module 1101, used to acquire multidimensional data of the original service, the multidimensional data representing the source code of the original service, its performance during operation, historical changes, and the semantics of the source code; and a construction module 1102, used to construct a multi-layer graph network and a hypergraph based on the multidimensional data, the multi-layer graph network including multiple layers, each layer including multiple entity nodes corresponding to the original service and the relationships between the multiple entity nodes, and the hypergraph including multiple hyperedges, the hyperedges indicating entity nodes belonging to the same business process implemented by the original service, and entity nodes... The nodes are those corresponding to functions, classes, or interfaces; the extraction module 1103 is used to extract node features from the multi-layer graph network and hypergraph to obtain node features of multiple entity nodes; the clustering module 1104 is used to cluster multiple entity nodes based on preset node constraints and node features of multiple entity nodes to obtain node cluster information, which includes multiple node clusters and the entity nodes contained in the node clusters; the generation module 1105 is used to generate microservice partitioning results based on the node cluster information, which indicates multiple microservices partitioned from the original service and the entity nodes belonging to the multiple microservices. For a description of the features in the embodiment corresponding to the microservice partitioning device, please refer to the relevant descriptions in the embodiment corresponding to the microservice partitioning method, which will not be repeated here.

[0119] ​ A schematic diagram of the structure of the electronic device provided in this application. ​ As shown, the electronic device 1200 provided in this embodiment includes at least one processor 1201 and a memory 1202. Optionally, the electronic device 1200 further includes a communication component 1203. The processor 1201, memory 1202, and communication component 1203 are connected via a bus. In specific implementation, at least one processor 1201 executes computer execution instructions stored in the memory 1202, causing at least one processor 1201 to execute the microservice partitioning method embodiment described above. The specific implementation process of the processor 1201 can be found in the above method embodiment, and its implementation principle and technical effects are similar; therefore, it will not be repeated here.

[0120] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the microservice partitioning method embodiments described above at runtime.

[0121] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0122] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the microservice partitioning method embodiments described above.

[0123] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the microservice partitioning method embodiments described above.

[0124] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0125] The microservice partitioning method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A microservice partitioning method, characterized in that, The method includes: Obtain multidimensional data of the original service, which is used to represent the source code of the original service, its performance during operation, historical changes, and the semantics of the source code; Based on the multidimensional data, a multi-layer graph network and a hypergraph are constructed. The multi-layer graph network includes multiple layers, each layer including multiple entity nodes corresponding to the original service and the association relationships between the multiple entity nodes. The hypergraph includes multiple hyperedges, each hyperedge indicating an entity node belonging to the same business process implemented by the original service. The entity node is a node corresponding to a function, class, or interface. Node features are extracted from the multilayer graph network and the hypergraph to obtain the node features of the multiple entity nodes; Based on preset node constraints and node characteristics of the multiple entity nodes, the multiple entity nodes are clustered to obtain node cluster information, which includes multiple node clusters and the entity nodes contained in the node clusters. Based on the node cluster information, a microservice partitioning result is generated, which indicates multiple microservices partitioned from the original service and the entity nodes belonging to the multiple microservices.

2. The method according to claim 1, characterized in that, The multidimensional data includes code data, link tracing data, historical change data, and semantic data. The code data includes the source code, the link tracing data represents the performance, the historical change data represents the historical change status, and the semantic data represents the semantics of the source code. The construction of a multi-layer graph network and a hypergraph based on the multidimensional data includes: Based on the code data, the link tracing data, the historical change data, and the semantic data, the multi-layer graph network is constructed. The hypergraph is constructed based on the link tracing data.

3. The method according to claim 2, characterized in that, The construction of the multi-layer graph network based on the code data, the link tracing data, the historical change data, and the semantic data includes: The code data, the link tracing data, the historical change data, and the semantic data are parsed respectively to obtain the layers corresponding to the code data, the link tracing data, the historical change data, and the semantic data. The multi-layer graph network is obtained by overlaying the layers corresponding to the code data, the link tracing data, the historical change data, and the semantic data.

4. The method according to claim 3, characterized in that, The code data is parsed to obtain the corresponding layer, including: Identify multiple business entities and the callers among the multiple business entities from the code data; the business entities include functions, classes, or interfaces. Based on the code data and the caller, the callee corresponding to the caller is determined from the plurality of business entities; Based on the multiple business entities, the caller, and the callee, a layer corresponding to the code data is constructed.

5. The method according to claim 3, characterized in that, The link tracing data is parsed to obtain the corresponding layer, including: Extract at least one call information from the link tracing data, the call information including the caller service, the callee service, the operation, the time consumption, and the timestamp; Based on the at least one call information, at least one service group and the performance parameters corresponding to the at least one service group are determined. The performance parameters indicate the call situation between the caller service and the callee service in the same service group. Based on the at least one service group and the performance parameters corresponding to the at least one service group, a layer corresponding to the link tracing data is constructed.

6. The method according to claim 3, characterized in that, The historical change data is parsed to obtain the layer corresponding to the historical change data, including: Extract at least one change record from historical change data, the change record indicating at least one code file that was changed in the past; Based on the at least one change record, at least one file pair and the common modification count corresponding to the at least one file pair are generated, wherein the common modification count corresponding to the file pair indicates the number of change records for the two code files in the file pair; Based on the at least one file pair and the number of common modifications corresponding to the at least one file pair, a layer corresponding to the historical change data is constructed.

7. The method according to claim 3, characterized in that, The semantic data is parsed to obtain the corresponding layer, including: Descriptive information of multiple business entities is extracted from the semantic data, and the business entities include functions, classes or interfaces; Feature extraction is performed on the description information of the multiple business entities to obtain the semantic features of the multiple business entities; Based on the semantic features of the multiple business entities, the similarity between each pair of business entities is determined; Based on the multiple business entities and the similarity between each pair of business entities, a layer corresponding to the semantic data is constructed.

8. The method according to claim 2, characterized in that, The construction of the hypergraph based on the link tracing data includes: Extract at least one operation information corresponding to a business process and the number of times the at least one business process occurs from the link tracing data, wherein the operation information indicates the operation performed when the business process is implemented; Traverse the operations in the link tracing data to determine the service to which the operation belongs; The services to which the operations belong in the operation information corresponding to the same business process are formed into a hyperedge, and the number of times the business process occurs is determined as the weight of the hyperedge corresponding to the business process, thus obtaining the hypergraph.

9. The method according to any one of claims 1 to 8, characterized in that, Before generating the microservice partitioning result based on the node cluster information, the method further includes: Based on a multi-objective optimization strategy, the node cluster information is updated. The multi-objective optimization strategy is used to optimize the dependency and interaction costs between microservices, optimize the microservice partitioning and the responsibilities of the teams to which they belong, and optimize the difference between the current partitioning result and the ideal partitioning result. The process of generating microservice partitioning results based on the node cluster information includes: The microservice partitioning result is generated based on the updated node cluster information.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the microservice partitioning method as described in any one of claims 1 to 9 when executing the computer program.

Images