Method for dynamically calculating correlation degree in micro-service system operation and maintenance

Abstract

The application discloses a correlation degree dynamic calculation method in micro-service system operation and maintenance, and relates to the technical field of software engineering, comprising: collecting micro-service call chain data corresponding to each software function in a preset micro-service system to generate a transaction data set; for any one target function in each software function, the traffic weight of each micro-service under the target function and the exponential decay position weight are calculated in combination with the transaction data set, the access intensity of each micro-service is obtained by comprehensively considering the traffic weight of each micro-service and the exponential decay position weight; the time contribution degree of the execution time of each micro-service to the total execution time of the target function is calculated; the fusion weight coefficient is determined based on the system type corresponding to the preset micro-service system, and the correlation degree between the target function and each micro-service is generated in combination with the fusion weight coefficient, the access intensity and the time contribution degree. The application solves the technical problem of poor quantification effect of the correlation degree between software functions and micro-services.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software engineering, and particularly relates to a correlation degree dynamic calculation method in micro-service system operation and maintenance. BACKGROUND

[0002] With the full transition of enterprise application architecture to micro-service, the system complexity presents exponential growth, and how to effectively manage the highly distributed and dynamically evolving micro-service system becomes a core challenge. For the management of the micro-service system, the existing management method generally adopts the means of software function and micro-service correlation degree analysis. However, the traditional software function and micro-service correlation degree analysis method has significant limitations: when facing dynamic characteristics such as micro-service instance elasticity, asynchronous communication and implicit dependency, it is difficult to accurately capture real-time correlation, leading to difficulty in discovering micro-service system performance bottlenecks, low efficiency in fault root cause positioning, and lack of data basis for architecture evolution. Therefore, there is a problem of poor quantification effect of software function and micro-service correlation degree in the current micro-service system management.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a correlation degree dynamic calculation method in micro-service system operation and maintenance, an electronic device, a storage medium and a computer program product, aiming at solving the technical problem of poor quantification effect of software function and micro-service correlation degree.

[0005] To achieve the above purpose, the present application provides a correlation degree dynamic calculation method in micro-service system operation and maintenance, which comprises:

[0006] Collecting micro-service call chain data corresponding to each software function in a preset micro-service system to generate a transaction data set;

[0007] For any one target function in the software functions, the traffic weight and the exponentially decaying position weight of each micro-service under the target function are calculated in combination with the transaction data set, and the access intensity of each micro-service is obtained by comprehensively considering the traffic weight and the exponentially decaying position weight of each micro-service;

[0008] The time contribution degree of the execution time of each micro-service to the total execution time of the target function is calculated;

[0009] The fusion weight coefficient is determined based on the system type corresponding to the preset micro-service system, and the correlation degree between the target function and each micro-service is generated in combination with the fusion weight coefficient, the access intensity and the time contribution degree.

[0010] In an embodiment, the step of collecting the microservice call chain data corresponding to each software function in the preset microservice system and generating a transaction dataset comprises:

[0011] intercepting, by a preset probe, a microservice call behavior corresponding to a target function in a preset microservice system based on a bytecode enhancement technique, the microservice call behavior corresponding to at least one microservice;

[0012] recording, by the preset probe, call chain data of each microservice in the microservice call behavior, cleaning the call chain data, and reconstructing each call chain in the call chain data to generate a transaction dataset.

[0013] In an embodiment, the step of recording, by the preset probe, call chain data of each microservice in the microservice call behavior comprises:

[0014] In the case where the preset probe requests to enter the microservice, a call link identifier is created and a start timestamp of the microservice is recorded, and in the case where the preset probe requests to leave the microservice, an end timestamp of the microservice is recorded;

[0015] calculating a first running time of the microservice based on the start timestamp and the end timestamp, determining a second running time of the target function based on the first running time, and counting a first call frequency of the microservice and a second call frequency of the target function;

[0016] In the case where the target function is a cross-service call behavior, call link context information is propagated through a preset request header field to record a complete microservice call link, the microservice call link including each microservice called by the target function;

[0017] The call link identifier, the start timestamp, the end timestamp, the first running time, the second running time, the first call frequency, the second call frequency, and the microservice call link are used as call chain data of each microservice.

[0018] In an embodiment, the step of cleaning the call chain data and reconstructing each call chain in the call chain data to generate a transaction dataset comprises:

[0019] excluding invalid call information in the call chain data and short-time call information with a first running time lower than a preset time threshold, and supplementing missing data in the call chain data;

[0020] grouping the call chain data according to the call link identifier to obtain each service call information, and sorting the each service call information based on the start timestamp to obtain each call chain.

[0021] The call chains are taken as a service call chain set, the call chains and the service time consumption information corresponding to the call chains are taken as a service trace chain set, and the service call chain set and the service trace chain set are taken as a transaction data set, wherein the service time consumption information is determined by the call chain data.

[0022] In an embodiment, the transaction data set includes a service call chain set, and the step of calculating the traffic weight and the exponentially decaying position weight of each microservice under the target function based on the transaction data set includes:

[0023] extracting a service call chain corresponding to the target function from the service call chain set, recording the total number of calls of the target function and each microservice in the service call chain;

[0024] For any one of the microservices, recording the number of calls and the position depth of the microservice in the service call chain;

[0025] calculating the traffic weight of the microservice based on the number of calls and the total number of calls, and calculating the exponentially decaying position weight of the microservice based on a decay coefficient and the position depth, wherein the decay coefficient is determined by the depth of the service call chain.

[0026] In an embodiment, the transaction data set includes a service trace chain set, and the step of calculating the time contribution degree of the execution time of each microservice to the total execution time of the target function includes:

[0027] extracting a trace call chain corresponding to the target function from the service trace chain set, extracting each microservice in the trace call chain and the service time consumption information corresponding to the trace call chain, and determining the execution time of each microservice and the total execution time of the target function based on the service time consumption information;

[0028] mapping the implementation process of the target function to a cooperative game process, wherein each microservice subset is an alliance in the cooperative game process, the contribution value of the alliance in the cooperative game process is the execution time of each microservice subset, and each microservice subset is a subset composed of microservices;

[0029] For any one of the microservices, calculating the difference between the contribution values before and after the microservice joins each optional alliance to obtain the marginal contribution value of the microservice under the corresponding optional alliance, wherein the optional alliance is a microservice subset that does not include the microservice;

[0030] The marginal contribution values of the microservices under each optional alliance are weighted and averaged to obtain an average marginal contribution value of the microservices, and a time contribution degree is generated based on the average marginal contribution value and the total execution time.

[0031] In an embodiment, the step of determining the fusion weight coefficient based on the system type corresponding to the preset microservice system comprises:

[0032] In the case where the system type corresponding to the preset microservice system is access-intensive, the fusion weight coefficient is set as a first weight coefficient;

[0033] In the case where the system type corresponding to the preset microservice system is performance-sensitive, the fusion weight coefficient is set as a second weight coefficient;

[0034] In the case where the system type corresponding to the preset microservice system is balanced, the fusion weight coefficient is set as a third weight coefficient.

[0035] In addition, to achieve the above-mentioned purpose, the present application also proposes a correlation degree dynamic calculation method system in microservice system operation and maintenance, the correlation degree dynamic calculation method system in microservice system operation and maintenance comprises:

[0036] A data acquisition module is configured to acquire microservice call chain data corresponding to each software function in a preset microservice system, and generate a transaction data set;

[0037] An access intensity calculation module is configured to calculate, for any one target function in the software functions, traffic weights and exponentially decaying position weights of microservices under the target function in combination with the transaction data set, and obtain access intensities of the microservices by comprehensively considering the traffic weights and exponentially decaying position weights of the microservices;

[0038] A time contribution degree calculation module is configured to calculate a time contribution degree of execution time of the microservices to total execution time of the target function;

[0039] A correlation degree calculation module is configured to determine a fusion weight coefficient based on a system type corresponding to the preset microservice system, and generate a correlation degree between the target function and the microservices in combination with the fusion weight coefficient, the access intensities and the time contribution degrees.

[0040] In addition, to achieve the above-mentioned purpose, the present application also proposes an electronic device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the correlation degree dynamic calculation method in microservice system operation and maintenance as described above.

[0041] In addition, to achieve the above object, the application further provides a storage medium, which is a computer readable storage medium, and a computer program is stored on the storage medium, and the computer program is executed by a processor to implement the steps of the method for dynamically calculating correlation degrees in micro-service system operation and maintenance.

[0042] In addition, to achieve the above object, the application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the method for dynamically calculating correlation degrees in micro-service system operation and maintenance.

[0043] The application provides a method for dynamically calculating correlation degrees in micro-service system operation and maintenance, which comprises: collecting micro-service call chain data corresponding to each software function in a preset micro-service system to generate a transaction data set; for any target function in each software function, calculating the traffic weight and the exponentially decaying position weight of each micro-service under the target function in combination with the transaction data set, and comprehensively obtaining the access intensity of each micro-service by integrating the traffic weight and the exponentially decaying position weight of each micro-service; calculating the time contribution degree of the execution time of each micro-service to the total execution time of the target function; determining a fusion weight coefficient based on the system type corresponding to the preset micro-service system, and generating the correlation degree between the target function and each micro-service in combination with the fusion weight coefficient, the access intensity and the time contribution degree.

[0044] The traditional software function and micro-service correlation degree analysis method has significant limitations: when facing dynamic characteristics such as micro-service instance elasticity, asynchronous communication and implicit dependency, it is difficult to accurately capture real-time correlation, leading to difficulty in discovering micro-service system performance bottlenecks, low fault root cause positioning efficiency and lack of data basis for architecture evolution. The application collects call chain data to comprehensively and accurately record all micro-services and their interaction details involved in the software function execution process, providing a rich data basis for subsequent analysis, solving the dynamic call and implicit dependency problems that cannot be captured by traditional static analysis, quantifying the access intensity of micro-services more finely by introducing traffic weight and exponentially decaying position weight, not only capturing the dynamic access mode of micro-services, but also revealing their key role in the system architecture, providing in-depth insight into the performance impact of micro-services by calculating the marginal contribution of each micro-service to the total execution time of the software function, which helps to identify performance bottlenecks and optimize the critical path, and by determining the fusion weight coefficient according to the system type, the access intensity and the time contribution degree can be more reasonably integrated to generate more accurate correlation degree indicators, which helps to accurately evaluate the importance of micro-services to software functions in different scenarios, and provides strong support for system optimization and fault troubleshooting. BRIEF DESCRIPTION OF DRAWINGS

[0045] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings required by the embodiments or the prior art description will be briefly introduced as follows. Obviously, the drawings are only used to explain the technical solutions of the present application, and thus the technical solutions of the present application can also be implemented without the accompanying drawings.

[0047] Figure 1 A flowchart provided for the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment 1 of the present application;

[0048] Figure 2 A relational graph provided for the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment 1 of the present application;

[0049] Figure 3 A flowchart provided for the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment 2 of the present application;

[0050] Figure 4 An access intensity calculation flowchart provided for the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment 2 of the present application;

[0051] Figure 5 An overall flowchart provided for the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment 2 of the present application;

[0052] Figure 6 A data collection flowchart provided for the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment 2 of the present application;

[0053] Figure 7 A module structure diagram provided for the correlation degree dynamic calculation system in Embodiment of the present application;

[0054] Figure 8 A device structure diagram of a hardware running environment involved in the correlation degree dynamic calculation method in the microservice system operation and maintenance in Embodiment of the present application.

[0055] The object implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0056] It should be understood that the first embodiment described herein is only used to explain the technical solutions of the present application, and is not used to limit the present application.

[0057] For better understanding of the technical solutions of the present application, the following will be described in detail in combination with the drawings of the specification and specific embodiments.

[0058] The main solution of the first embodiment of the present application is: collecting microservice call chain data corresponding to each software function in a preset microservice system to generate a transaction data set; for any target function in each software function, calculating the traffic weight and exponentially decaying position weight of each microservice under the target function in combination with the transaction data set, and comprehensively obtaining the access intensity of each microservice by the traffic weight and exponentially decaying position weight of each microservice; calculating the time contribution degree of the execution time of each microservice to the total execution time of the target function; determining a fusion weight coefficient based on the system type corresponding to the preset microservice system, and generating the correlation degree between the target function and each microservice in combination with the fusion weight coefficient, the access intensity and the time contribution degree.

[0059] In the first embodiment, for the convenience of description, the following describes the correlation degree dynamic calculation method system in the microservice system operation and maintenance as the execution subject.

[0060] Currently, the methods for measuring the correlation between software functions (SF) and microservices (MS) mainly include the following:

[0061] Correlation degree calculation based on feature characteristic weighted evaluation: the existing technology quantifies the correlation weight between functions and microservices by predefining feature characteristics (such as data storage, timeliness, function expansion, etc.), which provides a basis for monolithic application decomposition. This method usually relies on human experience and preset rules, divides the characteristics into six categories such as prerequisite, data, mixed openness, and calculates the weighted sum to determine the correlation degree.

[0062] Static code analysis to determine the correlation between functions and microservices: by directly analyzing the dependency relationship, interface call, and module relationship in the code, the correlation between software functions and microservices is inferred. For example, static analysis tools can build a call dependency graph between functions and methods to reveal explicit dependencies at the code level.

[0063] Dependency mapping based on distributed tracking: modern application performance management (APM) tools, such as Dynatrace Smartscape, AppDynamics and Skywalking, automatically discover and visualize the topological dependency relationship between microservices by collecting runtime distributed tracking data (Trace and Span). These tools can display the call path, execution time, error rate, etc. between services, thereby helping to understand system interaction and troubleshooting.

[0064] The above existing technologies have the following shortcomings in measuring the correlation between software functions and microservices:

[0065] (1) Static and dynamic disconnection:

[0066] The method based on function feature weighted evaluation may not accurately reflect the actual runtime function and dynamic association of microservices. In complex and changing business scenarios, manually adjusting the weights will consume a lot of manpower, and the accuracy is difficult to guarantee. The inherent static nature of this method makes it difficult to capture the dynamic behavior commonly seen in microservice architecture, such as the impact of elasticity, traffic fluctuations, or runtime configuration changes on inter-service association strength.

[0067] Although static code analysis can discover dependencies at the code level (such as method call graphs), it cannot capture runtime dynamic calls, data flow, and association strength at the business logic level. For example, a microservice may not directly call another microservice in the code, but communicate asynchronously through a message queue or event bus. This implicit dependency is difficult to identify through static analysis. For the asynchronous communication and event-driven patterns commonly seen in microservice architecture, the limitations of static analysis are more apparent. In distributed systems, dynamic creation and destruction of service instances, network latency, and resource contention at runtime can all lead to actual dependencies and performance bottlenecks that differ greatly from static analysis results.

[0068] (2) Lack of deep insight into business logic:

[0069] Although existing APM tools provide distributed tracing and topology discovery, they usually focus on technical-level call chains, performance indicators (such as latency, throughput, error rate), and infrastructure dependencies. They can identify direct calls between services, but it is difficult to quantify the degree of dependence of a single software function (i.e., a business operation) on multiple microservices, as well as the "contribution" or "importance" of each microservice to the completion of that function. For example, in a "user order" business transaction, multiple microservices such as order service, inventory service, and payment service may be involved. Existing tools can show the call order and response time of these services, but it is difficult to directly quantify the "actual contribution" of each microservice to the successful completion of the "user order" overall business function or its total response time. This disconnection between the technical level and the business logic level makes it difficult for the operations team to accurately quantify the impact on the business when performing microservice splitting, refactoring, or fault localization. For example, when a business function performance decreases, it is difficult to accurately determine which microservice has the "greatest responsibility" for the performance decrease, or which microservice optimization can bring the greatest business value improvement. Existing APM tools in business transaction association usually use attribute value comparison, threshold, or clustering algorithms for association, rather than using a strict game theory approach to quantify contributions. This indicates that although they can identify business flows, they still have shortcomings in deeply quantifying the actual contributions of each component to business results.

[0070] (3) Lack of automation and real-time performance:

[0071] Manual adjustment of weights and static analysis are costly to maintain and difficult to ensure real-time performance and accuracy in the face of rapid iteration and dynamic scaling of microservices architecture. Each time the business logic or microservice deployment changes, a large amount of manual intervention is required to update the associated rules or analyze the code, which is not sustainable in a continuous delivery microservices environment.

[0072] Although some APM tools provide automatic discovery and real-time monitoring, their correlation calculation may still be based on preset rules or simple statistics rather than deep data mining and contribution quantification, resulting in the inability to timely and accurately reflect complex dynamic correlations. For example, when the system load pattern changes, the call frequency and dependency strength between services may also change, and existing tools may not be able to adjust their correlation evaluation in real time and in detail.

[0073] The present application provides a solution that collects call chain data to comprehensively and accurately record all microservices involved in the execution of software functions and their interaction details, providing a rich data foundation for subsequent analysis, solving the problem of dynamic calls and implicit dependencies that traditional static analysis cannot capture, and quantifying the access intensity of microservices more finely by introducing traffic weights and exponentially decaying position weights, not only capturing the dynamic access patterns of microservices, but also revealing their key role in the system architecture. Through cooperative game theory, the marginal contribution of each microservice to the total execution time of software functions can be calculated fairly, providing in-depth insights into the performance impact of microservices, helping to identify performance bottlenecks and optimize critical paths, and by determining the fusion weight coefficient according to the system type, the access intensity and time contribution can be more reasonably integrated to generate more accurate correlation indicators, helping to accurately assess the importance of microservices to software functions in different scenarios, and providing strong support for system optimization and troubleshooting.

[0074] Specifically, the following outstanding effects are achieved:

[0075] (1) Improve system stability and reliability: Accurate correlation analysis can help development and operations teams better understand the complex dependencies between microservices. By identifying key microservices and their contribution to business functions, capacity planning, resource allocation, and troubleshooting can be more effectively performed. When a system problem occurs, the microservice that contributes the most to the affected software function can be quickly located, reducing the mean time to recover (MTTR) and improving system reliability and availability. Container automatic scaling can automatically adjust resources according to the needs of the application, ensuring that the application has the required computing power while avoiding resource waste. This flexibility and efficiency make containerized deployment more competitive in terms of resource utilization and cost.

[0076] (2) Optimize resource utilization and cost control: Understanding the degree of software function dependence on microservices and the contribution of each microservice helps allocate computing resources more reasonably. For example, more resources can be tilted to microservices that contribute more to core business functions, or optimized for those that are frequently called but have lower contribution. This helps deal with traffic surges or declines, reducing operating costs and improving efficiency.

[0077] (3) Support microservice architecture evolution and refactoring: During the evolution of the microservice architecture, accurate correlation data is a key basis for service splitting, merging or refactoring. By quantifying the coupling strength and functional correlation between microservices, we can avoid unreasonable splitting that leads to high coupling or low cohesion, and build a healthier and more maintainable microservice system.

[0078] (4) Accelerate fault diagnosis and root analysis: When software performance declines or errors occur, this method can provide a clear ranking of microservice contribution, helping engineers quickly identify the most likely cause of the problem. This is more efficient than traditional layer-by-layer troubleshooting, significantly reducing fault diagnosis time.

[0079] It should be noted that the execution subject of the first embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc. electronic device, or a system, application, program, etc. that can implement the above functions. The following is an example of a correlation dynamic calculation method system in microservice system operation and maintenance.

[0080] All actions to obtain signals, information or data in this application are carried out in accordance with the corresponding data protection regulations and policies of the country where the device is located, and with the authorization of the corresponding device owner.

[0081] Based on this, the embodiments of the present application provide a correlation dynamic calculation method in microservice system operation and maintenance, referring to Figure 1 , Figure 1 The flowchart of the first embodiment of the correlation dynamic calculation method in the microservice system operation and maintenance of the present application is shown in the figure.

[0082] In this embodiment, the correlation dynamic calculation method in the microservice system operation and maintenance includes steps S01-S04:

[0083] Step S01, collect the microservice call chain data corresponding to each software function in the preset microservice system, and generate a transaction data set;

[0084] It should be noted that the preset microservice system refers to an application system that has been deployed and run in a microservice architecture, and contains multiple independently deployed and cooperatively working microservices. The software function refers to a specific business function provided by the preset microservice system, such as "user ordering", "payment processing", and the like. The microservice call chain data is data flow that records all microservice call sequences, timestamps, execution states and the like involved in the execution process of the software function, for example, the "user ordering" function may successively call the order service, the inventory service and the payment service. The transaction data set is a transaction format suitable for subsequent analysis after the call chain data is classified according to the software function. Each transaction represents a complete execution path of a software function.

[0085] In addition, it should be noted that the call chain data during the execution of each software function in the microservice system can be collected in real time by deploying a distributed tracking tool. The distributed tracking tool can be Skywalking. SkyWalking is an open source application performance monitoring (APM) and observability analysis platform, mainly used for monitoring and diagnosis of distributed systems and microservice architectures.

[0086] It can be understood that, since the traditional method is difficult to accurately capture the real-time call relationship between microservices when facing the elasticity of microservice instances, asynchronous communication and implicit dependencies, step S01 is performed to generate a detailed transaction data set by collecting microservice call chain data in real time, which comprehensively records the microservices and their interaction involved in the execution process of the software function, provides a rich and accurate data basis for subsequent analysis, and ensures the comprehensiveness and real-time of the correlation calculation. Compared with the traditional static analysis method, the present application can dynamically capture the call relationship between microservices, including implicit dependencies and asynchronous communication, so as to more accurately reflect the actual running state of the microservice system.

[0087] In step S02, for any target function in each software function, the traffic weight and the exponentially decaying position weight of each microservice under the target function are calculated in combination with the transaction data set, and the access intensity of each microservice is obtained by comprehensively considering the traffic weight and the exponentially decaying position weight of each microservice.

[0088] It should be noted that the traffic weight is used to reflect the frequency of the microservice being called. The exponentially decaying position weight reflects the importance of the microservice in the architecture level in the call chain. The exponentially decaying position weight decreases with the increase of the call chain depth, for example, in the call chain "T1=[gateway, order service, payment service]", the exponentially decaying position weight of the gateway is the highest, and the exponentially decaying position weight of the payment service is the second. The access intensity comprehensively considers the traffic weight and the position weight, and can quantify the actual access intensity of the microservice. The access intensity of the microservice with high frequency access and close to the call chain entrance is higher.

[0089] Additionally, it should be noted that for each target function, all its call chains are extracted from the transaction dataset. The traffic weight and exponentially decaying position weight of each microservice in each call chain are calculated. Combining the data from all call chains, the weighted access strength of each microservice is calculated. The formula for calculating the weighted access strength is as follows:

[0090]

[0091] in, For the first Weighted access intensity of each microservice For the first Traffic weight of each microservice For the first The exponential decay position weights of each microservice are calculated. After calculating the weighted access strength of each microservice under each target function, the weighted access strengths of the same microservices under each target function are added together to obtain the final access strength of the microservice.

[0092] Understandably, traditional methods often rely on static weights or simple statistics, which cannot accurately reflect the actual access intensity and architectural importance of microservices in dynamic environments. Therefore, step S02 is performed by calculating traffic weights (reflecting the frequency of microservice calls) and exponentially decaying position weights (considering the architectural importance of microservices in the call chain). Step S02 can more precisely quantify the access intensity of microservices. Services with high-frequency access and close to the call chain entry point will receive higher scores, thus revealing the key role of microservices in the system. Compared with traditional methods, this application introduces a two-dimensional weighted model that considers not only call frequency but also architectural importance, thereby more accurately assessing the actual contribution of microservices in dynamic environments.

[0093] Step S03: Calculate the time contribution of each microservice's execution time to the total execution time of the target function;

[0094] It should be noted that the time contribution of each microservice's execution time to the total execution time of the target function can be calculated using cooperative game theory. Cooperative game theory is a mathematical theory used to study the value distribution problem when a group of participants achieve a common goal through cooperation. In this application, microservices are the participants, the completion of the software function is the goal, and execution time is the value. Execution time refers to the time consumed in executing a microservice. Total execution time refers to the total time from the initiation to the completion of the software function. The time contribution is quantified using Shapley values. Shapley values ​​are a tool used to interpret model prediction results, derived from cooperative game theory, and are used to measure the contribution of each feature to the model prediction.

[0095] It can be understood that, since the traditional APM tool can provide performance indicators, but it is difficult to quantify the specific contribution of a single microservice to the total execution time of software functions, making it difficult to accurately locate performance bottlenecks, step S03 is performed to use the Shapley value in cooperative game theory to calculate the marginal contribution of each microservice to the total execution time of software functions, providing in-depth insights into the performance impact of microservices, which helps to quickly identify performance bottlenecks and optimize critical paths. Compared with the traditional APM tool, the present application realizes the quantitative evaluation of the execution time contribution of microservices by introducing cooperative game theory, thereby more accurately locating performance bottlenecks and fault sources.

[0096] Step S04, determining a fusion weight coefficient based on the system type corresponding to the preset microservice system, and generating the correlation degree between the target function and each microservice in combination with the fusion weight coefficient, the access intensity, and the time contribution degree.

[0097] It should be noted that the system type is a category of system characteristics, such as access-intensive (high concurrency, read-heavy, write-light), performance-sensitive (low latency requirement), balanced (mixed characteristics), etc. The fusion weight coefficient is the weight ratio of the access intensity and the time contribution degree, which is adjusted according to the system type to adapt to different scene requirements. For example, the access-intensive system focuses on access intensity, and the performance-sensitive system focuses on time contribution. The correlation degree integrates the access intensity and the time contribution degree, which can quantify the actual impact and importance of microservices on software functions. The higher the correlation degree, the more critical the microservice is to the implementation of software functions.

[0098] In addition, it should be noted that the fusion weight coefficient is determined according to the system type (access-intensive, performance-sensitive, balanced), and the correlation degree between the target function and each microservice is calculated in combination with the access intensity and the time contribution degree. The correlation degree calculation formula is:

[0099]

[0100] wherein, is the correlation degree between the target function and the microservice , is the fusion weight coefficient, is the access intensity of the microservice , is the time contribution degree of the execution time of the microservice to the total execution time of the target function .

[0101] In addition, it should be noted that after generating the correlation degree between the target function and each microservice, it can be organized into a relationship graph. For example, as shown in Figure 2 , Figure 2A relationship graph diagram is provided, wherein the target function is a payment function, and the corresponding microservices include a gateway, an order, a risk control, and a payment. As can be seen from the relationship graph diagram, the execution order between the microservices can include: gateway→order→payment; gateway→payment; gateway→risk control→payment, and the relationship graph diagram can also display the correlation degree of each microservice and the target function. For example, the correlation degree of the gateway and the payment function is 0.68, the correlation degree of the order and the payment function is 0.72, the correlation degree of the risk control and the payment function is 0.58, and the correlation degree of the payment and the payment function is 0.92.

[0102] It can be understood that, since the traditional method often lacks flexibility and pertinence in comprehensive evaluation, it is difficult to adapt to the needs of different system types, resulting in poor correlation quantification effect, so step S04 is performed, by determining the fusion weight coefficient according to the system type (such as access-intensive, performance-sensitive, balanced), the access intensity and the time contribution degree can be more reasonably weighted and combined to generate more accurate correlation degree indicators, which helps to accurately evaluate the importance of microservices to software functions in different scenarios, and provides strong support for system optimization and fault troubleshooting. Compared with the traditional method, by introducing the system type and the fusion weight coefficient, the flexibility and pertinence of the correlation calculation are realized, thereby significantly improving the accuracy and practicality of the correlation quantification.

[0103] In a feasible implementation manner, in step S01, the microservice call chain data corresponding to each software function in the preset microservice system is collected to generate a transaction data set, and the step includes steps A01-A02:

[0104] Step A01, based on a preset probe, the microservice call behavior corresponding to the target function in the preset microservice system is intercepted through bytecode enhancement technology, and the microservice call behavior corresponds to at least one microservice;

[0105] It should be noted that the preset probe refers to a lightweight data collection component (such as a SkyWalking Agent) deployed in the microservice instance, which is used to monitor inter-service calls without intrusion, and can dynamically modify the class file of the microservice runtime through bytecode enhancement technology to insert call interception logic. Bytecode enhancement technology is a technology for dynamically modifying class files based on Java Virtual Machine (JVM), which can insert monitoring code before and after the method call through instrumentation without restarting the service, thereby realizing the monitoring of the execution process of the microservice. Instrumentation refers to inserting additional code into the source code or bytecode of a program to monitor, analyze or modify the behavior of the program. For example, the preset probe can insert interception logic at the entry method of the microservice. Microservice call behavior refers to the synchronous or asynchronous calls between microservices through HTTP / RPC protocols during the execution of software functions, which can include multiple microservices. For example, the "user order" function can trigger the order service to call the inventory service and the payment service.

[0106] In addition, it should be noted that due to the application of bytecode enhancement technology, when the microservice instance is automatically scaled out due to load changes, the newly started microservice instance will reload the class and trigger the bytecode enhancement process, thereby automatically integrating the probe function and intercepting the microservice call behavior. When the microservice instance is automatically scaled in due to load changes, the probe is destroyed after the microservice instance is terminated, without the need for manual intervention. This "plug and play" feature can adapt to the elasticity of the microservice instance.

[0107] Step A02, based on the preset probe, record the call chain data of each microservice in the microservice call behavior, clean the call chain data and reconstruct each call chain in the call chain data, and generate a transaction data set.

[0108] It should be noted that the call chain data is the original data related to the microservice call, such as microservice name, start / end timestamp, call relationship (parent-child Span), etc. The call chain refers to the collection of all microservices and their call order that a software function request goes through from initiation to completion. For example, the call chain of the "user order" function can be: gateway → order service → inventory service → payment service. The transaction data set is a collection of transactions with software functions as the granularity after cleaning and standardizing the call chain data. Each transaction contains the aggregation information of all related call chains of the function.

[0109] In this embodiment, by means of preset probes and bytecode enhancement technology, the calling behavior between microservices can be intercepted in real time and non-invasively, the integrity and accuracy of the calling chain data are ensured, high-quality data basis is provided for subsequent analysis, the limitations of traditional methods in data collection are solved, invalid and error data can be eliminated through data cleaning and calling chain reconstruction, the accuracy and consistency of the calling chain data are ensured, at the same time, the original data is converted into a transaction data set, a unified and standardized data format is provided for subsequent analysis, the analysis efficiency and accuracy are improved, the shortcomings of traditional methods in data processing are solved, and reliable data support is provided for subsequent correlation calculation.

[0110] In a feasible implementation, in step A02, the step of recording the calling chain data of each microservice in the microservice calling behavior based on the preset probe includes steps A11-A14:

[0111] Step A11, in the case that the preset probe requests to enter the microservice, a calling link identifier is created and the starting timestamp of the microservice is recorded, and in the case that the preset probe requests to leave the microservice, the ending timestamp of the microservice is recorded;

[0112] It should be noted that the calling link identifier (TraceID) is a globally unique identifier, which is used to link the cross-service calling records, and can be generated by using UUID or a snowflake algorithm. The starting timestamp and the ending timestamp respectively mark the starting time and the ending time of the microservice calling, which are used to calculate the execution time consumption of the microservice.

[0113] In addition, it should be noted that when the preset probe requests to enter the microservice, the preset probe intercepts the microservice calling request at the microservice entrance (such as the Controller layer), generates a globally unique calling link identifier, records the current timestamp as the starting timestamp, and marks the starting time of the microservice calling. When the preset probe requests to leave the microservice, the preset probe records the current timestamp as the ending timestamp at the microservice exit (such as when returning a response), and marks the ending time of the microservice calling.

[0114] Step A12, calculating the first running time of the microservice based on the starting timestamp and the ending timestamp, determining the second running time of the target function based on the first running time, and counting the first calling times of the microservice and the second calling times of the target function;

[0115] It should be noted that the first running time is the processing time consumption of a single microservice, which can be obtained by the difference between the starting timestamp and the ending timestamp. The second running time is the total time consumption of the target function, that is, the sum of the time consumptions of all associated microservices, which can be obtained by accumulating the first running times of the microservices under the target function. The first calling times are the number of times the microservice is called, and the second calling times are the number of times the target function is triggered.

[0116] Step A13, in the case of a target function being a cross-service calling behavior, propagate the calling link context information through a preset request header field to record the complete microservice calling link, which includes each microservice called by the target function in the microservice calling link;

[0117] It should be noted that the cross-service calling behavior refers to a scenario in which the current target function depends on multiple microservices to complete (such as “ordering” needing to call order service, payment service, and inventory service), and such behavior involves synchronous (HTTP / RPC) or asynchronous (message queue) communication, and needs to ensure that the context is continuously passed in the calling chain. The preset probe automatically injects the context information into the preset request header field when initiating the cross-service calling, and the preset request header field is a standardized HTTP Header or gRPCMetadata field (such as X-B3-TraceId, X-B3-SpanId), which is used to carry the calling link context information. The calling link context information includes calling link identification, current SpanID (identifying a single calling sub-link), parent SpanID (identifying the calling source), etc., which is used to ensure that the link is traceable. The microservice calling link is a sequence of microservices involved in the target function and the hierarchical relationship.

[0118] Step A14, taking the calling link identification, start timestamp, end timestamp, first running time, second running time, first calling frequency, second calling frequency, and microservice calling link as the calling chain data of each microservice.

[0119] It should be noted that the calling link identification, start timestamp, end timestamp, first running time, second running time, first calling frequency, second calling frequency, and microservice calling link are encapsulated as structured data as the calling chain data of the microservice.

[0120] In this embodiment, by collecting the calling link identification, start timestamp, end timestamp, first running time, second running time, first calling frequency, second calling frequency, and microservice calling link, full collection, standardized encapsulation, and business association of the calling chain data are achieved, providing a high-quality data basis for subsequent association quantitative analysis.

[0121] In a feasible embodiment, in step A02, the step of cleaning the calling chain data and reconstructing each calling chain in the calling chain data to generate a transaction data set includes steps A21-A23:

[0122] Step A21, excluding invalid calling information in the calling chain data, and short-time calling information with a first running time lower than a preset time threshold, and supplementing missing data in the calling chain data;

[0123] It should be noted that invalid call information and short call information are removed, wherein the invalid call information is call record not meeting preset rules, for example, isolated call (such as third-party API not transmitting link identifier) not carrying call link identifier, illegal service name (such as null or containing special character) and abnormal timestamp (such as end time earlier than start time) and the like. The short call information is call with first running time lower than preset time threshold (for example, 10 ms), for example, health check probe (such as / healthz interface of Kubernetes), internal cache hit (such as Redis query time consuming 2 ms) and false alarm or system noise and the like.

[0124] In addition, it should be noted that after the invalid call information and the short call information are removed, records missing key fields are repaired, for example, for missing end timestamp, the start time of subsequent microservices under the same call link identifier is inferred (such as the end time of A service should be earlier than the start time of B service); for missing service name, the IP:port is mapped to known service list, and for missing call times, the default initialization is 1.

[0125] Step A22, grouping the call chain data according to the call link identifier to obtain service call information, and sorting the service call information based on the start timestamp to obtain each call chain;

[0126] It should be noted that the cleaned data is aggregated according to the call link identifier to obtain all service call information under the same business request, the service call information is all microservices and related data of a single target function call, the service call information in each group is arranged in ascending order of start timestamp to restore the actual call order, and each call chain is obtained, the call chain is a service call sequence grouped and sorted according to the call link identifier, such as T1=[gateway, order service, payment service] and T2=[gateway, inventory service].

[0127] Step A23, taking each call chain as a service call chain set, taking each call chain and service time information corresponding to each call chain as a service tracking chain set, and taking the service call chain set and the service tracking chain set as a transaction data set, wherein the service time information is determined by the call chain data.

[0128] It should be noted that the service call chain set contains all cleaned and sorted call chains, each call chain takes the call link identifier as the key, and the value is the microservice call sequence. The service tracking chain set contains each call chain and corresponding service time information, which is used for performance analysis. The service time information includes first running time of a single microservice and second running time of a target function, which is determined by the call chain data.

[0129] In this embodiment, by filtering invalid data, the call chain data only retains the real business-related microservice interaction, focuses on the microservice call which has substantial impact on business function, improves the accuracy of correlation degree calculation, restores the complete call link through context completion, ensures that the correlation degree analysis covers all paths, ensures the timing correctness of the call chain through timestamp sorting, and provides reliable causal relationship for the correlation degree analysis.

[0130] Based on the first embodiment of the present application, the same or similar contents as the above first embodiment can be referred to the above introduction, and will not be described in detail. On this basis, please refer to Figure 3 , in step S02, the transaction data set includes a service call chain set, and the steps of calculating the traffic weight and the exponentially decaying position weight of each microservice under the target function in combination with the transaction data set include steps S11-S13:

[0131] Step S11, the service call chain corresponding to the target function is extracted from the service call chain set, and the total number of calls of the target function and each microservice in the service call chain are recorded;

[0132] It should be noted that each service call chain in the service call chain set has a business mark for identifying the function it implements, and all service call chains associated with the target function are filtered from the service call chain set of the transaction data set. The total number of calls of the target function, i.e. the number of filtered call chains, and the microservice names involved in all call chains (such as order service, payment service, inventory service) are extracted to form the microservice set of the target function.

[0133] Step S12, for any one of the microservices, record the number of calls and the position depth of the microservice in the service call chain;

[0134] It should be noted that for each microservice, the number of times (i.e. the number of calls) and the position depth of the microservice in all target function call chains are counted. The position depth refers to the logical level of the microservice in the call chain, which is counted from the entry service (the entry service depth is 0), for example, the position depth of the order service in T1=[gateway, order service, payment service] is 1.

[0135] Step S13, based on the number of calls and the total number of calls, the traffic weight of the microservice is calculated, and based on the decay coefficient and the position depth, the exponentially decaying position weight of the microservice is calculated, wherein the decay coefficient is determined by the depth of the service call chain.

[0136] It should be noted that the traffic weight reflects the proportion of the call frequency of the microservice in the target function, which is determined by the ratio of the number of calls to the total number of calls, and the traffic weight calculation formula is:

[0137]

[0138] wherein, is the flow weight, is the target function invoking microservice the number of invocations, is the total number of invocations of the target function.

[0139] The exponentially decaying position weight reflects the influence of the microservice call position on the target function, and is calculated based on the decay coefficient and the position depth. The exponentially decaying position weight calculation formula is:

[0140]

[0141] wherein, is the exponentially decaying position weight, is the natural constant, is the decay coefficient, is the microservice position depth in the call chain. The decay coefficient is related to the depth of the service call chain, and the specific correspondence is shown in Table 1.

[0142] Table 1

[0143]

[0144] Wherein, the longer the call chain, the slower the decay speed, and therefore the smaller the decay coefficient. Conversely, the shorter the call chain, the faster the decay speed, and therefore the larger the decay coefficient.

[0145] By way of example, in order to facilitate understanding of the technical concept or technical principle of the present application, please refer to Figure 4 , Figure 4 The access intensity calculation flowchart is provided. After inputting the service call chain, the total number of invocations, the number of invocations, and the position depth, the flow weight calculation and the position weight calculation are performed. The flow weight is the ratio of the number of invocations to the total number of invocations. The exponentially decaying position weight needs to be calculated in combination with the decay coefficient and the position depth. The flow weight and the exponentially decaying position weight are weighted to obtain the access intensity.

[0146] In this embodiment, the weight calculation is ensured to be only for the target function through the function level call chain screening, cross-function data pollution is avoided, the position depth is introduced to provide a basis for the subsequent exponential decay model, the contribution of the microservice close to the function entrance and the microservice close to the exit to the correlation degree is differentiated, the importance of the call sequence is quantified through the position depth to provide a basis for the subsequent decay weight, the high-frequency call service is ensured to obtain a higher basic weight through the calculation of the traffic weight, the call with excessive depth is punished through the calculation of the exponential decay weight, the key service close to the entrance is highlighted, the full-link quantification from the call chain data to the microservice correlation degree weight is realized, and the analysis accuracy of the function and component correlation degree in the microservice system is significantly improved to provide data-driven decision support for fault location, service degradation and the like.

[0147] In a feasible implementation, in step S03, the transaction data set includes a service tracking chain set, and the step of calculating the time contribution degree of the execution time of each microservice to the total execution time of the target function includes steps B01-B04:

[0148] Step B01 extracts the tracking call chain corresponding to the target function from the service tracking chain set, extracts each microservice in the tracking call chain and the service time consumption information corresponding to the tracking call chain, and determines the execution time of each microservice and the total execution time of the target function based on the service time consumption information;

[0149] It should be noted that, similar to the service call chain, each tracking call chain in the service tracking chain set is also marked with a business marker to identify the function it implements. All service tracking chains with a business marker associated with the target function are filtered from the service tracking chain set of the transaction data set. The microservice name and its execution time in each tracking call chain and the total execution time of the target function are recorded.

[0150] Step B02 maps the implementation process of the target function as a cooperative game process, wherein each microservice subset is a coalition in the cooperative game process, the contribution value of the coalition in the cooperative game process is the execution time of each microservice subset, and each microservice subset is a subset composed of each microservice;

[0151] It should be noted that the cooperative game theory is used to study how a group of participants (players) jointly achieve a certain goal (or "value") through cooperation. In cooperative game, how to fairly allocate the total value generated by cooperation to each participant is a core problem. The Shapley value is a solution concept in cooperative game, which provides a unique allocation method for the total surplus generated by the coalition. Its fairness is reflected in that it considers the marginal contribution of each player to all possible coalitions.

[0152] Additionally, it should be noted that in this application, the participants (players) are all the microservices involved in the target function, and the alliance is any subset of microservices. This application mainly studies the contribution of the execution time of microservices to the total execution time of the software function, so as to quantify the contribution of microservices to the execution time.

[0153] Step B03: For any microservice among the microservices, calculate the difference in contribution value of the microservice before and after joining each optional consortium, and obtain the marginal contribution value of the microservice under the corresponding optional consortium, where the optional consortium is a subset of microservices that does not include the microservices.

[0154] It should be noted that, for any microservice within each microservice, all tracing call chains containing the microservice are traversed. For each tracing call chain, optional federations that do not contain the microservice are identified, and the difference in contribution value of the microservice before and after joining each optional federation is calculated. The calculation formula is as follows:

[0155]

[0156] in, For the microservices selected from the various microservices, For the optional federation selected from the various optional federations, for those that do not contain microservices A subset of microservices For microservices Join the optional alliance The subsequent execution time, For optional alliance Execution time, The difference in value contributed by the microservice before and after joining various optional consortia is the value of the microservice. In the optional alliance The marginal contribution value below.

[0157] Step B04: Perform a weighted average of the marginal contribution values ​​of the microservices under each optional federation to obtain the average marginal contribution value of the microservices. Generate the time contribution based on the average marginal contribution value and the total execution time.

[0158] It should be noted that the formula for calculating the average marginal contribution value is:

[0159]

[0160] in, For microservices The corresponding average marginal contribution value, For the collection of all microservices, This represents the total number of microservices. The average marginal contribution value is the value of each microservice. The Shapley value is a time value, so it is also necessary to calculate its proportion in the total execution time to generate the time contribution.

[0161] For example, the total execution time of a certain software function is 100 ms, and the result obtained by Shapley value contribution analysis is shown in Table 2.

[0162] Table 2

[0163]

[0164] In this embodiment, by tracking the chain-level time consumption statistics, it is ensured that the time contribution calculation is based on the real calling scenario, the accuracy of the correlation analysis is improved, the joint execution time of the microservice subset is explicitly captured through the cooperative game model, the basis for the marginal contribution calculation is provided, the incremental influence of the microservice on the alliance execution time is quantified through the marginal contribution value, the key path service is highlighted, the direct and indirect influence of the microservice on the total execution time is accurately reflected through the time contribution, and the full-link quantification from the execution time data to the microservice correlation is realized, which significantly improves the accuracy of the performance bottleneck positioning in the microservice system and provides theoretical support for automatic operation and optimization.

[0165] In a feasible implementation, in step S04, the step of determining the fusion weight coefficient based on the system type corresponding to the preset microservice system includes steps B11-B13:

[0166] Step B11, in the case where the system type corresponding to the preset microservice system is access-intensive, the fusion weight coefficient is set as a first weight coefficient;

[0167] It should be noted that the microservice system corresponding to the access-intensive type is a system in which a large number of requests frequently flow in, and the main pressure of the system is concentrated on processing these massive access requests, and the core feature is that the number of requests is huge, but the data processing amount and the calculation complexity involved in each request are relatively low. The first weight coefficient is a value that is pre-set according to the characteristics of the access-intensive system. Since the access-intensive system pays more attention to quickly processing a large number of requests, the first weight coefficient will usually tend to prioritize the request processing capability of the system, and may give a higher weight to the modules related to processing requests in terms of resource allocation, task scheduling, etc. For example, when allocating server resources, more CPU time and memory will be allocated to the service modules responsible for processing user requests to ensure that a large number of accesses can be responded to quickly.

[0168] Step B12, in the case where the system type corresponding to the preset microservice system is performance-sensitive, the fusion weight coefficient is set as a second weight coefficient;

[0169] It should be noted that the performance-sensitive microservice system refers to a system that has extremely high requirements for the performance of processing requests, and even a very small performance fluctuation can have a serious impact on the overall operation of the system. It usually involves complex calculations, data processing or real-time tasks with extremely high requirements, such as financial transaction systems, industrial control systems, etc. The second weight coefficient is set to meet the demand for high performance, focusing on optimizing the performance indicators of the system, such as reducing response time, improving throughput, etc. In terms of resource allocation, it will prioritize modules that have a greater impact on performance, such as allocating more computing resources to critical computing modules and using more efficient algorithms and data structures to improve processing speed.

[0170] Step B13, in the case where the preset microservice system corresponds to a balanced system type, the fusion weight coefficient is set to a third weight coefficient.

[0171] It should be noted that the balanced microservice system is between the access-intensive and performance-sensitive microservice systems, which needs to process a certain number of access requests and has certain requirements for system performance. Such a system does not have as many requests as the access-intensive system, nor does it pursue performance as the performance-sensitive system. Instead, it needs to find a balance between the two to achieve stable operation and efficient processing of the system. The third weight coefficient is designed for balanced systems, which considers both access volume and performance factors. In resource allocation and task scheduling, it will take into account the ability to process requests and the improvement of system performance, without excessively favoring one side. For example, when allocating server resources, it will allocate CPU, memory and other resources according to the importance and processing needs of different modules to achieve balanced operation of the system as a whole.

[0172] Exemplarily, the setting rule of the fusion weight coefficient can be as shown in Table 3.

[0173] Table 3

[0174]

[0175] In this embodiment, by setting different fusion weight coefficients according to different microservice system types, the weight of each indicator in the correlation quantification can be reasonably adjusted according to the characteristics of different types of systems, so as to more accurately quantify the correlation between software functions and microservices and improve the quantification effect, providing a more reliable basis for system performance optimization, resource allocation, etc.

[0176] Exemplarily, in order to help understand the technical concept or technical principle of the present application, please refer to Figure 5 , Figure 5The overall flowchart of the correlation degree dynamic calculation method in the microservice system operation and maintenance is provided. First, data of a preset microservice system is collected (for example, collected through Skywalking), the collected data is preprocessed, weight calculation and execution time analysis are performed. When performing weight calculation, traffic weight and exponential decay position weight need to be determined, so as to calculate access intensity. When performing execution time analysis, Shapley value calculation is performed, so as to obtain Shapley contribution degree. The access intensity and the Shapley contribution degree are weighted and summed to obtain the correlation degree. The data collection process is as shown in Figure 6 , Figure 6 The data collection flowchart is provided, taking a microservice application as a starting point, which is an object to be monitored. Through the bytecode enhancement technology of the SkyWalking Agent probe, the method call is intercepted during the microservice runtime, so as to monitor and collect data. The collected data is sent to the SkyWalking OAP (Observability Analysis Platform) server through the gRPC protocol. The OAP server is the core component of SkyWalking, responsible for receiving, processing and storing monitoring data from various agents. It provides powerful data analysis capabilities and can aggregate, count and analyze massive monitoring data. Finally, the data processed by the OAP server is stored in the backend storage system. Common storage backends include Elasticsearch, MySQL, etc.

[0177] It should be noted that the above examples are only used to understand the present application and do not limit the microservice system operation and maintenance correlation degree dynamic calculation method of the present application. More forms of simple transformation based on this technical concept are within the protection scope of the present application.

[0178] The present application also provides a correlation degree dynamic calculation system, please refer to Figure 7 , the correlation degree dynamic calculation system comprises:

[0179] The data collection module 10 is used for collecting microservice call chain data corresponding to each software function in a preset microservice system, and generating a transaction data set;

[0180] The access intensity calculation module 20 is used for calculating the traffic weight and the exponential decay position weight of each microservice under a target function in combination with the transaction data set for any one target function in each software function, and comprehensively calculating the access intensity of each microservice according to the traffic weight and the exponential decay position weight of each microservice;

[0181] The time contribution degree calculation module 30 is used for calculating the time contribution degree of the execution time of each microservice to the total execution time of the target function;

[0182] The correlation degree calculation module 40 is configured to determine a fusion weight coefficient based on a system type corresponding to the preset micro-service system, and generate a correlation degree between the target function and each micro-service in combination with the fusion weight coefficient, the access intensity, and the time contribution degree.

[0183] Optionally, the data acquisition module 10 is further configured to:

[0184] intercept, based on the preset probe, a micro-service calling behavior corresponding to the target function in the preset micro-service system through bytecode enhancement technology, the micro-service calling behavior corresponding to at least one micro-service;

[0185] record, based on the preset probe, calling chain data of each micro-service in the micro-service calling behavior, clean the calling chain data, and reconstruct each calling chain in the calling chain data to generate a transaction data set.

[0186] Optionally, the data acquisition module 10 is further configured to:

[0187] create a calling link identifier and record a start timestamp of the micro-service in a case where the preset probe requests to enter the micro-service, and record an end timestamp of the micro-service in a case where the preset probe requests to exit the micro-service;

[0188] calculate a first running time of the micro-service based on the start timestamp and the end timestamp, determine a second running time of the target function based on the first running time, and count a first calling frequency of the micro-service and a second calling frequency of the target function;

[0189] in a case where the target function is a cross-service calling behavior, propagate calling link context information through a preset request header field to record a complete micro-service calling link, the micro-service calling link including each micro-service called by the target function;

[0190] use the calling link identifier, the start timestamp, the end timestamp, the first running time, the second running time, the first calling frequency, the second calling frequency, and the micro-service calling link as the calling chain data of each micro-service.

[0191] Optionally, the data acquisition module 10 is further configured to:

[0192] exclude invalid calling information in the calling chain data and short-time calling information with a first running time lower than a preset time threshold, and complete missing data in the calling chain data;

[0193] group the calling chain data according to the calling link identifier to obtain each service calling information, and sort the service calling information based on the start timestamp to obtain each calling chain.

[0194] The call chains are taken as a service call chain set, the call chains and the service time consumption information corresponding to the call chains are taken as a service tracking chain set, and the service call chain set and the service tracking chain set are taken as a transaction data set, wherein the service time consumption information is determined by the call chain data.

[0195] Optionally, the transaction data set includes the service call chain set, and the access intensity calculation module 20 is further configured to:

[0196] extract the service call chain corresponding to the target function from the service call chain set, record the total number of calls of the target function and each microservice in the service call chain;

[0197] for any one of the microservices, record the number of calls and the position depth of the microservice in the service call chain;

[0198] calculate the traffic weight of the microservice based on the number of calls and the total number of calls, and calculate the exponentially decaying position weight of the microservice based on the decay coefficient and the position depth, wherein the decay coefficient is determined by the depth of the service call chain.

[0199] Optionally, the time contribution degree calculation module 30 is further configured to:

[0200] extract the tracking call chain corresponding to the target function from the service tracking chain set, extract each microservice in the tracking call chain and the service time consumption information corresponding to the tracking call chain, determine the execution time of each microservice and the total execution time of the target function based on the service time consumption information;

[0201] map the implementation process of the target function to a cooperative game process, wherein each microservice corresponds to a subset of the cooperative game process, the contribution value of the alliance in the cooperative game process is the execution time of each microservice subset, and each microservice subset is a subset composed of each microservice;

[0202] for any one of the microservices, calculate the difference between the contribution values before and after the microservice joins each optional alliance to obtain the marginal contribution value of the microservice in the corresponding optional alliance, wherein the optional alliance is a microservice subset that does not include the microservice;

[0203] perform weighted average processing on the marginal contribution values of the microservice in each optional alliance to obtain the average marginal contribution value of the microservice, and generate the time contribution degree based on the average marginal contribution value and the total execution time.

[0204] Optionally, the correlation degree calculation module 40 is further configured to:

[0205] in a case where the system type corresponding to the preset microservice system is access-intensive, set the fusion weight coefficient as a first weight coefficient;

[0206] In a case where the system type corresponding to the preset micro-service system is a performance-sensitive type, the fusion weight coefficient is set as the second weight coefficient.

[0207] In a case where the system type corresponding to the preset micro-service system is a balanced type, the fusion weight coefficient is set as the third weight coefficient.

[0208] The correlation degree dynamic calculation system provided in the present application adopts the correlation degree dynamic calculation method in the micro-service system operation and maintenance in the above embodiments, and can solve the technical problem of poor quantification effect of software function and micro-service correlation. Compared with the prior art, the correlation degree dynamic calculation system provided in the present application has the same beneficial effects as the correlation degree dynamic calculation method in the micro-service system operation and maintenance provided in the above embodiments, and other technical features in the correlation degree dynamic calculation system are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0209] The present application provides an electronic device, which comprises at least one processor and a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the correlation degree dynamic calculation method in the micro-service system operation and maintenance in the above embodiment one.

[0210] Reference will be made to the following Figure 8 which shows a structural schematic diagram of an electronic device suitable for implementing the embodiments of the present application. The electronic device in the embodiments of the present application can include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (Personal Digital Assistant: personal digital assistants), PADs (Portable Application Description: tablet computers), PMPs (Portable Media Player: portable multimedia players), vehicle terminals (such as vehicle navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 8 The electronic device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0211] As Figure 8As shown, the electronic device can include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to programs stored in a read-only memory 1002 or loaded from a storage device 1003 into a random access memory 1004. Various programs and data required for operation of the electronic device are also stored in the random access memory 1004. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other by a bus 1005. An input / output interface 1006 is also connected to the bus. Generally, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the electronic device to communicate wirelessly or wired with other devices to exchange data. Although the electronic device with various systems is shown in the figure, it should be understood that all of the shown systems are not required to be implemented or possessed. More or less systems can be alternatively implemented or possessed.

[0212] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by a communication device, or installed from the storage device 1003, or installed from the read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are performed.

[0213] The electronic device provided by the present application adopts the correlation degree dynamic calculation method in the micro-service system operation and maintenance in the above-mentioned embodiments, which can solve the technical problem of poor quantization effect of software function and micro-service correlation. Compared with the prior art, the electronic device provided by the present application has the same beneficial effects as the correlation degree dynamic calculation method in the micro-service system operation and maintenance provided by the above-mentioned embodiments, and other technical features in the electronic device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0214] It should be understood that parts of the present disclosure can be realized by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0215] The above merely provides a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0216] The present application provides a computer readable storage medium having computer readable program instructions (i.e. computer programs) stored thereon, the computer readable program instructions being used to execute the correlation degree dynamic calculation method in the micro-service system operation and maintenance in the above-mentioned embodiments.

[0217] The computer readable storage medium provided by the present application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, the computer readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), etc., or any suitable combination of the above.

[0218] The above computer readable storage medium can be contained in an electronic device; or can exist separately without being assembled into an electronic device.

[0219] The computer readable storage medium described above carries one or more programs, when the one or more programs are executed by the electronic device, enable the correlation dynamic calculation device to collect microservice call chain data corresponding to each software function in the preset microservice system, generate a transaction data set; for any one target function in each software function, calculate the traffic weight and the exponentially decaying position weight of each microservice under the target function in combination with the transaction data set, and comprehensively obtain the access intensity of each microservice by combining the traffic weight and the exponentially decaying position weight of each microservice; calculate the time contribution degree of the execution time of each microservice to the total execution time of the target function; determine a fusion weight coefficient based on the system type corresponding to the preset microservice system, and generate the correlation degree between the target function and each microservice in combination with the fusion weight coefficient, the access intensity, and the time contribution degree.

[0220] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0221] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0222] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0223] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., a computer program) for executing the above-mentioned correlation degree dynamic calculation method in micro-service system operation and maintenance, and can solve the technical problem of poor quantification effect of software function and micro-service correlation degree. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the above-mentioned correlation degree dynamic calculation method in micro-service system operation and maintenance, and will not be described here.

[0224] The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the above-mentioned correlation degree dynamic calculation method in micro-service system operation and maintenance.

[0225] The computer program product provided by the present application can solve the technical problem of poor quantification effect of software function and micro-service correlation degree. Compared with the prior art, the computer program product provided by the present application has the same beneficial effects as the above-mentioned correlation degree dynamic calculation method in micro-service system operation and maintenance, and will not be described here.

[0226] The above only describes some embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields based on the technical concept of the present application, and the contents of the present application and the accompanying drawings are included in the patent protection scope of the present application.

Claims

1. A method for dynamically calculating the correlation degree in the operation and maintenance of a microservice system, characterized in that, The method for dynamically calculating the correlation degree in the operation and maintenance of the microservice system includes: Collect microservice call chain data corresponding to each software function in the preset microservice system and generate a transaction dataset. For any target function among the software functions, the traffic weight and exponentially decaying position weight of each microservice under the target function are calculated in combination with the transaction dataset. The access intensity of each microservice is obtained by combining the traffic weight and exponentially decaying position weight of each microservice. The traffic weight represents the frequency of each microservice being called, the exponentially decaying position weight represents the importance of each microservice in the architectural hierarchy of the call chain corresponding to each microservice, and the exponentially decaying position weight decreases as the depth of the call chain corresponding to each microservice increases. Calculate the time contribution of each microservice's execution time to the total execution time of the target function; Based on the system type corresponding to the preset microservice system, a fusion weight coefficient is determined, and the correlation between the target function and each microservice is generated by combining the fusion weight coefficient, the access intensity, and the time contribution. The transaction dataset includes a set of service call chains, and the step of calculating the traffic weight and exponential decay position weight of each microservice under the target function by combining the transaction dataset includes: Extract the service call chain corresponding to the target function from the service call chain set, and record the total number of calls to the target function and each microservice in the service call chain; For any one of the microservices, record the number of times the microservice is called and its position depth in the service call chain; The traffic weight of the microservice is calculated based on the number of calls and the total number of calls. The exponentially decaying position weight of the microservice is calculated based on the decay coefficient and the position depth, wherein the decay coefficient is determined by the depth of the service call chain.

2. The method for dynamically calculating the correlation degree in the operation and maintenance of a microservice system as described in claim 1, characterized in that, The steps of collecting microservice call chain data corresponding to each software function in the preset microservice system and generating a transaction dataset include: Based on a preset probe, bytecode enhancement technology is used to intercept microservice call behavior corresponding to the target function in a preset microservice system. The microservice call behavior corresponds to at least one microservice. Based on the preset probe recording the call chain data of each microservice in the microservice call behavior, the call chain data is cleaned and each call chain in the call chain data is reconstructed to generate a transaction dataset.

3. The method for dynamically calculating the correlation degree in the operation and maintenance of a microservice system as described in claim 2, characterized in that, The step of recording the call chain data of each microservice in the microservice call behavior based on the preset probe includes: When the preset probe requests to enter the microservice, a call chain identifier is created and the start timestamp of the microservice is recorded; when the preset probe requests to leave the microservice, the end timestamp of the microservice is recorded. The first runtime of the microservice is calculated based on the start timestamp and the end timestamp. The second runtime of the target function is determined based on the first runtime. The first number of calls to the microservice and the second number of calls to the target function are counted. When the target function is a cross-service call behavior, the call chain context information is propagated through a preset request header field to record the complete microservice call chain, which includes each microservice called by the target function; The call chain identifier, the start timestamp, the end timestamp, the first running time, the second running time, the first number of calls, the second number of calls, and the microservice call chain are used as the call chain data for each microservice.

4. The method for dynamically calculating the correlation degree in the operation and maintenance of a microservice system as described in claim 3, characterized in that, The step of cleaning and reconstructing the call chain data to generate a transaction dataset includes: Invalid call information and short-term call information with the first running time lower than a preset time threshold are excluded from the call chain data, and missing data in the call chain data are supplemented. The call chain data is grouped according to the call chain identifier to obtain the service call information, and the service call information is sorted according to the start timestamp to obtain the call chain. Each call chain is taken as a service call chain set, and each call chain and the service time information corresponding to each call chain are taken as a service tracing chain set. The service call chain set and the service tracing chain set are taken as a transaction dataset, wherein the service time information is determined by the call chain data.

5. The method for dynamically calculating the correlation degree in the operation and maintenance of a microservice system as described in claim 1, characterized in that, The transaction dataset includes a set of service tracing chains, and the step of calculating the time contribution of the execution time of each microservice to the total execution time of the target function includes: Extract the tracing call chain corresponding to the target function from the service tracing chain set, extract each microservice in the tracing call chain and the service time information corresponding to the tracing call chain, and determine the execution time of each microservice and the total execution time of the target function based on the service time information; The implementation process of the target function is mapped as a cooperative game process, wherein each microservice corresponds to a subset of the alliance in the cooperative game process, the contribution value of the alliance in the cooperative game process is the execution time of each microservice subset, and each microservice subset is a subset composed of microservices. For any one of the microservices, calculate the difference in contribution value of the microservice before and after joining each optional consortium to obtain the marginal contribution value of the microservice under the corresponding optional consortium, wherein the optional consortium is a subset of microservices that does not include the microservice. The marginal contribution values ​​of the microservice under each optional federation are weighted and averaged to obtain the average marginal contribution value of the microservice. The average marginal contribution value and the total execution time are used to generate the time contribution.

6. The method for dynamically calculating the correlation degree in the operation and maintenance of a microservice system as described in claim 1, characterized in that, The step of determining the fusion weight coefficient based on the system type corresponding to the preset microservice system includes: If the system type corresponding to the preset microservice system is access-intensive, the fusion weight coefficient is set as the first weight coefficient. If the system type corresponding to the preset microservice system is performance-sensitive, the fusion weight coefficient is set as the second weight coefficient. If the system type corresponding to the preset microservice system is balanced, the fusion weight coefficient is set as the third weight coefficient.

7. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dynamic correlation calculation method in the operation and maintenance of a microservice system as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the dynamic correlation calculation method in the operation and maintenance of a microservice system as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the dynamic correlation calculation method in the operation and maintenance of a microservice system as described in any one of claims 1 to 6.

Images