Framework migration method and system for heterogeneous micro-service architecture

Abstract

The invention provides a framework migration method and system for a heterogeneous micro-service architecture, and relates to the technical field of micro-service architecture.The framework migration method comprises the steps that migration priorities are determined through topological sorting based on service calling features, a unified service interface description file is generated, a link tracking probe is injected, and service adaptation layer codes are generated; flow control is carried out in combination with a variation gradient token bucket algorithm, and service fusing and degradation are realized by adopting an exponential backoff algorithm and a sliding time window mechanism. According to the method, the problems of complex service dependence, difficulty in flow regulation and control and the like in heterogeneous architecture migration are solved, the security and stability of framework migration are improved, and the operation and maintenance cost of the system is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservice architecture, and in particular to a framework migration method and system for heterogeneous microservice architecture. BACKGROUND

[0002] With the deepening development of enterprise informatization, microservice architecture has become the mainstream architecture pattern of modern software development. Microservice architecture splits complex application systems into multiple independently deployed, loosely coupled small services, each of which is responsible for a specific business function and collaborates through a lightweight communication mechanism. In actual application, due to technology stack evolution and business requirement changes, enterprises often need to face the challenge of migrating from an old framework to a new framework, i.e., the framework migration problem of heterogeneous microservice architecture.

[0003] Heterogeneous microservice architecture refers to the coexistence of microservices implemented using different technology stacks in the same system, such as Java Spring Boot, NodeJS, Go, etc. These services may use different communication protocols, data formats, and governance methods, and need to ensure normal operation and business continuity during migration. Traditional microservice migration usually adopts rewriting, adapter mode, or parallel running, but in large-scale complex systems, it often faces many challenges.

[0004] However, the existing heterogeneous microservice architecture framework migration technology still has defects and deficiencies. The service migration process lacks a scientific priority ordering mechanism. Existing technologies mostly use manual experience judgment or simple dependency analysis to determine the migration order, which is difficult to fully consider the complex calling dependency relationship between services, and is prone to cause problems such as service unavailability or circular dependency during migration, affecting business continuity; there is a lack of effective traffic control and service protection measures during microservice migration. In the service migration phase, the coexistence of new and old services running will cause unstable system load, and the existing technology lacks the ability to dynamically adjust traffic distribution according to the real-time load state of the service, which is prone to cause service overload or resource waste, reducing the overall availability of the system; the link tracking and fault handling mechanism between heterogeneous microservices is not perfect. Microservices implemented in different technology stacks differ in call link tracking, fault location, and recovery strategies, and existing technologies are difficult to provide a unified service quality assurance system, making it difficult to discover and solve abnormal situations in cross-framework service calls in a timely manner during migration, increasing the complexity of operation and maintenance and fault handling time. SUMMARY

[0005] The embodiment of the present application provides a framework migration method and system for heterogeneous microservice architecture, which can solve the problems in the prior art.

[0006] In a first aspect of the embodiment of the present application, a framework migration method for heterogeneous microservice architecture is provided, comprising: Scanning service interface information in a microservice architecture, processing a service call dependency matrix using a topological sorting algorithm based on service call characteristics, and generating a service migration priority sequence; Selecting a service to be migrated according to the service migration priority sequence, parsing interface definition information, and generating a unified service interface description file containing service names and interface paths; Parsing the unified service interface description file to generate an abstract syntax tree, identifying interface call nodes and injecting link tracking probes, filling in a code template by traversing the abstract syntax tree to generate service adaptation layer code, and dependency injecting the service adaptation layer code into the target microservice; Writing service call identifiers and time-to-live values in the request header of the target microservice, and storing the service call identifiers and time-to-live values in a distributed cache; Collecting request traffic data from the target microservice, calculating service load status using a variant gradient token bucket algorithm, generating token rate and bucket capacity parameters, and performing traffic control on service requests; Real-time monitoring of the running state of the target microservice, triggering a fuse mechanism when the service exception rate exceeds a preset fuse threshold, and dynamically adjusting the recovery time according to an exponential backoff algorithm; Using a sliding time window to calculate service level indicators after traffic control, triggering service degradation processing according to a preset degradation threshold, and writing the degradation processing results to a distributed cache; Starting an asynchronous timing task to clean up service call identifiers in the distributed cache that are less than the current timestamp.

[0007] In an alternative embodiment, scanning service interface information in a microservice architecture, processing a service call dependency matrix using a topological sorting algorithm based on service call characteristics, and generating a service migration priority sequence includes: Scanning service interface information in a microservice architecture, and constructing a service call dependency matrix based on the service interface information; Traversing the service call dependency matrix, counting the in-degree value of each service node, and adding service nodes with an in-degree value of zero to a candidate queue; Taking the head service node from the candidate queue, marking the head service node as visited and adding it to the result sequence, deleting the outgoing edge of the head service node, and updating the in-degree value of adjacent service nodes of the head service node; When deleting the outgoing edge causes the in-degree value of an adjacent service node to become zero, calculating the product of the service call frequency and response time of the adjacent service node as a priority weight, and inserting the adjacent service node into the corresponding position of the candidate queue according to the priority weight; Repeat until the candidate queue is empty, generating a migration priority sequence that combines service call characteristics; If there is an unvisited service node in the service call dependency matrix, disconnect the cyclic dependency edges between the unvisited service nodes in order of service call frequency from high to low, and add the source service node at the disconnected location to the candidate queue; Repeat the topological sorting process until all service nodes are visited to obtain a complete service migration priority sequence.

[0008] In an optional embodiment, parsing the unified service interface description file generates an abstract syntax tree, identifies interface call nodes and injects link tracking probes, fills in a code template to generate service adaptation layer code by traversing the abstract syntax tree, and includes service adaptation layer code in the target microservice through dependency injection. The unified service interface description file is parsed based on a keyword dictionary and regular expression rules to generate a token sequence, and a hierarchical analysis method is used to parse the token sequence to generate an abstract syntax tree containing service interface information. In the abstract syntax tree, identify the interface call entry node, parameter passing node, and return value node, and inject call identification generation and transmission logic to the interface call entry node, parameter recording and verification logic to the parameter passing node, and result collection logic to the return value node to generate an abstract syntax tree with injected link tracking probes. A code template library containing multiple programming languages is constructed, and the code templates in the code template library reserve placeholders for service interface information and tracking probe information. Traverse the abstract syntax tree with injected link tracking probes, fill in the service interface information and tracking probe information into the placeholder positions of the code templates, and generate service adaptation layer code with a plug-in architecture. The service adaptation layer code is deployed to the target microservice through dependency injection.

[0009] In an optional embodiment, the unified service interface description file is parsed based on a keyword dictionary and regular expression rules to generate a token sequence, and a hierarchical analysis method is used to parse the token sequence to generate an abstract syntax tree containing service interface information, which includes: Extract strings one by one from the unified service interface description file, match the strings with the entries in the keyword dictionary, mark the type attributes of the matched strings, and use regular expressions to extract the syntax features of the unmatched strings. Each processed string and the corresponding type attribute form a token sequence. Traverse the token sequence, record the position index of the predecessor and successor tokens for each token, 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 the syntax units, and generate an initial syntax tree. Traverse the initial syntax tree, extract and store the interface information of each syntax unit node into the attribute field of the node, establish node reference link according to the dependency relationship between nodes, and form a complete abstract syntax tree.

[0010] In an optional embodiment, request traffic data of the target microservice is collected, service load state is calculated through a variant gradient token bucket algorithm, token rate and bucket capacity parameters are generated, and traffic control is performed on service requests, including: Request traffic data of the target microservice is collected, and a feature vector containing request rate, success rate, delay distribution and resource occupation is obtained through time series analysis and statistical processing of 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, a variant factor and a conduction path are set between the levels, and a token bucket structure is determined; The token consumption data of each level is subjected to time decay calculation using the token bucket structure, token flow data of each level is collected along the conduction path, an exponential moving average reflecting the load change trend is obtained, the exponential moving average is weighted and corrected according to the variant factor, and a variant trigger threshold is obtained; The token generation rate is adjusted according to the exponential moving average of each level, the token conversion ratio between adjacent levels is calculated through the variant factor combining the burst traffic feature in the feature vector, and the capacity configuration parameters of the token bucket of each level are generated; Based on the token flow data, the token consumption rate is determined, when the token consumption rate exceeds the variant trigger threshold, the number of token migrations is determined based on the variant factor, and the dynamic reconstruction of the token bucket structure is performed.

[0011] In an optional embodiment, the running state of the target microservice is monitored in real time, and when the service exception rate exceeds a preset fuse threshold, a fuse mechanism is triggered and the recovery time is dynamically adjusted according to an exponential backoff algorithm, including: The running state of the target microservice is monitored in real time, and the running state data of the target microservice is collected; Based on the running state data, the abnormal events are classified and counted in a sliding time window, and the abnormal rate of the target microservice is obtained by weighted calculation according to the preset abnormal type weight; The abnormal rate is compared with the preset fuse threshold, and when the abnormal rate continuously exceeds the fuse threshold, the fuse mechanism is triggered and the backoff recovery process is entered; The initial recovery time is set according to the abnormal rate before the fuse, and the maximum retry limit is set, and the backoff base is calculated, which is determined by the product of the abnormal rate and the preset basic backoff coefficient; Based on the backoff base, a sequence of incremental recovery times is generated according to a preset increment, a current recovery attempt number is taken as an exponential power, a product of the recovery attempt number and the backoff base is calculated to obtain a current recovery time, and a random jitter factor is introduced to randomly offset the recovery time; After each recovery time arrives, a probe request is injected, the success rate of the probe request is counted, and when the success rate of the probe request exceeds a preset recovery threshold or reaches the maximum retry number limit, the backoff recovery process is ended.

[0012] In a second aspect of the embodiment of the application, a framework migration system of a heterogeneous microservice architecture is provided, comprising: A first unit is configured to scan service interface information in the microservice architecture, process a service call dependency matrix by using a topological sorting algorithm based on service call characteristics, and generate a service migration priority sequence; A second unit is configured to select a service to be migrated according to the service migration priority sequence, parse interface definition information, and generate a unified service interface description file containing a service name and an interface path; A third unit is configured to parse the unified service interface description file to generate an abstract syntax tree, identify interface call nodes and inject link tracking probes, fill a code template by traversing the abstract syntax tree to generate service adaptation layer code, and inject the service adaptation layer code into a target microservice; A fourth unit is configured to write a service call identifier and a time-to-live value in a request header of the target microservice, and store the service call identifier and the time-to-live value in a distributed cache; A fifth unit is configured to collect request flow data of the target microservice, calculate a service load state by using a variant gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform flow control on service requests; A sixth unit is configured to monitor a running state of the target microservice in real time, trigger a fuse mechanism and dynamically adjust a recovery time according to an exponential backoff algorithm when a service exception rate exceeds a preset fuse threshold; A seventh unit is configured to use a sliding time window to count service level indicators after flow control, trigger service degradation processing according to a preset degradation threshold, and write a degradation processing result into the distributed cache; An eighth unit is configured to start an asynchronous timing task, and clean up service call identifiers in the distributed cache that are less than a current timestamp.

[0013] In a third aspect of the embodiment of the application, an electronic device is provided, comprising: A processor; A memory for storing processor-executable instructions; The processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0014] In a fourth aspect of the embodiments of the present application, a computer readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0015] In the embodiments of the present application, the service dependency relationship is processed by the topological sorting algorithm based on the service call characteristics, an ordered migration priority sequence is generated, the smooth migration of the microservice architecture is ensured, the inter-service dependency conflict problem in the traditional migration process is effectively avoided, and the migration success rate is improved; the unified service interface description file and the automatically generated service adaptation layer are adopted, the seamless connection between heterogeneous frameworks is realized, the link tracking probe injected provides full-link monitoring capability, the service call path is visualized, the development cost of the integration of heterogeneous systems is greatly reduced, and the system maintenance efficiency is improved; intelligent flow control is realized by the mutation gradient token bucket algorithm, a complete service management system is formed in combination with the fuse mechanism and the service degradation strategy, the system maintains stability in a high concurrency scenario, effectively deals with traffic fluctuations and service abnormalities, improves the overall resilience and reliability of the microservice architecture, and optimizes the resource utilization efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 A flowchart of the framework migration method of the heterogeneous microservice architecture of the embodiments of the present application is shown in Figure 2 An abstract syntax tree generation flowchart is shown in DETAILED DESCRIPTION

[0017] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme of the embodiments of the present application will be described clearly and completely below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0018] The technical scheme of the present application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described in some embodiments.

[0019] Figure 1 A flowchart of the framework migration method of the heterogeneous microservice architecture of the embodiments of the present application is shown in Figure 1 As shown in the figure, the method comprises: Scanning service interface information in the microservice architecture, processing a service call dependency matrix by a topological sorting algorithm based on service call characteristics, and generating a service migration priority sequence; According to the service migration priority sequence, a service to be migrated is selected, interface definition information is parsed, and a unified service interface description file containing a service name and an interface path is generated; The unified service interface description file is parsed to generate an abstract syntax tree, interface call nodes are identified and link tracking probes are injected, code templates are filled by traversing the abstract syntax tree to generate service adaptation layer code, and the service adaptation layer code is injected into the target microservice according to the dependency; A service call identifier and a time limit value are written into the request header of the target microservice, and the service call identifier and the time limit value are stored in the distributed cache; Request flow data of the target microservice is collected, the service load state is calculated by a variant gradient token bucket algorithm, token rate and bucket capacity parameters are generated, and flow control is performed on service requests; The running state of the target microservice is monitored in real time, and when the service exception rate exceeds a preset breaking threshold, a breaking mechanism is triggered and the recovery time is dynamically adjusted according to an exponential backoff algorithm; The service level indicators after flow control are counted by a sliding time window, and service degradation processing is triggered according to a preset degradation threshold, and the degradation processing result is written into the distributed cache; An asynchronous timing task is started to clean up service call identifiers in the distributed cache that are less than the current timestamp.

[0020] In one specific embodiment, the service interface information in the microservice architecture is comprehensively scanned, the dependency relationship matrix is constructed by analyzing the calling characteristics between services, and the topological sorting algorithm is applied to generate the priority sequence of service migration. Based on this priority sequence, the service to be migrated is selected, and the interface definition information is parsed to generate a unified service interface description file containing the service name and the interface path.

[0021] Then, the unified interface description file is parsed, converted into an abstract syntax tree structure, all interface call nodes are identified, and link tracking probes are injected into these nodes. By traversing the abstract syntax tree, the preset code template is filled to generate the service adaptation layer code, and these codes are integrated into the target microservice through dependency injection.

[0022] During service calling, a specific service call identifier and a corresponding time limit value are written into the request header of the target microservice, and these information is stored in the distributed cache for subsequent flow control and state monitoring. The request flow data of the target microservice is continuously collected, the current load state of the service is calculated according to these data, the rate parameters and capacity parameters required for flow control are dynamically generated, and accurate control of service requests is realized.

[0023] Real-time monitoring of the running state of the target microservice, when detecting that the service exception rate exceeds the preset fuse threshold, the fuse mechanism is triggered, and the service recovery time interval is dynamically adjusted according to the current situation. At the same time, the sliding time window method is used to count the various service level indicators after the flow control, when these indicators reach the preset degradation threshold, the service degradation processing is triggered, and the processing result is written into the distributed cache.

[0024] Starting an asynchronous timing task, periodically cleaning up the service call identifiers in the distributed cache whose time limit value is less than the current timestamp, ensuring that the cache space is effectively utilized. Through a series of steps, the present application realizes the smooth migration and intelligent flow control of services in the microservice architecture, effectively improving the stability and reliability.

[0025] In an optional implementation, the service interface information in the microservice architecture is scanned, and a topological sorting algorithm based on service call characteristics is used to process the service call dependency matrix to generate a service migration priority sequence, including: Scanning the service interface information in the microservice architecture, and constructing a service call dependency matrix based on the service interface information; Traversing the service call dependency matrix, counting the in-degree value of each service node, and adding the service node with in-degree value of zero to the candidate queue; Taking the head service node from the candidate queue, marking the head service node as visited state and adding it to the result sequence, deleting the out-edge of the head service node, and updating the in-degree value of the adjacent service node of the head service node; When the deletion of the out-edge causes the in-degree value of the adjacent service node to become zero, calculating the product of the service call frequency and response time delay of the adjacent service node as the priority weight, and inserting the adjacent service node into the corresponding position of the candidate queue according to the priority weight; Repeat the execution until the candidate queue is empty, and generate a migration priority sequence combined with service call characteristics; If there is an unvisited service node in the service call dependency matrix, disconnect the circular dependency edge between the unvisited service nodes in order from high to low according to the service call frequency, and add the source service node at the disconnected position to the candidate queue; Repeat the topological sorting process until all service nodes are visited to obtain a complete service migration priority sequence.

[0026] Microservice architecture migration often faces complex service dependency relationships, and improper migration order may cause services to be unavailable. In one embodiment, by scanning the service interface information in the microservice architecture, a service call dependency matrix is constructed based on the service interface information. The service interface information can be obtained by analyzing the data of the service registry center, the service call log or the request record of the API gateway. The service call dependency matrix is a two-dimensional matrix, where the matrix elements represent the call relationship of the row service to the column service, and the value is 1 indicating that there is a call relationship, and the value is 0 indicating that there is no call relationship.

[0027] For example, in an e-commerce microservice system, there are five microservices: user service, commodity service, order service, payment service and inventory service. By analyzing the service interface information, the following service call dependency matrix can be obtained: the user service calls the order service; the commodity service does not call other services; the order service calls the commodity service, the payment service and the inventory service; the payment service calls the user service; the inventory service does not call other services. In the constructed dependency matrix, the row represents the caller and the column represents the callee.

[0028] 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 the service. For the above e-commerce system, the in-degree value of the user service is 1 (called by the payment service), the in-degree value of the commodity 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).

[0029] The service node with an in-degree value of zero is added to the candidate queue. An in-degree value of zero means that the service is not dependent on other services and can be migrated first. In practical applications, there may be multiple services with an in-degree value of zero, in which case they can all be added to the candidate queue. In the above e-commerce system, there is no service node with an in-degree value of zero in the initial state, which indicates that there is a circular dependency in the system.

[0030] The first service node in the candidate queue is taken out and marked as visited and added to the result sequence. At the same time, the out-edge of the service node is deleted, i.e. the call relationship of the service to other services, and the in-degree value of the service node adjacent to the service node is updated.

[0031] When the deletion of an out-edge causes the in-degree value of a neighboring service node to be zero, the product of the service call frequency and the response latency of the neighboring service node is calculated as the priority weight. The service call frequency refers to the number of calls per unit time, and the response latency refers to the average time required for the service to respond to a request. The greater the priority weight, the higher the call cost of the service, which should be migrated earlier. According to the calculated priority weight, the neighboring service node is inserted into the corresponding position of the candidate queue.

[0032] For example, assuming that in the above e-commerce system, the call frequency of the commodity service is 100 times per minute, and the response latency is 20 milliseconds, the priority weight of the commodity service is 2000; the call frequency of the payment service is 50 times per minute, and the response latency is 50 milliseconds, the priority weight of the payment service is 2500; the call frequency of the inventory service is 80 times per minute, and the response latency is 15 milliseconds, the priority weight of the inventory service is 1200. When the out-edge of the order service is deleted, the in-degree values of the commodity service, the payment service, and the inventory service are all zero, and according to their priority weights, they are inserted into the candidate queue in the order of the payment service, the commodity service, and the inventory service.

[0033] The above process is repeated until the candidate queue is empty, and a migration priority sequence combined with service call characteristics is generated.

[0034] Due to the complexity of the micro-service architecture, there may be circular dependencies between services, which can cause the service nodes with an in-degree value of zero to be unable to be found. When there are unvisited service nodes in the service call dependency matrix, the circular dependencies need to be identified and measures need to be taken to remove the circular dependencies. The specific method is to disconnect the circular dependency edges between unvisited service nodes in order of the service call frequency from high to low, and add the source service node at the disconnected position to the candidate queue.

[0035] For example, in the above e-commerce system, 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. Assuming that the frequency of the user service calling the order service is 200 times per minute, the frequency of the order service calling the payment service is 150 times per minute, and the frequency of the payment service calling the user service is 100 times per minute. According to the principle of call frequency from high to low, the call relationship between the payment service and the user service should be disconnected, and the payment service should be added to the candidate queue.

[0036] The topological sorting process is repeated until all service nodes are visited, and a complete service migration priority sequence is obtained. For the above e-commerce system, assuming that the call relationship between the payment service and the user service is disconnected, the in-degree value of the payment service becomes zero, and it is added to the candidate queue. After performing topological sorting, the possible service migration priority sequence obtained is: payment service, user service, order service, commodity service, and inventory service.

[0037] In the actual migration process, the migration is performed in sequence according to the generated service migration priority sequence. For the above e-commerce system, the payment service is migrated first, then the user service, followed by the order service, then the commodity service, and finally the inventory service. Such a migration order can ensure service availability during migration and reduce migration problems caused by service dependencies.

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

[0039] In an optional implementation, the uniform service interface description file is parsed to generate an abstract syntax tree, interface call nodes are identified and link tracking probes are injected, service adaptation layer code is generated by traversing the abstract syntax tree to fill in the code template, and the service adaptation layer code is dependency injected into the target microservice, including: The uniform service interface description file is parsed based on a keyword dictionary and regular expression rules to generate a token sequence, and a hierarchical analysis method is used to parse the token sequence to generate an abstract syntax tree containing service interface information; In the abstract syntax tree, interface call entry nodes, parameter passing nodes, and return value nodes are identified, and call identification generation and transmission logic is injected into the interface call entry nodes, parameter recording and verification logic is injected into the parameter passing nodes, and result collection logic is injected into the return value nodes, generating an abstract syntax tree with injected link tracking probes; A code template library containing multiple programming languages is constructed, and the code templates in the code template library reserve placeholders for service interface information and tracking probe information; The abstract syntax tree with injected link tracking probes is traversed, and the service interface information and the tracking probe information are filled into the placeholder positions of the code templates to generate service adaptation layer code with a plug-in architecture; The service adaptation layer code is deployed to the target microservice through dependency injection.

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

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

[0042] 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 node, parameter passing node, and return value node. For the interface call entry node, call identification generation and passing logic are injected. Specifically, a globally unique trace ID (such as UUID format "550e8400-e29b-41d4-a716-446655440000") is generated and passed in the call context. For example, add the "X-Trace-Id" field in the HTTP request header, or set the trace attribute in the RPC context. For the parameter passing node, parameter recording and verification logic is injected, recording parameter name, type, and value, while verifying whether the parameter meets type and range constraints. For example, for the userId parameter of the order creation interface, verify whether it is a valid integer type and record its value for link tracking. For the return value node, result collection logic is injected, recording return value type, structure, and processing time, etc. These injected probe logic uses non-intrusive methods such as dynamic proxy, aspect-oriented programming, etc. to ensure that the original interface function behavior is not changed.

[0043] After the injection of the probes is completed, a code template library is constructed. The template library supports multiple programming languages, such as Java, Python, Go, JavaScript, and the like. The template of each language includes a service class definition template, an interface method template, a parameter processing template, a return value processing template, an exception processing template, and the like. The template reserves placeholders for filling in service name, interface name, parameter list, parameter type, return value type, and tracking logic, and the like. For example, the service interface template of the Java language can be as follows: "%SERVICE_NAME%Service { %RETURN_TYPE% %METHOD_NAME%(%PARAM_LIST%) throws %EXCEPTION_TYPE%;}", where %SERVICE_NAME%, %RETURN_TYPE%, and the like are placeholders.

[0044] The abstract syntax tree of the injected link tracking probe is traversed to extract service interface information and tracking probe information. The service interface information includes service name, interface name, parameter list, return value type, and the like; and the tracking probe information includes call identification generation code, parameter verification code, result collection code, and the like. The system fills the information into the placeholder positions of 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 OrderService interface definition, OrderServiceImpl implementation class, parameter verifier, result processor, and the like components. These components adopt a plug-in architecture, and are loosely coupled through interface definition and dependency injection, facilitating extension and maintenance.

[0045] The generated service adaptation layer code is deployed to the target microservice through a dependency injection manner. In a Spring framework environment, the adaptation layer components are registered as Spring Beans through an annotation manner (such as @Service, @Component). In the startup stage, the Beans are dynamically registered through a configuration class, and the dependency relationships between the Beans and other components are established. Runtime configuration options are provided to allow developers to adjust the detail level, sampling rate, and storage strategy of link tracking, and the like.

[0046] In the embodiment, the automatic generation from the unified service interface description file to the service adaptation layer code with link tracking capability is implemented, which greatly improves the microservice development efficiency, enhances the system observability, and reduces the diagnosis difficulty of the cross-service calling problem.

[0047] As shown in FIG. 1, a flowchart of an abstract syntax tree generation process is shown. Figure 2

[0048] ​In an alternative embodiment, the uniform service interface description file is parsed to generate a token sequence based on a keyword dictionary and regular expression rules, and a hierarchical analysis method is used to parse the token sequence to generate an abstract syntax tree containing service interface information, including: Strings are extracted one by one from the uniform service interface description file, the strings are matched with entries in the keyword dictionary, the matched strings are marked with type attributes, and regular expressions are used to extract syntax features for unmatched strings, each processed string and corresponding type attribute are combined to form a token sequence; The token sequence is traversed, for each token, the position index of the predecessor token and the successor token is recorded, the corresponding syntax rule is obtained, adjacent tokens with the same syntax rule are merged into a syntax unit, a tree structure is constructed according to the hierarchical relationship of the syntax unit, and an initial syntax tree is generated; The initial syntax tree is traversed, the interface information of each syntax unit node is extracted and stored in the attribute field of the node, node reference links are established according to the dependency relationship between nodes, and a complete abstract syntax tree is formed.

[0049] In a specific embodiment, a keyword dictionary is constructed, which contains commonly used keywords in service interface descriptions, such as "service", "function", "interface", "parameter", "returns", "struct", "enum", etc. At the same time, a set of regular expression rules are predefined for identifying syntax elements such as identifiers, strings, numbers, etc. For example, the regular expression for identifiers can be defined as "[a-zA-Z_][a-zA-Z0-9_]*", which means starting with a letter or underscore, followed by letters, numbers or underscores.

[0050] In the parsing process, the content of the uniform service interface description file is read, and the content is read by line and preprocessed, including removing comments and removing unnecessary white spaces. After preprocessing, the content is read character by character, and continuous characters are combined into a string buffer. For each string buffer, it is first matched with entries in the keyword dictionary. If a match is found, the string is marked with the corresponding type attribute, for example, "service" is marked as "SERVICE_KEYWORD" type. If no keyword is matched, predefined regular expression rules are used to match the syntax features of the string. For example, for the string "getUserInfo", since it is not a keyword, the regular expression for identifiers is used to match it, and it is marked as "IDENTIFIER" type.

[0051] In a specific example, consider a simple service interface description: "service UserService { function getUserInfo(userId: string): UserInfo;}". Identify "service" as a keyword, labeled as "SERVICE_KEYWORD"; identify "UserService" as an identifier, labeled as "IDENTIFIER"; identify "{" as a left brace, labeled as "LEFT_BRACE"; and so on. Finally, the description file is parsed into the following sequence of tokens: [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("}")]. After generating the token sequence, start the hierarchical analysis of the token sequence to construct the abstract syntax tree. Traverse the token sequence and record the position index of the predecessor and successor tokens 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.

[0052] According to the predefined syntax rules, identify the relationship between the tokens and merge adjacent tokens that meet certain syntax rules into a syntax unit. In this example, "SERVICE_KEYWORD("service")" and "IDENTIFIER("UserService")" can be merged into a syntax unit representing a service definition. Similarly, "FUNCTION_KEYWORD("function")", "IDENTIFIER("getUserInfo")", and related tokens of its parameters and return type can be merged into a syntax unit representing a function definition.

[0053] By analyzing the hierarchical relationship between syntax units, an initial syntax tree is constructed. In this example, the service definition syntax unit is the root node of the tree, and the function definition syntax unit is the child node of the service definition node. The parameter definition and return type definition are the child nodes of the function definition node.

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

[0055] According to the dependency relationship between nodes, reference links between nodes are established. For example, the function definition node will reference its parameter and return type definition nodes. If the return type "UserInfo" is a structure defined elsewhere, a reference link from the function definition node to the structure definition node will be established.

[0056] After the above processing is completed, a complete abstract syntax tree is generated, which contains all the interface information defined in the service interface description file and represents the dependency relationship between interface elements through the reference relationship between nodes. This abstract syntax tree can be used for further processing, such as code generation, interface document generation, etc.

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

[0058] In an optional implementation, request flow data of a target microservice is collected, a service load state is calculated through a variant gradient token bucket algorithm, token rate and bucket capacity parameters are generated, and flow control is performed on service requests, including: Request flow data of a target microservice is collected, time series analysis and statistical processing are performed on the request flow data, and a feature vector containing request rate, success rate, delay distribution, and resource occupation is obtained; Based on the distribution characteristics of the feature vector, the token pool is divided into multiple levels according to the load gradient, a variant factor and a conduction path are set between the levels, and a token bucket structure is determined; The token bucket structure is used to calculate the time decay of token consumption data of each level, collect token flow data of each level along the conduction path, obtain an exponential moving average reflecting the trend of load variation, and obtain a variation trigger threshold by weighting the exponential moving average according to a variation factor; The token generation rate is adjusted according to the exponential moving average of each level, the token conversion ratio between adjacent levels is calculated through the variation factor combined with the burst traffic feature in the feature vector, and the capacity configuration parameters of the token bucket of each level are generated. Based on the token flow data, the token consumption rate is determined, and when the token consumption rate exceeds the variation trigger threshold, the token migration quantity is determined based on the variation factor, and the dynamic reconstruction of the token bucket structure is performed.

[0059] In a specific embodiment, the data acquisition module continuously monitors the request traffic data of the target microservice. In actual application, the data acquisition module records the number of requests received by the microservice, the number of successfully completed requests, request processing delay, and resource indicators such as CPU usage and memory occupancy with a time window of 500 milliseconds. For example, for a payment processing microservice, it may receive 200 requests per second during peak hours, with a success rate of 98%, an average processing delay of 45 milliseconds, and a CPU usage of 65%. These raw data are processed to construct a feature vector F=(200, 0.98, 45, 0.65) as the basis for subsequent analysis.

[0060] The collected time series data is processed by a sliding window to calculate the request rate fluctuation range, success rate stability, 95% quantile value of delay, and peak value of resource utilization within the last 10 minutes. Through these statistical characteristics, the request pattern is identified, for example, in the payment microservice, it is found that there are obvious request peaks at 12:00-13:00 and 18:00-19:00 on weekdays, and the peak request rate is about 2.5 times higher than the average value, at this time the success rate drops to 92% and the processing delay rises to 75 milliseconds.

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

[0062] To accurately reflect the trend of load changes, time decay calculation is applied to the token consumption data of each level. For each level Li, the value of its token consumption Ci after time decay is Ci', and the decay coefficient β is 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 the L2 level in three consecutive time windows is 120, 150, and 180, respectively, the latest decay value is calculated as 180 + 150 x 0.85 + 120 x 0.85 = 394.2. 2

[0063] The token flow data of each level is collected along the conduction path, and the exponential moving average is calculated. Taking the L2 level as an example, its exponential moving average E2 is obtained by weighted combination of the current value and the historical average value, and the weight factor γ is set to 0.3. If the token consumption of the current window L2 is 150, and the exponential moving average of the last period is 130, then the new average E2 = 150 x 0.3 + 130 x 0.7 = 136. According to the variation factor of each level, the exponential moving average is modified to obtain the variation trigger threshold T2 = E2 x (1 + α2) = 136 x 1.4 = 190.4, which indicates that when the token consumption of the L2 level exceeds this value, the variation mechanism will be triggered.

[0064] Based on the exponential moving average of each level, the token generation rate is dynamically adjusted. For example, the token benchmark generation rate of the microservice in normal state is 100 tokens per second, when the exponential moving average of the L2 level increases to 1.2 times of the original, the token generation rate of the L2 level is adjusted to 100 x (1 - α2 x 0.2) = 92 tokens per second, which is appropriately reduced to prevent overload. At the same time, combined with the burst traffic characteristics identified in the feature vector, such as the burst traffic of payment service may reach 3 times of the daily traffic during holidays, sufficient capacity is reserved for each level token bucket, L1 bucket capacity is set to 300 tokens, L2 is 200, L3 is 150, and L4 is 80, to cope with burst requests.

[0065] Real-time monitoring of token consumption rate, when the token consumption rate of L2 level exceeds the variation trigger threshold 190.4, the number of tokens that need to be migrated is calculated based on the variation factor α2. Assuming that the part exceeding the threshold is 20 tokens, the number of tokens migrated to L3 level is 20 x α2 = 8, and the number of tokens remaining in L2 is 12. At the same time, the token bucket structure is dynamically reconstructed, the capacity of L3 level is increased to 165, and the capacity of L2 level is reduced to 188, to adapt to the current load situation.

[0066] ​Through this dynamic adjustment mechanism, token resources can be flexibly configured according to actual traffic changes, effectively controlling resource consumption while ensuring service quality. For example, during the e-commerce platform's flash sale activity, the request volume of the payment microservice surged to 500 requests per second. By rapidly adjusting the token bucket parameters and increasing the token proportion at the L3 and L4 levels, the core transaction requests were prioritized for processing, while non-critical requests were moderately throttled, maintaining a service success rate of over 94% and stable operation.

[0067] In an optional embodiment, the running state of the target microservice is monitored in real time, and when the service exception rate exceeds a preset fuse threshold, a fuse mechanism is triggered and the recovery time is dynamically adjusted according to an exponential backoff algorithm, including: The running state of the target microservice is monitored in real time, and the running state data of the target microservice is collected; Based on the running state data, the abnormal events are classified and counted within a sliding time window, and the abnormal rate of the target microservice is calculated by weighting according to a preset abnormal type weight; The abnormal rate is compared with the preset fuse threshold, and when the abnormal rate continuously exceeds the fuse threshold, the fuse mechanism is triggered and the backoff recovery process is entered; The initial recovery time is set according to the abnormal rate before the fuse, and the maximum retry limit is set, and the backoff base is calculated, which is determined by the product of the abnormal rate and a preset basic backoff coefficient; Based on the backoff base, an increasing recovery time sequence is generated according to a preset increment, and with the increase of the recovery attempt number, the current recovery attempt number is taken as an exponential power, the product of the backoff base and the recovery attempt number is calculated to obtain the current recovery time, and a random jitter factor is introduced to randomly offset the recovery time; After each recovery time arrives, a probe request is injected, and the success rate of the probe request is calculated, and when the success rate of the probe request exceeds a preset recovery threshold or reaches the maximum retry limit, the backoff recovery process is ended.

[0068] In a specific embodiment, the real-time monitoring module continuously collects running state data of the target microservice, including response time, request success rate, resource occupancy rate and other key indicators. The collection frequency is 10 times per second to ensure data timeliness. The monitoring data is collected through a lightweight proxy component embedded in the target microservice instance, which only occupies less than 5% additional resources.

[0069] The abnormal event classification statistics are performed in a 10-second sliding time window. The abnormal types include: timeout exception, weight 0.8; connection exception, weight 0.9; resource exhaustion exception, weight 1.0; business logic exception, weight 0.7; and dependent service exception, weight 0.6. For example, in a certain 10-second window, if 5 timeout exceptions, 3 connection exceptions, and 2 dependent service exceptions are monitored, the weighted number of exceptions calculated according to the weight of each abnormal type is: 5*0.8+3*0.9+2*0.6=7.9. If the total number of requests in the time window is 100, the abnormal rate is 7.9%.

[0070] The fuse trigger mechanism compares the abnormal rate with a preset fuse threshold. The fuse threshold is set to 5% by default and can be adjusted according to the importance of the microservice. When the abnormal rate exceeds the fuse threshold for 3 consecutive time windows, the fuse mechanism is triggered. After the fuse is triggered, the target microservice will reject new non-critical requests and return a preset degraded response, while entering the backoff recovery process.

[0071] When the backoff recovery process starts, the initial recovery time is set based on the abnormal rate before the fuse. The specific calculation method is: when the abnormal rate is between 5%-10%, the initial recovery time is set to 2 seconds; when the abnormal rate is between 10%-20%, the initial recovery time is set to 5 seconds; when the abnormal rate is between 20%-50%, the initial recovery time is set to 10 seconds; and when the abnormal 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 by configuration.

[0072] The calculation of the backoff base is determined by the product of the abnormal rate and the preset base backoff coefficient. The base backoff coefficient is 2 by default, and when the abnormal rate before the fuse is 15%, the backoff base is 15%*2=0.3. This backoff base will be used for subsequent backoff time calculations, reflecting the influence of fault degree on recovery strategy.

[0073] The generation of the incremental recovery time sequence adopts an exponential backoff strategy, while introducing 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, the basic recovery time for the 1st recovery attempt is 5+0.3*2 0 =5.3 seconds; for the 2nd, 5+0.3*2 1 =5.6 seconds; and for the 3rd, 5+0.3*2 2 =6.2 seconds. The random jitter factor is in the range of [-0.2, 0.2], and the basic recovery time is multiplied by (1+random jitter factor) to obtain the final recovery time. For example, if the basic recovery time for the 3rd recovery attempt is 6.2 seconds and the random jitter factor is 0.1, the final recovery time is 6.2*(1+0.1)=6.82 seconds.

[0074] The probe request injection is carried out after each recovery time arrives. The probe request simulates a normal service request, but with a special mark for statistics. The number of probe requests is gradually increased, 5 probe requests are injected for the first time, 10 probe requests are injected for the second time, 5 more are added each time for the third time and subsequent times, until the maximum value of 50 is reached. The probe request success rate is calculated as the number of successfully responded probe requests divided by the total number of probe requests. The preset recovery threshold is 95% by default, indicating that when the probe request success rate exceeds 95%, it is considered that the service has recovered to normal.

[0075] There are two end conditions for the backoff recovery process: one is that the probe request success rate exceeds the preset recovery threshold, and the other is that the maximum retry number limit is reached. When any of the conditions is met, the fuse state is released, and the target microservice resumes receiving new requests. If the backoff recovery process is ended due to reaching the maximum retry number limit, a serious alarm will be issued to prompt the operation and maintenance personnel to intervene manually.

[0076] The monitoring strategy after recovery includes setting an observation period, which is 60 seconds by default. During the observation period, if the abnormal rate exceeds the fuse threshold again, the fuse will be triggered immediately, and the backoff base is increased by 50%, which embodies the cumulative punishment mechanism to prevent frequent recovery-fuse cycles. After the observation period ends, the normal monitoring mode is resumed.

[0077] In the embodiment, through real-time state monitoring, multi-dimensional abnormality analysis, adaptive fuse triggering and intelligent backoff recovery, efficient fault isolation and self-healing capability in the microservice architecture are realized, and the overall system resilience is improved.

[0078] The framework migration system of the heterogeneous microservice architecture in the embodiment of the application comprises: A first unit is configured to scan service interface information in the microservice architecture, process a service call dependency matrix by using a topology sorting algorithm based on service call characteristics, and generate a service migration priority sequence; A second unit is configured to select a service to be migrated according to the service migration priority sequence, parse interface definition information, and generate a unified service interface description file containing a service name and an interface path; A third unit is configured to parse the unified service interface description file to generate an abstract syntax tree, identify an interface call node and inject a link tracking probe, fill a code template by traversing the abstract syntax tree to generate service adaptation layer code, and inject the service adaptation layer code into a target microservice; A fourth unit is configured to write a service call identifier and a time limit value into a request header of the target microservice, and store the service call identifier and the time limit value in a distributed cache; A fifth unit is configured to collect request flow data of the target microservice, calculate a service load state by using a variant gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform flow control on service requests. The sixth unit is configured to monitor the running state of the target microservice in real time, and when the service exception rate exceeds a preset fuse threshold, trigger a fuse mechanism and dynamically adjust the recovery time according to an exponential backoff algorithm; The seventh unit is configured to use a sliding time window to count the service level index after flow control, trigger service degradation processing according to a preset degradation threshold, and write the degradation processing result into a distributed cache; The eighth unit is configured to start an asynchronous timing task to clean up service call identifiers in the distributed cache that are less than a current timestamp.

[0079] In a third aspect, an electronic device is provided, including: a processor; a memory for storing processor-executable instructions; The processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0080] In a fourth aspect, a computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0081] The present application can be a method, device, system and / or computer program product. The computer program product can include a computer readable storage medium having computer readable program instructions stored therein, which are used to perform various aspects of the present application.

[0082] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. Framework migration method for heterogeneous microservice architecture, characterized by: include: Scan the service interface information in the microservice architecture, use a topological 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 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; Parse the unified service interface description file to generate an abstract syntax tree, identify interface call nodes and inject link tracing probes, traverse the abstract syntax tree to fill in the code template to generate the service adaptation layer code, and inject the service adaptation layer code dependencies into the target microservice; Write the service call identifier and the aging value into the request header of the target microservice, and store the service call identifier and the aging value in the distributed cache; Collect the request traffic data of the target microservice, calculate the service load status through the mutation gradient token bucket algorithm, generate token rate and bucket capacity parameters, and perform flow control on service requests; Monitor the running status of the target microservice in real time. When the service exception 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. Use a sliding time window to calculate the service level indicators after flow control, trigger service degradation processing according to the preset degradation threshold, and write the degradation processing results into the distributed cache; Start an asynchronous scheduled task to clear the service call identifiers in the distributed cache that are less than the current timestamp.

2. The method according to claim 1, characterized in that Scan the service interface information in the microservice architecture, use a topological sorting algorithm based on service call characteristics to process the service call dependency matrix, and generate a service migration priority sequence including: Scan the service interface information in the microservice architecture and build 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 zero in-degree value to the candidate queue; Taking the first service node from the candidate queue, marking the first service node as visited and adding it to the result sequence, deleting the outgoing edge of the first service node, and updating the in-degree value of the service node adjacent to the first service node; When the in-degree value of an adjacent service node becomes zero due to deleting an outgoing edge, the product of the service call frequency and the response delay of the adjacent service node is calculated as the priority weight, and the adjacent service node is inserted into the corresponding position of the candidate queue according to the priority weight; Repeat the execution until the candidate queue is empty, and generate a migration priority sequence that combines the service call characteristics; If there are unvisited service nodes in the service call dependency matrix, disconnect the cyclic dependency edges between the unvisited service nodes in descending order of service call frequency, and add the source service nodes at the disconnected positions to the candidate queue; The topological sorting process is repeated until all service nodes are visited, and a complete service migration priority sequence is obtained.

3. The method according to claim 1, characterized in that Parse the unified service interface description file to generate an abstract syntax tree, identify interface call nodes and inject link tracing probes, traverse the abstract syntax tree to fill in the code template to generate the service adaptation layer code, and inject the service adaptation layer code dependencies into the target microservice, including: Parsing the unified service interface description file to generate a tag sequence based on a keyword dictionary and regular expression rules, and parsing the tag sequence to generate an abstract syntax tree containing service interface information using a hierarchical analysis method; Identify the interface call entry node, parameter transfer node, and return value node in the abstract syntax tree, inject call identifier generation and transfer logic into the interface call entry node, inject parameter recording and verification logic into the parameter transfer node, and inject result collection logic into the return value node to generate an abstract syntax tree for injecting the link tracing probe; Building 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; Traversing the abstract syntax tree of the injected link tracing probe, filling the service interface information and the tracing probe information into the placeholder position of the code template, and generating a service adaptation layer code with a plug-in architecture; Deploy the service adaptation layer code to the target microservice through dependency injection.

4. The method according to claim 3, characterized in that Parsing the unified service interface description file based on a keyword dictionary and regular expression rules to generate a tag sequence, and using a hierarchical analysis method to parse the tag sequence to generate an abstract syntax tree containing service interface information includes: Extracting character strings one by one from the unified service interface description file, matching the character strings with entries in a keyword dictionary, marking type attributes for matched character strings, extracting grammatical features for unmatched character strings using regular expressions, and composing each processed character string and its corresponding type attribute into a marked sequence; Traversing the tag sequence, for each tag, recording the position index of the tag's predecessor and successor tags, obtaining the corresponding grammatical rules, merging adjacent tags with the same grammatical rules into grammatical units, constructing a tree structure according to the hierarchical relationship of the grammatical units, and generating an initial grammatical tree; The initial syntax tree is traversed, the interface information of each syntax unit node is extracted and stored in the attribute field of the node, and node reference links are established according to the dependency relationship between nodes to form a complete abstract syntax tree.

5. The method according to claim 1, wherein Collect the request traffic data of the target microservice, calculate the service load status through the mutation gradient token bucket algorithm, generate the token rate and bucket capacity parameters, and perform flow control on the service request, including: Collect the request traffic data of the target microservice, perform time series analysis and statistical processing on the request traffic data, and obtain a feature vector containing the request rate, success rate, delay distribution, and resource usage; Based on the distribution characteristics of the characteristic vector, the token pool is divided into multiple levels according to the load gradient, and mutation factors and conduction paths are set between the levels to determine the token bucket structure; Using the token bucket structure, a time decay calculation is applied to the token consumption data of each layer, and the token flow data of each layer is collected along the conduction path to obtain an exponential sliding average reflecting the load change trend. The exponential sliding average is weighted and corrected according to the variation factor to obtain a variation trigger threshold. The token generation rate is adjusted according to the exponential sliding average of each layer, and the token conversion ratio between adjacent layers is calculated by the mutation factor in combination with the burst traffic characteristics in the feature vector to generate the capacity configuration parameters of the token bucket of each layer; The token consumption rate is determined based on the token flow data. When the token consumption rate exceeds a mutation trigger threshold, the token migration quantity 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 Monitor the running status of the target microservice in real time. When the service exception 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. Monitor the running status of the target microservice in real time and collect the running status data of the target microservice; Based on the running status data, classify and count abnormal events within the sliding time window, and perform weighted calculation according to the preset abnormal type weight to obtain the abnormal rate of the target microservice; Comparing the abnormality rate with a preset fuse threshold, when the abnormality rate continuously exceeds the fuse threshold, triggering the fuse mechanism and entering the backoff recovery process; Set the initial recovery time based on the abnormality rate before the circuit breaker is blown, set the maximum retry limit, and calculate the backoff base, which is determined by multiplying the abnormality rate by a preset basic backoff coefficient; Based on the backoff base, an increasing recovery time sequence is generated according to a preset increment. As the number of recovery attempts increases, the current number of recovery attempts is used as an exponential power, and the product of this number and the backoff base is calculated to obtain the current recovery time. A random jitter factor is introduced to randomly offset the recovery time. After each recovery time arrives, a probe request is injected, and the success rate of the probe request is counted. When the success rate of the probe request exceeds a preset recovery threshold or reaches the maximum retry limit, the backoff recovery process is ended.

7. A framework migration system for a heterogeneous microservice architecture, used to implement the method according to any one of claims 1 to 6, characterized in that: include: The first unit is used to scan the service interface information in the microservice architecture, process the service call dependency matrix using a topological sorting algorithm based on service call characteristics, 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 including 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 link tracing probes, generate service adaptation layer code by traversing the abstract syntax tree to fill in the code template, and inject the service adaptation layer code dependency into the target microservice; The fourth unit is used to write a service call identifier and an aging value into a request header of a target microservice, and store the service call identifier and the aging value into a distributed cache; The fifth unit is used to collect the request traffic data of the target microservice, calculate the service load status through the mutation gradient token bucket algorithm, generate the token rate and bucket capacity parameters, and perform flow control on the service request; The sixth unit is used to monitor the operating status of the target microservice in real time. When the service exception 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 use a sliding time window to count the service level indicators after flow control, trigger service degradation processing according to a preset degradation threshold, and write the degradation processing results into a distributed cache; The eighth unit is used to start an asynchronous timed task and clear the service call identifiers in the distributed cache that are less than the current timestamp.

8. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the 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 a processor, the method according to any one of claims 1 to 6 is implemented.

Images