Microservice state monitoring method, gateway, electronic device, and storage medium

Abstract

The application provides a micro-service state monitoring method, a gateway, an electronic device and a storage medium, solves the problems of high cost of monitoring and tracking of micro-service state under a micro-service architecture, inconvenience of monitoring and tracking, and inability to monitor in all scenarios, the monitoring method is applied to the gateway, and comprises the following steps: receiving an interface request sent by a request node, the interface request having header information, the header information comprising: an interface identifier of a requested interface, a node identifier of the request node, and a node identifier of a requested node; generating an interface request topology graph according to the node identifier of the request node and the interface identifier of the requested interface; and analyzing the interface request topology graph to obtain micro-service state information. By generating the interface request topology graph according to the header information and analyzing the interface request topology graph, the micro-service state information can be monitored conveniently and accurately.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of microservices, and in particular to a microservice state monitoring method, a gateway, an electronic device and a storage medium. BACKGROUND

[0002] In enterprise applications, microservice architecture can help existing business software of an enterprise better cope with complex business requirements, technical challenges and market changes, improve the flexibility, scalability and maintainability of the system, and thus provide a stronger competitive advantage for the enterprise. Microservice architecture can be generally divided into three granularities, namely microservice application, microservice node and microservice interface. Each microservice application can run on one or more microservice nodes, and each running microservice node has multiple microservice interfaces. As can be seen, the microservice architecture topology is very complex, and the calling relationship between nodes is complex and variable. Therefore, it is difficult to accurately monitor and track the microservice state.

[0003] The existing method for monitoring and tracking the microservice state is to use container orchestration tools such as Zipkin, Jaeger, etc. However, these container orchestration tools require high resource overhead and cost, and can only work in special scenarios. SUMMARY

[0004] In order to solve the problems of high cost, inconvenience and inability to monitor in all scenarios for monitoring and tracking the microservice state under the microservice architecture, the present application provides a microservice state information monitoring method, a gateway, an electronic device and a storage medium.

[0005] In a first aspect, the present application provides a microservice state monitoring method applied to a gateway, the monitoring method comprising:

[0006] receiving an interface request sent by a request node, the interface request having header information, the header information at least including an interface identifier of a requested interface, a node identifier of the request node, and a node identifier of a requested node, the interface request being used to request a microservice; generating a request interface node according to the node identifier of the request node and the interface identifier of the requested interface; generating a requested interface node according to the node identifier of the requested node and the interface identifier of the requested interface; establishing an edge between the request interface node and the requested interface node as an interface association edge according to the interface identifier of the requested interface, the node identifier of the request node and the node identifier of the requested node; adding an interface weight value and an interface call number of the interface request on the interface association edge according to a processing time and a call number of the interface request, to obtain an interface request topology graph; and analyzing the interface request topology graph to obtain microservice state information.

[0007] In the embodiments of the present application, in the head information of the interface request message, the node identifier of the request node, the node identifier of the requested node, and the interface identifier of the requested interface are included, and the three identifiers can directly determine the calling relationship of a microservice interface between nodes. Therefore, the interface request topology graph is generated according to the node identifier of the request node, the node identifier of the requested node, and the interface identifier of the requested interface, the calling relationship of the interface request between the microservice nodes can be obtained as a whole, and then the state information of the microservice can be conveniently and accurately obtained by analyzing the interface request topology graph.

[0008] Optionally, the microservice state information includes an interface hotspot, and the analyzing the interface request topology graph to obtain the microservice state information includes:

[0009] For each requested interface node in the interface request topology graph, the sum of the increments of the interface weight values and the sum of the increments of the interface calling times of the corresponding associated edges in a first preset time range are obtained; for each requested interface node, in a case where the sum of the increments of the interface weight values is greater than a preset interface processing time threshold or the sum of the increments of the interface calling times is greater than a preset interface calling frequency, the requested interface node is determined to be an interface hotspot in the first preset time range.

[0010] Optionally, in a case where the request node sends multiple interface requests to the requested node; the method further includes:

[0011] According to the node identifier of the request node and the node identifier of the requested node, the multiple interface requests are aggregated, and the interface weight values and the interface calling times of each aggregated interface request are accumulated as node weight values and node calling times; a request instance node is created according to the node identifier of the request node; a requested instance node is created according to the node identifier of the requested node; an edge is established between the request instance node and the requested instance node according to the node identifier of the request instance node and the node identifier of the requested instance node; the node weight values and the node calling times are added to the established edge to obtain a node request topology graph; the node request topology graph is analyzed to obtain the microservice state information.

[0012] Optionally, the microservice state information further includes a node hotspot, and the analyzing the node request topology graph to obtain the microservice state information includes:

[0013] For each node in the node request topology graph, obtain the sum of the increments of the node weight of the edge corresponding to the node as the requested instance node and the sum of the increments of the node call times in a second preset time range; for each node in the node request topology graph, if the sum of the increments of the node weight of the node is greater than a preset node processing time threshold, or the sum of the increments of the node call times of the node is greater than a preset node call frequency, determine that the node is a node hotspot in the second preset time range.

[0014] Optionally, the method further comprises:

[0015] According to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs, each pair of nodes with edges connected in the node request topology graph is aggregated, and the node weight value and the node call times of each aggregated pair of nodes are accumulated as microservice weight value and microservice call times; a requested microservice node is created according to the microservice to which the requested instance node belongs; a requested microservice node is created according to the microservice to which the requested instance node belongs; a edge is established between the requested microservice node and the requested microservice node according to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs; the microservice weight value and the microservice call times are added to the established edge to obtain a microservice request topology graph; the microservice node topology graph is analyzed to obtain microservice state information.

[0016] Optionally, the microservice state information includes microservice hotspots, and the analysis of the microservice node topology graph to obtain the microservice state information comprises:

[0017] For each node in the microservice request topology graph, obtain the sum of the increments of the microservice weight of the edge corresponding to the node as the requested microservice node and the sum of the increments of the microservice call times; for each node in the microservice request topology graph, if the sum of the increments of the microservice weight of the node is greater than a preset microservice processing time threshold, or the sum of the increments of the microservice call times of the node is greater than a preset microservice call frequency, determine that the microservice corresponding to the node is a microservice hotspot in the third preset time range.

[0018] Optionally, the method further comprises:

[0019] Periodically collect and save the interface request topology graph and the microservice state information; in response to a query request of a client, according to the interface request topology graph or the microservice state information, return a query result to the client.

[0020] Optionally, the query request comprises a microservice node identifier, and the returning of the query result to the client according to the interface request topology or the microservice state information comprises:

[0021] filtering, from the nodes of the interface request topology, a node identifier of a requested node or a node identifier of a requested node matching the microservice node identifier; segmenting the interface request topology to segment out the requested interface node or the requested interface node and the connection relationship therebetween that meet the filtering requirement, and returning the segmentation result to the client as the query result.

[0022] Optionally, the query request comprises a start time and an end time, and the microservice state information at least comprises an interface hotspot, and the returning of the query result to the client according to the interface request topology or the microservice state information comprises:

[0023] querying, from the microservice state information, the interface hotspot between the start time and the end time; and returning the queried interface hotspot to the client.

[0024] Optionally, the query request comprises a start time and an end time, and the returning of the query result to the client according to the interface request topology or the microservice state information comprises:

[0025] calculating an interface weight increment and an interface call number increment of each requested interface node in the interface request topology during the start time and the end time; calculating an interface average call duration according to the interface weight increment and the interface call number increment, and inversely sorting the requested interface nodes according to the interface average call duration; obtaining a requested interface node with an interface average call duration greater than a preset weight threshold value, and determining the requested interface node as a slow interface; and returning the slow interface to the client.

[0026] Optionally, the adding of the interface weight value of the interface request on the interface associated edge according to the processing time of the interface request comprises:

[0027] calculating the weight value of the microservice request wherein t represents a processing duration of the microservice request, μ represents a processing duration standard deviation, represents an average processing duration of the microservice request, and the weight value h of the microservice request is determined as the interface weight value of the interface associated edge.

[0028] In a second aspect, the present application provides a gateway for microservice state monitoring, the gateway comprising:

[0029] receive a request node sending an interface request, the interface request has header information, the header information at least includes: interface identifier of the requested interface, node identifier of the request node, node identifier of the requested node, the interface request is used for requesting micro service;

[0030] a topology graph generation module, configured to generate a request interface node according to the node identifier of the request node and the interface identifier of the requested interface; generate a requested interface node according to the node identifier of the requested node and the interface identifier of the requested interface; establish an edge between the request interface node and the requested interface node according to the interface identifier of the requested interface, the node identifier of the request node and the node identifier of the requested node, as an interface associated edge; add interface weight value and interface call times of the interface request on the interface associated edge according to processing time and call times of the interface request, to obtain an interface request topology graph;

[0031] a state analysis module, configured to analyze the interface request topology graph to obtain micro service state information.

[0032] Optionally, the micro service state information includes interface hot spots, and the state analysis module is specifically configured to, for each requested interface node in the interface request topology graph, obtain the increment of the interface weight value and the increment of the interface call times of the corresponding associated edge within a first preset time range; for each requested interface node, if the increment of the interface weight value is greater than a preset interface processing time threshold or the increment of the interface call times is greater than a preset interface call frequency, the requested interface node is determined as an interface hot spot in the first preset time range.

[0033] Optionally, in the case that the request node sends multiple interface requests to the requested node; the gateway is further configured to aggregate the multiple interface requests according to the node identifier of the request node and the node identifier of the requested node, and accumulate the interface weight value and the interface call times of each aggregated interface request as node weight value and node call times; create a request instance node according to the node identifier of the request node; create a requested instance node according to the node identifier of the requested node; establish an edge between the request instance node and the requested instance node according to the node identifier of the request instance node and the node identifier of the requested instance node; add the node weight value and the node call times on the established edge to obtain a node request topology graph; analyze the node request topology graph to obtain micro service state information.

[0034] Optionally, the microservice state information further comprises node hotspots, and the gateway is specifically configured to: for each node in the node request topology graph, obtain a sum of increments of node weights of edges corresponding to the node as a requested instance node and a sum of increments of node call times in a second preset time range; for each node in the node request topology graph, determine the node as a node hotspot in the second preset time range if the sum of increments of node weights of the node is greater than a preset node processing duration threshold or the sum of increments of node call times of the node is greater than a preset node call frequency.

[0035] Optionally, the gateway is further configured to: aggregate each pair of nodes with edges connected in the node request topology graph according to microservices to which the requested instance node and the requested instance node belong, and accumulate node weight values and node call times of each pair of nodes after aggregation as microservice weight values and microservice call times; create a requested microservice node according to a microservice to which the requested instance node belongs; create a requested microservice node according to a microservice to which the requested instance node belongs; establish an edge between the requested microservice node and the requested microservice node according to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs; and add the microservice weight values and the microservice call times on the established edge to obtain a microservice request topology graph; and analyze the microservice node topology graph to obtain microservice state information.

[0036] Optionally, the microservice state information comprises microservice hotspots, and the gateway is specifically configured to: for each node in the microservice request topology graph, obtain a sum of increments of microservice weights of edges corresponding to the node as a requested microservice node and a sum of increments of microservice call times in a third preset time range; and determine a microservice corresponding to the node as a microservice hotspot in the third preset time range if the sum of increments of microservice weights of the node is greater than a preset microservice processing duration threshold or the sum of increments of microservice call times of the node is greater than a preset microservice call frequency.

[0037] Optionally, the gateway is further configured to: periodically collect and save the interface request topology graph and the microservice state information; and in response to a query request of a client, return a query result to the client according to the interface request topology graph or the microservice state information.

[0038] Optionally, the query request includes a microservice node identifier, and the gateway is specifically configured to filter out a node identifier of a requested node or a node identifier of a requested node that matches the microservice node identifier from the node identifiers of the interface request topology; segment the interface request topology to segment out the requested interface node or the requested interface node and the connection relationship thereof that meet the filtering requirement, and return the segmentation result to the client as the query result.

[0039] Optionally, the query request includes a start time and an end time, and the microservice state information includes at least an interface hotspot, and the gateway is specifically configured to query the interface hotspot between the start time and the end time from the microservice state information; and return the queried interface hotspot to the client.

[0040] Optionally, the query request includes a start time and an end time, and the gateway is specifically configured to calculate an interface weight increment and an interface call number increment of each requested interface node in the interface request topology during the start time and the end time; calculate an interface average call duration according to the interface weight increment and the interface call number increment, and sort the requested interface nodes in a reverse order according to the interface average call duration; obtain a requested interface node with an interface average call duration greater than a preset weight threshold, and determine the requested interface node as a slow interface; and return the slow interface to the client.

[0041] In a third aspect, the present application provides an electronic device, comprising:

[0042] a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the microservice state monitoring method according to any one of the first aspect.

[0043] In a fourth aspect, the present application provides a storage medium, when the instructions in the storage medium are executed by the processor of an electronic device, the electronic device can execute the microservice state monitoring method according to any one of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1 A flowchart of a microservice state monitoring method provided by the first embodiment of the present application;

[0045] Figure 2 A definition field of the header information of the microservice interface request message provided by the first embodiment of the present application;

[0046] Figure 3 A specific example of the header information of the microservice interface request message provided by the first embodiment of the present application;

[0047] Figure 4A flowchart of a chain interface request provided by the first embodiment of the application is shown in FIG. 1.

[0048] Figure 5 Two schematic diagrams of an interface request topology provided by the first embodiment of the application are shown in FIGS. 2 and 3.

[0049] Figure 6 A schematic diagram of a node request topology provided by the first embodiment of the application is shown in FIG. 4.

[0050] Figure 7 A schematic diagram of a microservice request topology provided by the first embodiment of the application is shown in FIG. 5.

[0051] Figure 8 A schematic diagram of a structure of a gateway for monitoring the state of a microservice provided by the second embodiment of the application is shown in FIG. 6.

[0052] Figure 9 A schematic diagram of a structure of an electronic device provided by the third embodiment of the application is shown in FIG. 7.

[0053] Figure 10 A schematic diagram of a structure of a gateway instance in a specific application scenario provided by the second embodiment of the application is shown in FIG. 8. DETAILED DESCRIPTION

[0054] In order to better understand the technical solutions of the application, a simple introduction to the application scenario is given below.

[0055] The technical solutions of the application are applied to a microservice architecture. The microservice architecture is generally divided into three granularities, namely, a microservice application granularity, a microservice node granularity, and a microservice interface granularity. A microservice application can run multiple microservice instances, each of which runs on a node, and each microservice instance has multiple microservice interfaces to provide different functions externally. Among them, the microservices communicate with each other through a gateway. Since monitoring the state of a microservice can improve the maintainability and stability of the microservice, in related technologies, a container orchestration tool is generally used to monitor and track the state of a microservice. However, this method has high monitoring and tracking costs, is inconvenient to use, and cannot monitor all scenarios. Therefore, the application provides a method for monitoring the state of a microservice, a gateway, an electronic device, and a storage medium. The method is based on the calling relationship between microservices, and ultimately can be attributed to the calling relationship of a microservice interface. Therefore, as long as the request node, the target node, and the calling interface of the current interface request can be recorded in the interface request, the interface request topology between nodes can be constructed according to the above information, and the state information of the microservice can be obtained by analyzing the interface request topology. The state information of the microservice refers to the calling information at different granularities of the microservice architecture.

[0056] To better understand the technical solution of this application, the technical solution will be described in detail below through specific embodiments.

[0057] Example 1

[0058] This application provides a method for monitoring the status of microservices. This method is applied to a gateway, where microservice nodes must forward interface request messages through the gateway when calling each other's microservice interfaces. The method includes:

[0059] S101: Receive an interface request sent by a requesting node. The interface request has header information, which includes at least: the interface identifier of the requested interface, the node identifier of the requesting node, and the node identifier of the requested node. The interface request is used to request a microservice.

[0060] The header information is generated by the requesting node according to a predefined request protocol. This request protocol specifies that when a microservice makes an interface request, it must carry header information with fixed fields and format. This header information includes at least the interface identifier of the requested interface, the node identifier of the requesting node, and the node identifier of the requested node. Optionally, it may also include a request identifier and a request time. The node identifier includes two parts: the microservice identifier and the node ID. The specific header information format is as follows: Figure 2 As shown. Figure 3 Here is a specific example of the header information, where / A represents the interface identifier of the requested interface, 23159240421 represents the request identifier, 20240808191723 represents the request time as 19:17:23 on August 8, 2023, ServerA is the microservice to which the requesting node belongs, node1 is the instance node of microservice A, and is also the microservice node that actually initiated the interface request, ServerB is the microservice to which the requested node belongs. Since the interface request message has just arrived at the gateway, the instance node of the requested microservice cannot be determined at this time.

[0061] Specifically, in the micro-service architecture, the interface call across services is forwarded by the gateway. Therefore, when an instance node of service A initiates an interface request to service B, since the instance node of service A does not know which instance node of service B provides the service, the interface request message is first forwarded to the gateway between service A and service B. The gateway parses the header information of the interface request message, reads the micro-service identifier in the node identifier of the requested node, and selects an instance node of service B as the target instance node by querying the mapping relationship table between micro-services and micro-service nodes stored in the gateway. The target instance node ID is written into the node ID of the node identifier of the requested node, and the interface request message is forwarded to the target instance node. Then, the target instance node responds to the interface request and forwards the response message to the instance node initiating the interface request through the gateway. Meanwhile, the gateway records the processing time length of the interface request.

[0062] In an application scenario, as shown in Figure 4 When the instance node node1 of service A initiates an interface request to service B, the gateway 1 receives the header information of the interface request, fills an instance node node2 of service B into the node identifier of the requested node, and forwards the interface request to the node2 of service B. The node2 of service B also needs the resource of service C to respond to the request. In this case, in order to trace back to the request link of the same interface request, when service B initiates a new interface request to a node of service C through the gateway 2, the original request identifier reqID needs to be kept unchanged.

[0063] S102: generating a request interface node according to the node identifier of the request node and the interface identifier of the requested interface;

[0064] S103: generating a requested interface node according to the node identifier of the requested node and the interface identifier of the requested interface;

[0065] S104: establishing an edge between the request interface node and the requested interface node as an interface association edge according to the interface identifier of the requested interface, the node identifier of the request node and the node identifier of the requested node;

[0066] Specifically, since the interface request of one microservice interface occurs between two microservice instance nodes, the interface calling relationship can be determined by the node identifier of the request node, the node identifier of the request node and the interface identifier of the requested interface. Before generating the request interface node or the requested interface node, first, according to the node identifier of the request node or the requested interface, and the interface identifier of the requested interface, it is judged whether the same node already exists in the interface request topology graph. Specifically, the node identifier of the request node and the interface identifier of the requested interface are compared with the node identifier of the request node and the interface identifier of the requested interface in the interface request topology graph, or the node identifier of the requested node and the interface identifier of the requested interface are compared with the node identifier of the requested node and the interface identifier of the requested interface in the interface request topology graph, if the two do not match, it means that the same node does not exist. If they match, it means that the same node already exists in the interface request topology graph.

[0067] When the request interface node does not exist the same node and the requested interface node also does not exist the same node, it means that a new interface is called. The request interface node is generated according to the node identifier of the request node and the interface identifier of the requested interface; the requested interface node is generated according to the node identifier of the requested node and the interface identifier of the requested interface, and the interface association edge is established between the request interface node and the requested interface node according to the node identifier of the request node, the node identifier of the requested node and the interface identifier of the requested interface.

[0068] When the request interface node does not exist the same node and the requested interface node exists the same node, it means that another microservice node calls the requested interface. The request interface node is generated according to the node identifier of the request node and the interface identifier of the requested interface; the interface association edge is established between the request interface node and the requested interface node according to the node identifier of the request node, the node identifier of the requested node and the interface identifier of the requested interface.

[0069] When the request interface node and the requested interface node both exist, it means that the same interface is called between the two nodes for multiple times. Then the nodes are not recreated.

[0070] S105: according to the processing time and the calling times of the interface request, adding the interface weight value and the interface calling times of the interface request on the interface association edge to obtain an interface request topology graph;

[0071] Specifically, the method for calculating the interface weight value of the interface request is not limited.

[0072] If the microservice interface is only called once between two microservice nodes, the calculated interface weight value and the calling times are directly added to the interface association edge to obtain the interface request topology graph, as shown in the following figure: Figure 5The first case in the above formula (1) is that the interface request is a single request.

[0073] If the microservice interface is called multiple times between two microservice nodes, the interface weight value and the number of calls obtained each time need to be accumulated on the interface associated edge to obtain the interface request topology graph, as shown in FIG. 2. Figure 5 The second case in the above formula (1) is that the interface request is a single request.

[0074] In an embodiment, the step S105 of adding the interface weight value of the interface request on the interface associated edge according to the processing time of the interface request comprises:

[0075] calculating the weight value of the microservice request wherein t represents the processing duration of the microservice request; μ represents the standard deviation of the processing duration, represents the average processing duration of the microservice request; and the weight value h of the microservice request is determined as the interface weight value of the interface associated edge.

[0076] Specifically, the processing duration of each interface request is saved at the gateway. According to the processing duration of each interface request, the standard deviation of the processing duration of all interface requests and the average processing duration of the interface request can be obtained. Then, the weight value of the microservice request is obtained according to the above formula. In this embodiment, a method for calculating the weight value is provided, and based on this, reference data can be further provided for subsequent acquisition of microservice state information.

[0077] S106: analyzing the interface request topology graph to obtain microservice state information.

[0078] The microservice state information refers to hot spot information at different granularities. For example, interface hot spot, node hot spot or microservice hot spot.

[0079] Specifically, the method for analyzing the interface request topology graph is not limited. Illustratively, the interface weight value is taken as the path length between nodes. Since the longer the path length, the longer the interface processing duration and the higher the load, the higher the possibility of becoming an interface hot spot, a path addressing algorithm can be used to find the requested interface node with a path length greater than a preset threshold in the interface request topology graph. Alternatively, the interface call number can be used for analysis. The more the call number of an interface, the higher the possibility of becoming an interface hot spot. The analysis methods for node hot spot and microservice hot spot are similar, and are not described one by one.

[0080] In the embodiment, an interface request sent by a requesting node is received, the interface request having header information including at least an interface identifier of a requested interface, a node identifier of the requesting node, and a node identifier of a requested node, the interface request being used to request a microservice; a requesting interface node is generated according to the node identifier of the requesting node and the interface identifier of the requested interface; a requested interface node is generated according to the node identifier of the requested node and the interface identifier of the requested interface; an edge is established between the requesting interface node and the requested interface node as an interface association edge according to the interface identifier of the requested interface, the node identifier of the requesting node, and the node identifier of the requested node; and an interface weight value and an interface call frequency of the interface request are added to the interface association edge according to a processing time of the interface request and a call frequency, to obtain an interface request topology graph. Since the node identifier of the requesting node, the node identifier of the requested node, and the interface identifier of the requested interface are included in the header information of the interface request message, and the three identifiers can directly determine the call relationship of a microservice interface between nodes, the interface request topology graph is generated according to the node identifier of the requesting node, the node identifier of the requested node, and the interface identifier of the requested interface, the call relationship of the interface request between microservice nodes can be obtained as a whole, and then the state information of the microservice can be conveniently and accurately obtained by analyzing the interface request topology graph, so that the microservice running state and data request can be conveniently and accurately monitored, and the stability and maintainability of the microservice architecture as a whole are improved.

[0081] In a feasible implementation, the microservice state information includes an interface hotspot, and the step S105 of analyzing the interface request topology graph to obtain the microservice state information includes:

[0082] For each requested interface node in the interface request topology graph, an increment of a sum of interface weight values of corresponding association edges and an increment of a sum of interface call frequencies in a first preset time range are obtained.

[0083] For each requested interface node, if the increment of the sum of interface weight values is greater than a preset interface processing time threshold or the increment of the sum of interface call frequencies is greater than a preset interface call frequency, the requested interface node is determined to be an interface hotspot in the first preset time range.

[0084] The preset interface processing time threshold is a positive number. The preset interface call frequency is a positive integer. The first preset time range is not specifically limited. The interface hotspot refers to an interface with a longer processing time or a higher call frequency.

[0085] Specifically, since the interface request topology graph is continuously generated and accumulated over time, the sum of the interface weight values and the sum of the interface call times of the requested interface nodes and all interface associated edges in the interface request topology graph at a first time can be obtained; then the sum of the interface weight values and the sum of the interface call times of the requested interface nodes and all interface associated edges in the interface request topology graph at a second time are obtained again, wherein the second time is greater than the first time.

[0086] The sum of the interface weight values and the sum of the interface call times at the two times are subtracted according to the node correspondence relationship, that is, the sum of the interface weight values at the two times is subtracted for the same requested interface node, and the sum of the interface call times at the two times is subtracted, to obtain the increments of the sum of the interface weight values and the increments of the sum of the interface call times of the requested interface nodes between the first time and the second time. For each requested interface node, in the case where the increment of the sum of the interface weight values is greater than a preset interface processing time threshold, or the increment of the sum of the interface call times is greater than a preset interface call frequency, the requested interface node is determined to be an interface hotspot between the first time and the second time. In this embodiment, based on the interface request topology graph, microservice state information can be obtained, for example, the interface hotspots in the microservice architecture at each time period can be analyzed, so that the interface hotspots in the microservice architecture can be paid attention to and maintained in time, thereby improving the stability and reliability of the microservice architecture.

[0087] In the case where the request node sends a plurality of interface requests to the requested node, a feasible implementation method further includes:

[0088] According to the node identifier of the request node and the node identifier of the requested node, the plurality of interface requests are aggregated, and the interface weight values and the interface call times of each aggregated interface request are accumulated as node weight values and node call times;

[0089] A request instance node is created according to the node identifier of the request node;

[0090] A requested instance node is created according to the node identifier of the requested node;

[0091] According to the node identifier of the request instance node and the node identifier of the requested instance node, an edge is established between the request instance node and the requested instance node;

[0092] The node weight values and the node call times are added to the established edge to obtain a node request topology graph;

[0093] The node request topology graph is analyzed to obtain microservice state information.

[0094] Specifically, in Figure 5According to the node identifier of the request interface node and the node identifier of the requested interface node, the node pair with the interface association edge on the interface request topology graph is grouped, and the interface weight value and the interface call number on the interface association edge in the group are respectively accumulated to obtain the node weight value and the node call number. Before creating the request instance node or the requested instance node, whether the same node exists in the node request topology graph is determined according to the node identifier.

[0095] If the request instance node and the requested instance node do not exist, the request instance node is created according to the node identifier of the request interface node in the group, the requested instance node is created according to the node identifier of the requested interface node in the group, the request instance node and the requested instance node are connected by the node association edge, and the node weight value and the node call number of the group are added to the node association edge to obtain the node request topology graph as shown in Figure 6 .

[0096] If the node identifier of the request interface node in the group corresponds to the node identifier of one requested instance node in the node request topology graph, it is explained that the requested instance node simultaneously serves as the request instance node of another request, and one requested instance node is created as a second requested instance node according to the node identifier of the requested interface node in the group, the two requested instance nodes are connected by the node association edge, and the node weight value and the node call number of the group are added to the node association edge to obtain the node request topology graph.

[0097] Similarly, if the node identifier of the requested interface node in the group corresponds to the node identifier of one request instance node in the node request topology graph, it is explained that the request instance node simultaneously serves as the requested instance node of another request, one request instance node is created as a second request instance node according to the node identifier of the request interface node in the group, the two request instance nodes are connected by the node association edge, and the node weight value and the node call number of the group are added to the node association edge to obtain the node request topology graph. In this embodiment, for the high-concurrency application scenario that the request node sends multiple interface requests to the requested node, the node request topology graph is constructed, the data is analyzed from another granularity, the microservice state information is comprehensively obtained, and the microservice state is analyzed and monitored.

[0098] In a feasible embodiment, the microservice state information further includes a node hotspot, the node request topology graph is analyzed to obtain the microservice state information, including:

[0099] For each node in the node request topology graph, obtain the sum of the increments of the node weights of the edges corresponding to the node as the requested instance node and the sum of the increments of the node call times in a second preset time range;

[0100] For each node in the node request topology graph, if the sum of the increments of the node weights of the node is greater than a preset node processing duration threshold or the sum of the increments of the node call times of the node is greater than a preset node call frequency, the node is determined to be a node hotspot in the second preset time range.

[0101] The preset node processing duration threshold is a positive number. The preset node call frequency is a positive integer. The node hotspot refers to a node with a longer processing duration or a higher call frequency.

[0102] Specifically, since the node request topology graph is continuously generated and accumulated over time, and the request instance node can also serve as a requested instance node. Therefore, the sum of the node weight values and the sum of the node call times of the requested instance node and the node associated edges corresponding to the requested instance node in the node request topology graph can be obtained at a third time; then the sum of the node weight values and the sum of the node call times of the requested instance node and the node associated edges corresponding to the requested instance node in the node request topology graph are obtained again at a fourth time, where the fourth time is greater than the third time.

[0103] The sum of the node weight values and the sum of the node call times at the two times are subtracted according to the corresponding relationship of the requested instance node, that is, the sum of the node weight values at the two times is subtracted for the same requested instance node, and the sum of the node call times at the two times is subtracted, to obtain the increments of the sum of the node weight values and the increments of the sum of the node call times of the requested interface node between the fourth time and the third time. For each requested instance node, if the increment of the sum of the node weight values is greater than a preset node processing duration threshold or the increment of the sum of the node call times is greater than a preset node call frequency, the requested instance node is determined to be a node hotspot between the third time and the fourth time.

[0104] In this embodiment, based on the node request topology graph, the microservice state information such as the node hotspot can be obtained by analysis, so that the node hotspot in the microservice architecture can be paid attention to and maintained in time, and the stability and reliability of the microservice architecture can be improved.

[0105] In a feasible implementation, the method further includes:

[0106] According to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs, each pair of nodes having an edge connected in the node request topology graph is aggregated, and the node weight value and the node call times of each pair of nodes after aggregation are accumulated as the microservice weight value and the microservice call times;

[0107] According to the microservice to which the requested instance node belongs, a requested microservice node is created;

[0108] According to the microservice to which the requested instance node belongs, a requested microservice node is created;

[0109] According to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs, an edge is established between the requested microservice node and the requested microservice node;

[0110] The microservice weight value and the microservice call times are added to the established edge to obtain a microservice request topology graph;

[0111] The microservice node topology graph is analyzed to obtain microservice state information.

[0112] Specifically, on the basis of the node request topology graph, according to the node identifier of the requested instance node and the node identifier of the requested instance node, the node pair having a node associated edge on the node request topology graph is grouped, and the node weight value and the node call times on the node associated edge in the group are respectively accumulated to obtain the microservice weight value and the microservice call times. Before creating the requested microservice node or the requested microservice node, it is determined whether the same node exists in the microservice request topology graph according to the microservice identifier in the node identifier of the requested instance node or the node identifier of the requested instance node in the group.

[0113] If the requested microservice node and the requested microservice node do not exist, the requested microservice node is created according to the microservice identifier in the node identifier of the requested instance node in the group, the requested microservice node is created according to the microservice identifier in the node identifier of the requested instance node in the group, the requested microservice node and the requested microservice node are connected with a microservice associated edge, and the microservice weight value and the microservice call times of the group are added to the microservice associated edge to obtain a microservice request topology graph.

[0114] If the microservice identifier in the node identifier of the requested instance node in the group corresponds to the microservice identifier of a requested microservice node in the microservice request topology graph, it indicates that the requested microservice node also serves as another requested requested microservice node. A requested microservice node is created as a second requested microservice node according to the microservice identifier in the node identifier of the requested instance node in the group, the two requested microservice nodes are connected by a microservice association edge, and the microservice weight value and the microservice call number of the group are added to the microservice association edge, and the microservice request topology graph is obtained.

[0115] Similarly, if the microservice identifier in the node identifier of the requested instance node in the group corresponds to the microservice identifier of a requested microservice node in the microservice request topology graph, it indicates that the requested microservice node also serves as another requested requested microservice node. A requested microservice node is created as a second requested microservice node according to the microservice identifier in the node identifier of the requested instance node in the group, the two requested microservice nodes are connected by a microservice association edge, and the microservice weight value and the microservice call number of the group are added to the microservice association edge, and the microservice request topology graph is obtained as shown in Figure 7 .

[0116] In the embodiment, on the basis of the above node request topology graph, data can be further mined to generate a microservice request topology graph, data can be analyzed from another granularity, which is beneficial to more comprehensively obtain microservice state information and analyze and monitor the microservice state.

[0117] In a feasible embodiment, the microservice state information includes a microservice hotspot, and the analysis of the microservice node topology graph to obtain the microservice state information includes:

[0118] For each node in the microservice request topology graph, the sum of the increments of the microservice weights and the sum of the increments of the microservice call numbers of the edges corresponding to the node as a requested microservice node in a third preset time range are obtained.

[0119] For each node in the microservice request topology graph, if the sum of the increments of the microservice weights of the node is greater than a preset microservice processing duration threshold, or the sum of the increments of the microservice call numbers of the node is greater than a preset microservice call frequency, it is determined that the microservice corresponding to the node is a microservice hotspot in the third preset time range.

[0120] The preset microservice processing duration threshold is a positive number. The preset microservice call frequency is a positive integer. The microservice hotspot refers to a microservice with a longer processing duration or a higher call frequency.

[0121] Specifically, since the microservice request topology graph is continuously generated and accumulated over time, and the request microservice node can also be a requested microservice node. Therefore, the sum of the microservice weight values of the requested microservice node and the corresponding microservice associated edges of the requested microservice node in the microservice request topology graph and the sum of the microservice call times can be obtained at the fifth time point; then the sum of the microservice weight values of the requested microservice node and the corresponding microservice associated edges of the requested microservice node in the microservice request topology graph and the sum of the microservice call times are obtained again at the fourth time point, wherein the fourth time point is greater than the third time point.

[0122] The sum of the microservice weight values and the sum of the microservice call times at the two time points are subtracted according to the correspondence of the requested microservice node, that is, the sum of the microservice weight values at the two time points is subtracted for the same requested microservice node, and the sum of the microservice call times at the two time points is subtracted, to obtain the increment of the sum of the microservice weight values and the increment of the sum of the microservice call times of the requested microservice node between the fifth time point and the sixth time point. For each requested microservice node, in the case where the increment of the sum of the microservice weight values is greater than a preset microservice processing time threshold, or the increment of the sum of the microservice call times is greater than a preset microservice call frequency, the requested microservice node is determined to be a microservice hotspot between the fifth time point and the sixth time point.

[0123] In the embodiment, based on the microservice request topology graph, the microservice state information such as the microservice hotspot can be obtained, so that the microservice hotspot in the microservice architecture can be paid attention to, and the microservice architecture as a whole can be maintained in time to improve the stability and reliability of the microservice architecture.

[0124] In combination with the above embodiments, the microservice hotspots, node hotspots, and interface hotspots in the architecture can be conveniently determined, and the state information under the microservice architecture can be comprehensively monitored.

[0125] In a feasible implementation manner, in order to provide the monitored microservice state to the outside, the method further includes:

[0126] Periodically collecting and saving the interface request topology graph and the microservice state information;

[0127] In response to a query request of a client, a query result is returned to the client according to the interface request topology graph or the microservice state information.

[0128] In a feasible implementation manner, the query request includes a microservice node identifier, and the query result is returned to the client according to the interface request topology graph or the microservice state information, including:

[0129] filtering out a node identifier of a requested node or a node identifier of a requesting node from the nodes of the interface request topology graph that matches the microservice node identifier;

[0130] segmenting the interface request topology graph to segment out the requested interface node or the requesting interface node and the connection relationship therebetween that meet the filtering requirement, and returning the segmentation result to the client as the query result.

[0131] Specifically, the user inputs a microservice node identifier on the client to initiate a query request for the interface request topology graph; the background receives the query request and filters out a requested interface node whose microservice identifier in the node identifier matches the microservice node identifier input by the client from the requested interface nodes of the interface request topology graph. Then the filtered requested interface node and the requesting interface node associated therewith and the association relationship therebetween are segmented out from the interface request topology graph and returned to the client as the query result.

[0132] In the embodiment, based on the above-mentioned microservice state monitoring method, the monitored microservice state information can be provided to the outside, and based on the query request of the client, the query result is returned to the client. For example, using the microservice node identifier in the query request, the interface nodes (requesting nodes or requested nodes) matching the microservice node identifier in the interface request topology graph and the interface nodes related to the interface nodes can be filtered out, so as to be returned to the client, so that the user can understand the coupling between nodes based on the query result, and the microservice architecture can be maintained conveniently and efficiently.

[0133] In a feasible embodiment, the query request includes a start time and an end time, and the microservice state information includes at least an interface hotspot. The query result is returned to the client according to the interface request topology graph or the microservice state information, including:

[0134] querying the interface hotspots between the start time and the end time from the microservice state information;

[0135] returning the queried interface hotspots to the client.

[0136] The microservice state information includes the interface hotspot, and can also include a node hotspot and a microservice hotspot.

[0137] Specifically, the user inputs a start time and an end time on the client to initiate an interface hotspot query request; the background receives the interface hotspot query request, filters out the interface hotspots between the start time and the end time from the historical interface hotspots, and returns the interface hotspots to the client as the query result.

[0138] In the embodiment, a diversified query method is provided, the query request includes a start time and an end time, the microservice state information at least includes an interface hotspot, based on the query request, the interface hotspot in a time period between the start time and the end time can be found out from the interface request topology graph and the microservice state information collected and saved periodically, and the microservice hotspot is returned to the client. It can be understood that based on the above-mentioned implementation of obtaining the node hotspot and the microservice hotspot, the microservice state information can also include the node hotspot and the microservice hotspot. Based on the query request, the query request is correspondingly returned, and diversified external services are provided.

[0139] In a feasible embodiment, the query request includes a start time and an end time, and the query result is returned to the client according to the interface request topology graph or the microservice state information, including:

[0140] The interface weight increment and the interface call number increment of each requested interface node in the interface request topology graph during the start time and the end time are calculated;

[0141] The interface average call duration is calculated according to the interface weight increment and the interface call number increment, and the requested interface nodes are sorted in descending order according to the interface average call duration;

[0142] The requested interface node with the interface average call duration greater than a preset weight threshold is obtained and determined as a slow interface;

[0143] The slow interface is returned to the client.

[0144] The preset weight threshold is a positive number. The slow interface refers to an interface with a long processing duration.

[0145] Specifically, a user inputs a start time and an end time on a client to initiate a slow interface query request. After the background receives the slow interface query request, the interface weight increment and the interface call number increment of all requested interface nodes between the start time and the end time are filtered out from the interface request topology graph. Then, the interface weight increment and the interface call number increment are divided to obtain the interface average call duration, the requested interface nodes are sorted in descending order according to the interface average call duration, the requested interface node with the interface average call duration greater than a preset weight threshold is filtered out, and the filtered requested interface node is returned to the client as a query result.

[0146] In the embodiment, a slow interface query method is also provided. It can be understood that the above-mentioned microservice state monitoring method can not only determine the interface hotspot, but also determine the slow interface. Based on the query request of the client, the requested interface node with the average interface call duration greater than the preset weight threshold is screened out, so as to return to the client, so that the user can detect the slow interface in time and maintain the stability of the microservice architecture.

[0147] In combination with the above-mentioned embodiments, based on the previously mined, analyzed and stored data, services can be provided to the outside, corresponding query results are returned based on different query requests, the utilization rate of data is improved, the information required by the user is conveniently output, and the maintenance of the microservice architecture is facilitated.

[0148] Embodiment two

[0149] The embodiment of the application provides a gateway 200 for microservice state monitoring, as shown in the figure, the gateway 200 comprises a receiving module 201, a topology graph generation module 202 and a state analysis module 203. Figure 8

[0150] The receiving module 201 is used for receiving the interface request sent by the request node, the interface request has header information, and the header information at least comprises the interface identifier of the requested interface, the node identifier of the request node and the node identifier of the requested node, and the interface request is used for requesting the microservice.

[0151] The topology graph generation module 202 is used for generating the request interface node according to the node identifier of the request node and the interface identifier of the requested interface; generating the requested interface node according to the node identifier of the requested node and the interface identifier of the requested interface; establishing an edge between the request interface node and the requested interface node as an interface association edge according to the interface identifier of the requested interface, the node identifier of the request node and the node identifier of the requested node; adding the interface weight value and the interface call times of the interface request on the interface association edge according to the processing time and the call times of the interface request, and obtaining an interface request topology graph.

[0152] The state analysis module 203 is used for analyzing the interface request topology graph to obtain microservice state information.

[0153] Optionally, the topology graph generation module 202 is specifically used for calculating the weight value h of the microservice request Wherein, t represents the processing duration of the microservice request; μ represents the processing duration standard deviation, represents the average processing duration of the microservice request; the weight value h of the microservice request is determined as the interface weight value of the interface association edge. ​

[0154] Optionally, the microservice state information includes interface hotspots, and the state analysis module 203 is specifically configured to, for each requested interface node in the interface request topology graph, obtain an increment of a sum of interface weight values of corresponding associated edges and an increment of a sum of interface call times within a first preset time range; and for each requested interface node, in a case where the increment of the sum of interface weight values is greater than a preset interface processing time threshold or the increment of the sum of interface call times is greater than a preset interface call frequency, determine that the requested interface node is an interface hotspot within the first preset time range.

[0155] Optionally, the gateway 200 is further configured to aggregate the plurality of interface requests according to the node identifier of the request node and the node identifier of the requested node, and accumulate the interface weight values and the interface call times of each aggregated interface request as node weight values and node call times; create a request instance node according to the node identifier of the request node; create a requested instance node according to the node identifier of the requested node; establish an edge between the request instance node and the requested instance node according to the node identifier of the request instance node and the node identifier of the requested instance node; add the node weight values and the node call times on the established edge to obtain a node request topology graph; and analyze the node request topology graph to obtain microservice state information.

[0156] Optionally, the microservice state information includes node hotspots, and the state analysis module 203 is specifically configured to, for each node in the node request topology graph, obtain a sum of increments of node weights of edges corresponding to the node as a requested instance node and a sum of increments of node call times within a second preset time range; and for each node in the node request topology graph, in a case where the sum of increments of node weights of the node is greater than a preset node processing time threshold or the sum of increments of node call times of the node is greater than a preset node call frequency, determine that the node is a node hotspot within the second preset time range.

[0157] Optionally, the gateway 200 is further configured to aggregate each pair of nodes having edges connected in the node request topology graph according to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs, and accumulate the node weight value and the node call times of each pair of aggregated nodes as the microservice weight value and the microservice call times; create a requested microservice node according to the microservice to which the requested instance node belongs; create a requested microservice node according to the microservice to which the requested instance node belongs; establish an edge between the requested microservice node and the requested microservice node according to the microservice to which the requested instance node belongs and the microservice to which the requested instance node belongs; add the microservice weight value and the microservice call times on the established edge to obtain a microservice request topology graph; and analyze the microservice node topology graph to obtain microservice state information.

[0158] Optionally, the microservice state information includes microservice hotspots, and the state analysis module 203 is specifically configured to, for each node in the microservice request topology graph, obtain the sum of the increments of the microservice weight of the edge corresponding to the node as the requested microservice node and the sum of the increments of the microservice call times in a third preset time range; for each node in the microservice request topology graph, if the sum of the increments of the microservice weight of the node is greater than a preset microservice processing time threshold, or the sum of the increments of the microservice call times of the node is greater than a preset microservice call frequency, determine that the microservice corresponding to the node is a microservice hotspot in the third preset time range.

[0159] Optionally, the gateway 200 is further configured to periodically collect and save the interface request topology graph and the microservice state information; and in response to a query request of a client, return a query result to the client according to the interface request topology graph or the microservice state information.

[0160] Optionally, the query request includes a microservice node identifier, and the gateway 200 is specifically configured to filter out the node identifier of the requested node or the node identifier of the requested node from the nodes of the interface request topology graph that match the microservice node identifier; segment the interface request topology graph to segment out the requested interface node or the requested interface node and their connection relationship that meet the filtering requirements, and return the segmentation result to the client as the query result.

[0161] Optionally, the query request includes a start time and an end time, and the microservice state information includes at least interface hotspots, and the gateway 200 is specifically configured to query the interface hotspots between the start time and the end time from the microservice state information; and return the queried interface hotspots to the client.

[0162] Optionally, the query request includes a start time and an end time, and the gateway 200 is specifically configured to calculate an interface weight increment and an interface call number increment of each requested interface node in the interface request topology graph during the start time and the end time; calculate an interface average call duration according to the interface weight increment and the interface call number increment, and sort the requested interface nodes in a reverse order according to the interface average call duration; obtain a requested interface node with an interface average call duration greater than a preset weight threshold value, and determine the requested interface node as a slow interface; and return the slow interface to the client.

[0163] For example, in an actual application scenario, as shown in Figure 10 The gateway 300 can include a topology network controller 301 (a topology graph generation module), a resource monitor 302 (a state analysis module), a metadata manager 303, a northbound interface module 304, and a configuration module 305.

[0164] The topology network controller 301 is configured to construct a topology network according to a routing record of the gateway; the resource monitor 302 is configured to analyze an interface request topology graph to obtain microservice state information, such as an interface hotspot, a node hotspot, and a microservice hotspot; the metadata manager 303 is configured to periodically collect data generated by the resource monitor 302 and the topology network controller 301, and persistently save microservice node, microservice, and topology information; the northbound interface module 304 is configured to provide a northbound interface query capability for an upper GUI page or an interface with other analysis systems; and the configuration module 305 is configured to reuse gateway service configuration capabilities, and provide configuration information of the gateway monitoring microservice state, such as a data saving period, a hotspot node threshold, and an alarm monitoring threshold.

[0165] Embodiment Three

[0166] The embodiment of the application provides an electronic device 400, as shown in Figure 9 The electronic device 400 includes a processor 401 and a memory 402; the processor 401 is configured to execute a program stored in the memory 402 to implement the microservice state monitoring method in any one of the embodiments.

[0167] It can be understood that the structure shown in the figure is only schematic, and the electronic device 400 can further include more or fewer components than those shown in the figure, or have a different configuration from that shown in the figure.

[0168] For example, the processor 401 and the memory 402 can be connected through a communication bus. For another example, the electronic device can further include components such as a display, a mouse, and a keyboard.

[0169] In the embodiments of the present application, the processor 401 can be a central processor, a microprocessor, a single-chip microcomputer, etc., but is not limited thereto. The memory 402 can be a random access memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, etc., but is not limited thereto.

[0170] In the embodiments of the present application, the electronic device can be, but is not limited to, a desktop computer, a notebook computer, a smart phone, a smart wearable device, a vehicle-mounted device, etc., a physical device, and also can be a virtual machine, etc., a virtual device. In addition, the electronic device is not necessarily a single device, but also can be a combination of multiple devices, such as a server cluster, etc.

[0171] The embodiments of the present application also provide a computer readable storage medium, such as a floppy disk, an optical disk, a hard disk, a flash memory, a U disk, an SD (Secure Digital Memory Card) card, an MMC (Multimedia Card) card, etc., and the computer readable storage medium stores one or more programs. The one or more programs can be executed by one or more processors to implement the microservice state monitoring method according to any one of the embodiments.

[0172] Embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, embodiments of the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, embodiments of the present application can take the form of a computer program product implemented on one or more computer-usable storage media having computer-usable program code embodied in the medium.

[0173] In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented by other manners. The apparatus embodiments described above are only schematic, for example, the division of the units is only a logical function division, and there can be another division manner in actual implementation, and for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0174] The function modules in each of the embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0175] In this document, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations.

[0176] In the present text, the plural means two or more.

[0177] The above only is the embodiment of the present application, and does not limit the protection scope of the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for monitoring the status of microservices, characterized in that, Applied to gateways, the monitoring method includes: The interface request is received from the requesting node. The interface request has header information, which includes at least: the interface identifier of the requested interface, the node identifier of the requesting node, and the node identifier of the requested node. The interface request is used to request a microservice. A request interface node is generated based on the node identifier of the request node and the interface identifier of the requested interface. The requested interface node is generated based on the node identifier of the requested node and the interface identifier of the requested interface. An edge is established between the requesting interface node and the requested interface node based on the interface identifier of the requested interface, the node identifier of the requesting node, and the node identifier of the requested node, serving as an interface association edge; Based on the processing time and number of calls of the interface request, add the interface weight value and the number of calls of the interface request to the interface associated edge to obtain the interface request topology graph; The microservice status information is obtained by analyzing the interface request topology graph.

2. The monitoring method as described in claim 1, characterized in that, The microservice status information includes interface hotspots. The analysis of the interface request topology to obtain the microservice status information includes: For each requested interface node in the interface request topology graph, obtain the increment of the sum of the interface weight values ​​of the corresponding associated edges and the increment of the sum of the number of interface calls within a first preset time range; For each requested interface node, if the increment of the sum of the interface weight values ​​is greater than a preset interface processing time threshold, or the increment of the sum of the number of interface calls is greater than a preset interface call frequency, the requested interface node is determined to be an interface hotspot within the first preset time range.

3. The monitoring method as described in claim 1, characterized in that, When the requesting node sends multiple interface requests to the requested node, the method further includes: Based on the node identifier of the requesting node and the node identifier of the requested node, the multiple interface requests are aggregated, and the interface weight value and the number of interface calls of each aggregated interface request are accumulated as the node weight value and the number of node calls. Create a request instance node based on the node identifier of the request node; Create the requested instance node based on the node identifier of the requested node; Based on the node identifier of the requesting instance node and the node identifier of the requested instance node, an edge is established between the requesting instance node and the requested instance node; Add the node weight value and the node call count to the established edges to obtain the node request topology graph; The node request topology is analyzed to obtain microservice status information.

4. The monitoring method as described in claim 3, characterized in that, The microservice status information also includes node hotspots. The microservice status information is obtained by analyzing the node request topology graph, including: For each node in the node request topology graph, within a second preset time range, obtain the sum of the increments of the node weights of the edges corresponding to the node as the requested instance node and the sum of the increments of the node call count. For each node in the node request topology graph, if the sum of the increments of the node weights of that node is greater than a preset node processing time threshold, or if the sum of the increments of the number of node calls of that node is greater than a preset node call frequency, then that node is determined to be a node hotspot within the second preset time range.

5. The monitoring method as described in claim 3, characterized in that, The method further includes: Based on the microservice to which the request instance node belongs and the microservice to which the requested instance node belongs, each pair of nodes connected by an edge in the node request topology graph is aggregated, and the node weight value and node call count of each aggregated pair of nodes are accumulated as the microservice weight value and microservice call count. Create a request microservice node based on the microservice to which the request instance node belongs; Create the requested microservice node according to the microservice to which the requested instance node belongs; Based on the microservice to which the requesting instance node belongs and the microservice to which the requested instance node belongs, an edge is established between the requesting microservice node and the requested microservice node; Add the microservice weight value and the number of microservice calls to the established edges to obtain the microservice request topology graph; The microservice node topology is analyzed to obtain microservice status information.

6. The monitoring method as described in claim 5, characterized in that, The microservice status information includes microservice hotspots. The analysis of the microservice node topology to obtain the microservice status information includes: For each node in the microservice request topology graph, the sum of the increments of the microservice weights of the edges corresponding to the node as the requested microservice node and the sum of the increments of the number of microservice calls are obtained within a third preset time range. For each node in the microservice request topology graph, if the sum of the increments of the microservice weights of that node is greater than a preset microservice processing time threshold, or if the sum of the increments of the number of microservice calls of that node is greater than a preset microservice call frequency, the microservice corresponding to that node is determined to be a microservice hotspot within the third preset time range.

7. The monitoring method as described in claim 1, characterized in that, The method further includes: Regularly collect and save interface request topology diagrams and microservice status information; In response to a client's query request, the system returns query results to the client based on the interface request topology map or the microservice status information.

8. The monitoring method as described in claim 7, characterized in that, The query request includes a microservice node identifier, and the step of returning the query result to the client based on the interface request topology map or the microservice status information includes: Filter out the node identifier of the request node or the node identifier of the requested node that matches the microservice node identifier from each node of the interface request topology graph. The interface request topology is segmented to identify request interface nodes or requested interface nodes that meet the filtering requirements, along with their connection relationships. The segmentation results are then returned to the client as query results.

9. The monitoring method as described in claim 7, characterized in that, The query request includes a start time and an end time, and the microservice status information includes at least interface hotspots. Returning query results to the client based on the interface request topology map or the microservice status information includes: The interface hotspots between the start time and the end time are queried from the microservice status information; The retrieved API hotspots are returned to the client.

10. The monitoring method as described in claim 7, characterized in that, The query request includes a start time and an end time. Returning the query results to the client based on the interface request topology map or the microservice status information includes: Calculate the interface weight increment and interface call count increment for each requested interface node in the interface request topology graph during the period between the start time and the end time; Calculate the average call duration of the interface based on the interface weight increment and the interface call count increment, and sort the requested interface nodes in reverse order based on the average call duration of the interface. Requested interface nodes whose average call duration exceeds a preset weight threshold are identified as slow interfaces. The slow interface is returned to the client.

11. The monitoring method according to any one of claims 1-10, characterized in that, Based on the processing time of the interface request, an interface weight value for the interface request is added to the interface association edge, including: Calculate the weight value of the microservice request. Where t represents the processing time for obtaining microservice requests; μ represents the standard deviation of processing time. This indicates the average processing time for obtaining microservice requests; the weight value h of the microservice request is determined as the interface weight value of the interface associated edge.

12. A gateway for microservice status monitoring, characterized in that, include: The receiving module is used to receive interface requests sent by requesting nodes. The interface requests have header information, which includes at least: the interface identifier of the requested interface, the node identifier of the requesting node, and the node identifier of the requested node. The interface requests are used to request microservices. The topology graph generation module is used to generate a request interface node based on the node identifier of the request node and the interface identifier of the requested interface; generate a requested interface node based on the node identifier of the requested node and the interface identifier of the requested interface; establish an edge between the request interface node and the requested interface node based on the interface identifier of the requested interface, the node identifier of the request node, and the node identifier of the requested node, as an interface association edge; and add the interface weight value and the number of interface calls of the interface request to the interface association edge according to the processing time and the number of calls of the interface request, to obtain an interface request topology graph. The status analysis module is used to analyze the interface request topology to obtain microservice status information.

13. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the microservice state monitoring method as described in any one of claims 1 to 11.

14. A storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the microservice state monitoring method as described in any one of claims 1 to 11.

15. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the electronic device, the method for monitoring the status of microservices as described in any one of claims 1 to 11 is implemented.

Images