Cross-machine room traffic switching method and system based on dynamic rules

Abstract

The application provides a cross-machine room traffic switching method and system based on dynamic rules, comprising the following steps: S1, receiving traffic switching rules containing switching trigger conditions from a rule configuration center; S2, monitoring the performance indicators of target interfaces in real time through a traffic monitoring layer in the micro service of a source machine room; S3, judging whether the performance indicators meet the switching trigger conditions by a rule trigger engine; S4, when the switching trigger conditions are met, generating and publishing instructions for identifying traffic switching; S5, receiving and responding to the instructions by a traffic switching execution layer, intercepting requests accessing the target interfaces, and forwarding the requests to the target machine room. The application realizes low invasion and observability, adopts aspect-oriented programming technology to invade the business code, and is easy to integrate and maintain; through full-link log recording, the application realizes traceability and auditability of the whole process of traffic switching, and is convenient for troubleshooting and system optimization.

Description

Technical Field

[0001] This invention relates to the field of distributed computing technology, specifically to a method and system for cross-data center traffic switching based on dynamic rules, and more specifically to a method and system for cross-data center traffic switching for service disaster recovery. Background Technology

[0002] In modern distributed microservice architectures, ensuring high availability and continuity of services to cope with service failures or sudden traffic surges is a core requirement of system design. Currently, the industry typically employs multi-site active-active or disaster recovery solutions to improve the system's disaster recovery capabilities. For example, a common approach is to deploy multiple redundant systems in data centers in different geographical locations and set up a unified configuration center to manage the address information of each service. When an anomaly is detected in a data center or service, a business switchover process is triggered, redirecting traffic to the normal backup system.

[0003] However, the aforementioned existing technical solutions have the following shortcomings in practical applications: First, they suffer from severe resource redundancy, typically requiring the full deployment of disaster recovery centers in remote locations, leading to high infrastructure costs and very low utilization of backup resources during normal periods. Second, the switching granularity is coarse, mostly relying on DNS-level switching. This approach cannot accurately isolate localized failures of individual microservice interfaces or business modules. Once a switch is triggered, it often transfers all traffic across the entire region, resulting in a massive impact and potentially forcing many normally functioning services to shut down. Third, the level of automation is low and the response speed is slow. Fault detection, decision-making, and switching processes often require manual intervention, with response times typically lasting tens of minutes or even longer, failing to meet the stringent requirements of modern businesses for second- or minute-level rapid recovery. Finally, existing technical solutions lack dynamic, automated triggering mechanisms based on real-time service performance metrics. For example, they cannot make intelligent and rapid decisions and switches based on specific operational conditions such as real-time interface latency and error rates.

[0004] Patent document CN119172266A discloses a method and apparatus for pre-filtering network traffic storage. The method includes: configuring traffic filtering rules; acquiring initial network traffic; filtering the network traffic using the traffic filtering rules to obtain filtered network traffic information; performing application identification filtering on the filtered network traffic information to obtain valid network traffic information; updating the traffic filtering rules using the valid network traffic information; and classifying and storing the valid network traffic information based on the application type information of the valid network traffic information. However, this invention cannot make intelligent and rapid decisions and switches based on the specific operating conditions of the interface, such as real-time latency and error rate. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a method and system for cross-data center traffic switching based on dynamic rules.

[0006] A method for cross-data center traffic switching based on dynamic rules, provided by the present invention, includes: Step S1: Receive the traffic switching rules containing the switching trigger conditions from the rule configuration center; Step S2: Within the microservice in the source data center, monitor the performance metrics of the target interface in real time through the traffic monitoring layer; Step S3: The rule-triggered engine determines whether the performance metric meets the switching trigger condition; Step S4: When the switching triggering condition is met, generate and issue an instruction to identify the traffic switching; Step S5: The traffic switching execution layer receives and responds to the instruction, intercepts the request to access the target interface, and forwards the request to the target data center.

[0007] Preferably, the step of generating and issuing instructions for identifying traffic switching specifically includes: An instruction to identify traffic switching is generated and issued only when the switching trigger condition is met consecutively a preset number of times or continuously for a preset time.

[0008] Preferably, after forwarding the request to the target data center, a degradation step is further included: When the forwarding of the request fails or times out, a preset degradation logic is executed. The degradation logic includes returning the local cached data of the source data center or calling the local degradation service. An additional layer of protection is provided for cross-datacenter calls by integrating a circuit breaker and degradation component. Specifically, in the traffic switching execution layer, the logic point for executing cross-datacenter forwarding is encapsulated and configured. This logic point is the code block that calls the internal gateway to initiate an HTTP request. One or more circuit breaker and degradation rules are configured for this call point. When the circuit breaker is triggered, it will enter the open state. In the next preset time window, all attempts to make cross-datacenter forwarding calls will be immediately rejected. Instead of actually initiating network requests, the preset degradation logic will be executed directly. When an AOP aspect intercepts a new user request and prepares to forward it, the circuit breaker blocks the call. After catching the corresponding exception thrown by the circuit breaker, the AOP aspect will immediately execute the preset degradation logic. After the circuit breaker enters the open state for a preset time, it will automatically switch to the half-open state and allow the request to the target data center. If these requests succeed and return within a preset time, the circuit breaker considers the target data center to have recovered and closes the circuit breaker. If the probe request still fails, the circuit breaker will return to the open state and wait for the next probe cycle.

[0009] Preferably, it further includes: Receive manual commands from the page console; When performing a forwarding operation, the traffic switching execution layer prioritizes responding to the manual command to forcibly trigger or terminate the forwarding of the request, and only responds to the command to perform forwarding when there is no valid manual command. Under the default conditions, operations and maintenance personnel perform manual pre-switch. They log into the console, enter the service name and interface path in the manual switching interface, select the target data center, and click the "Force Forwarding" button. Upon receiving this operation, the backend service in the console generates a manual marker key in the centralized caching system, distinct from the automatically triggered key. This key is given an expiration period or left unused and terminated manually. The AOP aspect logic of the traffic switching execution layer is modified. Upon intercepting a request to access the interface, its judgment logic is adjusted to: first, check if a manual marker key exists; if it exists, immediately execute the traffic forwarding logic, no longer checking the automatically triggered conditions or key; if the manual marker key does not exist, continue executing the original automatic switching judgment logic. After the preset conditions are completed, the operations and maintenance personnel will switch the traffic back to the origin data center. The operations and maintenance personnel will find the corresponding manual switching task on the page console, click the "Force Close Forwarding" or "Terminate Forwarding" button, and the backend service of the console will send a command to the centralized caching system to delete the key. When the AOP aspect of the traffic switching execution layer intercepts the request again, it will stop the forwarding behavior because it finds that neither the manual marking key nor the automatic trigger key exists.

[0010] Preferably, it includes at least one of the following: The switching rules are distributed via the Nacos service; The instructions are transmitted through the Redis system.

[0011] Preferably, it includes at least one of the following: The steps for intercepting requests are implemented using Aspect-Oriented Programming (AOP) technology. The steps for forwarding the request include modifying a preset field in the request header to identify the target data center.

[0012] According to the present invention, a cross-data center traffic switching system based on dynamic rules is provided. The system performs the following operations: Rule Configuration Center: Used to store and distribute traffic switching rules containing switching trigger conditions; Traffic monitoring layer: Configured within a microservice, used to monitor the performance metrics of the target interface in real time; Traffic switching execution layer: used to receive switching instructions, and in response to the switching instructions, intercept requests to access the target interface, and forward the requests to the target data center; Rule triggering engine: used to determine whether the performance metric meets the switching triggering condition, and generate the switching instruction when it is met, and send the switching instruction to the traffic switching execution layer.

[0013] Preferably, the rule triggering engine is further configured as follows: A switching instruction is generated only when the switching trigger condition is met consecutively a preset number of times or continuously for a preset time.

[0014] Preferably, the traffic switching execution layer is further configured to: When the forwarding of the request fails or times out, a preset degradation logic is executed, which includes returning local cached data or calling a local degradation service.

[0015] Preferably, it further includes: The page console is used to receive user input to generate manual instructions and send the manual instructions to the traffic switching execution layer; The traffic switching execution layer is also configured to forcibly trigger or terminate the forwarding of the request based on the manual instruction.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention achieves fine-grained automated switching. By using aspect-oriented programming technology at the interface level for interception and forwarding, the scope of fault impact can be minimized. Combined with real-time monitoring based on sliding windows and composite threshold judgment, automatic fault detection and second-level response are achieved without manual intervention, greatly shortening fault recovery time.

[0017] 2. This invention improves resource utilization. This solution achieves disaster recovery by reusing service instances across data centers, which significantly reduces infrastructure costs compared to the traditional solution of deploying a full disaster recovery center.

[0018] 3. This invention enhances the reliability and flexibility of the system. The solution can integrate an anti-jitter mechanism to avoid frequent switching due to index fluctuations. By setting degradation and circuit breaker mechanisms, it can automatically roll back when cross-data center calls are abnormal, ensuring the basic availability of the system. In addition, it also supports manual intervention, improving the flexibility of the system in different operation and maintenance scenarios.

[0019] 4. This invention achieves low intrusion and observability. It adopts aspect-oriented programming technology, which is non-intrusive to business code and easy to integrate and maintain. Through full-link logging, it achieves traceability and auditability of the entire traffic switching process, which facilitates fault diagnosis and system optimization. Attached Figure Description

[0020] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A schematic diagram of the overall architecture of a cross-data center traffic switching system based on dynamic rules, provided for an embodiment of this application; Figure 2 This is a schematic diagram of the traffic switching data center topology provided in an embodiment of this application; Figure 3 The timing diagram of traffic interaction provided for the embodiments of this application. Detailed Implementation

[0021] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0022] Example 1: This embodiment provides a basic implementation scheme for a cross-data center traffic switching method and system based on dynamic rules, aiming to achieve automated, fine-grained fault transfer of specific microservice interfaces in a distributed system.

[0023] Reference Figure 1 and Figure 2 ,in Figure 1 This is a schematic diagram of the overall system architecture provided in an embodiment of this application. Figure 2This is a schematic diagram of the corresponding data center topology for traffic switching. In one embodiment of this application, the system is deployed in a distributed environment comprising a source data center (e.g., data center A) and a target data center (e.g., data center B). Both the source and target data centers deploy complete microservice application clusters, which may include external gateways, internal gateways, and multiple microservice instances. It is understood that the two data centers are connected via a high-speed dedicated network to ensure low latency and high bandwidth for cross-data center communication.

[0024] The system primarily consists of core functional modules such as a rule configuration center, a traffic monitoring layer, a traffic switching execution layer, and an optional web-based console. Specifically, the rule configuration center can be handled by a configuration service (e.g., implemented using Nacos) to centrally define, store, and dynamically distribute traffic switching rules. A centralized caching system (e.g., implemented using Redis) stores and transmits switching commands, acting as a signaling channel. As core logical components, the traffic monitoring layer and the traffic switching execution layer are embedded or integrated into various microservice instances within the source data center. The web-based console provides operations and maintenance personnel with a visual management interface for easy rule configuration and system status monitoring.

[0025] The following will combine Figure 1 and Figure 3 The complete workflow of this embodiment is illustrated below.

[0026] The process begins with the configuration and distribution of rules (step S101). In a specific application scenario, suppose a financial news platform runs a microservice named "news-service" in the source data center. This service provides a critical real-time news interface with the access path " / api / v3 / news / us-stock-live". Operations personnel can create a traffic switching rule for this interface in the rule configuration center (i.e., the configuration service) through the page console. This rule is defined using a standardized data structure that includes several key fields. For example, a specific rule configuration can be shown as: { "serviceName": "news-service", "interfacePath": " / api / v3 / news / us-stock-live","triggerCondition": { "request_threshold": 100, "slow_ratio": 0.4, "window_ms": 500, "slow_threshold_ms": 5000}, "forward_duration": 180, "targetCluster": "cluster-B"} The rule explicitly defines the target microservice name as "news-service" and the interface path as " / api / v3 / news / us-stock-live". The traffic switching is triggered by a composite condition: within a 500ms time window, if the total number of requests to this interface exceeds 100, and slow requests with a response time exceeding 5000ms account for more than 40% of these, a switchover is triggered. Once triggered, traffic will be forwarded to the target data center identified by "targetCluster: cluster-B", and this forwarding will continue for 180 seconds. After configuration, the rule configuration center utilizes its dynamic push capabilities (such as Nacos' configuration subscription and push mechanism) to distribute this rule in real time to all running "news-service" microservice instances in the source data center. Each instance pulls and caches this type of rule from the configuration center upon startup or runtime.

[0027] Subsequently, the system performs real-time traffic monitoring (step S102). When the microservice instance of "news-service" receives a user request, its internally integrated traffic monitoring layer begins operation. The traffic monitoring layer incorporates a high-performance sliding window statistician as its core component. This statistician maintains a data structure (such as a circular queue) in memory to store a series of time buckets. In this embodiment, the span of each time bucket can be set to 100 milliseconds. The statistician operates on a 100-millisecond cycle, processing all requests within the current time window (defined by window_ms: 500 in the rule, i.e., the most recent 5 time buckets) within each cycle. For each request entering this interface, the monitoring layer records its processing time. After the request is processed, the processing time is compared with the slow request threshold (slow_threshold_ms: 5000) defined in the rule to determine whether it is a slow request. Simultaneously, the statistician accumulates the total number of requests and the number of slow requests within the current time bucket in real time. By scanning all time buckets covered by the current sliding window, the total number of requests and the proportion of slow requests within the window can be quickly calculated.

[0028] Based on this, the system performs trigger condition judgment (step S103). The traffic monitoring layer also includes a rule triggering engine, which works closely with the sliding window statistician to obtain the latest statistical data at the end of each statistical period (e.g., 100 milliseconds). The engine iterates through all loaded switching rules and judges them one by one. Taking the aforementioned financial news interface as an example, suppose a sudden major news event causes a surge in traffic, excessive database pressure, and slow response. Within a 500-millisecond statistical window, the sliding window statistician calculates a total of 120 requests, of which 50 requests have a response time exceeding 5000 milliseconds. At this point, the rule triggering engine judges: the total number of requests (120) is greater than the preset request threshold of 100, so the condition is met; the slow request ratio (50 / 120 ≈ 41.7%) is greater than the preset slow request ratio threshold of 40%, so the condition is also met. Since both conditions are met simultaneously, the rule triggering engine determines that the switching condition has been met. If either condition is not met, the engine does not perform any operation, and the process returns to step S102 to continue the next round of monitoring and statistics.

[0029] Next, the system generates and writes a switching instruction (step S104). Once the triggering condition is met, the rule triggering engine immediately generates a switching instruction to indicate that the traffic of that interface needs to be forwarded. This instruction is a key with a specific format; for example, a unique key can be generated based on the service name and interface path, such as `forward:news-service: / api / v3 / news / us-stock-live`. Subsequently, the engine writes this key to the centralized caching system and sets its value to either `true` or the target data center identifier `cluster-B`. It should be noted that a time-to-live (TTL) is set for this key at the same time it is written. The TTL value is equal to the forwarding period configured in the rule, `forward_duration`, which is 180 seconds. This key with a TTL constitutes the core switching signaling of the entire system.

[0030] Finally, the system intercepts and forwards traffic (steps S105 and S106). In microservice instances, the traffic switching execution layer and the traffic monitoring layer coexist. This execution layer monitors the centralized caching system in real time in an efficient manner. As a preferred implementation, Redis's keyspace notification mechanism can be used to monitor the creation events of keys with specific prefixes (such as forward:) in real time through a subscription model. Once the creation of the aforementioned forward:news-service: / api / v3 / news / us-stock-live key is detected, the traffic switching execution layer is immediately activated.

[0031] The execution layer can leverage aspect-oriented programming (AOP) techniques, such as the Spring AOP framework in the Java ecosystem, to achieve non-intrusive interception of target interfaces. It defines an aspect whose pointcut expression precisely matches the method in the "news-service" microservice that handles requests to the " / api / v3 / news / us-stock-live" interface. When a new user request accesses this interface, the aspect intercepts it before the target method executes. In the interception logic, the execution layer first re-verifies the existence of the corresponding forwarding key in the cache to prevent key expiration between key detection and actual interception. After confirming the key's existence, the execution layer modifies the intercepted HTTP request object; specifically, it adds or modifies a custom field in its request header, for example, adding a header named X-Forward-Target and setting its value to the target data center identifier cluster-B defined in the rule.

[0032] After the request headers are modified, the execution layer no longer allows the request to be executed locally in the origin data center, but instead forwards the modified request out through the internal gateway. For example... Figure 2 As shown, the request is routed from the source data center's internal gateway to the target data center's internal gateway via a dedicated network. Upon receiving the request, the target data center's gateway parses its path and header information and distributes it to a healthy "news-service" instance within the target data center for processing. After processing the request, the target data center's service instance generates response data. This response returns along the original forwarding path: from the target data center's service instance to its internal gateway, then back to the source data center's internal gateway via the dedicated network, and finally, the source data center's traffic switching execution layer returns the response to the original caller, completing the entire loop. For the original caller, the entire cross-data center forwarding process is transparent.

[0033] When the 180-second forwarding cycle ends, the corresponding forwarding key in the centralized caching system is automatically deleted due to its expiration time. The traffic switching execution layer detects the disappearance of the key through its listening mechanism (polling or subscribing) and thus stops intercepting the interface. All subsequent requests to this interface will resume processing locally in the origin data center.

[0034] In summary, this embodiment provides a mechanism that automatically and quickly and seamlessly switches traffic from a faulty interface to a target data center when the performance of the source data center interface degrades. This mechanism ensures service continuity and user experience, and automatically recovers after the fault or traffic surge subsides. The entire process requires no manual intervention, and the response time is in the second range.

[0035] Example 2: Example 2 is a preferred example of Example 1, and is used to illustrate the present invention in more detail.

[0036] As an optional implementation, this embodiment introduces an enhanced trigger stability mechanism based on embodiment 1, which aims to prevent unnecessary and excessively frequent traffic switching caused by instantaneous network jitter or brief traffic spikes, thereby improving the stability and accuracy of switching decisions.

[0037] The system architecture and basic process remain consistent with Implementation Example 1. The main improvements are reflected in the rule definition in the rule configuration center and the internal logic of the rule triggering engine.

[0038] First, in the rule configuration phase (corresponding to step S101), the data structure of the switching rule is expanded to add a configuration item for debouncing processing. For example, a debounce field is added to the rule in Example 1: The `debounce` object contains two parameters: `count` indicates how many consecutive times the metric must be detected exceeding the limit before a switchover is actually triggered; `interval_sec` defines a cooldown time, which is a specified number of seconds after a successful switchover trigger, during which the switchover will not be triggered again even if the condition is met again, in order to prevent system "jitter".

[0039] Accordingly, the judgment logic of the rule triggering engine (corresponding to step S103) is modified. When the sliding window statistician of the traffic monitoring layer reports that the performance indicators (such as the total number of requests and the proportion of slow requests) of a certain interface reach the threshold for the first time, the rule triggering engine no longer generates a switching instruction immediately as in Example 1, but maintains a counter and timestamp associated with each interface in the memory of the microservice instance.

[0040] The specific working process is as follows: When the metric of the " / api / v3 / news / us-stock-live" interface is detected as exceeding the limit in the first statistical period, the rule triggering engine searches for the corresponding "continuous compliance counter" in memory. If the counter does not exist or is 0, its value is set to 1 and the current timestamp is recorded. At this time, no subsequent operations are performed. In the following statistical periods, if the metric of the interface still exceeds the limit, the engine increments the counter by 1. This process continues until the value of the counter reaches the value set by debounce.count in the rule (3 in this example). At this time, the engine will execute the step of generating and writing the switching instruction (step S104), that is, creating the forward:news-service: / api / v3 / news / us-stock-live key in the centralized cache system, thereby triggering the subsequent traffic switching process. If, during the counting accumulation process, the metric detected in any statistical period does not exceed the limit, the rule triggering engine will immediately clear the "continuous compliance counter" of the interface to zero, and the counting will start again from 1 when the limit is detected next time.

[0041] Furthermore, the `interval_sec: 5` parameter ensures that once the above consecutive criteria are met and a switchover is successfully triggered, the rule-triggered engine records the timestamp of this trigger. For the next 5 seconds, even if the interface's metrics continue to exceed the limits, the engine will ignore these trigger signals and will not generate new switchover instructions. This effectively prevents the system from rapidly oscillating between "switchover" and "no-switchover" states under boundary conditions.

[0042] By introducing this anti-jitter mechanism that includes continuous count judgment and cooldown time, this embodiment can effectively filter out false alarms caused by short-term and occasional performance fluctuations, ensuring that the relatively costly cross-data center traffic switching is only performed when service performance continues to deteriorate. This enhances the stability and decision-making accuracy of the entire disaster recovery system, and reduces unnecessary system overhead and potential interference with normal services.

[0043] Example 3: Example 3 is a preferred example of Example 1, and is used to illustrate the present invention in more detail.

[0044] To further enhance the reliability of the system, this embodiment introduces a degradation and circuit breaker mechanism based on embodiment 1 to deal with abnormal situations that may occur during cross-data center traffic forwarding, such as a failure of the target data center itself, or an interruption or severe congestion of the dedicated network between the source data center and the target data center.

[0045] The overall system architecture and basic switching process are the same as in Implementation Example 1. The core improvement of this implementation example lies in the traffic switching execution layer, which integrates a mature circuit breaker and degradation component (such as the widely used Sentinel library) to provide an additional protection layer for cross-data center calls.

[0046] Specifically, in the traffic switching execution layer, the logic point for executing cross-datacenter forwarding is encapsulated and configured. This logic point is typically the code block that calls the internal gateway to initiate an HTTP request. One or more circuit breaker and degradation rules can be configured for this call point, such as: 1. Degradation rule based on average response time: If the average response time of cross-datacenter calls exceeds a threshold (e.g., 2 seconds) within a set statistical period (e.g., 1 minute), a circuit breaker is triggered. 2. Degradation rule based on the proportion of exceptions in cross-datacenter calls (e.g., connection timeout, read timeout, target datacenter returning 5xx error codes, etc.) exceeds a threshold (e.g., 30%) within a set statistical period, a circuit breaker is triggered.

[0047] When the circuit breaker is triggered, it will enter the "open" state. Within the next preset time window (e.g., 60 seconds), all attempts to make cross-datacenter forwarding calls will be immediately rejected, and no network requests will actually be initiated. Instead, the preset degradation logic will be executed directly.

[0048] Imagine the following workflow: Assume the system follows the process in Example 1, and a traffic switch is successfully triggered due to a performance degradation of the "news-service" interface in the source data center. The traffic switch execution layer is forwarding requests to the target data center. During the switchover process, if, due to unknown reasons (such as a surge in load in the target data center or network line jitter), multiple requests forwarded to the target data center respond slowly, with an average response time exceeding 2 seconds, the circuit breaker and degradation component integrated in the traffic switch execution layer will detect this metric exceeding the limit and trigger the circuit breaker rule, changing the circuit breaker state from "closed" to "open".

[0049] At this point, when the AOP aspect intercepts a new user request and prepares to forward it, the circuit breaker will block the call. After catching the corresponding exception thrown by the circuit breaker, the AOP aspect will immediately execute the pre-defined fallback logic, rather than letting the request fail or wait for a long time. Understandably, the fallback logic can be flexibly customized according to business needs, including but not limited to: a. attempting to call another lightweight backup service on the origin data center, which may provide a simplified but usable response; b. directly reading slightly older data from the local cache (such as another cache instance in the origin data center or a memory cache) and returning it to the user, for example, returning historical news from 30 seconds ago, which is generally acceptable for news applications; c. returning a standard, user-friendly message informing the user that the service is temporarily busy and to try again later.

[0050] Meanwhile, for system observability, each degradation event is logged in detail. For example, a tag key (e.g., degrade:news-service: / api / v3 / news / us-stock-live) can be written to a centralized caching system to record the number of degradations. At the same time, structured logs containing request details, degradation reasons, timestamps, and other information are pushed to a centralized log analysis system (e.g., Elasticsearch) so that operations personnel can view alerts and perform subsequent troubleshooting through the web console.

[0051] After the fuse has been in the "open" state for a period of time (e.g., 60 seconds), it will automatically switch to the "half-open" state and tentatively allow a small number of requests to the target data center. If these requests succeed and return within a normal time, the fuse will assume that the target data center has recovered, thus closing the fuse and resuming normal cross-data center forwarding. If these probe requests still fail, the fuse will return to the "open" state and wait for the next probe cycle.

[0052] By introducing this degradation and circuit breaker mechanism, this embodiment constructs a multi-layered fault-tolerant protection system. Even if an unexpected event occurs during the execution of the high-availability measure of disaster recovery switching, the system can still provide impaired but usable services, avoiding direct exposure of faults to end users, thereby improving the overall robustness of the system and the user experience.

[0053] Example 4: Example 4 is a preferred example of Example 1, which is used to illustrate the present invention in more detail.

[0054] This embodiment provides an implementation method that supports manual intervention. It adds manual control functionality to automated switching to meet operational scenarios requiring proactive traffic control, such as planned maintenance, canary releases, version verification, and stress testing. This function grants operations personnel the highest level of control over traffic, with a priority higher than automatically triggered rules based on performance metrics.

[0055] The system architecture is basically the same as that of Example 1, with the main extensions being the functionality of the page console and the judgment logic of the traffic switching execution layer.

[0056] The functionality of the page console has been enhanced. In addition to rule configuration, it now provides a "manual traffic switching" interface. On this interface, operations and maintenance personnel can select the microservices and interfaces to be operated, specify the target data center, and choose "force enable forwarding" or "force disable forwarding".

[0057] Its workflow can be divided into the following two scenarios: Scenario 1: Manually Triggered Switchover. Suppose that before the release of important financial data, operations personnel anticipate a sudden and significant surge in traffic to the microservice providing the "economic data interpretation" interface (e.g., data-service: / api / v1 / econ-data). To distribute the pressure to a more resource-rich target data center in advance, the operations personnel decide to perform a manual pre-switch. In this case, the operations personnel log into the console, enter the service name `data-service` and the interface path ` / api / v1 / econ-data` in the manual switchover interface, select `cluster-B` as the target data center, and then click the "Force Forwarding" button. Upon receiving this operation, the backend service in the console will generate a specially formatted manual marker key in the centralized caching system, such as `manual_forward:data-service: / api / v1 / econ-data`, to distinguish it from the automatically triggered key. Simultaneously, a relatively long validity period (e.g., 2 hours) will be set for this key, specified by the operations personnel, or it may be left unset and terminated manually. Accordingly, the AOP aspect logic of the traffic switching execution layer has been modified. After intercepting a request to access the interface, its judgment logic has been adjusted to: first, check if a manually marked key exists; if it exists, immediately execute the traffic forwarding logic, and no longer check the automatically triggered conditions or keys; if the manually marked key does not exist, continue to execute the original automatic switching judgment logic. Therefore, because the operations and maintenance personnel have created a manually marked key, even if the current interface's performance indicators are completely normal, all traffic accessing this interface will be forcibly forwarded to the target data center.

[0058] Scenario 2: Manually Terminating the Switchover. After the financial data release conference ends and the traffic peak subsides, operations personnel need to switch traffic back to the origin data center. In this case, operations personnel can find the corresponding manual switchover task on the console and click the "Force Close Forwarding" or "Terminate Forwarding" button. The console backend service will send a delete key command to the centralized caching system, deleting the key `manual_forward:data-service: / api / v1 / econ-data`. When the AOP aspect of the traffic switchover execution layer intercepts a request again, it will stop forwarding because it finds that neither the manual mark key nor the automatic trigger key exists, allowing the request to resume local processing in the origin data center.

[0059] Understandably, this manual intervention mechanism also applies to scenarios where switching is forcibly prohibited. For example, when conducting a critical test, if no automatic switching behavior is desired to interfere with the test process, operations personnel can set a "disable switching" flag. When the AOP aspect detects this flag, it will ignore all automatically triggered signals, ensuring that traffic is always processed locally.

[0060] By providing manual and automatic dual-mode switching capabilities, this embodiment significantly improves the system's flexibility and maintainability. It can not only cope with sudden, unpredictable failures but also support planned, proactive traffic scheduling needs, enabling the technical solution to better adapt to complex and ever-changing production environments and meet diverse operational goals such as canary releases, capacity verification, and emergency drills.

[0061] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0062] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A dynamic rule-based cross-machine room traffic switching method, characterized in that, include: Step S1: Receive the traffic switching rules containing the switching trigger conditions from the rule configuration center; Step S2: Within the microservice in the source data center, monitor the performance metrics of the target interface in real time through the traffic monitoring layer; Step S3: The rule-triggered engine determines whether the performance metric meets the switching trigger condition; Step S4: When the switching triggering condition is met, generate and issue an instruction to identify the traffic switching; Step S5: The traffic switching execution layer receives and responds to the instruction, intercepts the request to access the target interface, and forwards the request to the target data center.

2. The method of claim 1, wherein, The specific steps for generating and issuing instructions to identify traffic switching are as follows: An instruction to identify traffic switching is generated and issued only when the switching trigger condition is met consecutively a preset number of times or continuously for a preset time. 3.The dynamic rule based cross-machine room traffic switching method of claim 1, wherein, Following the step of forwarding the request to the target data center, a degradation step is also included: When the forwarding of the request fails or times out, a preset degradation logic is executed. The degradation logic includes returning the local cached data of the source data center or calling the local degradation service. An additional layer of protection is provided for cross-datacenter calls by integrating a circuit breaker and degradation component. Specifically, in the traffic switching execution layer, the logic point for executing cross-datacenter forwarding is encapsulated and configured. This logic point is the code block that calls the internal gateway to initiate an HTTP request. One or more circuit breaker and degradation rules are configured for this call point. When the circuit breaker is triggered, it will enter the open state. In the next preset time window, all attempts to make cross-datacenter forwarding calls will be immediately rejected. Instead of actually initiating network requests, the preset degradation logic will be executed directly. When an AOP aspect intercepts a new user request and prepares to forward it, the circuit breaker blocks the call. After the AOP aspect catches the corresponding exception thrown by the circuit breaker, it will immediately execute the preset degradation logic. After the circuit breaker enters the open state for a preset time, it will automatically switch to the half-open state and allow the request to reach the target data center. If these requests succeed and return within a preset time, the circuit breaker assumes the target data center has recovered and closes the circuit breaker; if the probe requests still fail, the circuit breaker will return to the open state and wait for the next probe cycle.

4. The method of claim 1 or 2, wherein, Also includes: Receive manual commands from the page console; When performing a forwarding operation, the traffic switching execution layer prioritizes responding to the manual command to forcibly trigger or terminate the forwarding of the request, and only responds to the command to perform forwarding when there is no valid manual command. Under the default conditions, operations and maintenance personnel perform manual pre-switch. They log into the console, enter the service name and interface path in the manual switching interface, select the target data center, and click the "Force Forwarding" button. Upon receiving this operation, the backend service in the console generates a manual marker key in the centralized caching system, distinct from the automatically triggered key. This key is given an expiration period or left unused and terminated manually. The AOP aspect logic of the traffic switching execution layer is modified. Upon intercepting a request to access the interface, its judgment logic is adjusted to: first, check if a manual marker key exists; if it exists, immediately execute the traffic forwarding logic, no longer checking the automatically triggered conditions or key; if the manual marker key does not exist, continue executing the original automatic switching judgment logic. After the preset conditions are completed, the operations and maintenance personnel will switch the traffic back to the origin data center. The operations and maintenance personnel will find the corresponding manual switching task on the page console, click the "Force Close Forwarding" or "Terminate Forwarding" button, and the backend service of the console will send a command to the centralized caching system to delete the key. When the AOP aspect of the traffic switching execution layer intercepts the request again, it will stop the forwarding behavior because it finds that neither the manual marking key nor the automatic trigger key exists.

5. The dynamic rule-based cross-machine room traffic switching method according to any one of claims 1 to 4, characterized in that, Includes at least one of the following: The switching rules are distributed via the Nacos service; The instructions are transmitted through the Redis system. 6.The dynamic rule based cross-machine room traffic switching method according to any one of claims 1 to 5, wherein, Includes at least one of the following: The steps for intercepting requests are implemented using Aspect-Oriented Programming (AOP) technology. The steps for forwarding the request include modifying a preset field in the request header to identify the target data center.

7. A cross-data center traffic switching system based on dynamic rules, comprising the cross-data center traffic switching system based on dynamic rules as described in any one of claims 1-5, and performing the following: Rule Configuration Center: Used to store and distribute traffic switching rules containing switching trigger conditions; Traffic monitoring layer: Configured within a microservice, used to monitor the performance metrics of the target interface in real time; Traffic switching execution layer: used to receive switching instructions, and in response to the switching instructions, intercept requests to access the target interface, and forward the requests to the target data center; Rule triggering engine: used to determine whether the performance metric meets the switching triggering condition, and generate the switching instruction when it is met, and send the switching instruction to the traffic switching execution layer.

8. The dynamic rule-based cross-machine room traffic switching system of claim 7, wherein, The rule triggering engine is also configured as follows: A switching instruction is generated only when the switching trigger condition is met consecutively a preset number of times or continuously for a preset time.

9. The dynamic rule based cross room traffic switching system of claim 7, wherein, The traffic switching execution layer is also configured to: When the forwarding of the request fails or times out, a preset degradation logic is executed, which includes returning local cached data or calling a local degradation service.

10. The cross-data center traffic switching system based on dynamic rules according to claim 7 or 8, characterized in that, Also includes: The page console is used to receive user input to generate manual instructions and send the manual instructions to the traffic switching execution layer; The traffic switching execution layer is also configured to forcibly trigger or terminate the forwarding of the request based on the manual instruction.

Images