Task processing method and device for optimal scheduling of master station micro-service resources based on dynamic tidal load balancing technology, and computer equipment

Abstract

The invention relates to a task processing method and device for optimal scheduling of master station micro-service resources based on a dynamic tide load balancing technology, computer equipment, a storage medium and a computer program product. The method comprises the steps of obtaining a load prediction result corresponding to a to-be-analyzed micro-service node according to current load data of the to-be-analyzed micro-service node, current task type information of a to-be-processed task and current access node information corresponding to a terminal; determining candidate micro-service nodes from the to-be-analyzed micro-service nodes according to the load prediction result and the current task type information; determining the node health degree of the candidate micro-service node according to the load rate, the network delay information and the task type weight of the candidate micro-service node; and according to the node health degree and the task processing request, determining a target micro-service node corresponding to the to-be-processed task from the candidate micro-service nodes, and sending the to-be-processed task to the target micro-service node for processing. By adopting the method, the resource utilization rate can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a task processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on dynamic tidal load balancing technology for optimizing and scheduling the resources of a master station microservice. Background Technology

[0002] Currently, with the increasing number of computer tasks, efficient task processing has become crucial.

[0003] In traditional technologies, static weight allocation or fixed polling strategies are generally used when processing tasks. However, this approach is difficult to cope with the uneven resource utilization caused by the tidal effect of user access volume (such as peak meter reading times or sudden traffic surges) in metering automation master station applications, resulting in low resource utilization. Summary of the Invention

[0004] Based on this, it is necessary to provide a task processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve resource utilization by optimizing the scheduling of main station microservice resources based on dynamic tidal load balancing technology.

[0005] Firstly, this application provides a task processing method for optimizing and scheduling master station microservice resources based on dynamic tidal load balancing technology, including:

[0006] In response to a task processing request sent by the terminal for a task to be processed, the current load data of the microservice node to be analyzed corresponding to the task to be processed is obtained;

[0007] Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed;

[0008] Based on the load prediction results and the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes to be analyzed.

[0009] The node health of the candidate microservice nodes is determined based on their load rate, network latency information, and task type weight.

[0010] Based on the node health status and the task processing request, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes, and the task to be processed is sent to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

[0011] In one embodiment, determining the candidate microservice node corresponding to the task to be processed from the microservice nodes to be analyzed, based on the load prediction result and the current task type information, includes:

[0012] Obtain the preset partitioning ratio corresponding to the microservice node to be analyzed;

[0013] Based on the load prediction results, the preset partition ratio is updated to obtain the updated partition ratio corresponding to the microservice node to be analyzed.

[0014] According to the updated partitioning ratio, the microservice nodes to be analyzed are partitioned to obtain microservice nodes under different resource pool types.

[0015] Based on the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes under the different resource pool types.

[0016] In one embodiment, determining the candidate microservice node corresponding to the task to be processed from the microservice nodes under different resource pool types based on the current task type information includes:

[0017] Based on the current task type information, query the correspondence between the task type information and the resource pool type to obtain the current resource pool type corresponding to the task to be processed;

[0018] From the microservice nodes under the different resource pool types, the microservice node corresponding to the current resource pool type is determined as the candidate microservice node for the task to be processed.

[0019] In one embodiment, determining the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the node health status and the task processing request includes:

[0020] Based on the node health status, the scheduling weight corresponding to the candidate microservice node is determined;

[0021] Based on the scheduling weight, the virtual node corresponding to the candidate microservice node is determined;

[0022] Based on the task processing request and the virtual node, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes.

[0023] In one embodiment, determining the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the task processing request and the virtual node includes:

[0024] Obtain the first hash value corresponding to the task processing request and the second hash value corresponding to the virtual node;

[0025] Based on the first hash value and the second hash value, the target virtual node corresponding to the task to be processed is determined from the virtual nodes;

[0026] The microservice node corresponding to the target virtual node is determined from the candidate microservice nodes and used as the target microservice node for the task to be processed.

[0027] In one embodiment, determining the node health of the candidate microservice node based on its load rate, network latency information, and task type weight includes:

[0028] The health status of the first node of the candidate microservice nodes is determined based on the load rate of the candidate microservice nodes.

[0029] The health status of the second node of the candidate microservice node is determined based on the network latency information of the candidate microservice node.

[0030] The health of the third node of the candidate microservice node is determined based on the task type weight of the candidate microservice node.

[0031] The health scores of the first node, the second node, and the third node are fused to obtain the node health score of the candidate microservice node.

[0032] Secondly, this application also provides a task processing device for optimizing and scheduling the resources of a master station microservice based on dynamic tidal load balancing technology, comprising:

[0033] The data acquisition module is used to respond to the task processing request sent by the terminal for the task to be processed and to acquire the current load data of the microservice node to be analyzed corresponding to the task to be processed.

[0034] The load prediction module is used to obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed.

[0035] The node determination module is used to determine the candidate microservice node corresponding to the task to be processed from the microservice nodes to be analyzed based on the load prediction results and the current task type information.

[0036] The information determination module is used to determine the node health of the candidate microservice nodes based on their load rate, network latency information, and task type weight.

[0037] The task processing module is used to determine the target microservice node corresponding to the task to be processed from the candidate microservice nodes according to the node health status and the task processing request, and send the task to be processed to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

[0038] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0039] In response to a task processing request sent by the terminal for a task to be processed, the current load data of the microservice node to be analyzed corresponding to the task to be processed is obtained;

[0040] Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed;

[0041] Based on the load prediction results and the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes to be analyzed.

[0042] The node health of the candidate microservice nodes is determined based on their load rate, network latency information, and task type weight.

[0043] Based on the node health status and the task processing request, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes, and the task to be processed is sent to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

[0044] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0045] In response to a task processing request sent by the terminal for a task to be processed, the current load data of the microservice node to be analyzed corresponding to the task to be processed is obtained;

[0046] Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed;

[0047] Based on the load prediction results and the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes to be analyzed.

[0048] The node health of the candidate microservice nodes is determined based on their load rate, network latency information, and task type weight.

[0049] Based on the node health status and the task processing request, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes, and the task to be processed is sent to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

[0050] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0051] In response to a task processing request sent by the terminal for a task to be processed, the current load data of the microservice node to be analyzed corresponding to the task to be processed is obtained;

[0052] Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed;

[0053] Based on the load prediction results and the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes to be analyzed.

[0054] The node health of the candidate microservice nodes is determined based on their load rate, network latency information, and task type weight.

[0055] Based on the node health status and the task processing request, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes, and the task to be processed is sent to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

[0056] The aforementioned task processing method, apparatus, computer equipment, storage medium, and computer program product based on dynamic tidal load balancing technology for optimizing and scheduling microservice resources in a master station first responds to a task processing request sent by a terminal for a task to be processed. It then obtains the current load data of the microservice node to be analyzed corresponding to the task, acquires the current task type information of the task to be processed and the current access node information corresponding to the terminal, and inputs the current load data, current task type information, and current access node information into a trained load prediction model to obtain the load prediction result for the microservice node to be analyzed. Next, based on the load prediction result and the current task type information, it determines candidate microservice nodes corresponding to the task to be processed from the microservice nodes to be analyzed. Then, based on the load rate, network latency information, and task type weight of the candidate microservice nodes, it determines the node health of the candidate microservice nodes. Finally, based on the node health and the task processing request, it determines the target microservice node corresponding to the task to be processed from the candidate microservice nodes and sends the task to the target microservice node, enabling the target microservice node to process the task and obtain the task processing result corresponding to the task processing request. In this way, when processing tasks, the current load of microservice nodes is obtained in real time. Combined with task type and terminal access node information, the future load of nodes is predicted based on the load prediction model. Candidate nodes are selected based on the load prediction results and task type to ensure that node resources are accurately matched with task requirements. This avoids wasting high-priority node resources or allowing low-priority tasks to occupy critical resources. Furthermore, the health of candidate nodes is calculated through load rate, network latency, and task type weight, so that efficient nodes can be prioritized to undertake tasks. This ensures that resources are always tilted towards high-value tasks and efficient nodes, which is conducive to improving resource utilization. Moreover, the entire process adopts a dynamic allocation method, avoiding the problem of uneven resource utilization caused by the tidal effect of user access volume in the metering automation master station application, which is difficult to deal with by using static weight allocation or fixed polling strategy, thus resulting in low resource utilization. This further improves resource utilization. Attached Figure Description

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

[0058] Figure 1 This is a flowchart illustrating a task processing method for optimizing and scheduling microservice resources on a main station based on dynamic tidal load balancing technology in one embodiment.

[0059] Figure 2This is a flowchart illustrating the steps for determining the candidate microservice node corresponding to the task to be processed in one embodiment.

[0060] Figure 3 This is a flowchart illustrating a task processing method for optimizing and scheduling microservice resources on the main station based on dynamic tidal load balancing technology, as shown in another embodiment.

[0061] Figure 4 This is a structural block diagram of a task processing device for optimizing and scheduling the microservice resources of a master station based on dynamic tidal load balancing technology in one embodiment.

[0062] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0064] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0065] In one exemplary embodiment, such as Figure 1 As shown, a task processing method for optimizing and scheduling microservice resources on a master station based on dynamic tidal load balancing technology is provided. This embodiment illustrates the method by applying it to a server. It is understood that this method can also be applied to terminals, and to systems including terminals and servers, and is implemented through interaction between the terminals and servers. The terminals can be, but are not limited to, various personal computers, laptops, smartphones, and tablets; the servers can be independent servers or server clusters composed of multiple servers. In this embodiment, the method includes the following steps:

[0066] Step S101: In response to the task processing request sent by the terminal for the task to be processed, obtain the current load data of the microservice node to be analyzed corresponding to the task to be processed.

[0067] Among them, pending tasks refer to tasks that need to be processed.

[0068] Among them, a task processing request refers to a request to process a task that is to be processed.

[0069] Among them, the microservice nodes to be analyzed represent the set of candidate microservice nodes that may undertake the processing tasks.

[0070] The current load data refers to the load data of the microservice node to be analyzed at the current time.

[0071] For example, the server receives a task processing request for a task to be processed from the terminal via a network path, and performs an integrity check on the task processing request to obtain an integrity check result. If the integrity check result indicates that the task processing request is complete, the server responds to the task processing request by determining the current microservice node where the task to be processed is located, and from the microservice nodes, determining the microservice nodes whose network topology distance (e.g., network hop count) to the current microservice node is less than or equal to a preset network topology distance (e.g., set to "network hop count ≤ 2"), as the microservice node to be analyzed corresponding to the task to be processed. Then, the server uses a load monitoring module deployed on the microservice node to be analyzed to collect the CPU (Central Processing Time) of the microservice node to be analyzed in real time at the current time. The following data are used as the current load data for the microservice nodes to be analyzed: CPU (including CPU utilization and load, to assess CPU workload and performance status), memory data (mainly memory usage, to understand memory resource usage and avoid service abnormalities due to insufficient memory), network bandwidth data (including real-time monitoring of network bandwidth usage to determine if there is network congestion or insufficient bandwidth), and task queue depth data (including the number of tasks waiting to be processed in the task queue, reflecting the degree of task backlog).

[0072] Step S102: Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, current task type information and current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed.

[0073] The current task type information is used to indicate the business category to which the task to be processed belongs (including real-time high-priority requests, such as meter reading and call testing, as well as batch processing tasks, such as log processing), also known as service type label.

[0074] The current access node information refers to the information corresponding to the microservice node to which the terminal is connected, also known as the information corresponding to the current microservice node where the task to be processed is located.

[0075] Among them, the load prediction model refers to the network model that can use the current load data, current task type information and current access node information to obtain the load prediction result of the microservice node to be analyzed, such as the LSTM (Long Short-Term Memory) model.

[0076] The load prediction result refers to the quantitative data of the load status of the microservice node to be analyzed in a future period (such as the next month).

[0077] For example, the server extracts the field features of key fields from the request parameters carried in the task processing request, and inputs these field features into the trained task type prediction model to obtain the predicted probability of the task to be processed under each preset task type information. Next, the server selects the preset task type information with the highest predicted probability from the preset task type information and uses it as the current task type information of the task to be processed. Then, the server obtains the current access node information corresponding to the terminal. Next, the server inputs the current load data, current task type information, and current access node information into the trained load prediction model to obtain the first load prediction result corresponding to the microservice node to be analyzed. Then, the server inputs the current load data, current task type information, and current access node information into the historical load prediction model to obtain the second load prediction result corresponding to the microservice node to be analyzed. Finally, the server fuses the first and second load prediction results according to the model weights of the trained load prediction model and the historical load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed.

[0078] Step S103: Based on the load prediction results and the current task type information, determine the candidate microservice nodes corresponding to the tasks to be processed from the microservice nodes to be analyzed.

[0079] Among them, candidate microservice nodes represent the set of microservice nodes that are analyzed and have the ability to take on the current task.

[0080] For example, based on the load prediction results and the current task type information, the server determines from the microservice nodes to be analyzed which microservice nodes have load prediction results that satisfy the preset load prediction results and current task type information that satisfy the preset task type information, and uses these microservice nodes as candidate microservice nodes corresponding to the tasks to be processed.

[0081] Step S104: Determine the node health of the candidate microservice nodes based on their load rate, network latency information, and task type weight.

[0082] The load rate is used to represent the load pressure of candidate microservice nodes at the current time. The higher the load rate, the greater the pressure on the candidate microservice nodes.

[0083] The network latency information indicates the data transmission latency of the candidate microservice nodes. It's important to note that network latency affects task execution efficiency; low-latency nodes are better suited for handling real-time tasks.

[0084] Among them, the task type weight is used to represent the weight coefficient corresponding to the current task type information of the candidate microservice node to be adapted to the task to be processed.

[0085] Among them, node health is used to represent a quantitative score corresponding to the comprehensive ability of candidate microservice nodes to undertake processing tasks.

[0086] For example, the server extracts a first feature vector of the load rate of the candidate microservice node, a second feature vector of the network latency information, and a third feature vector of the task type weight. The server then fuses the first, second, and third feature vectors to obtain a fused feature vector. Next, the server inputs the fused feature vector into multiple trained node health prediction models to obtain multiple predicted node health values ​​for the candidate microservice node. Finally, the server sums the multiple predicted node health values ​​of the candidate microservice node according to the model weights of each trained node health prediction model to obtain the node health value of the candidate microservice node.

[0087] Step S105: Based on the node health and task processing request, determine the target microservice node corresponding to the task to be processed from the candidate microservice nodes, and send the task to be processed to the target microservice node so that the target microservice node can process the task to be processed and obtain the task processing result corresponding to the task processing request.

[0088] The target microservice node refers to the microservice node that is most suitable for the task to be processed.

[0089] The task processing result is used to represent the final output data or status feedback information corresponding to the task processing request.

[0090] For example, the server determines the microservice node whose node health and task processing request both meet the preset conditions from the candidate microservice nodes based on the node health and task processing request, and uses it as the target microservice node for the task to be processed; then, the server sends the task to be processed to the target microservice node through the network path between the server and the target microservice node, so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

[0091] In the above-mentioned task processing method for optimizing and scheduling microservice resources of the main station based on dynamic tidal load balancing technology, the following steps are taken: First, in response to the task processing request sent by the terminal for the task to be processed, the current load data of the microservice node to be analyzed corresponding to the task to be processed is obtained. Then, the current task type information of the task to be processed and the current access node information of the terminal are obtained. The current load data, current task type information, and current access node information are input into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed. Next, based on the load prediction result and the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes to be analyzed. Then, based on the load rate, network latency information, and task type weight of the candidate microservice nodes, the node health of the candidate microservice nodes is determined. Finally, based on the node health and the task processing request, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes, and the task to be processed is sent to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request. In this way, when processing tasks, the current load of microservice nodes is obtained in real time. Combined with task type and terminal access node information, the future load of nodes is predicted based on the load prediction model. Candidate nodes are selected based on the load prediction results and task type to ensure that node resources are accurately matched with task requirements. This avoids wasting high-priority node resources or allowing low-priority tasks to occupy critical resources. Furthermore, the health of candidate nodes is calculated through load rate, network latency, and task type weight, so that efficient nodes can be prioritized to undertake tasks. This ensures that resources are always tilted towards high-value tasks and efficient nodes, which is conducive to improving resource utilization. Moreover, the entire process adopts a dynamic allocation method, avoiding the problem of uneven resource utilization caused by the tidal effect of user access volume in the metering automation master station application, which is difficult to deal with by using static weight allocation or fixed polling strategy, thus resulting in low resource utilization. This further improves resource utilization.

[0092] In one exemplary embodiment, such as Figure 2 As shown, step S103 above, based on the load prediction results and the current task type information, determines the candidate microservice nodes corresponding to the tasks to be processed from the microservice nodes to be analyzed, specifically including the following steps:

[0093] Step S201: Obtain the preset partitioning ratio corresponding to the microservice node to be analyzed.

[0094] Step S202: Based on the load prediction results, update the preset partition ratio to obtain the updated partition ratio corresponding to the microservice node to be analyzed.

[0095] Step S203: According to the updated partitioning ratio, the microservice nodes to be analyzed are partitioned to obtain microservice nodes under different resource pool types.

[0096] Step S204: Based on the current task type information, determine the candidate microservice nodes corresponding to the task to be processed from the microservice nodes under different resource pool types.

[0097] The preset allocation ratio represents the pre-defined proportion of the microservice nodes to be analyzed that are allocated to different resource pools. For example, 60% of the microservice nodes to be analyzed belong to the online pool, and 40% belong to the offline pool.

[0098] The updated allocation ratio refers to the preset allocation ratio after updating based on the load forecast results. For example, based on the load forecast results (which indicate whether the current time period is a peak or off-peak period), during peak periods, the resource ratio of the online pool is dynamically expanded, for example, to 80%, to ensure that critical business operations can be processed in a timely and efficient manner; during off-peak periods, the resource ratio of the offline pool is appropriately increased to make full use of idle resources and improve the overall resource utilization rate.

[0099] The resource pool type represents the classification result corresponding to the microservice node. In practical scenarios, resource pool types include online pools and offline pools. It should be noted that each resource pool type corresponds to specific task type information. For example, the online pool is mainly responsible for handling real-time, high-priority requests, while the offline pool is used to handle batch processing tasks.

[0100] For example, the server determines the preset partitioning ratio corresponding to the microservice node to be analyzed based on the historical load pattern information of the microservice node to be analyzed; then, based on the load prediction results, the server determines the ratio update information corresponding to the preset partitioning ratio (such as dynamically expanding the resource ratio of the online pool or appropriately increasing the resource ratio of the offline pool), and updates the preset partitioning ratio according to the ratio update information to obtain the updated partitioning ratio corresponding to the microservice node to be analyzed; then, the server partitions the microservice node to be analyzed according to the updated partitioning ratio to obtain microservice nodes under different resource pool types; finally, based on the current task type information, the server determines the candidate microservice node corresponding to the task to be processed from the microservice nodes under different resource pool types.

[0101] In this embodiment, by updating the preset partitioning ratio based on the load prediction results, the mismatch between the resource pool and the actual load caused by partitioning according to a fixed ratio is avoided, and the size of the resource pool is dynamically adjusted with the load changes, thereby improving the overall resource utilization rate. Moreover, the candidate nodes are directly matched to the corresponding resource pool according to the current task type, without having to traverse all nodes to be analyzed, which greatly simplifies the filtering logic.

[0102] In an exemplary embodiment, step S204 above, which determines the candidate microservice node corresponding to the task to be processed from the microservice nodes under different resource pool types based on the current task type information, specifically includes the following: based on the current task type information, querying the correspondence between the task type information and the resource pool type to obtain the current resource pool type corresponding to the task to be processed; determining the microservice node corresponding to the current resource pool type from the microservice nodes under different resource pool types as the candidate microservice node corresponding to the task to be processed.

[0103] The current resource pool type refers to the resource pool type that matches the task to be processed.

[0104] For example, the server queries the correspondence between the current task type information and the resource pool type based on the current task type information, obtains the resource pool type corresponding to the current task type information, and uses the resource pool type as the current resource pool type corresponding to the task to be processed; then, the server determines the microservice node corresponding to the current resource pool type from the microservice nodes under different resource pool types, and uses the microservice node as the candidate microservice node corresponding to the task to be processed.

[0105] In this embodiment, the resource pool type that matches the current task is directly queried based on a preset correspondence, without having to judge the suitability of each resource pool node one by one. This greatly reduces the amount of computation and time spent in the screening process, improves task allocation efficiency, reduces task execution delay and resource waste, and achieves efficient screening of candidate nodes.

[0106] In an exemplary embodiment, step S105 above, which determines the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the node health and the task processing request, specifically includes the following: determining the scheduling weight corresponding to the candidate microservice node based on the node health; determining the virtual node corresponding to the candidate microservice node based on the scheduling weight; and determining the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the task processing request and the virtual node.

[0107] The scheduling weight is a quantified coefficient representing the priority of tasks undertaken by candidate microservice nodes. It's important to note that the scheduling weight is positively correlated with node health. Microservice nodes with higher health have a larger scheduling weight and a higher probability of receiving task assignments.

[0108] Virtual nodes refer to logical node replicas obtained by mapping candidate microservice nodes.

[0109] For example, the server queries the correspondence between node health and scheduling weight based on node health, obtains the scheduling weight corresponding to the node health, and uses it as the scheduling weight corresponding to the candidate microservice node; then, the server multiplies the scheduling weight by the total number of virtual nodes corresponding to the hash ring, obtains the number of virtual nodes corresponding to the candidate microservice node on the hash ring, and uses the virtual nodes corresponding to the number of virtual nodes as the virtual nodes corresponding to the candidate microservice node; based on the task processing request and the virtual nodes, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes.

[0110] For example, if candidate microservice node A has a health score of 90, and the corresponding relationship shows a scheduling weight of 0.9, and the total number of virtual nodes in the hash ring is 200, then the number of its virtual nodes is 0.9 × 200 = 180. These virtual nodes will be evenly distributed on the hash ring.

[0111] In this embodiment, by determining the scheduling weight based on the node health, it is ensured that nodes with higher health receive higher scheduling priority, thereby reducing task execution failure rate and latency. Furthermore, virtual nodes are mapped based on the scheduling weight, transforming weight differences into differences in the number of virtual nodes, thus achieving load balancing among candidate nodes and improving the accuracy of microservice scheduling.

[0112] In an exemplary embodiment, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes based on the task processing request and the virtual node. Specifically, this includes: obtaining a first hash value corresponding to the task processing request and a second hash value corresponding to the virtual node; determining the target virtual node corresponding to the task to be processed from the virtual nodes based on the first hash value and the second hash value; and determining the microservice node corresponding to the target virtual node from the candidate microservice nodes as the target microservice node corresponding to the task to be processed.

[0113] The first hash value refers to the hash value corresponding to the task processing request.

[0114] The second hash value refers to the hash value corresponding to the virtual node.

[0115] The target virtual node refers to the virtual node that matches the task to be processed.

[0116] For example, the server extracts key information (such as task identifier, terminal identifier, request identifier, etc.) from the task processing request and performs hash calculation on the key information to obtain the first hash value corresponding to the task processing request. Then, based on the position information of the virtual node on the hash ring, the server obtains the second hash value corresponding to the virtual node. Then, through consistent hash matching, the server sorts the second hash values ​​of all virtual nodes by size and distributes them on the hash ring. The virtual node corresponding to the first second hash value encountered by the first hash value in the clockwise (or counterclockwise) direction on the hash ring is taken as the target virtual node corresponding to the task to be processed. Then, the server determines the microservice node corresponding to the target virtual node from the candidate microservice nodes and takes it as the target microservice node corresponding to the task to be processed.

[0117] In this embodiment, a first hash value is generated based on the task processing request, and a second hash value is generated by the virtual node. The objective matching of hash values ​​replaces the judgment of manual rules, avoiding the subjectivity of task allocation, ensuring that the same or similar tasks can be stably mapped to the same type of node, improving scheduling consistency, avoiding overload of a single node, and balancing efficiency and balance.

[0118] In an exemplary embodiment, step S104 above, which determines the node health of a candidate microservice node based on its load rate, network latency information, and task type weight, specifically includes the following: determining the first node health of the candidate microservice node based on its load rate; determining the second node health of the candidate microservice node based on its network latency information; determining the third node health of the candidate microservice node based on its task type weight; and fusing the first, second, and third node health values ​​to obtain the node health of the candidate microservice node.

[0119] The first node health score refers to the node health score obtained based on the load rate of the candidate microservice nodes.

[0120] The second node health refers to the node health obtained based on the network latency information of the candidate microservice nodes.

[0121] Among them, the third node health refers to the node health obtained based on the task type weight of the candidate microservice node.

[0122] For example, the server determines, from multiple node health prediction models, a first node health prediction model corresponding to the load rate of the candidate microservice node, a second node health prediction model corresponding to the network latency information of the candidate microservice node, and a third node health prediction model corresponding to the task type weight of the candidate microservice node. Next, the server inputs the load rate into the first node health prediction model to obtain the node health corresponding to the load rate, which is used as the first node health of the candidate microservice node. Then, the server inputs the network latency information into the second node health prediction model to obtain the node health corresponding to the network latency information, which is used as the second node health of the candidate microservice node. Next, the server inputs the task type weight into the third node health prediction model to obtain the node health corresponding to the task type weight, which is used as the third node health of the candidate microservice node. Finally, the server sums the first node health, second node health, and third node health based on the model weights of the first, second, and third node health prediction models to obtain the node health of the candidate microservice node.

[0123] In this embodiment, load rate, network latency, and task type weight are evaluated as three independent dimensions, avoiding misjudgments of health caused by a single indicator. This allows the health status of each dimension to be accurately quantified. By integrating the results of the three dimensions through fusion processing, it is beneficial to ensure that the final health status can truly reflect the node's comprehensive ability to undertake the current task.

[0124] In one exemplary embodiment, such as Figure 3 As shown, another task processing method based on dynamic tidal load balancing technology for optimizing the scheduling of microservice resources on the main station is provided. Taking the application of this method to a server as an example, the specific steps include:

[0125] Step S301: In response to the task processing request sent by the terminal for the task to be processed, obtain the current load data of the microservice node to be analyzed corresponding to the task to be processed.

[0126] Step S302: Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, current task type information and current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed.

[0127] Step S303: Obtain the preset partition ratio corresponding to the microservice node to be analyzed; update the preset partition ratio according to the load prediction result to obtain the updated partition ratio corresponding to the microservice node to be analyzed; partition the microservice node to be analyzed according to the updated partition ratio to obtain microservice nodes under different resource pool types.

[0128] Step S304: Based on the current task type information, query the correspondence between the task type information and the resource pool type to obtain the current resource pool type corresponding to the task to be processed.

[0129] Step S305: From the microservice nodes under different resource pool types, determine the microservice node corresponding to the current resource pool type as the candidate microservice node for the task to be processed.

[0130] Step S306: Determine the first node health of the candidate microservice node based on the load rate of the candidate microservice node; determine the second node health of the candidate microservice node based on the network latency information of the candidate microservice node; determine the third node health of the candidate microservice node based on the task type weight of the candidate microservice node.

[0131] Step S307: The health scores of the first node, the second node, and the third node are fused to obtain the node health scores of the candidate microservice nodes.

[0132] Step S308: Determine the scheduling weight corresponding to the candidate microservice node based on the node health; determine the virtual node corresponding to the candidate microservice node based on the scheduling weight.

[0133] Step S309: Obtain the first hash value corresponding to the task processing request and the second hash value corresponding to the virtual node; determine the target virtual node corresponding to the task to be processed from the virtual nodes based on the first hash value and the second hash value.

[0134] Step S310: Determine the microservice node corresponding to the target virtual node from the candidate microservice nodes, and use it as the target microservice node for the task to be processed.

[0135] Step S311: Send the task to be processed to the target microservice node so that the target microservice node can process the task and obtain the task processing result corresponding to the task processing request.

[0136] In the aforementioned task processing method for optimizing and scheduling microservice resources on the main station based on dynamic tidal load balancing technology, when processing tasks, the current load of microservice nodes is obtained in real time. Combined with task type and terminal access node information, the future load of nodes is predicted based on a load prediction model. Candidate nodes are selected based on the load prediction results and task type to ensure that node resources are accurately matched with task requirements, avoiding waste of high-priority node resources or allowing low-priority tasks to occupy critical resources. Furthermore, the health of candidate nodes is calculated through load rate, network latency, and task type weight, thereby prioritizing the selection of efficient nodes to undertake tasks. This ensures that resources are always tilted towards high-value tasks and efficient nodes, which is conducive to improving resource utilization. Moreover, the entire process adopts a dynamic allocation method, avoiding the problem of uneven resource utilization caused by the tidal effect of user access volume in metering automation main station applications, which is difficult to deal with by using static weight allocation or fixed polling strategies, resulting in low resource utilization. This further improves resource utilization.

[0137] In an exemplary embodiment, to more clearly illustrate the task processing method for optimizing and scheduling master station microservice resources based on dynamic tidal load balancing technology provided in this application, the following specific embodiment will be used to describe this task processing method for optimizing and scheduling master station microservice resources based on dynamic tidal load balancing technology. In one embodiment, this application also provides a method for optimizing and scheduling master station microservice resources based on dynamic tidal load balancing technology. Specifically, it includes the following:

[0138] A method for optimizing and scheduling microservice resources in a master station based on dynamic tidal load balancing technology is proposed, applicable to metering automation master station applications and edge computing scenarios. By real-time sensing of microservice load fluctuations and combining them with dynamic weight adjustment strategies, efficient resource allocation and service quality optimization are achieved, making it particularly suitable for high-concurrency business scenarios with significant load fluctuations.

[0139] The specific plan is as follows:

[0140] I. Real-time acquisition of multi-dimensional load data:

[0141] Dedicated load monitoring modules are deployed on each microservice node to collect load data from multiple dimensions in real time. The load data specifically includes: CPU-related data (including CPU utilization, load status, etc., to assess CPU workload and performance status), memory data (mainly memory utilization, to understand the use of memory resources and avoid service abnormalities due to insufficient memory), network bandwidth data (including real-time monitoring of network bandwidth usage to determine if there are network congestion or insufficient bandwidth issues), and task queue depth data (including clearly identifying the number of tasks waiting to be processed in the task queue, reflecting the degree of task backlog).

[0142] The collected load data will be stored in a time-series database in a timely manner for subsequent analysis and processing. Time-series databases can efficiently process and store data that changes over time, providing a solid data foundation for subsequent load forecasting.

[0143] II. Constructing a spatiotemporal prediction model integrating an LSTM neural network to predict load fluctuations:

[0144] The spatiotemporal prediction model's input parameters include historical traffic data, service type labels, and user access node information. Historical traffic data is used to analyze traffic patterns over a past period, including peak and off-peak traffic times and trends of increase or decrease. Service type labels are used to tag different types of services (such as meter reading, call generation, and log processing), as these services have different load characteristics and priorities. User access node information helps identify the specific nodes accessed by users, aiding in the analysis of load distribution across different nodes.

[0145] By comprehensively analyzing these input parameters, the spatiotemporal prediction model, using an LSTM neural network, can learn the spatiotemporal characteristics and patterns of load changes, thereby predicting load trends for the next 24 hours. Furthermore, introducing service type labels can further optimize prediction accuracy, enabling more accurate predictions based on the priority and characteristics of different services.

[0146] III. Dynamically dividing online and offline resource pools:

[0147] Based on the load prediction results, the microservice nodes are divided into online pools and offline pools.

[0148] The online pool is primarily responsible for handling real-time, high-priority requests, such as meter reading and call testing. During peak periods, based on forecast results, the resource allocation of the online pool is dynamically expanded, for example, to 80%, to ensure that critical business processes can be handled promptly and efficiently.

[0149] The offline pool is used to process batch tasks, such as log processing. During off-peak periods, the resource allocation of the offline pool should be appropriately increased to make full use of idle resources and improve the overall resource utilization rate.

[0150] By dynamically adjusting the resource pool ratio as described above, flexible resource allocation is achieved, better adapting to load demands at different times.

[0151] IV. Generating scheduling weights based on node health scores:

[0152] The health of a node is scored by taking into account factors such as load rate, network latency, and service type weight. The load rate reflects the current load pressure of the node; the higher the load rate, the greater the pressure on the node. Network latency affects the execution efficiency of tasks; nodes with low latency are more suitable for handling real-time tasks. Based on the importance and priority of different services, corresponding service type weights are assigned to the nodes.

[0153] Dynamic scheduling weights are generated based on node health scores. Tasks are prioritized for allocation to low-latency, highly available nodes to improve task execution efficiency and service quality. Simultaneously, an improved consistent hashing algorithm is employed, mapping 200 virtual nodes to each physical node to achieve a balanced load distribution across all nodes, preventing load concentration on a few nodes.

[0154] Consistent hashing algorithm principle:

[0155] Consistent hashing organizes the entire hash space into a virtual ring. Each physical node in the system is mapped to a position on this ring. When a request arrives, the hash value of the request is used to search clockwise on the ring, and the first physical node found is the node to which the request will be assigned.

[0156] Improvements to the consistent hashing algorithm: the introduction of virtual nodes.

[0157] To avoid load imbalance caused by uneven distribution of physical nodes on the hash ring, 200 virtual nodes are created for each physical node, and these virtual nodes are also mapped to the hash ring. This way, when a request looks up a node, it is more evenly distributed across the virtual nodes corresponding to each physical node, thus achieving load balancing.

[0158] V. Implement partial task migration to balance the load:

[0159] When the load on a node exceeds a preset threshold (e.g., CPU utilization > 85%), a local task migration mechanism is triggered.

[0160] 1. Migration Protocol: The QUIC (Quick UDP Internet Connections) protocol is used for multi-path parallel transmission. This protocol is characterized by high efficiency and low latency, which improves the efficiency of task migration. Simultaneously, forward error correction (FEC) is used to add redundant information during data transmission, reducing the packet loss rate during migration and ensuring it is below 0.1%, thus guaranteeing data integrity and consistency.

[0161] 2. Traffic Monitoring and Retry: Integrated service mesh enables real-time monitoring of cross-node traffic. When task migration fails, it can automatically retry, improving the system's fault tolerance and stability.

[0162] 3. Migration ratio: When the node load exceeds the threshold, 20% of the tasks on that node will be migrated to idle nodes to alleviate the load pressure on that node, while ensuring that the overall performance of the system is not significantly affected.

[0163] In the above embodiments, when processing tasks, the current load of microservice nodes is obtained in real time. Combined with task type and terminal access node information, the future load of nodes is predicted based on a load prediction model. Candidate nodes are selected based on the load prediction results and task type to ensure that node resources are accurately matched with task requirements. This avoids wasting high-priority node resources or allowing low-priority tasks to occupy critical resources. Furthermore, the health of candidate nodes is calculated through load rate, network latency, and task type weight, thereby prioritizing the selection of efficient nodes to undertake tasks. This ensures that resources are always tilted towards high-value tasks and efficient nodes, which is beneficial to improving resource utilization. Moreover, the entire process adopts a dynamic allocation method, avoiding the problem of uneven resource utilization caused by the tidal effect of user access volume in metering automation master station applications, which is difficult to deal with by static weight allocation or fixed polling strategies, resulting in low resource utilization. This further improves resource utilization. At the same time, by combining the LSTM model and business tags, the resource pool can be preheated 72 hours in advance. By adjusting resource allocation and configuration in advance before sudden traffic surges, the impact of these surges on service stability was effectively reduced, improving the system's responsiveness. Dynamic switching between online and offline dual pools enabled efficient resource utilization, increasing resource utilization from 40% to over 85% compared to traditional solutions, thus reducing resource waste. Multi-path parallel transmission based on the QUIC protocol improved task migration efficiency by 60% compared to traditional TCP (Transmission Control Protocol). Simultaneously, forward error correction coding (FEC) ensured data consistency during migration, guaranteeing successful task execution.

[0164] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0165] Based on the same inventive concept, this application also provides a task processing device for optimizing the scheduling of master station microservice resources based on dynamic tidal load balancing technology, used to implement the task processing method for optimizing the scheduling of master station microservice resources based on dynamic tidal load balancing technology described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the task processing device for optimizing the scheduling of master station microservice resources based on dynamic tidal load balancing technology provided below can be found in the limitations of the task processing method for optimizing the scheduling of master station microservice resources based on dynamic tidal load balancing technology described above, and will not be repeated here.

[0166] In one exemplary embodiment, such as Figure 4 As shown, a task processing device for optimizing and scheduling microservice resources on a master station based on dynamic tidal load balancing technology is provided, comprising: a data acquisition module 401, a load prediction module 402, a node determination module 403, an information determination module 404, and a task processing module 405, wherein:

[0167] The data acquisition module 401 is used to respond to the task processing request sent by the terminal for the task to be processed and to obtain the current load data of the microservice node to be analyzed corresponding to the task to be processed.

[0168] The load prediction module 402 is used to obtain the current task type information of the task to be processed and the current access node information of the terminal, and input the current load data, current task type information and current access node information into the trained load prediction model to obtain the load prediction result of the microservice node to be analyzed.

[0169] The node determination module 403 is used to determine the candidate microservice nodes corresponding to the tasks to be processed from the microservice nodes to be analyzed based on the load prediction results and the current task type information.

[0170] The information determination module 404 is used to determine the node health of candidate microservice nodes based on the load rate, network latency information and task type weight of the candidate microservice nodes.

[0171] The task processing module 405 is used to determine the target microservice node corresponding to the task to be processed from the candidate microservice nodes according to the node health and the task processing request, and send the task to be processed to the target microservice node so that the target microservice node can process the task to be processed and obtain the task processing result corresponding to the task processing request.

[0172] In an exemplary embodiment, the node determination module 403 is further configured to obtain a preset partitioning ratio corresponding to the microservice node to be analyzed; update the preset partitioning ratio according to the load prediction result to obtain the updated partitioning ratio corresponding to the microservice node to be analyzed; partition the microservice node to be analyzed according to the updated partitioning ratio to obtain microservice nodes under different resource pool types; and determine the candidate microservice node corresponding to the task to be processed from the microservice nodes under different resource pool types according to the current task type information.

[0173] In an exemplary embodiment, the node determination module 403 is further configured to query the correspondence between the task type information and the resource pool type based on the current task type information to obtain the current resource pool type corresponding to the task to be processed; and determine the microservice node corresponding to the current resource pool type from the microservice nodes under different resource pool types as the candidate microservice node corresponding to the task to be processed.

[0174] In an exemplary embodiment, the task processing module 405 is further configured to determine the scheduling weight corresponding to the candidate microservice node based on the node health; determine the virtual node corresponding to the candidate microservice node based on the scheduling weight; and determine the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the task processing request and the virtual node.

[0175] In an exemplary embodiment, the task processing module 405 is further configured to obtain a first hash value corresponding to the task processing request and a second hash value corresponding to the virtual node; determine the target virtual node corresponding to the task to be processed from the virtual nodes based on the first hash value and the second hash value; and determine the microservice node corresponding to the target virtual node from the candidate microservice nodes as the target microservice node corresponding to the task to be processed.

[0176] In an exemplary embodiment, the information determination module 404 is further configured to determine the first node health of the candidate microservice node based on the load rate of the candidate microservice node; determine the second node health of the candidate microservice node based on the network latency information of the candidate microservice node; determine the third node health of the candidate microservice node based on the task type weight of the candidate microservice node; and perform fusion processing on the first node health, the second node health, and the third node health to obtain the node health of the candidate microservice node.

[0177] The modules in the task processing device for optimizing and scheduling microservice resources on the main station based on dynamic tidal load balancing technology can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0178] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as current task type information and current access node information. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a task processing method for optimizing the scheduling of master station microservice resources based on dynamic tidal load balancing technology.

[0179] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0180] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0181] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above-described method embodiments.

[0182] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0183] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0184] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0185] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A task processing method for optimizing and scheduling master station microservice resources based on dynamic tidal load balancing technology, characterized in that, The method includes: In response to a task processing request sent by the terminal for a task to be processed, the current load data of the microservice node to be analyzed corresponding to the task to be processed is obtained; Obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed; Based on the load prediction results and the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes to be analyzed. The node health of the candidate microservice nodes is determined based on their load rate, network latency information, and task type weight. Based on the node health status and the task processing request, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes, and the task to be processed is sent to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

2. The method according to claim 1, characterized in that, The step of determining the candidate microservice node corresponding to the task to be processed from the microservice nodes to be analyzed based on the load prediction result and the current task type information includes: Obtain the preset partitioning ratio corresponding to the microservice node to be analyzed; Based on the load prediction results, the preset partition ratio is updated to obtain the updated partition ratio corresponding to the microservice node to be analyzed. According to the updated partitioning ratio, the microservice nodes to be analyzed are partitioned to obtain microservice nodes under different resource pool types. Based on the current task type information, candidate microservice nodes corresponding to the task to be processed are determined from the microservice nodes under the different resource pool types.

3. The method according to claim 2, characterized in that, The step of determining the candidate microservice node corresponding to the task to be processed from the microservice nodes under different resource pool types based on the current task type information includes: Based on the current task type information, query the correspondence between the task type information and the resource pool type to obtain the current resource pool type corresponding to the task to be processed; From the microservice nodes under the different resource pool types, the microservice node corresponding to the current resource pool type is determined as the candidate microservice node for the task to be processed.

4. The method according to claim 1, characterized in that, The step of determining the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the node health status and the task processing request includes: Based on the node health status, the scheduling weight corresponding to the candidate microservice node is determined; Based on the scheduling weight, the virtual node corresponding to the candidate microservice node is determined; Based on the task processing request and the virtual node, the target microservice node corresponding to the task to be processed is determined from the candidate microservice nodes.

5. The method according to claim 4, characterized in that, The step of determining the target microservice node corresponding to the task to be processed from the candidate microservice nodes based on the task processing request and the virtual node includes: Obtain the first hash value corresponding to the task processing request and the second hash value corresponding to the virtual node; Based on the first hash value and the second hash value, the target virtual node corresponding to the task to be processed is determined from the virtual nodes; The microservice node corresponding to the target virtual node is determined from the candidate microservice nodes and used as the target microservice node for the task to be processed.

6. The method according to any one of claims 1 to 5, characterized in that, The step of determining the node health of the candidate microservice nodes based on their load rate, network latency information, and task type weights includes: The health status of the first node of the candidate microservice nodes is determined based on the load rate of the candidate microservice nodes. The health status of the second node of the candidate microservice node is determined based on the network latency information of the candidate microservice node. The health of the third node of the candidate microservice node is determined based on the task type weight of the candidate microservice node. The health scores of the first node, the second node, and the third node are fused to obtain the node health score of the candidate microservice node.

7. A task processing device for optimizing and scheduling master station microservice resources based on dynamic tidal load balancing technology, characterized in that, The device includes: The data acquisition module is used to respond to the task processing request sent by the terminal for the task to be processed and to acquire the current load data of the microservice node to be analyzed corresponding to the task to be processed. The load prediction module is used to obtain the current task type information of the task to be processed and the current access node information corresponding to the terminal, and input the current load data, the current task type information and the current access node information into the trained load prediction model to obtain the load prediction result corresponding to the microservice node to be analyzed. The node determination module is used to determine the candidate microservice node corresponding to the task to be processed from the microservice nodes to be analyzed based on the load prediction results and the current task type information. The information determination module is used to determine the node health of the candidate microservice nodes based on their load rate, network latency information, and task type weight. The task processing module is used to determine the target microservice node corresponding to the task to be processed from the candidate microservice nodes according to the node health status and the task processing request, and send the task to be processed to the target microservice node so that the target microservice node processes the task to be processed and obtains the task processing result corresponding to the task processing request.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images