Resource scheduling method and device, equipment, storage medium and computer product

Abstract

The invention relates to the technical field of content distribution network resource management, and provides a resource scheduling method, device and equipment, a storage medium and a computer product, a service request is received, a feature vector of the service request is determined, and the feature vector represents the service processing complexity, the service quality level and the service weight factor of the service request; obtaining one or more of load information, performance information and fault information of the node to determine a computing power score of the node; and determining a resource scheduling strategy of the service request based on the feature vector and the computing power score. The computing power demand of the service request is measured from multiple angles, the computing power demand evaluation accuracy is improved, the resource scheduling strategy is determined based on the computing power demand of the service request represented by the feature vector and the computing power score of the node, the service computing power demand can be dynamically matched, and the resource scheduling efficiency is improved. The computing power score of the node is determined based on one or more of load information, performance information and fault information, and burst traffic and node state dynamic changes can be handled.

Description

Technical Field

[0001] This application relates to the field of content delivery network resource management technology, specifically to a resource scheduling method, apparatus, device, storage medium, and computer product. Background Technology

[0002] Currently, Content Delivery Network (CDN) scheduling systems typically allocate computing power based on resource allocation strategies, achieving load balancing through round-robin or threshold-triggered methods. For example, when a node's CPU utilization exceeds a threshold (e.g., 80%), task migration is triggered; another method is to predict future resource demands by analyzing historical load data and allocate computing power according to the prediction. However, these methods rely on a single metric to measure computing power demand, failing to accurately assess business computing power requirements. Using fixed quotas or simple round-robin mechanisms cannot dynamically match real-time business computing power needs, leading to insufficient or overloaded resource utilization. Furthermore, relying on historical data for prediction makes it difficult to cope with sudden traffic surges and dynamic changes in node status. Summary of the Invention

[0003] This application provides a resource scheduling method, apparatus, device, storage medium, and computer product to solve the problems in the prior art that rely on a single indicator to measure computing power demand, which cannot accurately assess business computing power demand; adopt fixed quotas or simple polling mechanisms, which cannot dynamically match the real-time computing power demand of the business, resulting in insufficient resource utilization or overload; and rely on historical data for prediction, which is difficult to cope with sudden traffic and dynamic changes in node status.

[0004] In a first aspect, embodiments of this application provide a resource scheduling method, including: Receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level and service weight factor of the service request. Obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score; Based on the feature vector and the computing power score, the resource scheduling strategy for the service request is determined.

[0005] As one embodiment, receiving a service request and determining the feature vector of the service request includes: Receive the service request and determine the type identifier of the service request; Based on the type identifier, the business processing complexity, the service quality level, and the business weight factor are determined respectively. The feature vector is determined based on the business processing complexity, the service quality level, and the business weight factor.

[0006] As one embodiment, determining the business processing complexity, the service quality level, and the business weight factor based on the type identifier includes: The complexity of the business processing is determined based on the number of instruction cycles required to identify the type and the amount of data required to complete the business request. Based on the type identifier, the service quality level to which the service request belongs is obtained by filtering from a preset service quality level library; Based on the type identifier, the business weight factor to which the business request belongs is obtained by filtering from the preset business weight factor library.

[0007] As one embodiment, obtaining one or more of the node's load information, performance information, and fault information to determine the node's computing power score includes: Obtain the load information, the performance information, and the fault information; The computing power score is determined based on the load information, the performance information, and the fault information.

[0008] As one embodiment, determining the computing power score based on the load information, the performance information, and the fault information includes: Based on the node type, a first weight corresponding to the load information, a second weight corresponding to the performance information, and a third weight corresponding to the fault information are determined. The computing power score is determined based on the load information, the performance information, the fault information, the first weight, the second weight, and the third weight.

[0009] As one embodiment, determining the resource scheduling strategy for the service request based on the feature vector and the computing power score includes: Based on the computing power score, candidate nodes are determined; Based on the feature vector and the computing power score, the matching score of the candidate node is determined; The candidate nodes are sorted based on the matching score to determine the target node, and the resource scheduling strategy is determined based on the target node.

[0010] As one embodiment, it also includes: The load information of the node is obtained based on the first time granularity; The performance and fault information of the node are obtained based on the second time granularity. Based on the load information, optimize the resource scheduling strategy, and / or, based on the performance information and the fault information, optimize the resource scheduling strategy; Wherein, the first time granularity is smaller than the second time granularity.

[0011] As one embodiment, optimizing the resource scheduling strategy based on the load information, and / or optimizing the resource scheduling strategy based on the performance information and the fault information, includes: Based on the load information, anomaly detection is performed on the node; if an anomaly is detected in the node, migration processing is performed on the node; and / or Based on the performance information and the fault information, a performance trend detection is performed to obtain the performance trend detection result, and the weight required for the computing power score in the calculation process is adjusted based on the performance trend detection result.

[0012] Secondly, embodiments of this application provide a resource scheduling apparatus, comprising: The first determining module is used to receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level and service weight factor of the service request. The second determining module is used to obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score. The third determining module is used to determine the resource scheduling strategy for the service request based on the feature vector and the computing power score.

[0013] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the resource scheduling method described in the first aspect.

[0014] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the resource scheduling method described in the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the resource scheduling method described in the first aspect.

[0016] The resource scheduling method, apparatus, device, storage medium, and computer product provided in this application receive a service request, determine a feature vector of the service request, the feature vector being used to characterize the service processing complexity, service quality level, and service weight factor of the service request; acquire one or more of the node's load information, performance information, and fault information to determine the node's computing power score; and determine a resource scheduling strategy for the service request based on the feature vector and the computing power score. This application characterizes the service processing complexity, service quality level, and service weight factor of the service request using feature vectors, measuring the computing power demand of the service request from multiple perspectives, which can improve the accuracy of computing power demand assessment. Determining a resource scheduling strategy based on the computing power demand of the service request characterized by the feature vector and the node's computing power score can dynamically match the service computing power demand, avoiding insufficient resource utilization or overload. Furthermore, the node's computing power score is determined based on one or more of the load information, performance information, and fault information, rather than relying on historical data for prediction, which can cope with sudden traffic surges and dynamic changes in node status. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in 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 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 flowchart illustrating the resource scheduling method provided in the embodiments of this application.

[0019] Figure 2 This is one of the schematic diagrams of the resource scheduling strategy optimization process provided in the embodiments of this application.

[0020] Figure 3 This is the second schematic diagram of the resource scheduling strategy optimization process provided in the embodiments of this application.

[0021] Figure 4 This is a schematic diagram of the resource scheduling device provided in the embodiments of this application.

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

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

[0024] It should be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and regulations of the locality and with authorization from the owner of the relevant device.

[0025] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0026] Reference Figure 1 This application provides a resource scheduling method applicable to scenarios such as dynamic content acceleration and edge computing. The method is implemented based on the scheduling center of a content delivery network, upgrading the algorithm logic of existing scheduling decision modules to support intelligent scheduling in multiple fault scenarios, effectively improving the stability of business services. Specifically, the resource scheduling method may include steps S100-S300.

[0027] Step S100: Receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level, and service weight factor of the service request.

[0028] A business request is used to characterize a request initiated by a business user for at least one type of content distribution service. The request encapsulates a type identifier for the content distribution service, which is used to determine the feature vector of the business request. Content distribution services may include video transcoding, file downloading, and API responses, among others.

[0029] Business processing complexity is used to characterize and measure the actual demand of the content distribution business on node computing power (i.e. computing power) during the processing.

[0030] Service quality ratings are used to characterize the service quality required for content distribution services, such as response latency, packet loss rate, etc.

[0031] The business weight factor is used to characterize the elastic weight between the priority of the comprehensive content distribution business and resource consumption, so that the scheduling center can comprehensively consider the importance of the content distribution business and the resource consumption of nodes when allocating resources.

[0032] Optionally, the feature vector is a triple vector constructed based on business processing complexity, service quality level, and business weight factor. Correspondingly, in this embodiment, a triple quantization model is set as C=(Tp,Qc,Wt), where C represents the triple quantization model, Tp represents business processing complexity, Qc represents service quality level, and Wt represents business weight factor. The input of the triple quantization model is the business request, and the output is the feature vector of the business request.

[0033] It should be understood that traditional resource scheduling methods mostly rely on CPU utilization to measure computing power demand, which cannot fully reflect the actual situation of the business. For example, a business request may have low CPU utilization at a certain moment, but due to its high processing complexity and high service quality requirements, its actual computing power demand is very high. The embodiments of this application use a triplet quantization model to more accurately assess the computing power demand of the business, achieve precise allocation of resources, improve resource utilization, and avoid business performance degradation caused by unreasonable resource allocation.

[0034] Step S200: Obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score.

[0035] The nodes include edge nodes and core nodes. This application embodiment does not limit the number of nodes. The scheduling center obtains one or more of the load information, performance information and fault information of the registered nodes. The more types of information obtained, the more accurate the computing power score. This application embodiment uses the acquisition of node load information, performance information and fault information as an example for illustration.

[0036] Load information reflects the real-time load of a node based on its CPU utilization.

[0037] Performance information reflects the computing power of a node based on its hardware performance.

[0038] Fault information is used to measure whether a node fails within a preset time and the extent to which the failure affects the node’s current computing power.

[0039] Step S300: Based on the feature vector and the computing power score, determine the resource scheduling strategy for the service request.

[0040] Feature vectors are used to measure the actual computing power required by a node for a business request, while computing power scores are used to measure the real-time computing power of a node. By matching feature vectors and computing power scores, the target node for processing business requests can be determined. Correspondingly, resource scheduling strategies are used to characterize the scheme of allocating business requests to the target node.

[0041] Optionally, load information, performance information, and fault information of nodes can be obtained based on different time granularities to enable real-time monitoring of node status and long-term performance evaluation, thereby optimizing resource scheduling strategies.

[0042] Understandably, this application uses feature vectors to characterize the business processing complexity, service quality level, and business weight factor of business requests, measuring the computing power requirements of business requests from multiple perspectives. This can improve the accuracy of computing power requirement assessment. Based on the computing power requirements of business requests characterized by feature vectors and the computing power scores of nodes, resource scheduling strategies are determined, which can dynamically match business computing power requirements and avoid insufficient resource utilization or overload. In addition, the computing power scores of nodes are determined based on one or more of load information, performance information, and fault information, rather than relying on historical data for prediction, which can cope with sudden traffic and dynamic changes in node status.

[0043] As one embodiment, receiving a service request and determining the feature vector of the service request includes: Receive the service request and determine the type identifier of the service request; Based on the type identifier, the business processing complexity, the service quality level, and the business weight factor are determined respectively. The feature vector is determined based on the business processing complexity, the service quality level, and the business weight factor.

[0044] Optionally, receiving the business request and determining the type identifier of the business request specifically means receiving the business request, parsing the business request, and extracting the type identifier from a specific field in the request header of the business request.

[0045] For example, the business request is encapsulated based on the Hypertext Transfer Protocol (HTTP). After receiving the business request, the scheduling center parses the X-CDN-Feature field in the HTTP request header and extracts the type identifier. The type identifier is used to characterize which type of business the business request is for, such as video transcoding, file download, or dynamic API response.

[0046] Optionally, the dispatch center pre-establishes a business feature library, a service quality level library, and a business weight factor library. The business feature library contains the baseline instruction cycle count for services corresponding to different type identifiers. The service quality level library contains the service quality level required for services corresponding to different type identifiers. The business weight factor library contains the weight factors for services corresponding to different type identifiers. Correspondingly, based on the type identifier, the business processing complexity, the service quality level, and the business weight factor are determined, including filtering the corresponding baseline instruction cycle count, service quality level, and weight factor from the business feature library, service quality level library, and business weight factor library respectively based on the type identifier to determine the business processing complexity, service quality level, and business weight factor.

[0047] Determining the feature vector based on the business processing complexity, the service quality level, and the business weight factor includes combining the business processing complexity, the service quality level, and the business weight factor into a triple vector as the feature vector.

[0048] Understandably, this application determines the complexity of business processing, the quality of service level, and the business weight factor based on the type identifier of the business request. By measuring the actual computing power required by the business request from multiple dimensions, it accurately assesses the business computing power demand, achieves precise resource allocation, avoids resource waste or overload, and effectively improves resource utilization. For example, for complex video transcoding tasks, more computing power can be allocated based on its high business processing complexity value to ensure efficient execution of business requests.

[0049] As one embodiment, determining the business processing complexity, the service quality level, and the business weight factor based on the type identifier includes: The complexity of the business processing is determined based on the number of instruction cycles required to identify the type and the amount of data required to complete the business request. Based on the type identifier, the service quality level to which the service request belongs is obtained by filtering from a preset service quality level library; Based on the type identifier, the business weight factor to which the business request belongs is obtained by filtering from the preset business weight factor library.

[0050] Optionally, based on the type identifier, a baseline instruction cycle count for processing this type of business request is matched from the business feature library. The amount of data to be processed is determined based on the request content encapsulated in the business request. The business processing complexity is then calculated based on the baseline instruction cycle count and the amount of data to be processed. The formula for calculating the business processing complexity is as follows: ; in, Indicates the first k One instruction,n Number of instructions Indicates the first k The base instruction cycle number of the instruction. This indicates the amount of data that needs to be processed.

[0051] It should be understood that completing a CDN service request requires executing multiple CPU instructions. For example, a file download request triggers a series of complex micro-operations within a CDN node: from receiving network data packets, parsing the HTTP protocol, querying cache indexes, reading stored data, assembling response packets, to finally sending the request. Each of these steps requires one or more basic CPU instructions. The number of instructions varies depending on the type of service request.

[0052] Instruction cycle count refers to the minimum number of time units (clock cycles) required for a CPU to complete one instruction. It is a fundamental metric for measuring instruction execution speed and CPU efficiency. The number of cycles varies for different instructions—simple instructions (such as addition) may only require one cycle, while complex instructions (such as division) may require dozens of cycles. By analyzing the total number of instruction cycles for a specific task, the computational complexity and its true demand on CPU performance can be accurately assessed.

[0053] Instruction cycle count refers to the minimum number of time units (clock cycles) required for the CPU to complete one instruction. It is a fundamental indicator for measuring instruction execution speed and CPU efficiency. The number of cycles varies for different instructions—simple instructions may only require one cycle, while complex instructions may require dozens of cycles.

[0054] The baseline instruction cycle count can be understood as the baseline value of the number of instruction cycles required to complete the instruction.

[0055] Optionally, the service quality level library, or service level agreement (SLA) rule library, matches the service quality level to which different types of business requests belong.

[0056] For example, the service quality level library is shown in the table below: According to the service quality level database, the service quality level required for services such as live streaming is Q1. The specific service quality requirements include a response latency of less than or equal to 50ms, a packet loss rate of less than or equal to 0.01%, and a priority weight of 0.9.

[0057] Optionally, based on the type identifier, the business weight factor to which the business request belongs is obtained by filtering from a preset business weight factor library, including: determining the business attribute of the business request based on the type identifier, determining the business weight factor based on the business attribute, and the business weight factor library is used to represent the mapping relationship between the business attribute and the business weight factor.

[0058] For example, the business weight factor library is shown in the table below: It is understood that the embodiments of this application propose a scheme for determining business processing complexity, service quality level, and business weight factor. Business processing complexity accurately measures the actual computing power required for a business request, while service quality level and business weight factor can be used to implement priority control and elastic scaling mechanisms, ensuring that high-priority businesses receive resources first and meet the SLA requirements of different businesses. For example, high-QC level tasks such as live streaming can trigger preemptive scheduling to guarantee low latency and low packet loss rate.

[0059] As one embodiment, obtaining one or more of the node's load information, performance information, and fault information to determine the node's computing power score includes: Obtain the load information, the performance information, and the fault information; The computing power score is determined based on the load information, the performance information, and the fault information.

[0060] Optionally, load information, performance information, and fault information of a node can be obtained based on probes deployed on the node.

[0061] It is understood that the embodiments of this application determine the computing power score of a node by using load information, performance information and fault information, and accurately evaluate the real-time computing power of the node.

[0062] As one embodiment, determining the computing power score based on the load information, the performance information, and the fault information includes: Based on the node type, a first weight corresponding to the load information, a second weight corresponding to the performance information, and a third weight corresponding to the fault information are determined. The computing power score is determined based on the load information, the performance information, the fault information, the first weight, the second weight, and the third weight.

[0063] Optionally, node types include core nodes and edge nodes. The first weight can be represented as α, the second weight as β, and the third weight as γ. The initial weights corresponding to different node types are shown in the table below: Further optionally, the first weight, second weight, and third weight can be dynamically adjusted.

[0064] Optionally, the computing power score is determined based on the load information, the performance information, the fault information, the first weight, the second weight, and the third weight, including substituting the load information, the performance information, the fault information, the first weight, the second weight, and the third weight into the computing power score calculation formula to obtain the algorithm score.

[0065] The formula for calculating computing power score is as follows: ; in, Represents a node i exist t The computing power score at any given moment.

[0066] Represents a node i The load information, specifically... This is the average value of the real-time CPU utilization within a sliding window. By calculating the average CPU utilization within the sliding window, the real-time load of the node can be reflected more smoothly, avoiding the interference of instantaneous high or low load on the evaluation results.

[0067] The calculation formula is as follows: ; in, Represents a node i exist t Real-time CPU utilization at any given moment Represents a node i exist t-1 The mean of the sliding window at time points. The smoothing coefficient is determined based on grid search optimization.

[0068] Represents a node i The performance information, specifically the basic performance coefficient (benchmark score), reflects the node's hardware performance, which is influenced by factors such as CPU model, number of cores, and memory size. The value of is a fundamental indicator for measuring the computing power of a node.

[0069] The calculation formula is as follows: ; Among them, CPU performance represents the quantified value of the node's CPU performance, memory bandwidth represents the quantified value of the node's memory bandwidth, and disk I / O represents the quantified value of the node's disk I / O performance.

[0070] Represents a node i The fault information is used to measure whether a node has recently experienced a fault and the extent of that fault's impact on current computing power. Over time, the impact of a fault on a node's computing power gradually decreases, manifesting as exponential decay.

[0071] The calculation formula is as follows: ; The difference between the current time and the last fault time is in minutes, and 60 is also in minutes.

[0072] For example, if a node fails within the last 5 minutes, such as a packet loss rate greater than 5% for 30 consecutive seconds, then... =5.

[0073] Optionally, the weights α, β, and γ can be dynamically adjusted based on the node type. For example, for edge nodes, since they focus more on real-time responsiveness, the weight of α can be appropriately increased; while for core nodes, which may focus more on their basic performance, the weight of β can be increased accordingly.

[0074] It is understood that this application comprehensively considers the real-time load, basic performance, and fault conditions of nodes, and determines the first weight corresponding to the load information, the second weight corresponding to the performance information, and the third weight corresponding to the fault information based on the node type. This can accurately assess the real-time computing power of nodes and provide a reliable basis for resource scheduling.

[0075] As one embodiment, determining the resource scheduling strategy for the service request based on the feature vector and the computing power score includes: Based on the computing power score, candidate nodes are determined; Based on the feature vector and the computing power score, the matching score of the candidate node is determined; The candidate nodes are sorted based on the matching score to determine the target node, and the resource scheduling strategy is determined based on the target node.

[0076] Optionally, nodes with computing power scores greater than or equal to a score threshold are selected as candidate nodes, while those with scores less than the threshold (e.g., ...) are selected as candidate nodes. Nodes with a value of <0.5 trigger business migration, enabling initial screening of nodes.

[0077] Optionally, the formula for calculating the matching score is as follows: ; in, The score represents the matching score, and λ1, λ2, and λ3 represent dynamic weighting coefficients, which can be configured based on the business type.

[0078] Sort the candidate nodes based on the matching score, including sorting the candidate nodes in descending order based on the matching score, so as to achieve fine screening of the nodes.

[0079] Resource scheduling policies are used to represent the scheduling of business requests to target nodes. When concurrent business requests are received, resource scheduling policies are used to represent the scheduling of each business request to its corresponding target node.

[0080] Optionally, if the computing power scores of all candidate nodes are lower than the emergency score threshold (e.g., 0.6), resources are allocated from the emergency resource pool, which is a set of backup node resources reserved in advance to cope with sudden traffic and failure scenarios.

[0081] Understandably, this application proposes a hierarchical scheduling decision. Specifically, it first performs preliminary screening based on computing power scores, then performs fine screening based on feature vectors and computing power scores, and finally implements emergency scheduling based on an emergency resource pool to optimize resource allocation.

[0082] As an example, the resource scheduling method provided in this application further includes the following steps: The load information of the node is obtained based on the first time granularity; The performance and fault information of the node are obtained based on the second time granularity. Based on the load information, optimize the resource scheduling strategy, and / or, based on the performance information and the fault information, optimize the resource scheduling strategy; Wherein, the first time granularity is smaller than the second time granularity.

[0083] Optionally, the load information of the node can be obtained at the first-time granularity, including short-cycle collection of node load, temperature, and other hardware indicators. Hardware indicators can quickly reflect the current operating status of the node. For example, excessive node load may lead to a decrease in computing power, and excessive temperature may trigger hardware protection mechanisms and reduce CPU performance. By collecting and feeding back hardware indicators in a short period of time, node hardware problems can be detected in a timely manner and corresponding measures can be taken, such as adjusting service allocation and activating heat dissipation equipment.

[0084] Optionally, performance and fault information of the node can be obtained based on a second time granularity, including long-term collection of historical business execution success rate, latency compliance rate, and other information. This information can macroscopically reflect the overall performance of the node over a period of time. For example, if a node has a low business execution success rate and a low latency compliance rate over a period of time, it indicates that the node may have potential problems and requires further investigation and optimization.

[0085] Optionally, the first time granularity is seconds, and the second time granularity is minutes.

[0086] Understandably, this application proposes a dual-channel strategy optimization mechanism with different time granularities. The first time-granularity strategy optimization mechanism (second-level strategy optimization mechanism) is mainly used for real-time monitoring of the node's hardware status. When an anomaly is detected, it immediately triggers an early warning and takes preliminary emergency measures, such as temporarily transferring some tasks corresponding to business requests to other nodes. The second time-granularity strategy optimization mechanism (minute-level strategy optimization mechanism) is used to evaluate and analyze the long-term performance of the node, and adjust the node's resource allocation strategy and task scheduling priority based on the evaluation results. In practical applications, the data from the second-level strategy optimization mechanism can serve as a supplement and verification to the minute-level strategy optimization mechanism, and the results of the minute-level strategy optimization mechanism can guide the parameter settings and emergency strategy formulation of the second-level strategy optimization mechanism. For example, when the minute-level strategy optimization mechanism finds that the task execution success rate of a certain node is continuously declining, the monitoring of that node can be strengthened in the second-level strategy optimization mechanism, shortening the monitoring cycle and promptly identifying and resolving potential problems.

[0087] As one embodiment, optimizing the resource scheduling strategy based on the load information, and / or optimizing the resource scheduling strategy based on the performance information and the fault information, includes: Based on the load information, anomaly detection is performed on the node; if an anomaly is detected in the node, migration processing is performed on the node; and / or Based on the performance information and the fault information, a performance trend detection is performed to obtain the performance trend detection result, and the weight required for the computing power score in the calculation process is adjusted based on the performance trend detection result.

[0088] Reference Figure 2 In the second-level strategy optimization mechanism, the agent program deployed on the node collects second-level data of indicators such as CPU utilization, memory usage and network card temperature. For example, the collection time granularity of CPU utilization is 1 second, the collection time granularity of memory usage is 2 seconds, and the collection time granularity of network packet loss rate is 500ms.

[0089] Among them, CPU utilization can be the average value of a 5-second sliding window, memory usage can represent the current percentage of idle memory, and network card temperature can be read from node hardware sensor data using the Intelligent Platform Management Interface (IPMI).

[0090] Anomaly detection is performed on the nodes based on the load information. If an anomaly is detected in a node, migration processing is initiated. The CPU utilization and memory usage in the load information are compared with thresholds. If the threshold is exceeded multiple times, the node is determined to be an anomaly, and migration processing is performed. For example, if the CPU utilization of a node exceeds 85% for three consecutive times, hot migration is triggered.

[0091] In other embodiments, the parameters of the node and the computing power score of the node can also be adjusted based on the network card temperature of the load information. For example, if the network card temperature exceeds 75°C, dynamic frequency reduction (CPU frequency reduced by 20%) is initiated, and the computing power score is adjusted at the same time.

[0092] Reference Figure 3 In the minute-level strategy optimization mechanism, the agent program deployed on the node collects minute-level task success rate, latency compliance rate, resource utilization rate and fault information, such as the task success rate of a 5-minute window and the latency compliance rate of the rolling 10-minute average, to perform performance trend detection on the node, that is, to determine whether the node's performance trend is an optimization trend or a deterioration trend.

[0093] For example, if the latency compliance rate of a certain type of business request executed by a certain node is consistently below 90%, the priority weight of that type of business request in the scheduling decision will be increased, for example, Qc+0.1. If the resource utilization (CPU / memory / bandwidth utilization, etc.) of a certain node is consistently below 40%, the load weight of that node will be reduced, for example, α will be reduced to 0.7. For example, if the task failure rate of a certain node in the last 5 minutes is > 5%, the first weight of that node will be reduced to 0.8, while the second weight of that node will be increased to 1.2.

[0094] Optionally, this application adjusts the computing power score of nodes in real time based on second-level data, and generates a strategy optimization report daily based on minute-level data to update the weight coefficients.

[0095] Understandably, this application combines second-level and minute-level dual-channel optimization mechanisms to achieve real-time monitoring and long-term performance evaluation of node status, thereby optimizing scheduling strategies, avoiding resource over-configuration or waste, and reducing hardware procurement and maintenance costs. For example, through real-time monitoring and dynamic adjustment, unnecessary server idleness can be reduced, and the overall utilization rate of the server cluster can be improved. The resource scheduling apparatus provided in the embodiments of this application is described below. The resource scheduling apparatus described below can be referred to in correspondence with the resource scheduling method described above.

[0096] Reference Figure 4 This application provides a resource scheduling device, including: The first determining module 10 is used to receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level and service weight factor of the service request. The second determining module 20 is used to obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score. The third determining module 30 is used to determine the resource scheduling strategy for the service request based on the feature vector and the computing power score.

[0097] As an example, the first determining module 10 is further configured to: Receive the service request and determine the type identifier of the service request; Based on the type identifier, the business processing complexity, the service quality level, and the business weight factor are determined respectively. The feature vector is determined based on the business processing complexity, the service quality level, and the business weight factor.

[0098] As an example, the first determining module 10 is further configured to: The complexity of the business processing is determined based on the number of instruction cycles required to identify the type and the amount of data required to complete the business request. Based on the type identifier, the service quality level to which the service request belongs is obtained by filtering from a preset service quality level library; Based on the type identifier, the business weight factor to which the business request belongs is obtained by filtering from the preset business weight factor library.

[0099] As one embodiment, the second determining module 20 is further configured to: Obtain the load information, the performance information, and the fault information; The computing power score is determined based on the load information, the performance information, and the fault information.

[0100] As one embodiment, the second determining module 20 is further configured to: Based on the node type, a first weight corresponding to the load information, a second weight corresponding to the performance information, and a third weight corresponding to the fault information are determined. The computing power score is determined based on the load information, the performance information, the fault information, the first weight, the second weight, and the third weight.

[0101] As one embodiment, the third determining module 30 is further configured to: Based on the computing power score, candidate nodes are determined; Based on the feature vector and the computing power score, the matching score of the candidate node is determined; The candidate nodes are sorted based on the matching score to determine the target node, and the resource scheduling strategy is determined based on the target node.

[0102] As one embodiment, it also includes: An optimization module is configured to acquire the load information of the node based on a first time granularity; acquire the performance information and fault information of the node based on a second time granularity; optimize the resource scheduling strategy based on the load information; and / or optimize the resource scheduling strategy based on the performance information and the fault information; wherein the first time granularity is smaller than the second time granularity.

[0103] As one embodiment, the optimization module is further configured to: Based on the load information, anomaly detection is performed on the node; if an anomaly is detected in the node, migration processing is performed on the node; and / or Based on the performance information and the fault information, a performance trend detection is performed to obtain the performance trend detection result, and the weight required for the computing power score in the calculation process is adjusted based on the performance trend detection result.

[0104] Figure 5 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 5 As shown, the electronic device may include: a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other via the communication bus 540. The processor 510 can call a computer program in the memory 530 to execute the steps of a resource scheduling method, including: Receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level and service weight factor of the service request. Obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score; Based on the feature vector and the computing power score, the resource scheduling strategy for the service request is determined.

[0105] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the resource scheduling method provided in the above embodiments, including: Receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level and service weight factor of the service request. Obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score; Based on the feature vector and the computing power score, the resource scheduling strategy for the service request is determined.

[0107] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to perform the steps of the methods provided in the above embodiments, including: Receive a service request and determine the feature vector of the service request. The feature vector is used to characterize the service processing complexity, service quality level and service weight factor of the service request. Obtain one or more of the node's load information, performance information, and fault information to determine the node's computing power score; Based on the feature vector and the computing power score, the resource scheduling strategy for the service request is determined.

[0108] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0109] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0110] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0111] Finally, it should be noted that the above 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 resource scheduling method, characterized in that, The method comprises: receiving a service request, determining a feature vector of the service request, the feature vector being used to represent a service processing complexity, a service quality level and a service weight factor of the service request; obtaining one or more of load information, performance information and fault information of a node to determine a computing power score of the node; determining a resource scheduling strategy of the service request based on the feature vector and the computing power score.

2. The method of claim 1, wherein, The receiving of the service request and the determination of the feature vector of the service request comprise: receiving the service request and determining a type identifier of the service request; determining the service processing complexity, the service quality level and the service weight factor based on the type identifier, respectively; determining the feature vector based on the service processing complexity, the service quality level and the service weight factor.

3. The method of claim 2, wherein, The determination of the service processing complexity, the service quality level and the service weight factor based on the type identifier comprises: determining the service processing complexity based on the number of instruction cycles required by the type identifier and the amount of data required to process the service request; filtering the service quality level to which the service request belongs from a preset service quality level library based on the type identifier; filtering the service weight factor to which the service request belongs from a preset service weight factor library based on the type identifier.

4. The method of claim 1, wherein, The obtaining of one or more of the load information, the performance information and the fault information of the node to determine the computing power score of the node comprises: obtaining the load information, the performance information and the fault information; determining the computing power score based on the load information, the performance information and the fault information.

5. The method of claim 4, wherein, The determination of the computing power score based on the load information, the performance information and the fault information comprises: determining a first weight corresponding to the load information, a second weight corresponding to the performance information and a third weight corresponding to the fault information based on the type of the node; determining the computing power score based on the load information, the performance information, the fault information, the first weight, the second weight and the third weight.

6. The method of claim 1, wherein, The determination of the resource scheduling strategy of the service request based on the feature vector and the computing power score comprises: determining a candidate node based on the computing power score; determining a matching score of the candidate node based on the feature vector and the computing power score; sorting the candidate nodes based on the matching score to determine a target node, and determining the resource scheduling strategy based on the target node.

7. The method of claim 1 to 6, wherein, Further comprising: obtaining the load information of the node based on a first time granularity; obtaining the performance information and the fault information of the node based on a second time granularity; optimizing the resource scheduling strategy based on the load information, and / or optimizing the resource scheduling strategy based on the performance information and the fault information; wherein the first time granularity is smaller than the second time granularity.

8. The method of claim 7, wherein, The optimization of the resource scheduling strategy based on the load information, and / or the optimization of the resource scheduling strategy based on the performance information and the fault information comprises: performing abnormality detection on the node based on the load information, and performing migration processing on the node if it is determined that the node has an abnormality; and / or performing performance trend detection based on the performance information and the fault information to obtain a performance trend detection result, and adjusting a weight required in the calculation process of the computing power score based on the performance trend detection result.

9. A resource scheduling apparatus, characterized by comprising: comprise: a first determination module configured to receive a service request, and determine a feature vector of the service request, the feature vector being used to represent a service processing complexity, a service quality level and a service weight factor of the service request; a second determination module configured to obtain one or more of load information, performance information and fault information of a node, to determine a computing power score of the node; a third determination module configured to determine a resource scheduling strategy of the service request based on the feature vector and the computing power score.

10. An electronic device comprising a processor and a memory having a computer program stored therein, characterized in that, The processor executes the computer program to implement the steps of the resource scheduling method in any one of claims 1 to 8.

11. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the resource scheduling method in any one of claims 1 to 8.

12. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the resource scheduling method in any one of claims 1 to 8.

Images