A micro-service architecture dependency relationship visual analysis method

Abstract

The present application relates to the technical field of micro-service architecture, and particularly relates to a micro-service architecture dependency relationship visual analysis method, which comprises the following steps: collecting traffic data of a target micro-service network in a current working environment according to a preset collection frequency, and performing proxy injection and traffic mirroring on the obtained traffic data to obtain tracking data; performing dependency analysis on the tracking data through a graph construction algorithm, constructing a service dependency graph, and then visually displaying the service dependency graph; and based on the service dependency graph, performing real-time circular dependency detection and single-point fault fusion perception on the target micro-service network.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture technology, and in particular to a method for visual analysis of microservice architecture dependencies. Background Technology

[0002] Microservice architecture is a method of developing a single application as a set of small, loosely coupled microservices. Each microservice is an independent, deployable process built around a specific business capability (such as user management, order processing, and payment). Services collaborate through lightweight communication mechanisms (such as HTTP / REST, gRPC, and message queues). Application scenarios include: Large, complex applications: When a monolithic application becomes too large and cumbersome, making development, testing, and deployment extremely slow, it's the best time to split into microservices. Examples include Netflix, Amazon, eBay, and Taobao. Business scenarios requiring rapid iteration and frequent releases: For example, internet companies need to respond quickly to market changes; the independent deployment characteristics of microservices allow teams to release multiple times a day without blocking each other. High-concurrency systems requiring elastic scaling: For example, flash sales on e-commerce platforms or trending events on social media. Microservices can be scaled quickly only for high-load services such as orders and product queries.

[0003] Automatically drawing service dependency graphs through traffic mirroring and topology analysis is a core technology in the service mesh and observability domains. It can be used to analyze circular dependencies and single points of failure in microservice architectures.

[0004] However, using service dependency graphs for circular dependency analysis has a lag because service dependency graphs are usually updated periodically (within a time window), and newly generated circular dependencies within that time window cannot be captured in real time. Circular dependency graphs are usually based on services as nodes. While the algorithm can detect single points of failure when a service is identified as a single point of failure, it cannot detect the redundancy of service instances, and therefore cannot accurately determine whether it is a single point of failure. This is because a service identified as a single point of failure can only be considered a true single point of failure if it has only one instance behind it. Summary of the Invention

[0005] This invention, based on a service dependency graph, achieves real-time detection of newly generated circular dependencies by embedding detection data, avoiding complete reliance on a lagging service dependency graph and improving the real-time performance of circular dependency detection.

[0006] The technical solution proposed in this invention is: a method for visual analysis of microservice architecture dependencies, the method comprising:

[0007] Traffic data of the target microservice network in the current working environment is collected according to the preset collection frequency, and the obtained traffic data is injected by proxy and mirrored to obtain tracking data.

[0008] Dependency analysis is performed on the tracking data using graph building algorithms to construct a service dependency graph, which is then visualized.

[0009] Based on the service dependency graph, real-time circular dependency detection and single-point fault fusion perception are performed on the target microservice network.

[0010] Preferably, the step of performing proxy injection and traffic mirroring on the obtained traffic data to obtain tracking data includes:

[0011] Traffic data flowing into and out of the corresponding services is obtained through a network proxy, and a tracking database is embedded in the traffic data of each service. When a service is invoked, a tracking data vector is generated.

[0012] Copy the tracking data vector and traffic data of each service into the tracking environment to obtain tracking data, and send the tracking data vector to the backend of the tracking system in the tracking environment via message queue or direct HTTP.

[0013] The tracking data vector includes tracking ID, work unit ID, parent work unit ID, timestamp, service name, and operation name.

[0014] Preferably, the step of embedding a tracing database in each service and generating a tracing data vector when the service is invoked includes:

[0015] Upon receiving a call request, the first service generates a unique trace ID, then creates a unit of work and assigns a corresponding unit of work ID to the unit of work;

[0016] Pass the tracking ID and work unit ID to the next service;

[0017] When the next service receives the call request, it creates a parent unit of work and uses the unit of work ID of the previous service as the parent unit of work ID, while also saving the trace ID obtained from the previous service;

[0018] Each work unit and its parent work unit collect the operation name, service start time, duration, and service name of their corresponding service to construct a service tracking vector. ;

[0019] in, They represent services respectively. The tracking ID, unit of work ID, parent unit of work ID, service start time, service duration, and service name;

[0020] For the first service, which is the starting point of the service call chain, .

[0021] Preferably, the step of performing dependency analysis on the tracking data using a graph construction algorithm to construct a service dependency graph, and then visualizing the service dependency graph, includes:

[0022] The backend of the tracking system identifies the service name in each tracking service vector and uses the identified service name as a node.

[0023] Identify the tracing ID of the previous service by using the parent unit of work ID in the tracing service vector of the current service, and obtain the service name of the previous service based on that service ID;

[0024] Establish a directed edge between the current service and the previous service, with the direction pointing from the previous service to the current service;

[0025] Multiple nodes and edges constitute a service chain, and multiple service chains constitute a service dependency graph;

[0026] Within a time window, the dependency strength between services that have service call relationships is: ;in, Indicates the first Service within a time window Call service Total number of times Indicates the first The average latency of each call within a time window; Indicates the first The length of a time window;

[0027] By continuously sliding the time window and updating the dependency strength with new tracking data, a decay factor is introduced to prevent outdated dependencies from persisting for a long time.

[0028] Then, the updated dependency strength ;in, Indicates the attenuation factor; Indicates the first Service within a time window Call service Total number of times Indicates the first The average latency of each call within a time window; Indicates the first The length of a time window;

[0029] Weights are assigned to the corresponding edges in the service dependency graph based on dependency strength.

[0030] The obtained service dependency graph is rendered and output using a graphical library, including:

[0031] The size of the corresponding node is rendered based on the number of times the service is called within a time window;

[0032] The thickness of an edge is rendered based on the dependency strength, i.e., the edge weight, within a time window.

[0033] Based on a time window The size of the rendering edge determines the color depth.

[0034] Preferably, the step of performing real-time circular dependency detection and single-point fault fusion perception on the target microservice network based on the service dependency graph includes:

[0035] The service chain is obtained from the service dependency graph, and detection data is embedded in the service chain to realize real-time detection of newly generated circular dependencies, thus avoiding complete reliance on the service dependency graph.

[0036] By introducing a multi-dimensional confidence calculation and hierarchical decision-making mechanism, the false positives of circular dependency detection can be identified in advance and the false positive probability can be quantified in order to control the false positive rate of circular dependency detection.

[0037] By constructing a two-layer detection architecture, combining circular dependency detection and instance redundancy analysis, single point of failure can be comprehensively evaluated.

[0038] Preferably, the step of embedding detection data in the service chain to achieve real-time detection of newly generated circular dependencies includes:

[0039] For each request entering the target microservice network, a path state vector P, i.e., detection data, is initialized. The path vector P is passed between services along the service chain. The path vector P includes the service names of all services that the corresponding service request has visited.

[0040] When a call request arrives at the first service, the trace ID and service start time of the first service are retrieved from the trace data vector of the first service.

[0041] Initialize the path vector P, add the retrieved trace ID to P, and associate the service start time with P;

[0042] When a call request arrives at the called service, the called service checks whether its own tracking ID already exists in P;

[0043] If so, it is determined to be a circular dependency, a warning is triggered, and an error response is returned to prevent the request from looping indefinitely;

[0044] Otherwise, determine if there is no circular dependency;

[0045] Maintain a recent visitor cache locally for each service. This recent visitor cache is a cache with the key being the tracking ID of the corresponding service and the value being P, and is set to be no less than [value missing]. Time to Live (TTL).

[0046] Preferably, the introduction of multi-dimensional confidence calculation and hierarchical decision-making mechanism to identify and quantify the false positive probability of circular dependency detection in advance, in order to control the false positive rate of circular dependency detection, includes:

[0047] Construct a confidence calculation model for circular dependencies, including:

[0048] Time decay factor ;in, This indicates the time interval since the last access to the same service; The time decay coefficient is used to control the decay coefficient.

[0049] Depth weights ;in, Indicates the depth of influence coefficient. This indicates the current call depth, i.e., the length of the path vector;

[0050] Historical pattern confidence ;in, This indicates the number of times a virtuous cycle of circular dependency has been detected historically. This indicates the number of times in history that a circular dependency has been detected as a vicious cycle. This represents the balance factor; the vicious cycle is an infinite cycle that leads to the depletion of system resources, while the virtuous cycle is a cycle with a finite number of iterations.

[0051] Therefore, the confidence level of circular dependency is ;in , , The weighting coefficients represent the time decay factor, depth weight, and historical pattern confidence.

[0052] if Then the circular dependency is judged to be benign;

[0053] if The circular dependency is then deemed malicious, and a warning is triggered.

[0054] if Then, the probability of misjudgment due to circular dependency is quantified, including:

[0055] Calculate the prior misclassification probability ;in, This indicates the number of times a historical judgment was correct. Indicates the number of historical misjudgments;

[0056] Calculate the probability of conditional misjudgment based on Bayesian model Among them, the feature vector , , ];

[0057] Real-time misclassification probability estimated based on feature vectors ;in, This represents the sigmoid function. , , , These represent the feature weights;

[0058] if and The call request is allowed to continue; where, and These represent the conditional misjudgment probability threshold and the real-time misjudgment probability threshold, respectively.

[0059] Otherwise, the call request will be marked as pending confirmation and placed in the manual review queue, suspending the service call.

[0060] Preferably, the method of constructing a two-layer detection architecture, combining circular dependency detection and instance redundancy analysis, to comprehensively evaluate single-point failures includes:

[0061] Add instance-level call information to the path vector, including:

[0062] Obtain the instance ID of the actual call corresponding to each service name, the timestamp of the instance, and the health status code of each instance; a healthy instance is one whose response time is less than a preset response threshold.

[0063] The actual instance ID, instance timestamp, and health status code of each instance are added to the path vector to form an extended path vector.

[0064] Perform real-time calculation of instance redundancy, including:

[0065] Calculate and obtain instance health ;in, This indicates the number of currently healthy instances; Indicates the total number of registered instances;

[0066] Calculate the fault domain distribution degree ;in, This represents the maximum number of instances in a single availability zone;

[0067] Calculate the effectiveness of complex equilibrium ;in, This represents the number of requests to the busiest instance. This represents the average number of requests per instance.

[0068] Then, the overall redundancy score ;in, , , These represent the weights for health, distribution, and effectiveness.

[0069] Combining circular dependency detection and instance redundancy, a comprehensive risk score is formed, including:

[0070] Calculate and obtain the circular dependency risk coefficient ;in, This indicates an indicator function; it is 1 when a circular dependency is detected, and 0 otherwise. Indicates the current service;

[0071] Calculate and obtain the single-point risk coefficient of the instance. ;

[0072] Therefore, the overall risk score for the service is: ;

[0073] if Therefore, the overall risk of the service is judged to be low, that is, the single point of risk is low.

[0074] if Therefore, the overall risk of the service is judged to be medium risk, that is, the single point of risk is medium risk.

[0075] if If so, the overall risk of the service is judged to be high, that is, the single point of risk is high.

[0076] Develop dynamic decision-making strategies to address different levels of single-point risks with different handling measures, including:

[0077] When a single point of risk is high, the circuit breaker mechanism is triggered, an alarm is issued and capacity expansion is recommended, and the overall redundancy score, single point of risk coefficient and overall risk score are recorded.

[0078] When a single point of risk is classified as medium risk, a degradation process is triggered, rate limiting is enabled, the operation and maintenance system is asynchronously reported, and the service is flagged but allowed to continue.

[0079] When the single-point risk is low, record the overall redundancy score, single-point risk coefficient, and overall risk score for trend analysis.

[0080] An electronic device includes a processor, a communication module connected to the processor, and a memory, the electronic device being used to implement the aforementioned microservice architecture dependency visualization analysis method.

[0081] A computer-readable storage medium storing a computer program that is executed by a processor to implement the aforementioned microservice architecture dependency visualization analysis method.

[0082] The beneficial effects of this invention are:

[0083] To reduce the probability of misjudgment in the determination of circular dependencies, this invention introduces a multi-dimensional confidence calculation method to extract misjudgments and control the misjudgment rate of circular dependency detection. Furthermore, by combining circular dependency detection with instance redundancy analysis, a comprehensive assessment of single-point failures is conducted to determine the risk level. Attached Figure Description

[0084] Figure 1 This is a flowchart of a microservice architecture dependency visualization analysis method according to the present invention. Detailed Implementation

[0085] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious modifications will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0086] It is understood that the term "a" should be understood as "at least one" or "one or more", that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple, and the term "a" should not be understood as a limitation on the number.

[0087] refer to Figure 1 The technical solution provided by this invention is: a method for visual analysis of microservice architecture dependencies, the method comprising:

[0088] Step 1: Collect traffic data of the target microservice network in the current working environment according to the preset collection frequency, and perform proxy injection and traffic mirroring on the obtained traffic data to obtain tracking data.

[0089] The process of injecting a proxy and mirroring the obtained traffic data to obtain tracking data includes the following steps:

[0090] Traffic data flowing into and out of the corresponding services is obtained through a network proxy (such as Envoy), and a tracing database is embedded in the traffic data of each service. When a service is invoked, a tracing data vector is generated. Specifically, the steps include:

[0091] Upon receiving a call request, the first service generates a unique trace ID, then creates a unit of work and assigns a corresponding unit of work ID to the unit of work;

[0092] Pass the tracking ID and work unit ID to the next service;

[0093] When the next service receives the call request, it creates a parent unit of work and uses the unit of work ID of the previous service as the parent unit of work ID, while also saving the trace ID obtained from the previous service;

[0094] Each work unit and its parent work unit collect the operation name (e.g., API endpoint), service start time, duration, and service name of its corresponding service to construct a service tracking vector. ;

[0095] in, They represent services respectively. The tracking ID, unit of work ID, parent unit of work ID, service start time, service duration, and service name;

[0096] For the first service, which is the starting point of the service call chain, .

[0097] Copy the tracking data vector and traffic data of each service into the tracking environment to obtain tracking data, and send the tracking data vector to the backend of the tracking system in the tracking environment via message queue or direct HTTP.

[0098] The tracking data vector includes tracking ID, work unit ID, parent work unit ID, timestamp, service name, and operation name.

[0099] Step 2: Perform dependency analysis on the tracking data using graph construction algorithms to build a service dependency graph, and then visualize the service dependency graph; specifically, this includes the following steps:

[0100] The backend of the tracking system identifies the service name in each tracking service vector and uses the identified service name as a node.

[0101] Identify the tracing ID of the previous service by using the parent unit of work ID in the tracing service vector of the current service, and obtain the service name of the previous service based on that service ID;

[0102] Establish a directed edge between the current service and the previous service, with the direction pointing from the previous service (i.e., the calling node) to the current service (the called node).

[0103] Multiple nodes and edges constitute a service chain, and multiple service chains constitute a service dependency graph;

[0104] Within a time window, the dependency strength between services that have service call relationships is: ;in, Indicates the first Service within a time window Call service Total number of times Indicates the first The average latency of each call within a time window (latency is introduced because a high-latency call, even if it is not called frequently, may become a system bottleneck, and its dependency is worth paying attention to). Indicates the first The length of a time window ( This is used to normalize the number of calls, so that the intensity calculated in different time windows can be compared.

[0105] By continuously sliding the time window and updating the dependency strength with new tracking data, a decay factor is introduced to prevent outdated dependencies from persisting for a long time.

[0106] Then, the updated dependency strength ;in, (This represents the decay factor, which causes the historical intensity to decay over time). Indicates the first Service within a time window Call service Total number of times Indicates the first The average latency of each call within a time window; Indicates the first The length of a time window;

[0107] Weights are assigned to the corresponding edges in the service dependency graph based on dependency strength.

[0108] The obtained service dependency graph is rendered and output using a graphical library (such as D3.js), including:

[0109] The size of the corresponding node is rendered based on the number of times the service is called within a time window;

[0110] The thickness of an edge is rendered based on the dependency strength, i.e., the edge weight, within a time window.

[0111] Based on a time window The size of the rendering edge determines the color depth.

[0112] The steps for service dependency detection based on the service dependency graph are as follows: Starting from any node in the service dependency graph, perform a depth-first traversal (DFS). During the traversal, maintain a recursive stack. If a node is found to already exist in the current recursive stack, it proves that a back edge has been found, indicating a circular dependency. This method relies on the service dependency graph, but the service dependency graph is fixed within a time window. If a new circular dependency appears within a time window, it cannot be identified in real time.

[0113] In this embodiment, the above problem can be solved by the following steps:

[0114] Step 3: Based on the service dependency graph, perform real-time circular dependency detection and single-point fault fusion awareness on the target microservice network. This includes the following steps:

[0115] Step 3.1: Obtain the service chain from the service dependency graph and embed detection data into the service chain to achieve real-time detection of newly generated circular dependencies, avoiding complete reliance on the (lagging) service dependency graph; specifically including the following steps:

[0116] For each request entering the target microservice network, a path state vector P, i.e., detection data, is initialized. The path vector P is passed between services along the service chain. The path vector P includes the service names of all services that the corresponding service request has visited.

[0117] When a call request arrives at the first service (e.g., the gateway), the first service's trace ID and service start time are retrieved from the first service's trace data vector;

[0118] Initialize the path vector P, add the retrieved trace ID to P, associate the service start time with P, and ensure that P is synchronized with the time window;

[0119] When a call request arrives at the called service, the called service checks whether its own tracking ID already exists in P;

[0120] If so, it is determined to be a circular dependency, a warning is triggered, and an error response is returned to prevent the request from looping indefinitely;

[0121] Otherwise, determine if there is no circular dependency;

[0122] Maintain a recent visitor cache locally for each service. This recent visitor cache is a cache with the key being the tracking ID of the corresponding service and the value being P, and is set to be no less than [value missing]. Time to Live (TTL).

[0123] Setting up a recent visitor cache can prevent duplicate processing of the same path for the same request based on the tracking ID for asynchronous calls or retries; it can also quickly retrieve complete path information from the cache when a circular dependency is detected, for use in warnings and analysis.

[0124] The core of this method lies in shifting the detection logic from centralized, batch topology analysis to a distributed, request-level execution process. By dynamically maintaining and validating a path state within the request's invocation context, any service receiving a request can immediately determine whether the invocation will lead to a circular dependency, thus solving the problem of how to capture newly generated circular dependencies within a time window in real time.

[0125] Step 3.2: Introduce a multi-dimensional confidence calculation and hierarchical decision-making mechanism to identify and quantify the false positive probability of circular dependency detection in advance, thereby controlling the false positive rate of circular dependency detection. Specifically, this includes:

[0126] Construct a confidence calculation model for circular dependencies, including:

[0127] Time decay factor ;in, This indicates the time interval since the last access to the same service; The time decay factor (e.g., 0.1) is used to control the decay factor; the role of the time decay factor is to increase the confidence level of repeated accesses in a short period of time and decrease the confidence level of repeated accesses in a long period of time.

[0128] Depth weights ;in, This represents the depth of influence coefficient (e.g., 0.2). This indicates the current call depth, i.e., the length of the path vector; the purpose of the depth weight is that the deeper the call depth, the higher the risk of a loop.

[0129] Historical pattern confidence ;in, This indicates the number of times a virtuous cycle of circular dependency has been detected historically. This indicates the number of times in history that a circular dependency has been detected as a vicious cycle. The term "balance factor" refers to the balance factor; a vicious cycle is an infinite loop that leads to the exhaustion of system resources, while a benign cycle is a loop with a finite number of iterations (e.g., retries and recursion).

[0130] Therefore, the confidence level of circular dependency is ;in , , The weighting coefficients represent the time decay factor, depth weight, and historical pattern confidence.

[0131] if Then the circular dependency is judged to be benign;

[0132] if The circular dependency is then deemed malicious, and a warning is triggered.

[0133] if Then, the probability of misjudgment due to circular dependency is quantified, including:

[0134] Calculate the prior misclassification probability ;in, This indicates the number of times a historical judgment was correct. Indicates the number of historical misjudgments;

[0135] Calculate the probability of conditional misjudgment based on Bayesian model Among them, the feature vector , , ];

[0136] Real-time misclassification probability estimated based on feature vectors ;in, This represents the sigmoid function. , , , These represent the feature weights;

[0137] if and If the judgment is incorrect, the call request is allowed to continue; among them, and These represent the conditional misjudgment probability threshold and the real-time misjudgment probability threshold, respectively.

[0138] Otherwise, the call request will be marked as pending confirmation and placed in the manual review queue, suspending the service call.

[0139] False positives are unavoidable in circular dependency detection. Common scenarios include: **Benevolent retry mechanism:** Service A fails to call Service B and then calls Service B again according to the retry strategy. False positive: The path vector already contains B, leading the system to mistakenly identify it as a circular dependency. Characteristics of this scenario: The same service appears consecutively with short time intervals. **Bounded recursive call scenario:** In workflow engines or graph computation, Service A may call itself a limited number of times according to business logic. False positive: It is immediately judged as a circular dependency when it is actually controlled recursion. Characteristics of this scenario: Limited call depth and clear termination conditions. **Asynchronous callback path scenario:** Service A → Service B → Message queue → [Later] → Service A (process callback). False positive: Service A finds itself in the historical path during the callback, leading to a false positive. Characteristics of this scenario: Large time span, indirect calls through middleware. **Data sharding routing scenario:** The gateway routes requests to different instances of the same service based on load or data sharding. False positive: Service IDs are the same but instances are different, leading to a false positive. Characteristics of this scenario: Different physical instances but the same logical service. In this embodiment, step 3.2 effectively manages the risk of misjudgment and controls the probability of misjudgment by using a probabilistic approach when performing circular dependency detection.

[0140] Step 3.3: By constructing a two-layer detection architecture, combining circular dependency detection and instance redundancy analysis, a comprehensive assessment of single-point failures is conducted. This includes the following steps:

[0141] Add instance-level call information to the path vector, including:

[0142] Obtain the instance ID of the actual call corresponding to each service name, the timestamp of the instance, and the health status code of each instance; a healthy instance is one whose response time is less than a preset response threshold.

[0143] The actual instance ID, instance timestamp, and health status code of each instance are added to the path vector to form an extended path vector.

[0144] Perform real-time calculation of instance redundancy, including:

[0145] Calculate and obtain instance health ;in, This indicates the number of currently healthy instances; Indicates the total number of registered instances; Obtain from service registries such as Nacos and Consul; and health check endpoints.

[0146] Calculate the fault domain distribution degree ;in, This indicates the maximum number of instances in a single availability zone; the closer the value is to 1, the more evenly the instances are distributed, and the closer it is to 0, the greater the risk of a single availability zone.

[0147] Calculate the effectiveness of complex equilibrium ;in, This represents the number of requests to the busiest instance. This represents the average number of requests per instance.

[0148] Then, the overall redundancy score ;in, , , These represent the weights for health, distribution, and effectiveness.

[0149] Combining circular dependency detection and instance redundancy, a comprehensive risk score is formed, including:

[0150] Calculate and obtain the circular dependency risk coefficient ;in, This indicates an indicator function; it is 1 when a circular dependency is detected, and 0 otherwise. Indicates the current service;

[0151] Calculate and obtain the single-point risk coefficient of the instance. ;

[0152] Therefore, the overall risk score for the service is: ;

[0153] if Therefore, the overall risk of the service is judged to be low, that is, the single point of risk is low.

[0154] if Therefore, the overall risk of the service is judged to be medium risk, that is, the single point of risk is medium risk.

[0155] if If so, the overall risk of the service is judged to be high, that is, the single point of risk is high.

[0156] Develop dynamic decision-making strategies to address different levels of single-point risks with different handling measures, including:

[0157] When a single point of risk is high, the circuit breaker mechanism is triggered, an alarm is issued and capacity expansion is recommended, and the overall redundancy score, single point of risk coefficient and overall risk score are recorded.

[0158] When a single point of risk is classified as medium risk, a degradation process is triggered, rate limiting is enabled, the operation and maintenance system is asynchronously reported, and the service is flagged but allowed to continue.

[0159] When the single-point risk is low, record the overall redundancy score, single-point risk coefficient, and overall risk score for trend analysis.

[0160] Existing single point of failure detection methods are based on service dependency graphs, which use service nodes rather than service instances as nodes. While these graphs can detect single points of failure, they cannot determine whether the service is supported by 100 load-balanced instances or only one instance. The latter is a true single point of failure, while the former is not. In this example, step 3.3 addresses the problem of existing single point-of-failure detection methods based on service dependency graphs and centrality metrics that fail to recognize instance redundancy.

[0161] The present invention also provides an electronic device, including a processor, a communication module connected to the processor, and a memory, the electronic device being used to implement the aforementioned microservice architecture dependency visualization analysis method.

[0162] The present invention also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the aforementioned microservice architecture dependency visualization analysis method.

[0163] The processes described above with reference to the flowcharts in the embodiments disclosed in this invention can be implemented as computer software programs. The embodiments disclosed in this invention 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 via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU), it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wire segments, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless segments, wire segments, optical fibers, RF, etc., or any suitable combination thereof.

[0164] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0165] Those skilled in the art should understand that the embodiments of the present invention described above and shown in the accompanying drawings are merely examples and do not limit the present invention. The purpose of the present invention has been fully and effectively achieved, and the functions and structural principles of the present invention have been demonstrated and explained in the embodiments. Without departing from the stated principles, the implementation of the present invention may have any changes or modifications.

Claims

1. A method for visual analysis of dependencies in microservice architecture, characterized in that, The method includes: Traffic data of the target microservice network in the current working environment is collected according to the preset collection frequency, and the obtained traffic data is injected by proxy and mirrored to obtain tracking data. Dependency analysis is performed on the tracking data using graph building algorithms to construct a service dependency graph, which is then visualized. Based on the service dependency graph, real-time circular dependency detection and single-point fault fusion perception are performed on the target microservice network, including: obtaining service chains from the service dependency graph and embedding detection data in the service chains to realize real-time detection of newly generated circular dependencies, avoiding complete reliance on the service dependency graph; By introducing a multi-dimensional confidence calculation and hierarchical decision-making mechanism, the false positives of circular dependency detection can be identified in advance and the false positive probability can be quantified in order to control the false positive rate of circular dependency detection. By constructing a two-layer detection architecture, combining circular dependency detection and instance redundancy analysis, single point of failure can be comprehensively evaluated.

2. The method for visual analysis of microservice architecture dependencies according to claim 1, characterized in that, The process of injecting proxy data and mirroring traffic to obtain tracking data includes: Traffic data flowing into and out of the corresponding services is obtained through a network proxy, and a tracking database is embedded in the traffic data of each service. When a service is invoked, a tracking data vector is generated. Copy the tracking data vector and traffic data of each service into the tracking environment to obtain tracking data, and send the tracking data vector to the backend of the tracking system in the tracking environment via message queue or direct HTTP. The tracking data vector includes tracking ID, work unit ID, parent work unit ID, timestamp, service name, and operation name.

3. The method for visual analysis of microservice architecture dependencies according to claim 2, characterized in that, The method involves embedding a tracing database in each service, generating a tracing data vector when the service is invoked, including: Upon receiving a call request, the first service generates a unique trace ID, then creates a unit of work and assigns a corresponding unit of work ID to the unit of work; Pass the tracking ID and work unit ID to the next service; When the next service receives the call request, it creates a parent unit of work and uses the unit of work ID of the previous service as the parent unit of work ID, while also saving the trace ID obtained from the previous service; Each work unit and its parent work unit collect the operation name, service start time, duration, and service name of their corresponding service to construct a service tracking vector. ; in, They represent services respectively. The tracking ID, unit of work ID, parent unit of work ID, service start time, service duration, and service name; For the first service, which is the starting point of the service call chain, .

4. The microservice architecture dependency visualization analysis method according to claim 3, characterized in that, The process of performing dependency analysis on the tracking data using a graph construction algorithm to construct a service dependency graph, and then visualizing the service dependency graph, includes: The backend of the tracking system identifies the service name in each tracking service vector and uses the identified service name as a node. Identify the tracing ID of the previous service by using the parent unit of work ID in the tracing service vector of the current service, and obtain the service name of the previous service based on that service ID; Establish a directed edge between the current service and the previous service, with the direction pointing from the previous service to the current service; Multiple nodes and edges constitute a service chain, and multiple service chains constitute a service dependency graph; Within a time window, the dependency strength between services that have service call relationships is: ;in, Indicates the first Service within a time window Call service Total number of times Indicates the first The average latency of each call within a time window; By continuously sliding the time window and updating the dependency strength with new tracking data, a decay factor is introduced to prevent outdated dependencies from persisting for a long time. Then, the updated dependency strength ;in, Indicates the attenuation factor; Indicates the first Service within a time window Call service Total number of times Indicates the first The average latency of each call within a time window; Indicates the first The length of a time window; Indicates the first The length of a time window; Weights are assigned to the corresponding edges in the service dependency graph based on dependency strength. The obtained service dependency graph is rendered and output using a graphical library, including: The size of the corresponding node is rendered based on the number of times the service is called within a time window; The thickness of an edge is rendered based on the dependency strength, i.e., the edge weight, within a time window. Based on a time window The size of the rendering edge determines the color depth.

5. The microservice architecture dependency visualization analysis method according to claim 4, characterized in that, The method of embedding detection data in the service chain to achieve real-time detection of newly generated circular dependencies includes: For each request entering the target microservice network, a path state vector P, i.e., detection data, is initialized. The path vector P is passed between services along the service chain. The path vector P includes the service names of all services that the corresponding service request has visited. When a call request arrives at the first service, the trace ID and service start time of the first service are retrieved from the trace data vector of the first service. Initialize the path vector P, add the retrieved trace ID to P, and associate the service start time with P; When a call request arrives at the called service, the called service checks whether its own tracking ID already exists in P; If so, it is determined to be a circular dependency, a warning is triggered, and an error response is returned to prevent the request from looping indefinitely; Otherwise, determine if there is no circular dependency; Maintain a recent visitor cache locally for each service. This recent visitor cache is a cache with the key being the tracking ID of the corresponding service and the value being P, and is set to be no less than [value missing]. Time to Live (TTL).

6. The method for visual analysis of microservice architecture dependencies according to claim 5, characterized in that, The introduction of multi-dimensional confidence calculation and hierarchical decision-making mechanisms to identify and quantify the false positive probability of circular dependency detection in advance, thereby controlling the false positive rate of circular dependency detection, includes: Construct a confidence calculation model for circular dependencies, including: Time decay factor ;in, This indicates the time interval since the last access to the same service; The time decay coefficient is used to control the decay coefficient. Depth weights ;in, Indicates the depth of influence coefficient. This indicates the current call depth, i.e., the length of the path vector; Historical pattern confidence ;in, This indicates the number of times a virtuous cycle of circular dependency has been detected historically. This indicates the number of times in history that a circular dependency has been detected as a vicious cycle. This represents the balance factor; the vicious cycle is an infinite loop that leads to the depletion of system resources, while the virtuous cycle is a loop with a finite number of iterations. Therefore, the confidence level of circular dependency is ;in , , The weighting coefficients represent the time decay factor, depth weight, and historical pattern confidence. if Then the circular dependency is judged to be benign; if The circular dependency is then deemed malicious, and a warning is triggered. if Then, the probability of misjudgment due to circular dependency is quantified, including: Calculate the prior misclassification probability ;in, This indicates the number of times a historical judgment was correct. Indicates the number of historical misjudgments; Calculate the probability of conditional misjudgment based on Bayesian model Among them, the feature vector , , ]; Real-time misclassification probability estimated based on feature vectors ;in, This represents the sigmoid function. , , , These represent the feature weights; if and The call request is allowed to continue; where, and These represent the conditional misjudgment probability threshold and the real-time misjudgment probability threshold, respectively. Otherwise, the call request will be marked as pending confirmation and placed in the manual review queue, suspending the service call.

7. The method for visual analysis of microservice architecture dependencies according to claim 6, characterized in that, The method involves constructing a two-layer detection architecture, combining circular dependency detection and instance redundancy analysis, to comprehensively evaluate single-point failures, including: Add instance-level call information to the path vector, including: Obtain the instance ID of the actual call corresponding to each service name, the timestamp of the instance, and the health status code of each instance; a healthy instance is one whose response time is less than a preset response threshold. The actual instance ID, instance timestamp, and health status code of each instance are added to the path vector to form an extended path vector. Perform real-time calculation of instance redundancy, including: Calculate and obtain instance health ;in, This indicates the number of currently healthy instances; Indicates the total number of registered instances; Calculate the fault domain distribution degree ;in, This represents the maximum number of instances in a single availability zone; Calculate the effectiveness of complex equilibrium ;in, This represents the number of requests to the busiest instance. This represents the average number of requests per instance. Then, the overall redundancy score ;in, , , These represent the weights for health, distribution, and effectiveness. Combining circular dependency detection and instance redundancy, a comprehensive risk score is formed, including: Calculate and obtain the circular dependency risk coefficient ;in, This indicates an indicator function; it is 1 when a circular dependency is detected, and 0 otherwise. Indicates the current service; Calculate and obtain the single-point risk coefficient of the instance. Therefore, the overall risk score for the service is: ； if Therefore, the overall risk of the service is judged to be low, that is, the single point of risk is low. if Therefore, the overall risk of the service is judged to be medium risk, that is, the single point of risk is medium risk. if If so, the overall risk of the service is judged to be high, that is, the single point of risk is high. Develop dynamic decision-making strategies to address different levels of single-point risks with different handling measures, including: When a single point of risk is high, the circuit breaker mechanism is triggered, an alarm is issued and capacity expansion is recommended, and the overall redundancy score, single point of risk coefficient and overall risk score are recorded. When a single point of risk is classified as medium risk, a degradation process is triggered, rate limiting is enabled, the operation and maintenance system is asynchronously reported, and the service is flagged but allowed to continue. When the single-point risk is low, record the overall redundancy score, single-point risk coefficient, and overall risk score for trend analysis.

8. An electronic device, comprising a processor, a communication module connected to the processor, and a memory, characterized in that, The electronic device is used to implement the microservice architecture dependency visualization analysis method described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement any one of the microservice architecture dependency visualization analysis methods according to claims 1-7.

Images