Framework migration method and system for heterogeneous microservice architecture

Abstract

The application provides a framework migration method and system of a heterogeneous micro-service architecture, relates to the technical field of micro-service architecture, and comprises the following steps: determining a migration priority through topological sorting based on service call characteristics, generating a unified service interface description file, injecting a link tracking probe, and realizing service adaptation layer code generation; combining a variation gradient token bucket algorithm to perform flow control, and adopting an exponential backoff algorithm and a sliding time window mechanism to realize service fusing and degradation. The application solves the problems of complex service dependence and difficult flow regulation in the migration of a heterogeneous architecture, improves the safety and stability of framework migration, and reduces system operation and maintenance costs.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture technology, and in particular to a framework migration method and system for heterogeneous microservice architectures. Background Technology

[0002] With the deepening development of enterprise informatization, microservice architecture has become the mainstream architectural pattern in modern software development. Microservice architecture breaks down complex application systems into multiple independently deployed, loosely coupled small services, each responsible for specific business functions and collaborating through lightweight communication mechanisms. In practical applications, due to the evolution of technology stacks and changes in business requirements, enterprises often face the challenge of migrating from old frameworks to new ones—the framework migration problem of heterogeneous microservice architectures.

[0003] Heterogeneous microservice architecture refers to the coexistence of microservices implemented using different technology stacks within the same system, such as Java Spring Boot, NodeJS, and Go. These services may employ different communication protocols, data formats, and governance methods, requiring the maintenance of normal service operation and business continuity during migration. Traditional microservice migration typically employs methods such as rewriting, adapter patterns, or parallel execution, but these often face numerous challenges in large-scale, complex systems.

[0004] However, existing heterogeneous microservice architecture migration technologies still have shortcomings and deficiencies. The service migration process lacks a scientific prioritization mechanism. Most existing technologies rely on manual experience or simple dependency analysis to determine the migration order, making it difficult to fully consider the complex call dependencies between services. This can easily lead to service unavailability or circular dependencies during migration, impacting business continuity. Furthermore, effective traffic control and service protection measures are lacking during microservice migration. During the service migration phase, the coexistence of old and new services can cause unstable system load. Existing technologies lack the ability to dynamically adjust traffic allocation based on real-time service load status, easily leading to service overload or resource waste, reducing overall system availability. The link tracing and fault handling mechanisms between heterogeneous microservices are also inadequate. Microservices implemented with different technology stacks differ in call link tracing, fault location, and recovery strategies. Existing technologies struggle to provide a unified service quality assurance system, making it difficult to promptly detect and resolve anomalies in cross-framework service calls during migration, increasing operational complexity and fault handling time. Summary of the Invention

[0005] This invention provides a framework migration method and system for heterogeneous microservice architectures, which can solve the problems in the prior art.

[0006] A first aspect of this invention provides a framework migration method for heterogeneous microservice architectures, comprising:

[0007] Scan the service interface information in the microservice architecture, use a topology sorting algorithm based on service call characteristics to process the service call dependency matrix, and generate a service migration priority sequence;

[0008] Select services to be migrated based on the service migration priority sequence, parse the interface definition information, and generate a unified service interface description file containing the service name and interface path;

[0009] The unified service interface description file is parsed to generate an abstract syntax tree, the interface call nodes are identified and the link tracing probe is injected, the service adaptation layer code is generated by filling the code template by traversing the abstract syntax tree, and the service adaptation layer code is injected into the target microservice.

[0010] Write the service call identifier and time expiration value into the request header of the target microservice, and store the service call identifier and time expiration value in the distributed cache;

[0011] Collect request traffic data of the target microservice, calculate the service load status through the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests.

[0012] Real-time monitoring of the target microservice's operational status; when the service failure rate exceeds the preset circuit breaker threshold, the circuit breaker mechanism is triggered and the recovery time is dynamically adjusted according to the exponential backoff algorithm.

[0013] The service level indicators after traffic control are statistically analyzed using a sliding time window. Service degradation is triggered according to a preset degradation threshold, and the degradation results are written to a distributed cache.

[0014] Start an asynchronous scheduled task to clear service call identifiers in the distributed cache that are earlier than the current timestamp.

[0015] In one optional embodiment, scanning service interface information in the microservice architecture, processing the service call dependency matrix using a topology sorting algorithm based on service call characteristics, and generating a service migration priority sequence includes:

[0016] Scan the service interface information in the microservice architecture and construct a service call dependency matrix based on the service interface information;

[0017] Traverse the service call dependency matrix, count the in-degree value of each service node, and add the service nodes with an in-degree value of zero to the candidate queue;

[0018] Take the first service node from the candidate queue, mark the first service node as visited and add it to the result sequence, delete the outgoing edges of the first service node, and update the in-degree value of the service nodes adjacent to the first service node.

[0019] When deleting an outgoing edge causes the in-degree of an adjacent service node to become zero, the product of the service call frequency and response latency of the adjacent service node is calculated as a priority weight, and the adjacent service node is inserted into the corresponding position in the candidate queue according to the priority weight.

[0020] Repeat the process until the candidate queue is empty, generating a migration priority sequence that combines service call characteristics;

[0021] If there are unvisited service nodes in the service call dependency matrix, the circular dependency edges between the unvisited service nodes are disconnected in descending order of service call frequency, and the source service node at the disconnection point is added to the candidate queue.

[0022] Repeat the topology sorting process until all service nodes have been accessed to obtain a complete service migration priority sequence.

[0023] In one optional embodiment, parsing the unified service interface description file to generate an abstract syntax tree, identifying interface call nodes and injecting tracing probes, generating service adaptation layer code by traversing the abstract syntax tree and filling code templates, and injecting the service adaptation layer code dependencies into the target microservice includes:

[0024] The unified service interface description file is parsed based on a keyword dictionary and regular expression rules to generate a tag sequence, and the tag sequence is parsed using a hierarchical analysis method to generate an abstract syntax tree containing service interface information;

[0025] In the abstract syntax tree, the interface call entry node, parameter passing node, and return value node are identified. Call identifier generation and passing logic is injected into the interface call entry node, parameter recording and verification logic is injected into the parameter passing node, and result collection logic is injected into the return value node to generate an abstract syntax tree for injecting the link tracing probe.

[0026] Construct a code template library containing multiple programming languages, wherein the code templates in the code template library reserve placeholders for service interface information and tracing probe information;

[0027] Traverse the abstract syntax tree of the injection link tracing probe, fill the service interface information and the tracing probe information into the placeholder positions of the code template, and generate service adaptation layer code with a plug-in architecture;

[0028] The service adaptation layer code is deployed to the target microservice via dependency injection.

[0029] In an optional embodiment, the unified service interface description file is parsed to generate a tag sequence based on a keyword dictionary and regular expression rules, and the tag sequence is then parsed to generate an abstract syntax tree containing service interface information using a hierarchical analysis method, including:

[0030] Extract strings one by one from the unified service interface description file, match the strings with entries in the keyword dictionary, mark the type attributes of the matched strings, extract the syntax features of the unmatched strings using regular expressions, and combine each processed string and its corresponding type attribute into a mark sequence.

[0031] Traverse the token sequence, for each token, record the position index of the predecessor and successor tokens, obtain the corresponding syntax rules, merge adjacent tokens with the same syntax rules into syntax units, construct a tree structure according to the hierarchical relationship of syntax units, and generate the initial syntax tree;

[0032] Traverse the initial syntax tree, extract the interface information of each syntax unit node and store it in the node's attribute field, establish node reference links based on the dependencies between nodes, and form a complete abstract syntax tree.

[0033] In one optional embodiment, request traffic data of the target microservice is collected, the service load status is calculated using the mutated gradient token bucket algorithm, token rate and bucket capacity parameters are generated, and traffic control of service requests is performed, including:

[0034] Collect request traffic data of the target microservice, and obtain a feature vector containing request rate, success rate, latency distribution and resource consumption by performing time series analysis and statistical processing on the request traffic data.

[0035] Based on the distribution characteristics of the feature vector, the token pool is divided into multiple levels according to the load gradient, and a mutation factor and transmission path are set between the levels to determine the token bucket structure.

[0036] The token bucket structure is used to apply time decay calculation to the token consumption data of each level, and the token flow data of each level is collected along the transmission path to obtain the exponential moving average reflecting the load change trend. The exponential moving average is weighted and corrected according to the mutation factor to obtain the mutation trigger threshold.

[0037] The token generation rate is adjusted based on the exponential moving average of each level. Combined with the burst traffic characteristics in the feature vector, the token conversion ratio between adjacent levels is calculated through the mutation factor to generate the capacity configuration parameters of the token bucket at each level.

[0038] The token consumption rate is determined based on token flow data. When the token consumption rate exceeds the mutation trigger threshold, the number of token migrations is determined based on the mutation factor, and the token bucket structure is dynamically reconstructed.

[0039] In one optional embodiment, the running status of the target microservice is monitored in real time. When the service failure rate exceeds a preset circuit breaker threshold, the circuit breaker mechanism is triggered, and the recovery time is dynamically adjusted according to an exponential backoff algorithm, including:

[0040] Real-time monitoring of the target microservice's operational status and collection of operational status data for the target microservice;

[0041] Based on the operational status data, abnormal events are classified and statistically analyzed within a sliding time window, and weighted calculations are performed according to preset abnormality type weights to obtain the abnormality rate of the target microservice.

[0042] The abnormality rate is compared with a preset circuit breaker threshold. When the abnormality rate continuously exceeds the circuit breaker threshold, the circuit breaker mechanism is triggered, and the backoff recovery process begins.

[0043] The initial recovery time is set based on the anomaly rate before the circuit breaker is triggered, and a maximum retry limit is set. The backoff base is calculated, which is determined by the product of the anomaly rate and a preset basic backoff coefficient.

[0044] Based on the backoff base, an increasing recovery time series is generated according to a preset increase. As the number of recovery attempts increases, the current number of recovery attempts is used as an exponent to calculate the product with the backoff base to obtain the current recovery time. A random jitter factor is introduced to randomly offset the recovery time.

[0045] After each recovery time, a probe request is injected, and the success rate of the probe request is counted. When the success rate of the probe request exceeds the preset recovery threshold or reaches the maximum number of retries limit, the backoff recovery process ends.

[0046] A second aspect of this invention provides a framework migration system for heterogeneous microservice architectures, comprising:

[0047] The first unit is used to scan service interface information in the microservice architecture, and uses a topology sorting algorithm based on service call characteristics to process the service call dependency matrix and generate a service migration priority sequence.

[0048] The second unit is used to select services to be migrated according to the service migration priority sequence, parse the interface definition information, and generate a unified service interface description file containing the service name and interface path.

[0049] The third unit is used to parse the unified service interface description file to generate an abstract syntax tree, identify interface call nodes and inject tracing probes, and generate service adaptation layer code by traversing the abstract syntax tree to fill the code template. The service adaptation layer code is then injected into the target microservice.

[0050] The fourth unit is used to write the service call identifier and time expiration value into the request header of the target microservice, and store the service call identifier and time expiration value into the distributed cache.

[0051] The fifth unit is used to collect request traffic data of the target microservice, calculate the service load status through the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests.

[0052] The sixth unit is used to monitor the running status of the target microservice in real time. When the service failure rate exceeds the preset circuit breaker threshold, the circuit breaker mechanism is triggered and the recovery time is dynamically adjusted according to the exponential backoff algorithm.

[0053] The seventh unit is used to statistically analyze the service level indicators after traffic control using a sliding time window, trigger service degradation processing according to a preset degradation threshold, and write the degradation processing results into a distributed cache.

[0054] Unit 8 is used to start asynchronous scheduled tasks and clean up service call identifiers in the distributed cache that are earlier than the current timestamp.

[0055] A third aspect of the present invention provides an electronic device, comprising:

[0056] processor;

[0057] Memory used to store processor-executable instructions;

[0058] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0059] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0060] In this embodiment of the invention, a topology sorting algorithm based on service call characteristics is used to process service dependencies and generate an ordered migration priority sequence, ensuring a smooth migration of the microservice architecture. This effectively avoids service dependency conflicts in traditional migration processes and improves the migration success rate. A unified service interface description file and an automatically generated service adaptation layer are used to achieve seamless connectivity between heterogeneous frameworks. Simultaneously, the injected link tracing probe provides full-link monitoring capabilities, making service call paths visible, significantly reducing the development cost of heterogeneous system integration, and improving system maintenance efficiency. Intelligent flow control is achieved through a mutated gradient token bucket algorithm, combined with a circuit breaker mechanism and service degradation strategy to form a complete service governance system. This ensures system stability under high concurrency scenarios, effectively responds to traffic fluctuations and service anomalies, improves the overall resilience and reliability of the microservice architecture, and optimizes resource utilization efficiency. Attached Figure Description

[0061] Figure 1 This is a flowchart illustrating the framework migration method for a heterogeneous microservice architecture according to an embodiment of the present invention.

[0062] Figure 2 Generate a flowchart for the abstract syntax tree. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0064] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0065] Figure 1 This is a flowchart illustrating the framework migration method for a heterogeneous microservice architecture according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes:

[0066] Scan the service interface information in the microservice architecture, use a topology sorting algorithm based on service call characteristics to process the service call dependency matrix, and generate a service migration priority sequence;

[0067] Select services to be migrated based on the service migration priority sequence, parse the interface definition information, and generate a unified service interface description file containing the service name and interface path;

[0068] The unified service interface description file is parsed to generate an abstract syntax tree, the interface call nodes are identified and the link tracing probe is injected, the service adaptation layer code is generated by filling the code template by traversing the abstract syntax tree, and the service adaptation layer code is injected into the target microservice.

[0069] Write the service call identifier and time expiration value into the request header of the target microservice, and store the service call identifier and time expiration value in the distributed cache;

[0070] Collect request traffic data of the target microservice, calculate the service load status through the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests.

[0071] Real-time monitoring of the target microservice's operational status; when the service failure rate exceeds the preset circuit breaker threshold, the circuit breaker mechanism is triggered and the recovery time is dynamically adjusted according to the exponential backoff algorithm.

[0072] The service level indicators after traffic control are statistically analyzed using a sliding time window. Service degradation is triggered according to a preset degradation threshold, and the degradation results are written to a distributed cache.

[0073] Start an asynchronous scheduled task to clear service call identifiers in the distributed cache that are earlier than the current timestamp.

[0074] In one specific implementation, a comprehensive scan of the service interface information in the microservice architecture is performed. A dependency matrix is ​​constructed by analyzing the call characteristics between services, and a topology sorting algorithm is applied to generate a priority sequence for service migration. Based on this priority sequence, services to be migrated are selected, and their interface definition information is parsed to generate a unified service interface description file containing the service name and interface path.

[0075] The unified interface description file is then parsed, converted into an abstract syntax tree structure, and all interface call nodes are identified. Tracing probes are injected into these nodes. By traversing the abstract syntax tree and filling in predefined code templates, service adaptation layer code is generated and integrated into the target microservice via dependency injection.

[0076] During service invocation, a specific service invocation identifier and corresponding expiration value are written into the request header of the target microservice, and this information is stored in a distributed cache for subsequent traffic control and status monitoring. Request traffic data of the target microservice is continuously collected, and the current load status of the service is calculated based on this data. The rate and capacity parameters required for traffic control are dynamically generated to achieve precise control over service requests.

[0077] The system monitors the operational status of the target microservice in real time. When the service failure rate exceeds the pre-set circuit breaker threshold, the circuit breaker mechanism is triggered, and the service recovery interval is dynamically adjusted based on the current situation. Simultaneously, a sliding time window method is used to statistically analyze various service level indicators after flow control. When these indicators reach preset degradation thresholds, service degradation processing is triggered, and the processing results are written to a distributed cache.

[0078] An asynchronous scheduled task is initiated to periodically clean up service call identifiers in the distributed cache whose expiration values ​​are less than the current timestamp, ensuring effective utilization of cache space. Through this series of steps, this invention achieves smooth service migration and intelligent traffic control in a microservice architecture, effectively improving stability and reliability.

[0079] In one optional implementation, service interface information in the microservice architecture is scanned, and a topology sorting algorithm based on service call characteristics is used to process the service call dependency matrix to generate a service migration priority sequence, including:

[0080] Scan the service interface information in the microservice architecture and construct a service call dependency matrix based on the service interface information;

[0081] Traverse the service call dependency matrix, count the in-degree value of each service node, and add the service nodes with an in-degree value of zero to the candidate queue;

[0082] Take the first service node from the candidate queue, mark the first service node as visited and add it to the result sequence, delete the outgoing edges of the first service node, and update the in-degree value of the service nodes adjacent to the first service node.

[0083] When deleting an outgoing edge causes the in-degree of an adjacent service node to become zero, the product of the service call frequency and response latency of the adjacent service node is calculated as a priority weight, and the adjacent service node is inserted into the corresponding position in the candidate queue according to the priority weight.

[0084] Repeat the process until the candidate queue is empty, generating a migration priority sequence that combines service call characteristics;

[0085] If there are unvisited service nodes in the service call dependency matrix, the circular dependency edges between the unvisited service nodes are disconnected in descending order of service call frequency, and the source service node at the disconnection point is added to the candidate queue.

[0086] Repeat the topology sorting process until all service nodes have been accessed to obtain a complete service migration priority sequence.

[0087] Microservice architecture migration often involves complex service dependencies, and improper migration order can lead to service unavailability. One implementation involves scanning service interface information within the microservice architecture and constructing a service call dependency matrix based on this information. Service interface information can be obtained by analyzing data from a service registry, inter-service call logs, or API gateway request records. The service call dependency matrix is ​​a two-dimensional matrix where matrix elements represent the call relationship between row services and column services; a value of 1 indicates the existence of a call relationship, and a value of 0 indicates the absence of a call relationship.

[0088] For example, in a certain e-commerce microservice system, there are five microservices: User Service, Product Service, Order Service, Payment Service, and Inventory Service. By analyzing the service interface information, the following service call dependency matrix can be obtained: User Service calls Order Service; Product Service does not call other services; Order Service calls Product Service, Payment Service, and Inventory Service; Payment Service calls User Service; Inventory Service does not call other services. In the constructed dependency matrix, rows represent callers, and columns represent callees.

[0089] After constructing the service call dependency matrix, the matrix is ​​traversed to count the in-degree value of each service node. The in-degree value refers to how many other services depend on this service. For the e-commerce system mentioned above, the in-degree value of the user service is 1 (called by the payment service), the in-degree value of the product service is 1 (called by the order service), the in-degree value of the order service is 1 (called by the user service), the in-degree value of the payment service is 1 (called by the order service), and the in-degree value of the inventory service is 1 (called by the order service).

[0090] Add service nodes with an in-degree of zero to the candidate queue. An in-degree of zero means that the service is not depended on by other services and can be migrated first. In practical applications, there may be multiple services with an in-degree of zero; in this case, all of them can be added to the candidate queue. In the e-commerce system mentioned above, there are no service nodes with an in-degree of zero in the initial state, indicating that there is a circular dependency in the system.

[0091] Remove the head service node from the candidate queue, mark it as visited, and add it to the result sequence. Simultaneously, delete the outgoing edges of this service node (i.e., its call relationships to other services), and update the in-degree values ​​of the service nodes adjacent to it.

[0092] When deleting an outgoing edge causes the in-degree of an adjacent service node to become zero, the product of the service call frequency and response latency of that adjacent service node is calculated as its priority weight. Service call frequency refers to the number of times a service is called per unit of time, and response latency refers to the average time required for the service to respond to a request. A higher priority weight indicates a higher call cost for the service and that it should be migrated earlier. Based on the calculated priority weight, adjacent service nodes are inserted into their corresponding positions in the candidate queue.

[0093] For example, in the e-commerce system described above, assuming the product service is called 100 times per minute with a response latency of 20 milliseconds, its priority weight is 2000; the payment service is called 50 times per minute with a response latency of 50 milliseconds, so its priority weight is 2500; and the inventory service is called 80 times per minute with a response latency of 15 milliseconds, so its priority weight is 1200. After deleting the outgoing edge of the order service, the in-degree values ​​of the product service, payment service, and inventory service all become zero. Based on their priority weights, they are inserted into the candidate queue in the order of payment service, product service, and inventory service.

[0094] Repeat the above process until the candidate queue is empty, generating a migration priority sequence that combines service call characteristics.

[0095] Due to the complexity of microservice architecture, circular dependencies may exist between services, making it impossible to find service nodes with an in-degree of zero. When there are unvisited service nodes in the service call dependency matrix, it is necessary to identify the circular dependencies and take measures to resolve them. Specifically, the circular dependency edges between unvisited service nodes are broken sequentially according to the service call frequency from high to low, and the source service node at the break point is added to a candidate queue.

[0096] For example, in the e-commerce system described above, there is a circular dependency between the user service and the payment service: the user service calls the order service, the order service calls the payment service, and the payment service calls the user service. Assume the user service calls the order service 200 times per minute, the order service calls the payment service 150 times per minute, and the payment service calls the user service 100 times per minute. Based on the principle of decreasing call frequency, the call relationship between the payment service and the user service should be broken, and the payment service should be added to the candidate queue.

[0097] Repeat the topology sorting process until all service nodes have been visited, resulting in a complete service migration priority sequence. For the e-commerce system described above, assuming that after disconnecting the call relationship between the payment service and the user service, the in-degree value of the payment service becomes zero, it is added to the candidate queue. After performing the topology sort, the possible service migration priority sequence is: payment service, user service, order service, product service, and inventory service.

[0098] During the actual migration process, services are migrated sequentially according to the generated migration priority sequence. For the e-commerce system mentioned above, the payment service is migrated first, followed by the user service, then the order service, then the product service, and finally the inventory service. This migration order ensures service availability during the migration process and reduces migration problems caused by service dependencies.

[0099] In this embodiment, by considering factors such as service call frequency and response latency, a reasonable service migration priority sequence is generated, solving the service dependency problem during the migration of heterogeneous microservice architectures and improving migration efficiency and success rate. This method is applicable to migration scenarios of various microservice architectures and has broad application prospects.

[0100] In one optional implementation, the unified service interface description file is parsed to generate an abstract syntax tree, interface call nodes are identified and tracing probes are injected, and service adaptation layer code is generated by filling code templates through traversing the abstract syntax tree. The service adaptation layer code is then injected into the target microservice as a dependency, including:

[0101] The unified service interface description file is parsed based on a keyword dictionary and regular expression rules to generate a tag sequence, and the tag sequence is parsed using a hierarchical analysis method to generate an abstract syntax tree containing service interface information;

[0102] In the abstract syntax tree, the interface call entry node, parameter passing node, and return value node are identified. Call identifier generation and passing logic is injected into the interface call entry node, parameter recording and verification logic is injected into the parameter passing node, and result collection logic is injected into the return value node to generate an abstract syntax tree for injecting the link tracing probe.

[0103] Construct a code template library containing multiple programming languages, wherein the code templates in the code template library reserve placeholders for service interface information and tracing probe information;

[0104] Traverse the abstract syntax tree of the injection link tracing probe, fill the service interface information and the tracing probe information into the placeholder positions of the code template, and generate service adaptation layer code with a plug-in architecture;

[0105] The service adaptation layer code is deployed to the target microservice via dependency injection.

[0106] In one specific implementation, a unified service interface description file is received, which can be a Swagger, OpenAPI, WSDL, or a custom-formatted interface description file. For the received interface description file, a keyword dictionary and a regular expression rule base are established. The keyword dictionary contains keywords such as service name, interface name, parameter type, and return value type; the regular expression rules are used to identify specific patterns in the interface description file, such as URL patterns, parameter definition patterns, and data type definition patterns. For example, for a RESTful style interface description, a regular expression like " / api / v[0-9]+ / [a-zA-Z0-9_-]+" is used to match the API path. The system applies these rules through a lexical analyzer, converting the unified service interface description file into a sequence of tags, each tag containing type, value, and location information.

[0107] For the parsed token sequence, a recursive descent parsing method is used to construct an abstract syntax tree. During the analysis, hierarchical structures such as service definitions, interface definitions, parameter definitions, and return value definitions are identified. For example, for the order service of an e-commerce system, the interface description file might define interfaces such as "createOrder", "getOrderById", and "updateOrderStatus". These interfaces are parsed into nodes in the abstract syntax tree, each node containing information such as the interface name, input parameters, output parameters, and access permissions. During the construction process, the system also verifies the consistency and integrity of the interfaces, such as parameter type matching and the existence of required parameters.

[0108] After the abstract syntax tree is constructed, interface call node identification and probe injection are performed. Three types of key nodes are identified: interface call entry nodes, parameter passing nodes, and return value nodes. For interface call entry nodes, call identifier generation and transmission logic is injected. Specifically, a globally unique trace ID (e.g., UUID format "550e8400-e29b-41d4-a716-446655440000") is generated and passed in the call context. For example, an "X-Trace-Id" field is added to the HTTP request header, or trace attributes are set in the RPC context. For parameter passing nodes, parameter recording and validation logic is injected, recording the parameter name, type, and value, while verifying whether the parameter conforms to type and range constraints. For example, for the userId parameter of the order creation interface, it is verified whether it is a valid integer type, and its value is recorded for traceback. For return value nodes, result collection logic is injected, recording information such as return value type, structure, and processing time. These injected probe logics are implemented using non-intrusive methods, such as dynamic proxies and aspect-oriented programming, to ensure that the functional behavior of the original interface is not changed.

[0109] After probe injection is complete, a code template library is built. This library supports multiple programming languages, such as Java, Python, Go, and JavaScript. Each language's template includes service class definition templates, interface method templates, parameter handling templates, return value handling templates, and exception handling templates. Placeholders are reserved in the templates to populate information such as service name, interface name, parameter list, parameter type, return value type, and tracing logic. For example, a Java service interface template might look like this: "%SERVICE_NAME%Service { %RETURN_TYPE% %METHOD_NAME%(%PARAM_LIST%) throws %EXCEPTION_TYPE%;}", where %SERVICE_NAME% and %RETURN_TYPE% are placeholders.

[0110] The abstract syntax tree of the injected tracing probe is traversed to extract service interface information and tracing probe information. Service interface information includes service name, interface name, parameter list, and return value type; tracing probe information includes call identifier generation code, parameter validation code, and result collection code. The system fills this information into placeholder positions in the code template to generate complete service adaptation layer code. Taking the order service of an e-commerce system as an example, the generated Java adaptation layer code includes components such as the OrderService interface definition, the OrderServiceImpl implementation class, parameter validator, and result processor. These components adopt a plug-in architecture, achieving loose coupling through interface definition and dependency injection, facilitating expansion and maintenance.

[0111] The generated service adaptation layer code is deployed to the target microservice via dependency injection. Within the Spring framework environment, the adaptation layer components are registered as Spring Beans using annotations (such as `@Service` and `@Component`). During startup, these Beans are dynamically registered through configuration classes, and their dependencies on other components are established. Runtime configuration options are provided, allowing developers to adjust the verbosity of tracing, sampling rate, and storage strategy, among other things.

[0112] In this embodiment, the automatic generation of service adaptation layer code with tracing capabilities from a unified service interface description file is realized, which greatly improves the efficiency of microservice development, enhances system observability, and reduces the difficulty of diagnosing cross-service call problems.

[0113] like Figure 2 The diagram shown illustrates the process of generating an abstract syntax tree.

[0114] In one optional implementation, the unified service interface description file is parsed to generate a tag sequence based on a keyword dictionary and regular expression rules, and the tag sequence is then parsed to generate an abstract syntax tree containing service interface information using a hierarchical analysis method, including:

[0115] Extract strings one by one from the unified service interface description file, match the strings with entries in the keyword dictionary, mark the type attributes of the matched strings, extract the syntax features of the unmatched strings using regular expressions, and combine each processed string and its corresponding type attribute into a mark sequence.

[0116] Traverse the token sequence, for each token, record the position index of the predecessor and successor tokens, obtain the corresponding syntax rules, merge adjacent tokens with the same syntax rules into syntax units, construct a tree structure according to the hierarchical relationship of syntax units, and generate the initial syntax tree;

[0117] Traverse the initial syntax tree, extract the interface information of each syntax unit node and store it in the node's attribute field, establish node reference links based on the dependencies between nodes, and form a complete abstract syntax tree.

[0118] In one specific implementation, a keyword dictionary is constructed, containing keywords commonly used in service interface descriptions, such as "service", "function", "interface", "parameter", "returns", "struct", and "enum". Simultaneously, a predefined set of regular expression rules is used to identify syntactic elements such as identifiers, strings, and numbers. For example, the regular expression for an identifier can be defined as "[a-zA-Z_][a-zA-Z0-9_]*", indicating that it begins with a letter or underscore, followed by letters, numbers, or underscores.

[0119] During parsing, content is read from the unified service interface description file, line by line, and preprocessed, including removing comments and redundant whitespace. After preprocessing, characters are read one by one, forming string buffers from consecutive characters. For each string buffer, it is first matched against entries in the keyword dictionary. If a match is successful, the string is marked with the corresponding type attribute, for example, "service" is marked as "SERVICE_KEYWORD". If no keyword is matched, predefined regular expression rules are used to match and determine the syntactic features of the string. For example, for the string "getUserInfo", since it is not a keyword, a regular expression for identifiers is used to match and it is marked as "IDENTIFIER".

[0120] In a concrete example, consider a simple service interface description: "service UserService { function getUserInfo(userId: string): UserInfo;}". We identify "service" as a keyword and label it "SERVICE_KEYWORD"; we identify "UserService" as an identifier and label it "IDENTIFIER"; we identify "{" as a left curly brace and label it "LEFT_BRACE"; and so on. Ultimately, the description file is parsed into the following sequence of tags: [SERVICE_KEYWORD("service"), IDENTIFIER("UserService"), LEFT_BRACE("{"),FUNCTION_KEYWORD("function"), IDENTIFIER("getUserInfo"), LEFT_PAREN("("),IDENTIFIER("userId"), COLON(":"), TYPE_IDENTIFIER("string"), RIGHT_PAREN(")"), COLON(":"), TYPE_IDENTIFIER("UserInfo"), SEMICOLON(";"), RIGHT_BRACE("}")].

[0121] After generating the token sequence, hierarchical analysis is performed to construct an abstract syntax tree. The token sequence is traversed, and the position indices of its predecessor and successor tokens are recorded for each token. For example, in the above token sequence, the predecessor token of "IDENTIFIER("UserService")" is "SERVICE_KEYWORD("service")", with a position index of 0; the successor token is "LEFT_BRACE("{")", with a position index of 2.

[0122] Based on predefined syntax rules, relationships between tags are identified, and adjacent tags that conform to specific syntax rules are merged into a syntactic unit. In this example, "SERVICE_KEYWORD("service")" and "IDENTIFIER("UserService")" can be merged into a syntactic unit representing a service definition. Similarly, "FUNCTION_KEYWORD("function")", "IDENTIFIER("getUserInfo")", and their associated tags for parameters and return types can be merged into a syntactic unit representing a function definition.

[0123] An initial syntax tree is constructed by analyzing the hierarchical relationships between syntax units. In this example, the service definition syntax unit is the root node of the tree, and the function definition syntax unit is a child node of the service definition node. Parameter definitions and return type definitions are child nodes of the function definition node.

[0124] The initial syntax tree is further traversed, and interface information is extracted from each syntax unit node and stored in the node's attribute fields. For example, the service name "UserService" is extracted from the service definition node and stored as the node's name attribute; the function name "getUserInfo", parameter information "userId: string", and return type "UserInfo" are extracted from the function definition node and stored as the node's name, parameters, and returnType attributes, respectively.

[0125] Based on the dependencies between nodes, reference links are established between them. For example, a function definition node references its parameter and return type definition nodes. If the return type "UserInfo" is a struct defined elsewhere, a reference link is established from the function definition node to the struct definition node.

[0126] After the above processing is completed, a complete abstract syntax tree is generated. This tree contains all the interface information defined in the service interface description file, and the dependencies between interface elements are represented by the reference relationships between nodes. This abstract syntax tree can be used for further processing, such as code generation and interface documentation generation.

[0127] This parsing method, based on a keyword dictionary and regular expression rules, combined with hierarchical analysis techniques, effectively transforms unified service interface description files into structured abstract syntax trees, providing a solid foundation for subsequent service interface processing. By customizing the keyword dictionary and regular expression rules, this method can adapt to service interface description files of different formats, exhibiting strong flexibility and scalability.

[0128] In one optional implementation, request traffic data of the target microservice is collected, the service load status is calculated using the mutated gradient token bucket algorithm, token rate and bucket capacity parameters are generated, and traffic control of service requests is performed, including:

[0129] Collect request traffic data of the target microservice, and obtain a feature vector containing request rate, success rate, latency distribution and resource consumption by performing time series analysis and statistical processing on the request traffic data.

[0130] Based on the distribution characteristics of the feature vector, the token pool is divided into multiple levels according to the load gradient, and a mutation factor and transmission path are set between the levels to determine the token bucket structure.

[0131] The token bucket structure is used to apply time decay calculation to the token consumption data of each level, and the token flow data of each level is collected along the transmission path to obtain the exponential moving average reflecting the load change trend. The exponential moving average is weighted and corrected according to the mutation factor to obtain the mutation trigger threshold.

[0132] The token generation rate is adjusted based on the exponential moving average of each level. Combined with the burst traffic characteristics in the feature vector, the token conversion ratio between adjacent levels is calculated through the mutation factor to generate the capacity configuration parameters of the token bucket at each level.

[0133] The token consumption rate is determined based on token flow data. When the token consumption rate exceeds the mutation trigger threshold, the number of token migrations is determined based on the mutation factor, and the token bucket structure is dynamically reconstructed.

[0134] In one specific implementation, a data acquisition module continuously monitors the request traffic data of the target microservice. In practical applications, the data acquisition module records the number of requests received by the microservice, the number of successfully completed requests, request processing latency, and resource indicators such as CPU utilization and memory usage, using a 500-millisecond time window. For example, a payment processing microservice might receive 200 requests per second during peak periods, with a success rate of 98%, an average processing latency of 45 milliseconds, and CPU utilization reaching 65%. This raw data is processed to construct a feature vector F=(200, 0.98, 45, 0.65), which serves as the basis for subsequent analysis.

[0135] The collected time-series data is processed using a sliding window method to calculate the request rate fluctuation range, success rate stability, 95th percentile latency, and peak resource utilization over the past 10 minutes. These statistical characteristics help identify request patterns. For example, in the payment microservice, significant request peaks were observed during weekdays from 12:00-13:00 and 18:00-19:00, with peak request rates approximately 2.5 times higher than the average. During these peaks, the success rate dropped to 92%, and processing latency increased to 75 milliseconds.

[0136] Based on the distribution characteristics of feature vectors, the token pool is divided into multiple load gradient levels. In a typical embodiment, four levels are designed: L1 (light load layer, load rate 0-30%), L2 (medium load layer, load rate 30%-60%), L3 (heavy load layer, load rate 60%-85%), and L4 (overload layer, load rate >85%). Each level is configured with different variation factors, α1=0.2, α2=0.4, α3=0.7, and α4=0.9, reflecting the weight of each level's influence on stability. A bidirectional transmission path P=(P12, P21, P23, P32, P34, P43) is set between levels to control the flow of tokens between different levels.

[0137] To accurately reflect load change trends, a time decay calculation is applied to the token consumption data at each level. For each level Li, its token consumption Ci, after time decay, becomes Ci', with a decay coefficient β set to 0.85, indicating that the weight of historical data decreases by 15% after each time window. For example, if the token consumption of level L2 in three consecutive time windows is 120, 150, and 180 respectively, then the latest decay value is calculated as 180 + 150 × 0.85 + 120 × 0.85. 2 =180+127.5+86.7=394.2.

[0138] Token flow data at each level is collected along the transmission path, and the exponential moving average is calculated. Taking level L2 as an example, its exponential moving average E2 is obtained by weighting the current value and the historical average, with the weighting factor γ set to 0.3. If the token consumption in the current window L2 is 150, and the exponential moving average of the previous period was 130, then the new average value E2 = 150 × 0.3 + 130 × 0.7 = 136. The exponential moving average is corrected according to the mutation factor of each level, resulting in the mutation trigger threshold T2 = E2 × (1 + α2) = 136 × 1.4 = 190.4, indicating that the mutation mechanism will be triggered when the token consumption of level L2 exceeds this value.

[0139] The token generation rate is dynamically adjusted based on the exponential moving average of each level. For example, if the base token generation rate of a microservice under normal conditions is 100 tokens / second, and the exponential moving average of the L2 level increases to 1.2 times the original rate, the token generation rate of the L2 level is adjusted to 100 × (1 - α2 × 0.2) = 92 tokens / second to prevent overload. Simultaneously, considering the burst traffic characteristics identified in the feature vector, such as the possibility that payment services may experience burst traffic up to three times the normal level during holidays, sufficient capacity is reserved for the token buckets at each level: L1 bucket capacity is set to 300 tokens, L2 to 200, L3 to 150, and L4 to 80, to handle sudden requests.

[0140] The token consumption rate is monitored in real time. When the token consumption rate at the L2 level exceeds the mutation trigger threshold of 190.4, the number of tokens that need to be migrated is calculated based on the mutation factor α2. Assuming that 20 tokens exceed the threshold, the number of tokens migrated up to the L3 level is 20 × α2 = 8, and the number of tokens retained in L2 is 12. Simultaneously, the token bucket structure is dynamically restructured, increasing the capacity of the L3 level to 165 and decreasing the capacity of the L2 level to 188 to adapt to the current load.

[0141] This dynamic adjustment mechanism allows for flexible allocation of token resources based on actual traffic changes, effectively controlling resource consumption while ensuring service quality. For example, during a flash sale on an e-commerce platform, the request volume for the payment microservice surged to 500 requests per second. The token bucket parameters were quickly adjusted to increase the token ratio at the L3 and L4 levels, ensuring priority processing of core transaction requests while appropriately limiting non-critical requests, maintaining a service success rate above 94% and ensuring stable operation.

[0142] In one optional implementation, the running status of the target microservice is monitored in real time. When the service failure rate exceeds a preset circuit breaker threshold, the circuit breaker mechanism is triggered, and the recovery time is dynamically adjusted according to an exponential backoff algorithm, including:

[0143] Real-time monitoring of the target microservice's operational status and collection of operational status data for the target microservice;

[0144] Based on the operational status data, abnormal events are classified and statistically analyzed within a sliding time window, and weighted calculations are performed according to preset abnormality type weights to obtain the abnormality rate of the target microservice.

[0145] The abnormality rate is compared with a preset circuit breaker threshold. When the abnormality rate continuously exceeds the circuit breaker threshold, the circuit breaker mechanism is triggered, and the backoff recovery process begins.

[0146] The initial recovery time is set based on the anomaly rate before the circuit breaker is triggered, and a maximum retry limit is set. The backoff base is calculated, which is determined by the product of the anomaly rate and a preset basic backoff coefficient.

[0147] Based on the backoff base, an increasing recovery time series is generated according to a preset increase. As the number of recovery attempts increases, the current number of recovery attempts is used as an exponent to calculate the product with the backoff base to obtain the current recovery time. A random jitter factor is introduced to randomly offset the recovery time.

[0148] After each recovery time, a probe request is injected, and the success rate of the probe request is counted. When the success rate of the probe request exceeds the preset recovery threshold or reaches the maximum number of retries limit, the backoff recovery process ends.

[0149] In one specific implementation, the real-time monitoring module continuously collects operational status data of the target microservice, including key indicators such as response time, request success rate, and resource utilization. The collection frequency is 10 times per second to ensure data timeliness. Monitoring data is collected through a lightweight proxy component embedded in the target microservice instance, consuming less than 5% of additional resources.

[0150] Anomaly event classification and statistics are performed within a 10-second sliding time window. Anomaly types include: timeout anomalies (weight 0.8); connection anomalies (weight 0.9); resource exhaustion anomalies (weight 1.0); business logic anomalies (weight 0.7); and dependent service anomalies (weight 0.6). For example, if 5 timeout anomalies, 3 connection anomalies, and 2 dependent service anomalies are detected within a 10-second window, the weighted anomaly count calculated based on the weights of each anomaly type is: 5 × 0.8 + 3 × 0.9 + 2 × 0.6 = 7.9. If the total number of requests within this time window is 100, the anomaly rate is 7.9%.

[0151] The circuit breaker mechanism compares the exception rate with a preset circuit breaker threshold. The default threshold is 5%, which can be adjusted according to the importance of the microservice. The circuit breaker is triggered when the exception rate exceeds the threshold for three consecutive time windows. After the circuit breaker is triggered, the target microservice will reject new non-critical requests, return a preset degraded response, and enter a backoff recovery process.

[0152] At the start of the backoff recovery process, the initial recovery time is set based on the anomaly rate before the circuit breaker was triggered. Specifically, the calculation method is as follows: when the anomaly rate is between 5% and 10%, the initial recovery time is set to 2 seconds; when the anomaly rate is between 10% and 20%, the initial recovery time is set to 5 seconds; when the anomaly rate is between 20% and 50%, the initial recovery time is set to 10 seconds; and when the anomaly rate exceeds 50%, the initial recovery time is set to 30 seconds. The maximum number of retries is limited to 10 by default and can be adjusted through configuration.

[0153] The backoff base is determined by multiplying the anomaly rate by a preset base backoff coefficient. The base backoff coefficient defaults to 2. When the anomaly rate before the circuit breaker is 15%, the backoff base is 15% × 2 = 0.3. This backoff base will be used to calculate the subsequent backoff time, reflecting the impact of the fault severity on the recovery strategy.

[0154] The incremental recovery time series is generated using an exponential backoff strategy, while also incorporating a random jitter factor. For the nth recovery attempt, the basic recovery time is calculated as: initial recovery time + backoff base × 2^(n-1). For example, if the initial recovery time is 5 seconds and the backoff base is 0.3, then the basic recovery time for the first recovery attempt is 5 + 0.3 × 2. 0 =5.3 seconds; the second time is 5 + 0.3 × 2 1=5.6 seconds; the third time is 5 + 0.3 × 2 2 =6.2 seconds. The random jitter factor ranges from -0.2 to 0.2. Multiply the basic recovery time by (1 + random jitter factor) to get the final recovery time. For example, if the basic recovery time of the 3rd recovery attempt is 6.2 seconds and the random jitter factor is 0.1, then the final recovery time is 6.2 × (1 + 0.1) = 6.82 seconds.

[0155] Probe requests are injected after each recovery timeout. These probe requests simulate normal business requests but are specially marked for statistical purposes. The number of probe requests gradually increases: 5 probe requests are injected initially, 10 in the second, and 5 more in each subsequent injection, until a maximum of 50 is reached. The probe request success rate is calculated by dividing the number of successfully responding probe requests by the total number of probe requests. The default recovery threshold is 95%, meaning that service is considered restored when the probe request success rate exceeds 95%.

[0156] The backoff recovery process terminates under two conditions: first, the success rate of probe requests exceeds a preset recovery threshold; second, the maximum number of retry attempts is reached. When either condition is met, the circuit breaker is lifted, and the target microservice resumes receiving new requests. If the backoff recovery process terminates due to reaching the maximum number of retry attempts, a critical alarm will be issued, prompting operations personnel to intervene manually.

[0157] The monitoring strategy after recovery includes setting an observation period, which defaults to 60 seconds. During the observation period, if the anomaly rate exceeds the circuit breaker threshold again, the circuit breaker will be triggered immediately, and the backoff base will increase by 50%, reflecting a cumulative penalty mechanism to prevent frequent recovery-circuit breaker cycles. After the observation period ends, normal monitoring mode will be restored.

[0158] In this embodiment, efficient fault isolation and self-healing capabilities in the microservice architecture are achieved through real-time status monitoring, multi-dimensional anomaly analysis, adaptive circuit breaker triggering, and intelligent fallback recovery, thereby improving the overall resilience of the system.

[0159] The framework migration system for heterogeneous microservice architectures in this embodiment of the invention includes:

[0160] The first unit is used to scan service interface information in the microservice architecture, and uses a topology sorting algorithm based on service call characteristics to process the service call dependency matrix and generate a service migration priority sequence.

[0161] The second unit is used to select services to be migrated according to the service migration priority sequence, parse the interface definition information, and generate a unified service interface description file containing the service name and interface path.

[0162] The third unit is used to parse the unified service interface description file to generate an abstract syntax tree, identify interface call nodes and inject tracing probes, and generate service adaptation layer code by traversing the abstract syntax tree to fill the code template. The service adaptation layer code is then injected into the target microservice.

[0163] The fourth unit is used to write the service call identifier and time expiration value into the request header of the target microservice, and store the service call identifier and time expiration value into the distributed cache.

[0164] The fifth unit is used to collect request traffic data of the target microservice, calculate the service load status through the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests.

[0165] The sixth unit is used to monitor the running status of the target microservice in real time. When the service failure rate exceeds the preset circuit breaker threshold, the circuit breaker mechanism is triggered and the recovery time is dynamically adjusted according to the exponential backoff algorithm.

[0166] The seventh unit is used to statistically analyze the service level indicators after traffic control using a sliding time window, trigger service degradation processing according to a preset degradation threshold, and write the degradation processing results into a distributed cache.

[0167] Unit 8 is used to start asynchronous scheduled tasks and clean up service call identifiers in the distributed cache that are earlier than the current timestamp.

[0168] A third aspect of the present invention provides an electronic device, comprising:

[0169] processor;

[0170] Memory used to store processor-executable instructions;

[0171] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0172] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0173] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

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

Claims

1. A framework migration method for heterogeneous microservice architectures, characterized in that, include: Scan the service interface information in the microservice architecture, use a topology sorting algorithm based on service call characteristics to process the service call dependency matrix, and generate a service migration priority sequence; Select services to be migrated based on the service migration priority sequence, parse the interface definition information, and generate a unified service interface description file containing the service name and interface path; The unified service interface description file is parsed to generate an abstract syntax tree, the interface call nodes are identified and the link tracing probe is injected, the service adaptation layer code is generated by filling the code template by traversing the abstract syntax tree, and the service adaptation layer code is injected into the target microservice. Write the service call identifier and time expiration value into the request header of the target microservice, and store the service call identifier and time expiration value in the distributed cache; Collect request traffic data of the target microservice, calculate the service load status through the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests. Real-time monitoring of the target microservice's operational status; when the service failure rate exceeds the preset circuit breaker threshold, the circuit breaker mechanism is triggered and the recovery time is dynamically adjusted according to the exponential backoff algorithm. The service level indicators after traffic control are statistically analyzed using a sliding time window. Service degradation is triggered according to a preset degradation threshold, and the degradation results are written to a distributed cache. Start an asynchronous scheduled task to clear service call identifiers in the distributed cache that are earlier than the current timestamp.

2. The method according to claim 1, characterized in that, Scanning service interface information in the microservice architecture, a topology sorting algorithm based on service call characteristics is used to process the service call dependency matrix, generating a service migration priority sequence including: Scan the service interface information in the microservice architecture and construct a service call dependency matrix based on the service interface information; Traverse the service call dependency matrix, count the in-degree value of each service node, and add the service nodes with an in-degree value of zero to the candidate queue; Take the first service node from the candidate queue, mark the first service node as visited and add it to the result sequence, delete the outgoing edges of the first service node, and update the in-degree value of the service nodes adjacent to the first service node. When deleting an outgoing edge causes the in-degree of an adjacent service node to become zero, the product of the service call frequency and response latency of the adjacent service node is calculated as a priority weight, and the adjacent service node is inserted into the corresponding position in the candidate queue according to the priority weight. Repeat the process until the candidate queue is empty, generating a migration priority sequence that combines service call characteristics; If there are unvisited service nodes in the service call dependency matrix, the circular dependency edges between the unvisited service nodes are disconnected in descending order of service call frequency, and the source service node at the disconnection point is added to the candidate queue. Repeat the topology sorting process until all service nodes have been accessed to obtain a complete service migration priority sequence.

3. The method according to claim 1, characterized in that, The process involves parsing the unified service interface description file to generate an abstract syntax tree, identifying interface call nodes and injecting tracing probes, and then filling code templates by traversing the abstract syntax tree to generate service adaptation layer code. This service adaptation layer code is then injected into the target microservice as a dependency. The unified service interface description file is parsed based on a keyword dictionary and regular expression rules to generate a tag sequence, and the tag sequence is parsed using a hierarchical analysis method to generate an abstract syntax tree containing service interface information; In the abstract syntax tree, the interface call entry node, parameter passing node, and return value node are identified. Call identifier generation and passing logic is injected into the interface call entry node, parameter recording and verification logic is injected into the parameter passing node, and result collection logic is injected into the return value node to generate an abstract syntax tree for injecting the link tracing probe. Construct a code template library containing multiple programming languages, wherein the code templates in the code template library reserve placeholders for service interface information and tracing probe information; Traverse the abstract syntax tree of the injection link tracing probe, fill the service interface information and the tracing probe information into the placeholder positions of the code template, and generate service adaptation layer code with a plug-in architecture; The service adaptation layer code is deployed to the target microservice via dependency injection.

4. The method according to claim 3, characterized in that, Based on a keyword dictionary and regular expression rules, the unified service interface description file is parsed to generate a tag sequence. Then, a hierarchical analysis method is used to parse the tag sequence to generate an abstract syntax tree containing service interface information, including: Extract strings one by one from the unified service interface description file, match the strings with entries in the keyword dictionary, mark the type attributes of the matched strings, extract the syntax features of the unmatched strings using regular expressions, and combine each processed string and its corresponding type attribute into a mark sequence. Traverse the token sequence, for each token, record the position index of the predecessor and successor tokens, obtain the corresponding syntax rules, merge adjacent tokens with the same syntax rules into syntax units, construct a tree structure according to the hierarchical relationship of syntax units, and generate the initial syntax tree; Traverse the initial syntax tree, extract the interface information of each syntax unit node and store it in the node's attribute field, establish node reference links based on the dependencies between nodes, and form a complete abstract syntax tree.

5. The method according to claim 1, characterized in that, Collect request traffic data of the target microservice, calculate the service load status using the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests, including: Collect request traffic data of the target microservice, and obtain a feature vector containing request rate, success rate, latency distribution and resource consumption by performing time series analysis and statistical processing on the request traffic data. Based on the distribution characteristics of the feature vector, the token pool is divided into multiple levels according to the load gradient, and a mutation factor and transmission path are set between the levels to determine the token bucket structure. The token bucket structure is used to apply time decay calculation to the token consumption data of each level, and the token flow data of each level is collected along the transmission path to obtain the exponential moving average reflecting the load change trend. The exponential moving average is weighted and corrected according to the mutation factor to obtain the mutation trigger threshold. The token generation rate is adjusted based on the exponential moving average of each level. Combined with the burst traffic characteristics in the feature vector, the token conversion ratio between adjacent levels is calculated through the mutation factor to generate the capacity configuration parameters of the token bucket at each level. The token consumption rate is determined based on token flow data. When the token consumption rate exceeds the mutation trigger threshold, the number of token migrations is determined based on the mutation factor, and the token bucket structure is dynamically reconstructed.

6. The method according to claim 1, characterized in that, Real-time monitoring of the target microservice's operational status; when the service failure rate exceeds the preset circuit breaker threshold, triggering the circuit breaker mechanism and dynamically adjusting the recovery time according to the exponential backoff algorithm, including: Real-time monitoring of the target microservice's operational status and collection of operational status data for the target microservice; Based on the operational status data, abnormal events are classified and statistically analyzed within a sliding time window, and weighted calculations are performed according to preset abnormality type weights to obtain the abnormality rate of the target microservice. The abnormality rate is compared with a preset circuit breaker threshold. When the abnormality rate continuously exceeds the circuit breaker threshold, the circuit breaker mechanism is triggered, and the backoff recovery process begins. The initial recovery time is set based on the anomaly rate before the circuit breaker is triggered, and a maximum retry limit is set. The backoff base is calculated, which is determined by the product of the anomaly rate and a preset basic backoff coefficient. Based on the backoff base, an increasing recovery time series is generated according to a preset increase. As the number of recovery attempts increases, the current number of recovery attempts is used as an exponent to calculate the product with the backoff base to obtain the current recovery time. A random jitter factor is introduced to randomly offset the recovery time. After each recovery time, a probe request is injected, and the success rate of the probe request is counted. When the success rate of the probe request exceeds the preset recovery threshold or reaches the maximum number of retries limit, the backoff recovery process ends.

7. A framework migration system for heterogeneous microservice architectures, used to implement the method of any one of claims 1-6, characterized in that, include: The first unit is used to scan service interface information in the microservice architecture, and uses a topology sorting algorithm based on service call characteristics to process the service call dependency matrix and generate a service migration priority sequence. The second unit is used to select services to be migrated according to the service migration priority sequence, parse the interface definition information, and generate a unified service interface description file containing the service name and interface path. The third unit is used to parse the unified service interface description file to generate an abstract syntax tree, identify interface call nodes and inject tracing probes, and generate service adaptation layer code by traversing the abstract syntax tree to fill the code template. The service adaptation layer code is then injected into the target microservice. The fourth unit is used to write the service call identifier and time expiration value into the request header of the target microservice, and store the service call identifier and time expiration value into the distributed cache. The fifth unit is used to collect request traffic data of the target microservice, calculate the service load status through the mutated gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform traffic control on service requests. The sixth unit is used to monitor the running status of the target microservice in real time. When the service failure rate exceeds the preset circuit breaker threshold, the circuit breaker mechanism is triggered and the recovery time is dynamically adjusted according to the exponential backoff algorithm. The seventh unit is used to statistically analyze the service level indicators after traffic control using a sliding time window, trigger service degradation processing according to a preset degradation threshold, and write the degradation processing results into a distributed cache. Unit 8 is used to start asynchronous scheduled tasks and clean up service call identifiers in the distributed cache that are earlier than the current timestamp.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images