Service portrait-based micro-service dependency dynamic optimization merging method and system
By combining a service profiling engine and a merge decision engine, microservice dependencies are managed automatically, solving the problems of high costs and configuration drift caused by manual configuration, and improving system performance and resource utilization efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHONGDIAN DATA IND CO LTD
- Filing Date
- 2025-12-17
- Publication Date
- 2026-05-01
AI Technical Summary
Existing technologies suffer from high manual configuration costs and exponentially increasing configuration time when managing massive microservice dependencies. Furthermore, the need to manually update dependency configurations after service topology changes leads to high configuration drift rates, impacting system performance and troubleshooting efficiency.
By registering microservice IPs and ports through the service profiling engine, establishing interface proxy records, listening for connection requests and forwarding request headers and bodies, and using the merge decision engine to analyze interface parameters and result values, the system achieves automated discovery and real-time synchronization of service interfaces and dependencies, eliminating the bottleneck of manual configuration.
It achieves automated management of microservice dependencies, reduces manual configuration costs, improves system performance and troubleshooting efficiency, reduces configuration drift rate, and enhances system real-time performance and resource utilization efficiency.
Smart Images
Figure CN121967516A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of microservice systems and data processing technology, and in particular to a method and system for dynamic optimization and merging of microservice dependencies based on service profiles. Background Technology
[0002] Microservice architecture has become the mainstream design paradigm for modern distributed systems. It improves the scalability and flexibility of a system by breaking down a monolithic application into small, independent services. However, as the number of services increases and service interfaces are repeatedly developed, the dependencies between services become increasingly complex, leading to problems such as degraded system performance and increased risk of fault propagation.
[0003] Microservice architecture, as a distributed system design style, has undergone rapid evolution and widespread adoption over the past decade. Compared to traditional monolithic architecture, microservice architecture builds applications as a collection of small services, each running in its own process, communicating with each other through lightweight mechanisms (such as HTTP requests). While this architectural pattern offers advantages such as deployment flexibility, technological heterogeneity, and scalability, the surge in the number of microservices leads to inefficiencies in manually configuring dependencies. When the number of microservices exceeds 200, the efficiency of manually managing dependencies decreases by 73% (Google SRE Team 2023 Report); each additional hop in the inter-service call chain increases troubleshooting time by 40 minutes; and microservices lack runtime awareness, with 43% of production incidents stemming from incompatible dependency changes.
[0004] Existing technologies have high operational costs for manually maintaining massive microservice dependencies. When the number of microservices exceeds a critical point (N>200), the time spent on dependency configuration increases exponentially (for example, the configuration cost increases by 37% for every 100 new services added by a certain vendor). After a service topology change, the dependency configuration needs to be manually updated, and the response delay causes the configuration drift rate to be >70%. Summary of the Invention
[0005] This application provides a method and system for dynamic optimization and merging of microservice dependencies based on service profiles, which can realize the automated discovery and real-time synchronization of service interfaces and dependencies, eliminating the bottleneck of manual configuration.
[0006] This application provides a method for dynamic optimization and merging of microservice dependencies based on service profiles, including: Each microservice's own IP and port are pre-registered with the service profiling engine, and a proxy port is set to form an interface proxy record. When a microservice calls the interface of another microservice, the proxy IP and proxy port are configured instead. The interface proxy record includes the correspondence between the service IP, service port and the proxy-side optimizer IP and proxy port. Listen for external connection requests, determine the interface call based on the connection request, and forward the request header and request body of the connection request to the microservice system according to the called interface; In the microservice system, optimization and merging are performed based on the parameters and result values recorded in the request logs of each layer's interface.
[0007] This application provides a microservice dependency dynamic optimization and merging system based on service profiles, including a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the steps of the aforementioned microservice dependency dynamic optimization and merging method based on service profiles.
[0008] This application establishes a profile-driven pre-merge compatibility verification mechanism to prevent interface contract conflicts, achieve automated discovery and real-time synchronization of service interfaces and dependencies, and eliminate manual configuration bottlenecks.
[0009] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description
[0010] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of the overall process of the microservice dependency dynamic optimization and merging method based on service profile in an embodiment of this application. Detailed Implementation
[0011] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
[0012] In existing related technologies, code merging often leads to abnormal system behavior due to a lack of runtime state awareness. Interface protocol conflicts after merging account for 61% of production incidents (CNCF 2024 report). Traditional CI / CD processes cannot predict the impact of merging on dependent parties (mean time to recovery is 3.8 hours). This application provides a microservice dependency dynamic optimization merging method based on service profiling. This application's microservice dependency governance scheme, based on real-time service profiling and adaptive decision-making, has a core innovation in a three-layer closed-loop system of dynamic perception, intelligent decision-making, and precise execution. It feeds runtime profiling back to the code merging stage, achieving a development-operation closed loop and solving the problem of ambiguous dependency relationships in traditional solutions. Specifically, as shown... Figure 1 As shown, it includes the following steps: In step S101, each microservice's own IP address and port are pre-registered with the service profiling engine, and a proxy port is set to form an interface proxy record. When a microservice internally calls another microservice's interface, a proxy IP address and port are configured instead. The interface proxy record includes the mapping between the service IP address, service port, and the proxy-side optimizer IP address and proxy port. Existing Java-developed microservice systems expose the IP address and port of HTTP requests. In this specific example, the microservice first registers its own IP address and port with the service profiling engine and sets a proxy port to form an interface proxy record, for example: In step S102, external connection requests are monitored, and the interface call is determined based on the connection request. According to the called interface, the request header and body of the connection request are forwarded to the microservice system. In some specific examples, proxy interception technology is used, developed based on the Spring Boot framework, to monitor external HTTP requests, non-intrusively capture interface calls, and forward them to the microservice system by transparently passing the HTTP header and body.
[0013] In step S103, in the microservice system, optimization and merging are performed based on the parameters and result values recorded in the request records of each layer interface.
[0014] This application establishes a profile-driven pre-merge compatibility verification mechanism to prevent interface contract conflicts, achieve automated discovery and real-time synchronization of service interfaces and dependencies, and eliminate manual configuration bottlenecks.
[0015] In some embodiments, the method further includes: the service profiling engine parses and obtains the API interfaces of the microservices, generates a list of microservice interfaces, and writes it into the profiling library, such as: Then, exhaustively call the API interface and parameter combinations to initiate simulated requests to the service interface in batches.
[0016] In some embodiments, listening for external connection requests further includes: The external request first accesses the optimizer IP and proxy port, then uses the optimizer (which depends on the optimizer) to find the proxy configuration, and finally forwards the connection request to the actual IP and port of the microservice system. A unique request identifier is generated within the optimizer, and the service results are recorded in the profile database.
[0017] In some embodiments, recording service results to the profile database includes: Layered recording of API calls: When the (N-1)th microservice calls the Nth microservice, the request identifier remains unchanged, indicating it's the same request, and a layer N service record is generated. In some specific examples, the first-layer API call is recorded. When a microservice calls a second microservice, the request identifier remains unchanged, indicating it's the same request, and a second-layer service record is generated. Similarly, when the (N-1)th microservice continues to call the Nth microservice, the request identifier remains unchanged, indicating it is the same request, and a service record for the Nth layer is generated. In some embodiments, optimization and merging based on the parameters and result values recorded in the request logs of each interface layer includes: Analyze the parameters and result values of the request records from the first-level interfaces. If the parameters and result values are similar, merge the first-level interfaces; and, Analyze the parameters and result values of the current layer and the next layer in the connection request. If the parameters and result values are similar, merge the upper and lower layers.
[0018] For example, if the parameters and result values of interfaces a and c are the same, then when requesting interface address c, the request can be directly forwarded to interface address a, and the two interfaces are actually merged into one.
[0019] Analyze the parameters and result values of the current layer and the next layer for each request. If the parameters and result values are similar, merge the upper and lower layers. For example, if the parameters and result values of the first-layer interface o are the same as those of the second-layer interface p, then when requesting address o, it can be directly forwarded to address p, effectively merging the two interfaces into one.
[0020] In some embodiments, parameter similarity is determined by comparing parameter types and order using the edit distance algorithm, and calculating the similarity of parameter sets using the Jaccard coefficient. For example, parameters are marked as similar when the similarity is ≥0.9.
[0021] In some embodiments, the determination of result similarity is implemented using a result structure similarity detection algorithm, including: Convert the resulting structure into a JSON string, and then into a dictionary object; Remove built-in key names and use the edit distance algorithm to calculate key name similarity; The average value is used as the result similarity based on the key name, value, and structural similarity. For example, a similar result is marked as ≥0.8.
[0022] When parameters and results are similar, interfaces are identified as similar and marked as eligible for merging. The merging decision engine updates the service profile database, merges similar interfaces, and then notifies the service profile engine to exhaustively call the interfaces before and after the merge. If the interface results before and after the merge are still similar, the merge is normal; if the interface results before and after the merge deviate significantly, the merge is abnormal, and the merge will be released and a new decision will be made.
[0023] In the development environment, service profiles can be identified and merged repeatedly to continuously and promptly discover duplicate interfaces in various microservices for system optimization.
[0024] Compared to existing service affinity deployment schemes (physical layer optimization) and dependency mining techniques (static analysis layer), this application's microservice dependency dynamic optimization and merging method based on service profiling achieves breakthrough improvements in three dimensions: real-time performance, closed-loop governance, and cost control. This application integrates interface discovery and runtime profiling to achieve bidirectional control. The merging decision engine can assess a 30% reduction in microservices, and the number of resources required for the same business volume can be reduced by 50%.
[0025] This application also proposes a microservice dependency dynamic optimization and merging system based on service profiles, including a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the steps of the aforementioned microservice dependency dynamic optimization and merging method based on service profiles.
[0026] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0027] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0028] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0029] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.
Claims
1. A microservice dependency dynamic optimization and merging method based on service profiling, characterized in that, include: Each microservice's own IP and port are pre-registered with the service profiling engine, and a proxy port is set to form an interface proxy record. When a microservice calls the interface of another microservice, the proxy IP and proxy port are configured instead. The interface proxy record includes the correspondence between the service IP, service port and the proxy-side optimizer IP and proxy port. Listen for external connection requests, determine the interface call based on the connection request, and forward the request header and request body of the connection request to the microservice system according to the called interface; In the microservice system, optimization and merging are performed based on the parameters and result values recorded in the request logs of each layer's interface.
2. The microservice dependency dynamic optimization and merging method based on service profile as described in claim 1, characterized in that, Also includes: The service profiling engine parses and obtains the API interfaces of microservices, generates a list of microservice interfaces, and writes it into the profiling library. as well as, Exhaustively call API interfaces and parameter combinations to initiate simulated requests to service interfaces in batches.
3. The microservice dependency dynamic optimization and merging method based on service profile as described in claim 2, characterized in that, Listening for external connection requests also includes: The external request first accesses the optimizer IP and proxy port, then uses the optimizer to find the proxy configuration and forwards the connection request to the actual IP and port of the microservice system. A unique request identifier is generated within the optimizer, and the service results are recorded in the profile database.
4. The microservice dependency dynamic optimization and merging method based on service profile as described in claim 3, characterized in that, Recording service results into the profile database includes: Layered record of interface calls: When the (N-1)th microservice calls the Nth microservice, the request identifier remains unchanged, indicating it is the same request, and a layer N service record is generated.
5. The microservice dependency dynamic optimization and merging method based on service profile as described in claim 1, characterized in that, Based on the parameters and result values recorded in the request logs of each interface layer, optimization and merging are performed, including: Analyze the parameters and result values of the request records from the first-level interfaces. If the parameters and result values are similar, merge the first-level interfaces; and, Analyze the parameters and result values of the current layer and the next layer in the connection request. If the parameters and result values are similar, merge the upper and lower layers.
6. The microservice dependency dynamic optimization and merging method based on service profile as described in claim 5, characterized in that, To determine parameter similarity, the edit distance algorithm is used to compare parameter types and order, and the similarity of parameter sets is calculated in combination with the Jaccard coefficient.
7. The microservice dependency dynamic optimization and merging method based on service profile as described in claim 5, characterized in that, The similarity of the results is determined using a result structure similarity detection algorithm, including: Convert the resulting structure into a JSON string, and then into a dictionary object; Remove built-in key names and use the edit distance algorithm to calculate key name similarity; The average value is determined as the result similarity based on the key name, value, and structural similarity.
8. A microservice dependency dynamic optimization and merging system based on service profiling, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, which, when executed by the processor, implements the steps of the microservice dependency dynamic optimization and merging method based on service profile as described in any one of claims 1 to 7.