Scheduling method, device and equipment of content distribution network and storage medium

Abstract

This invention provides a scheduling method, apparatus, device, and storage medium for a content delivery network (CDN), relating to the field of edge computing technology. The method includes: organizing a first group of CDN nodes to perform application-layer quality probing on the external interfaces of a target CDN node, obtaining first quality data; the target CDN node performing application-layer probing on its internal devices, obtaining second quality data; calculating a first quality score based on the first quality data, and calculating a second quality score based on the second quality data; determining the overall quality status of the target CDN node based on the first and second quality scores; and triggering a service traffic scheduling operation for the target CDN node based on the overall quality status. This invention achieves CDN-native, two-dimensional, hierarchical panoramic quality monitoring, effectively avoiding misjudgments caused by network instability, and automatically completing service scheduling for faulty nodes, thereby improving CDN service quality and resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a scheduling method, apparatus, device, and storage medium for a content delivery network. Background Technology

[0002] With the rapid development of internet content distribution, Content Delivery Networks (CDNs) have become a key infrastructure for improving the end-user access experience. To ensure the stability and efficiency of CDN services, continuous and accurate quality monitoring and early warning are crucial.

[0003] Currently, common CDN quality monitoring solutions in the industry have many limitations: First, monitoring methods that rely on third-party devices or platforms suffer from poor real-time data transmission, difficulty in linking with CDN systems, and high coordination and development costs. Second, network-layer-based (such as ping) detection methods cannot effectively reflect the true quality of application-layer services and are often impossible to implement due to security policy restrictions. Third, judgment logic based on simple thresholds (such as 1-2 instances of exceeding the standard) or a single algorithm is prone to generating a large number of false alarms due to brief network fluctuations, or causing frequent business switching, which in turn affects service continuity. Fourth, the use of a unified quality evaluation standard cannot adapt to the diverse business types within the CDN (such as latency-sensitive small file services and download services that can tolerate certain fluctuations) and differentiated resource configurations.

[0004] Therefore, there is an urgent need to design a quality early warning and scheduling scheme that is deeply coupled with the CDN system itself, can truly reflect service quality from the application layer, has hierarchical evaluation capabilities, and can achieve precise automatic scheduling. Summary of the Invention

[0005] This invention provides a scheduling method, apparatus, device, and storage medium for a content delivery network, which solves the technical problems of existing CDN quality monitoring solutions that rely on external systems, have limited monitoring dimensions, are prone to misjudgment, and cannot be intelligently linked with scheduling, resulting in inaccurate monitoring and untimely scheduling.

[0006] This invention provides a scheduling method for a content delivery network (CDN). The method includes: organizing a first group of CDN nodes to perform application-layer quality probing on the external service interfaces of a target CDN node, based on the CDN's own network architecture, to obtain first quality data; and organizing the target CDN nodes to perform application-layer quality probing on the service devices they manage, to obtain second quality data; calculating a first quality score reflecting the external service quality of the target CDN node based on the first quality data; calculating a second quality score reflecting the internal service quality of the target CDN node based on the second quality data; determining the comprehensive quality status of the target CDN node based on the first and second quality scores, the comprehensive quality status being used to identify the node status; and triggering a service traffic scheduling operation for the target CDN node based on the comprehensive quality status.

[0007] According to a content delivery network scheduling method provided by the present invention, organizing a first group of CDN nodes to perform application layer quality detection on the external service interface of a target CDN node to obtain first quality data includes: determining multiple CDN nodes belonging to the same scheduling region as the target CDN node as a first group of CDN nodes according to the CDN network's regional division strategy; controlling each node in the first group of CDN nodes to periodically initiate application layer protocol requests to the virtual IP address of the target CDN node; and recording the response result and latency of each application layer protocol request to form the first quality data.

[0008] According to a content delivery network scheduling method provided by the present invention, a target CDN node is organized to perform application layer quality probing on the service devices it manages to obtain second quality data. The method includes: obtaining address information of all service devices within the target CDN node by a probing control component deployed on the target CDN node; controlling the management server of the target CDN node to initiate application layer protocol requests to the addresses of the service devices according to a preset node probing cycle; and recording the response results and latency of each application layer protocol request initiated to the service devices to form the second quality data.

[0009] According to a content delivery network scheduling method provided by the present invention, initiating an application layer protocol request includes: using the curl tool to initiate a Hypertext Transfer Protocol (HTTP) request or a Hypertext Transfer Protocol Secure (HTTPS) request.

[0010] According to a content delivery network scheduling method provided by the present invention, a first quality score reflecting the external service quality of a target CDN node is calculated based on first quality data, including: statistically analyzing the first quality data according to a first preset time window and calculating the proportion of abnormal dialing tests of the target CDN node; determining the instantaneous state of the target CDN node in multiple consecutive time sub-windows based on the proportion of abnormal dialing tests; determining the external service quality status of the target CDN node according to the distribution of each instantaneous state in a second preset time window and in conjunction with a first preset rule; if the external service quality status is a fault, then marking the first quality score as a specific value representing the fault; if the external service quality status is not a fault, then obtaining the first quality score through a first normalization calculation based on the latency information in the first quality data.

[0011] According to a content delivery network scheduling method provided by the present invention, a first preset rule is configured as follows: when the number of fault instantaneous states reaches a first threshold within a second preset time window, the external service quality status is determined to be faulty; when the number of fault instantaneous states does not reach the first threshold but reaches a second threshold, and the number of sub-healthy instantaneous states reaches a third threshold, the external service quality status is determined to be faulty; when the number of fault instantaneous states does not reach the first threshold but reaches the second threshold, and the number of sub-healthy instantaneous states does not reach the third threshold, the external service quality status is determined to be sub-healthy; when the number of fault instantaneous states does not reach the second threshold, and the number of sub-healthy instantaneous states reaches the third threshold, the external service quality status is determined to be sub-healthy; when the number of fault instantaneous states does not reach the second threshold, and the number of sub-healthy instantaneous states does not reach the third threshold, the external service quality status is determined to be healthy.

[0012] According to a content delivery network scheduling method provided by the present invention, a second quality score reflecting the service quality inside a target CDN node is calculated based on second quality data. The method includes: statistically analyzing the second quality data according to a third preset time window; calculating the percentage of independent dial-up anomalies for each service device inside the target CDN node; determining the health status of each service device based on the percentage of independent dial-up anomalies; judging whether the internal service quality status of the target CDN node is abnormal based on the proportion of service devices in an unhealthy state within the target CDN node and in conjunction with a second preset rule; if abnormal, marking the second quality score as a specific value representing a fault; if not abnormal, obtaining the second quality score through a second normalization calculation based on latency information from healthy service devices in the second quality data.

[0013] According to a content delivery network scheduling method provided by the present invention, a second preset rule is configured as follows: when the proportion of service devices in a faulty state within a target CDN node reaches a fourth threshold, the internal service quality status is determined to be abnormal; when the proportion of service devices in a faulty state does not reach the fourth threshold, but the proportion of service devices in a sub-healthy state reaches a fifth threshold, the internal service quality status is determined to be abnormal; when the proportion of service devices in a faulty state does not reach the fourth threshold, the proportion of service devices in a sub-healthy state does not reach the fifth threshold, and the total proportion of service devices in an unhealthy state reaches a sixth threshold, the internal service quality status is determined to be abnormal; when the proportion of service devices in a faulty state does not reach the fourth threshold, the proportion of service devices in a sub-healthy state does not reach the fifth threshold, and the total proportion of service devices in an unhealthy state does not reach the sixth threshold, the internal service quality status is determined to be normal.

[0014] According to a content delivery network scheduling method provided by the present invention, the comprehensive quality status of a target CDN node is determined based on a first quality score and a second quality score, including: determining whether the first quality score or the second quality score is a specific value representing a fault; if so, determining that the comprehensive quality status of the target CDN node is a fault; if not, performing a weighted summation of the first quality score and the second quality score according to a preset weight to obtain a comprehensive quality score; comparing the comprehensive quality score with a preset grading threshold, and determining the comprehensive quality status based on the comparison result.

[0015] According to the scheduling method of a content delivery network provided by the present invention, before determining the overall quality status of a target CDN node, the method further includes: configuring different quality judgment threshold sets for different types of services based on the different quality sensitivities of CDN service types; wherein, for high-sensitivity services, the threshold requirements for latency and dialing success rate in the configured quality judgment threshold set are higher than the corresponding threshold requirements in the quality judgment threshold set configured for low-sensitivity services.

[0016] According to a content delivery network scheduling method provided by the present invention, a service traffic scheduling operation for a target CDN node is triggered based on the overall quality status, including: automatically generating a scheduling instruction when the overall quality status of the target CDN node is determined to be faulty; sending the scheduling instruction to the CDN scheduling system to trigger the switching of service traffic flowing to the target CDN node to a backup CDN node in the same area; wherein the selection of the backup CDN node is at least partially based on its overall quality status or overall quality score.

[0017] According to the content delivery network scheduling method provided by the present invention, after triggering the service traffic scheduling operation for the target CDN node, the method further includes: if the target CDN node is scheduled offline, sending an instruction to other CDN nodes in the same region as the target CDN node to stop the quality detection task for the target CDN node; if a new CDN node comes online, sending an instruction to other CDN nodes in the same region as the new CDN node to start the quality detection task for the new CDN node.

[0018] This invention also provides a scheduling device for a content delivery network (CDN), comprising: an intrinsic detection module, configured to organize a first group of CDN nodes to perform application-layer quality detection on the external service interfaces of a target CDN node based on the CDN's own network architecture, thereby obtaining first quality data; and to organize the target CDN nodes to perform application-layer quality detection on the service devices they manage, thereby obtaining second quality data; a dual-dimensional evaluation module, configured to calculate a first quality score reflecting the external service quality of the target CDN node based on the first quality data; and to calculate a second quality score reflecting the internal service quality of the target CDN node based on the second quality data; a panoramic judgment module, configured to determine the comprehensive quality status of the target CDN node based on the first quality score and the second quality score, wherein the comprehensive quality status is used to identify the node status; and a linkage scheduling module, configured to trigger a service traffic scheduling operation for the target CDN node based on the comprehensive quality status.

[0019] The present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the content delivery network scheduling method described above.

[0020] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the scheduling method of any of the above-described content delivery networks.

[0021] The content delivery network scheduling method, apparatus, equipment, and storage medium provided by this invention utilize the CDN's own network node resources for bidirectional application layer quality detection, establishing an endogenous data collection system covering the node's external service interfaces and internal service devices. Based on this dual-source data, external and internal quality scores of the node are calculated separately, constructing a two-dimensional quality assessment model that links service carrying capacity with internal resource status. According to the fusion and hierarchical judgment of internal and external quality scores, the overall operating status of the node can be comprehensively and accurately identified and classified. When a node failure or sub-healthy state is identified, the linkage scheduling of business traffic and node management operations can be automatically and instantly triggered based on the status judgment result, realizing closed-loop control of the entire link from quality monitoring and status assessment to scheduling execution. This constructs an endogenous, two-dimensional, hierarchical panoramic quality monitoring and linkage scheduling mechanism of the CDN, effectively avoiding misjudgments caused by network instability, and automatically completing the business scheduling of faulty nodes, thereby improving the service quality and resource utilization efficiency of the CDN. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in this invention 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 invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the overall architecture of CDN endogenous hierarchical panoramic quality early warning and linkage scheduling provided in an embodiment of the present invention.

[0024] Figure 2 This is a schematic diagram of the node deployment and interaction of CDN regional detection provided in an embodiment of the present invention.

[0025] Figure 3 This is a flowchart illustrating a content delivery network scheduling method provided in an embodiment of the present invention.

[0026] Figure 4 This is a schematic diagram of the CDN VIP node quality status determination logic based on a time sliding window provided in an embodiment of the present invention.

[0027] Figure 5 This is a schematic diagram of the CDN VIP node latency normalization calculation model provided in an embodiment of the present invention.

[0028] Figure 6 This is a schematic diagram of the structure of a content delivery network scheduling device provided in an embodiment of the present invention.

[0029] Figure 7This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0031] Figure 1 This is a schematic diagram of the overall architecture of CDN endogenous hierarchical panoramic quality early warning and linkage scheduling provided in an embodiment of the present invention. It includes a CDN endogenous hierarchical panoramic quality early warning and linkage scheduling system, which consists of a CDN endogenous hierarchical panoramic quality early warning and linkage scheduling server (QWE server) deployed in the CDN scheduling center, and QWE clients deployed on each CDN edge node.

[0032] In addition, the architecture also includes the original core components of CDN, including the content center and the origin server. The edge nodes provide content services to end users, the content center is used to store content resources that are not cached by the edge nodes, and the origin server stores the original content resources that are not cached by the content center.

[0033] Specifically, the QWE server, as the core control and analysis component of the architecture, is responsible for generating quality detection strategies, summarizing test data, assessing quality status, and initiating linkage scheduling commands. Each CDN edge node deploys a QWE client to receive detection strategies issued by the QWE server, control the internal components of the node to perform quality detection, collect detection results, and report them to the QWE server.

[0034] For example, its data interaction logic is as follows: if the edge node does not cache the content requested by the end user, it will send a content retrieval request to the content center; if the content center does not cache the content, it will further send a retrieval request to the origin server to ensure the integrity of content distribution.

[0035] Meanwhile, the QWE client and QWE server achieve real-time data transmission through a preset interface, including the issuance of detection strategies, the reporting of test results, and the transmission of scheduling instructions.

[0036] It should be noted that, Figure 1The core feature of the architecture shown is that it is CDN-native, meaning that both the QWE server and the QWE client are tightly coupled with the original CDN software system, rather than relying on external third-party components. When the CDN adds new service types (such as small file distribution and large file download), the QWE server will automatically adapt and generate detection methods, thresholds and algorithms that match the quality requirements of the service, ensuring that quality warnings are synchronized with business development.

[0037] Figure 2 This is a schematic diagram of node deployment and interaction for CDN regionalized probing provided in an embodiment of the present invention. Its architecture is divided into three logical units: a scheduling center, Region 1, and Region 2. The components and interaction relationships within each unit are as follows: Dispatch Center: Deployed with QWE servers, responsible for generating regional division strategies, issuing detection tasks, summarizing detection results, and determining node quality status, while storing basic information and real-time quality data of devices in each region.

[0038] Region 1 and Region 2: Both are CDN service areas. CDN node 1 and CDN node N are deployed in Region 1, and CDN node 2 and CDN node M are deployed in Region 2. Each CDN node includes a QWE client, a load balancer (LVS), a node management server, and multiple cache servers.

[0039] LVS is the interface for nodes to provide external services. It is responsible for receiving requests from end users and distributing them to the internal cache server. The cache server is used to store content and provide actual services. The node management server performs quality detection tasks under the control of the QWE client.

[0040] Specifically, the interaction logic for regional detection is as follows: Detection range limitation: According to CDN scheduling principles (such as proximity service and resource load balancing), the QWE server sends a regional information table to QWE clients in each region, limiting the detection range to mutual detection between nodes within the same region, excluding its own nodes.

[0041] For example, the QWE client of CDN node 1 in region 1 only controls its node management server to probe CDN node N in region 1, and does not probe itself; similarly, the QWE client of CDN node N only probes CDN node 1 in region 1 to avoid data redundancy and invalid results caused by cross-region probes (such as a northwest node probing a northeast node, which does not conform to the CDN nearest service principle and the result has no statistical significance).

[0042] Probe Task Execution: The QWE client obtains a probe range and frequency information table from the QWE server. Table 1 specifies the probe source (i.e., the management server of this node), the probe target (i.e., the LVS of other nodes in the same area), the probe URL (http: / / {vip}:{port} / content, where {vip} is the virtual IP of the target node's LVS, {port} is the service port, and the content is a pre-set test file of a fixed number of bytes), the probe interval, and the probe start time. An example of Table 1 is shown below: Table 1 Serial Number This node's management server Test the corresponding VIP server test URL Test interval (seconds) Test start time 1 1.1.1.1 1.1.2.2 http: / / {vip}:{port} / content 30 2025-1-1 00:00 2 1.1.1.1 2.1.1.2 http: / / {vip}:{port} / content 30 2025-1-2 10:00 3 1.1.1.1 2.1.2.2 http: / / {vip}:{port} / content 30 2025-1-3 20:00 The node management server initiates probes to the target VIP server using a Layer 7 probe tool according to the table requirements. After each probe, the results are recorded, and the QWE client packages and reports the probe results to the QWE server according to the probe result upload format. The uploaded table is shown in Table 2 below: Table 2 This node's management server Test the corresponding VIP server test URL Interval between each dial test (seconds) Test time Time to obtain results Get result status code Result retrieval latency (ms) Upload time 1.1.1.1 1.1.2.2 http: / / {vip}:{port} / content 30 2025-1-512:05:00 2025-1-512:05:08 200 56.2 2025-1-512:05:11 Regional Equipment Information Management: The QWE server stores a table illustrating the equipment division of each region, recording the basic configuration and quality score of all nodes within the region. An example table is shown in Table 3 below. Table 3 Serial Number Region ID CDN Node Name QWE client server VIP Server cache server External test score for this node This node's own rating Overall quality score 1 CMCC-HUB-AREA1 XXX 1.1.1.1 1.1.1.2 1.1.1.3-1.1.1.25 X Y Z 2 CMCC-HUB-AREA2 XXX 1.1.2.1 1.1.2.2 1.1.2.3-1.1.2.22 3 CMCC-NORTHWEST1 XXX 2.1.1.1 2.1.1.2 2.1.1.5-2.1.1.13 4 CMCC-NORTHWEST2 XXX 2.1.2.1 2.1.2.2 2.1.2.6-2.1.2.18 The following is combined Figure 3 This invention describes the scheduling method for a content delivery network. For consistency, the entity executing this method will be uniformly referred to as the system, and will not be described further thereafter.

[0043] Figure 3 This is a flowchart illustrating the scheduling method of a content delivery network provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the method includes the following: S301. Based on the CDN's own network architecture, organize the first group of CDN nodes to perform application layer quality detection on the external service interface of the target CDN node and obtain the first quality data.

[0044] In some embodiments, multiple CDN nodes belonging to the same scheduling region as the target CDN node can be identified as the first group of CDN nodes according to the CDN network's regional partitioning strategy.

[0045] For example, you can first obtain the area information table issued by the QWE server. This table contains the area ID (such as CMCC-HUB-AREA1, CMCC-NORTHWEST2), node name and IP address of each CDN node. If the area ID of the target CDN node is CMCC-HUB-AREA1, then all CDN nodes with the area ID CMCC-HUB-AREA1 are filtered from the table to form the first group of CDN nodes, ensuring that the probe source and the target node are in the same area.

[0046] Specifically, since the results of a node probing its own interface are easily affected by the node's internal resource consumption and cannot reflect the actual access quality of the end user, the target CDN node itself in the first group of CDN nodes is excluded, and only other nodes in the same area are retained as the probe source.

[0047] Furthermore, control each node in the first group of CDN nodes to periodically send application layer protocol requests to the virtual IP address of the target CDN node.

[0048] In one alternative implementation, each node in the first group of CDN nodes can be controlled to periodically send HTTP or HTTPS requests to the virtual IP address of the target CDN node using a command-line uniform resource locator (curl).

[0049] For example, the probe interval (e.g., 30 seconds), probe start time (e.g., 2025-1-1 00:00), and probe URL (http: / / {vip}:{port} / content) for each node in the first group can be determined based on the probe range and frequency information table issued by the QWE server. Taking CDN node 1 in the first group as an example, its node management server will execute the curl command at 2025-1-1 00:00.

[0050] Specifically, the node management server can be controlled to skip the domain name resolution process by directly entering the virtual IP address (e.g., 1.1.1.2) and port number (e.g., 80) of the target node in the curl command, instead of the domain name, thereby reducing the interference of DNS resolution latency on the detection results.

[0051] Furthermore, the response results and latency of each application layer protocol request are recorded to form the first quality data.

[0052] For example, two types of core data can be recorded after the curl command is executed: first, the response result, including the HTTP response status code (e.g., 200 for success, 404 for content not found) and error messages (e.g., connection refused, connection timeout); second, latency data, including total latency (obtained through curl's time_total parameter, i.e., the total time from initiating the request to receiving the response) and TCP connection latency (calculated through the difference between the time_connect parameter and the time_namelookup parameter, i.e., the time from the completion of domain name resolution to the completion of the TCP three-way handshake).

[0053] Specifically, during a probe of target node 1.1.1.2 by CDN node 1, the recorded information includes: the IP address of the local management server (1.1.1.1), the IP address of the corresponding VIP server (1.1.1.2), the probe URL (http: / / 1.1.1.2:80 / test.txt), the probe interval (30 seconds), the probe time (2025-1-5 12:05:00), the result acquisition time (2025-1-5 12:05:08), the result acquisition status code (200), and the result acquisition latency (56.2ms). This data is packaged and stored, and will be uploaded to the QWE server after the reporting cycle is reached.

[0054] It should be noted that the recorded probe content is a fixed small-byte file as agreed by CDN; if the probe file is too large, the latency will include the file transmission time and cannot accurately reflect the response speed of the service interface; while the transmission time of small-byte files (such as a few bytes) can be ignored and can more accurately reflect the real-time response capability of the interface.

[0055] Thus, by recording data in all dimensions, this invention ensures that the first quality data includes both service availability (response status code) and service performance (latency), avoiding quality assessment bias caused by a single data dimension.

[0056] S302. Based on the CDN's own network architecture, organize the target CDN node to perform application layer quality detection on the service devices it manages, and obtain the second quality data.

[0057] In some embodiments, the address information of all service devices within the target CDN node can be obtained by a detection and control component deployed on the target CDN node.

[0058] For example, the QWE client of the target CDN node reads the IP addresses of all internal cache servers (such as 1.1.1.3-1.1.1.25) from the node configuration file; the QWE client organizes these IP addresses into a list of internal service devices to ensure that subsequent probes can cover all core service devices and avoid abnormal user access due to the failure of some cache servers (such as external probes showing LVS is normal, but internal cache failure, users still cannot obtain content).

[0059] The cache server is the device that actually provides content services inside the node, while LVS only serves as an external interface for forwarding requests.

[0060] Specifically, the QWE client will periodically (e.g., every 5 minutes) update the list of internal service devices. If a node adds or takes a cache server offline, the list will be updated synchronously to ensure that the detection range is consistent with the actual device configuration of the node.

[0061] Furthermore, the management server controlling the target CDN node initiates application layer protocol requests to the address of the service device according to a preset node probing cycle.

[0062] In one alternative implementation, the management server of the target CDN node can be controlled to use the curl tool to send HTTP or HTTPS requests to the address of the service device according to a preset node probing period.

[0063] For example, since the state of internal cache servers may change more frequently (e.g., sudden traffic surges causing cache invalidation), more frequent probing is needed to detect anomalies promptly. Therefore, the intra-node probing cycle (e.g., 10 seconds) can be set shorter than the inter-region probing cycle (e.g., 30 seconds). The target node's management server will execute curl commands according to the internal probing task table, as shown in Table 4 below: Table 4 Serial Number This node's management server Dialing the corresponding cache server test URL Test interval (seconds) 1 1.1.1.1 1.1.1.5 http: / / {cache}:{port} / content 10 2 1.1.1.1 1.1.1.6 http: / / {cache}:{port} / content 10 3 1.1.1.1 1.1.1.7 http: / / {cache}:{port} / content 10 Taking the cache server 1.1.1.5 as an example, the curl command executed by the management server is "curl -w "time_total:\t\t%{time_total}\n" http: / / 1.1.1.5:8080 / inner_test.txt". Here, "8080" is the service port of the cache server, and "inner_test.txt" is a small test file pre-installed within the node.

[0064] Furthermore, the response results and latency of each application layer protocol request initiated to the service device are recorded to form second quality data.

[0065] For example, record response results (status codes, error messages) and latency data (total latency, TCP connection latency) similar to those of external probes, and add a device identification field to distinguish the probe results of different cache servers.

[0066] For example, in a probe of cache server 1.1.1.5, the recorded content includes: the IP of the local node management server (1.1.1.1), the IP of the corresponding cache server being probed (1.1.1.5), the probe URL (http: / / 1.1.1.5:8080 / inner_test.txt), the probe interval (10 seconds), the probe time (2025-1-5 12:05:00), the result acquisition time (2025-1-5 12:05:02), the result acquisition status code (200), and the result acquisition latency (12.3ms).

[0067] Specifically, the second quality data can also be packaged according to the node's internal status upload format. This format includes fields such as "this node's management server", "interval between each test (seconds)", "test start time", "test end time", "normalized value for this stage", "this node's latency (ms)", and "upload time". An example table is shown in Table 5 below: Table 5 This node's management server Interval between each dialing test (seconds) Test start time Test end time Normalized value in this stage Local node latency (ms) Upload time 1.1.1.1 10 2025-1-5 12:05:00 2025-1-5 12:05:50 69 56.2 2025-1-5 12:06:02 The QWE client reports the data in the table to the QWE server in real time, ensuring that the dispatch center can synchronously grasp the internal quality status of the target node.

[0068] Thus, by recording and reporting internal data in a structured manner, this invention ensures that the second quality data can work in conjunction with the first quality data, providing complete data for the subsequent dual-dimensional scoring of external and internal testing, and avoiding quality misjudgments caused by missing internal data.

[0069] S303. Based on the first quality data, calculate the first quality score that reflects the external service quality of the target CDN node.

[0070] In some embodiments, first quality data can be collected according to a first preset time window to calculate the proportion of abnormal test results for the target CDN node.

[0071] For example, the first preset time window can be 30 seconds (consistent with the inter-regional detection interval). All test records of the first group of CDN nodes to the target node within this window (e.g., 10 records) are counted. Among them, the number of successful records with status code 200 is 8, and the total number of records is 10. According to the formula of test anomaly percentage = 1 - sum (number of records with status code 200) / sum (total number of records), the test anomaly percentage is calculated to be 1 - 8 / 10 = 20%.

[0072] Specifically, in actual statistics, invalid records (such as non-response records caused by the failure of the probe source itself) are excluded, and only valid probe records (i.e. records that receive a clear response after a request is initiated) are counted to ensure the accuracy of the anomaly ratio calculation; if a probe record shows a connection timeout, it is included in the number of records with non-200 status codes and participates in the anomaly ratio calculation.

[0073] Furthermore, based on the proportion of abnormalities detected during dialing, the instantaneous state of the target CDN node within multiple consecutive time sub-windows is determined.

[0074] Exemplarily, three groups of abnormal proportion thresholds can be preset: the first threshold M (e.g., 30%), the second threshold N (e.g., 50%), where M < N. If the proportion of abnormal tests in a certain time sub-window < M (e.g., 20% < 30%), the instantaneous state is determined to be healthy; if M ≤ the proportion of abnormal tests < N (e.g., 30% ≤ 40% < 50%), it is determined to be sub-healthy; if the proportion of abnormal tests ≥ N (e.g., 50% ≥ 50%), it is determined to be faulty. Taking 5 consecutive time sub-windows (each 30 seconds) as an example, the proportions of abnormal tests are 20%, 25%, 35%, 45%, 55% respectively, and the corresponding instantaneous states are healthy, healthy, sub-healthy, sub-healthy, and faulty in sequence.

[0075] Specifically, the values of M and N can be dynamically adjusted according to the CDN service type. For high-sensitivity services (such as small file distribution, games), M and N are set smaller (e.g., M = 20%, N = 40%) to more strictly monitor the quality; for low-sensitivity services (such as large file downloads), M and N are set larger (e.g., M = 40%, N = 60%) to avoid frequent misjudgments.

[0076] Furthermore, according to the distribution of each instantaneous state within the second preset time window and combined with the first preset rule, the external service quality status of the target CDN node is determined.

[0077] Optionally, the first preset rule is configured to include the following five conditions: 1) When the number of faulty instantaneous states reaches the first threshold within the second preset time window, the external service quality status is determined to be faulty.

[0078] Exemplarily, the second preset time window is a time sliding window with a length set to 7 minutes and 30 seconds (i.e., including 15 30-second time sub-windows), and the first threshold a (e.g., 5); if 6 out of 15 sub-windows are in the faulty state (6 ≥ 5), then the external service quality status is directly determined to be faulty.

[0079] 2) When the number of faulty instantaneous states does not reach the first threshold but reaches the second threshold, and the number of sub-healthy instantaneous states reaches the third threshold, the external service quality status is determined to be faulty.

[0080] Exemplarily, the second threshold b (e.g., 3), the third threshold c (e.g., 8); if there are 4 faulty states (4 ≥ 3 and 4 < 5) and 9 sub-healthy states (9 ≥ 8) in 15 sub-windows, then the external service quality status is determined to be faulty.

[0081] 3) When the number of faulty instantaneous states does not reach the first threshold but reaches the second threshold, and the number of sub-healthy instantaneous states does not reach the third threshold, the external service quality status is determined to be sub-healthy.

[0082] For example, if there are 4 fault states (4≥3 and 4<5) and 6 sub-health states (6<8) in the 15 sub-windows, then the external service quality status is determined to be sub-healthy.

[0083] 4) When the number of fault instantaneous states does not reach the second threshold, but the number of sub-health instantaneous states reaches the third threshold, the external service quality status is determined to be sub-healthy.

[0084] For example, if there are 2 fault states (2<3) and 9 sub-health states (9≥8) in the 15 sub-windows, then the external service quality status is determined to be sub-healthy.

[0085] 5) When the number of fault instantaneous states does not reach the second threshold and the number of sub-health instantaneous states does not reach the third threshold, the external service quality status is determined to be healthy.

[0086] For example, if there are 2 fault states (2<3) and 5 sub-health states (5<8) in the 15 sub-windows, then the external service quality status is determined to be healthy.

[0087] In this embodiment of the invention, the determination logic of the above-mentioned time sliding window can be achieved through the following: Figure 4 exhibit.

[0088] Figure 4 This is a schematic diagram of the CDN VIP node quality status determination logic based on a time sliding window provided in this embodiment of the invention, which includes three situations: fault at the time interval point, sub-health at the time interval point, and healthy at the time interval point; the external service quality status is divided into VIP fault and VIP sub-health.

[0089] Specifically, at this time interval point, a fault corresponds to a single time sub-window that determines the condition as a fault; at this time interval point, a sub-healthy condition corresponds to a single time sub-window that determines the condition as sub-healthy; and at this time interval point, a healthy condition corresponds to a single time sub-window that determines the condition as healthy.

[0090] For example, in the diagram, 'a' represents the first threshold for the number of fault states, 'b' represents the second threshold for the number of fault states, and 'c' represents the third threshold for the number of sub-health states. The external service quality status can be determined by comparing the number of each state within the window with 'a', 'b', and 'c'.

[0091] For example, if the number of faults at a given time interval is ≥a, it is a VIP fault; if the number of faults at a given time interval is ≥b and the number of sub-healthy items at that time interval is ≥c, it is a VIP fault.

[0092] Optionally, it can also handle special cases of continuous sub-health: if the external service quality status is sub-healthy for K consecutive (e.g., 3) second preset time windows, it is determined to be a fault state. For example, if three consecutive 7-minute and 30-second windows are in sub-healthy condition, a fault determination is triggered.

[0093] When actually judging whether the quality of external services is abnormal, you can first count the number of fault states in the window and the relationship between a and b, then count the number of sub-health states and the relationship between c, and finally match the corresponding conditions in the first preset rule to ensure that the judgment result is rigorous.

[0094] Thus, this invention effectively filters out transient anomalies caused by brief network fluctuations (such as a single sub-window failure but overall health) by using a time-sliding window and multi-condition rules, thereby improving the accuracy of quality status determination.

[0095] In one alternative implementation, if the external service quality status is faulty, the first quality score is marked as a specific value characterizing the fault.

[0096] For example, a specific value representing a fault can be preset to -1. If the external service quality status is determined to be faulty, the first quality score is -1. This mark is then synchronously uploaded to the regional device division information table of the QWE server, corresponding to the external test node score field.

[0097] For example, the CDN node with region ID CMCC-HUB-AREA2 in the table has an external test score of -1, indicating that the node is experiencing a service failure.

[0098] In another optional implementation, if the external service quality status is not faulty, the first quality score is obtained by first normalization calculation based on the latency information in the first quality data.

[0099] For example, the average latency of all successful dial-up test records within the second preset time window can be calculated first. Taking 15 sub-windows as an example, the average latency of successful dial-up tests in each sub-window is 50ms, 55ms, 60ms... (a total of 15 values), and the average latency of the window is calculated to be r=65ms; then the optimal latency value rmin (e.g., 50ms) and the worst latency value rmax (e.g., 200ms) of the VIP node are preset, and the latency data is normalized to the interval [60, 100] (60 is the worst score, and 100 is the optimal score).

[0100] Specifically, the normalization calculation of a single time delay parameter should refer to the following formula: .

[0101] In this embodiment of the invention, when the target CDN node has multiple latency metrics to consider (such as TTL latency, first packet latency), it needs to be handled as follows: Figure 5 The logic shown is used for processing.

[0102] Figure 5 This is a schematic diagram of the CDN node latency normalization calculation model provided in this embodiment of the invention. It contains complete multi-latency parameter processing elements, with multiple latency parameter modules distributed horizontally: corresponding to latency 1, latency 2...latency N respectively (N is a positive integer greater than 2, representing more latency parameters).

[0103] For example, each delay parameter module contains four core elements: normalization principle (such as delay 1 normalization principle, delay 2 normalization principle, delay N normalization principle), weight (such as delay 1 weight, delay 2 weight, delay N weight), and normalized value (such as delay 1 normalized value, delay 2 normalized value, delay N normalized value).

[0104] Specifically, the fusion result after normalization of each delay parameter is the final delay value, and the sum of the weights of delay 1, 2, and N is 100%.

[0105] When dealing with multiple delay parameters in practice, the following logic applies: Independent normalization: For each delay parameter (delay 1, delay 2, delay N), apply its corresponding normalization principle (e.g., for TTL delay, x=100 when r≤50ms, and for first packet delay, x=100 when r≤30ms) to calculate their respective normalized values ​​(e.g., TTL delay normalized value 90, first packet delay normalized value 98).

[0106] Weight configuration: Assign a weight to each latency parameter and ensure that the sum of all weights is 100% (e.g., TTL latency weight 0.4, first packet latency weight 0.6, 0.4+0.6=1.0).

[0107] Fusion calculation: The normalized values ​​of each delay parameter are multiplied by their corresponding weights and then summed to obtain the final delay value. This value is the unified result after normalization of multiple delay parameters (e.g., 90×0.4+98×0.6=94.8).

[0108] For example, considering the target CDN node, TTL latency (e.g., r=65ms, rmin=50ms, rmax=200ms) and first packet latency (e.g., r=40ms, rmin=30ms, rmax=150ms) need to be taken into account. TTL latency normalization: x1=60+40*(200-65) / (200-50)=96; First packet latency normalization: x2=60+40*(150-40) / (150-30)=60+40*110 / 120≈96.67; Weight configuration: TTL latency weight 0.4, first packet latency weight 0.6 (0.4+0.6=100%); Final latency value = 96×0.4+96.67×0.6≈96.4. That is, the normalized result of the target node based on multiple delay parameters is 96.4, which is used as the first quality score.

[0109] Thus, this invention, through multi-delay processing, ensures that the normalization of each delay parameter meets its own quality requirements, and achieves data unification through weight fusion, avoiding scoring deviations caused by differences in multiple delay dimensions.

[0110] S304. Based on the second quality data, calculate the second quality score that reflects the service quality inside the target CDN node.

[0111] In some embodiments, second quality data can be statistically analyzed according to a third preset time window to calculate the percentage of independent dial-up anomalies for each service device within the target CDN node.

[0112] For example, a third preset time window can be set to 10 seconds, consistent with the node's probe interval. Within this window, the target node management server records 5 probe attempts to a specific cache server (e.g., 1.1.1.5). Of these, 4 are successful attempts with status code 200, and the total number of attempts is 5. Using the formula: Independent probe failure rate = 1 - sum(number of records with status code 200) / sum(total number of records), the independent probe failure rate for this cache server is calculated to be 1 - 4 / 5 = 20%.

[0113] Specifically, the percentage of independent test anomalies can be calculated for each cache server (e.g., 1.1.1.3-1.1.1.25) within the target node to ensure that the quality status of each service device is evaluated and to avoid misjudgment of overall quality due to anomalies in some devices.

[0114] For example, if a cache server is taken offline for maintenance, it will be marked as not in service and will not be included in the calculation of the percentage of abnormalities in independent testing.

[0115] Furthermore, the health status of each service device is determined based on the percentage of abnormal independent dialing tests.

[0116] Exemplarily, three sets of internal exception ratio thresholds can be preset in advance: the fourth threshold P (such as 20%), the fifth threshold Q (such as 40%), where P < Q. If the independent measurement exception ratio of a certain cache server < P (such as 15% < 20%), its health status is determined to be healthy; if P ≤ independent measurement exception ratio < Q (such as 20% ≤ 35% < 40%), it is determined to be sub-healthy; if the independent measurement exception ratio ≥ Q (such as 45% ≥ 40%), it is determined to be faulty.

[0117] For example, taking 10 cache servers in the target node as an example, their health status distribution is: 6 are healthy, 2 are sub-healthy, and 2 are faulty.

[0118] Specifically, the health status of each cache server can also be recorded in the internal device status table and updated in real time. If a certain originally healthy cache server has an independent measurement exception ratio ≥ Q in two consecutive third preset time windows, its status is updated to faulty to ensure the timeliness of status determination.

[0119] Furthermore, according to the proportion of service devices in the target CDN node that are in an unhealthy state, combined with the second preset rule, it is judged whether the internal service quality status of the target CDN node is abnormal.

[0120] Optionally, the second preset rule is configured to include the following four conditions: 1) When the proportion of service devices in the target CDN node that are in a faulty state reaches the fourth threshold, it is judged that the internal service quality status is abnormal.

[0121] Exemplarily, the fourth threshold X (such as 20%), the target node has a total of 20 cache servers, among which 5 are in a faulty state, the fault ratio = 5 / 20 = 25% ≥ 20%, then it is judged that the internal service quality status is abnormal.

[0122] 2) When the proportion of service devices in a faulty state does not reach the fourth threshold, and the proportion of service devices in a sub-healthy state reaches the fifth threshold, it is judged that the internal service quality status is abnormal.

[0123] Exemplarily, the fifth threshold Y (such as 30%), the fault ratio = 10% < 20%, the sub-healthy ratio = 35% ≥ 30%, then it is judged that the internal service quality status is abnormal.

[0124] 3) When the proportion of service devices in a faulty state does not reach the fourth threshold, and the proportion of service devices in a sub-healthy state does not reach the fifth threshold, and the total proportion of service devices in an unhealthy state reaches the sixth threshold, it is judged that the internal service quality status is abnormal.

[0125] For example, for the sixth threshold Z (e.g., 40%, Z=X+Y), if the failure rate is 10%<20%, the sub-health rate is 25%<30%, and the total unhealthy rate is 10%+25%=35%<40%, then it is not considered abnormal for the time being; if the total unhealthy rate is 45%≥40%, then the internal service quality status is judged to be abnormal.

[0126] 4) When the proportion of service devices in a faulty state does not reach the fourth threshold, the proportion of service devices in a sub-healthy state does not reach the fifth threshold, and the total proportion of service devices in an unhealthy state does not reach the sixth threshold, the internal service quality status is judged to be normal.

[0127] For example, if the failure rate is 10% < 20%, the sub-health rate is 25% < 30%, and the total unhealthy rate is 35% < 40%, then the internal service quality status is judged to be normal.

[0128] When actually judging whether the internal service quality status is abnormal, it can be checked layer by layer in the order of failure ratio, sub-health ratio, and total unhealthy ratio. As long as any of the above abnormal conditions are met, the internal service quality status is judged to be abnormal.

[0129] For example, if the failure rate does not meet the standard, but the sub-health rate does, it can be directly judged as abnormal without further verification of the total rate.

[0130] Thus, this invention ensures that the internal service quality status assessment considers both faulty equipment and the cumulative impact of sub-healthy equipment through multi-dimensional proportional verification and tiered judgment, avoiding misjudgments of internal quality due to single-dimensional judgment.

[0131] In one alternative implementation, if an anomaly is determined, the second quality score is marked as a specific value characterizing the fault.

[0132] For example, the second quality score is consistent with the first quality score, with a specific value of -1 representing a fault. If the service quality status inside the target node is abnormal, the QWE client will mark the second quality score as -1 and report it to the QWE server, updating the local node's own score field in the regional device division schematic information table.

[0133] For example, the CDN node with region ID CMCC-NORTHWEST1 in the table has a self-rating of -1, indicating that the node has an internal service failure.

[0134] In another alternative implementation, if the result is determined to be non-abnormal, a second quality score is obtained by calculating the latency information from the health service device in the second quality data through a second normalization.

[0135] For example, cache servers with healthy internal status can be selected first, and the successful dial-up latency of these healthy devices within a third preset time window can be counted to calculate the average latency v within the node.

[0136] For example, taking 5 healthy cache servers as an example, their average latencies are 10ms, 12ms, 11ms, 13ms, and 12ms respectively, and the average internal latency of the node is v=(10+12+11+13+12) / 5=11.6ms.

[0137] Specifically, the normalization formula for a single internal delay parameter is the same as that for the external one, as follows: If the target node needs to consider multiple internal latency metrics (such as cache hit latency and content read latency), then the same principle applies. Figure 5 The logic shown: Independent normalization: For each internal latency metric, apply its corresponding normalization principle (e.g., cache hit latency P). min =8ms, content read latency P min =5ms), calculate their respective normalized values ​​(e.g., cache hit latency normalized value 95, content read latency normalized value 100).

[0138] Weight configuration: Assign weights and ensure the sum is 100% (e.g., cache hit latency weight 0.5, content read latency weight 0.5).

[0139] Fusion calculation: The weighted summation yields the final value of the internal delay (e.g., 95×0.5+100×0.5=97.5), which is used as the second quality score.

[0140] For example, taking v=11.6ms, pmin=10ms, and pmax=50ms (a single latency metric) as an example, substituting into the formula, we get: y=60+40*(50-11.6) / (50-10)=60+40*38.4 / 40=60+38.4=98.4, which means the second quality score is 98.4.

[0141] Thus, this invention ensures that the second quality score reflects only the quality level of normal service equipment through health device screening and normalization, while maintaining consistency with the multi-latency processing logic of the first quality score.

[0142] S305. Determine the overall quality status of the target CDN node based on the first quality score and the second quality score.

[0143] Optionally, before determining the overall quality status of the target CDN node, different quality judgment threshold sets can be configured for different types of services based on their varying sensitivity to quality.

[0144] Specifically, for high-sensitivity services, the threshold requirements for latency and dial-up success rate in the configured quality judgment threshold set are higher than the corresponding threshold requirements in the quality judgment threshold set configured for low-sensitivity services.

[0145] For example, the threshold set for high-sensitivity services (such as small file distribution and games) is as follows: health threshold for abnormal test rate ≤ 20%, sub-health threshold 20%-40%, fault threshold ≥ 40%, latency health threshold ≤ 100ms, sub-health threshold 100ms-200ms, fault threshold ≥ 200ms; the threshold set for low-sensitivity services (such as large file downloads) is as follows: health threshold for abnormal test rate ≤ 40%, sub-health threshold 40%-60%, fault threshold ≥ 60%, latency health threshold ≤ 300ms, sub-health threshold 300ms-500ms, fault threshold ≥ 500ms.

[0146] Specifically, the service type carried by the target node (such as simultaneously carrying small file and large file services) can be read from the CDN service configuration table, and the corresponding threshold sets can be loaded respectively. In the subsequent comprehensive quality status determination, different service types will be evaluated separately to ensure that the determination results match the service quality requirements.

[0147] For example, if the overall status of the target node for small file services is sub-healthy, and the overall status for large file services is healthy, then the status of the two types of services will be recorded separately for subsequent differentiated scheduling.

[0148] Thus, this invention achieves the core objective of tiered quality early warning through business-differentiated threshold configuration, avoiding the problem that a single threshold cannot adapt to diverse businesses, and ensuring that quality judgment is closely integrated with the actual business scenarios of CDN.

[0149] In this embodiment of the invention, the overall quality status is used to identify the node status; the overall quality status includes node health, sub-health, or fault.

[0150] In some embodiments, it can be determined whether the first quality score or the second quality score is a specific value characterizing a fault.

[0151] For example, first read the first quality score (external test score of this node) and the second quality score (this node's own score) of the target node in the area device division schematic information table. For example, the first quality score of target node 1 is 90 and the second quality score is -1, the first quality score of target node 2 is -1 and the second quality score is 85, and the first quality score of target node 3 is 85 and the second quality score is 95.

[0152] Specifically, since a first quality score of -1 means an external service failure and a second quality score of -1 means an internal service failure, we can prioritize checking whether -1 exists. Any failure will cause the node to be unable to provide services normally, and should be judged as a comprehensive failure.

[0153] In one alternative implementation, if the first or second quality score is -1, then the overall quality status of the target CDN node is determined to be faulty.

[0154] For example, if the second quality score of target node 1 is -1 (internal failure), even if the first quality score is 90 (normal external service), its overall quality status is still determined to be a failure; similarly, if the first quality score of target node 2 is -1 (external service failure), even if the internal service is normal, it is also determined to be a comprehensive failure.

[0155] In another optional implementation, if not (i.e., neither the first nor the second quality score is -1), the first quality score and the second quality score are weighted and summed according to preset weights to obtain a comprehensive quality score.

[0156] For example, the external quality score weight H (e.g., 0.6) can be preset, and the internal quality score weight (1-H) = 0.4. If the first quality score of target node 3 is 85 and the second quality score is 95, substituting into the formula "comprehensive quality score = x×H + y×(1-H)", the comprehensive quality score is calculated as 85×0.6 + 95×0.4 = 51 + 39 = 90.

[0157] Specifically, the weight H can be dynamically adjusted according to the business type. For highly sensitive businesses, H is set to 0.7 (focusing more on external service quality), and (1-H)=0.3; for low-sensitivity businesses, H is set to 0.5 (equal attention is paid to external and internal quality).

[0158] For example, if the target node carries highly sensitive services, with a first quality score of 85 and a second quality score of 95, then the overall quality score = 85 × 0.7 + 95 × 0.3 = 59.5 + 28.5 = 88.

[0159] Furthermore, the overall quality score is compared with a preset grading threshold, and the overall quality status is determined based on the comparison result.

[0160] For example, a comprehensive quality grading threshold can be preset: a healthy threshold ≥ 85, a sub-healthy threshold 60-85, and a fault threshold < 60. If the comprehensive quality score = 90 ≥ 85, it is judged as healthy; if the score = 75 (60 < 75 < 85), it is judged as sub-healthy; and if the score = 55 < 60, it is judged as faulty.

[0161] Specifically, the grading thresholds are matched with the business type. The health threshold for high-sensitivity businesses is ≥90, and the health threshold for low-sensitivity businesses is ≥80. For example, if a target node carries high-sensitivity businesses and its overall quality score is 88 < 90, it is considered sub-healthy; if it carries low-sensitivity businesses, its score is 88 ≥ 80, and it is considered healthy.

[0162] Thus, this invention, through dynamic weight adjustment and hierarchical threshold adaptation, ensures that the comprehensive quality status judgment can reflect the synergistic impact of external and internal quality, and adapt to the quality requirements of different businesses, thereby achieving the goal of panoramic quality early warning.

[0163] S306. Based on the overall quality status, trigger a service traffic scheduling operation for the target CDN node.

[0164] In some embodiments, when the overall quality status of the target CDN node is determined to be faulty, a scheduling instruction is automatically generated.

[0165] For example, the target node's region ID (e.g., CMCC-HUB-AREA1), VIP server IP (e.g., 1.1.1.2), and offline reason (e.g., internal cache failure rate of 25%) can be read from the region device partitioning information table of the QWE server to generate scheduling instructions.

[0166] The instructions include: the IP address of the faulty node (1.1.1.2), its region (CMCC-HUB-AREA1), the time of its shutdown (e.g., immediately), and the rules for selecting a replacement node (the healthy node with the highest overall quality score in the same region).

[0167] Specifically, scheduling instructions can also include service relocation priorities. If the target node carries high-sensitivity services, the priority is set to the highest, and the traffic switch must be completed within 10 seconds; if it carries low-sensitivity services, the priority is set to medium, and the switch can be completed within 30 seconds, ensuring the service continuity of critical services.

[0168] Furthermore, the scheduling command is sent to the CDN scheduling system to trigger the switching of service traffic flowing to the target CDN node to a backup CDN node in the same region.

[0169] The selection of backup CDN nodes is based at least in part on their overall quality status or overall quality score.

[0170] For example, after receiving the scheduling instruction, the CDN scheduling system selects the node with the healthiest overall quality status and the highest overall quality score (such as node 4 with a score of 92) in the CMCC-HUB-AREA1 area as the backup node; then it gradually switches the business traffic originally flowing to 1.1.1.2 (such as 1,000 requests per second) to the VIP server IP of node 4 (1.1.1.6).

[0171] Optionally, if there are no healthy nodes in the same area, the CDN scheduling system can request cross-region scheduling authorization from the QWE server. After the QWE server verifies the authorization, it will switch the traffic to a healthy node in a neighboring area (such as CMCC-HUB-AREA2) and update the detection range in the area information table to ensure that subsequent detection can cover the backup node across the region.

[0172] Thus, this invention achieves the core objective of coordinated scheduling by prioritizing switching within the same region and conducting cross-regional authorization assessment. This ensures rapid transfer of traffic from faulty nodes while avoiding increased latency caused by blind cross-regional scheduling, thus balancing service quality and resource efficiency.

[0173] Optionally, after the scheduling operation, if the target CDN node is scheduled offline, an instruction is sent to other CDN nodes in the same region as the target CDN node to stop the quality probing task of the target CDN node.

[0174] For example, the QWE server will send an offline notification to the QWE clients of all CDN nodes in the CMCC-HUB-AREA1 area.

[0175] The notification included: the IP address of the offline node (1.1.1.2), the offline time (2025-1-5 12:10:00), and the reason for offline (internal cache failure).

[0176] Specifically, if a QWE client belongs to an offline node (1.1.1.2), its external CDN service will be stopped immediately, and it will wait for the administrator to maintain it; if it belongs to another node (such as 1.1.1.1), the probe task for 1.1.1.2 will be removed from the probe task list, the node management server will be notified to stop the probe, and the probe data and results to be reported for 1.1.1.2 stored locally will be deleted.

[0177] In addition, the QWE server can also synchronously update the detection range and frequency information table, delete all detection entries involving 1.1.1.2, and ensure that no further detection tasks are generated for this node, thus avoiding resource waste.

[0178] Thus, this invention ensures that a faulty node is no longer probed after it goes offline by synchronizing offline notifications and cleaning up probe tasks, while also preventing other nodes from reporting invalid data due to continuous probing of the faulty node, thereby improving system resource utilization.

[0179] Optionally, after the scheduling operation is performed, if a new CDN node comes online, an instruction is sent to other CDN nodes in the same region as the new CDN node to start a quality detection task for the new CDN node.

[0180] For example, if the VIP server IP of the newly added node 5 is 1.1.1.7 and its region is CMCC-HUB-AREA1, the QWE server will send an online notification to the QWE clients of all CDN nodes in that region.

[0181] The notification includes: the new node IP (1.1.1.7), the probe start time (2025-1-5 12:15:00), the probe interval (30 seconds), and the probe URL (http: / / 1.1.1.7:80 / content).

[0182] Specifically, if a QWE client belongs to the newly added node 5, the notification will be ignored; if it belongs to other nodes (such as 1.1.1.1), a task for 1.1.1.7 will be added to the probe task list, and the node management server will be notified to start the probe after 12:15:00 and report the results along with other probe data.

[0183] In addition, the QWE server can update the regional device partitioning information table and add information about the newly added node 5 (region ID, QWE client server IP, VIP server IP, etc.) to ensure that it is included in the network-wide quality monitoring scope.

[0184] Thus, this invention ensures that newly added nodes can be quickly integrated into the CDN quality monitoring system by synchronizing online notifications and adding detection tasks, and promptly assigns detection tasks to them, providing quality data support for subsequent business scheduling.

[0185] Optionally, a heartbeat detection and data retransmission process can also be performed to ensure the integrity of quality data and the accuracy of node status: Heartbeat detection: Each QWE client reports test data to the QWE server at a preset period (e.g., 60 seconds). If the QWE server receives the data within the period, it determines that the node is active. If it does not receive the directly reported data, but receives probe data from other nodes (e.g., node A did not report, but node B reported the probe results for A), it determines that the node is alive and issues a data retransmission command. If neither is received, it alerts the administrator without waiting for the quality judgment process.

[0186] Data retransmission: After receiving the retransmission command, the QWE client retransmits all the probe data within the time range specified in the command (e.g., 12:00:00-12:05:00 on January 5, 2025). The QWE server will overwrite the original missing data after receiving it to ensure the accuracy of the quality score calculation.

[0187] In the content delivery network scheduling method provided by this invention, an endogenous data collection system covering the external service interface and internal service equipment of a node is established by utilizing the CDN's own network node resources for bidirectional application layer quality detection. Based on this dual-source data, external and internal quality scores of the node are calculated respectively, and a two-dimensional quality assessment model linking service carrying capacity and internal resource status is constructed. According to the fusion and hierarchical judgment of internal and external quality scores, the overall operating status of the node can be identified and classified in a panoramic and accurate manner. When a node failure or sub-healthy state is identified, the linkage scheduling of business traffic and node management operations can be automatically and instantly triggered according to the status judgment result, realizing the closed-loop control of the entire link from quality monitoring, status assessment to scheduling execution. This constructs an endogenous, two-dimensional hierarchical panoramic quality monitoring and linkage scheduling mechanism of CDN, effectively avoiding misjudgments caused by network instability, and automatically completing the business scheduling of faulty nodes, thereby improving the service quality and resource utilization efficiency of CDN.

[0188] Figure 6 This is a structural diagram of a content delivery network scheduling device provided in an embodiment of the present invention. The content delivery network scheduling device includes: an endogenous detection module 601, a two-dimensional evaluation module 602, a panoramic determination module 603, and a linkage scheduling module 604.

[0189] The system comprises: an intrinsic detection module 601, which, based on the content delivery network (CDN)'s own network architecture, organizes a first group of CDN nodes to perform application-layer quality detection on the external service interfaces of the target CDN node to obtain first quality data; and organizes the target CDN nodes to perform application-layer quality detection on the service devices they manage to obtain second quality data; a dual-dimensional evaluation module 602, which calculates a first quality score reflecting the external service quality of the target CDN node based on the first quality data; and calculates a second quality score reflecting the internal service quality of the target CDN node based on the second quality data; a panoramic judgment module 603, which determines the comprehensive quality status of the target CDN node based on the first and second quality scores, the comprehensive quality status being used to identify the node status; and a linkage scheduling module 604, which triggers business traffic scheduling operations for the target CDN node based on the comprehensive quality status.

[0190] In some embodiments, the endogenous detection module 601 is specifically used to: determine multiple CDN nodes belonging to the same scheduling region as the target CDN node as a first group of CDN nodes according to the CDN network's regional division strategy; control each node in the first group of CDN nodes to periodically initiate application layer protocol requests to the virtual IP address of the target CDN node; and record the response result and latency of each application layer protocol request to form first quality data.

[0191] In some embodiments, the aforementioned endogenous detection module 601 is specifically used for: obtaining the address information of all service devices within the target CDN node by a detection control component deployed on the target CDN node; controlling the management server of the target CDN node to initiate application layer protocol requests to the addresses of the service devices according to a preset node-internal detection cycle; and recording the response results and latency of each application layer protocol request initiated to the service devices to form second quality data.

[0192] In some embodiments, the endogenous detection module 601 described above is specifically used to initiate an HTTP request or an HTTPS request using the curl tool.

[0193] In some embodiments, the dual-dimensional evaluation module 602 is specifically used for: statistically analyzing first quality data according to a first preset time window, and calculating the proportion of abnormal dialing tests of the target CDN node; determining the instantaneous state of the target CDN node in multiple consecutive time sub-windows based on the proportion of abnormal dialing tests; determining the external service quality status of the target CDN node according to the distribution of each instantaneous state in a second preset time window and in conjunction with a first preset rule; if the external service quality status is a fault, marking the first quality score as a specific value representing the fault; if the external service quality status is not a fault, obtaining the first quality score through a first normalization calculation based on the latency information in the first quality data.

[0194] In some embodiments, the dual-dimensional evaluation module 602 is specifically used for: statistically analyzing second quality data according to a third preset time window, calculating the proportion of independent dial-up anomalies for each service device within the target CDN node; determining the health status of each service device based on the proportion of independent dial-up anomalies; judging whether the internal service quality status of the target CDN node is abnormal based on the proportion of service devices in an unhealthy state within the target CDN node and in conjunction with a second preset rule; if abnormal, marking the second quality score as a specific value representing a fault; if not abnormal, obtaining the second quality score through a second normalization calculation based on the latency information from healthy service devices in the second quality data.

[0195] In some embodiments, the above-mentioned panoramic determination module 603 is specifically used to: determine whether the first quality score or the second quality score is a specific value that represents a fault; if so, determine that the overall quality status of the target CDN node is a fault; if not, perform a weighted summation of the first quality score and the second quality score according to a preset weight to obtain an overall quality score; compare the overall quality score with a preset grading threshold, and determine the overall quality status according to the comparison result.

[0196] In some embodiments, the scheduling device of the content delivery network described above may further include: a threshold configuration module, which is configured to configure different quality judgment threshold sets for different types of services according to the different quality sensitivity of CDN service types; wherein, for high-sensitivity services, the threshold requirements for latency and dialing success rate in the configured quality judgment threshold set are higher than the corresponding threshold requirements in the quality judgment threshold set configured for low-sensitivity services.

[0197] In some embodiments, the above-mentioned linkage scheduling module 604 is specifically used to: automatically generate a scheduling instruction when the overall quality status of the target CDN node is determined to be faulty; send the scheduling instruction to the CDN scheduling system to trigger the switching of service traffic flowing to the target CDN node to a backup CDN node in the same area; wherein the selection of the backup CDN node is at least partially based on its overall quality status or overall quality score.

[0198] In some embodiments, the scheduling device of the content delivery network described above may further include: an instruction sending module, which is configured to: if a target CDN node is scheduled offline, send an instruction to other CDN nodes in the same region as the target CDN node to stop the quality probing task for the target CDN node; if a new CDN node comes online, send an instruction to other CDN nodes in the same region as the new CDN node to start the quality probing task for the new CDN node.

[0199] In the content delivery network scheduling device provided by this invention, an endogenous data collection system covering the external service interface and internal service equipment of the node is established by utilizing the CDN's own network node resources to conduct bidirectional application layer quality detection. Based on this dual-source data, the external and internal quality scores of the node are calculated respectively, and a two-dimensional quality assessment model linking service carrying capacity and internal resource status is constructed. According to the fusion and hierarchical judgment of the internal and external quality scores, the overall operating status of the node can be identified and classified in a panoramic and accurate manner. When a node failure or sub-healthy state is identified, the linkage scheduling of business traffic and node management operations can be automatically and instantly triggered according to the status judgment result. This realizes the closed-loop control of the entire link from quality monitoring and status assessment to scheduling execution, thereby constructing a CDN-endogenous, two-dimensional hierarchical panoramic quality monitoring and linkage scheduling mechanism, effectively avoiding misjudgments caused by network instability, and automatically completing the business scheduling of faulty nodes, thereby improving the service quality and resource utilization efficiency of the CDN.

[0200] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7 As shown, the electronic device may include: a processor 710, a communications interface 720, a memory 730, and a communications bus 740, wherein the processor 710, the communications interface 720, and the memory 730 communicate with each other through the communications bus 740.

[0201] The processor 710 can call logical instructions in the memory 730 to execute a content delivery network scheduling method. This method includes: organizing a first group of CDN nodes to perform application-layer quality probing on the external service interfaces of a target CDN node based on the CDN's own network architecture, obtaining first quality data; organizing the target CDN nodes to perform application-layer quality probing on the service devices they manage, obtaining second quality data; calculating a first quality score reflecting the external service quality of the target CDN node based on the first quality data; calculating a second quality score reflecting the internal service quality of the target CDN node based on the second quality data; determining the overall quality status of the target CDN node based on the first and second quality scores, the overall quality status being used to identify the node status; and triggering a service traffic scheduling operation for the target CDN node based on the overall quality status.

[0202] Furthermore, the logical instructions in the aforementioned memory 730 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 the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. 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.

[0203] On the other hand, the present invention 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 execute the content delivery network scheduling method provided by the above methods. The method includes: organizing a first group of CDN nodes to perform application layer quality detection on the external service interface of a target CDN node based on the CDN's own network architecture, and obtaining first quality data; organizing the target CDN nodes to perform application layer quality detection on the service devices they manage, and obtaining second quality data; calculating a first quality score reflecting the external service quality of the target CDN node based on the first quality data; calculating a second quality score reflecting the internal service quality of the target CDN node based on the second quality data; determining the comprehensive quality status of the target CDN node based on the first quality score and the second quality score, wherein the comprehensive quality status is used to identify the node status; and triggering a service traffic scheduling operation for the target CDN node based on the comprehensive quality status.

[0204] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a scheduling method for a content delivery network provided by the methods described above. This method includes: organizing a first group of CDN nodes to perform application-layer quality probing on the external service interfaces of a target CDN node based on the CDN's own network architecture, obtaining first quality data; organizing the target CDN nodes to perform application-layer quality probing on the service devices they manage, obtaining second quality data; calculating a first quality score reflecting the external service quality of the target CDN node based on the first quality data; calculating a second quality score reflecting the internal service quality of the target CDN node based on the second quality data; determining the overall quality status of the target CDN node based on the first and second quality scores, the overall quality status being used to identify the node status; and triggering a service traffic scheduling operation for the target CDN node based on the overall quality status.

[0205] 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.

[0206] 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.

[0207] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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; and these 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 the present invention.

Claims

1. A scheduling method for a content delivery network, characterized in that, The method includes: Based on the content delivery network (CDN) architecture, the first group of CDN nodes is organized to perform application layer quality detection on the external service interfaces of the target CDN node to obtain first quality data; and the target CDN node is organized to perform application layer quality detection on the service devices it manages to obtain second quality data. Based on the first quality data, a first quality score reflecting the external service quality of the target CDN node is calculated; and based on the second quality data, a second quality score reflecting the internal service quality of the target CDN node is calculated. Based on the first quality score and the second quality score, the overall quality status of the target CDN node is determined, and the overall quality status is used to identify the node status; Based on the overall quality status, a service traffic scheduling operation is triggered for the target CDN node.

2. The method according to claim 1, characterized in that, The organization's first group of CDN nodes performs application-layer quality probing on the external service interfaces of the target CDN node to obtain first quality data, including: Based on the CDN network's regional division strategy, multiple CDN nodes belonging to the same scheduling region as the target CDN node are identified as the first group of CDN nodes. Control each node in the first group of CDN nodes to periodically send application layer protocol requests to the virtual IP address of the target CDN node; Record the response result and latency of each application layer protocol request to form the first quality data.

3. The method according to claim 1, characterized in that, The organization performs application layer quality detection on the target CDN node and the service devices it manages to obtain second quality data, including: The detection and control component deployed on the target CDN node obtains the address information of all service devices within the node; The management server controlling the target CDN node initiates application layer protocol requests to the address of the service device according to a preset node probing cycle; The response results and latency of each application layer protocol request initiated to the service device are recorded to form the second quality data.

4. The method according to claim 2 or 3, characterized in that, The initiation of the application layer protocol request includes: Use the curl tool to initiate Hypertext Transfer Protocol (HTTP) or HTTPS requests.

5. The method according to claim 1, characterized in that, The step of calculating a first quality score reflecting the external service quality of the target CDN node based on the first quality data includes: The first quality data is statistically analyzed according to the first preset time window, and the proportion of abnormal dialing tests of the target CDN node is calculated. Based on the percentage of abnormal dialing tests, the instantaneous state of the target CDN node within multiple consecutive time sub-windows is determined; Based on the distribution of each instantaneous state within the second preset time window, and in conjunction with the first preset rule, the external service quality status of the target CDN node is determined. If the external service quality status is faulty, then the first quality score is marked as a specific value characterizing the fault; If the external service quality status is not faulty, the first quality score is obtained by first normalization calculation based on the latency information in the first quality data.

6. The method according to claim 5, characterized in that, The first preset rule is configured as follows: When the number of instantaneous fault states reaches the first threshold within the second preset time window, the external service quality state is determined to be faulty. When the number of faulty instantaneous states does not reach the first threshold but reaches the second threshold, and the number of sub-healthy instantaneous states reaches the third threshold, the external service quality state is determined to be faulty. When the number of fault instantaneous states does not reach the first threshold but reaches the second threshold, and the number of sub-health instantaneous states does not reach the third threshold, the external service quality status is determined to be sub-healthy. When the number of fault instantaneous states does not reach the second threshold, but the number of sub-health instantaneous states reaches the third threshold, the external service quality status is determined to be sub-healthy. When the number of faulty instantaneous states does not reach the second threshold and the number of sub-healthy instantaneous states does not reach the third threshold, the external service quality status is determined to be healthy.

7. The method according to claim 1, characterized in that, The step of calculating a second quality score reflecting the service quality within the target CDN node based on the second quality data includes: The second quality data is statistically analyzed according to the third preset time window, and the percentage of independent dial-up anomalies of each service device within the target CDN node is calculated. The health status of each service device is determined based on the percentage of abnormal independent dialing tests. Based on the proportion of service devices in an unhealthy state within the target CDN node, and in conjunction with the second preset rule, it is determined whether the internal service quality status of the target CDN node is abnormal. If it is determined to be abnormal, the second quality score is marked as a specific value characterizing the fault; If the result is determined to be non-abnormal, the second quality score is obtained by calculating the latency information from the health service device in the second quality data through the second normalization.

8. The method according to claim 7, characterized in that, The second preset rule is configured as follows: When the proportion of service devices in a faulty state inside the target CDN node reaches the fourth threshold, the internal service quality status is determined to be abnormal. When the proportion of service devices in a faulty state does not reach the fourth threshold, and the proportion of service devices in a sub-healthy state reaches the fifth threshold, the internal service quality status is determined to be abnormal. When the proportion of service devices in a faulty state does not reach the fourth threshold, the proportion of service devices in a sub-healthy state does not reach the fifth threshold, and the total proportion of service devices in an unhealthy state reaches the sixth threshold, the internal service quality status is determined to be abnormal. When the proportion of service devices in a faulty state does not reach the fourth threshold, the proportion of service devices in a sub-healthy state does not reach the fifth threshold, and the total proportion of service devices in an unhealthy state does not reach the sixth threshold, the internal service quality status is determined to be normal.

9. The method according to claim 1, characterized in that, The overall quality status includes node health, sub-health, or failure; determining the overall quality status of the target CDN node based on the first quality score and the second quality score includes: Determine whether the first quality score or the second quality score is a specific value characterizing a fault; If so, the overall quality status of the target CDN node is determined to be faulty; If not, the first quality score and the second quality score are weighted and summed according to the preset weights to obtain the comprehensive quality score; The overall quality score is compared with a preset grading threshold, and the overall quality status is determined based on the comparison result.

10. The method according to claim 1, characterized in that, Before determining the overall quality status of the target CDN node, the method further includes: Based on the different quality sensitivity of CDN service types, different sets of quality judgment thresholds are configured for different types of services. Specifically, for high-sensitivity services, the threshold requirements for latency and dial-up success rate in the configured quality judgment threshold set are higher than the corresponding threshold requirements in the quality judgment threshold set configured for low-sensitivity services.

11. The method according to claim 1, characterized in that, The step of triggering a service traffic scheduling operation for the target CDN node based on the overall quality status includes: When the overall quality status of the target CDN node is determined to be faulty, a scheduling instruction is automatically generated. The scheduling instruction is sent to the CDN scheduling system to trigger the switching of service traffic flowing to the target CDN node to a backup CDN node in the same area; The selection of the backup CDN node is based at least in part on its overall quality status or overall quality score.

12. The method according to claim 1, characterized in that, After triggering the service traffic scheduling operation for the target CDN node, the method further includes: If the target CDN node is scheduled offline, an instruction is sent to other CDN nodes in the same region as the target CDN node to stop the quality detection task of the target CDN node. If a new CDN node comes online, an instruction is sent to other CDN nodes in the same region as the new CDN node to initiate a quality detection task for the new CDN node.

13. A scheduling device for a content delivery network, characterized in that, The device includes: The intrinsic detection module is used to organize a first group of CDN nodes to perform application layer quality detection on the external service interfaces of the target CDN node based on the content delivery network (CDN) network architecture itself, and to obtain first quality data; and to organize the target CDN nodes to perform application layer quality detection on the service devices they manage, and to obtain second quality data. The dual-dimensional evaluation module is used to calculate a first quality score reflecting the external service quality of the target CDN node based on the first quality data; and to calculate a second quality score reflecting the internal service quality of the target CDN node based on the second quality data. The panoramic judgment module is used to determine the overall quality status of the target CDN node based on the first quality score and the second quality score, wherein the overall quality status is used to identify the node status; The linkage scheduling module is used to trigger service traffic scheduling operations for the target CDN node based on the overall quality status.

14. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the method as described in any one of claims 1 to 12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 12.

Images