A flow scheduling method and apparatus, computing device, and storage medium

Abstract

The application provides a traffic scheduling method and device, a computing device and a storage medium. The first public network IP is probed by using a first probing mode, a first probing result is obtained, the connectivity of each first public network IP is determined, a second public network IP is determined based on each first probing result, target information corresponding to the second public network IP is probed by using a second probing mode, a second probing result is obtained, the service availability of each second public network IP is determined, a third public network IP is determined based on each second probing result, and traffic borne by the third public network IP is processed by using a preset processing mode. The first probing mode is used for preliminary screening, and the second probing mode is used for verification, so that false alarms caused by network jitter are effectively filtered, unnecessary traffic switching is avoided, a closed loop is formed from probing, judging to scheduling processing, manual intervention is reduced, and the fault response time is shortened.

Description

Technical Field

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

[0002] The Domain Name System (DNS), as part of the internet infrastructure, has the core function of converting domain names into Internet Protocol (IP) addresses. This conversion process is called domain name resolution, and DNS, also known as the Domain Name Resolution System, acts as a guide for network access. With the development of internet services, more and more businesses rely on DNS services. Therefore, the ability to quickly respond to traffic scheduling needs related to DNS has become an important metric for evaluating DNS systems.

[0003] Currently, traffic scheduling for DNS systems typically involves requesting manual traffic scheduling when it is determined that the DNS system requires it. However, this manual approach to traffic scheduling increases the cost of operation and maintenance, lacks automatic and timely traffic scheduling capabilities, and results in significant delays in fault detection and switching response, severely impacting business continuity. Summary of the Invention

[0004] To address the problems in the aforementioned related technologies, this application provides a traffic scheduling method, apparatus, computing device, and storage medium that can achieve automatic and timely traffic scheduling, improve the response speed of fault detection and switching response, and enhance business continuity.

[0005] In a first aspect, embodiments of this application provide a traffic scheduling method, the method comprising: The first probing method is used to probe at least one first public Internet Protocol (IP) IP address, and a first probing result is obtained for each first public IP address; each first probing result is used to characterize the connectivity of the corresponding first public IP address. Based on each of the first detection results, a second public IP address is determined, and a second detection method is used to detect the target information corresponding to the second public IP address to obtain a second detection result corresponding to each second public IP address; each second detection result is used to characterize the service availability of the corresponding third public IP address. Based on each of the second detection results, a third public IP address is determined, and the traffic carried by the third public IP address is scheduled and processed using a preset processing method.

[0006] By using the above method, we can first use the first detection method for initial screening, and then use the second detection method for verification. This effectively filters out false alarms caused by network jitter, avoids unnecessary traffic switching, and forms a closed loop from detection and judgment to scheduling and processing, reducing manual intervention and shortening fault response time.

[0007] In one possible implementation, the step of probing at least one first public Internet Protocol (IP) IP address using a first probing method to obtain a first probing result corresponding to each first public IP address includes: Within each first cycle, a connectivity probe is performed on each of the first public IP addresses using the first probe method to obtain the first probe failure rate; If the failure rate of the first probe exceeds a first threshold within a set number of attempts, the first probe result corresponding to the target first public IP address is determined to be unsuccessful; the target first public IP address is any of the first public IP addresses. If the first detection failure rate is less than or equal to the first threshold, then the first detection result corresponding to the target first public IP is determined to be successful.

[0008] This approach avoids triggering alarms based on a single failure, instead basing the judgment on the failure rate of multiple probes. This prevents subsequent processes from being triggered by occasional network fluctuations, thus improving system stability and anti-interference capabilities.

[0009] In one possible implementation, the target information includes at least a domain name; the step of using a second probing method to probe the target information corresponding to the second public IP address, and obtaining a second probing result for each second public IP address, includes: Within each second cycle, the second detection method is used to perform a service availability test on each domain name corresponding to each second public IP address, and the second detection failure rate is obtained. If the failure rate of the second probe exceeds the second threshold within a set number of attempts, the second probe result corresponding to the target second public IP is determined to be unsuccessful; the target second public IP can be any second public IP. If the second detection failure rate is less than or equal to the second threshold, then the second detection result corresponding to the target second public IP is determined to be successful.

[0010] By refining the detection granularity to the domain name level using the above methods, it is possible to accurately determine whether the problem is at the IP level or a problem specific to a particular service, providing a more accurate basis for subsequent scheduling decisions.

[0011] In one possible implementation, each public IP address corresponds to one data center; each data center deploys at least one of the aforementioned public IP addresses; the scheduling and processing of the traffic carried by the third public IP address through a preset processing method includes: If the number of data centers in operation other than the first data center is less than a set number, then each domain name deployed in the first data center will be scheduled to a backup data center, or the origin server will be enabled to resolve each domain name deployed in the first data center; the origin server stores the domain names deployed in each data center; the first data center is the data center corresponding to the third public IP address; If the number of data centers in operation other than the first data center is greater than or equal to the set number, then traffic routing to the first data center is suspended, and each domain name deployed in the first data center is scheduled to the second data center; the second data center is one or more data centers other than the first data center.

[0012] Through the above methods, standard traffic scheduling can be performed for different situations, or the origin server can be enabled as a backup, which can cope with full spectrum issues from common failures to extreme disasters, greatly enhancing business continuity and system resilience. Introducing the origin server or backup data center as the last line of defense ensures that even if the multi-active architecture is paralyzed on a large scale, the business will not be completely interrupted.

[0013] In one possible implementation, scheduling each domain name deployed in the first data center to the second data center includes: Obtain the load level of each second data center, and determine the scheduling weight of each second data center based on the load level and the number of second data centers; Based on the scheduling weight, each domain name deployed in the first data center is scheduled to the second data center.

[0014] By using the above method, traffic is not simply distributed evenly when switching, but the real-time load capacity of each health center is taken into account. This prevents a center from becoming overloaded due to a sudden surge in traffic, which could lead to secondary failures and improves the overall resource utilization rate.

[0015] In one possible implementation, after scheduling the traffic carried by the third public IP address using a preset processing method, the method further includes: The first detection method is used to detect each fourth public IP deployed in the first data center, and the third detection result corresponding to each fourth public IP is obtained; If each of the third detection results and each of the fourth detection results passes the corresponding threshold, then a target processing method is determined based on the preset processing method, and the first data center is processed using the target processing method; the fourth detection result is obtained by detecting each fourth public IP deployed in the first data center using the second detection method; the target processing method is the reverse operation process of the preset processing method.

[0016] Using the above methods, when restoring the first data center, dual detection and verification are also adopted to ensure that the service is truly ready before switching back traffic. There is an escape route in case of failure and a switchback after recovery, forming a complete self-healing closed loop, which avoids the service being overwhelmed by traffic before it is fully ready.

[0017] In one possible implementation, before probing the target information corresponding to the second public IP address using the second probing method, the method further includes: Within each third cycle, if the first probe result of the fifth public IP is unsuccessful, and the distributed lock of the fifth public IP is successfully acquired, then the fifth public IP is determined to meet the probe conditions; the distributed lock is used to indicate that the fifth public IP is in an idle state; the fifth public IP is any of the second public IPs; If the first probe result of the fifth public IP is unsuccessful and the distributed lock of the fifth public IP cannot be obtained, then it is determined that the fifth public IP does not meet the probe conditions. The second detection method for detecting the target information corresponding to the second public IP address includes: The second detection method is used to detect the target information corresponding to the fifth public IP address that meets the detection conditions.

[0018] The above method can ensure that the same public IP address is not operated on by multiple probes or scheduling processes at the same time through a distributed lock mechanism, thus preventing state chaos or duplicate scheduling caused by concurrency in a distributed system.

[0019] Secondly, embodiments of this application provide a traffic scheduling device, the device comprising: The first detection unit is used to detect at least one first public Internet Protocol (IP) IP using a first detection method, and obtain a first detection result corresponding to each first public IP; each first detection result is used to characterize the connectivity of the corresponding first public IP. The second detection unit is used to determine the second public IP address based on each of the first detection results, and to detect the target information corresponding to the second public IP address using a second detection method to obtain a second detection result corresponding to each of the second public IP addresses; each of the second detection results is used to characterize the service availability of the corresponding third public IP address. The scheduling and processing unit is used to determine the third public network IP based on each of the second detection results, and to schedule and process the traffic carried by the third public network IP through a preset processing method.

[0020] Thirdly, embodiments of this application provide a computing device, including: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and implement the method described in the first aspect according to the obtained program instructions.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described in the first aspect.

[0022] This application provides a traffic scheduling method, apparatus, computing device, and storage medium. It can use a first probing method to probe at least one first public IP address, obtaining a first probing result for each first public IP address, thereby determining the connectivity of each first public IP address. Based on each first probing result, a second public IP address can be determined. A second probing method is then used to probe the target information corresponding to the second public IP address, obtaining a second probing result for each second public IP address, thereby determining the service availability of each second public IP address. Finally, based on each second probing result, a third public IP address is determined, and the traffic carried by the third public IP address is scheduled using a preset processing method. By first using the first probing method for initial screening and then verifying with the second probing method, false alarms caused by network jitter are effectively filtered, unnecessary traffic switching is avoided, and a closed loop is formed from probing and judgment to scheduling processing, reducing manual intervention and shortening fault response time. Attached Figure Description

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

[0024] Figure 1 This application provides an illustration of an application scenario for a traffic scheduling method. Figure 2 A flowchart illustrating a traffic scheduling method provided in this application embodiment; Figure 3 A detailed flowchart of a traffic scheduling method provided in an embodiment of this application; Figure 4 A structural block diagram of a traffic scheduling device provided in an embodiment of this application; Figure 5 This is a structural block diagram of a computing device provided in an embodiment of this application. Detailed Implementation

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

[0026] It should be noted that the terms "comprising" and "having" and their variations used in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0027] The terms "first" and "second" used in this document are for descriptive purposes only and should not be construed as indicating relative importance or implying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0028] The word “exemplary” as used below means “serving as an example, embodiment, or illustration.” Any embodiment illustrated as an “exemplary” need not be construed as superior to or better than other embodiments.

[0029] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0030] In one possible embodiment, Figure 1 This illustration shows an application scenario diagram of a traffic scheduling method provided in an embodiment of this application, such as... Figure 1As shown, this scenario includes data centers 101, 102, and 103, an origin server 104, and computing device 105. Data centers 101, 102, and 103 can be simultaneously online, providing services to the outside world as multi-active data centers. Alternatively, only data centers 101 and 102 can be activated, with data center 103 serving as a backup data center. This application does not limit the activation status of the data centers. Similarly, the number of data centers is not necessarily three; it can be more or less. Each data center independently deploys a complete service and has at least one public IP address as a traffic entry point. If all three data centers are activated, under normal circumstances, they share all user requests, and user demands are routed to the nearest or lightest-loaded center. Origin server 104 is independent of the three data centers and stores the most original and complete data of the service. Normally, it does not directly carry ordinary user traffic; its main responsibility is to synchronize data across centers to maintain eventual consistency. Only in extreme scenarios where all three data centers fail will it be activated as a backup site. The computing device 105 can be used to execute a traffic scheduling method provided in this application. The computing device 105 can control the data center 101, data center 102, data center 103 and source station 104, thereby realizing true traffic scheduling.

[0031] The computing device 105 can initiate two types of probes to data centers 101, 102, 103 and origin server 104 via a dedicated intranet line to detect their health status. Data centers 101, 102 and 103 can perform bidirectional data synchronization with origin server 104 via a high-speed intranet dedicated line or a virtual private network (VPN) to ensure that transaction, configuration and other data are ultimately consistent and persistently stored in origin server 104.

[0032] The computing device 104 includes, but is not limited to, mobile phones, tablets, laptops, PDAs, and mobile internet devices (MIDs). It should be noted that this application may include more computing devices, such as one computing device using a first detection method, one using a second detection method, and one performing traffic scheduling. Therefore, different numbers of computing devices can be configured, and this application does not limit the number of computing devices.

[0033] In addition to using computing device 104, the traffic scheduling method provided in this application embodiment can also be deployed on a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Similarly, this application does not limit the number of servers.

[0034] As an essential part of internet infrastructure, DNS's core function is to translate domain names into IP addresses. This process is called domain name resolution, and DNS, also known as the Domain Name System, acts as a guide for network access. With the development of internet services, more and more businesses rely on DNS services. Therefore, the ability to quickly respond to traffic scheduling requests related to DNS has become a crucial metric for evaluating DNS systems.

[0035] Currently, traffic scheduling for DNS systems typically involves requesting manual traffic scheduling when it is determined that the DNS system requires it. However, this manual approach to traffic scheduling increases the cost of operation and maintenance, lacks automatic and timely traffic scheduling capabilities, and results in significant delays in fault detection and switching response, severely impacting business continuity.

[0036] Figure 2 A flowchart of a traffic scheduling method provided in an embodiment of this application is shown, as follows: Figure 2 As shown, the method may include the following steps: Step S201: Use the first probing method to probe at least one first public Internet Protocol (IP) IP address and obtain the first probing result corresponding to each first public IP address.

[0037] In one possible embodiment, the first probing method can be a Transport Layer (Layer 4) Transmission Control Protocol (TCP) port connectivity probe, where the first public IP address is a pre-configured list of public IP addresses deployed at the entrance of each multi-active data center. Step S201 can be implemented as follows: within each first period, the first probing method is used to perform a connectivity probe on each first public IP address once to obtain a first failure rate. Within a set number of attempts, if the first probe failure rate exceeds a first threshold, the first probe result corresponding to the target first public IP address is determined to be a failure; if the first probe failure rate is less than or equal to the first threshold, the first probe result corresponding to the target first public IP address is determined to be a success, wherein the target first public IP address is any first public IP address.

[0038] Specifically, the first period can be preset to 30 seconds. Within each first period, the probe module can initiate a TCP connection request to each public IP address in the configuration list. The default probe port can be 80 or 443, which is not limited in this application. The probe module can send a Synchronize SequenceNumber (SYN) packet to the specified port of the target public IP. If a response to the SYN packet is received within the timeout period, the first probe result is considered successful; if no response is received within the timeout period or a Reset (RST) packet is received, the first probe result is considered unsuccessful. Each probe result can be recorded in a sliding window counter in memory. The number of consecutive probes can be set to 10 (i.e., the set number), and the first threshold is 50%. The sliding window always keeps a record of the 10 most recent probes. Each time a new probe is completed, the window slides forward one position, discarding the earliest record. For any target's primary public IP address, the failure rate is calculated as follows: Failure Rate = Number of failures within the sliding window ÷ 10 × 100%. For example, if 6 out of the last 10 probes to a public IP address timed out without a response, the current failure rate is 60%. After each probe, the sliding window for that target's primary public IP address can be immediately evaluated. Scenario 1: If the failure rate exceeds the first threshold, the test is deemed unsuccessful. If the current failure rate exceeds 50%, the first probe result corresponding to the first public IP address of the target is determined to be unsuccessful.

[0039] Scenario 2: The failure rate does not exceed the first threshold, and the test is considered successful. If the current failure rate is less than or equal to 50%, the first probe result corresponding to the first public IP address of the target is determined to be successful. The system only updates the internal status flag, does not trigger an alarm push, and continues the probe in the next cycle.

[0040] It should be noted that the values ​​of the number of times, the first threshold, and the first period in the above description are not fixed, but can be increased or decreased according to different needs. This application does not limit the above values ​​here.

[0041] Step S202: Determine the second public IP address based on each first detection result.

[0042] In one possible embodiment, for the first public IP address whose first probe result is unsuccessful in step S201, an alarm message can be generated, which includes key fields such as the public IP address, failure rate, and probe timestamp, and pushed to a message queue (such as Kafka) for processing in subsequent step S203.

[0043] For example, suppose the probe records of a data center's public IP address 203.0.113.10 over 10 periods are: success, failure, failure, success, failure, failure, failure, failure, failure, success. Then, the number of failures within the sliding window is 6, resulting in a failure rate of 60%, exceeding the 50% threshold. The system determines the first probe result as unsuccessful and pushes an alarm message to Kafka. The alarm message can include the following content: {"ip": "203.0.113.10", "timestamp": "...", "alert_type": "layer4_failure"}, which represents the public IP address, probe timestamp, and probe result, respectively. It may also include other content, which is not limited in this application. Furthermore, public IP address 203.0.113.10 can also be considered a second public IP address.

[0044] Step S203: Use the second detection method to detect the target information corresponding to the second public IP address, and obtain the second detection result corresponding to each second public IP address.

[0045] In one possible embodiment, the second probing method is specifically an application layer (layer 7) HTTP / HTTPS request probing, and the target information is a list of business domain names carried by the public IP. The first probing method (layer 4 TCP probing) has identified multiple public IPs whose first probing results are unsuccessful. These IPs are determined as second public IPs and await further verification in the second probing method. However, in actual operation, there are multiple parallel processing flows in the system that may simultaneously attempt to initiate layer 7 verification probing on the same public IP. If two flows probe simultaneously and reach different conclusions, it may lead to conflicts in traffic scheduling instructions. Therefore, before executing step S203, the following steps can be performed: In each third cycle, if the first probing result of the fifth public IP is unsuccessful and the distributed lock of the fifth public IP is successfully acquired, then the fifth public IP is determined to meet the probing conditions; if the first probing result of the fifth public IP is unsuccessful and the distributed lock of the fifth public IP cannot be acquired, then the fifth public IP is determined not to meet the probing conditions. Here, the distributed lock is used to indicate that the fifth public IP is in an idle state; the fifth public IP is any second public IP.

[0046] Specifically, the third cycle can be preset to 10 seconds. The timed scanning process iterates through all second public IPs within each third cycle, executing the following admission judgment logic for each. Assuming that at the current moment, the list of second public IPs contains a target IP: 198.51.100.25, whose first probe result in step S201 has been determined as failing, the following verification can be performed on this IP: Step 1: Attempt to acquire a distributed lock. A request can be sent to a distributed lock service (such as one based on Redis or ZooKeeper) to attempt to lock the resource with the key value lock:probe:198.51.100.25, with a lock timeout set to 60 seconds. Step 2: Perform admission judgment based on the acquisition result. Case 1: Successfully acquire the distributed lock: If the distributed lock for this IP is in an idle state (i.e., not held by other processes), and the system successfully acquires the lock, then it is determined that 198.51.100.25 meets the probe conditions. This lock will accompany the entire second probe process until the probe is completed and the second probe result is obtained, at which point the holder will actively release it. During this period, any other process attempting to acquire the lock will be rejected, thus ensuring the uniqueness of the probe operation. Scenario 2: Unable to acquire the distributed lock: If the distributed lock for this IP is already held by another process (for example, the normal processing flow in step S202 is performing a layer 7 HTTP probe on this IP), the system fails to acquire the lock, and it is determined that 198.51.100.25 does not meet the probe conditions. The system directly skips this IP, does not initiate a second probe method, and waits for re-evaluation in the next third cycle.

[0047] In one possible embodiment, after executing the above process, step S203 becomes probing the target information corresponding to the fifth public IP address that meets the probing conditions using a second probing method. Specifically, after the above admission verification, all fifth public IP addresses that meet the probing conditions can be aggregated to form a list to be probed. Subsequently, the second probing method is formally used to initiate application-layer HTTP / HTTPS request probing of the target information (i.e., the list of business domain names) carried by these IP addresses. For example, 198.51.100.25 successfully acquired the distributed lock, and its carried business domain names are api.example.com and www.example.com. Then, HTTP GET requests are initiated to these two domain names respectively, and the returned status codes and response content are verified to see if they meet expectations, thereby obtaining the second probing result corresponding to the IP address. It should be noted that in the traffic scheduling method provided in this application, the above-mentioned distributed lock acquisition process can be executed not only before executing step S203, but also before each probing using the second probing method. This application does not limit this.

[0048] In one possible embodiment, step S201 discovers a public IP address with abnormal connectivity through transport layer TCP probing, but Layer 4 failure does not necessarily mean the service is truly unavailable. It could be due to network link jitter, temporary firewall policies, or overload of intermediate routing devices. Directly triggering traffic switching based on this would cause unnecessary scheduling instability. Therefore, this step uses Layer 7 service verification to distinguish between "real faults" and "network misjudgments," providing an accurate basis for subsequent scheduling decisions. The execution of step S203 can be as follows: Within each second cycle, a service availability probe is performed on each domain name corresponding to each second public IP address using the second probing method, obtaining the second probe failure rate; within a set number of attempts, if the second probe failure rate exceeds a second threshold, the second probe result corresponding to the target second public IP address is determined to be unsuccessful; if the second probe failure rate is less than or equal to the second threshold, the second probe result corresponding to the target second public IP address is determined to be successful, where the target second public IP address is any second public IP address.

[0049] Specifically, the second cycle can be preset to 30 seconds. Within each second cycle, all second public IPs are traversed, and application-layer probing (i.e., the second probing method) is initiated for each domain name associated with each second public IP. The mapping relationship between domain names and public IPs is obtained by querying the configuration management system. For example, if the public IP 198.51.100.25 is associated with the business domain names api.example.com, www.example.com, and pay.example.com, then these three domain names need to be probed separately. The single probe process for each domain name is as follows: The probe module sends an HTTP GET request to the target domain name, setting a timeout of 5 seconds in the request. When sending the request, the system obtains the IP address corresponding to the domain name in advance through DNS resolution to ensure that the probe traffic does indeed pass through the target second public IP. If the returned HTTP status code is within the preset normal range (e.g., 200 to 399) and the response time does not exceed the timeout threshold, the probe is considered successful; if the connection times out, a 5xx error code is returned, or the connection is refused, the probe is considered to have failed. Consistent with the first detection method, the second detection method also employs a sliding window mechanism. The system sets the number of consecutive probes to 10 (i.e., the set number), and the second threshold to 50%. For any target second public IP, the system independently maintains a sliding window of length 10 for each domain name under that IP, recording the success or failure of the last 10 probes. The failure rate of a single domain name is calculated as follows: Failure rate of a single domain name = Number of failures within the sliding window of that domain name ÷ 10 × 100%. After each second-cycle probe is completed, the target second public IP is immediately comprehensively judged. The judgment logic is as follows: Case 1: Failure rate exceeds the second threshold: If the failure rate of each domain name under the second public IP exceeds 50%, the second probe result corresponding to the target second public IP is determined to be unsuccessful. At this time, the system confirms that the IP has a real business failure, rather than simply network jitter. The IP is then identified as a third public IP and enters the traffic scheduling process in step S204. Scenario 2: Failure rate does not exceed the second threshold: If the failure rate of any domain under the second public IP is less than or equal to 50%, the second probe result corresponding to the target second public IP is determined to be successful. In this case, the previous Layer 4 alarm can be determined to be a misjudgment (such as caused by network jitter), and subsequent traffic scheduling operations will not be triggered. The system updates the alarm task status corresponding to the IP to "alarm not handled" and records the reason "Layer 4 misjudgment, Layer 7 normal".

[0050] For example, taking the second public IP address 198.51.100.25 as an example, it is associated with three business domain names. All Layer 7 probe requests to these three domain names timed out, confirming a 100% failure rate, far exceeding the preset 50% threshold. Therefore, the second probe result is deemed a failure, confirming a genuine business failure on this IP, and proceeding to the subsequent scheduling and handling process. If only api.example.com has a 90% failure rate, but www.example.com and pay.example.com have failure rates of 10% and 0% respectively, then the second probe result is deemed a success, indicating only a single business function is abnormal, rather than a shared network entry point or a server-wide failure. The system does not perform a global traffic switch to avoid unnecessary impact from migrating healthy businesses along with it.

[0051] Step S204: Determine the third public IP address based on each second detection result, and schedule the traffic carried by the third public IP address using a preset processing method.

[0052] In one possible implementation, each public IP address corresponds to a data center, and each data center deploys at least one public IP address. Business domain names are resolved to the public IP addresses of each data center through a global load balancing system (such as intelligent DNS), achieving traffic distribution under a multi-active architecture. Step S203 confirms that the third public IP address (i.e., the public IP address with a Layer 7 probe failure rate exceeding the second threshold) has a genuine business failure. At this point, simply taking the failed data center offline and completely switching off all traffic might overload the target data center; if multiple data centers fail simultaneously, it could lead to a complete service interruption. Therefore, the first data center (i.e., the failed data center) corresponding to the third public IP address can be determined first based on its ownership relationship. For example, if the third public IP address 198.51.100.25 belongs to the "Beijing Data Center," then the first data center is the "Beijing Data Center." Subsequently, the system queries the health status of all data centers under the multi-active architecture and counts the number of data centers currently in operation (i.e., online and healthy), excluding the first data center.

[0053] Specifically, assuming the quantity is 1, the system executes a scheduling strategy based on the comparison between the number of healthy data centers and the set quantity, depending on the situation: Scenario 1: If the number of operational data centers other than the primary data center is greater than or equal to one, then the standard offline and weighted scheduling process can be executed. For example, when at least one data center in Shanghai, Guangzhou, etc., is in a healthy operational state in addition to the Beijing data center, the system performs standard offline processing. The specific steps are as follows: Step 1: Suspend traffic routing to the faulty center. The API interface of the global load balancing system can be called to precisely suspend traffic routing for all public IPs of the "Beijing data center" under this domain name. At this time, DNS resolution will no longer return the IP address of the Beijing data center, and new requests will no longer be directed to the faulty center. Step 2: Obtain the load level of the secondary data centers. The system queries the real-time load indicators of each secondary data center (Shanghai, Guangzhou, etc.), including CPU utilization, number of connections, bandwidth utilization, etc. Assume that the current load of the Shanghai data center is 40%, and the current load of the Guangzhou data center is 60%. Step 3: Calculate scheduling weights. The scheduling weight of each healthy center can be calculated based on the load level and the number of secondary data centers. The principle of weight calculation is: the lower the load, the higher the weight, and the more traffic is allocated. One usable weight calculation formula is: Weight of a center = (1 - the center's load rate) / 1 × 100%. Substituting the above data, Shanghai's weight = (1 - 0.4) / [(1 - 0.4) + (1 - 0.6)] × 100% = 0.6 / 1.0 × 100% = 60%; Guangzhou's weight = (1 - 0.6) / 1.0 × 100% = 40%. Step 4: Perform traffic scheduling based on weights. The weight configuration interface of the global load balancing system can be called to schedule user traffic originally routed to the Beijing data center to the Shanghai and Guangzhou data centers at ratios of 60% and 40% respectively. Through this load-aware dynamic allocation, the overload of a single data center due to a sudden increase in traffic is avoided.

[0054] Scenario 2: If the number of operational data centers other than the primary data center is less than one, then each domain name deployed in the primary data center can be redirected to a backup data center, or the origin server can be enabled to resolve each domain name deployed in the primary data center. For example, when all data centers except the Beijing data center in a multi-active architecture fail (i.e., the number of healthy data centers is 0), the system cannot redirect traffic to other multi-active data centers. In this case, an extreme backup strategy is triggered: the system automatically switches the domain name resolution to the backup data center, or enables the origin server, which stores all domain names and business data deployed in each data center.

[0055] In one possible embodiment, after completing the traffic scheduling in step S204, the failback process can be implemented as follows: The system continuously uses a first probing method (Layer 4 TCP probing) to probe each of the fourth public IPs deployed in the first data center, obtaining a third probing result. Here, the fourth public IP refers to all public IPs exposed to the outside world within the data center. Simultaneously, the system uses a second probing method (Layer 7 HTTP / HTTPS probing) to probe the business domain names associated with these fourth public IPs, obtaining a fourth probing result. The system determines that the Beijing data center has recovered when the following conditions are met simultaneously: each third probing result is successful (i.e., Layer 4 TCP probing is continuously successful, and the failure rate drops below the first threshold); each fourth probing result is successful (i.e., Layer 7 business probing is continuously successful, and the failure rate drops below the second threshold).

[0056] In one possible embodiment, after confirming fault recovery, a target processing method can be determined based on a preset processing method. The target processing method is the reverse operation of the aforementioned fault scheduling processing, specifically including: the system calling the global load balancing API to re-enable traffic routing for the first data center under that domain name; adopting a gradual weighted recovery strategy, that is, gradually increasing the traffic ratio in stages, rather than a one-time full rollback. For example, first restore 10% of the traffic and observe for 5 minutes; after confirming stability, restore to 50%; after further confirmation, restore to 100%. After the rollback operation is completed, the system updates the status of the alarm task to "alarm recovered", releases the relevant resources, and completes the entire fault handling loop.

[0057] Taking a complete fault handling example: Stage 1, Fault Occurrence: Layer 4 and Layer 7 probes of the Beijing data center's public IP address 198.51.100.25 both failed, triggering an alarm; Stage 2, Tiered Decision: The Shanghai and Guangzhou data centers were detected to be operational, belonging to the second data center category, and both were healthy (number of healthy centers = 2 ≥ 1), and the method corresponding to situation 1 was executed; Stage 3, Weight Calculation: Based on the Shanghai data center's load of 40%, the corresponding allocation weight for Shanghai was determined to be 60%, and based on the Guangzhou data center's load of 60%, the corresponding allocation weight for Guangzhou was determined to be 40%; Stage 4, Scheduling Execution: The Beijing data center went offline, and traffic was switched to the Shanghai and Guangzhou data centers, with no service interruption during this period; Stage 5, Recovery Probe: The Layer 4 + Layer 7 probe results of the Beijing center were continuously monitored, awaiting a recovery signal; Stage 6, Revert Execution: After confirming recovery, the load of the Beijing data center was gradually reversed in stages: 10% → 50% → 100%.

[0058] This application provides a traffic scheduling method, apparatus, computing device, and storage medium. It can use a first probing method to probe at least one first public IP address, obtaining a first probing result for each first public IP address, thereby determining the connectivity of each first public IP address. Based on each first probing result, a second public IP address can be determined. A second probing method is then used to probe the target information corresponding to the second public IP address, obtaining a second probing result for each second public IP address, thereby determining the service availability of each second public IP address. Finally, based on each second probing result, a third public IP address is determined, and the traffic carried by the third public IP address is scheduled using a preset processing method. By first using the first probing method for initial screening and then verifying with the second probing method, false alarms caused by network jitter are effectively filtered, unnecessary traffic switching is avoided, and a closed loop is formed from probing and judgment to scheduling processing, reducing manual intervention and shortening fault response time.

[0059] In one specific embodiment, Figure 3 A detailed flowchart of a traffic scheduling method provided in this application embodiment is shown below. Figure 3 As shown, the method may include the following steps: Step S301: In each first cycle, a connectivity probe is performed on each first public IP address using the first probe method to obtain the first probe failure rate.

[0060] Step S302: Determine whether the failure rate of the first detection exceeds the first threshold within the set number of attempts. If yes, proceed to step S303; otherwise, proceed to step S304.

[0061] Step S303: Determine that the first probe result corresponding to the target's first public IP address is unsuccessful. Then proceed to step S305.

[0062] Step S304: Determine that the first probe result corresponding to the first public IP address of the target is passed.

[0063] Step S305: Determine whether the distributed lock for the fifth public IP address can be successfully acquired within each third cycle. If yes, proceed to step S306; otherwise, proceed to step S307.

[0064] Step S306: Determine that the fifth public IP address meets the detection requirements. Then proceed to step S308.

[0065] Step S307: Determine that the fifth public IP address does not meet the detection requirements. Then return to step S305.

[0066] Step S308: Use the second detection method to detect the target information corresponding to the fifth public IP address that meets the detection conditions, and obtain the second detection result.

[0067] Step S309: Determine whether the number of data centers in operation other than the first data center is less than a set number. If yes, proceed to step S310; otherwise, proceed to step S311.

[0068] Step S310: Dispatch each domain name deployed in the first data center to the backup data center, or enable the origin server to resolve each domain name deployed in the first data center. Then execute step S312.

[0069] Step S311: Pause traffic routing to the first data center and redirect each domain name deployed in the first data center to the second data center.

[0070] In one possible embodiment, each domain name deployed in the first data center can be scheduled to the second data center in the following way: obtain the load level of each second data center, and determine the scheduling weight of each second data center based on the load level and the number of second data centers; schedule each domain name deployed in the first data center to the second data center based on the scheduling weight.

[0071] Step S312: Use the first detection method to detect each fourth public network IP deployed in the first data center, and obtain the third detection result corresponding to each fourth public network IP.

[0072] Step S313: If each third detection result and each fourth detection result pass the corresponding threshold, then the target processing method is determined based on the preset processing method, and the first data center is processed using the target processing method.

[0073] Based on the same inventive concept Figure 4 A structural block diagram of a traffic scheduling device provided in an embodiment of this application is shown below. Figure 4 As shown, the traffic scheduling device 400 may include: The first detection unit 401 is used to detect at least one first public Internet Protocol (IP) IP using a first detection method, and obtain a first detection result corresponding to each first public IP; each first detection result is used to characterize the connectivity of the corresponding first public IP. The second detection unit 402 is used to determine the second public IP based on each of the first detection results, and to detect the target information corresponding to the second public IP using a second detection method to obtain the second detection result corresponding to each of the second public IPs; each of the second detection results is used to characterize the service availability of the corresponding third public IP. The scheduling processing unit 403 is used to determine the third public network IP based on each of the second detection results, and to schedule the traffic carried by the third public network IP through a preset processing method.

[0074] In one possible implementation, the first detection unit 401 is specifically used to perform a connectivity detection on each of the first public network IPs using the first detection method in each first cycle, and obtain a first detection failure rate. If the failure rate of the first probe exceeds a first threshold within a set number of attempts, the first probe result corresponding to the target first public IP address is determined to be unsuccessful; the target first public IP address is any of the first public IP addresses. If the first detection failure rate is less than or equal to the first threshold, then the first detection result corresponding to the target first public IP is determined to be successful.

[0075] In one possible implementation, the second detection unit 402 is specifically used to perform a service availability detection on each domain name corresponding to each second public IP address using the second detection method in each second period, and obtain the second detection failure rate. If the failure rate of the second probe exceeds the second threshold within a set number of attempts, the second probe result corresponding to the target second public IP is determined to be unsuccessful; the target second public IP can be any second public IP. If the second detection failure rate is less than or equal to the second threshold, then the second detection result corresponding to the target second public IP is determined to be successful.

[0076] In one possible implementation, the scheduling processing unit 403 is specifically used to schedule each domain name deployed in the first data center to a backup data center if the number of data centers in operation other than the first data center is less than a set number, or to enable the origin server to resolve each domain name deployed in the first data center; the origin server stores the domain names deployed in each data center; the first data center is the data center corresponding to the third public IP address; If the number of data centers in operation other than the first data center is greater than or equal to the set number, then traffic routing to the first data center is suspended, and each domain name deployed in the first data center is scheduled to the second data center; the second data center is one or more data centers other than the first data center.

[0077] In one possible implementation, the scheduling processing unit 403 is specifically used to obtain the load level of each second data center and determine the scheduling weight of each second data center based on the load level and the number of second data centers. Based on the scheduling weight, each domain name deployed in the first data center is scheduled to the second data center.

[0078] In one possible implementation, the scheduling processing unit 403 can also be used to probe each fourth public network IP deployed in the first data center using a first probing method, and obtain a third probing result corresponding to each fourth public network IP. If each of the third detection results and each of the fourth detection results passes the corresponding threshold, then a target processing method is determined based on the preset processing method, and the first data center is processed using the target processing method; the fourth detection result is obtained by detecting each fourth public IP deployed in the first data center using the second detection method; the target processing method is the reverse operation process of the preset processing method.

[0079] In one possible implementation, the second detection unit 402 can also be used to determine that the fifth public IP has the conditions for detection if, in each third cycle, the first detection result of the fifth public IP is unsuccessful and the distributed lock of the fifth public IP is successfully acquired; the distributed lock is used to indicate that the fifth public IP is in an idle state; the fifth public IP is any of the second public IPs. If the first probe result of the fifth public IP is unsuccessful and the distributed lock of the fifth public IP cannot be obtained, then it is determined that the fifth public IP does not meet the probe conditions. The second detection method is used to detect the target information corresponding to the fifth public IP address that meets the detection conditions.

[0080] Based on the same inventive concept, embodiments of this application provide a computing device that can implement the traffic scheduling method described above. Please refer to... Figure 5 The computing device 500 includes a memory 501, a processor 502, and a bus 503. The memory 501 stores computer programs executed by the processor 502. The memory 501 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required for running instant messaging functions; the data storage area may store various instant messaging information and operation instruction sets.

[0081] Memory 501 may be volatile memory, such as random-access memory (RAM); memory 501 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 501 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 501 may be a combination of the above-mentioned memories.

[0082] Processor 502 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 502 is used to implement the traffic scheduling method in the above embodiments when calling the computer program stored in memory 501.

[0083] This application embodiment does not limit the specific connection medium between the memory 501 and the processor 502 described above. This application embodiment... Figure 5 The memory 501 and the processor 502 are connected via a bus 503, and the bus 503 is in Figure 5 The connections between other components are shown in thick lines only and are not intended to be limiting. The 503 bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0084] It should be noted that the computing device 500 provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0085] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the traffic scheduling methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the traffic scheduling method, the implementation of the above-described computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0086] Based on the same inventive concept, this application provides a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to implement the aforementioned traffic scheduling method. Since the principle by which the above-described computer program product solves the problem is similar to that of the traffic scheduling method, the implementation of the above-described computer program product can be referred to the implementation of the method, and repeated details will not be elaborated further.

[0087] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0088] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0089] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0090] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0091] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A traffic scheduling method, characterized in that, The method includes: The first probing method is used to probe at least one first public Internet Protocol (IP) IP address, and a first probing result is obtained for each first public IP address; each first probing result is used to characterize the connectivity of the corresponding first public IP address. Based on each of the first detection results, a second public IP address is determined, and a second detection method is used to detect the target information corresponding to the second public IP address to obtain a second detection result corresponding to each second public IP address; each second detection result is used to characterize the service availability of the corresponding third public IP address; Based on each of the second detection results, a third public IP address is determined, and the traffic carried by the third public IP address is scheduled and processed using a preset processing method.

2. The method according to claim 1, characterized in that, The first probing method is used to probe at least one first public Internet Protocol (IP) IP address to obtain a first probing result corresponding to each first public IP address, including: Within each first cycle, a connectivity probe is performed on each of the first public IP addresses using the first probe method to obtain the first probe failure rate; If the failure rate of the first probe exceeds a first threshold within a set number of attempts, the first probe result corresponding to the target first public IP address is determined to be unsuccessful; the target first public IP address is any of the first public IP addresses. If the first detection failure rate is less than or equal to the first threshold, then the first detection result corresponding to the target first public IP is determined to be successful.

3. The method according to claim 1, characterized in that, The target information includes at least a domain name; the second probing method is used to probe the target information corresponding to the second public IP, and the second probing result corresponding to each second public IP is obtained, including: Within each second cycle, the second detection method is used to perform a service availability test on each domain name corresponding to each second public IP address, and the second detection failure rate is obtained. If the failure rate of the second probe exceeds the second threshold within a set number of attempts, the second probe result corresponding to the target second public IP is determined to be unsuccessful; the target second public IP can be any second public IP. If the second detection failure rate is less than or equal to the second threshold, then the second detection result corresponding to the target second public IP is determined to be successful.

4. The method according to claim 1, characterized in that, Each public IP address corresponds to one data center; each data center deploys at least one of the aforementioned public IP addresses; the scheduling and processing of traffic carried by the third public IP address through a preset processing method includes: If the number of data centers in operation other than the first data center is less than a set number, then each domain name deployed in the first data center will be scheduled to a backup data center, or the origin server will be enabled to resolve each domain name deployed in the first data center; the origin server stores the domain names deployed in each data center; the first data center is the data center corresponding to the third public IP address; If the number of data centers in operation other than the first data center is greater than or equal to the set number, then traffic routing to the first data center is suspended, and each domain name deployed in the first data center is scheduled to the second data center; the second data center is one or more data centers other than the first data center.

5. The method according to claim 4, characterized in that, The step of scheduling each domain name deployed in the first data center to the second data center includes: Obtain the load level of each second data center, and determine the scheduling weight of each second data center based on the load level and the number of second data centers; Based on the scheduling weight, each domain name deployed in the first data center is scheduled to the second data center.

6. The method according to claim 4, characterized in that, After scheduling the traffic carried by the third public IP address using a preset processing method, the method further includes: The first detection method is used to detect each fourth public IP deployed in the first data center, and the third detection result corresponding to each fourth public IP is obtained; If each of the third detection results and each of the fourth detection results passes the corresponding threshold, then a target processing method is determined based on the preset processing method, and the first data center is processed using the target processing method; the fourth detection result is obtained by detecting each fourth public IP deployed in the first data center using the second detection method; the target processing method is the reverse operation process of the preset processing method.

7. The method according to claim 1, characterized in that, Before employing the second detection method to probe the target information corresponding to the second public IP address, the method further includes: Within each third cycle, if the first probe result of the fifth public IP is unsuccessful, and the distributed lock of the fifth public IP is successfully acquired, then the fifth public IP is determined to meet the probe conditions; the distributed lock is used to indicate that the fifth public IP is in an idle state; the fifth public IP is any of the second public IPs; If the first probe result of the fifth public IP is unsuccessful and the distributed lock of the fifth public IP cannot be obtained, then it is determined that the fifth public IP does not meet the probe conditions. The second detection method for detecting the target information corresponding to the second public IP address includes: The second detection method is used to detect the target information corresponding to the fifth public IP address that meets the detection conditions.

8. A flow scheduling device, characterized in that, The device includes: The first detection unit is used to detect at least one first public Internet Protocol (IP) IP using a first detection method, and obtain a first detection result corresponding to each first public IP; each first detection result is used to characterize the connectivity of the corresponding first public IP. The second detection unit is used to determine the second public IP address based on each of the first detection results, and to detect the target information corresponding to the second public IP address using a second detection method to obtain a second detection result corresponding to each of the second public IP addresses; each of the second detection results is used to characterize the service availability of the corresponding third public IP address. The scheduling and processing unit is used to determine the third public network IP based on each of the second detection results, and to schedule and process the traffic carried by the third public network IP through a preset processing method.

9. A computing device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium storing a computer program therein, characterized in that: When the computer program is executed by a processor, it implements the method of any one of claims 1-7.

Images