Request processing method and device, electronic equipment and storage medium

Abstract

The invention provides a request processing method and device, electronic equipment and a storage medium, and relates to the technical field of artificial intelligence and cloud computing, in particular to the technical field of a content delivery network (CDN) and the like. According to the scheme, in response to a received to-be-processed service request sent by a client and the to-be-processed service request is scheduled to a first target edge node, an actual bandwidth and a target bandwidth of the first target edge node in a current time period are obtained; in response to the fact that the actual bandwidth is larger than the target bandwidth, determining a second target edge node from at least one non-overload candidate edge node according to a traffic scheduling strategy which aims at minimizing the scheduling cost and meets the traffic scheduling requirement in the current time period; according to the IP address of the second target edge node, redirecting the to-be-processed service request to the second target edge node, and receiving a first target response generated by the second target edge node in response to the to-be-processed service request; and sending the first target response to the client.

Description

Technical Field

[0001] This disclosure relates to the fields of artificial intelligence and cloud computing, specifically to the fields of content delivery networks (CDNs), and particularly to a request processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the continuous expansion of the internet and the evolution of business models, users are placing increasingly stringent demands on the responsiveness, availability, and consistency of network services. Content Delivery Networks (CDNs), as the core infrastructure supporting high-concurrency access on the modern internet, are widely deployed at edge nodes around the world. Their aim is to push computing and storage capabilities down to the network edge, closer to users, thereby reducing transmission latency, improving service efficiency, and enhancing system robustness. In this architecture, each service request initiated by a user (webpage loading or video playback) is typically directed by a scheduling system to a specific edge node for processing. Due to the highly dynamic and spatiotemporally uneven nature of service traffic, the load levels carried by different edge nodes vary significantly at different times. Therefore, in a large-scale distributed network environment, efficient and reliable processing of user requests is crucial. Summary of the Invention

[0003] This disclosure provides a request processing method, apparatus, electronic device, and storage medium.

[0004] According to one aspect of this disclosure, a request processing method is provided, comprising: In response to receiving a pending service request sent by a client and the pending service request being scheduled to a first target edge node, the actual bandwidth and target bandwidth of the first target edge node in the current time period are obtained; In response to the actual bandwidth being greater than the target bandwidth, a second target edge node is determined from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements within the current time period; wherein the traffic scheduling requirements are determined based on the traffic demand values ​​of each service in the current time period. Based on the IP address of the second target edge node, the pending service request is redirected to the second target edge node, and the first target response generated by the second target edge node in response to the pending service request is received; Send the first target response to the client.

[0005] According to another aspect of this disclosure, a request processing apparatus is provided, comprising: The first acquisition module is used to, in response to receiving a pending service request sent by a client and the pending service request being scheduled to a first target edge node, acquire the actual bandwidth and target bandwidth of the first target edge node in the current time period; A first determining module is configured to, in response to the actual bandwidth being greater than the target bandwidth, determine a second target edge node from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements within the current time period; wherein the traffic scheduling requirements are determined based on the traffic demand values ​​of each service in the current time period. The processing module is configured to redirect the pending service request to the second target edge node according to the IP address of the second target edge node, and receive the first target response generated by the second target edge node in response to the pending service request; The sending module is used to send the first target response to the client.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method proposed in one aspect of this disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described in the foregoing aspect of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method proposed in the foregoing aspect of this disclosure.

[0009] The request processing method of this disclosure, after a pending service request arrives at an edge node, obtains in real time its actual bandwidth and preset target bandwidth for the current time period. This enables the system to identify the first target edge node that is already overloaded (i.e., its actual bandwidth exceeds the target bandwidth) in the first instance. Then, based on a strategy that aims to minimize scheduling costs while meeting the traffic scheduling needs of various services in the current time period, a second target edge node is accurately determined from multiple unloaded candidate edge nodes. The pending service request is then accurately redirected based on the IP address of the second target edge node. This not only effectively avoids service delays or failures caused by local node resource overload but also ensures that high-cost, low-quality paths are not misused. Finally, the client can obtain a response generated by the second target edge node, thereby improving the resource utilization efficiency, system stability, and scheduling intelligence level of the entire content delivery network while ensuring the continuity of user experience.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating the request processing method provided in Embodiment 1 of this disclosure; Figure 2 This is a flowchart illustrating the request processing method provided in Embodiment 2 of this disclosure; Figure 3 This is a flowchart illustrating the request processing method provided in Embodiment 3 of this disclosure; Figure 4 This is a schematic diagram of the scheduling system provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the network flow model provided in the embodiments of this disclosure; Figure 6 This is a schematic diagram of the request processing apparatus provided in Embodiment 4 of this disclosure; Figure 7 A schematic block diagram of an example electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the technical solution disclosed herein are all carried out with the consent of the user, and all comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0014] CDN distributes content from the origin server to edge acceleration nodes around the world. When a user makes a request for website resources, the request is routed to the edge acceleration node closest to the user, and the edge acceleration node directly responds to the content required by the user, improving the response speed of the user's access to website resources.

[0015] The CDN scheduling system is a core component of the CDN system. It uses various scheduling strategies to direct all requests for a client's domain to appropriate target edge nodes, thereby achieving traffic control, quality control, cost control, and fault handling. 302 scheduling (HTTP...) 302 redirect scheduling, as a traditional CDN scheduling method, requires all user requests to first access the 302 policy center. The policy center returns the appropriate target acceleration node IP address according to the scheduling policy, and the user request then performs a 302 redirect based on the returned target IP. The scheduling policy typically only implements disaster recovery scheduling, i.e., when a node is fully utilized or has quality issues, business traffic is switched off to avoid impacting business quality. However, since all user requests must request a 302 redirect from the 302 policy center, it increases the latency of the first request packet, impacting business quality. Furthermore, due to limitations in node and business traffic collection latency, the scheduling policy is generally updated every few minutes, which cannot cope with the cost and quality impact caused by second-level traffic surges leading to node overload. If the business traffic data on which the scheduling policy relies is based on user access logs from edge nodes, it needs to be parsed from the edge nodes and then aggregated and calculated at the center. This involves large data volumes and long links, with collection latency typically exceeding 5 minutes. In addition, the scheduling policy cannot simultaneously consider cost and quality, only performing single-objective optimization or locally optimal strategies, such as only implementing passive disaster recovery scheduling without proactive cost optimization.

[0016] In view of at least one of the above-mentioned problems, this disclosure provides a request processing method, apparatus, electronic device and storage medium.

[0017] The request processing method, apparatus, electronic device, and storage medium of this disclosure are described below with reference to the accompanying drawings.

[0018] Figure 1 This is a flowchart illustrating the request processing method provided in Embodiment 1 of this disclosure.

[0019] This disclosure illustrates an example where the request processing method is configured in a request processing device, which can be applied to any electronic device to enable the electronic device to perform request processing functions.

[0020] Among them, electronic devices can be any device with computing capabilities, such as computers, mobile terminals, servers, etc. Mobile terminals can be hardware devices with various operating systems, touch screens and / or displays, such as in-vehicle devices, mobile phones, tablets, personal digital assistants, wearable devices, etc.

[0021] like Figure 1 As shown, the request processing method may include the following steps: Step 101: In response to receiving a pending service request sent by the client and the pending service request being scheduled to the first target edge node, obtain the actual bandwidth and target bandwidth of the first target edge node in the current time period.

[0022] To achieve real-time perception and accurate judgment of the load status of edge nodes, one possible approach is that when a user initiates a business request (such as accessing a webpage or loading a video), the request usually first passes through DNS or other upper-layer scheduling systems and is initially assigned to an edge node with better geographical location or network conditions (i.e., the first target edge node). The system does not immediately have the request processed directly by that node. Instead, it obtains the bandwidth of that node during the current scheduling period, i.e., the actual observed outbound bandwidth of the external network (i.e., the actual bandwidth) and the node's preset target bandwidth. Thus, based on the actual bandwidth and target bandwidth of the first target edge node, the system can quickly assess whether the current node still has the ability to provide high-quality service before the business request is actually processed.

[0023] Step 102: In response to the actual bandwidth being greater than the target bandwidth, a second target edge node is determined from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements in the current time period.

[0024] The traffic scheduling requirement is determined based on the traffic demand of each service during the current time period.

[0025] To achieve optimal scheduling decisions that balance global efficiency and local quality when nodes are overloaded, one possible approach is to select a second target edge node from multiple unloaded candidate edge nodes when the actual bandwidth of the first target edge node exceeds its target bandwidth. Instead of directly processing requests by that node, the system selects the node with the lowest scheduling cost from all unloaded candidate edge nodes based on a traffic scheduling strategy that aims to minimize scheduling costs while meeting the traffic scheduling requirements of the current time period.

[0026] It should be noted that the goal of this traffic scheduling strategy is to minimize the overall scheduling cost (such as cross-provincial transmission cost, over-limit penalties, regional priority, etc.) while meeting the total traffic demand of all current services across the network. In order to ensure that traffic scheduling meets the actual business load, the traffic scheduling demand in the current time period is dynamically calculated based on the real-time request quantity and average file size of each service.

[0027] Step 103: Based on the IP address of the second target edge node, redirect the pending service request to the second target edge node, and receive the first target response generated by the second target edge node in response to the pending service request.

[0028] To improve service reliability and continuity, after determining the optimal second target edge node, the system uses the standard HTTP 302 temporary redirect mechanism to return a Location header containing the node's IP address (or domain name) to the client. The client browser or SDK automatically initiates a new round of requests to this new address. Upon receiving the request, the second target edge node, being in an unloaded state, can efficiently complete content processing and generate a normal business response (i.e., the first target response).

[0029] Step 104: Send the first target response to the client.

[0030] To achieve high-quality service interaction without the user's awareness, one possible approach is to return the first target response generated by the second target edge node to the client.

[0031] The request processing method of this disclosure, after a pending service request arrives at an edge node, obtains in real time its actual bandwidth and preset target bandwidth for the current time period. This enables the system to identify the first target edge node that is already overloaded (i.e., its actual bandwidth exceeds the target bandwidth) in the first instance. Then, based on a strategy that aims to minimize scheduling costs while meeting the traffic scheduling needs of various services in the current time period, a second target edge node is accurately determined from multiple unloaded candidate edge nodes. The pending service request is then accurately redirected based on the IP address of the second target edge node. This not only effectively avoids service delays or failures caused by local node resource overruns but also ensures a better balance between cost and service quality in the overall network traffic allocation. Finally, the client can obtain a response generated by the second target edge node, thereby improving the resource utilization efficiency, system stability, and scheduling intelligence level of the entire content delivery network while ensuring the continuity of user experience.

[0032] To clearly illustrate how the second target edge node is determined from at least one unloaded candidate edge node according to a traffic scheduling strategy aimed at minimizing scheduling costs and meeting the traffic scheduling requirements in the current time period in the above embodiments, this disclosure proposes another request processing method.

[0033] Figure 2 This is a flowchart illustrating the request processing method provided in Embodiment 2 of this disclosure.

[0034] Step 201: In response to receiving a pending service request sent by the client and the pending service request being scheduled to the first target edge node, obtain the actual bandwidth and target bandwidth of the first target edge node in the current time period.

[0035] Step 202: Obtain the schedulable traffic quota for each candidate edge node as indicated by the traffic scheduling policy.

[0036] To assess the scheduling capabilities of candidate edge nodes, as a possible approach, when a redirection is triggered, the system calculates the schedulable traffic quota based on the traffic scheduling strategy generated under the minimum scheduling cost, combined with the real-time bandwidth usage of each candidate edge node. The schedulable traffic quota represents the maximum amount of additional traffic that can be accepted at present. The schedulable traffic quota comprehensively considers multiple constraints such as the node's target bandwidth, remaining capacity, regional priority, and scheduling cost.

[0037] It should be noted that the traffic scheduling strategy is generated using the following steps: (1) Obtain the network flow model; wherein, the network flow model includes multiple network flow nodes and directed edges connecting the multiple network flow nodes, and the direction of the directed edges is used to indicate the transmission direction of traffic during the scheduling process; To achieve a structured representation of the traffic scheduling problem, one possible approach is to first obtain a network flow model, which consists of multiple network flow nodes (such as source nodes, business domain name nodes, edge nodes, sink nodes, etc.) and directed edges connecting these nodes; where the direction of each directed edge indicates the logical transmission path of traffic from upstream to downstream during the scheduling process (e.g., from business demand to edge resources).

[0038] When creating a network flow model, multiple layers of network flow nodes can be created first. These layers include at least a traffic ingress layer, a domain name layer, a node layer, and a traffic egress layer arranged in sequence. The traffic ingress layer represents the entry point of service traffic, the domain name layer indicates the service domain name associated with the service traffic, the node layer indicates the edge node carrying the service traffic, and the traffic egress layer indicates the exit point of the service traffic. Directed edges are established between network flow nodes in adjacent layers. Each directed edge includes a capacity limit and a unit traffic cost. The capacity limit indicates the maximum traffic value allowed through the directed edge, and the unit traffic cost indicates the scheduling cost introduced per unit of traffic on the directed edge. The network flow nodes and directed edges are combined to generate the network flow model.

[0039] It should be noted that when establishing directed edges between network flow nodes at adjacent levels across multiple layers, a first directed edge is established between the source node and each domain name node. The unit traffic cost of the first directed edge is a predetermined cost, indicating that there is no scheduling cost from the source node to the domain name layer where the domain name node resides. The capacity limit of the first directed edge is determined based on the traffic demand of the business domain name of the corresponding domain name node. A second directed edge is then constructed between each domain name node and each edge node. The second directed edge satisfies predetermined scheduling constraints, and its capacity limit is the value of the business domain name of the corresponding domain name node. Given a fixed traffic scheduling requirement, the unit traffic cost of the second directed edge is determined based on the scheduling priority of the service domain name. Two parallel third directed edges are established between each edge node and the sink. The capacity limit of one third directed edge is determined based on the target bandwidth allowed for the corresponding edge node in the current time period, and the unit traffic cost of the other third directed edge is a set cost. The capacity limit of the other third directed edge is determined based on the difference between the capacity limit of the corresponding edge node and the target bandwidth. The unit traffic cost of the other third directed edge is determined based on the scheduling priority of the corresponding edge node.

[0040] In other words, the source (S) is the starting point of traffic, the sink (T) is the ending point, and in between are the domain name layer (each node represents a business domain name) and the node layer (each node represents a CDN edge node). First, a first directed edge is established between the source node (S) and each domain name node. Its capacity limit (cap) is set to the traffic demand value of the domain name in the current time period (i.e., domain name traffic), and the unit traffic cost (cost) is set to 0, indicating that there is no scheduling cost from decomposing the total business demand to specific domain names. Second, based on actual scheduling constraints (such as regional affinity, service quality requirements, etc.), a second directed edge (i.e., an inline edge) is established between the domain name layer and the node layer. The second directed edge satisfies the set scheduling constraints, which include at least one of the following: the region where the edge node is located matches the target user region of the business domain name; the edge node supports the service type or protocol required by the business domain name; the current network quality of the edge node meets the service quality requirements of the business domain name; the edge node is in an available state and has not reached its capacity limit, etc. The capacity limit of the second directed edge is the traffic scheduling demand value of the business domain name of the corresponding domain name node, while the unit traffic cost is dynamically set according to the scheduling priority. For example, for quality-sensitive domain names, if priority scheduling to edge nodes in the same province is required, the edge cost to the node in the same province is set to a smaller value, while the edge cost to the node in another province is set to a smaller value. The value is set to a larger value to form a penalty, thereby guiding the optimization algorithm to prioritize high-priority paths. Finally, two parallel third directed edges (i.e., sink edges) are established between each edge node and the sink (T): the first edge is the expected billing edge, whose cap is equal to the target bandwidth of the node in the current time period (i.e., the expected billing value), and cost is 0, representing the resource range of low-cost and compliant use; the second edge is the capacity limit edge, whose cap is the difference between the physical capacity limit of the edge node and the target bandwidth, and cost is set according to the scheduling priority of the node in the over-limit scenario. For example, the cost is small for high-priority solutions and large for low-priority or penalized use scenarios. Thus, this model not only accurately expresses the business traffic demand and resource constraints, but also automatically realizes the comprehensive scheduling goal of prioritizing the full use of the target bandwidth, avoiding over-limit, and scheduling nearby in the process of solving the minimum cost flow, thereby generating the optimal traffic allocation strategy that takes into account service quality, resource efficiency, and operating costs.

[0041] (2) Based on the network flow constraints associated with multiple network flow nodes and multiple directed edges, generate flow constraints; wherein, the flow constraints are used to indicate that the allocated flow on each directed edge does not exceed the corresponding flow carrying capacity. Furthermore, based on the network flow constraints associated with each node and directed edge in the network flow model (such as the target bandwidth, link capacity, and billing threshold of edge nodes), a set of flow constraints is generated. Among them, the network flow constraints include at least one of the following: capacity constraint, flow conservation constraint, service demand constraint, and resource aggregation constraint. The capacity constraint is used to indicate that the allocated flow on each directed edge does not exceed the corresponding capacity limit. The flow conservation constraint is used to indicate that the total inflow flow to network flow nodes other than those located at the flow ingress layer and flow egress layer is equal to the total outflow flow. The service demand constraint is used to indicate that the flow from the flow ingress layer to each domain name node located at the domain name layer is equal to the flow demand value of the corresponding service domain name. The resource aggregation constraint is used to indicate that the total flow to each edge node is equal to the total flow from the corresponding edge node to the flow egress layer.

[0042] Therefore, by introducing capacity constraints, traffic conservation constraints, business demand constraints, and resource aggregation constraints, the system accurately maps the physical limitations and business logic in the actual scheduling scenario to the network flow model. This enables the traffic scheduling strategy generated based on the network flow model to not only meet the goal of minimizing global costs, but also to ensure feasibility, consistency, and executability under complex multi-service and multi-level CDN architectures, thereby significantly improving the accuracy of scheduling results, system stability, and resource utilization efficiency.

[0043] (3) Construct the objective function based on the flow constraints and minimizing the scheduling cost; To achieve globally cost-optimal scheduling while satisfying resource constraints, as a possible approach, a mathematical objective function is constructed by combining the aforementioned traffic constraints with the business objective of minimizing scheduling costs. The scheduling cost can be set differently based on factors such as regional priority, cross-network costs, and over-limit penalties, thereby guiding the optimization process to prioritize high-quality, low-cost scheduling paths.

[0044] (4) Based on the traffic scheduling requirements, solve the objective function to obtain the schedulable traffic quota of each candidate edge node, and generate the traffic scheduling strategy based on the schedulable traffic quota of each candidate edge node.

[0045] The objective function is solved by taking the traffic scheduling requirements of each service in the current time period (such as the total real-time bandwidth requirements of video, image, and other services) as input to obtain the schedulable traffic quota for each candidate edge node for a specific service. Subsequently, a complete traffic scheduling strategy is generated based on these quotas. This strategy not only satisfies the overall network demand and optimizes costs, but also provides a scheduling basis for edge nodes when processing individual requests.

[0046] Therefore, by constructing a network flow model containing multiple network flow nodes and directed edges, where the direction of each edge precisely describes the transmission path of traffic during the scheduling process, and based on the traffic constraints associated with nodes and edges, it is ensured that the allocated traffic on any directed edge does not exceed its corresponding traffic carrying capacity. Furthermore, by taking minimizing the scheduling cost as the objective function and using the traffic scheduling demand of each service in the current time period as the total inflow constraint, the objective function is solved. The resulting optimal solution not only satisfies all capacity and demand constraints, but also outputs a refined schedulable traffic quota for each candidate edge node, thereby generating a globally cost-optimal traffic scheduling strategy. This transforms the complex multi-node, multi-service resource allocation problem into a standard minimum cost flow problem, significantly improving the scheduling efficiency, resource utilization, and cost control capabilities of the content delivery network in high-concurrency, variable-load scenarios.

[0047] Step 203: Select a second target edge node from at least one candidate edge node based on the schedulable traffic quota of each candidate edge node.

[0048] To achieve precise node scheduling, one possible approach is to obtain the schedulable traffic quotas of multiple candidate edge nodes with the lowest scheduling costs, and then optimize the selection based on these quota values. For example, nodes with sufficient quotas can be selected as the second target edge nodes.

[0049] For example, assuming that the traffic demand of the business domain name live.example.com is 100 Gbps during the current time period, the scheduling strategy is generated by the minimum cost flow algorithm: the Beijing node (Node-BJ) is allocated 60 Gbps (i.e., the scheduled traffic quota is 60 Gbps, and the unit scheduling cost is 10), the Shanghai node (Node-SH) is allocated 30 Gbps (the unit scheduling cost is 30), and the Guangzhou node (Node-GZ) is allocated 10 Gbps (the unit scheduling cost is 80). The target bandwidths for each node are 60 Gbps, 50 Gbps, and 40 Gbps, respectively. At this time, a user located in Beijing initiates a request to live.example.com. DNS initially routes it to the first target edge node, Node-BJ. Upon receiving the request, the Nginx module of Node-BJ immediately queries its local 302 flow control module and finds that the current real-time bandwidth is 68 Gbps, while its target bandwidth is 60 Gbps. Since 68 > 60, Node-BJ is determined to be overloaded and a 302 redirect needs to be triggered. The 302 flow control module then, based on the issued traffic scheduling policy, filters out candidate nodes that are allowed by the traffic scheduling policy and are not currently overloaded: Node-SH has a real-time bandwidth of 42 Gbps (< target 50 Gbps), and is not overloaded; Node-GZ has a real-time bandwidth of 35 Gbps (< target 40 Gbps), and is not overloaded. Among Node-SH and Node-GZ, Node-SH... The unit scheduling cost of 30 is lower than the unit scheduling cost of 80 of Node-GZ, therefore the second target edge node is determined to be Node-SH.

[0050] Step 204: Based on the IP address of the second target edge node, redirect the pending service request to the second target edge node, and receive the first target response generated by the second target edge node in response to the pending service request.

[0051] Step 205: Send the first target response to the client.

[0052] It should be noted that the execution process of steps 201 and 204 to 205 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit this and will not elaborate further.

[0053] In summary, the second target edge node is selected based on the schedulable traffic quota of each candidate edge node indicated by the traffic scheduling strategy. This quota is the upper limit of traffic to be allocated, which is obtained by solving the traffic scheduling requirements of the current time period, node capacity constraints, and scheduling cost optimization objectives. Therefore, node selection based on schedulable traffic quota can ensure that the redirection decision is consistent with the global optimal scheduling intention, and avoid directing traffic to nodes that are not overloaded but have high scheduling costs. This effectively improves the accuracy of resource allocation and scheduling efficiency while ensuring system stability.

[0054] In any embodiment of this disclosure, when the actual bandwidth is less than or equal to the target bandwidth, the current edge node responds to the service request to be processed. The following describes the process in conjunction with... Figure 3 The embodiments are described in detail.

[0055] Figure 3 This is a flowchart illustrating the request processing method provided in Embodiment 3 of this disclosure.

[0056] like Figure 3 As shown, the request processing method may include the following steps: Step 301: In response to receiving a pending service request sent by the client and the pending service request being scheduled to the first target edge node, obtain the actual bandwidth and target bandwidth of the first target edge node in the current time period.

[0057] To avoid overload misjudgments or scheduling failures caused by bandwidth perception lag or rough estimation, one possible approach is to periodically collect and aggregate the network egress traffic of each service instance to obtain the actual bandwidth of the node.

[0058] As an example, in response to the arrival of a set period, the network egress traffic of each service instance in the first target edge node is collected; the network egress traffic of each service instance under the first target edge node is summed to obtain the actual bandwidth of the first target edge node.

[0059] In other words, the system triggers a data collection task every set period (e.g., every 5 seconds), traversing all service instances (such as multiple Nginx instances or business processes) deployed on the edge node, reading the real-time traffic data of their network egress direction, and then summing up the egress traffic values ​​scattered across each service instance to obtain the total actual bandwidth consumption of the edge node in the current period. This effectively avoids overload misjudgments caused by relying on rough estimates or global average indicators, provides a reliable basis for 302 flow control decisions, and significantly improves the accuracy of scheduling and system stability.

[0060] Step 302: In response to the actual bandwidth being greater than the target bandwidth, a second target edge node is determined from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements in the current time period.

[0061] The traffic scheduling requirement is determined based on the traffic demand of each service during the current time period.

[0062] To achieve precise scheduling of CDN edge node traffic, one possible approach is to define traffic scheduling requirements as the total amount of traffic resources that the entire CDN network needs to allocate to all services (e.g., different domain names or services) within the current scheduling period (e.g., every 5 seconds). The total traffic resources are derived from the sum of the traffic requirements of each service. The traffic requirements of each service are dynamically calculated based on real-time service request characteristics. For example, during the current scheduling period, the number of service requests (i.e., the number of requests received per unit time) for each service (e.g., the domain name live.example.com) is collected, and combined with the average request file size obtained from historical or real-time statistics for that service (e.g., an average of 2 MB of data returned per video request), the number of service requests is multiplied by the average request file size to accurately estimate the total network bandwidth required by that service in the current period, i.e., the traffic requirements of each service (e.g., 10,000 requests / second × 2 MB / request ≈ 160 Gbps).

[0063] Therefore, by converting user request behavior into bandwidth demand, the actual traffic pressure of each service at the current moment can be accurately determined, avoiding the deviation caused by relying on fixed thresholds or delayed predictions. This makes the determination of traffic scheduling demand more real-time and accurate, providing a reliable input for the subsequent generation of high-quality traffic scheduling strategies based on the minimum cost flow model. It enables the system to achieve accurate, efficient and low-cost allocation of edge node resources in the event of sudden traffic surges.

[0064] Step 303: Based on the IP address of the second target edge node, redirect the pending service request to the second target edge node, and receive the first target response generated by the second target edge node in response to the pending service request.

[0065] Step 304: Send the first target response to the client.

[0066] Step 305: In response to the actual bandwidth being less than or equal to the target bandwidth, receive the second target response generated by the first target edge node in response to the pending service request.

[0067] To achieve a low-latency, high-efficiency user service experience, one possible approach is to redirect user requests to the first target edge node after they are routed by DNS. If the node's real-time bandwidth is less than or equal to the target bandwidth (i.e., not overloaded), no redirection is necessary. In this case, the node directly processes the request through local services such as Nginx and generates a normal business response (e.g., returning a video stream or webpage content), which is the second target response. This indicates that the node is in a healthy state and can efficiently serve users.

[0068] Step 306: Send the second target response to the client.

[0069] To maximize the resource utilization of edge nodes, as one possible implementation, the first target edge node directly returns the business response (second target response) it generates to the client.

[0070] It should be noted that the execution process of steps 303 to 304 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit this and will not elaborate further.

[0071] In summary, when the actual bandwidth is less than or equal to the target bandwidth, the node can be determined to be in a healthy state with available resources and controllable service quality. The system does not need to trigger a 302 redirect, but directly receives the second target response generated by the node after processing the pending business request, and returns the second target response to the client. This avoids unnecessary redirection overhead and cross-node transmission delay, which not only significantly reduces the end-to-end response time of user requests, but also effectively improves the resource utilization efficiency of edge nodes.

[0072] In any of the above embodiments, such as Figure 4As shown, the request processing method of this disclosure embodiment can be applied to a scheduling system, wherein the scheduling system is, for example, a second-level edge 302 scheduling system. The second-level edge 302 scheduling system is mainly divided into a basic data source, a 302 policy center module, a 302 flow control module, an Nginx Web service module, and a traffic collection module. The basic data source provides the basic information required for system operation; the 302 policy center module is responsible for generating and distributing the globally optimal scheduling policy. The 302 policy center module includes: a data caching layer, a second-level data processing component, and a scheduling policy component. The data caching layer aggregates traffic reports and domain name request data from edge nodes and performs preprocessing; the second-level data processing component receives 2.2 node traffic and domain name traffic from edge nodes (once every 5 seconds) and performs aggregation analysis; the scheduling policy component generates a 3.2 scheduling policy (5 seconds). The system includes a schedulable traffic quota table; a 302 flow control module for traffic control and user request processing (receiving requests from Nginx, determining if the current node is overloaded, and if so, selecting a second target node according to the policy and returning a 302 redirect); traffic aggregation and reporting (aggregating traffic data from multiple service instances and reporting the summarized node traffic and domain traffic to the policy center); an Nginx Web service module for receiving and responding to user requests, serving as the entry and exit point for business traffic; and a traffic acquisition module for real-time monitoring and reporting of network exit traffic data from edge nodes.

[0073] To address the issue that traditional 302 scheduling requires all requests to the 302 policy center for a 302 redirect, user requests no longer directly access the 302 policy center. The user request flow is as follows: (1) User requests are scheduled to the edge node by DNS. After receiving the user request, the Nginx module of the edge node accesses the 302 flow control module inside the node to ask whether the request needs a 302. (2) The 302 flow control module decides whether the request needs to be redirected to 302 and the target node to be redirected based on the real-time bandwidth of the current node and the target bandwidth of the node given by the policy center. If the node's real-time bandwidth is greater than the target bandwidth, it means that the node is in an overrun state and a 302 redirect is required. The flow control module will find the target node that is not overrunning according to the scheduling policy and return the 302 target node. If the node's real-time bandwidth is less than the target bandwidth, it means that the node is not overrunning and there is no need to perform a 302 redirect. The Nginx on this node can directly provide web services.

[0074] To address the issue of traditional data centers being unable to handle second-level traffic surges that cause node traffic to exceed limits, the traffic collection solution has implemented a 5-second granularity for data collection latency. The specific node and business traffic collection process is as follows: (1) Node traffic collection: All web service machines on the edge nodes have deployed traffic collection modules. The network card external network traffic is collected periodically every 5 seconds and uniformly reported to the 302 flow control module on the central control machine to aggregate the node 5-second bandwidth, and then reported to the 302 policy center. (2) Business domain traffic collection: The 302 flow control module counts the number of requests for each business domain every 5 seconds. Based on the average file size per request, the business domain traffic is obtained by multiplying the number of requests by the file size per request and then reported to the 302 policy center. To address the issue that single-objective optimization of scheduling strategies cannot simultaneously balance cost and quality, a multi-objective programming algorithm is employed in scheduling strategy generation. Scheduling strategy generation mainly consists of two stages: (1) Modeling The 302 traffic scheduling problem is abstracted into the minimum cost maximum flow problem, and a network flow model in graph theory is established. The network flow model consists of several vertices and edges. Each edge has two key attributes: cap represents the upper limit of the corresponding network flow, and the flow size cannot exceed cap; the second attribute is cost, which represents the penalty incurred per unit of flow. For example, such as Figure 5 As shown, source node S and sink node T represent the starting and ending points of the network flow model; nodes at the domain level represent each service domain name; nodes at the node level represent all CDN edge nodes; edges are established between source nodes and nodes at the domain level, with cap set to domain traffic and cost set to 0 (no penalty); nodes at the domain level establish internal edges with nodes at the node level based on scheduling constraints, with cap set to domain traffic and cost set according to the priority of domain scheduling to nodes. The cost of high-priority flow control schemes should be as small as possible, and the cost of low-priority flow control schemes should be as large as possible. For example, if a quality-sensitive domain name needs to be scheduled to a node within the same province with high priority, then the cost of the edge from it to a node in another province should be set to a larger cost penalty; nodes at the node level establish sink edges with nodes, and set the expected billing edge and the node capacity limit edge respectively. The cap of the expected billing edge is the expected billing value of the node, and the cost is 0 (no penalty); the cap of the node capacity limit edge is the difference between the capacity limit and the expected billing value. Similarly, the cost of high-priority flow control schemes should be as small as possible, and the cost of low-priority flow control schemes should be as large as possible. (2) Solve After completing the network flow modeling, the corresponding linear programming problem is sent to the operations research model solution center for solving. The result obtained is the optimal domain-node traffic allocation and scheduling strategy that balances cost and quality. The downstream 302 flow control module periodically obtains the scheduling strategy from the center to query the 302 target node.

[0075] With the above Figures 1 to 5 Corresponding to the request processing method provided in the embodiments, this disclosure also provides a request processing apparatus. Since the request processing apparatus provided in the embodiments of this disclosure is similar to the one described above... Figures 1 to 6 The request processing method provided in the embodiments corresponds to the request processing apparatus provided in the embodiments of this disclosure, and will not be described in detail in the embodiments of this disclosure.

[0076] Figure 6 This is a schematic diagram of the request processing apparatus provided in Embodiment 4 of this disclosure.

[0077] like Figure 6 As shown, the request processing device 600 includes: a first acquisition module 610, a first determination module 620, a processing module 630, and a sending module 640.

[0078] The first acquisition module 610 is used to acquire the actual bandwidth and target bandwidth of the first target edge node in the current time period in response to receiving a pending service request sent by the client and the pending service request being scheduled to the first target edge node; the first determination module 620 is used to determine a second target edge node from at least one unloaded candidate edge node in response to the actual bandwidth being greater than the target bandwidth, based on a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements in the current time period; wherein the traffic scheduling requirements are determined based on the traffic requirements of each service in the current time period; the processing module 630 is used to redirect the pending service request to the second target edge node according to the IP address of the second target edge node, and receive the first target response generated by the second target edge node in response to the pending service request; the sending module 640 is used to send the first target response to the client.

[0079] As one possible implementation, the first determining module 620 is used to obtain the schedulable traffic quota of each candidate edge node indicated by the traffic scheduling strategy; and select a second target edge node from each candidate edge node according to the schedulable traffic quota of each candidate edge node.

[0080] As one possible implementation, the traffic scheduling strategy is generated using the following modules: a second acquisition module, a first generation module, a first creation module, and a second generation module.

[0081] The second acquisition module is used to acquire a network flow model, which includes multiple network flow nodes and directed edges connecting these nodes, with the direction of the directed edges indicating the direction of traffic transmission during the scheduling process. The first generation module is used to generate traffic constraints based on network flow constraints associated with the multiple network flow nodes and directed edges, whereby the traffic constraints indicate that the allocated traffic on each directed edge does not exceed the corresponding traffic carrying capacity. The first creation module is used to construct an objective function based on the traffic constraints and minimizing the scheduling cost. The second generation module is used to solve the objective function based on the traffic scheduling requirements, obtain the schedulable traffic quota for each candidate edge node, and generate a traffic scheduling strategy based on the schedulable traffic quota for each candidate edge node.

[0082] As one possible implementation, the network flow model is constructed using the following modules: a second creation module and a combination module.

[0083] The second creation module is used to create network flow nodes at multiple levels. These multiple levels include at least a traffic ingress layer, a domain name layer, a node layer, and a traffic egress layer arranged in sequence. The traffic ingress layer represents the entry point of service traffic, the domain name layer indicates the service domain name associated with the service traffic, the node layer indicates the edge node carrying the service traffic, and the traffic egress layer indicates the exit point of the service traffic. Directed edges are established between network flow nodes at adjacent levels within these multiple levels. Each directed edge includes a capacity limit and a unit traffic cost. The capacity limit indicates the maximum traffic value allowed through the directed edge, and the unit traffic cost indicates the scheduling cost introduced per unit of traffic on the directed edge. The combination module is used to combine network flow nodes with directed edges to generate a network flow model.

[0084] As one possible implementation, multiple network flow nodes include a source node at the traffic ingress layer, a sink node at the traffic egress layer, a domain name node at the domain name layer, and an edge node at the node layer. A second creation module is used to establish a first directed edge between the source node and each domain name node. The unit traffic cost of the first directed edge is a predetermined cost, indicating that there is no scheduling cost from the source node to the domain name layer where the domain name node resides. The capacity limit of the first directed edge is determined based on the traffic scheduling requirements of the corresponding domain name node's business domain name. A second directed edge is constructed between each domain name node and each edge node. The second directed edge satisfies predetermined scheduling constraints. The capacity limit of the second directed edge is the traffic scheduling requirement of the business domain name of the corresponding domain name node, and the unit traffic cost of the second directed edge is determined according to the scheduling priority of the business domain name; two parallel third directed edges are established between each edge node and the sink; the capacity limit of one third directed edge is determined according to the target bandwidth allowed to be used by the corresponding edge node in the current time period, and the unit traffic cost of one third directed edge is a set cost; the capacity limit of the other third directed edge is determined according to the difference between the capacity limit of the corresponding edge node and the target bandwidth; the unit traffic cost of the other third directed edge is determined according to the scheduling priority of the corresponding edge node.

[0085] As one possible implementation, network flow constraints include at least one of the following: capacity constraints; wherein the capacity constraints indicate that the allocated traffic on each directed edge does not exceed the corresponding capacity limit; traffic conservation constraints; wherein the traffic conservation constraints indicate that the total inflow traffic to network flow nodes other than those located at the traffic ingress layer and the traffic egress layer is equal to the total outflow traffic; service demand constraints; wherein the service demand constraints indicate that the traffic flowing from the traffic ingress layer to each domain name node located at the domain name layer is equal to the traffic demand value of the corresponding service domain name; and resource aggregation constraints; wherein the resource aggregation constraints indicate that the total traffic flowing to each edge node is equal to the total traffic flowing from the corresponding edge node to the traffic egress layer.

[0086] As one possible implementation, the processing module 630 is also used to receive the second target response generated by the first target edge node in response to the pending service request when the actual bandwidth is less than or equal to the target bandwidth; the sending module 640 is also used to send the second target response to the client.

[0087] As one possible implementation, the actual bandwidth is obtained by a collection module, which is used to collect the network egress traffic of each service instance in the first target edge node in response to the arrival of a set period; and to sum the network egress traffic of each service instance under the first target edge node to obtain the actual bandwidth of the first target edge node.

[0088] As one possible implementation, the traffic demand value of each service is determined using the following steps: a third acquisition module and a second determination module.

[0089] The third acquisition module is used to acquire the service request volume and average request file size of any service within the current time period; the second determination module is used to determine the traffic demand value of any service based on the service request volume and average request file size.

[0090] The request processing apparatus of this disclosure, after a pending service request arrives at an edge node, obtains in real time its actual bandwidth and preset target bandwidth for the current time period. This enables the system to identify the first target edge node that is already overloaded (i.e., its actual bandwidth exceeds the target bandwidth) in the first instance. Then, based on a strategy that aims to minimize scheduling costs while meeting the traffic scheduling needs of various services in the current time period, it accurately determines the second target edge node from multiple unloaded candidate edge nodes. Based on the IP address of the second target edge node, it accurately redirects the pending service request. This not only effectively avoids service delays or failures caused by local node resource overruns but also ensures a better balance between cost and service quality in the overall network traffic allocation. Finally, the client can obtain a response generated by the second target edge node, thereby improving the resource utilization efficiency, system stability, and scheduling intelligence level of the entire content delivery network while ensuring the continuity of user experience.

[0091] To implement the above embodiments, this disclosure also provides an electronic device, which may include at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the request processing method proposed in any of the above embodiments of this disclosure.

[0092] To implement the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the request processing method proposed in any of the above embodiments of this disclosure.

[0093] To implement the above embodiments, this disclosure also provides a computer program product, which includes a computer program that, when executed by a processor, implements the request processing method proposed in any of the above embodiments of this disclosure.

[0094] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0095] Figure 7A schematic block diagram of an example electronic device that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0096] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 702 or a computer program loaded from storage unit 708 into RAM (Random Access Memory) 703. The RAM 703 can also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An I / O (Input / Output) interface 705 is also connected to the bus 704.

[0097] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of displays, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0098] The computing unit 701 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as the request processing methods described above. For example, in some embodiments, the request processing methods described above can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 802 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the request processing methods described above can be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform the above-described request processing method by any other suitable means (e.g., by means of firmware).

[0099] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0100] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0101] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0102] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0103] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0104] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0105] It's important to note that artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies primarily include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0106] According to the technical solution of this disclosure, after a pending service request arrives at an edge node, its actual bandwidth and preset target bandwidth for the current time period are obtained in real time. This enables the system to identify the first target edge node that is already overloaded (i.e., the actual bandwidth exceeds the target bandwidth) in the first instance. Then, based on a strategy that aims to minimize scheduling costs and meet the traffic scheduling needs of each service in the current time period, a second target edge node is accurately determined from multiple unloaded candidate edge nodes. The pending service request is then accurately redirected based on the IP address of the second target edge node. This not only effectively avoids service delays or failures caused by local node resource overruns, but also ensures a better balance between cost and service quality in the allocation of network traffic. Finally, the client can obtain a response generated by the second target edge node, thereby improving the resource utilization efficiency, system stability, and scheduling intelligence level of the entire content delivery network while ensuring the continuity of user experience.

[0107] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution proposed in this disclosure can be achieved, and this is not limited herein.

[0108] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A request processing method, comprising: In response to receiving a pending service request sent by a client and the pending service request being scheduled to a first target edge node, the actual bandwidth and target bandwidth of the first target edge node in the current time period are obtained; In response to the actual bandwidth being greater than the target bandwidth, a second target edge node is determined from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements within the current time period; wherein the traffic scheduling requirements are determined based on the traffic demand values ​​of each service in the current time period. Based on the IP address of the second target edge node, the pending service request is redirected to the second target edge node, and the first target response generated by the second target edge node in response to the pending service request is received; Send the first target response to the client.

2. The method according to claim 1, wherein, The step of determining a second target edge node from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements within the current time period includes: Obtain the schedulable traffic quota for each candidate edge node as indicated by the traffic scheduling policy; Based on the schedulable traffic quota of each candidate edge node, a second target edge node is selected from the candidate edge nodes.

3. The method according to claim 1, wherein, The traffic scheduling strategy is generated using the following steps: Obtain a network flow model; wherein the network flow model includes multiple network flow nodes and directed edges connecting the multiple network flow nodes, and the direction of the directed edges is used to indicate the transmission direction of traffic during the scheduling process; Based on the network flow constraints associated with the plurality of network flow nodes and the plurality of directed edges, flow constraints are generated; wherein, the flow constraints are used to indicate that the allocated flow on each of the directed edges does not exceed the corresponding flow carrying capacity. Based on the aforementioned traffic constraints and the goal of minimizing scheduling costs, an objective function is constructed. Based on the traffic scheduling requirements, the objective function is solved to obtain the schedulable traffic quota for each candidate edge node, and the traffic scheduling strategy is generated based on the schedulable traffic quota for each candidate edge node.

4. The method according to claim 3, wherein, The network flow model is constructed using the following steps: Create network flow nodes at multiple levels; wherein the multiple levels include at least a traffic ingress layer, a domain name layer, a node layer, and a traffic egress layer arranged in sequence; wherein the traffic ingress layer is used to characterize the ingress of service traffic, the domain name layer is used to indicate the service domain name associated with the service traffic, the node layer is used to indicate the edge node carrying the service traffic, and the traffic egress layer is used to indicate the egress of the service traffic. Directed edges are established between network flow nodes in adjacent layers of the multiple layers; wherein, the directed edge includes a capacity limit and a unit flow cost, the capacity limit is used to indicate the maximum flow value allowed to pass through the directed edge, and the unit flow cost is used to indicate the scheduling cost introduced per unit flow on the directed edge; The network flow nodes are combined with the directed edges to generate the network flow model.

5. The method according to claim 4, wherein, The plurality of network flow nodes include source nodes located at the traffic ingress layer, sink nodes located at the traffic egress layer, domain name nodes located at the domain name layer, and edge nodes located at the node layer; The establishment of directed edges between network flow nodes in adjacent levels of the multiple levels includes: A first directed edge is established between the source point and each of the domain name nodes; wherein, the unit traffic cost of the first directed edge is a set cost, the set cost is used to indicate that there is no scheduling cost from the source point to the domain name layer where the domain name node is located, and the capacity limit of the first directed edge is determined according to the traffic scheduling demand value of the business domain name of the corresponding domain name node. Construct a second directed edge between each of the domain name nodes and each of the edge nodes; wherein the second directed edge satisfies the set scheduling constraints, the upper limit of the capacity of the second directed edge is the traffic scheduling requirement value of the business domain name of the corresponding domain name node, and the unit traffic cost of the second directed edge is determined according to the scheduling priority of the business domain name; Two parallel third directed edges are established between each edge node and the sink node; wherein, the capacity limit of one third directed edge is determined according to the target bandwidth allowed to be used by the corresponding edge node in the current time period, and the unit traffic cost of the third directed edge is the set cost; the capacity limit of the other third directed edge is determined according to the difference between the capacity limit of the corresponding edge node and the target bandwidth; and the unit traffic cost of the other third directed edge is determined according to the scheduling priority of the corresponding edge node.

6. The method according to claim 5, wherein, The network flow constraints include at least one of the following: Capacity constraint; wherein the capacity constraint is used to indicate that the allocated flow on each of the directed edges does not exceed the corresponding capacity limit; Flow conservation constraint; wherein, the flow conservation constraint is used to indicate that the total inflow of network flow nodes, excluding those located at the flow ingress layer and flow egress layer, is equal to the total outflow; Business demand constraints; wherein, the business demand constraints are used to indicate that the traffic flowing from the traffic ingress layer to each domain name node located in the domain name layer is equal to the traffic demand value of the corresponding business domain name; Resource aggregation constraint; wherein the resource aggregation constraint is used to indicate that the total flow to each of the edge nodes is equal to the total flow from the corresponding edge node to the flow exit layer.

7. The method according to claim 1, wherein, The method further includes: In response to the actual bandwidth being less than or equal to the target bandwidth, a second target response generated by the first target edge node in response to the pending service request is received; Send the second target response to the client.

8. The method according to any one of claims 1-7, wherein, The actual bandwidth was obtained using the following steps: In response to the arrival of a set period, the network egress traffic of each service instance in the first target edge node is collected; The actual bandwidth of the first target edge node is obtained by summing the network egress traffic of each service instance under the first target edge node.

9. The method according to any one of claims 1-7, wherein, The traffic demand values ​​for each of the aforementioned services are determined using the following steps: Obtain the service request volume and average request file size for any of the services within the current time period; The traffic requirement value for any of the services is determined based on the number of service requests and the average request file size.

10. A request processing apparatus, comprising: The first acquisition module is used to, in response to receiving a pending service request sent by a client and the pending service request being scheduled to a first target edge node, acquire the actual bandwidth and target bandwidth of the first target edge node in the current time period; A first determining module is configured to, in response to the actual bandwidth being greater than the target bandwidth, determine a second target edge node from at least one unloaded candidate edge node according to a traffic scheduling strategy that aims to minimize scheduling costs and meet the traffic scheduling requirements within the current time period; wherein the traffic scheduling requirements are determined based on the traffic demand values ​​of each service in the current time period. The processing module is configured to redirect the pending service request to the second target edge node according to the IP address of the second target edge node, and receive the first target response generated by the second target edge node in response to the pending service request; The sending module is used to send the first target response to the client.

11. An electronic device, wherein, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-9.

Images