Micro-service traffic processing method and apparatus, electronic device, and storage medium

Abstract

The application relates to the computer technical field, in particular to a micro-service traffic processing method and device, electronic equipment and storage medium; the method comprises the following steps: determining at least one service traffic link corresponding to a current time; each service traffic link comprises a plurality of service nodes with a calling relationship and real-time output traffic corresponding to the plurality of service nodes; based on the at least one service traffic link, determining at least one target service node corresponding to an upstream calling node; based on the real-time output traffic of the upstream calling node corresponding to the at least one target service node, determining first traffic configuration information corresponding to the at least one target service node. The application can refine the traffic operation granularity and improve the service stability of the micro-service system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a microservice traffic processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Microservices divide a single application into a set of services, each deployed independently, and these services coordinate and cooperate with each other. Each service runs in its own independent process, and services communicate with each other using lightweight communication mechanisms.

[0003] In existing technologies, when the traffic requesting a microservice system is too large, the traffic can be uniformly rate-limited through a gateway, so that the traffic filtered by the gateway can enter the microservice system. However, the traffic granularity of the gateway rate-limiting method is relatively large, which can lead to a mismatch between the gateway's traffic operation and the actual processing traffic of each service in the microservice system. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide a microservice traffic processing method, apparatus, electronic device and storage medium that can realize personalized settings of traffic configuration information for each service node, thereby refining the granularity of traffic operation and improving the service stability of the microservice system.

[0005] To address the aforementioned technical problems, this application provides a microservice traffic processing method, comprising:

[0006] Identify at least one service traffic link corresponding to the current time; each service traffic link includes multiple service nodes with calling relationships, and the real-time output traffic corresponding to each of the multiple service nodes;

[0007] Based on the at least one service traffic link, determine the upstream calling node corresponding to each of the at least one target service node; the at least one target service node is a service node other than the root service node in the at least one service traffic link;

[0008] Based on the real-time output traffic of the upstream calling nodes corresponding to each of the at least one target service node, first traffic configuration information corresponding to each of the at least one target service node is determined; the first traffic configuration information is used to indicate that at the at least one target service node, a first traffic operation is performed on the future traffic from the corresponding upstream calling node; the future traffic is the traffic after the current time.

[0009] On the other hand, embodiments of this application provide a microservice traffic processing apparatus, including:

[0010] The link determination module is used to determine at least one service traffic link corresponding to the current time; each service traffic link includes multiple service nodes with calling relationships, and the real-time output traffic corresponding to each of the multiple service nodes;

[0011] The upstream call node determination module is used to determine the upstream call node corresponding to each of the at least one target service node based on the at least one service traffic link; the at least one target service node is a service node other than the root service node in the at least one service traffic link;

[0012] The first configuration information determination module is used to determine the first traffic configuration information corresponding to each of the at least one target service nodes based on the real-time output traffic of the upstream calling nodes corresponding to each of the at least one target service nodes; the first traffic configuration information is used to instruct that a first traffic operation be performed on the future traffic from the corresponding upstream calling nodes at the at least one target service node; the future traffic is the traffic after the current time.

[0013] On the other hand, this application provides an apparatus including a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the microservice traffic processing method as described above.

[0014] On the other hand, this application provides a computer storage medium storing at least one instruction or at least one program, wherein the at least one instruction or the at least one program is loaded by a processor and executed as described above for the microservice traffic processing method.

[0015] Implementing the embodiments of this application has the following beneficial effects:

[0016] This application can determine the upstream calling node corresponding to each target service node by using at least one service traffic link corresponding to the current time. Based on the real-time output traffic of the upstream calling node corresponding to each target service node, the first traffic configuration information corresponding to the target service node is determined, thereby refining the granularity of traffic operation and realizing personalized settings of traffic configuration information for each target service node, making the traffic configuration information compatible with the target service node. In addition, by setting the corresponding first traffic configuration information at each target service node, it is possible to avoid excessive traffic at the corresponding target service node, which could lead to slow response of the microservice system or even cause a cascading failure, thereby improving the service stability of the microservice system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the implementation environment provided in the embodiments of this application;

[0019] Figure 2 This is a flowchart of a microservice traffic processing method provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the microservice call relationship provided in the embodiments of this application;

[0021] Figure 4 This is a flowchart of the first traffic configuration information generation method provided in the embodiments of this application;

[0022] Figures 5(a)-5(d) This is a schematic diagram of the service traffic link provided in the embodiments of this application;

[0023] Figure 6 This is a flowchart of a rate limiting information configuration method provided in an embodiment of this application;

[0024] Figure 7 This is a flowchart of a method for determining traffic configuration information based on traffic processing priority, provided in an embodiment of this application.

[0025] Figure 8 This is a flowchart of a service node control method provided in an embodiment of this application;

[0026] Figure 9 This is a flowchart of a service traffic link display method provided in an embodiment of this application;

[0027] Figure 10 This is a schematic diagram illustrating the service traffic link provided in the embodiments of this application;

[0028] Figure 11 This is a flowchart of a traffic configuration information configuration method provided in an embodiment of this application;

[0029] Figure 12 This is a diagram of the microservice traffic processing system architecture provided in the embodiments of this application;

[0030] Figure 13 This is a schematic diagram of a microservice traffic processing device provided in an embodiment of this application.

[0031] Figure 14This is a schematic diagram of the electronic device structure provided in the embodiments of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0034] Please see Figure 1 The illustration shows an implementation environment provided in this application embodiment. This implementation environment may include: a traffic management platform 110, a microservice cluster 120, a database 130, and a request client 140. The microservice cluster 120 includes multiple data processing nodes, each of which may deploy one or more service nodes. Corresponding call chains exist between the multiple service nodes. The traffic management platform 110 and the microservice cluster 120 can communicate via a network, and the microservice cluster 120 and the request client 140 can also communicate via a network. The microservice cluster 120 can store the traffic data of each service node in the database 130.

[0035] Specifically, the requesting end 140 can send a service request to the microservice cluster 120 according to service needs. This service request can then flow into the microservice cluster 120 as input traffic. Each service node in the microservice cluster 120 performs corresponding traffic operations on the received traffic according to its own traffic configuration information and returns the corresponding service content information based on the corresponding service request. In addition, each service node in the microservice cluster 120 can perform traffic statistics on the current service node and store the statistical traffic data in the database 130. Furthermore, each service node in the microservice cluster 120 can also report the traffic statistics information of the current service node and the upstream calling node information to the traffic management platform 110. The traffic management platform 110 can construct service traffic links based on the reported information, display the service traffic links, and formulate corresponding traffic configuration information. The traffic configuration information is then distributed to each service node so that each service node can process traffic based on the traffic configuration information.

[0036] The requesting client 140 can communicate with the microservice cluster 120 based on a browser / server (B / S) or client / server (C / S) model. The requesting client 140 may include physical devices such as smartphones, tablets, laptops, digital assistants, smart wearable devices, and in-vehicle terminals, and may also include software running on the physical device, such as applications. The operating system running on the requesting client 140 in this embodiment may include, but is not limited to, Android, iOS, Linux, and Windows.

[0037] Traffic management platforms may include physical devices such as laptops, desktop computers, and servers, but are not limited to these.

[0038] A microservice cluster 120 can be a server cluster or distributed system consisting of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0039] To address the issues of coarse-grained traffic operations on microservices and mismatch between traffic operations and the actual traffic processing capacity of each service in a microservice system in existing technologies, this application provides a microservice traffic processing method. The executing entity can be the aforementioned traffic management platform, as described above. Figure 2 The method may include:

[0040] S210. Determine at least one service traffic link corresponding to the current time; each service traffic link includes multiple service nodes with calling relationships, and the real-time output traffic corresponding to each of the multiple service nodes.

[0041] In this embodiment, at least one service traffic link corresponding to each traffic link construction time can be determined. Each traffic link construction time can correspond to one or more service traffic links, and each service traffic link can include all or some service nodes in the microservice cluster. Each service node can correspond to one microservice.

[0042] As can be seen from the above, each service node in the microservice cluster can also report the current service node's traffic statistics and upstream call node information to the traffic management platform. Thus, the traffic management platform can determine the real-time output traffic of the corresponding service node based on the traffic statistics of each service node, and determine the call relationship between the current service node and the upstream call node based on the upstream call node information. That is, based on the current service node and its corresponding upstream call node, a traffic link segment can be formed. Further, by splicing multiple traffic link segments, the corresponding service traffic link can be obtained.

[0043] Furthermore, link tracking can be implemented at each service node in the microservice cluster, allowing the acquisition of call relationships between service nodes. In one specific embodiment, link tracking can be achieved by setting link tracking filters and traffic execution filters at each service node. The link tracking filter at each service node can save the service identifier information from the service requests received by that service node. During remote service calls, the remote call interceptor injects the saved service identifier information into the service request. This service request, now infused with the service identifier information, is then passed to downstream service nodes, where the service identifier information corresponds to the current service node. The traffic execution filter at the downstream service node can extract the service identifier information of the upstream calling node from the service request, thereby determining the call relationship between the upstream calling node and the current service node. The service identifier information can be the service address information of the service node, such as the service URL (Uniform Resource Locator), or the service node's API information. At each service node, traffic data statistics can be performed on different service identification information. The service identification information is the service URL, and the traffic statistics are QPS (Queries Per Second) and TPS (Transactions Per Second). The data structure is stored as a Map. Taking QPS as an example, the corresponding call statistics item can be Map(service URL, QPS). Through the call statistics item, the upstream calling node of the current service node and the real-time output traffic of the upstream calling node can be determined.

[0044] Having obtained the call statistics for each service node, the upstream calling node that called that service node can be identified, and the corresponding traffic link segment can be determined. Each traffic link segment can include the current service node and its upstream calling node. Then, based on the traffic link segments corresponding to each service node, the corresponding service traffic link can be obtained by concatenating the links. Specifically, during the concatenation process, service nodes without call statistics can be identified as root service nodes. Concatenation can proceed sequentially from downstream service nodes towards the root service node until the root service node is reached, at which point the concatenation of the current service traffic link is considered complete.

[0045] In one example, the call statistics items corresponding to each service node can be traversed, the root service node that does not have call statistics items can be marked, and then the traffic link segments can be pieced together in turn by breadth-first search or depth-first search to obtain the complete service traffic link.

[0046] For example, given that the upstream calling node of service B is service A, the upstream node of service D is also service A, and the upstream nodes of service C include both service B and service D, and since service A has no upstream calling node, service A can be identified as the root service node. We can start concatenating from service C to obtain the traffic link segments service B→service C and service D→service C. Furthermore, we can obtain the traffic link segments service A→service B and service A→service D, resulting in two corresponding service traffic links: service A→service B→service C and service A→service D→service C. For details on the completed service traffic links, please refer to [link to documentation]. Figure 3 It illustrates a diagram of microservice call relationships, from Figure 3 As can be seen from this, service A calls service B, service A calls service D, service B calls service C, and service D calls service C.

[0047] Furthermore, each service traffic link includes multiple service nodes with calling relationships, as well as the real-time output traffic corresponding to each of the multiple service nodes; the real-time output traffic corresponding to each service node can be the output traffic after being processed by that service node, and the real-time output traffic of that service node can be used as the input traffic of the downstream service node of that service node.

[0048] S220. Based on the at least one service traffic link, determine the upstream calling node corresponding to each of the at least one target service node; the at least one target service node is a service node other than the root service node in the at least one service traffic link.

[0049] Once the service traffic path is determined, the upstream calling node corresponding to any target service node can be directly determined based on the service traffic path. As mentioned above, a service node without call statistics can be identified as the root service node. Correspondingly, in the service traffic path, a service node without an upstream calling node can be identified as the root service node. Accordingly, in the service traffic path, all service nodes except the root service node can be identified as target service nodes, and each target service node has a corresponding upstream calling node.

[0050] When there is only one service traffic link, the service traffic link includes one root service node and at least one target service node; when there are multiple service traffic links, the number of root service nodes can be the same as the number of service traffic links, and each service traffic link includes one root service node and at least one target service node.

[0051] Furthermore, in each service traffic link, the root service node is used as the starting traversal node, and the traversal begins along the call direction of the service in the service traffic link. The target service node that is finally traversed is the terminating traversal node. Thus, when there are multiple target service nodes in the service traffic link, except for the terminating traversal node, the other target service nodes can all be used as the upstream call nodes of the corresponding service nodes.

[0052] S230. Based on the real-time output traffic of the upstream calling nodes corresponding to each of the at least one target service node, determine the first traffic configuration information corresponding to each of the at least one target service node; the first traffic configuration information is used to instruct that a first traffic operation be performed on the future traffic from the corresponding upstream calling node at the at least one target service node; the future traffic is the traffic after the current time.

[0053] As described above, the real-time output traffic of each service node can be the output traffic after processing by that service node, and this real-time output traffic can serve as the input traffic for its downstream service nodes. Therefore, each target service node can receive the real-time output traffic of its corresponding upstream calling node. Thus, at each target service node, it is necessary to determine the first traffic configuration information for the upstream calling node based on its real-time output traffic. That is, the first traffic configuration information can be determined based on the real-time output traffic of the upstream calling node; different real-time output traffic of the upstream calling node will result in different first traffic configuration information.

[0054] It should be noted that the first traffic configuration information at each target service node is information that instructs the execution of the first traffic operation on the future traffic of its upstream calling nodes. That is, the processing strategy for future traffic is determined by the real-time traffic at the current moment. The future traffic can specifically be the traffic corresponding to each service node after the current moment.

[0055] Specifically, the first traffic operation in this embodiment may include, but is not limited to, rate limiting the output traffic of the upstream calling node, and processing the output traffic of the upstream calling node based on the priority of the upstream calling node; correspondingly, one or more of the following operations may be performed at each target service node: rate limiting the output traffic of the upstream calling node, and processing the output traffic of the upstream calling node based on the priority of the upstream calling node.

[0056] This application can determine the upstream calling node corresponding to each target service node by using at least one service traffic link corresponding to the current time. Based on the real-time output traffic of the upstream calling node corresponding to each target service node, the first traffic configuration information corresponding to the target service node is determined, thereby refining the granularity of traffic operation and realizing personalized settings of traffic configuration information for each target service node, making the traffic configuration information compatible with the target service node. In addition, by setting the corresponding first traffic configuration information at each target service node, it is possible to avoid excessive traffic at the corresponding target service node, which could lead to slow response of the microservice system or even cause a cascading failure, thereby improving the service stability of the microservice system.

[0057] Please see Figure 4 It illustrates a method for generating first traffic configuration information, which may include:

[0058] S410. Determine a converging service node from the at least one target service node; the converging service node corresponds to multiple upstream calling nodes.

[0059] S420. Based on the real-time output traffic of the multiple upstream calling nodes, generate the first traffic configuration information corresponding to the merging service node.

[0060] When there is only one service traffic link, for any target service node, there may be one or more upstream calling nodes. The target service node that corresponds to multiple upstream calling nodes can be determined as the upstream calling node.

[0061] In one example, see Figure 5(a), the number of service traffic links containing the target service node C is one, and the target service node C corresponds to an upstream calling node B, so the target service node C is not a converging service node.

[0062] In another example, see Figure 5(b), where there is one service traffic link containing the target service node C, and the target service node C corresponds to two upstream calling nodes B and D, thus the target service node C is a converging service node.

[0063] When there are multiple service traffic links, for any target service node, there may be one or more upstream calling nodes. The target service node corresponding to multiple upstream calling nodes can be determined as the upstream calling node.

[0064] Specifically, when any target service node exists in at least two service traffic links, the upstream calling node of the target service node in each service traffic link is determined;

[0065] Based on the upstream calling node of any target service node in each service traffic link, determine the upstream calling node corresponding to any target service node.

[0066] Therefore, for any target service node that exists in at least two service traffic links, it is necessary to determine the corresponding upstream calling node in each service traffic link in which it exists, so as to avoid the omission of upstream calling nodes and improve the accuracy of upstream calling node determination.

[0067] In one example, please refer to Figure 5(c), there are multiple service traffic links containing the target service node C, specifically two. In service traffic link 1, the target service node C corresponds to one upstream calling node B, and in service traffic link 2, the target service node C corresponds to one upstream calling node D. Thus, the target service node C corresponds to two upstream calling nodes B and D, and the target service node C is a converging service node.

[0068] In another example, see Figure 5(d), there are multiple service traffic links involving the target service node C, specifically two. In service traffic link 1, the target service node C corresponds to two upstream calling nodes B and D. In service traffic link 2, the target service node C corresponds to the upstream calling node E. Thus, the target service node C corresponds to three upstream calling nodes B, D, and E.

[0069] Once the convergence service node is determined, first traffic configuration information corresponding to the convergence service node can be generated based on the real-time output traffic of multiple upstream calling nodes of the convergence service node. The first traffic configuration information corresponding to the convergence service node is used to instruct that at the convergence service node, corresponding first traffic operations be performed on future traffic from the multiple upstream calling nodes respectively; the first traffic operation corresponding to each upstream calling node is associated with the real-time output traffic of each upstream calling node.

[0070] At the convergence service node, the first traffic configuration information may include traffic configuration sub-information corresponding to multiple upstream calling nodes respectively. Correspondingly, the first traffic operation may include traffic sub-operations corresponding to multiple upstream calling nodes respectively. The traffic configuration sub-information and the traffic sub-operations have a corresponding relationship. That is, at the convergence service node, each upstream calling node has traffic configuration sub-information corresponding to that upstream calling node, so that the convergence service node can perform corresponding traffic sub-operations on the future traffic of the corresponding upstream calling node based on the traffic configuration information corresponding to each upstream calling node.

[0071] For a target service node with one upstream calling node, it can be determined as a non-converging service node. The first traffic configuration information corresponding to the non-converging service node can be generated directly based on the real-time output traffic of the upstream calling node of the non-converging service node. The first traffic configuration information corresponding to the non-converging service node is used to indicate that at the non-converging service node, the corresponding first traffic operation is performed on the future traffic from its upstream calling node. The first traffic operation is associated with the real-time output traffic of the upstream calling node.

[0072] Therefore, when determining the traffic configuration information of the target service node, it can be based on the node type of the target service node. First, the node type of the target service node corresponding to multiple upstream calling nodes can be determined as the aggregation service node, which can avoid the omission of upstream calling nodes for each target service node. Furthermore, based on the real-time output traffic of multiple upstream calling nodes, the first traffic configuration information corresponding to the aggregation service can be generated, which can be adapted to the actual traffic processing of multiple upstream calling nodes, realize personalized settings of traffic configuration information, and thus realize personalized operations on the future traffic of multiple upstream calling nodes, improving traffic operation efficiency and adaptability.

[0073] For any converging service node, if the first traffic operation information is used to instruct rate limiting operations on future traffic to the upstream calling node, corresponding rate limiting configuration information can be determined for each upstream calling node; please refer to [link to details]. Figure 6 It illustrates a method for configuring rate limiting information, which may include:

[0074] S610. Based on the real-time output traffic corresponding to each of the multiple upstream calling nodes, determine the rate limiting threshold of the merging service node for the multiple upstream calling nodes respectively;

[0075] S620. Based on the rate limiting threshold of the convergence service node for the multiple upstream calling nodes, generate the first traffic configuration information corresponding to the convergence service node.

[0076] The first traffic configuration information here may specifically include rate limiting configuration information. The rate limiting configuration information for each upstream calling node can be configured based on its respective real-time output traffic. Specifically, the rate limiting configuration information can be a rate limiting threshold, and the rate limiting threshold for each upstream calling node is related to its real-time output traffic. For example, the upstream calling node with a larger real-time output traffic has a larger rate limiting threshold at the merging service node; the upstream calling node with a smaller real-time output traffic has a smaller rate limiting threshold at the merging service node. The rate limiting threshold can specifically represent the maximum amount of traffic that the merging service node can receive from each upstream calling node. Traffic exceeding this rate limiting threshold will be discarded. Therefore, the first traffic configuration information corresponding to the merging service node is used to instruct that, at the merging service node, rate limiting operations are performed on future traffic from the upstream calling nodes from the merging service node based on the rate limiting thresholds of the multiple upstream calling nodes.

[0077] Specifically, for any aggregation service node, the traffic ratio information can be determined based on the real-time output traffic of each of the multiple upstream calling nodes; then, based on the actual traffic processing capacity (i.e., load traffic) of the aggregation service node and the traffic ratio information, a ratio calculation is performed to obtain the rate limiting threshold corresponding to each of the multiple upstream calling nodes; that is, the sum of the rate limiting thresholds of the multiple upstream calling nodes is less than or equal to the load traffic of the aggregation service node, thereby avoiding excessive processing pressure on the aggregation service node and improving service stability.

[0078] Therefore, for any converged service node, the corresponding rate limiting threshold can be determined based on the real-time output traffic of its multiple upstream calling nodes, thereby enabling personalized rate limiting for each upstream calling node. Furthermore, by processing the traffic of the corresponding upstream calling nodes through the rate limiting threshold, the simplicity and ease of operation of rate limiting can be improved.

[0079] For any non-converging service node, there is a corresponding upstream calling node. Based on the real-time output traffic of the upstream calling node, a rate limiting threshold for the upstream calling node can be configured at the non-converging service node. This rate limiting threshold is less than or equal to the load traffic of the non-converging service node, and then the corresponding first traffic configuration information can be generated based on the rate limiting threshold.

[0080] Furthermore, each service traffic link includes not only multiple service nodes with calling relationships and their respective real-time output traffic, but also their respective real-time input traffic. For any given service node, its real-time input and output traffic may be the same or different. If the real-time input and output traffic are the same, it indicates that the real-time input traffic meets the load capacity of the service node, and the service node has not performed rate limiting on the real-time input traffic. If the real-time input and output traffic are different, it indicates that the real-time input traffic does not meet the load capacity of the service node; specifically, the real-time input traffic may be greater than the real-time output traffic, meaning that the service node has performed rate limiting on the real-time input traffic. Therefore, the traffic processing information of any service node can be determined based on its real-time input and output traffic.

[0081] Accordingly, please refer to Figure 7 It illustrates a method for determining traffic configuration information based on traffic processing priority, which may include:

[0082] S710. Based on the real-time input traffic of the multiple upstream calling nodes and the real-time output traffic of the multiple upstream calling nodes, determine the rate limiting information corresponding to each of the multiple upstream calling nodes.

[0083] S720. Based on the rate limiting information corresponding to each of the multiple upstream calling nodes, determine the traffic processing priority of the merging service node for the multiple upstream calling nodes.

[0084] S730. Based on the traffic processing priority of the converged service node for the plurality of upstream calling nodes, generate first traffic configuration information corresponding to the converged service node; the first traffic configuration information is used to indicate that, at the converged service node, future traffic from the upstream calling nodes from the converged service node is processed based on the traffic processing priority of the converged service node for the plurality of upstream calling nodes.

[0085] The rate limiting information of the upstream calling node can be determined by the ratio of the real-time output traffic to the real-time input traffic of the upstream calling node. The larger the ratio, the larger the proportion of traffic passing through, and the smaller the corresponding rate limiting information; the smaller the ratio, the smaller the proportion of traffic passing through, and the larger the corresponding rate limiting information.

[0086] The specific rate limiting information of the upstream calling node can also be determined by the difference between the real-time inbound and outbound traffic and the real-time outbound traffic. The smaller the difference, the smaller the corresponding rate limiting information; the larger the difference, the larger the corresponding rate limiting information.

[0087] After determining the rate limiting information, the traffic processing priority of each upstream calling node can be determined. The upstream calling node with a smaller rate limiting information has a higher traffic processing priority, and the upstream calling node with a larger rate limiting information has a lower traffic processing priority. Thus, the traffic processing priority of each upstream calling node can be determined, and the first traffic configuration information corresponding to the merging service node can be generated.

[0088] Specifically, based on the traffic processing priorities of the merging service node for multiple upstream calling nodes, the processing of future traffic from upstream calling nodes originating from the merging service node may include:

[0089] Based on traffic processing priority, the order of traffic processing for multiple upstream calling nodes is determined, and the traffic of multiple upstream calling nodes is processed sequentially according to the traffic processing order; future traffic of upstream calling nodes with higher traffic processing priority is processed first.

[0090] Furthermore, traffic processing priority can be assigned to... Figure 6 The flow control for future traffic to multiple upstream calling nodes is determined by combining the flow control thresholds of multiple upstream calling nodes. Specifically, the flow control order is first determined based on flow processing priority, and then the flow to each upstream calling node is processed sequentially according to this order. Future traffic from upstream calling nodes with higher flow control priority is processed first, and the processed traffic meets the corresponding flow control threshold for each upstream calling node.

[0091] For example, a convergence service node C corresponds to two upstream calling nodes B and D. The traffic processing priority of upstream calling node B is higher than that of upstream calling node D. The rate limiting threshold for upstream calling node B is m, and the rate limiting threshold for upstream calling node D is n. Therefore, when the convergence service node C receives future traffic from upstream calling nodes B and D, it first processes the future traffic from upstream calling node B, with a traffic processing limit of m; then it processes the future traffic from upstream calling node D, with a traffic processing limit of n.

[0092] By using the rate limiting information of each upstream calling node, the traffic processing priority of multiple upstream calling nodes at the merging service node is determined. This allows the output traffic of upstream calling nodes with lower rate limiting to have higher traffic processing priority, enabling this traffic to pass through as quickly as possible and improving traffic processing efficiency. Furthermore, by processing the output traffic of multiple upstream calling nodes sequentially based on traffic processing priority, orderly traffic processing can be achieved, avoiding the problem of excessive pressure on the merging service node caused by excessive traffic at the same time, and improving service stability.

[0093] The root service node serves as the entry point for traffic reception in the microservice system. The specific traffic received can be determined based on the real-time load of the microservice system. Specifically, the second traffic configuration information corresponding to the root service node can be determined based on the real-time input traffic and the real-time output traffic of each service node in the at least one service traffic link. The second traffic configuration information is used to instruct the execution of a second traffic operation on future traffic entering the root service node. The second traffic operation is associated with the real-time output traffic of each service node and the future traffic entering the root service node.

[0094] Each service traffic link includes real-time input traffic and real-time output traffic corresponding to multiple service nodes. Each service node also has corresponding load traffic. Therefore, based on the real-time input and output traffic of each service node, the real-time load of each service node can be determined, including the real-time load of the root service node and the real-time load of non-root service nodes, thereby determining the real-time load of the microservice system. After determining the real-time load of the microservice system, traffic configuration information can be determined for the root service node, which serves as the entry point for traffic reception. The root service node can perform second traffic operations on future traffic entering the microservice system according to the corresponding second traffic configuration information. The second traffic operations can also include rate limiting operations and traffic processing operations based on traffic processing priorities. Further, the second traffic configuration information can include rate limiting information and priority information. For at least one traffic source, a corresponding traffic threshold can be set, so that the root service node can perform rate limiting processing on the received traffic according to the traffic threshold; for multiple traffic sources, corresponding traffic processing priorities can be set, so that the root service node can process the received traffic according to the traffic processing priorities. The traffic processing priority for the root service node can be determined based on the traffic source identifier. That is, different traffic processing priorities can be predetermined for different traffic source identifiers.

[0095] Based on the real-time load of the microservice system, the traffic configuration information at the root service node is determined so that the root service node can perform corresponding traffic operations on the future traffic sources. This ensures that the traffic entering the microservice system is matched with the load of the microservice system, thereby avoiding the problem of excessive pressure on the microservice system caused by excessive instantaneous traffic and improving the stability of the microservice system.

[0096] The traffic management platform can also check the operational status of each service node; please refer to [link / reference needed]. Figure 8 It illustrates a service node control method, which may include:

[0097] S810. Obtain the performance index data of each service node in the at least one service traffic link.

[0098] S820. If there is an abnormal service node among the service nodes, control the abnormal service node to shut down its service; the performance index data of the abnormal service node meets the preset abnormal conditions.

[0099] The performance metrics here can include one or more of the following: response time, throughput, etc. Based on the acquired performance metric data of each service node, the real-time status of each service node can be determined, and thus, abnormal service nodes can be identified. Preset abnormal conditions can be, for example, actual response time greater than or equal to a preset response time, or actual throughput less than or equal to a preset throughput.

[0100] For the same service node that exists in multiple service traffic links, the real-time status of the service node can be determined comprehensively based on the performance index data of the service node in multiple service traffic links.

[0101] Once an abnormal service node is identified, its service can be shut down, causing access requests to the abnormal service node to fail quickly and return degraded service resources, thus preventing it from affecting downstream service nodes and improving service stability.

[0102] If an abnormal service node is identified, when a preset time window is reached, its real-time status can be reassessed based on the performance metrics data of the abnormal service node within the current time window. When the real-time status returns to normal, it can be determined that the abnormal service node has recovered and its service can be resumed.

[0103] Once the service traffic path at the current moment is determined, it can also be visualized, facilitating the observation of each service node and its corresponding traffic processing. Please refer to the relevant documentation for further information. Figure 9 It illustrates a method for displaying service traffic links, which may include:

[0104] S910. Display service traffic link interface; the traffic link interface includes a node link display area.

[0105] S920. In response to the service traffic link display instruction, display multiple service nodes and the chained call relationship between the multiple service nodes in the node link display area.

[0106] S930. Display the real-time input traffic and real-time output traffic of the multiple service nodes in the traffic display area corresponding to each of the multiple service nodes; the traffic display area corresponding to each service node is the adjacent area of ​​the display area where each service node is located.

[0107] Before receiving a service traffic link display instruction, the service traffic link interface can be displayed. The node link display area in the service traffic link interface can be used to display multiple service nodes and the chained call relationships between them. Furthermore, upon receiving a service traffic link display instruction, multiple service nodes and the chained call relationships between them can be displayed in the node link display area. For each service node, a corresponding traffic display area can be provided. The traffic display area can be used to display the real-time input and output traffic of the corresponding service node, and can be an area adjacent to the display area for each service node.

[0108] By visualizing the service traffic flow, the calling relationships between service nodes and the real-time input and output traffic of each service node can be intuitively determined through the visual interface, thereby improving the intuitiveness and convenience of observing the status of each service node in the microservice system.

[0109] Please see Figure 10 It displays a schematic diagram of the service traffic chain, including a service traffic chain interface. This interface includes a node chain display area, which shows multiple service nodes and the chained call relationships between them. Each service node has a corresponding traffic display area, used to show the real-time input and output traffic of that service node.

[0110] With the service traffic chain displayed, the traffic configuration information for each service node can be determined based on the real-time output traffic of its upstream calling nodes. Specifically, when configuring traffic configuration information, triggers can be initiated based on the service nodes displayed on the service traffic chain interface. Please refer to [link to relevant documentation]. Figure 11 It illustrates a method for configuring traffic configuration information, which may include:

[0111] S1110. In response to a traffic configuration instruction triggered by at least one service node in the node link display area, display the traffic configuration interface.

[0112] S1120. In response to the target parameter input operation based on the traffic configuration interface, generate first traffic configuration information corresponding to the at least one service node; the target parameter is determined based on the real-time output traffic displayed in the target traffic display area, and the target traffic display area is the traffic display area of ​​the upstream calling node of the at least one service node.

[0113] For example, if it is necessary to configure traffic configuration information for service node C, the service node C displayed in the service traffic link interface can be triggered, and the traffic configuration interface will be displayed accordingly. The traffic configuration interface may include at least one information configuration item, and can respond to the target parameter input operation based on the information configuration item, thereby generating the first traffic configuration information corresponding to service node C.

[0114] Therefore, when the call relationship between each service node in the microservice system and the real-time input and output traffic of each service node are observed through the service traffic link interface, if it is necessary to configure the traffic configuration information of the relevant service node, it can be triggered directly based on the service node displayed in the service traffic link interface. Then, the relevant parameters are input through the traffic configuration interface displayed by the trigger to generate the corresponding traffic configuration information, which improves the convenience and efficiency of traffic configuration information configuration.

[0115] It should be noted that the methods described above in this embodiment can be combined based on actual implementation conditions and have corresponding beneficial effects, which will not be elaborated here.

[0116] The following is a specific example illustrating the implementation process of this application. Please refer to [link / reference]. Figure 12 The diagram illustrates the architecture of a microservice traffic processing system, which includes a traffic management platform, a microservice cluster, and a database. The microservice cluster includes data processing node 1, data processing node 2, and data processing node 3. Taking the deployment of one service node on each data processing node as an example, the microservice cluster may include service node A, service node B, and service node C. Each service node is equipped with a traffic proxy module.

[0117] Microservice clusters: These deploy services for business applications and can contain tens of thousands of microservices in large-scale websites. Complex call chains exist between these services. Each sub-service can scale its instance count based on system load. For example, during peak traffic periods, the number of instances of service node B can be increased to 20, while during off-peak periods it can be reduced to 10. Upstream and downstream service nodes A and C can adaptively adjust their rate-limiting thresholds based on the number of instances of B. If current traffic statistics remain consistently low, and system load also remains low, the current service can be scaled down. The scaling down of dependent downstream service resources can be assessed based on the service traffic chain. This scaling down can be done manually by operations personnel based on end-to-end traffic observation data, or it can be done using automated operations scripts based on current end-to-end traffic observation data.

[0118] Traffic Proxy Module: Deployed alongside business services. The main functions of the traffic proxy module include traffic statistics, link tracking, link pass-through, rate limiting policy execution, and traffic processing based on priority. Traffic statistics monitor the traffic and thread count of interfaces within the service and store the statistical data per second. Link tracking and link pass-through are used to detect link call relationships, uploading the tracking and pass-through data to the traffic management platform. This allows the platform to piece together the link to obtain the complete service traffic link for processing the entire link's traffic. Rate limiting policy execution includes request approval or rejection, execution of circuit breaker and degradation policies, and rate limiting policies based on service traffic links.

[0119] In addition, the execution of rate limiting logic includes a series of sequentially executed processing chains, including:

[0120] Rate limiting policy matching: Matching / hitting the rate limiting policies issued by the traffic control platform;

[0121] Flow control: Implements direct flow limiting, cold start, queuing, and other processing methods;

[0122] Circuit breaking and degradation: When a service becomes unstable, response time increases, or the anomaly rate increases, requests to this service resource fail quickly and a degraded resource is returned to prevent its impact from spreading to other downstream resources. After a specified time window has passed, it can be restored based on the current anomaly indicators.

[0123] System load protection: When the system load is high, if requests continue to come in, it may cause the system to crash and become unresponsive. System load protection balances the ingress traffic of the microservice system with the system load, ensuring that the microservice system can handle the maximum number of requests within its capacity.

[0124] Traffic management platform: Receives link data reports from the traffic proxy module, splices service traffic links according to the link context and displays them, configures traffic configuration information based on the service traffic links and sends it to the traffic proxy module, and can also have traffic observation and alarm functions.

[0125] Database: Provides persistent storage for traffic data collected by the traffic proxy module. Specific storage formats may include MySQL, InfluxDB, etc.

[0126] Specifically, the traffic configuration information for each service node can be further configured by combining the node identifier of the upstream calling node. The node identifier can be the node access address identifier, node name information, etc., so that different traffic configuration information can be configured for different node identifiers.

[0127] This embodiment also provides a microservice traffic processing device, which can be implemented in hardware and / or software. Please refer to [link / reference]. Figure 13 The device may include:

[0128] The link determination module 1310 is used to determine at least one service traffic link corresponding to the current time; each service traffic link includes multiple service nodes with calling relationships, and the real-time output traffic corresponding to each of the multiple service nodes;

[0129] The upstream call node determination module 1320 is used to determine the upstream call node corresponding to each of the at least one target service node based on the at least one service traffic link; the at least one target service node is a service node other than the root service node in the at least one service traffic link;

[0130] The first configuration information determination module 1330 is used to determine the first traffic configuration information corresponding to each of the at least one target service nodes based on the real-time output traffic of the upstream calling nodes corresponding to each of the at least one target service nodes; the first traffic configuration information is used to instruct that a first traffic operation be performed on the future traffic from the corresponding upstream calling nodes at the at least one target service node; the future traffic is the traffic after the current time.

[0131] Furthermore, the first configuration information determining module includes:

[0132] A convergence service node determination module is used to determine a convergence service node from the at least one target service node; the convergence service node corresponds to multiple upstream calling nodes;

[0133] The first generation module is used to generate first traffic configuration information corresponding to the merging service node based on the real-time output traffic of the multiple upstream calling nodes; the first traffic configuration information corresponding to the merging service node is used to indicate that at the merging service node, a corresponding first traffic operation is performed on the future traffic from the multiple upstream calling nodes respectively; the first traffic operation corresponding to each upstream calling node is associated with the real-time output traffic of each upstream calling node.

[0134] Furthermore, the first generation module includes:

[0135] The rate limiting threshold determination module is used to determine the rate limiting threshold of the merging service node for the multiple upstream calling nodes based on the real-time output traffic corresponding to each of the multiple upstream calling nodes.

[0136] The second generation module is used to generate first traffic configuration information corresponding to the converged service node based on the rate limiting threshold of the converged service node for the plurality of upstream calling nodes; the first traffic configuration information corresponding to the converged service node is used to indicate that at the converged service node, based on the rate limiting threshold of the plurality of upstream calling nodes, a rate limiting operation is performed on the future traffic from the upstream calling nodes of the converged service node.

[0137] Furthermore, each service traffic link includes the real-time input traffic corresponding to each of the multiple service nodes;

[0138] The first generation module includes:

[0139] The rate limiting degree determination module is used to determine the rate limiting degree information corresponding to each of the multiple upstream calling nodes based on the real-time input traffic and the real-time output traffic of the multiple upstream calling nodes.

[0140] The priority determination module is used to determine the traffic processing priority of the merging service node for the multiple upstream calling nodes based on the rate limiting information corresponding to each of the multiple upstream calling nodes.

[0141] The third generation module is used to generate first traffic configuration information corresponding to the convergence service node based on the traffic processing priority of the convergence service node for the plurality of upstream calling nodes; the first traffic configuration information is used to indicate at the convergence service node that future traffic from the upstream calling nodes from the convergence service node should be processed based on the traffic processing priority of the convergence service node for the plurality of upstream calling nodes.

[0142] Furthermore, each service traffic link includes the real-time input traffic corresponding to each of the plurality of service nodes; the device further includes:

[0143] The second traffic configuration information determination module is used to determine the second traffic configuration information corresponding to the root service node based on the real-time input traffic corresponding to each service node in the at least one service traffic link and the real-time output traffic corresponding to each service node; the second traffic configuration information is used to instruct that a second traffic operation be performed on the future traffic entering the root service node at the root service node; the second traffic operation is associated with the real-time output traffic corresponding to each service node and the future traffic entering the root service node.

[0144] Furthermore, the device also includes:

[0145] The data acquisition module is used to acquire performance index data of each service node in the at least one service traffic link;

[0146] The service shutdown module is used to control the abnormal service node to shut down its service when there is an abnormal service node among the service nodes; the performance index data of the abnormal service node meets the preset abnormal conditions.

[0147] Furthermore, the at least one service traffic link includes multiple service traffic links;

[0148] The upstream calling node determination module includes:

[0149] The first determining module is used to determine the upstream calling node of any target service node in each service traffic link when any target service node exists in at least two service traffic links;

[0150] The second determining module is used to determine the upstream calling node corresponding to any target service node based on the upstream calling node of any target service node in each service traffic link.

[0151] Furthermore, each service traffic link includes the real-time input traffic corresponding to each of the multiple service nodes;

[0152] The device further includes:

[0153] The first display module is used to display the service traffic link interface; the traffic link interface includes a node link display area.

[0154] The second display module is used to respond to the service traffic link display instruction and display multiple service nodes and the chained call relationship between the multiple service nodes in the node link display area;

[0155] The third display module is used to display the real-time input traffic and real-time output traffic of the multiple service nodes in the traffic display area corresponding to each of the multiple service nodes; the traffic display area corresponding to each service node is the adjacent area of ​​the display area where each service node is located.

[0156] Furthermore, the device also includes:

[0157] The fourth display module is used to display the traffic configuration interface in response to a traffic configuration command triggered by at least one service node in the node link display area.

[0158] The configuration module is used to generate first traffic configuration information corresponding to the at least one service node in response to the target parameter input operation based on the traffic configuration interface; the target parameter is determined based on the real-time output traffic displayed in the target traffic display area, and the target traffic display area is the traffic display area of ​​the upstream calling node of the at least one service node.

[0159] The apparatus provided in the above embodiments can execute the methods provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in the above embodiments can be found in the methods provided in any embodiment of this application.

[0160] This embodiment also provides a computer-readable storage medium storing at least one instruction or at least one program, which is loaded by a processor and executed as any of the methods described above in this embodiment.

[0161] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the methods described in this embodiment.

[0162] This embodiment also provides an electronic device, the structural diagram of which can be found in [reference needed]. Figure 14 The device 1400 can vary significantly in configuration or performance, and may include one or more central processing units (CPUs) 1422 (e.g., one or more processors) and memory 1432, and one or more storage media 1430 (e.g., one or more mass storage devices) for storing applications 1442 or data 1444. The memory 1432 and storage media 1430 may be temporary or persistent storage. Programs stored in the storage media 1430 may include one or more modules (not shown), each module including a series of instruction operations on the device. Furthermore, the CPU 1422 may be configured to communicate with the storage media 1430 and execute the series of instruction operations in the storage media 1430 on the device 1400. The device 1400 may also include one or more power supplies 1426, one or more wired or wireless network interfaces 1450, one or more input / output interfaces 1458, and / or one or more operating systems 1441, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM Etc. Any of the methods described above in this embodiment can be based on... Figure 14 The equipment shown is used for implementation.

[0163] This specification provides the operational steps of the methods described in the embodiments or flowcharts, but more or fewer operational steps may be included based on conventional or non-inventive labor. The steps and order listed in the embodiments are merely one possible execution order among many steps and do not represent the only execution order. In actual system or interrupt product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0164] The structure shown in this embodiment is only a partial structure related to the solution of this application and does not constitute a limitation on the device to which the solution of this application is applied. Specific devices may include more or fewer components than shown, or combinations of certain components, or arrangements of different components. It should be understood that the methods, apparatuses, etc., disclosed in this embodiment can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or unit modules through some interfaces.

[0165] Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0166] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0167] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A microservice traffic processing method, characterized in that, include: Identify at least one service traffic link corresponding to the current moment; Each service traffic link includes multiple service nodes with calling relationships, the real-time output traffic corresponding to each of the multiple service nodes, and the real-time input traffic corresponding to each of the multiple service nodes; Based on the at least one service traffic link, determine the upstream calling node corresponding to each of the at least one target service node; The at least one target service node is a service node other than the root service node in the at least one service traffic link; Determine the converging service node from the at least one target service node; The convergence service node corresponds to multiple upstream calling nodes; Based on the real-time output traffic of the multiple upstream calling nodes, the first traffic configuration information corresponding to the merging service node is generated; The process of generating first traffic configuration information corresponding to the merging service node based on the real-time output traffic of the multiple upstream calling nodes includes: Based on the real-time input traffic and real-time output traffic of the multiple upstream calling nodes, the rate limiting information corresponding to each of the multiple upstream calling nodes is determined; based on the rate limiting information corresponding to each of the multiple upstream calling nodes, the traffic processing priority of the merging service node for the multiple upstream calling nodes is determined; based on the traffic processing priority of the merging service node for the multiple upstream calling nodes, the first traffic configuration information corresponding to the merging service node is generated. The first traffic configuration information corresponding to the convergence service node is used to indicate that, at the convergence service node, based on the traffic processing priority of the convergence service node for the multiple upstream calling nodes, the future traffic flowing to the upstream calling nodes of the convergence service node is processed; the future traffic is the traffic after the current time.

2. The method according to claim 1, characterized in that, The process of generating first traffic configuration information corresponding to the merging service node based on the real-time output traffic of the multiple upstream calling nodes includes: Based on the real-time output traffic of each of the multiple upstream calling nodes, the rate limiting threshold of the merging service node for the multiple upstream calling nodes is determined respectively. Based on the rate limiting threshold of the multiple upstream calling nodes by the converged service node, first traffic configuration information corresponding to the converged service node is generated; the first traffic configuration information corresponding to the converged service node is used to indicate that, at the converged service node, rate limiting operation is performed on future traffic flowing to the upstream calling nodes of the converged service node based on the rate limiting threshold of the multiple upstream calling nodes.

3. The method according to claim 1, characterized in that, The method further includes: Based on the real-time input traffic and the real-time output traffic of each service node in the at least one service traffic link, the second traffic configuration information corresponding to the root service node is determined; the second traffic configuration information is used to instruct the execution of a second traffic operation on the future traffic entering the root service node at the root service node; the second traffic operation is associated with the real-time output traffic of each service node and the future traffic entering the root service node.

4. The method according to claim 1, characterized in that, The method further includes: Obtain performance index data of each service node in the at least one service traffic link; If an abnormal service node exists among the service nodes, the abnormal service node is controlled to shut down; the performance index data of the abnormal service node meets the preset abnormal conditions.

5. The method according to claim 1, characterized in that, The at least one service traffic link includes multiple service traffic links; The step of determining the upstream calling node corresponding to at least one target service node based on the at least one service traffic link includes: If any target service node exists in at least two service traffic links, determine the upstream calling node of the target service node in each service traffic link; Based on the upstream calling node of any target service node in each service traffic link, determine the upstream calling node corresponding to any target service node.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The interface displays the service traffic flow; the traffic flow interface includes a node flow display area. In response to the service traffic link display instruction, multiple service nodes and the chained call relationship between the multiple service nodes are displayed in the node link display area; The traffic display area corresponding to each of the multiple service nodes displays the real-time input traffic and real-time output traffic of the multiple service nodes; the traffic display area corresponding to each service node is the adjacent area of ​​the display area where each service node is located.

7. The method according to claim 6, characterized in that, The method further includes: In response to a traffic configuration command triggered by at least one service node in the node link display area, a traffic configuration interface is displayed; In response to the input operation of the target parameter based on the traffic configuration interface, first traffic configuration information corresponding to the at least one service node is generated; the target parameter is determined based on the real-time output traffic displayed in the target traffic display area, and the target traffic display area is the traffic display area of ​​the upstream calling node of the at least one service node.

8. A microservice traffic processing device, characterized in that, include: The link determination module is used to determine at least one service traffic link corresponding to the current time. Each service traffic link includes multiple service nodes with calling relationships, the real-time output traffic corresponding to each of the multiple service nodes, and the real-time input traffic corresponding to each of the multiple service nodes; The upstream call node determination module is used to determine the upstream call node corresponding to each of the at least one target service node based on the at least one service traffic link. The at least one target service node is a service node other than the root service node in the at least one service traffic link; A convergence service node determination module is used to determine a convergence service node from the at least one target service node; The convergence service node corresponds to multiple upstream calling nodes; The first generation module is used to generate the first traffic configuration information corresponding to the convergence service node based on the real-time output traffic of the multiple upstream calling nodes. The first generation module includes: A rate limiting degree determination module is used to determine the rate limiting degree information corresponding to each of the multiple upstream calling nodes based on the real-time input traffic and the real-time output traffic of the multiple upstream calling nodes; a priority determination module is used to determine the traffic processing priority of the merging service node for the multiple upstream calling nodes based on the rate limiting degree information corresponding to each of the multiple upstream calling nodes; a third generation module is used to generate the first traffic configuration information corresponding to the merging service node based on the traffic processing priority of the merging service node for the multiple upstream calling nodes. The first traffic configuration information corresponding to the convergence service node is used to indicate that, at the convergence service node, based on the traffic processing priority of the convergence service node for the multiple upstream calling nodes, the future traffic flowing to the upstream calling nodes of the convergence service node is processed; the future traffic is the traffic after the current time.

9. The apparatus according to claim 8, characterized in that, The first generation module includes: The rate limiting threshold determination module is used to determine the rate limiting threshold of the merging service node for the multiple upstream calling nodes based on the real-time output traffic corresponding to each of the multiple upstream calling nodes. The second generation module is used to generate first traffic configuration information corresponding to the converged service node based on the rate limiting threshold of the converged service node for the plurality of upstream calling nodes; the first traffic configuration information corresponding to the converged service node is used to indicate that at the converged service node, based on the rate limiting threshold of the plurality of upstream calling nodes, a rate limiting operation is performed on the future traffic flowing to the upstream calling nodes of the converged service node.

10. The apparatus according to claim 8, characterized in that, The device further includes: The second traffic configuration information determination module is used to determine the second traffic configuration information corresponding to the root service node based on the real-time input traffic corresponding to each service node in the at least one service traffic link and the real-time output traffic corresponding to each service node; the second traffic configuration information is used to instruct that a second traffic operation be performed on the future traffic entering the root service node at the root service node; the second traffic operation is associated with the real-time output traffic corresponding to each service node and the future traffic entering the root service node.

11. The apparatus according to claim 8, characterized in that, The device further includes: The data acquisition module is used to acquire performance index data of each service node in the at least one service traffic link; The service shutdown module is used to control the abnormal service node to shut down its service when there is an abnormal service node among the service nodes; the performance index data of the abnormal service node meets the preset abnormal conditions.

12. The apparatus according to claim 8, characterized in that, The upstream calling node determination module includes: The first determining module is used to determine the upstream calling node of any target service node in each service traffic link when any target service node exists in at least two service traffic links; The second determining module is used to determine the upstream calling node corresponding to any target service node based on the upstream calling node of any target service node in each service traffic link.

13. The apparatus according to any one of claims 8-12, characterized in that, The device further includes: The first display module is used to display the service traffic link interface; the traffic link interface includes a node link display area. The second display module is used to respond to the service traffic link display instruction and display multiple service nodes and the chained call relationship between the multiple service nodes in the node link display area; The third display module is used to display the real-time input traffic and real-time output traffic of the multiple service nodes in the traffic display area corresponding to each of the multiple service nodes; the traffic display area corresponding to each service node is the adjacent area of ​​the display area where each service node is located.

14. The apparatus according to claim 13, characterized in that, The device further includes: The fourth display module is used to display the traffic configuration interface in response to a traffic configuration command triggered by at least one service node in the node link display area. The configuration module is used to generate first traffic configuration information corresponding to the at least one service node in response to the target parameter input operation based on the traffic configuration interface; the target parameter is determined based on the real-time output traffic displayed in the target traffic display area, and the target traffic display area is the traffic display area of ​​the upstream calling node of the at least one service node.

15. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the microservice traffic processing method as described in any one of claims 1 to 7.

16. A computer storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor according to any one of claims 1 to 7.

17. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the microservice traffic processing method as described in any one of claims 1 to 7.

Images