Traffic scheduling method, system, device, medium and program product

Abstract

The application relates to the technical field of computer network and application communication, and more particularly to an application traffic scheduling method, an application traffic scheduling system implementing the method, a computer device, a computer readable storage medium and a computer program product. The method comprises the following steps: obtaining first monitoring data facing service calls and second monitoring data facing terminal accesses; performing integrated analysis on the traffic switching decision model based on the first monitoring data and the second monitoring data to generate a traffic scheduling instruction; and performing a traffic scheduling operation corresponding to the traffic scheduling instruction, wherein the traffic scheduling operation comprises: performing centralized scheduling on traffic corresponding to the first monitoring data; and performing guidance on traffic corresponding to the second monitoring data through an edge network node based on a traffic identifier, and performing connection migration on traffic that has not been guided based on the real-time bandwidth state of a cross-data center link.

Description

Technical Field

[0001] This application relates to the fields of computer networks and application communication technology, and more specifically to an application traffic scheduling method, an application traffic scheduling system implementing the above method, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the development of internet services, core business scenarios have been fully migrated to online applications. Modern applications generally adopt complex architectures such as microservices and distributed systems. While improving flexibility, these architectures also introduce multiple potential points of failure, including network issues and inter-service calls, making ensuring business continuity a critical challenge. Such applications typically handle both end-user access traffic and internal inter-service call traffic supporting business logic. When a failure occurs, how to quickly and reliably schedule and switch between these two types of heterogeneous traffic is the core issue for maintaining service availability.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] To address or at least mitigate one or more of the above problems, embodiments of this application provide an application traffic scheduling method, an application traffic scheduling system implementing the above method, a computer device, a computer-readable storage medium, and a computer program product, which can achieve intelligent and smooth switching of application traffic in hybrid architectures, effectively avoiding the risk of bandwidth congestion in cross-regional network links while ensuring business continuity.

[0005] According to a first aspect of this application, an application traffic scheduling method is provided, the method comprising the following steps: acquiring first monitoring data for service calls and second monitoring data for terminal access; performing integrated analysis based on the first monitoring data and the second monitoring data through a traffic switching decision model to generate a traffic scheduling instruction; executing a traffic scheduling operation corresponding to the traffic scheduling instruction, the traffic scheduling operation comprising: centrally scheduling the traffic corresponding to the first monitoring data; and guiding the traffic corresponding to the second monitoring data through edge network nodes based on traffic identifiers, and performing connection migration for traffic that has not been guided based on the real-time bandwidth status of cross-data center links.

[0006] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the first monitoring data includes at least one of: system success rate, number of transactions per second in the system, number of inter-service call dependencies, and application interface caller identifier.

[0007] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the second monitoring data includes at least one of front-end loading time, JavaScript error rate, user session activity, network access error rate, and terminal device type.

[0008] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the traffic switching decision model is configured to perform the following steps: extracting and quantifying multi-dimensional features from the first monitoring data and the second monitoring data, and performing weighted fusion calculation on the quantized features to generate a total decision score.

[0009] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, multi-dimensional feature extraction of the first monitoring data and the second monitoring data includes: extracting a first type of feature from the first monitoring data, the first type of feature including at least one of enterprise customer level, application programming interface call frequency and business link dependency degree; and extracting a second type of feature from the second monitoring data, the second type of feature including at least one of user activity, access depth, access time period and terminal network environment.

[0010] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the traffic switching decision model is a weighted scoring card model.

[0011] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the weighted scoring card model adopts a dual-threshold decision mechanism, including: comparing the weighted and fused total decision score with a preset trigger threshold and a warning threshold, wherein the warning threshold is lower than the trigger threshold; when the total decision score is higher than the trigger threshold, generating an instruction to immediately execute a switch; when the total decision score is between the warning threshold and the trigger threshold, generating warning information.

[0012] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, centralized scheduling of the traffic corresponding to the first monitoring data is achieved by the gateway control center issuing scheduling instructions to all registered gateway nodes, and the scheduling instructions are used to change the routing target of inter-service traffic.

[0013] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the gateway node registers its service identifier and network address with the gateway control center upon startup.

[0014] As an alternative or supplement to the above solution, a method according to an embodiment of this application further includes: allocating a traffic identifier for identifying a target data center to the terminal's first user request; and guiding the user request through an edge network node based on the traffic identifier includes: when the edge network node receives a user request carrying the traffic identifier, it routes the user request to the corresponding target data center according to the traffic identifier.

[0015] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the edge network node is an edge node of a content delivery network.

[0016] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, performing connection migration for traffic that has not been redirected based on the real-time bandwidth status of the cross-data center link includes: calculating the peak instantaneous bandwidth demand required to perform the migration; determining whether the peak instantaneous bandwidth demand is less than a preset safety ratio of the total bandwidth of the cross-data center link; if it is less, then immediately performing connection migration through the central network device; if it is not less, then waiting for a preset time interval and then repeating the above calculation and determination steps until the conditions are met or a preset timeout period is reached.

[0017] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the traffic scheduling operation further includes: monitoring the real-time traffic splitting progress guided by the edge network node based on the traffic identifier; and dynamically deciding and triggering connection migration through the central network device based on the real-time traffic splitting progress and a preset progress completion threshold, and in conjunction with the real-time bandwidth status of the cross-data center link.

[0018] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, calculating the peak instantaneous bandwidth demand required to perform the migration includes: determining the estimated bandwidth occupied by the residual network connection during the migration based on traffic sampling data within a historical time period, wherein the traffic sampling data includes the peak number of requests per second of the target data center, the average page size, and the peak traffic concentration, and the estimated bandwidth is obtained by weighted averaging of the bandwidth values ​​calculated from multiple sampling points within the historical time period.

[0019] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, sampling points that are closer to the current time are assigned higher weights.

[0020] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the central network device is a load balancer.

[0021] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the method is implemented by an intelligent agent comprising a perception layer, a decision layer, and a service layer, wherein the perception layer is used to acquire the first monitoring data and the second monitoring data, the decision layer is used to run the traffic switching decision model and generate the traffic scheduling instruction, and the service layer is used to respond to the traffic scheduling instruction and coordinate the execution of the traffic scheduling operation.

[0022] According to a second aspect of this application, an application traffic scheduling system is provided, comprising: a data acquisition module for acquiring first monitoring data for service calls and second monitoring data for terminal access; a decision analysis module connected to the data acquisition module for performing integrated analysis based on the first monitoring data and the second monitoring data through a traffic switching decision model to generate a traffic scheduling instruction; and a scheduling execution module connected to the decision analysis module for executing a traffic scheduling operation corresponding to the traffic scheduling instruction, wherein the scheduling execution module comprises: a first scheduling unit for centralized scheduling of traffic corresponding to the first monitoring data; and a second scheduling unit for guiding traffic corresponding to the second monitoring data through edge network nodes based on traffic identifiers, and performing connection migration for traffic that has not been guided based on the real-time bandwidth status of cross-data center links.

[0023] According to a third aspect of this application, a computer device is provided, comprising: a memory; a processor; and a computer program stored on the memory and executable on the processor, wherein execution of the computer program causes any one of the methods described according to a first aspect of this application to be performed.

[0024] According to a fourth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including instructions that, when executed, perform any one of the methods described according to a first aspect of this application.

[0025] According to a fifth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements any one of the methods described according to a first aspect of this application.

[0026] The application traffic scheduling scheme according to one or more embodiments of this application breaks through the limitations of traditional schemes that handle the two types of traffic separately by integrating the analysis of first monitoring data for service calls and second monitoring data for terminal access. This achieves collaborative intelligent decision-making based on the global business status, thereby enabling more accurate determination of the necessity of traffic scheduling. Secondly, during scheduling, this scheme implements targeted operations for the two types of traffic: centralized scheduling is used for inter-service call traffic to ensure rapid and unified switching of backend service links; for terminal user traffic, an innovative phased processing method combining traffic identifier-based guidance and connection migration based on real-time bandwidth status is adopted. This design makes the migration process of user traffic smooth and imperceptible, while strictly adhering to the real-time bandwidth status of cross-data center links during the final connection migration stage, reducing or avoiding the risk of wide area network bandwidth overload or "breakdown" due to excessive instantaneous traffic. Therefore, this scheme achieves automation, intelligence, and security of business traffic scheduling under complex application architectures, effectively ensuring the continuity of core businesses. Attached Figure Description

[0027] The above and / or other aspects and advantages of this application will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. In the drawings: Figure 1 This is a schematic flowchart of an application traffic scheduling method 10 according to one or more embodiments of this application; Figure 2 A schematic structural diagram of an intelligent agent 20 according to one or more embodiments of this application; Figure 3 This is a schematic flowchart illustrating an application traffic scheduling scheme according to one or more embodiments of this application; Figure 4 A schematic block diagram of an application traffic scheduling system 40 according to one or more embodiments of this application; Figure 5 This is a schematic block diagram of a computer device 50 according to one or more embodiments of this application. Detailed Implementation

[0028] The following detailed description is merely exemplary in nature and is not intended to limit the disclosed technology or its application and use. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical fields, background art, or the following detailed description.

[0029] In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0030] Terms such as "comprising" and "including" indicate that, in addition to the units and steps that are directly and explicitly described in the specification, the technical solution of this application does not exclude the presence of other units and steps that are not directly or explicitly described. Terms such as "first" and "second" do not indicate the order of the units in terms of time, space, size, etc., but are merely used to distinguish the units.

[0031] In the following, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings.

[0032] As enterprises deepen their digital transformation, various online applications, especially microservice-based apps, have widely adopted multi-datacenter, multi-active deployment models to support high-concurrency access and business continuity requirements. In such distributed environments, application traffic exhibits a clear binary structure: on the one hand, access requests from end users (such as consumers initiating through mobile applications or web pages) constitute user-side traffic (referred to as C-end traffic), whose experience directly affects user retention and brand reputation; on the other hand, calls and interactions between microservices within the application and between the system and external partners generate service-side traffic (referred to as B-end traffic). This type of traffic typically involves critical business links and data consistency, and its stability directly affects the execution of core business operations.

[0033] When a single data center experiences a partial failure, performance bottleneck, or scheduled maintenance, it is often necessary to redirect business traffic, either wholly or partially, to other healthy data centers. This process requires not only a smooth migration of access points for end-users (C-end) to avoid session interruptions and experience degradation, but also simultaneous coordination of routing changes for numerous backend service calls (B-end) to ensure the continuity of business logic and the correctness of data processing. Especially when traffic is redirected between data centers across different regions, the large amount of data synchronization and request forwarding consumes WAN link bandwidth. Without effective bandwidth awareness and protection mechanisms, link congestion can easily occur, exacerbating business latency or even causing redirection failure.

[0034] Therefore, in actual operation and disaster recovery scenarios, how to integrate the perception, decision-making, and execution of collaborative scheduling of B-end and C-end traffic, and ensure the bandwidth security of cross-regional network links in real time during the scheduling process, has become a key technical challenge to ensure the high availability of distributed applications and user experience. This scenario is widely found in industries with extremely high requirements for business continuity, such as finance, e-commerce, social media, and cloud computing. Effective solutions can significantly improve the system's automatic disaster recovery capabilities and resource utilization efficiency.

[0035] Please refer to the attached diagram below. Figure 1 This is a schematic flowchart of an application traffic scheduling method 10 according to one or more embodiments of this application.

[0036] like Figure 1 As shown, in step 101, the first monitoring data for service calls and the second monitoring data for terminal access are obtained.

[0037] This step aims to provide comprehensive data input for subsequent intelligent decision-making. Its core lies in the simultaneous collection of two types of data that reflect the operational status of backend services and the user experience of the frontend, thereby constructing a unified view that integrates the health of the business support system and the perceived status of the end user.

[0038] In one or more embodiments, the first monitoring data is used to characterize the quality and correlation of inter-service traffic (i.e., B-end traffic). Exemplarily, such data may include one or more of the following: system success rate (e.g., application programming interface (API) call success rate or transaction success rate), system transactions per second (TPS), number of inter-service call dependencies (used to identify critical links and the scope of failure impact), and API caller identifiers (used to distinguish traffic from different enterprise customers or internal systems), etc. This data typically reflects the processing capacity, stability, and complexity of the business chain in the application backend.

[0039] In one or more embodiments, the second monitoring data is used to characterize the experience quality and behavioral characteristics of end-user traffic (i.e., C-end traffic). For example, such data may include one or more of the following: front-end loading time (e.g., page first-screen rendering time), JavaScript error rate, user session activity (e.g., session duration and operation frequency), network access error rate (e.g., HTTP error code ratio), and terminal device type, operating system, and network environment. This data is directly related to the user's intuitive experience and the likelihood of successfully completing operations while using the application.

[0040] By acquiring the two types of data in parallel in step 101, method 10 ensures that the entire business chain from the user interaction entry point to the backend service processing is observable. This integrated data acquisition mechanism allows both business interruptions caused by backend service anomalies and user experience degradation caused by frontend network or code issues to be included in the evaluation framework in a timely and equal manner, creating the necessary conditions for subsequent steps to execute intelligent decisions based on multi-dimensional business characteristics.

[0041] In step 103, based on the first monitoring data and the second monitoring data, an integrated analysis is performed through the traffic switching decision model to generate traffic scheduling instructions.

[0042] It is important to emphasize that the decision analysis process in step 103 does not examine technical or user metrics in isolation. Instead, it integrates and weighs the primary monitoring data reflecting service-side health with the secondary monitoring data reflecting user-side experience within a unified business continuity framework, thereby generating intelligent scheduling decisions.

[0043] The traffic switching decision model aims to assess the comprehensive necessity, urgency, and potential business impact of performing traffic scheduling operations based on the current system state revealed by multi-dimensional data. In one or more embodiments, the traffic switching decision model is configured to perform a series of steps to achieve the aforementioned integrated analysis. For example, the model first extracts and quantifies multi-dimensional features from the input first and second monitoring data, transforming various types of raw monitoring data into unified, computable quantitative indicators. Subsequently, the model employs specific fusion computation logic to comprehensively analyze these quantified features and output a judgment result that supports decision-making, such as a comprehensive score representing the benefits or risks of switching, a clear classification label, or a direct operational recommendation. This process elevates the decision-making basis from fragmented indicators to a comprehensive assessment of the business situation.

[0044] In one or more embodiments, when performing multi-dimensional feature extraction and quantification, the traffic switching decision model can extract a first type of feature from the first monitoring data, such as enterprise customer level, API call frequency, and business link dependency. For example, the quantification of enterprise customer level can be based on the API caller identifier in the original data (i.e., the first monitoring data), by querying a preset customer value mapping table to map different caller identifiers to a level score of 1 to 5. The quantification of API call frequency can combine TPS in the original data with historical baseline data, for example, calculating the percentage of the current TPS to the historical peak TPS and mapping it to a score of 0 to 10. The quantification of business link dependency can be based on the number of service call dependencies in the original data, for example, directly counting the number of downstream core systems that depend on the currently abnormal service as its score, or superimposing a link importance weighted score based on business knowledge. These quantified features collectively characterize the state of B-end traffic from the perspective of business importance and scope of influence.

[0045] Meanwhile, the traffic switching decision model can extract a second type of feature from the second monitoring data, such as user activity, access depth, access time period, and terminal network environment. For example, user activity can be quantified based on user session activity in the original data (i.e., the second monitoring data), for instance, by classifying users into activity levels from 1 to 10 based on their recent session frequency and duration. Access depth can be quantified based on the analysis of the user's current session's interaction sequence, or indirectly inferred from front-end loading time and JavaScript error rate. For example, a session currently filling out a complex form (usually accompanied by specific API calls and front-end interactions) might be assigned a high sensitivity score if loading time increases dramatically or the error rate rises. Access time period can be quantified directly based on the timestamps of the monitoring data, combined with a preset time-period business traffic density model (e.g., assigning a score of 10 to peak business periods and 1 to off-peak periods in the early morning). The quantification of the terminal network environment can be achieved by combining terminal device type and network access error rate. For example, for terminal users using 4G mobile networks with a high network error rate, their environment may be judged as sensitive to handover latency, thus being assigned a negative score with higher risk. By simultaneously extracting heterogeneous features from B-end and C-end users and quantifying them based on business logic, this model constructs a complete and computable feature profile covering the backend service chain and the frontend user chain.

[0046] The aforementioned traffic switching decision model can employ various interpretable or machine learning models to implement the feature fusion and decision-making functions. In one or more embodiments, the traffic switching decision model can be specifically implemented as a weighted scorecard model. In the weighted scorecard model, a weight coefficient can be assigned to each of the aforementioned quantified features (e.g., customer level score, API call frequency score, user activity score, etc.), and a final decision score can be calculated by weighted summation. Different categories (e.g., B-end features, C-end features, and possible system-level features) can be assigned different category-based weights, and different features within the same category can also have different individual weights. These weights reflect the relative importance of different features in the final decision, and their setting typically needs to be determined jointly by combining business objectives, operational experience, and historical data analysis. For example, higher weights can be given to the level features of core customers to reflect the priority of ensuring their business continuity; higher weights can also be given to access features during peak business hours to avoid the wider impact that switching during critical periods might cause. In one or more embodiments, these weights are not fixed, but can be continuously optimized and adjusted dynamically by backtesting and analyzing historical fault and switchover data, thereby enabling the model's decision logic to continuously adapt to business changes and operational practices. In one specific implementation, an online learning mechanism can be introduced, allowing the model to continuously optimize weight parameters based on real-time feedback data, thereby effectively responding to sudden changes in business models (such as drastic changes in traffic characteristics during e-commerce promotional events).

[0047] In other embodiments, the traffic switching decision model may also take other forms, such as rule-based decision trees, support vector machines (SVMs), or trained neural network models that can learn more complex nonlinear relationships between features from historical data to make decisions.

[0048] For implementations using a weighted scorecard model, the decision-making mechanism can be designed in various ways. In one specific implementation, the weighted scorecard model can employ a dual-threshold decision-making mechanism to generate the final traffic scheduling instruction. This mechanism compares the calculated total decision score with a preset lower warning threshold and a higher trigger threshold. When the total decision score is higher than the trigger threshold, the model can generate an instruction to immediately execute the switchover; when the total decision score is between the warning threshold and the trigger threshold, the model can generate a warning message to notify operations personnel to intervene in the decision-making; if it is lower than the warning threshold, no operation is triggered. In other implementations, the decision-making mechanism can also be a single threshold comparison, or a multi-level response mechanism containing more threshold levels, such as setting multiple tiers like "observation," "warning," "mild switchover," and "forced switchover," with each tier corresponding to different automated response actions or notification strategies.

[0049] In step 105, the traffic scheduling operation corresponding to the traffic scheduling instruction is executed.

[0050] This step is a key execution phase for realizing business traffic migration. It aims to adopt differentiated scheduling mechanisms based on the different technical characteristics and business sensitivities of B-end and C-end traffic, and to ensure the reasonable and secure use of critical resources (such as cross-regional WAN bandwidth) during the overall scheduling process. This will ensure business continuity while minimizing the potential impact of scheduling behavior on system stability and user experience.

[0051] The traffic scheduling operation in step 105 includes centralized scheduling of the traffic corresponding to the first monitoring data, namely, inter-service call traffic (B-end traffic). This scheduling mode aims to solve the problem of unified and rapid changes in the call relationships among numerous backend service instances.

[0052] In one or more embodiments, this centralized scheduling can be implemented through a unified gateway control center. Specifically, during normal system operation, each gateway node handling inter-service traffic (e.g., an API gateway) can proactively register its service identifier and network address with the gateway control center upon startup. When the decision-making layer issues an instruction to switch B-end traffic, the scheduling execution layer can initiate a scheduling request to the gateway control center. The gateway control center can then issue batch routing change instructions (i.e., scheduling instructions) to all registered gateway nodes affected by this scheduling. These instructions instruct each gateway node to reroute internal service call requests originally directed to a faulty or high-load data center to a designated healthy data center. Through this centralized control and distributed execution model, global routing switching of B-end traffic under a complex microservice architecture can be completed efficiently and consistently.

[0053] In other embodiments, centralized scheduling can also be implemented through other mechanisms, such as issuing new routing rules through a unified configuration center, or directly modifying the health status and routing weight of service instances using service registration and discovery components.

[0054] The traffic scheduling operation in step 105 also includes implementing a phased and differentiated collaborative scheduling strategy for the traffic corresponding to the second monitoring data, namely, end-user access traffic (C-end traffic). This strategy aims to solve the problem that a single scheduling mechanism cannot simultaneously meet the often conflicting goals of "smooth user experience" and "complete fault recovery." Its core idea is: in the first phase, a flexible, identifier-based guidance process smoothly transitions some user sessions to the new data center; in the second phase, a strictly conditional forced migration securely cleans up the remaining residual connections, thereby achieving eventual consistency switching of traffic while ensuring user experience.

[0055] The first phase implements traffic identification-based routing, designed to minimize disruption to online users. In one or more embodiments, the execution of the first phase relies on the allocation of traffic identifiers. For example, when an end user initiates a new session or makes an initial request, a backend intelligent scheduling system or dedicated routing service assigns a unique traffic identifier (e.g., an encrypted token or a specific cookie value) to the request, encoding information about the target data center, and returns it to the client via an HTTP response. All subsequent requests for that user session will carry this identifier. Edge network nodes acting as traffic access points, such as edge servers in a content delivery network (CDN), are configured to recognize this traffic identifier. When an edge node detects a valid traffic identifier in a request, it prioritizes forwarding the request based on the routing target indicated by that identifier, thus bypassing its default load balancing logic. In this way, massive amounts of dispersed user traffic can be seamlessly redirected to new data centers at the network edge, completely transparent to users, achieving a preliminary, lossless traffic migration experience.

[0056] While the first phase can migrate most of the traffic, in practice, some "residual traffic" cannot be immediately switched using identifiers. This includes persistent connections that haven't ended, client requests that haven't received new identifiers in time, or old requests caused by network latency. To ensure the integrity of fault isolation and the eventual release of resources, a second phase—forced migration of the residual traffic—must be introduced. Because such forced migration operations (typically involving global modifications to routing rules on the central load balancer) instantly transfer the pressure of residual connections to cross-datacenter links, there is a risk of bandwidth capacity being exhausted and triggering a cascading failure. Therefore, in some embodiments of this application, the execution of the second phase does not immediately follow the first phase, but is placed within a decision-making loop prioritizing "bandwidth security."

[0057] In one or more embodiments, the forced migration is triggered based on a comprehensive two-condition judgment. The system can track in real time the proportion or absolute number of requests that still access the old data center after being redirected by an identifier, i.e., the "real-time traffic offloading progress". Only when this real-time traffic offloading progress reaches a preset completion threshold (indicating that residual traffic has been reduced to a low level) will the system begin to assess the bandwidth security of performing the forced migration. The final forced migration triggering decision is based on a logical AND judgment of two conditions: "real-time traffic offloading progress has reached or exceeded the progress completion threshold" and "real-time bandwidth status meets security conditions". Only when both conditions are met will the system generate an instruction to trigger the final connection migration through the central network device. This logic ensures that the migration operation is performed after most traffic has been smoothly migrated out, while avoiding periods of network link congestion. In embodiments employing this two-condition judgment, the specific implementation can also include more complex strategies, such as introducing a priority mechanism for different fault levels, allowing for appropriate relaxation of the progress threshold under extremely high-priority faults; or dynamically adjusting the progress conditions when bandwidth is extremely abundant.

[0058] In other embodiments, the triggering decision for forced migration may be solely related to whether "real-time bandwidth status meets safety conditions." This type of design may be suitable for scenarios with extreme requirements for fault recovery time, or where the efficiency of the first-phase flexible bootstrapping is extremely high, and residual traffic is inherently controllable. In such embodiments, the core focus of the system is the bandwidth security of the forced migration action itself. Once the system confirms through calculation (e.g., calculating the peak instantaneous bandwidth demand and determining that it is less than the link's safety capacity) that immediately executing the migration will not overwhelm the network link, it can trigger the migration command without continuously waiting or strictly judging whether the progress of flexible bootstrapping has reached a certain threshold. This can further shorten the overall fault recovery time.

[0059] In one or more embodiments, the calculation of instantaneous peak bandwidth demand relies on the analysis and prediction of historical traffic sampling data. This calculation aims to estimate the amount of cross-datacenter data transfer that residual connections might suddenly generate if a forced migration were immediately implemented, and its accuracy directly affects the effectiveness of the bandwidth protection mechanism. To achieve this goal, the data foundation required for the calculation can first be established. For example, the system can collect traffic snapshot data of the target data center within a recent configurable historical time window. This data typically includes, but is not limited to: peak requests per second during the sampling period, average page size served, and coefficients reflecting the concentration of traffic during peak periods.

[0060] Based on the aforementioned data, various prediction algorithms can be used to estimate the peak instantaneous bandwidth demand. In one specific embodiment, a weighted average-based estimation method is employed. Specifically, let the time window for one sampling be t seconds, and the peak number of requests per second observed within this window be QPS.t The peak traffic concentration is η, and the average page size is PG. avg First, the total page views (PV) within this window can be estimated. t : Furthermore, the estimated bandwidth BD generated within this time window t bps (The unit is bits per second) can be calculated using the following formula: By calculating separately for multiple (e.g., n) such sampling windows, a series of bandwidth estimates {BD} can be obtained. t1 ,BD t2 , ..., BD tn The estimated peak instantaneous bandwidth demand (BD) now Then, it is obtained by taking a weighted average of this series of values, that is: Among them, w i The weighting values ​​are used to assign weights to sampling points that are closer to the current time. In this weighting process, higher weights can be assigned to sampling points that are closer to the current time, so that the estimated value better reflects recent traffic trends.

[0061] To further optimize the timeliness and accuracy of the forecast, in one or more embodiments, the calculation of BD can also be performed. now Sometimes, or in subsequent trend assessments, an analysis of bandwidth change trends can be incorporated. For example, the method of calculating the "center difference value" can be used to determine a downward trend in bandwidth, such as: Where BD represents the bandwidth sequence and h is the step size. This calculation can sensitively detect whether bandwidth utilization has entered a downward trend, thus helping to determine whether the timing for a forced migration is safe.

[0062] It should be noted that the above calculation method based on specific formula derivation and weighted average is only an exemplary implementation. In other embodiments, different mathematical models or prediction algorithms can be used to achieve the same purpose, such as using a sliding window moving average to smooth fluctuations, or applying a time series prediction model (such as exponential smoothing) to directly predict bandwidth requirements at future times.

[0063] In obtaining peak instantaneous bandwidth demand (BD) nowThen, this can be compared with a key "safe bandwidth threshold" to make a final decision. This safe bandwidth threshold is typically derived by multiplying the total physical bandwidth capacity of the cross-data center links by a preset safety factor (e.g., 0.8, or 80%). This safety factor is designed to reserve buffer space for normal fluctuations in network traffic, preventing the actual link utilization from reaching saturation due to estimation errors or sudden bursts of traffic. Through this comparison mechanism between "estimated peak" and "safe capacity," the system can quantitatively assess the bandwidth risk of forced migration operations, thereby determining whether to execute them immediately.

[0064] After a forced migration is triggered, the command can be sent to the central network device (such as the global load balancer F5) to perform a global switch of routing rules and clean up any remaining connections. If the above conditions are not met, especially if the estimated bandwidth exceeds the limit, the system will enter a waiting state, re-collecting data, assessing progress, and calculating bandwidth after a preset time interval. This process will repeat until the conditions are met or the accumulated waiting time reaches the preset timeout limit.

[0065] Through the precise coordination of the two-stage strategy described above—the first stage aims for a smooth user experience, while the second stage strives for a thorough switchover while ensuring bandwidth security—step 105 achieves intelligent and robust scheduling of C-end traffic. Combined with the aforementioned centralized scheduling of B-end traffic, this method ultimately constitutes a complete and reliable integrated application traffic scheduling solution.

[0066] Figure 2 This is a schematic structural diagram of an intelligent agent 20 according to one or more embodiments of this application. As shown in the figure, the intelligent agent 20 adopts a layered and decoupled architecture design, which consists of a perception layer, a decision layer and a service layer. These three layers work together to realize a complete closed loop from data collection and intelligent analysis to scheduling execution, and can serve as the implementation carrier of the application traffic scheduling method (such as method 10) described in this application.

[0067] The perception layer serves as the interface between the intelligent agent 20 and the operating environment, responsible for continuously acquiring raw data reflecting the application system's status. In one or more embodiments, the perception layer integrates various monitoring tools and data acquisition probes to simultaneously collect first-level monitoring data (such as system success rate and transaction count) for inter-service calls and second-level monitoring data (such as front-end loading time and user activity) for end-user access. This real-time or near-real-time data provides comprehensive factual evidence for subsequent intelligent decision-making.

[0068] The decision layer is the "brain" of Agent 20, responsible for integrated analysis and intelligent judgment of the data reported by the perception layer. Internally, this layer operates the traffic switching decision model described earlier. This model performs multi-dimensional feature extraction, quantification, and fusion calculations on the input B-end and C-end data, ultimately generating instructions on whether to perform traffic scheduling and how to schedule it. The existence of the decision layer transforms traffic scheduling from an operation relying on human experience and judgment into an automated and intelligent decision-making process based on quantitative rules and models.

[0069] The service layer is the "executor" of Agent 20, responsible for transforming the abstract instructions generated by the decision layer into specific, executable scheduling operations. This layer encapsulates the control logic for centralized scheduling of B-end traffic, the identification management and guidance logic for seamless switching for C-end users, and protective algorithms to ensure the security of cross-regional wide area network bandwidth. Through the service layer, intelligent decision-making can be applied accurately and securely to the actual network infrastructure and traffic paths.

[0070] Figure 3 This is a schematic flowchart illustrating an application traffic scheduling scheme according to one or more embodiments of this application. The diagram generally depicts the collaborative process and key components of the system performing integrated scheduling of B-end and C-end traffic after receiving a switching instruction. As shown, the scheduling scheme does not treat the two types of traffic in isolation, but rather initiates and coordinates them through a unified control logic. This ensures that in fault or maintenance scenarios, front-end user access and back-end service calls can be synchronously and orderly migrated to the target data center, thereby maintaining the overall continuity and consistency of business operations.

[0071] Specifically, this integrated scheduling scheme comprises two parallel execution branches. The first is the C-end traffic switching branch, which employs a phased and refined scheduling strategy. In one or more embodiments, this process first uses a "labeled traffic routing" stage to allocate and utilize traffic identifiers for user requests from the APP client, achieving silent and precise traffic redirection at the edge network side, allowing most users to seamlessly access the new data center. Subsequently, in the "F5 switching + bandwidth protection" stage, the system performs forced switching and connection cleanup on residual connections that were not guided by labels, while meeting cross-regional bandwidth security conditions. This ensures that the links do not become overloaded, completing the final closed loop of traffic switching.

[0072] The other branch is the B-end traffic switching branch, which focuses on centralized and unified control of inter-service call traffic. In one or more embodiments, this process is centered on a "B-end gateway control center." Once the integrated switching process is initiated, the control center issues unified switching instructions to all registered sub-gateways. Each sub-gateway updates its routing policy in real time according to the instructions, thereby redirecting internal service requests originally directed to the source data center in batches and synchronously to healthy data centers. This centralized control and distributed execution model ensures the efficiency and consistency of B-end traffic switching in complex microservice architectures.

[0073] Figure 3 The document clearly states that the switching actions between the C-end and the B-end originate from the same "initiate switching" decision point and ultimately converge into the result state of "integrated switching between B and C ends". This reflects the core idea of ​​this application: through a collaborative framework, user-oriented traffic scheduling and service-oriented traffic scheduling are logically unified and executed in a coordinated manner, thereby solving the timing mismatch and state inconsistency problems that may occur when switching between the two types of traffic in traditional solutions, and realizing truly integrated intelligent scheduling.

[0074] Figure 4 This is a schematic block diagram of an application traffic scheduling system 40 according to one or more embodiments of this application. Figure 4 As shown, the application traffic scheduling system 40 includes a data acquisition module 410, a decision analysis module 420, and a scheduling execution module 430, wherein the scheduling execution module 430 includes a first scheduling unit 431 and a second scheduling unit 432. These modules and units are interconnected through data and instruction streams, work together, and jointly constitute the hardware and software carrier for implementing the aforementioned application traffic scheduling method.

[0075] The data acquisition module 410 is the data perception entry point of the system 40, responsible for continuously acquiring and integrating monitoring data from different layers of the application system. In one or more embodiments, the monitoring data acquired by this module is divided into first monitoring data oriented towards service calls and second monitoring data oriented towards terminal access.

[0076] The decision analysis module 420 is connected to the data acquisition module 410, receiving the monitoring data provided by it and performing intelligent analysis. In one or more embodiments, the decision analysis module 420 has a built-in traffic switching decision model, which is configured to perform multi-dimensional feature extraction and quantification on the first and second monitoring data, and perform weighted fusion calculation on the quantified features to generate a total decision score. The multi-dimensional feature extraction includes extracting a first type of feature (such as at least one of enterprise customer level, API call frequency, and business link dependency) from the first monitoring data and extracting a second type of feature (such as at least one of user activity, access depth, access time period, and terminal network environment) from the second monitoring data. In one or more embodiments, the traffic switching decision model is specifically implemented as a weighted scoring card model. For embodiments using the weighted scoring card model, its decision mechanism may include a dual-threshold decision mechanism: comparing the weighted fusion decision score with a preset trigger threshold and a warning threshold (the warning threshold is lower than the trigger threshold); when the decision score is higher than the trigger threshold, generating an instruction to immediately execute the switching; when the decision score is between the warning threshold and the trigger threshold, generating warning information. It should be noted that the weighted scoring card model and the dual threshold mechanism are only examples. In other embodiments, the decision analysis module 420 may also use other models such as decision trees and neural networks and corresponding decision logic to achieve intelligent analysis.

[0077] The scheduling execution module 430 is connected to the decision analysis module 420 and is used to receive traffic scheduling instructions and execute specific traffic scheduling operations. This module contains two units responsible for scheduling different types of traffic. The first scheduling unit 431 is used for centralized scheduling of inter-service call traffic (B-end traffic) corresponding to the first monitoring data. In one or more embodiments, the first scheduling unit 431 includes or interfaces with a gateway control center, which is used to issue scheduling instructions to all registered gateway nodes to change the routing target of inter-service traffic. The gateway nodes can register their service identifier and network address with the gateway control center upon startup.

[0078] The second scheduling unit 432 is used to schedule the terminal user access traffic (C-end traffic) corresponding to the second monitoring data. Its design integrates flexible guidance and protective migration. In one or more embodiments, the second scheduling unit 432 includes a tag management module for assigning a traffic identifier to the terminal's first user request to identify the target data center. The second scheduling unit 432 may also include an edge scheduling module, which configures or coordinates edge network nodes (such as edge nodes of a content delivery network) so that when the edge network node receives a user request carrying the traffic identifier, it can route the request to the corresponding target data center based on the identifier. In addition, the second scheduling unit 432 may also include a traffic splitting progress monitoring module for monitoring the real-time traffic splitting progress guided by the traffic identifier; and a migration decision module for dynamically deciding and triggering connection migration through the central network device based on the real-time traffic splitting progress and a preset progress completion threshold, combined with the real-time bandwidth status of the cross-data center link. In one or more embodiments, the migration decision-making process is specifically completed collaboratively by a bandwidth calculation submodule, a condition judgment submodule, and a migration control submodule: the bandwidth calculation submodule calculates the peak instantaneous bandwidth requirement needed to execute the migration; the condition judgment submodule determines whether the peak value is less than a preset safety ratio of the total bandwidth of the cross-data center links; and the migration control submodule, based on the judgment result, immediately executes the migration or enters a loop waiting for reassessment. The bandwidth calculation submodule can obtain a bandwidth estimate based on historical traffic sampling data (such as the peak number of requests per second, average page size, and peak traffic concentration of the target data center) by weighted averaging the bandwidth values ​​calculated from multiple sampling points, where sampling points closer to the current moment can be assigned higher weights. In one or more embodiments, the central network device is a load balancer.

[0079] Figure 5 This is a schematic block diagram of a computer device 50 according to one or more embodiments of this application. The computer device 50 includes a memory 510, a processor 520, and a computer program 530 stored on the memory 510 and executable on the processor 520, the execution of which causes the method 10 described above to be performed.

[0080] Furthermore, as described above, this application can also be implemented as a computer-readable storage medium storing a program for executing the process described in method 10 above. Here, various types of computer-readable storage media can be used, such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memories (e.g., ROM, non-volatile memory, etc.), and tapes (e.g., magnetic tape, cassette tape, etc.).

[0081] This application can also be implemented as a computer program product comprising a computer program that, when executed by a processor, performs the steps of method 10 as described above.

[0082] Where applicable, the various embodiments provided in this application may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be combined into composite components comprising software, hardware, and / or both. Where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be divided into sub-components comprising software, hardware, or both. Additionally, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0083] The software (such as program code and / or data) according to this application may be stored on one or more computer-readable storage media. It is also contemplated that the software identified herein may be implemented using one or more networked and / or otherwise general-purpose or special-purpose computers and / or computer systems. Where applicable, the order of the various steps described herein may be changed, combined into compound steps, and / or divided into sub-steps to provide the features described herein.

[0084] The embodiments and examples presented herein are provided to best illustrate embodiments of this application and its particular applications, thereby enabling those skilled in the art to implement and use this application. However, those skilled in the art will understand that the above description and examples are provided for ease of illustration and example only. The descriptions presented are not intended to cover all aspects of this application or to limit this application to the precise forms disclosed.

Claims

1. An application traffic scheduling method, characterized in that, The method includes: Obtain the first monitoring data for service calls and the second monitoring data for terminal access; Based on the first monitoring data and the second monitoring data, an integrated analysis is performed through a traffic switching decision model to generate traffic scheduling instructions; Execute the traffic scheduling operation corresponding to the traffic scheduling instruction, the traffic scheduling operation including: Centralized scheduling of the traffic corresponding to the first monitoring data; and For the traffic corresponding to the second monitoring data, it is guided through edge network nodes based on traffic identifiers, and connection migration is performed on the traffic that has not been guided based on the real-time bandwidth status of cross-data center links.

2. The method according to claim 1, wherein, The first monitoring data includes at least one of the following: system success rate, number of transactions per second, number of inter-service call dependencies, and application interface caller identifier.

3. The method according to claim 1, wherein, The second monitoring data includes at least one of the following: front-end loading time, JavaScript error rate, user session activity, network access error rate, and terminal device type.

4. The method according to claim 1, wherein, The traffic switching decision model is configured to perform the following steps: extract and quantify multi-dimensional features from the first monitoring data and the second monitoring data, and perform weighted fusion calculation on the quantified features to generate a total decision score.

5. The method according to claim 4, wherein, Multi-dimensional feature extraction of the first and second monitoring data includes: Extract a first type of feature from the first monitoring data, the first type of feature including at least one of enterprise customer level, application programming interface call frequency, and business link dependency degree; and A second type of feature is extracted from the second monitoring data. The second type of feature includes at least one of user activity, access depth, access time period, and terminal network environment.

6. The method according to claim 1, wherein, The traffic switching decision model is a weighted scoring card model.

7. The method according to claim 6, wherein, The weighted scoring card model employs a dual-threshold decision mechanism, including: The weighted and fused total decision score is compared with a preset trigger threshold and an early warning threshold, wherein the early warning threshold is lower than the trigger threshold. When the total decision score is higher than the trigger threshold, an instruction is generated to immediately execute the switch. When the total decision score is between the warning threshold and the trigger threshold, a warning message is generated.

8. The method according to claim 1, wherein, The centralized scheduling of the traffic corresponding to the first monitoring data is achieved by the gateway control center issuing scheduling instructions to all registered gateway nodes. The scheduling instructions are used to change the routing target of traffic between services.

9. The method according to claim 8, wherein, The gateway node registers its service identifier and network address with the gateway control center upon startup.

10. The method according to claim 1, wherein, The method further includes: assigning a traffic identifier to the terminal's first user request to identify the target data center; and Traffic-based routing via edge network nodes includes: when the edge network node receives a user request carrying the traffic identifier, it routes the user request to the corresponding target data center based on the traffic identifier.

11. The method according to claim 10, wherein, The edge network node is the edge node of the content delivery network.

12. The method according to claim 1, wherein, The traffic scheduling operation also includes: Monitor the real-time traffic diversion progress of the edge network nodes based on the traffic identifier; Based on the real-time traffic splitting progress and the preset progress completion threshold, and combined with the real-time bandwidth status of the cross-data center link, a dynamic decision is made and a connection migration is triggered through the central network device.

13. The method according to claim 1, wherein, Based on the real-time bandwidth status of cross-data center links, connection migration is performed on traffic that has not yet been redirected, including: Calculate the peak instantaneous bandwidth requirement needed to perform the migration; Determine whether the peak instantaneous bandwidth demand is less than a preset safety ratio of the total bandwidth of the cross-data center link; If the value is less than 1, the connection migration will be performed immediately through the central network device. If it is not less than, wait for a preset time interval and then repeat the above calculation and judgment steps until the condition is met or the preset timeout period is reached.

14. The method according to claim 13, wherein, The peak instantaneous bandwidth requirements for performing the migration include: Based on traffic sampling data within a historical time period, the estimated bandwidth occupied by the residual network connection during migration is determined. The traffic sampling data includes the peak number of requests per second, average page size, and peak traffic concentration of the target data center. The estimated bandwidth is obtained by weighted averaging of the bandwidth values ​​calculated from multiple sampling points within the historical time period.

15. The method according to claim 14, wherein, Sampling points that are closer to the current moment are given higher weights.

16. The method according to any one of claims 12-15, wherein, The central network device is a load balancer.

17. The method according to claim 1, wherein, The method is implemented by an intelligent agent comprising a perception layer, a decision layer, and a service layer, wherein the perception layer is used to acquire the first monitoring data and the second monitoring data, the decision layer is used to run the traffic switching decision model and generate the traffic scheduling instruction, and the service layer is used to respond to the traffic scheduling instruction and coordinate the execution of the traffic scheduling operation.

18. An application traffic scheduling system, characterized in that, include: The data acquisition module is used to acquire the first monitoring data for service calls and the second monitoring data for terminal access. The decision analysis module, connected to the data acquisition module, is used to perform integrated analysis based on the first monitoring data and the second monitoring data through a traffic switching decision model to generate traffic scheduling instructions. A scheduling execution module, connected to the decision analysis module, is used to execute traffic scheduling operations corresponding to the traffic scheduling instructions, wherein the scheduling execution module includes: The first scheduling unit is used to centrally schedule the traffic corresponding to the first monitoring data; as well as The second scheduling unit is used to guide the traffic corresponding to the second monitoring data through edge network nodes based on the traffic identifier, and to perform connection migration for traffic that has not been guided based on the real-time bandwidth status of cross-data center links.

19. The system according to claim 18, wherein, The system is implemented in the form of an intelligent agent, which includes: a perception layer, corresponding to the data acquisition module; a decision layer, corresponding to the decision analysis module; and a service layer, corresponding to the scheduling and execution module.

20. The system according to claim 18, wherein, The first monitoring data acquired by the data acquisition module includes at least one of the following: system success rate, number of transactions per second, number of inter-service call dependencies, and application programming interface caller identifier; and / or The second monitoring data acquired by the data acquisition module includes at least one of the following: front-end loading time, JavaScript error rate, user session activity, network access error rate, and terminal device type.

21. The system according to claim 18, wherein, The traffic switching decision model in the decision analysis module is configured to perform the following steps: extract and quantify multi-dimensional features from the first and second monitoring data, and perform weighted fusion calculation on the quantified features to generate a total decision score.

22. The system according to claim 21, wherein, The multi-dimensional feature extraction performed by the traffic switching decision model includes: Extract a first type of feature from the first monitoring data, the first type of feature including at least one of enterprise customer level, application programming interface call frequency, and business link dependency degree; and A second type of feature is extracted from the second monitoring data. The second type of feature includes at least one of user activity, access depth, access time period, and terminal network environment.

23. The system according to claim 18, wherein, The traffic switching decision model in the decision analysis module is a weighted scorecard model.

24. The system according to claim 23, wherein, The weighted scoring card model employs a dual-threshold decision mechanism, including: The weighted and fused total decision score is compared with a preset trigger threshold and an early warning threshold, wherein the early warning threshold is lower than the trigger threshold. When the total decision score is higher than the trigger threshold, an instruction is generated to immediately execute the switch. When the total decision score is between the warning threshold and the trigger threshold, a warning message is generated.

25. The system according to claim 18, wherein, The first scheduling unit includes a gateway control center, which is used to issue scheduling instructions to all gateway nodes that have registered with it to change the routing target of inter-service traffic.

26. The system according to claim 25, wherein, The gateway node registers its service identifier and network address with the gateway control center upon startup.

27. The system according to claim 18, wherein, The second scheduling unit also includes: The tag management module is used to assign a traffic identifier to the target data center for the terminal's first user request; and The edge scheduling module is used to enable the edge network node to route the user request to the corresponding target data center based on the traffic identifier when it receives a user request carrying the traffic identifier.

28. The system according to claim 27, wherein, The edge network node is the edge node of the content delivery network.

29. The system according to claim 18, wherein, The second scheduling unit also includes: The traffic splitting progress monitoring module is used to monitor the real-time traffic splitting progress of the edge network node based on the traffic identifier; The migration decision module is used to dynamically decide and trigger connection migration through the central network device based on the real-time traffic splitting progress and the preset progress completion threshold, and in combination with the real-time bandwidth status of the cross-data center link.

30. The system according to claim 18, wherein, The second scheduling unit includes: The bandwidth calculation submodule is used to calculate the peak instantaneous bandwidth requirement needed to perform the migration; The condition judgment submodule is used to determine whether the peak instantaneous bandwidth demand is less than a preset safety ratio of the total bandwidth of the cross-data center link; The migration control submodule is used to immediately perform connection migration through the central network device when the judgment result of the condition judgment submodule is less than; when the judgment result is not less than, it waits for a preset time interval and then re-triggers the bandwidth calculation submodule and the condition judgment submodule until the condition is met or the preset timeout period is reached.

31. The system according to claim 30, wherein, The bandwidth calculation submodule calculates the instantaneous bandwidth demand peak, including: Based on traffic sampling data within a historical time period, the estimated bandwidth occupied by the residual network connection during migration is determined. The traffic sampling data includes the peak number of requests per second, average page size, and peak traffic concentration of the target data center. The estimated bandwidth is obtained by weighted averaging of the bandwidth values ​​calculated from multiple sampling points within the historical time period.

32. The system according to claim 31, wherein, In the weighted average, sampling points that are closer to the current time are given higher weights.

33. The system according to any one of claims 29 to 32, wherein, The central network device is a load balancer.

34. A computer device, characterized in that, It comprises: a memory; a processor; and a computer program stored in the memory and executable on the processor, the execution of which causes the method according to any one of claims 1-17 to be performed.

35. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed, perform the method according to any one of claims 1-17.

36. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-17.

Images