Automatic switching method and device for gateway application, equipment and medium

Abstract

The invention relates to the technical field of artificial intelligence, can be applied to business scenes such as financial science and technology, medical health and the like, and discloses an automatic switching method, device, equipment and medium for gateway application. A health detection module detects health state data generated by a main gateway and a standby gateway, the health state data is processed by an anomaly detection and collection sub-module, a switching decision sub-module generates a switching instruction, a routing request sub-module updates a routing relation and determines a target gateway, a request entry address forwards a service request to the target gateway, and the target gateway sends the service request. And the log and alarm module records switching and abnormity and issues an alarm, and the health detection module generates a back-switching instruction and updates the routing relationship to complete back-switching when detecting that the main gateway is recovered. According to the invention, through cooperation of the health detection module, the switching decision module and the request routing module, automatic switching when the main gateway is abnormal and automatic back-switching after recovery are realized, service interruption is avoided, and stable operation of high-real-time service is ensured.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an automatic switching method, apparatus, device, and storage medium for gateway applications. Background Technology

[0002] In the fintech sector, bank OTP (One-Time Password) SMS systems are widely used in highly sensitive business scenarios such as transaction verification and account security confirmation. These systems have extremely high requirements for real-time performance and stability; any delay or interruption can directly impact transaction security and customer experience. However, while some existing financial institutions' SMS gateway architectures support multi-channel switching to handle communication link anomalies, manual intervention is still required to switch to a backup machine when the host machine hosting the bank's OTP gateway application interface experiences hardware failure or system crash. This manual switching mode inevitably introduces time delays during operation and response, leading to OTP SMS sending failures during the delay period, resulting in transaction interruptions, incomplete customer verification, and potential financial risks.

[0003] In the healthcare sector, many critical real-time notification services (such as surgical progress reminders, critical value alerts, and remote diagnostic verification code distribution) also rely on highly available messaging systems. These systems need to interact with healthcare institution information systems or medical device gateway interfaces. When a host or service node fails, the lack of an automated failover mechanism necessitates manual intervention to modify system configurations. This not only prolongs system recovery time but may also lead to missed opportunities for timely notifications during critical medical decision-making windows, impacting patient safety and the quality of care.

[0004] In existing general gateway application architectures, a common problem is the lack of rapid and automated routing switching capabilities when faced with host-level failures or unavailability. While some systems can switch to backup channels to obtain data when a link fails, they cannot automatically switch back or switch when the node hosting the gateway application interface becomes unavailable. Connection restoration can only be achieved through manual modification of configuration files and restarting the routing service. This approach relies heavily on the response speed and accuracy of operations personnel, and the time consumed during the switching process can directly cause message transmission interruptions and business unavailability. This risk is particularly pronounced for financial and healthcare systems with extremely high availability and low latency requirements. Summary of the Invention

[0005] The main objective of this invention is to provide an automatic switching method, apparatus, device, and storage medium for gateway applications, aiming to solve the technical problem that existing technologies lack an automated routing switching mechanism when host or gateway application interfaces fail, relying on manual configuration modifications to complete the switching, which leads to delays in fault recovery and risks of service interruption.

[0006] To achieve the above objectives, the present invention provides an automatic switching method for gateway applications, comprising:

[0007] Configure the routing control component to associate with the primary gateway and the backup gateway, and set the request entry address;

[0008] The health detection module performs health checks on the main gateway and the backup gateway to generate health status data.

[0009] The health status data is received by the anomaly detection and collection submodule of the routing switching module, health status information is generated, and a switching instruction is generated by the switching decision submodule of the routing switching module based on the health status information.

[0010] The request routing submodule of the routing switching module updates the routing relationships in the routing control component and determines the target gateway according to the switching instruction;

[0011] The service request is forwarded to the target gateway through the request entry address;

[0012] The system records routing switching information and abnormal information and sends alarm notifications through the log and alarm module.

[0013] When the health detection module detects that the main gateway has recovered, it generates a switchback instruction through the switchover decision submodule and updates the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

[0014] Furthermore, to achieve the above objectives, the present invention provides an automatic switching device for gateway applications, comprising:

[0015] The routing control component module is used to configure the routing control component to associate with the primary gateway and the backup gateway, and to set the request entry address;

[0016] The health detection module is used to perform health detection on the main gateway and the backup gateway and generate health status data.

[0017] The anomaly detection and collection module is used to receive the health status data through the anomaly detection and collection submodule of the routing switching module, generate health status information, and generate a switching instruction based on the health status information through the switching decision submodule of the routing switching module.

[0018] The request routing module is used to update the routing relationships in the routing control component and determine the target gateway according to the switching instruction through the request routing submodule of the routing switching module;

[0019] The business request processing module is used to forward business requests to the target gateway through the request entry address;

[0020] The logging and alarm module is used to record routing switching information and abnormal information and send alarm notifications.

[0021] The switching decision module is used to generate a switchback instruction through the switching decision submodule when the health detection module detects that the main gateway has recovered, and to update the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

[0022] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and an automatic switching program for gateway applications stored in the memory and executable on the processor, wherein the automatic switching program for gateway applications, when executed by the processor, implements the steps of the automatic switching method for gateway applications as described above.

[0023] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing an automatic switching program for a gateway application, wherein the automatic switching program for a gateway application, when executed by a processor, implements the steps of the automatic switching method for a gateway application as described above.

[0024] Beneficial Effects: This invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as fintech and healthcare. It discloses an automatic switching method, apparatus, device, and medium for gateway applications, comprising: configuring a routing control component to associate a primary gateway and a backup gateway and setting a request entry address; performing health checks on the primary and backup gateways and generating health status data through a health detection module; receiving the health status data and generating health status information through an anomaly detection collection submodule of the routing switching module; generating a switching instruction based on the health status information through a switching decision submodule; updating the routing relationships in the routing control component and determining the target gateway through a request routing submodule based on the switching instruction; forwarding the business request to the target gateway through the request entry address; recording routing switching information and anomaly information and sending alarm notifications through a log and alarm module; and when the health detection module detects that the primary gateway has recovered, generating a rollback instruction through the switching decision submodule and updating the routing relationships in the routing control component through the request routing submodule to complete the rollback. This invention introduces modules such as health detection, switching decision, and request routing into gateway applications, enabling automated switching when the main gateway or channel malfunctions and automatic reverting during recovery. This eliminates the delay caused by manual configuration modifications, effectively reduces the risk of service interruption during faults, and ensures the continuity and stability of high real-time services. Attached Figure Description

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings:

[0026] Figure 1 This is a schematic diagram of an application environment for an automatic switching method for gateway applications according to an embodiment of the present invention;

[0027] Figure 2 This is a flowchart illustrating an embodiment of the automatic switching method for gateway applications according to the present invention.

[0028] Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the automatic switching device for gateway applications of the present invention.

[0029] Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0030] Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0031] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0032] The automatic switching method for gateway applications provided in this invention can be applied to applications such as... Figure 1In this application environment, the user terminal communicates with the server via a network. The server can configure the routing control component through the user terminal to associate the primary and backup gateways and set the request entry address. The health detection module performs health checks on the primary and backup gateways and generates health status data. The anomaly detection and collection submodule of the routing switching module receives the health status data and generates health status information. The switching decision submodule generates a switching command based on the health status information. The request routing submodule updates the routing relationships in the routing control component based on the switching command and determines the target gateway. The service request is forwarded to the target gateway through the request entry address. The log and alarm module records routing switching information and anomaly information and sends alarm notifications. When the health detection module detects that the primary gateway has recovered, the switching decision submodule generates a rollback command and updates the routing relationships in the routing control component through the request routing submodule to complete the rollback. This invention, by introducing modules such as health detection, switching decision, and request routing into the gateway application, achieves automated switching when the primary gateway or channel malfunctions and automatic rollback upon recovery. This eliminates the delay caused by manual configuration modifications, effectively reduces the risk of service interruption during failures, and ensures the continuity and stability of high real-time services. The user terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0033] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the automatic switching method for gateway applications provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0034] like Figure 2 As shown, the automatic switching method for gateway applications proposed in this invention includes the following steps:

[0035] S10, Configure the routing control component to associate with the primary gateway and the backup gateway, and set the request entry address;

[0036] In this embodiment, the goal is to provide a single entry point for business calls and manage both the primary and backup gateways simultaneously in the backend, thereby eliminating the latency and risks associated with manual failover. The configuration phase revolves around several key terms. Configuration refers to the entire process of setting parameters, binding resources, writing rules, and making them effective for executable entities. This includes both static items such as addresses, ports, certificates, and routing rules, and dynamic items such as upstream node registration and start / stop flags. The routing control component originates from the concept of a traffic hub at layers four to seven. It can be a reverse proxy, application gateway, layer four forwarding device, or cloud load balancer instance, and its form is not limited to software or hardware. Implementation focuses on listening, forwarding, rule matching, and session maintenance capabilities. Association refers to establishing a one-to-one or one-to-many mapping between backend targets and forwarding rules within the routing control component. Common endpoints include upstream pool registration, service discovery registration, or static backend table updates, along with role fields identifying the host and backup host. These role fields are used for subsequent automatic failover and are not used for judgment in this phase. The primary gateway is the preferred gateway node for business operations, handling request processing under normal circumstances. The backup gateway is an equivalent replacement node, taking over traffic when the primary gateway is unavailable. Both maintain consistency in functional interfaces, authentication methods, and network reachability, differing only in role and initial weight. The configuration specifies the entry points and rules required for listening and forwarding, including listening protocols, ports, certificates, hostnames, and path mappings, written to the routing control component. The request entry address originates from the unified access design and can be represented as a virtual IP, anycast address, or domain alias, residing at either Layer 4 or Layer 7. When using domain names, authoritative resolution and certificate management are combined; when using addresses, drifting or advertising strategies are used. To ensure logical consistency between the entry point and the backend, hostname matching, path matching, or header matching are established between the entry point and routing rules. To adapt to multi-tenant scenarios, namespaces or service prefixes are introduced to isolate different services. The actual implementation proceeds in the following order, avoiding the use of "steps" and instead employing a series of stages: Initialize the routing control component and load the minimum operating configuration; request or assign the request entry address and bind it to a listener; register the access endpoints of the primary and backup gateways to the upstream pool and write role identifiers and initial weights as primary bias; establish matching rules from the entry point to the upstream pool, with rules covering protocol, hostname, and path; load the transmission security policy, allowing the entry point to terminate encryption or pass through and indicate the target based on the service name; perform connectivity and syntax checks, verifying only the reachability from the entry point to the two gateways and the rule syntax, without triggering health checks; trigger smooth reload to allow the new rules to take over new connections, while existing connections continue. The implementation meaning of each term in this stage is as follows: The routing control component undertakes listening, matching, forwarding, and reload; the primary and backup gateways are registered in the form of address-port pairs; association is implemented through the upstream pool member table; the request entry address is publicly exposed through listener blocks and certificate binding; the final effect of the configuration is achieved through continuous reload.To adapt to multiple data centers or availability zones, the entry point can be set as a VIP within the region and line policies can be implemented at the global resolution layer; to adapt to multiple protocols, the listener can enable HTTP and HTTPS or TCP proxies in parallel and perform traffic splitting at the matching layer; to adapt to two-way authentication, the entry point can load a two-way certificate chain and pass the client's identity to the backend; to adapt to canary deployments or rollbacks, the rules reserve traffic splitting anchors marked by headers, paths, or sources, which can also split traffic by source for verification when the primary and backup roles remain unchanged.

[0037] The implementation can choose a Layer 7 reverse proxy model. The entry point uses a domain name mapped to a virtual address, listens with HTTP and encrypted HTTP enabled, imports server certificate chains and enables service name indication, and uses hostname rules to map specific host headers and paths from the request entry address to a backend set called "Gateway Upstream." The access endpoints of the primary and backup gateways are registered in this set, role identifiers are recorded as primary and backup, initial weight configuration is primary biased, persistent sessions are based on source address or token concatenation, connectivity verification is completed through handshake probes to the two backends and routing rule syntax checks, and then a non-disruptive reload is triggered to make the listening and mapping rules effective. Alternatively, a Layer 4 forwarding model can be chosen. The entry point exposes the transport layer address and port, enables pass-through encryption and relies on service name indication to complete certificate verification on the backend, primary and backup endpoints are registered as transport layer targets, the forwarding table maintains session consistency based on the session 5-tuple, and a non-disruptive reload takes over new sessions in kernel mode. A service discovery-driven model can also be chosen. The routing control component subscribes to the primary and backup endpoint list from the registry or configuration repository at startup, and the association process is transformed into writing primary and backup roles to the registration entries and referencing the logical service name in the rules, while the entry point remains unchanged. Adaptation methods for different production environments include single-availability-zone and multi-availability-zone scenarios. In single-zone scenarios, the entry point is bound to a single virtual address. In multi-zone scenarios, the entry point uses global resolution to distribute across regions and deploy regional entry points within each region. The key system can choose to terminate at the entry point or at the backend. Termination at the entry point facilitates unified certificate management, while termination at the backend ensures end-to-end encryption consistency. The resolution system can use short buffer times for faster convergence during entry point switching, or it can use resolution weights to support canary traffic verification. Regarding parameter optimization, listening concurrency, connection pool capacity, and retry behavior need to match the backend's carrying capacity. The entry queue length and timeout need to match the upstream processing latency budget. The overload strategy selects smooth takeover to avoid connection interruptions, and the rule matching order is from specific to general to reduce matching overhead. If the upstream is a multi-interface device, multiple access endpoints are registered and distinguished by target topology labels at the mapping layer, combined with the source address or availability zone label to complete the nearest forwarding. If the business requires dual-active cities, the entry point adopts a global resolution route strategy, guiding calls from different regions to the nearest entry point. The primary and backup are registered in the upstream pool of their respective regions. The entry point and rules maintain a consistent structure for easy unified maintenance.

[0038] Example Description: In the fintech business, a routing control component is configured for the bank's one-time password SMS service. The entry point uses a trusted domain name and is bound to an encrypted certificate. The primary gateway and backup gateway are registered in a set called OTP Upstream. The entry rules map requests from a unified domain name and a specific path to this set. Role identifiers distinguish between the primary and backup gateways. The initial weight is set to primary bias. After smooth reload, the unified entry point connects to the group's SMS platform. The calling end does not need to care about changes in the backend host location. Subsequently, when health detection and decision-making processes intervene, the switching can be completed directly based on the role identifier.

[0039] In the healthcare business, a routing control component is configured for medical institutions' verification SMS and appointment reminders. The entry point adopts a domain name plus region-based resolution scheme. The in-hospital main gateway and the off-hospital disaster recovery gateway are registered as primary and backup in the upstream set. The entry rules distribute verification SMS and reminder notifications to the same set based on the hostname and path. Transmission security adopts entry point termination and transparent transmission of client identity to the backend. After smooth reload, the application system only accesses the unified entry point. Changes in the location or region of the backend primary and backup will not affect business calls, meeting the requirements for timeliness and compliance.

[0040] After configuration, this embodiment provides a unique access point to the outside world through the request entry address. The routing control component maintains the association between the primary gateway and the backup gateway. The calling end no longer directly perceives changes in the backend host. The entry point and rules take effect through uninterrupted reload. New connections are immediately forwarded according to the latest mapping. This not only establishes the necessary structural prerequisites for subsequent automatic switching and backoff, but also reduces the latency and configuration deviation caused by manual reconfiguration, shortens the service recovery time window, and improves business continuity.

[0041] S20, perform health checks on the main gateway and the backup gateway through the health detection module, and generate health status data;

[0042] In this embodiment, the goal is to periodically, continuously, and quantifiably acquire the operational status of the primary and backup gateways during their operational cycles, and to integrate different types of monitoring results into health status data that can be used for subsequent judgment. The functionality of the health detection module originates from the technical system of network operation and maintenance monitoring and application availability detection, and can provide hardware probes, software probes, containerized probes, or cloud probe services; its implementation is not limited to a single protocol stack.

[0043] During execution, the access endpoints of the primary and backup gateways must first be identified. These endpoints are registered during the configuration phase and include information such as protocol, address, and port. The health monitoring module initiates multi-dimensional probes based on these endpoints. The infrastructure probe collects system-level operational load data, such as CPU usage and memory consumption values ​​read via Secure Shell Protocol (SSH) or monitoring interfaces. This data can reflect host resource bottlenecks or anomalies. The network quality probe evaluates the transmission link, commonly using Internet Control Message Protocol (ICMP) or Transmission Control Protocol (TCP) handshakes to calculate latency and packet loss rate. Excessive latency or severe packet loss directly affects the timeliness and stability of request forwarding. The business probe simulates real business calls, such as constructing HTTP or HTTPS requests that conform to application interface requirements and verifying response status codes and response times. This probe result directly reflects the availability of business functions.

[0044] The collected raw results are timestamped and standardized within the health monitoring module. Different units and dimensions of measurement need to be converted into a uniformly comparable format. For example, percentage load, millisecond latency, and HTTP status codes are mapped to a unified health scoring dimension. Anomaly marking of the probe results is based on preset thresholds. For instance, network quality probes mark network anomalies when they time out, and service probes mark service anomalies when they return a non-success status code. These markings are stored in the intermediate result set along with the raw measurements.

[0045] The health monitoring module integrates the infrastructure metrics, network quality metrics, service metrics, and anomaly markers of the primary and backup gateways into a structured health status data object. This object can be in key-value pair, JSON structure, or binary serialization format, and includes both numerical metrics and Boolean anomaly markers, along with the collection time and target identifier information. In this way, subsequent modules can directly use this data for health status assessment and failover decisions without needing to re-collect the data.

[0046] A centralized probing architecture can be adopted, deploying the health detection module in a network location adjacent to the routing control components to reduce the uncertainty of the probing link. Infrastructure probes access the target host's system interfaces through secure authentication, network quality probes initiate multi-packet measurements at a fixed frequency and calculate the mean and variance, and service probes construct the minimum effective request load for different interfaces and verify the response structure and status codes. Alternatively, a distributed probing architecture can be used, deploying probes in different network locations and comprehensively analyzing multi-point observation results to eliminate interference from local network anomalies.

[0047] In environments with high security requirements, read-only application performance monitoring proxies can be used to replace direct system interface access, avoiding exposure of host management channels. In scenarios with extremely high real-time requirements, probe intervals can be shortened and asynchronous, non-blocking data collection methods can be used to reduce the impact of probes on host performance. When deployed across regions, health status data can be collected separately for each region and uniformly encoded and stored at the data aggregation layer.

[0048] For setting indicator thresholds, quantile thresholds can be automatically calculated based on historical operating data, or absolute values ​​can be manually set. For example, CPU utilization exceeding 80% can be flagged as resource strain, latency exceeding 200 milliseconds as network degradation, and HTTP status codes outside the 200-299 range can be flagged as business anomalies. To improve the accuracy of judgments, a method of multiple probes and taking the median value can be used to filter out occasional anomalies.

[0049] Example Description: In the fintech business, for a bank's one-time password SMS gateway, the health detection module initiates a probe from the node where the routing control component is located every few seconds. The infrastructure probe collects the CPU and memory usage of the gateway server, the network quality probe measures latency and packet loss, and the business probe calls the bank's OTP interface to verify the response status code and response time. The results are encoded into health status data to determine whether it is necessary to switch to a backup gateway.

[0050] In the healthcare business, for the appointment confirmation SMS gateway of the online diagnosis and treatment platform, the health monitoring module periodically simulates appointment confirmation requests, records the response time and status code, and monitors the load and network quality of the backend server. These results are combined into health status data, which is used to quickly switch to the backup node when the host fails, ensuring the real-time delivery of notifications.

[0051] This embodiment continuously provides quantifiable operational status across three dimensions—resources, network, and services—through a health monitoring module. The generated health status data provides consistent and directly usable input for subsequent anomaly detection and switching decisions, reducing manual confirmation steps and improving the timeliness and accuracy of status identification, thereby reducing the risk of service interruption.

[0052] S30, the health status data is received by the anomaly detection and collection submodule of the routing switching module, health status information is generated, and a switching instruction is generated by the switching decision submodule of the routing switching module based on the health status information;

[0053] In this embodiment, the goal is to transmit health status data from the collection side to the routing switching module. The anomaly detection and collection submodule receives, parses, and integrates this data to form consistent, complete health status information with anomaly markers. Subsequently, the switching decision submodule generates switching instructions based on this health status information. The anomaly detection and collection submodule originates from data aggregation and cleaning technologies in the field of operational observability, targeting three types of indicators: resources, links, and services. The access method can be either pull or push, and the payload can be structured text, binary serialization, or message queue events. The health status data refers to the observation results set of the primary and backup gateways, typically including CPU utilization, memory usage, network latency, packet loss rate, response status code, response time, and anomaly markers; these fields come from various probes in the health detection module. Upon access, the anomaly detection and collection submodule appends a timestamp, source identifier, and target identifier to each record to establish uniqueness. It then standardizes the fields and unifies the units to eliminate dimensional differences caused by different collection sources; for example, it maps percentages, time values, and category codes to a unified key space, retaining both original and normalized representations for subsequent processes.

[0054] During the integration process, the anomaly detection and collection submodule systematically merges multiple observations within the same time window, handling missing and duplicate fields, and prioritizing the retention of later valid records. When conflicting anomaly markers exist, a single marker is assigned based on source priority and data freshness. After merging, health status information is generated. The difference between health status information and health status data is that the former has been cleaned, aligned, and aggregated, making it directly usable for decision-making; the latter leans towards the raw collection results and may contain noise and missing items. To improve traceability, the health status information retains a list of sources and processing history, facilitating subsequent problem localization.

[0055] After receiving health status information, the switchover decision submodule loads preset switchover conditions and switchover modes. The preset switchover conditions consist of infrastructure thresholds, network quality thresholds, and service thresholds, sourced from operational baselines, service level agreements, or historical percentile statistics. Switchover modes include two types: observation mode and immediate switchover mode. The former addresses jitter scenarios, using continuous observation for stability assessment, while the latter addresses sudden failure scenarios, prioritizing rapid response. The switchover decision submodule compares each health status information against the set of conditions, generates a set of comparison results, and then outputs a single switchover command based on the switchover mode. The switchover command is an execution request to the request routing submodule, typically containing fields such as target role (primary or backup), target gateway address, validity period identifier, and activation priority. The source description can include the triggered metric name and corresponding threshold description, facilitating logging and alarm module recording the cause.

[0056] To broaden applicability, the anomaly detection and collection submodule and the switching decision submodule are decoupled through an interface contract: the former promises stable field naming, time semantics, and target identifier semantics, while the latter relies solely on agreed-upon fields for comparison, without limiting the upstream collection protocol or implementation language. This preserves the flexibility of cross-platform deployment and facilitates the expansion of collection dimensions without altering the decision implementation, such as adding observations like disk read / write wait times, available connection pool counts, and application thread saturation. For example, the financial side can add a risk control level field, and the medical side can add a business window time period field, both accessing health status information via extended keys without disrupting existing fields.

[0057] Health status data can be accessed in a streaming manner: the anomaly detection and collection submodule is connected to a message queue topic or event bus, processes records in arrival order, and uses a memory ring buffer to maintain the most recent observation window between the primary and backup gateways; or it can be accessed in a batch manner: incremental data is read from the persistent repository of the health detection module at regular intervals, and the observation sequence is reconstructed according to time windows. The former has lower latency and is suitable for high real-time services; the latter puts less pressure on the source end and is suitable for cross-regional or weak network environments.

[0058] Field standardization can be achieved using a mapping table. Establish a mapping between metric names and units. Any newly added metric must first be renamed and have its unit unified through the mapping table before entering the merging process. For missing fields, placeholders and availability markers are used to fill in the gaps; for duplicate fields, a source priority strategy is used to select the retained items. Anomaly marker merging employs a two-stage process: first, merging within a source, then merging across sources; within a source, the later the time is used; across sources, the source with higher credibility is used. Credibility is derived from the collection method, probe stability, and historical consistency.

[0059] The switching decision submodule's loading conditions can come from the configuration center or read-only storage. To avoid jitter caused by frequent changes, a change activation delay and version number are set. The anomaly detection and collection submodule carries the version number in the health status information, and the switching decision submodule selects a matching version for comparison based on this. The observation mode can be implemented using a combination of counters and time windows: whenever an anomaly marker appears in the health status information, an unqualified observation is recorded, and old records are cleared when the time window expires; a switching command is only output when the cumulative number of unqualified observations reaches a threshold. The immediate switching mode directly outputs the switching command when a single observation triggers the condition, with an additional short protection time to avoid round-trip switching.

[0060] When outputting a switching command, the switching decision submodule generates a unique identifier, a replay prevention identifier, and a validity period identifier. The anomaly detection and collection submodule attaches a summary of the corresponding health status information to the switching command metadata, facilitating downstream recording of the cause. When interfacing with the request routing submodule, an idempotent interface is used: repeated delivery of a switching command with the same unique identifier only generates one update, avoiding duplicate execution due to network jitter. To coordinate with the logging and alarm modules, the switching decision submodule submits an audit event along with the output command, including a summary of the triggering conditions, the trigger source, and the target gateway information, facilitating unified recording.

[0061] In resource-constrained environments, the anomaly detection and collection submodule and the switchover decision submodule can be deployed as a single process, internally using a shared memory queue to transmit health status information. In high-concurrency environments, they can be deployed separately, communicating via zero-copy queues or local sockets to reduce replication overhead. To adapt to cross-regional scenarios, health status information can include regional identifiers and weights, and the switchover decision submodule outputs instructions based on the nearest region. When an anomaly is observed in the local region but normal in the remote region, the remote backup gateway is selected as the target, and the switchback proceeds only after the local region recovers.

[0062] Example Description: In the fintech business, the group's SMS platform accesses the bank's one-time password interface through a routing control component. The anomaly detection and collection submodule continuously receives observation records from resource probes, link probes, and interface probes, uniformly mapping them to health status information. When the response status code is abnormal and network latency further increases, the switchover decision submodule generates a switchover instruction based on the observation mode after multiple consecutive unqualified observations, pointing to the backup gateway address. Subsequently, the request routing submodule performs a route update, allowing SMS data retrieval and push to continue.

[0063] In the healthcare business, appointment confirmations and critical test notifications need to be delivered reliably. The anomaly detection and collection submodule aggregates application node load, intra-hospital link quality, and interface response performance into health status information. When an interface becomes unavailable during a business period and is accompanied by resource congestion, the switchover decision submodule directly outputs a switchover command in immediate switchover mode, switching the forwarding target to a backup node to avoid notification backlog and appointment failures.

[0064] In this embodiment, the anomaly detection and collection submodule organizes multi-source observation results into a consistent health status information. The switching decision submodule outputs a clear switching command based on this information, forming a low-latency closed loop from observation to decision. This reduces the delay and probability of misjudgment caused by manual intervention, improves the timeliness and controllability of primary / backup switching, and provides traceable triggering basis for the log and alarm modules.

[0065] S40, the routing submodule of the routing switching module updates the routing relationship in the routing control component and determines the target gateway according to the switching instruction;

[0066] In this embodiment, the goal is to enable the request routing submodule to atomically update the routing relationships in the routing control component based on the switching instruction, and to provide a clear target gateway. The request routing submodule originates from the gateway forwarding and load balancing domain, and typically exists as an independent process, embedded module, or side-wheel proxy. It is responsible for parsing instructions, verifying their validity, executing routing changes, and returning results and audit information. The switching instruction is a behavior description oriented towards the execution layer. The payload may include fields such as target role, target gateway address, priority, validity period identifier, idempotency identifier, and grayscale ratio identifier. The source can be a message event issued by the switching decision submodule, configuration center changes, control plane pushes, or local callbacks. To ensure compatibility, the instruction format can adopt either a key-value structure or a hierarchical structure. The meaning of the fields is agreed upon in the contract document and stored in the version repository. The version number carried by the instruction is matched with the capability set of the routing control component to avoid incompatible updates.

[0067] The routing control component is the execution entity that carries the forwarding logic between the request entry address and the backend gateway. It can take the form of a reverse proxy, a Layer 4 load balancer, a service mesh data plane, or a forwarding table of a programmable switch. The routing relationship is the data structure within the routing control component used to determine the request's path, represented as a combination of elements such as upstream target sets, weight tables, matching rule sets, connection persistence policies, and health status hooks. The target gateway is a gateway instance or group of instances capable of providing external business capabilities. It can be a primary, backup, or equivalent backup within a region, and its location depends on three types of information: gateway address, identifier, and tag.

[0068] The execution chain begins with receiving the switchover command. The request routing submodule reads the command and performs idempotency checks, using an idempotency flag to determine if execution is repeated. Semantic checks are then performed, covering field integrity, target gateway existence, and conflict detection with the current route. Conflict detection includes checking if a higher-priority update already exists for the same ingress point, whether the target gateway is isolated, and whether there are any incomplete connection clearing tasks. After successful checks, a change plan is generated. The change plan defines the affected ingress point set, matching rules, weights, and session persistence policies, and specifies the execution order. To mitigate risk, the change plan supports grayscale fields. When a grayscale flag exists, it is first written to shadow rules at a small percentage, and availability is verified using probe requests or real-time telemetry before expanding coverage until a complete switchover.

[0069] The write phase is implemented through two paths. The memory path writes the new routing relationships to the runtime data plane by calling the hot-update interface of the routing control component, ensuring atomicity and rollback capability. The configuration path generates a configuration snapshot, saves it to a temporary file or configuration storage, and triggers a lossless reload after consistency verification, ensuring that the old and new worker processes run concurrently, old connections are naturally exhausted, and new connections enter the target gateway according to the new rules. Both paths record version numbers and checksums for easy rollback to the previous version. To ensure compatibility with long-lived connections, the change plan can include connection purging strategies, such as setting old targets to no longer accept new connections, retaining existing connections until timeout or completion, and synchronously tracking connection counts and latency metrics during this process.

[0070] When determining the target gateway, the request routing submodule performs a one-time resolution based on the target role and gateway address in the switching instruction. If necessary, it queries the registry or cache to supplement metadata, such as availability zone, network domain, supported protocol set, and current load indicator. It also filters unavailable instances based on health status hook results and selects the final target by weight or tag. To cooperate with the logging and alarm modules, the execution chain generates audit records at three key points: receiving the instruction, writing completed, and result confirmation. These records include a summary of the switching reason, the old version number, the new version number, the target gateway identifier, and the entry identifier.

[0071] The confirmation process is implemented through two pathways. Active confirmation involves the routing control component exposing its probe interface. Upon receiving a successful write signal, it immediately sends a probe request to the target gateway address, confirming availability based on a successful response. Passive confirmation involves reading the new traffic hit and error rates from the routing control component's real-time telemetry; success is considered achieved if a preset threshold is met. These two confirmation pathways are not mutually exclusive and can be enabled simultaneously to increase confidence. If confirmation fails, a rollback plan is executed, restoring the routing relationship to the previous valid version, and simultaneously delivering audit and alarm events.

[0072] Hot updates via a reverse proxy can be implemented. The request routing submodule maps the switching command to a weight adjustment or redirection of the upstream target group. First, the new target is registered in the memory data plane. Then, the entry point is bound to the new target group. Finally, a lossless reload is triggered to allow rules to switch between the old and new processes. The reload action does not terminate existing connections; new inbound connections are routed to the target gateway according to the new routing relationship. To reduce intermittent outages, a session persistence policy is enabled and a drain flag is set. The old target no longer accepts new connections until the connection count reaches zero or the timeout period is reached.

[0073] Service mesh control plane push can be used. The request routing submodule, as a downstream component of the control plane, constructs a routing resource object after receiving the switching instruction. This object includes the route entry, matching conditions, and cluster target. The resource object is then pushed to the data plane through the control plane interface, and the data plane hot-loads the resource according to the resource version. If canary fields are enabled, shadow route entries are generated first, and verification is completed in conjunction with request mirroring or proportional routing before replacing the main route entries.

[0074] Layer 4 load balancing can be used for switchover. The request routing submodule writes the target gateway address to the backend pool, sets the old backend to an empty state, updates the forwarding table or backend pool weight, and triggers the forwarding table to take effect. To support multi-region deployment, region tags and priorities are introduced, prioritizing targets within the same region, and using cross-region targets as a fallback path. If the entry point uses an anycast address, routing relationship updates and routing propagation are managed within the same change transaction to ensure the stability of the external entry point.

[0075] Parallel rollback protection can be introduced. During writing, a rollback snapshot is generated synchronously, containing the routing relationships, weights, and binding relationships of the old version. When the confirmation failure module receives a failure event or the health detection module reports an anomaly again, the rollback snapshot is applied directly, and then the failure snapshot and trigger context are written to the audit database for analysis.

[0076] Idempotency and debouncing mechanisms can be added. Each switching instruction has a unique identifier, and repeated arrivals are only recorded once. When consecutive instructions in the opposite direction are received within a short period of time, debouncing windows are used to merge and execute them, avoiding jitter caused by frequent back-and-forth switching. To avoid single-point bottlenecks, the request routing submodule can be horizontally scaled, and a master election or lease mechanism is used to ensure that changes at the same entry point are executed serially by a single instance.

[0077] Example Description: In the fintech business, the entry point of the SMS platform is monitored by the routing control component. The switching decision submodule issues an instruction to the backup gateway. After the request routing submodule parses the instruction, it binds the entry point to the upstream group where the backup gateway is located, and enables session persistence and connection emptying. After reload, it immediately sends a probe request to the backup gateway address, and at the same time reads real-time telemetry to confirm that the new traffic has hit the backup end. Once the confirmation is successful, it writes to the audit log and sends back the status. The verification code request continues to be forwarded stably.

[0078] In the healthcare business, appointment notifications are sent to the agent through a unified portal. Network jitter causes the main gateway to respond abnormally. The decision-making side issues a switching instruction, requesting the routing submodule to switch the target to an available gateway instance in the same region. The new target is first imported in a low-scale grayscale. After observing that the error rate in telemetry is normal, it is expanded to the full scale. During this period, the old instance is set to be drained and the existing connection is maintained until the completion. The notification sending link remains consistent.

[0079] This embodiment converts the switching command into a rollbackable routing relationship update through the request routing submodule, and confirms the result through dual channels of probing and telemetry. The routing control component completes the determination of the target gateway and the activation of the new rule without interrupting the existing connection, reducing manual intervention and delay, reducing the probability of backswing jitter and incorrect routing, and providing a complete triggering and execution chain for subsequent logs and alarm records.

[0080] S50, the service request is forwarded to the target gateway through the request entry address;

[0081] In this embodiment, the request entry address is used to uniformly handle external inbound traffic. The source can be a reverse proxy listening address, a Layer 4 load balancer entry point, an inbound endpoint of the service mesh, or an anycast address mapping. This address is bound to the routing control component, carrying out receiving, parsing, and forwarding actions. The service request points to a specific call to the gateway application, including elements such as method, path, header, payload, authentication information, and tracking identifiers. It can originate from the application server, the enterprise SMS platform, or the internal information platform. The target gateway is the gateway instance or group of instances that actually processes the service request, possessing address, identity, availability zone label, and protocol capability information, and is typically identified after the preceding routing relationships are updated.

[0082] Upon receiving a service request at the request ingress address, the routing control component first performs ingress matching and protocol identification, extracting the protocol type, hostname, path, and query string, while also reading the tracing identifier for subsequent link diagnostics. Following this, pre-forwarding preparations are performed, including destination address resolution, header processing, and connection reuse strategy selection. Destination address resolution reads the target gateway address and port identifier based on the existing routing relationships, supplementing gateway metadata from the registry or local cache if necessary. Header processing covers host header rewriting, origin verification, authentication pass-through, and compression negotiation, ensuring downstream devices correctly understand the request semantics. Connection reuse strategies reduce handshake overhead and latency, selecting between persistent connections, pooled connections, or new connections based on the protocol and gateway capabilities.

[0083] The request reconstruction phase maps the semantics of the ingress gateway to a form acceptable to the target gateway, including path concatenation or rewriting, header addition / deletion, direct payload transmission, or secondary encapsulation. If there are protocol differences between the ingress and target, protocol bridging is performed to complete the conversion between plaintext and encryption, different application layer protocols, and maintain end-to-end tracking. Then, downlink forwarding is initiated, sending the reconstructed request to the target gateway, and applying timeout management, concurrency control, and retry strategies during transmission. Retry is based on idempotent semantics and is triggered only if the target gateway has not established a session or returned a definite result, avoiding duplicate submissions. To reduce jitter, connection warm-up and slow start strategies can be enabled shortly after the target gateway switchover, allowing the new target to gradually carry business requests.

[0084] In the return path, the routing control component receives the service response data from the target gateway, performs header write-back, compression or decompression, encoding conversion, and trace identifier padding, maintains the status code and load unchanged, and returns the service response data to the requesting source according to the original connection. Events and metrics generated throughout the entire link are sent to the telemetry channel, including target hit information, latency distribution, error type, and origin bandwidth, for operation and maintenance and auditing. In abnormal scenarios, a degraded forwarding or fast failure strategy is triggered: when the target gateway is unreachable during the handshake phase, a clear error is returned; when the target gateway returns a definite error during the application phase, no automatic retry is performed, but the error is transmitted back and the hit information is recorded for use in subsequent decision-making.

[0085] This can be implemented using a reverse proxy. At the operating system layer, a listening socket is bound to the request entry address, enabling parallel connection processing using a multi-process or multi-threaded model. After receiving the path resolution protocol and path, the target gateway address is obtained by querying the routing relationship through shared memory. The host header and source address marker are rewritten as needed, reused in the target gateway's long connection pool, and downstream requests are constructed and sent. A header whitelist mechanism is enabled to restrict the inbound and outbound header sets, preventing irrelevant fields from affecting the gateway's judgment. When the response is returned, it is processed according to the compression negotiation and encoding requirements on the entry side. Finally, the response is written back to the entry connection and the context is released.

[0086] Alternatively, a service mesh data plane can be used. Configure the request entry address as an inbound listener, select routes using a matching chain, and direct requests to the target gateway instance based on the target cluster selection strategy. Enable request mirroring for canary deployments; once the target is determined, disable mirroring and retain only the main route. For bidirectional encryption scenarios, inbound and outbound processes each perform certificate verification and session establishment independently, while the data plane internally maintains plaintext or re-encrypted transmission, ensuring consistent tracking identifiers.

[0087] Alternatively, a Layer 4 load balancing approach can be used. The request entry address is processed at the transport layer, and the connection is allocated to the target gateway based on the seven-tuple and weight mapping. If necessary, a proxy header is injected during the connection establishment phase to transparently transmit the source address information to the target gateway. To minimize interruptions, connection scheduling supports non-disruptive migration and session persistence. Combined with the empty flag in the routing relationship, new connections are suspended during target switching without affecting in-transit traffic.

[0088] To improve stability, rate limiting and circuit breaking can be introduced. Thresholds can be set at the request entry address level based on historical latency and error categories. When triggered, rate limiting can be applied to the entry point or the target gateway can be temporarily isolated, and the event can be written to telemetry for upstream decision-making reference. To reduce first-hit latency, a connection preheating strategy can be used. After routing updates, an idle connection to the target gateway can be established in advance and a handshake completed before handling new requests. To ensure observability, entry-target hit statistics, forwarding time, retry statistics, and error distribution can be output to the log and metrics system in a unified format, supporting aggregation by entry point, target gateway, availability zone, and tag dimensions.

[0089] Example description: In the field of fintech business, the group SMS platform sends the verification code request to the request entry address. The routing control component selects the target gateway based on the effective routing relationship, rewrites the host header and reuses it in the gateway's long connection pool, sends the request, and writes it back to the platform application as is after receiving the business response data. The platform does not need to be aware of the target change behind it, and the verification code sending link remains continuous.

[0090] In the healthcare business, in-hospital appointment reminders are sent from the in-hospital information system to the request entry address. The routing control component reads the routing relationship and selects the nearest target gateway. During peak periods, connection warm-up and rate limiting are enabled to ensure stable forwarding under high concurrency. When the target instance is temporarily unreachable, a clear error is quickly sent back and the hit information is recorded for monitoring and subsequent automatic switching.

[0091] This embodiment unifies the reception, parsing, reconstruction, and forwarding within the request entry address and connects with the already effective routing relationship. Once the target is clear, the inbound traffic will stably reach the target gateway along the expected path. Connection reuse and warm-up reduce handshake costs, write-back and transparent transmission maintain the consistency of response semantics, and telemetry output provides a basis for subsequent operation and maintenance and decision-making. Anomaly handling and rate limiting circuit breaking reduce the scope of error propagation, and the forwarding link maintains continuity during target changes.

[0092] S60 records routing switching information and abnormal information and sends alarm notifications through the log and alarm module;

[0093] In this embodiment, the logging and alarm module performs dual functions of recording and notification, forming a chain around routing switch information and anomaly information that includes collection, shaping, storage, generation, distribution, receipt verification, and closed-loop tracing. Routing switch information includes switch time, switch reason, target gateway, original gateway, switch command type, switch decision source, and request entry address hit status. Anomaly information includes anomaly markers in health status data, indicator snapshots, probe failure categories, and return code summaries from the request routing submodule. To ensure integrated tracing, the logging and alarm module uses the same entry identifier and link identifier in both the database entry and distribution stages. The entry identifier is used for idempotency and deduplication, while the link identifier is used to connect events before and after the switch.

[0094] The data collection phase is driven by two input paths: one from the switching event stream exposed by the routing switching module, containing the switching command type and target gateway; and the other from the abnormal event stream exposed by the health detection module, containing abnormal markers and indicator snapshots. The logging and alarm modules align the two inputs with a timeline, establish field mappings, and establish a causal relationship between switching events and health anomalies. The shaping phase standardizes the routing switching information and abnormal information into structured records, with fields grouped into a basic metadata group, a health summary group, a switching decision group, an execution result group, and an alarm dispatch group. The basic metadata group contains entry identifiers and link identifiers; the health summary group contains abnormal markers and key indicator summaries; the switching decision group contains the switching command type and switching reason; the execution result group contains the target gateway and the original gateway; and the alarm dispatch group reserves notification channels and recipient sets.

[0095] In the storage phase, structured records are written to the log database, employing a queryable model compatible with full-text search and conditional search. A field-level write strategy requires strong consistency in writing to the main log table and asynchronous writing to the index. To ensure reliability during peak periods, a write queue and batch commit are introduced. Failed entries are placed in a retry queue, and an entry identifier is retained to prevent duplicate writing. In the generation phase, alarm notifications are derived from the structured records. A subject and body are generated based on a notification template, which includes the minimum necessary fields and supports placeholders for extended fields. During template rendering, field integrity and sensitive information anonymization rules are validated; for example, gateway addresses are presented as masks, and link identifiers are presented as hashes.

[0096] In the alarm distribution phase, the alarm dispatch group selects and establishes a connection with the appropriate notification channel. This channel can be email, SMS, or an enterprise alarm platform, all using a unified sending interface. Before sending, throttling and noise reduction are performed. Multiple triggers with the same link identifier and switching command type within a short period are merged into a single dispatch, with the number of merges noted in the message body. After sending, the system waits for channel feedback. Successful feedback is written back to the structured record of the dispatch status; failed feedback triggers an exponential backoff retrieval process, recording the number of retries and the final reason for failure. Closed-loop tracking links the feedback status with the entry identifier in the log database. Incomplete entries are periodically added to the inspection list, where inspection tasks complete the status or trigger manual reminders. To ensure consistency, the log and alarm modules write a baseline record after each routing relationship update to distinguish between normal and abnormal switching.

[0097] Access control and compliance are implemented through a two-layer system. The first layer performs field-level access control on the log database side, restricting the reading scope of sensitive fields. The second layer performs anonymization and minimizes output on the alarm notification generation side, outputting only the necessary set of fields. Data integrity is achieved through signature field verification and timestamp alignment. The signature field covers the entry identifier, link identifier, and key field summary. Timestamp alignment is based on the event time of the routing switching module, with time drift corrections made by the health detection module and the request routing submodule. To facilitate location, the log and alarm modules map the request entry address, target gateway, and original gateway to availability zone and data center labels, forming a retrieval index based on geographical and topological dimensions.

[0098] The logging and alarm modules can be deployed as independent services and connected to the switching event stream and abnormal event stream via a message bus. Serializable consumer groups ensure that each event is processed only once. Structured records are stored using a hybrid of key-value pairs and columnar indexes. Key-value pairs are used for fast lookup by entry identifier, while columnar indexes are used for high-dimensional filtering. The template system loads multiple alarm templates and uses a conditional selector to select the appropriate template. The conditional selector determines the appropriate template based on the switching command type, target gateway label, and channel availability. Email channels establish connections and send messages via transport layer encryption; SMS channels send short text messages through the enterprise gateway interface; and the enterprise alarm platform channel pushes events via the platform API. All three channels implement unified receipt parsing, with the receipt state machine including states such as pending, sent, confirmed, failed, and retry.

[0099] Alternatively, the log and alarm modules can be embedded into the plugin system of the routing control component. The collection interface delivers data to the plugin via a memory queue. After the plugin completes shaping and template rendering, it writes the records to local persistence, and then a background thread asynchronously aggregates them to the central log database. Channel selection is controlled through a local policy file, allowing the use of only the enterprise alarm platform channel in a network isolation environment, and automatically resending emails and SMS messages after external connections are restored. To improve timeliness, when the plugin detects that the switching command type is immediate switching, it directly triggers the high-priority channel and skips noise suppression and merging, ensuring that it reaches the on-duty personnel as soon as possible.

[0100] The logging and alarm modules can also be integrated with the observability platform. Structured records are synchronously written to a time-series database and an event repository. The time-series database contains timelines of latency, error rates, and traffic spikes, while the event repository stores detailed records of routing switch information and anomaly information. The two are linked through link identifiers. Alarm rules are maintained on the observability platform side. The logging and alarm modules receive alarm decisions from the platform and are responsible for issuing and receiving acknowledgments, forming a centralized rule system with decentralized execution. To handle cross-regional deployment, the module introduces a regional prefix for entry identifiers. When aggregating across regions, the module performs fragmented aggregation and sequential merging based on the regional prefix.

[0101] Example Description: In the fintech business, when the group SMS platform triggers a channel anomaly, it enters the routing switch process. The log and alarm module receives the switch event and health anomaly, and generates a structured record containing the switch reason, target gateway, and request entry address hit status. This record is simultaneously sent through the enterprise alarm platform channel and SMS channel. After receiving a successful receipt, the entry status is updated to "confirmed". Based on this, operations and maintenance personnel can view the latency curve and error distribution of the corresponding link in the console with one click and troubleshoot accordingly.

[0102] In the healthcare business, when the in-hospital reminder service experiences a gateway switch during peak business hours, the log and alarm modules merge the anomaly marker and the switch command type into the same record, push it to the department's IT duty email via email, and at the same time, the event card pops up on the platform's alarm wall. The receipt status is synchronized to the event repository. The duty personnel can quickly retrieve the target gateway and availability zone tag involved in the switch based on the link identifier, confirm that the service is uninterrupted and complete the event loop.

[0103] This embodiment collects routing switching information and abnormal information in a unified manner and forms a structured record. The log and alarm modules establish a causal relationship between switching events and health anomalies. The notification issuance has noise suppression, merging, and acknowledgment closed-loop capabilities. Item identifiers and link identifiers connect the collection, storage, and dispatch links, making the location and accountability paths clear, reducing the latency of on-duty response, and separating configuration and execution to bring more stable alarm delivery.

[0104] S70, when the health detection module detects that the main gateway has recovered, it generates a switchback instruction through the switching decision submodule, and updates the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

[0105] In this embodiment, the health monitoring module continuously generates recovery judgment inputs during runtime. These inputs are derived from combined observations of infrastructure and business metrics, including CPU usage, memory usage, network latency, packet loss, interface response status, and response time. To avoid jitter, the health monitoring module performs timeline merging and direction consistency checks on continuous observation results, resulting in two types of data: recovery judgment conclusions and recovery judgment criteria. The recovery judgment conclusions are used to trigger subsequent actions, while the recovery judgment criteria are used for tracing and auditing. The switching decision submodule subscribes to the recovery judgment conclusions from the health monitoring module. When the recovery judgment conclusion indicates that the primary gateway is available, the switching decision submodule loads a preset recovery condition set and a backoff constraint set, performs a consistency comparison with the recovery judgment criteria, and generates a backoff instruction. The backoff instruction includes fields such as the target gateway identifier (primary gateway), target gateway address, backoff trigger source, trigger time, backoff priority, and fallback strategy hook. These fields are encapsulated in an immutable format for easy cross-module transmission and idempotent processing.

[0106] After receiving a switchback command, the request routing submodule enters the parsing phase. It extracts the target gateway address and switchback priority from the command, verifies the command's source and signature to prevent expired or duplicate commands from entering the execution path. After successful parsing, it enters the routing relationship change preparation phase. It reads the current routing relationships and configuration set snapshot from the routing control component, generates a change plan, and describes the adjustment of the pointer from the current target to the main gateway, the member mapping between the listening ingress and the upstream pool, and the start / stop order of weights and health probes. To control connections in transit, the change plan includes connection exhaustion policies for old targets and cold start detection policies for new targets. Based on this, the request routing submodule updates the routing relationships in the routing control component, restoring the pointer from the ingress to the upstream to the main gateway address, and triggers the routing control component's reload process, making the new routing relationships effective. The reload process is executed in a lossless manner, preserving existing connections until completion or timeout, while applying the new routing relationships to newly arriving requests.

[0107] To mitigate the risk of rollback failure, the request routing submodule immediately sends a probe request to the main gateway address upon activation. This probe request covers the handshake, basic interface calls, and authentication links. Upon receiving the probe response, the rollback execution result is marked based on the response status and timing consistency. Successfully, the target gateway is recorded as active; otherwise, the change is revoked according to the rollback strategy hook, reverting the routing relationship to its pre-activation state. The reason for failure and the recovery criteria are also written into the audit. Throughout the process, the logging and alarm modules record the rollback time, reason for rollback, target gateway, and original gateway, forming a closed-loop traceable link. In concurrent scenarios, the request routing submodule uses the idempotent key of the rollback command and the version number of the routing relationship to control mutual exclusion, allowing only a single rollback link to enter the execution state, while other concurrent commands enter a waiting or discarded branch.

[0108] A recovery determination pipeline can be added to the health monitoring module. This pipeline comprises three stages: observation and data acquisition, time window aggregation, and directional consistency verification. Observation and data acquisition simultaneously obtains indicators from both the infrastructure and business sides; time window aggregation integrates continuous observations into a single conclusion; and directional consistency verification eliminates misjudgments caused by single rebounds. The recovery determination conclusion generated by the pipeline is delivered to the switching decision submodule via the event bus.

[0109] A two-layer verification system, consisting of a recovery condition set and a rollback constraint set, can be introduced in the switchover decision submodule. The recovery condition set determines whether the primary gateway meets the rollback requirements, while the rollback constraint set determines whether the current business phase allows rollback, such as postponing rollback when there are a large number of pending requests. After the two-layer verification passes, a rollback instruction is generated. The instruction signature is completed by the key service, and the instruction is stored in the event stream and labeled with an idempotent key and version number.

[0110] A three-stage rollback execution can be implemented in the request routing submodule. The first stage is preparation, which reads the routing relationship snapshot from the routing control component, generates a change plan, and writes it to temporary storage. The second stage is commit, which modifies the routing relationship according to the change plan and triggers the reload of the routing control component to make the new relationship effective. The third stage is verification, which verifies the availability of the main gateway service by probing requests. If successful, the version number is moved forward and the change plan is archived; if it fails, the rollback hook is called to restore the old relationship and record the failure context. The three stages are isolated by transaction boundaries, allowing for safe rollback at the boundaries in case of exceptions.

[0111] Partition rollback policies can also be configured in cross-region deployment environments. The switching decision submodule generates partition rollback instructions based on region tags, requesting the routing submodule to execute the rollback in partition order to avoid jitter caused by simultaneous switching across the entire region. To adapt to different routing control components, different overload triggering methods are implemented at the implementation layer, such as sending overload signals to processes or calling management interfaces to complete lossless hot updates. To adapt to different security domains, two types of paths are selected during the probing phase: internal network probing or isolated zone proxy probing, and the probing path type is marked in the instructions to ensure consistency between the probing and production paths.

[0112] Example Description: In the fintech business, the connection between the group's SMS platform and the bank's gateway is carried out on the backup gateway. After the health detection module detects that the primary gateway has recovered, it gives a recovery judgment conclusion. The switchover decision submodule generates a switchback command and delivers it. The request routing submodule adjusts the entry point to the upstream address back to the primary gateway address according to the change plan, completes lossless reload, and initiates a probe to the primary gateway. After the request returns successfully, it marks the switchback as complete. SMS data retrieval and push are re-entered through the primary gateway path, and the backup gateway is deactivated for standby.

[0113] In the healthcare business, the in-hospital reminder service uses a dual-gateway deployment, with the backup gateway handling the business outside of the designated on-call hours. When the health monitoring module confirms that the primary gateway is available, the switchover decision submodule issues a switchback command, requesting the routing submodule to update the routing relationships and perform a health probe. Once the probe meets the requirements, the switchover takes effect, and medical order reminders and test notifications resume using the primary gateway. The backup gateway remains in hot standby mode, and alarm records automatically associate this switchback with previous abnormal links for easy subsequent auditing.

[0114] This embodiment achieves a continuous link of recovery determination, instruction generation, routing relationship update and effectiveness verification. After the main gateway recovers, it can complete the switchback without human intervention. The routing relationship is switched back to the main gateway in a lossless manner. After the effect is achieved, service detection is performed immediately and the decision to retain or roll back is made based on the results. With the help of idempotency and version control, concurrent interference is avoided, and the overall switchback latency and failure probability are reduced, thereby reducing the risk of service interruption.

[0115] This invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as fintech and healthcare. It discloses an automatic switching method, apparatus, device, and medium for gateway applications, comprising: configuring a routing control component to associate a primary gateway and a backup gateway and setting a request entry address; performing health checks on the primary and backup gateways and generating health status data through a health detection module; receiving the health status data and generating health status information through an anomaly detection collection submodule of the routing switching module; generating a switching instruction based on the health status information through a switching decision submodule; updating the routing relationships in the routing control component and determining the target gateway through a request routing submodule based on the switching instruction; forwarding the business request to the target gateway through the request entry address; recording routing switching information and anomaly information and sending alarm notifications through a log and alarm module; and when the health detection module detects that the primary gateway has recovered, generating a rollback instruction through the switching decision submodule and updating the routing relationships in the routing control component through the request routing submodule to complete the rollback. This invention introduces modules such as health detection, switching decision, and request routing into gateway applications, enabling automated switching when the main gateway or channel malfunctions and automatic reverting during recovery. This eliminates the delay caused by manual configuration modifications, effectively reduces the risk of service interruption during faults, and ensures the continuity and stability of high real-time services.

[0116] In one embodiment, step S10 above includes:

[0117] S101, Create a routing control component instance;

[0118] S102, Add the first access address of the main gateway to the routing control component instance;

[0119] S103, Add the second access address of the backup gateway to the routing control component instance;

[0120] S104, Set the listening address of the routing control component instance as the request entry address;

[0121] S105, Send a test request to verify the network connectivity between the routing control component instance and the first access address and the second access address;

[0122] S106, When the network connectivity verification is successful, the routing configuration of the routing control component instance is activated to make the routing relationship in the routing control component instance effective;

[0123] S107, when network connectivity verification fails, the log and alarm module is triggered to record the configuration abnormality.

[0124] In this embodiment, the routing control component instance operates on a unified ingress and upstream mapping mechanism. A named instance is generated in the runtime environment, allocated an independent configuration and state space, initializes an empty routing relationship set, upstream node pool, and listener binding set, and establishes a version number and idempotent key for subsequent changes and rollbacks. This instance can originate from a software-based reverse proxy or traffic distribution device, or a gateway framework with proxy forwarding capabilities, as long as it can maintain the ingress-to-upstream pointing relationship and support hot-applying. After instance generation, placeholders for default security policies, certificates, and access control lists are loaded, but ingress binding and upstream registration are not performed to prevent unverified configurations from prematurely entering the production path.

[0125] The primary gateway's first access address is added to the upstream node pool of the routing control component instance. The source of the first access address can be a domain name or network address, or a service identifier from the service registry. The format must include the transport layer protocol and service port or equivalent identifier. Semantic and conflict checks are performed during addition, including address syntax validity, deduplication from existing entries, no alias conflicts with backup gateway entries, and no loopback risk with the listening binding. After successful checks, a role and priority tag is added to the primary gateway entry, written to the primary target bit of the candidate routing relationship, and associated with a health probe configuration placeholder, providing a hook point for subsequent connectivity verification and runtime health monitoring.

[0126] The backup gateway's second access address is added to the same upstream node pool in a symmetrical manner. The source and format of the second access address are consistent with the first access address. The registration process reuses the same set of semantic verification and conflict verification logic, and the entry is tagged with a backup target. To avoid a single point of failure caused by the primary and backup gateways pointing to the same physical terminal, the verification phase checks the address equivalence relationship and certificate fingerprint equivalence relationship. If equivalence is found, registration is blocked, and diagnostic information is generated and submitted to the log and alarm module's diagnostic channel. After successful registration, the candidate routing relationship simultaneously holds structured pointers to both the primary and backup targets, allowing for subsequent weight adjustments or target switching at the decision-making level.

[0127] The listening address is set as the request entry address and mapped to the instance's listening binding set. The request entry address can originate from a service domain name or a network address. The mapping process completes port binding, protocol stack selection, and certificate chain loading, while simultaneously establishing a virtual host mapping and path matching table for the entry point to candidate routes. To mitigate the risk of entry point conflicts, the listening binding process queries the current runtime environment's occupancy list. If occupancy is detected, it is not written into the binding but instead rewritten to a pending state, waiting for manual or automated processes to release it before retrying. After binding is complete, the instance has the ability to receive inbound requests and distribute them to the upstream pool, but it remains in a candidate state and does not take over production traffic until connectivity verification and activation are completed.

[0128] The test request is used to verify the network connectivity between the routing control component instance and the first and second access addresses. The test request originates within the instance, travels through the same forwarding link as the production path to the upstream node, and covers transport handshake, application layer probing, and optional authentication probing. The returned results record three elements: round-trip time, handshake result, and response code. To reduce false positives, the test request is sent multiple times in short cycles and timeline merged. The merged results are marked as connected, unreachable, or uncertain. For connected states, success evidence is recorded and bound to candidate route relationships; for unreachable or uncertain states, failure context is recorded and the diagnostic branch is initiated. After both upstream addresses have completed their output, an overall verification report is generated, archived within the instance, and pushed to the audit channel of the logs and alarms module.

[0129] When connectivity verification passes, the routing configuration of the routing control component instance is activated, making the routing relationships within the instance effective. The activation process proceeds in a transactional manner. First, candidate routing relationships are copied to the version to be activated. Then, semantic review and dry run checks are performed. The dry run renders the forwarding table according to the production path but does not persist traffic. After verification, a lossless reload is triggered. During the reload, existing connections are maintained until natural termination, and newly arriving requests are forwarded to the upstream pool according to the version to be activated. After the reload is completed, the version to be activated is promoted to the current version, the version number is moved forward, and candidate configurations and verification reports are archived, forming a traceable configuration genealogy. To avoid race conditions caused by concurrent activation, the activation process uses instance-level version locks and idempotent keys, allowing only one candidate version to enter the activation channel.

[0130] When connectivity verification fails, the logging and alarm module is triggered to record the configuration anomaly. The logging and alarm module receives the failure context and overall verification report from the instance, extracts the request entry address, failed access address, failure stage category, error category, and timestamp, generates structured log entries, and writes them to persistent storage. Simultaneously, it generates alarm notifications according to the alarm policy and delivers them to notification channels. To support subsequent troubleshooting, log entries are associated with the version number and idempotent key of candidate routes, enabling quick location of the corresponding candidate configuration and verification batch after a failure. Alarm notifications enter a suppression window after the initial issuance to avoid noise from repeated alarms, while retaining an escalation channel to increase the alarm level in the event of prolonged failures.

[0131] This embodiment establishes a tight causal chain between instance generation, upstream registration, entry point binding, connectivity verification, and lossless activation. The entry point to the upstream undergoes consistency and channel reachability verification before production. The activation action and the routing relationship activation action are clearly separated yet sequentially connected, reducing the probability of unverified configurations entering the production path, lowering human intervention and configuration deviations during the master-slave switchover preparation phase, and enabling traceability and rapid location in abnormal scenarios through structured logs and alarm channels. This shortens the lead time for deployment and switchover and reduces the risk of SMS data retrieval and forwarding interruptions.

[0132] In one embodiment, step S20 above includes:

[0133] S201, The health detection module sends infrastructure probes to monitor the CPU usage and memory consumption of the main gateway and backup gateway;

[0134] S202, The network quality probe is sent through the health detection module to monitor the network latency and packet loss rate of the main gateway and the backup gateway;

[0135] S203, The health detection module sends a service probe to simulate a request to monitor the response status code and response time of the main gateway and the backup gateway;

[0136] S204, when the network quality probe response times out, mark the primary gateway and / or backup gateway as having network anomalies;

[0137] S205, when the service probe returns a non-success status code, mark the primary gateway and / or backup gateway as having a service abnormality;

[0138] S206, Generate health status data including the CPU utilization, memory usage, network latency, packet loss rate, response status code, response time, and anomaly markers of the primary gateway and backup gateway.

[0139] In this embodiment, the health monitoring module establishes observation channels simultaneously for the primary and backup gateways. Independent execution units and result caches are allocated to the infrastructure probe, network quality probe, and service probe, respectively, and observation data is organized using gateway identifiers and time sequence identifiers. The infrastructure probe collects readable counts of CPU utilization and memory usage, using permissions and interfaces consistent with the operating environment to read the metrics. After sampling, it writes the data to a record line containing the gateway identifier and sampling time sequence. Short-term spikes are then smoothed using a sliding window and extreme value suppression to generate stable readings of CPU utilization and memory usage. These readings are not subject to numerical threshold judgments; only consistency in source, standardization, and timeline are ensured, providing reliable input for subsequent judgments.

[0140] The network quality probe initiates round-trip probes to detect network latency and packet loss rate. It constructs packets using the same transmission path as the production link, records the sending and receiving timestamps, counts the number of returned packets, and calculates the round-trip time distribution and return ratio to generate observational data on network latency and packet loss rate. If the probe fails to receive a return packet within the specified timeframe, the current observation point is marked as having timed out, and a network anomaly marker is generated in the observation row of that gateway. The network quality probe and the infrastructure probe run in parallel, and both are stored in the database on the same timeline to facilitate subsequent cross-metric correlation analysis.

[0141] The business probe replicates the actual request pattern at the application layer, accessing external service interfaces with minimal load, recording response status codes and response times, and retaining necessary request context such as interface identifiers and route entry identifiers for backtracking. If the response status code is in the unsuccessful range, the current observation point is marked as a business anomaly. The anomaly mark, response time, and response status code are all stored in the database, forming complete evidence of application layer availability. The business probe and network quality probe share the target addressing strategy and connection multiplexing strategy to ensure consistency between business layer availability determination and network layer observation criteria.

[0142] After the three types of probes complete one data collection, the health monitoring module aggregates the observation data at the gateway granularity. The aggregation logic prioritizes timeline alignment, merging CPU utilization and memory usage into an infrastructure observation pair, network latency and packet loss rate into a network quality observation pair, and response status code and response time into a service observation pair. Network anomalies and service anomalies are also merged into the same record row. The aggregation results are written into the health status data structure, which includes fields for CPU utilization, memory usage, network latency, packet loss rate, response status code, response time, and anomaly flags. The primary gateway and backup gateway each form an independent record set, with each set corresponding one-to-one with the identifier of the source gateway. To ensure the determinism of subsequent processing, the health status data undergoes field integrity and type validation before being written. Missing items are recorded as unavailable placeholders and output along with the anomaly flag, without being filled by interpolation, thus avoiding errors affecting subsequent judgments.

[0143] In scenarios where network quality probes time out, network anomaly tags are applied only to the gateway where the timeout occurred, leaving the other gateway unaffected, thus avoiding misleading cross-gateway comparisons. Similarly, in scenarios where service probes return unsuccessful status codes, service anomaly tags are applied only to the gateway experiencing the anomaly. Both types of anomaly tags can coexist or exist independently. Health status data is recorded factually and maintains open fields, allowing subsequent modules to implement different judgment strategies based on single or combined tags. The final output health status data includes both continuous metrics and discrete tags, featuring a traceable timeline, a comparable dual-gateway parallel structure, and an extensible field set. This provides direct input for subsequent anomaly detection, collection, and switching decisions without requiring further data cleaning.

[0144] This embodiment collects and aggregates data in parallel—including CPU utilization and memory usage, network latency and packet loss rate, and response status codes and response times—on a single timeline. The health detection module outputs structured health status data to both the primary and backup gateways. Network quality probe response timeouts trigger network anomaly flags, and service probes returning unsuccessful status codes trigger service anomaly flags. These two types of flags, along with metrics, are output together, forming a multi-dimensional profile of the resource, network, and application layers. This output directly eliminates the risk of misjudgment caused by a single indicator, reduces the secondary cleansing cost in subsequent judgment stages, and provides stable and consistent input to the anomaly detection collection submodule and the handover decision submodule. This shortens the fault identification and processing link and improves the quality and timeliness of judgments before automatic handover.

[0145] In one embodiment, step S30 above includes:

[0146] S301, the health status data is received through the anomaly detection and collection submodule of the routing switching module, and the infrastructure indicators, network quality indicators and service indicators in the health status data are analyzed through the anomaly detection and collection submodule.

[0147] S302, integrate the infrastructure indicators, network quality indicators and service indicators to generate health status information with anomaly markers;

[0148] S303, the switching decision submodule of the routing switching module loads preset switching conditions including infrastructure threshold, network quality threshold and service threshold, as well as preset switching modes including observation mode or immediate switching mode.

[0149] S304, the handover decision submodule compares the health status information of the gateway to be handed over with the infrastructure threshold, network quality threshold and service threshold;

[0150] S305, when the health status information marked with an abnormality meets the observation mode conditions, a delayed switching instruction is generated through the switching decision submodule;

[0151] S306, When the health status information marked with an abnormality meets the conditions for immediate switching mode, an immediate switching instruction is generated through the switching decision submodule.

[0152] In this embodiment, the anomaly detection and collection submodule establishes a one-way receiving channel and a temporary buffer for health status data. It bins the data according to the timeline and gateway identifier, ensuring that infrastructure metrics, network quality metrics, and service metrics within the same time series are aligned in the same record. After reception, the parsing unit reads the fields and performs semantic classification. CPU utilization and memory usage are classified as infrastructure metrics, network latency and packet loss rate as network quality metrics, and response status codes and response times as service metrics. The parsing process does not change the original value caliber; it only establishes stable field names and unified source labels for subsequent integration and comparison. Simultaneously, the source gateway and collection time series are appended to the record header to form a traceable key.

[0153] After parsing, the anomaly detection and collection submodule integrates the three types of indicators. The integration unit merges infrastructure indicators, network quality indicators, and service indicators from the same gateway using the timeline as the primary key, and reads the anomaly tags generated in the original data, merging network anomaly tags and service anomaly tags into the same record. If any type of indicator is missing, the integration unit retains an empty placeholder and records the missing reason label, without filling it in by inference, thus ensuring that subsequent judgments are based on the actual collected status. The integration result is written into the health status information data structure, which includes infrastructure indicator groups, network quality indicator groups, service indicator groups, and anomaly tag groups, stored with tags for downstream filtering or combination references by tags. The health status information maintains a one-to-one correspondence with the health status data in terms of timeline and gateway dimensions, and performs integrity and field type checks during writing; records that fail the checks are marked as unusable and isolated.

[0154] Before reading health status information, the handover decision submodule loads preset handover conditions and preset handover modes. The preset handover conditions include three sets of boundaries: infrastructure thresholds, network quality thresholds, and service thresholds, corresponding to the judgment criteria for resource consumption, link quality, and service availability, respectively. The preset handover modes include two decision paths: observation mode and immediate handover mode. During the loading process, the threshold groups and mode configurations are fixed as read-only snapshots, with version numbers and effective timestamps appended, facilitating the establishment of a source association with subsequently generated handover commands.

[0155] After obtaining health status information, the switching decision submodule first identifies the gateway to be switched based on the source gateway. Then, it compares the health status information with anomaly markers against infrastructure thresholds, network quality thresholds, and service thresholds item by item. The comparison order follows a bottom-up path from the resource layer, network layer, and service layer. Any conclusion triggered at any layer that does not meet the conditions is recorded as a trigger point and enters the mode determination process. If the preset switching mode is observation mode, the switching decision submodule generates a delayed switching instruction based on the continuity and cross-layer consistency of the anomaly markers. The delayed switching instruction clearly specifies the gateway to be switched, the trigger point label, and the effective conditions, and carries the threshold snapshot version. If the preset switching mode is immediate switching mode, the switching decision submodule generates an immediate switching instruction when it finds that the comparison result with the threshold group meets the trigger conditions and the anomaly marker is valid. The immediate switching instruction also binds the gateway to be switched, the trigger point label, and the threshold snapshot version. Both types of switching instructions are output as structured payloads, directly usable by the request-oriented routing submodule, without needing to explain the meaning of the fields again.

[0156] To improve stability, an idempotent reading strategy and a deduplication sequence number mechanism are used between the anomaly detection and collection submodule and the switching decision submodule to prevent duplicate records on the same timeline from causing multiple triggers. Health status information is tagged with a data freshness label before entering the switching decision submodule to remove expired information and prevent historical anomalies from affecting the current judgment. When outputting the switching command, the switching decision submodule simultaneously records a summary of the input information and the threshold group version, forming a complete chain of decision evidence for easy subsequent traceability and auditing.

[0157] This embodiment utilizes an anomaly detection and collection submodule to uniformly analyze and integrate infrastructure metrics, network quality metrics, and service metrics. Health status information carries both numerical metrics and anomaly markers in a single record, reducing ambiguity caused by fragmented dimensions. The handover decision submodule, after loading preset handover conditions and modes, compares the anomaly-marked health status information with infrastructure thresholds, network quality thresholds, and service thresholds item by item. It can generate delayed handover commands in observation mode and immediate handover commands in immediate handover mode, thus supporting different decision paths with the same data caliber. This process shortens the link from data collection to decision-making, reduces the probability of false triggers caused by single-dimensional judgments, and improves traceability and stability by binding commands to threshold snapshots, providing clear, direct, and reliable input for subsequent routing updates.

[0158] In one embodiment, step S40 above includes:

[0159] S401, the target gateway address is obtained by parsing the switching instruction through the request routing submodule of the routing switching module;

[0160] S402, the routing relationship of the routing control component is modified by the request routing submodule to point the request forwarding target to the target gateway address;

[0161] S403, the routing control component is reloaded through the request routing submodule to make the routing relationship update effective;

[0162] S404, A probe request is sent to the target gateway address through the request routing submodule;

[0163] S405, When the request routing submodule receives a successful response to the probe request, the routing switch is marked as complete;

[0164] S406, The currently effective target gateway address is stored through the request routing submodule.

[0165] In this embodiment, the request routing submodule first establishes a read-only parsing channel for the switching command, extracting metadata such as the target gateway address, command signature, validity period, threshold version, and trigger reason by field. To avoid ambiguity, the parsing process performs format validation on the target gateway address, hostname-to-address parsing validation, and address reachability pre-check, and performs an integrity verification between the parsing result and the command signature; if the signature or validity period mismatches, the parsing is rejected and does not proceed to the subsequent update link. After parsing, a one-time context is generated, containing the target gateway address and a decision evidence digest. Subsequent operations all reference this context to prevent data tampering in the link.

[0166] The request routing submodule then enters the routing relationship update phase. This phase constructs two parallel structures according to transaction semantics: one set represents the routing relationships to be implemented, pointing to the target gateway address; the other is a snapshot of the currently effective routing relationships, used for failure rollback. Update granularity covers key items such as upstream pool entries, forwarding targets, weight fields, and health probe entry points. Any fields related to the forwarding path are modified within the same transaction to ensure atomicity. The update operation is completed in the in-memory configuration area and undergoes consistency checks, including the existence of target entries, the integrity of reverse proxy links, and circular pointer detection. After successful checks, the data is written to a controlled configuration buffer, awaiting activation.

[0167] To ensure immediate and effective routing updates, the routing submodule requests a non-disruptive reload of the routing control component. The reload is performed on a separate control channel, employing a graceful switching strategy. Existing connections terminate naturally according to their original effective relationships, while new connections are established according to the routing relationships to be implemented. The reload result carries a return code and an effectiveness summary. The module evaluates the return code and compares it with the summary content. If inconsistencies or abnormal returns are found, a rollback is triggered, the buffer is restored to its original snapshot, the entire update link is marked as failed, and further execution ceases.

[0168] After confirming the routing control component report is effective, the request routing submodule initiates a probe request to the target gateway address. The probe request reuses a unified probe stack, comprising two sequences: link-layer reachability probe and service ingress availability probe. These are executed sequentially, terminating the sequence upon link-layer failure. Service ingress probe uses the same protocol and path as the operational traffic, constructing a verification request with minimal load, employing independent probe credentials, and isolating the cache. The entire probe request and response timeline is recorded, and the recorded values ​​are written to a temporary metric to serve as evidence of effectiveness along with the reload results.

[0169] When the request routing submodule receives a successful response to the probe request, the module generates a route switching completion flag locally. This flag includes the switching instruction identifier, the target gateway address, the effective summary returned by the routing control component, key points of the probe response, and the generation time. It is then written to the state storage and made public to upstream records and alarm links. If the probe fails to meet the requirements or is not completed within the specified time window, the module triggers a rollback process, restoring the routing relationship to a snapshot version and recording the reason for failure and checkpoints requiring review for operation and maintenance and upstream decision-making units to review.

[0170] To ensure that subsequent requests and operations can accurately identify the current forwarding target, the request routing submodule persists the currently effective target gateway address to the configuration state database and broadcasts it to subscribers. The persisted record maintains a one-to-one correspondence with the route switch completion marker, including a version number and timestamp. The broadcast uses an idempotent message body containing the currently effective address and the previous version address, allowing subscribers to update their local caches and ensure consistent path display. The entire chain forms a closed loop of "resolution → update → reload → probe → marker → persistence." Any anomalies at any stage are captured and triggered by rollback and logging, ensuring that the consistency between the routing control component and the state storage is not compromised.

[0171] This embodiment completes the switching command parsing, atomic update of routing relationships, uninterrupted reload, target gateway detection, completion mark and effective address persistence within the same link. The change of forwarding path is changed from offline configuration writing to online closed-loop control. Reload is only triggered after the consistency check passes, and the completion mark is generated and published externally only after the detection is successful, thereby reducing the risk of erroneous switching and "configuration has been changed but the path has not taken effect". Update and rollback have transaction attributes, and can be restored to the original snapshot in case of an anomaly. The dual verification of reload and detection improves the verifiability and audit traceability of the effect, and provides a stable and controllable target gateway selection basis for subsequent business requests.

[0172] In one embodiment, step S50 above includes:

[0173] S501, the routing control component receives the service request at the request entry address and parses the protocol type and target path of the service request;

[0174] S502, the routing control component reconstructs the request data according to the protocol type and the target gateway address to obtain the reconstructed request;

[0175] S503, the reconstructed request is sent to the target gateway through the routing control component;

[0176] S504, Receive service response data returned by the target gateway through the routing control component;

[0177] S505, the service response data is returned to the requesting source through the routing control component.

[0178] In this embodiment, the routing control component establishes a listening channel at the request entry address. After the access layer completes the handshake and session initialization, it maps the business request to an internal request object. The parsing process performs layered processing on the protocol type and target path: the transport and security layers determine whether the channel is plaintext or encrypted, and perform certificate chain verification and hostname matching in the encrypted channel scenario; the application layer parses the method, path, query parameters, and header fields, extracting key metadata such as client address, user agent, and content type, while recording the entry timestamp and session identifier for subsequent link tracing and backtracking. The parsing phase also performs normalization and boundary checks on the target path, eliminating path crossings and illegal segments to ensure that subsequent forwarding does not introduce unauthorized resource access.

[0179] Based on the protocol type and target gateway address, the routing control component reconstructs the request data, generating a reconstructed request. The reconstruction process includes several deterministic operations: unifying the protocol scheme and setting the target gateway address and port; rewriting the host header and path prefix according to the gateway interface specification; retaining business-related headers and parameters; deleting headers strongly bound to the entry point or potentially exposing the internal topology; appending a link tracing header and entry timestamp; and setting placeholder metadata for forwarding timeout and retry policies. To mitigate side effects from cross-gateway inconsistencies, the body of the request only adjusts the block encoding and compression method to a minimum set while maintaining the byte sequence, ensuring the target gateway obtains semantics consistent with the entry point after decoding. After reconstruction, a read-only buffer is generated in memory to prevent downstream processes from making unintended modifications to the request content.

[0180] The routing control component uses a connection pool to establish or reuse upstream connections with the target gateway, sending the reconstructed requests to the target gateway. Before sending, concurrency gating and rate shaping are performed to prevent sudden pressure surges on the target gateway due to instantaneous switching. During transmission, half-close protection and heartbeat keep-alive are enabled to ensure stable long-term connections. The sending queue is dequeued according to a first-in, first-out principle, maintaining consistent order within the same session so that the target gateway processes requests in the expected order. If the underlying connection fails or the target gateway becomes temporarily unreachable, the routing control component selects a backup connection channel with the same target gateway address based on retry placeholder metadata for a limited number of retransmissions, and writes the timeline of each attempt into internal metrics for subsequent diagnostics.

[0181] After the target gateway returns the service response data, the routing control component performs verification and shaping on the backhaul link. First, it verifies the integrity of the status line and necessary headers. Then, it performs security cleanup and standardization of the response headers, including removing internal network segment information, masking implementation detail headers, merging duplicate header values, and limiting the total header size. Compression and chunking strategies are aligned with the ingress capabilities. If the ingress does not support a specific compression algorithm, transcoding is performed on the backhaul link to ensure the request source can directly parse it. To improve end-to-end observability, the routing control component appends link tracing information and the ingress session identifier to the response header and writes round-trip latency, upstream processing latency, and volume metrics into the metrics bucket.

[0182] The routing control component returns the processed service response data to the requesting source. The return action adheres to the protocol capabilities and session attributes negotiated at the ingress point, maintaining the connection reuse strategy and congestion control parameters unchanged to avoid introducing abrupt changes within the same session. If the requesting source actively closes the connection during the backhaul phase, the component discards the entity to be sent according to idempotent semantics and records the reason for the interruption; if a recoverable error occurs during backhaul transmission, the component performs a single-buffered retransmission without compromising the idempotency of the response. Thus, the ingress reception, parsing, reconstruction, sending, receiving, and return form a closed loop. The target gateway address, the reconstructed request, and the service response data maintain a one-to-one correspondence throughout the entire link, and all key nodes are recorded in traces and metrics to support subsequent operation, maintenance, and auditing.

[0183] This embodiment completes entry point parsing, request reconstruction, upstream transmission, backhaul shaping, and response return within the same data plane, forming an end-to-end controllable forwarding path from the request entry address to the target gateway. The parsing and normalization of protocol type and target path reduce the probability of failure caused by semantic inconsistencies between the entry point and the target. The reconstructed request maintains the business semantics with minimal changes, and the load on the target gateway is smoothed through connection pooling, concurrency gates, and rate limiting mechanisms. The business response data is standardized and observable in the backhaul link, enabling the request source to obtain stable and consistent response performance and providing a complete chain of evidence for subsequent location, thereby reducing anomalies caused by differences in the forwarding link and improving forwarding success rate and auditability.

[0184] In one embodiment, step S70 above includes:

[0185] S701, the health monitoring module monitors the recovery indicator data of the main gateway, including infrastructure indicators and business indicators;

[0186] S702, load preset recovery conditions by switching decision submodules;

[0187] S703, when the recovery index data meets the preset recovery conditions, a switchback command is generated by the switching decision submodule;

[0188] S704, the main gateway address is obtained by parsing the back-switch instruction through the request routing submodule;

[0189] S705, by requesting the routing submodule to modify the routing relationship of the routing control component to point to the main gateway address;

[0190] S706, The routing control component is reloaded by requesting the routing submodule to make the routing relationship update effective;

[0191] S707, a probe request is sent to the main gateway address via the request routing submodule;

[0192] S708, when the request routing submodule receives a successful response, the switchback is marked as complete.

[0193] In this embodiment, the health detection module employs a multi-dimensional data collection and cross-validation process to determine the recovery of the main gateway. First, a time window for recovery indicator data is established. Within this window, raw samples of infrastructure and business indicators are written at fixed intervals. Infrastructure indicators are derived from resource probes and process probes, while business indicators are derived from simulated business calls and response parsing. To reduce the interference of momentary fluctuations on the judgment, sampling denoising and abnormal sample removal are performed before writing to the window, eliminating obviously distorted and incomplete samples. Subsequently, the samples within the window are aggregated by dimension into recovery indicator data, forming a comparable structured set, accompanied by a timestamp and source marker, which serves as the sole input for subsequent judgments.

[0194] After the switch decision submodule loads the preset recovery conditions, it performs a step-by-step comparison using recovery indicator data as input. The preset recovery conditions consist of an infrastructure threshold group and a business threshold group, and also include constraints such as the minimum number of observations and the observation time span to avoid erroneous switchbacks caused by instantaneous recovery. The submodule first checks whether the indicators covered by the infrastructure threshold group are continuously met within the window, then checks whether the response status codes and response times covered by the business threshold group are continuously met within the same window, and finally checks whether the window span meets the time constraints of the preset recovery conditions. A switchback instruction is generated when all conditions are met; if any condition is not met, the current state is retained and the next round of observation begins. To prevent concurrent state conflicts, the submodule writes a one-time flag when generating the switchback instruction for deduplication processing in the downstream execution link.

[0195] After receiving the switchback command, the request routing submodule completes a two-stage routing adjustment. The first stage parses the switchback command, extracting the primary gateway address, port, protocol type, and execution mode flag, and verifies the command timing and one-time flag; commands that fail verification are discarded. The second stage performs an ordered update on the routing control component, first writing the new routing relationships, marking the primary gateway as the entry target, and then triggering the reload process of the routing control component, ensuring the new routing relationships take effect without interrupting existing connections. To reduce connection jitter during the switchover, the request routing submodule enables a short-term diversion strategy after reload, limiting the concurrent growth rate of connections entering the target gateway and naturally reclaiming old target connections to avoid instantaneous congestion caused by a large number of concurrent migrations.

[0196] The request routing submodule performs service availability verification immediately upon activation. The submodule constructs a probe request using the same protocol, header fields, and key business parameters as production, and sends it directly to the main gateway address via the routing control component, awaiting a business response. To eliminate the impact of occasional probe failures, the probe employs a limited number of retries and interval control. All probe requests are marked at the routing control component level as not participating in statistical billing and rate limiting to avoid impacting normal business operations. If any probe returns a successful response, the submodule records the availability status of the main gateway and writes the current target identifier to persistent storage. If no successful response is obtained within the limited number of attempts, a rollback path is triggered, restoring the routing relationship to the target before the rollback, and a failed rollback event is recorded, awaiting the next round of recovery determination.

[0197] To manage concurrency and race conditions during the rollback process, a single-writer semantic and idempotent execution constraint are adopted between the switchover decision submodule and the request routing submodule. The single-writer semantic is implemented using mutex tokens or sequence numbers to ensure that only one rollback instruction enters the effective path at any given time. Idempotent execution is achieved through one-time identification and target snapshots; duplicate rollback instructions are identified and ignored during the parsing phase, and effective rollbacks are not reapplied. This mechanism works in conjunction with the logging and alerting modules, ensuring that any routing relationship change, successful probe, or rollback operation is written to the event log in real time, facilitating tracking and observability.

[0198] Example Description: In the clinical information system of a large, comprehensive medical institution, there is a need for real-time data exchange between an electronic medical record (EMR) platform and multiple third-party laboratory testing platforms, imaging diagnostic systems, drug prescription review systems, and other external medical service systems. The institution's core business gateway is responsible for the unified routing and security control of all medical data exchanges, ensuring that doctors' prescriptions, test requests, and image report retrieval operations can be completed within seconds to support real-time decision-making in scenarios such as emergency rooms and intensive care units (ICUs). Due to the extremely high requirements for timeliness and accuracy in the medical field, any anomaly at the gateway end will directly affect the continuity and safety of patient care.

[0199] During the deployment phase, operations and maintenance personnel first configure the routing control component to associate it with both the primary and backup gateways, and set a unique request entry address for the clinical information system. For example, the primary gateway is associated with a high-performance node in data center A, and the backup gateway is associated with a geographically redundant node in data center B. After configuration, various medical service requests are received through the listening address, and test requests are sent to verify the network connectivity of the primary and backup gateways. Only when both verifications pass is the routing configuration activated and the routing relationship made effective; otherwise, the logging and alarm module is immediately triggered to record the configuration anomaly and notify the on-duty engineer.

[0200] During the operation of medical institutions, the health monitoring module continuously monitors the main gateway and backup gateway in real time. Infrastructure probes collect server CPU usage and memory usage to prevent delays in medical data processing due to resource exhaustion; network quality probes monitor latency and packet loss between the two server rooms to prevent lag in the transmission of large files such as electrocardiograms and images; business probes simulate real business requests such as submitting test requests and retrieving image reports, monitoring response status codes and response times. Once a network probe timeout or abnormal business response is detected on the main gateway, health status data with detailed indicators is immediately generated.

[0201] The anomaly detection and collection submodule of the routing switching module receives this health status data and parses it to extract indicators of infrastructure, network quality, and service layers. It then combines these with anomaly markers to generate health status information. The switching decision submodule loads pre-defined medical service switching conditions, such as allowing short-term network fluctuations but not allowing more than 3 consecutive seconds of image report acquisition failures. When the health status information meets the conditions of the observation mode, a delayed switching command is generated to continue observation; if immediate switching mode conditions occur (e.g., interruption of real-time transmission of ICU bedside monitoring data), an immediate switching command is generated to ensure uninterrupted data link transmission.

[0202] Upon receiving the switchover command, the request routing submodule resolves the target gateway address and forwards the request from the routing control component to the backup gateway. Simultaneously, it performs a hot reload to immediately activate the routing relationship. The module sends a probe request to the backup gateway, such as simulating a retrieval of a patient's complete test report data. Only after confirming the backup gateway's service availability does it mark the switchover as complete and record the currently active gateway address. This ensures that doctors' operational requests still receive a response within seconds and are not interrupted due to a primary gateway failure.

[0203] When a healthcare institution's business request enters the routing control component through the entry address, the component parses the request's protocol type (such as HL7, FHIR over HTTP, HTTPS) and target path, and reconstructs the request data based on the target gateway address, for example, by adding necessary authentication parameters for image retrieval requests. The reconstructed request is sent to the target gateway, which interacts with the external system and returns business response data, which is then forwarded by the routing control component to the clinical information system caller, ensuring that the interface on the doctor's or nurse's end is updated in real time.

[0204] During any routing switch, the log and alarm module records the time of the switch, the reason (such as CPU overload, network latency exceeding the threshold), the gateway address before and after the switch, and the detected abnormal information. These records are then sent to maintenance personnel via the medical institution's IT operations and maintenance alarm platform and on-duty mobile phone SMS to ensure that problems are traceable and can be responded to quickly.

[0205] When the health monitoring module detects that the main gateway has recovered (e.g., CPU and memory usage return to normal, network latency decreases, and image retrieval response success rate recovers), the switchover decision submodule generates a switchback command based on preset recovery conditions. The request routing submodule parses the switchback command and points the routing relationship back to the main gateway. After reloading the routing control component, it performs a probe verification. If the verification is successful, the switchback is marked as complete, thereby redirecting the data flow back to the main gateway node to leverage its higher performance processing capabilities.

[0206] In the OTP (One-Time Password) SMS authentication system of a national bank, the core gateway needs to interact with the transaction processing platforms of the head office and multiple branches in real time. OTP SMS is used for high-risk operations such as payment instruction confirmation, fund transfer authorization, and verification of changes to sensitive information. Sending latency directly affects whether transactions can be completed within regulatory time limits, and is also related to customer fund security and user experience. Therefore, the bank has built a primary and backup gateway architecture to ensure the stable transmission of OTP SMS data.

[0207] During system initialization, operations and maintenance personnel configure the routing control component, associating the primary gateway with a high-performance node in the bank's headquarters data center and the backup gateway with a redundant node in the disaster recovery center data center. A unified request entry address is set as the sole access point for the transaction system to call the OTP SMS gateway. After configuration, the system verifies the communication quality between the routing control component and the primary and backup gateways by sending network connectivity test requests. Once both are confirmed to be available, the routing configuration is activated, and the routing relationship officially takes effect. If any party is detected to be unavailable, the log and alarm module immediately records the configuration anomaly and notifies the network security operations and maintenance team.

[0208] During operation, the health monitoring module continuously monitors the primary and backup gateways across multiple dimensions, including infrastructure, network quality, and service layers. Infrastructure probes collect real-time data on server CPU and memory usage to prevent response delays due to resource exhaustion during high-concurrency OTP generation and verification. Network quality probes measure latency and packet loss in the data center links between the two locations to prevent OTP SMS data loss or delay during transmission. Service probes simulate real OTP SMS delivery requests, monitoring response status codes and response times to ensure the health of the call link from the transaction platform to the gateway. If a network probe times out or a service probe response is abnormal, the health monitoring module generates health status data with detailed metrics.

[0209] The anomaly detection and collection submodule of the routing switching module receives this health status data and parses it to extract infrastructure, network quality, and service metrics, generating health status information based on anomaly markers. The switching decision submodule loads preset switching conditions for financial transactions; for example, two or more consecutive OTP generation request timeouts or SMS delivery interface response failures are considered immediate switching conditions. If the observation mode condition is triggered, a delayed switching instruction is generated to continue monitoring; if the immediate switching condition is triggered, an immediate switching instruction is generated.

[0210] When the immediate switchover command is issued to the request routing submodule, this module resolves the target gateway address, switches the request forwarding target of the routing control component to the backup gateway, and performs a hot reload operation to ensure that the new routing relationship takes effect immediately. Subsequently, it sends a transaction simulation probe request to the backup gateway, such as generating and sending an OTP SMS message with signature verification. After confirming that transaction-related business processes are available, it marks the routing switchover as complete and records the currently effective target gateway address for subsequent monitoring and backtracking.

[0211] During transaction processing, all OTP SMS requests from the core transaction system enter the routing control component through the request entry address. The component parses the protocol type (usually HTTPS) and the target path, and reconstructs the request data based on the target gateway address. This includes adding security fields such as digital signatures, timestamps, and anti-replay random numbers to ensure data integrity and compliance. The reconstructed request is then sent to the target gateway, which connects the SMS channel gateway to the operator platform to complete the delivery. The returned business response data is then transmitted back to the transaction platform so that the OTP SMS status can be instantly reflected in the user interface or the backend risk control system.

[0212] Any routing switch or anomaly detection result will be recorded by the log and alarm module, including the switch time, triggering reason, gateway address before and after the switch, and abnormal indicators. The system will promptly notify the operations and security departments through the bank's internal alarm platform, encrypted email, or secure SMS channels to ensure that the problem is traceable and can be handled quickly.

[0213] When the health monitoring module detects that the main gateway has resumed operation, and infrastructure indicators such as CPU usage, memory usage, and network latency, as well as business indicators such as OTP SMS service success rate, have all returned to normal, the switchover decision submodule will generate a switchback instruction based on preset recovery conditions. The request routing submodule parses this switchback instruction and points the routing relationship to the main gateway address, performs reloading to make the routing relationship effective, and then verifies it by simulating an OTP SMS request transaction. After successful verification, the switchback is marked as complete, and traffic is switched back to the main gateway node with better performance, thereby restoring the optimal business processing path.

[0214] This embodiment uses a health monitoring module to collect recovery indicator data from both infrastructure and business levels in a time window manner. The switching decision submodule then performs continuous, concurrent, and multi-dimensional comparisons under preset recovery conditions, significantly reducing the probability of erroneous switchbacks. The request routing submodule employs ordered updates and reload activation during switchback execution, along with short-term traffic redirection and natural recycling, suppressing connection jitter and concurrency congestion during the switchover. After the probe request takes effect, it undergoes business-level verification and provides failure rollback paths and idempotent constraints, making the switchback behavior controllable, traceable, and recoverable. Overall, this shortens the unavailability period during the recovery process, reduces the risk of business interruption, and stabilizes the user experience.

[0215] In one embodiment, an automatic switching device for gateway applications is provided, which corresponds one-to-one with the automatic switching method for gateway applications described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the automatic switching device for gateway applications of the present invention. The modules include a routing control component module 10, a health detection module 20, an anomaly detection and collection module 30, a request routing module 40, a service request processing module 50, a log and alarm module 60, and a switching decision module 70. Detailed descriptions of each functional module are as follows:

[0216] The routing control component module 10 is used to configure the routing control component to associate with the primary gateway and the backup gateway, and to set the request entry address;

[0217] Health detection module 20 is used to perform health detection on the main gateway and the backup gateway and generate health status data.

[0218] The anomaly detection and collection module 30 is used to receive the health status data through the anomaly detection and collection submodule of the routing switching module, generate health status information, and generate a switching instruction based on the health status information through the switching decision submodule of the routing switching module.

[0219] The request routing module 40 is used to update the routing relationship in the routing control component and determine the target gateway according to the switching instruction through the request routing submodule of the routing switching module;

[0220] The service request processing module 50 is used to forward service requests to the target gateway through the request entry address;

[0221] The logging and alarm module 60 is used to record routing switching information and abnormal information and send alarm notifications.

[0222] The switching decision module 70 is used to generate a switchback instruction through the switching decision submodule when the health detection module detects that the main gateway has recovered, and to update the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

[0223] In one embodiment, the routing control component module 10 is specifically used for:

[0224] Create a route control component instance;

[0225] Add the first access address of the main gateway to the routing control component instance;

[0226] Add the second access address of the backup gateway to the routing control component instance;

[0227] Set the listening address of the routing control component instance as the request entry address;

[0228] Send a test request to verify the network connectivity between the routing control component instance and the first access address and the second access address;

[0229] When network connectivity verification passes, the routing configuration of the routing control component instance is activated, making the routing relationships in the routing control component instance effective.

[0230] When network connectivity verification fails, the logging and alarm module is triggered to record the configuration error.

[0231] In one embodiment, the health detection module 20 is specifically used for:

[0232] The health monitoring module sends infrastructure probes to monitor the CPU usage and memory consumption of the primary and backup gateways;

[0233] The network quality probe is sent via the health detection module to monitor the network latency and packet loss rate of the main gateway and the backup gateway;

[0234] The health detection module sends a service probe to simulate a request to monitor the response status code and response time of the primary gateway and backup gateway;

[0235] When the network quality probe response times out, mark the primary gateway and / or backup gateway as having network anomalies.

[0236] When the service probe returns a non-success status code, mark the primary gateway and / or backup gateway as having a service abnormality.

[0237] Generate health status data including the CPU utilization, memory usage, network latency, packet loss rate, response status code, response time, and anomaly markers of the primary gateway and backup gateway.

[0238] In one embodiment, the anomaly detection and collection module 30 is specifically used for:

[0239] The health status data is received by the anomaly detection and collection submodule of the routing switching module, and the infrastructure indicators, network quality indicators and service indicators in the health status data are analyzed by the anomaly detection and collection submodule.

[0240] Integrate the aforementioned infrastructure metrics, network quality metrics, and service metrics to generate health status information with anomaly markers;

[0241] The switching decision submodule of the routing switching module loads preset switching conditions, including infrastructure thresholds, network quality thresholds, and service thresholds, as well as preset switching modes, including observation mode or immediate switching mode.

[0242] The handover decision submodule compares the health status information of the gateway to be handed over with the infrastructure threshold, network quality threshold, and service threshold.

[0243] When the health status information marked with an anomaly meets the observation mode conditions, a delayed switching instruction is generated through the switching decision submodule.

[0244] When the health status information marked with an anomaly meets the conditions for immediate switching mode, an immediate switching instruction is generated through the switching decision submodule.

[0245] In one embodiment, the request routing module 40 is specifically used for:

[0246] The target gateway address is obtained by parsing the switching instruction through the request routing submodule of the routing switching module;

[0247] The request routing submodule modifies the routing relationship of the routing control component, directing the request forwarding target to the target gateway address;

[0248] The routing control component is reloaded by the request routing submodule to make the routing relationship update effective;

[0249] The request routing submodule sends a probe request to the target gateway address;

[0250] When the request routing submodule receives a successful response to the probe request, the route switching is marked as complete.

[0251] The request routing submodule stores the currently active target gateway address.

[0252] In one embodiment, the service request processing module 50 is specifically used for:

[0253] The routing control component receives the service request at the request entry address and parses the protocol type and target path of the service request.

[0254] The routing control component reconstructs the request data according to the protocol type and the target gateway address to obtain the reconstructed request;

[0255] The reconstructed request is sent to the target gateway via the routing control component;

[0256] The routing control component receives the service response data returned by the target gateway.

[0257] The routing control component returns the service response data to the requesting source.

[0258] In one embodiment, the switching decision module 70 is specifically used for:

[0259] The health monitoring module monitors the recovery indicator data of the main gateway, including infrastructure indicators and business indicators.

[0260] Load preset recovery conditions by switching decision submodules;

[0261] When the recovery indicator data meets the preset recovery conditions, a switchback command is generated by the switching decision submodule;

[0262] The main gateway address is obtained by parsing the back-switch instruction through the request routing submodule;

[0263] The routing submodule is requested to modify the routing relationship of the routing control component to point to the main gateway address;

[0264] The routing control component is reloaded by requesting the routing submodule to make the routing relationship update effective;

[0265] The request routing submodule sends a probe request to the main gateway address;

[0266] When the request routing submodule receives a successful response, the switchback is marked as complete.

[0267] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external user terminals via a network connection. When executed by the processor, the computer program implements server-side functions or steps of an automatic switching method for gateway applications.

[0268] In one embodiment, a computer device is provided, which may be a user terminal, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements user-side functions or steps of an automatic switching method for gateway applications.

[0269] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0270] Configure the routing control component to associate with the primary gateway and the backup gateway, and set the request entry address;

[0271] The health detection module performs health checks on the main gateway and the backup gateway to generate health status data.

[0272] The health status data is received by the anomaly detection and collection submodule of the routing switching module, health status information is generated, and a switching instruction is generated by the switching decision submodule of the routing switching module based on the health status information.

[0273] The request routing submodule of the routing switching module updates the routing relationships in the routing control component and determines the target gateway according to the switching instruction;

[0274] The service request is forwarded to the target gateway through the request entry address;

[0275] The system records routing switching information and abnormal information and sends alarm notifications through the log and alarm module.

[0276] When the health detection module detects that the main gateway has recovered, it generates a switchback instruction through the switchover decision submodule and updates the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

[0277] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0278] Configure the routing control component to associate with the primary gateway and the backup gateway, and set the request entry address;

[0279] The health detection module performs health checks on the main gateway and the backup gateway to generate health status data.

[0280] The health status data is received by the anomaly detection and collection submodule of the routing switching module, health status information is generated, and a switching instruction is generated by the switching decision submodule of the routing switching module based on the health status information.

[0281] The request routing submodule of the routing switching module updates the routing relationships in the routing control component and determines the target gateway according to the switching instruction;

[0282] The service request is forwarded to the target gateway through the request entry address;

[0283] The system records routing switching information and abnormal information and sends alarm notifications through the log and alarm module.

[0284] When the health detection module detects that the main gateway has recovered, it generates a switchback instruction through the switchover decision submodule and updates the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

[0285] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0286] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0287] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0288] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. An automatic switching method for gateway applications, characterized in that, Includes the following steps: Configure the routing control component to associate with the primary gateway and the backup gateway, and set the request entry address; The health detection module performs health checks on the main gateway and the backup gateway to generate health status data. The health status data is received by the anomaly detection and collection submodule of the routing switching module, health status information is generated, and a switching instruction is generated by the switching decision submodule of the routing switching module based on the health status information. The request routing submodule of the routing switching module updates the routing relationships in the routing control component and determines the target gateway according to the switching instruction; The service request is forwarded to the target gateway through the request entry address; The system records routing switching information and abnormal information and sends alarm notifications through the log and alarm module. When the health detection module detects that the main gateway has recovered, it generates a switchback instruction through the switchover decision submodule and updates the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

2. The automatic switching method for gateway applications as described in claim 1, characterized in that, Configure the routing control component to associate with the primary and backup gateways, and set the request entry address, including: Create a route control component instance; Add the first access address of the main gateway to the routing control component instance; Add the second access address of the backup gateway to the routing control component instance; Set the listening address of the routing control component instance as the request entry address; Send a test request to verify the network connectivity between the routing control component instance and the first access address and the second access address; When network connectivity verification passes, the routing configuration of the routing control component instance is activated, making the routing relationships in the routing control component instance effective. When network connectivity verification fails, the logging and alarm module is triggered to record the configuration error.

3. The automatic switching method for gateway applications as described in claim 1, characterized in that, The health detection module performs health checks on the primary gateway and the backup gateway to generate health status data, including: The health monitoring module sends infrastructure probes to monitor the CPU usage and memory consumption of the primary and backup gateways; The network quality probe is sent via the health detection module to monitor the network latency and packet loss rate of the main gateway and the backup gateway; The health detection module sends a service probe to simulate a request to monitor the response status code and response time of the primary gateway and backup gateway; When the network quality probe response times out, mark the primary gateway and / or backup gateway as having network anomalies. When the service probe returns a non-success status code, mark the primary gateway and / or backup gateway as having a service abnormality. Generate health status data including the CPU utilization, memory usage, network latency, packet loss rate, response status code, response time, and anomaly markers of the primary gateway and backup gateway.

4. The automatic switching method for gateway applications as described in claim 1, characterized in that, The health status data is received by the anomaly detection and collection submodule of the routing switching module, health status information is generated, and a switching command is generated by the switching decision submodule of the routing switching module based on the health status information, including: The health status data is received by the anomaly detection and collection submodule of the routing switching module, and the infrastructure indicators, network quality indicators and service indicators in the health status data are analyzed by the anomaly detection and collection submodule. Integrate the aforementioned infrastructure metrics, network quality metrics, and service metrics to generate health status information with anomaly markers; The switching decision submodule of the routing switching module loads preset switching conditions, including infrastructure thresholds, network quality thresholds, and service thresholds, as well as preset switching modes, including observation mode or immediate switching mode. The handover decision submodule compares the health status information of the gateway to be handed over with the infrastructure threshold, network quality threshold, and service threshold. When the health status information marked with an anomaly meets the observation mode conditions, a delayed switching instruction is generated through the switching decision submodule. When the health status information marked with an anomaly meets the conditions for immediate switching mode, an immediate switching instruction is generated through the switching decision submodule.

5. The automatic switching method for gateway applications as described in claim 1, characterized in that, The request routing submodule of the routing switching module updates the routing relationships in the routing control component and determines the target gateway according to the switching instruction, including: The target gateway address is obtained by parsing the switching instruction through the request routing submodule of the routing switching module; The request routing submodule modifies the routing relationship of the routing control component, directing the request forwarding target to the target gateway address; The routing control component is reloaded by the request routing submodule to make the routing relationship update effective; The request routing submodule sends a probe request to the target gateway address; When the request routing submodule receives a successful response to the probe request, the route switching is marked as complete. The request routing submodule stores the currently active target gateway address.

6. The automatic switching method for gateway applications as described in claim 1, characterized in that, Forwarding the service request to the target gateway through the request entry address includes: The routing control component receives the service request at the request entry address and parses the protocol type and target path of the service request. The routing control component reconstructs the request data according to the protocol type and the target gateway address to obtain the reconstructed request; The reconstructed request is sent to the target gateway via the routing control component; The routing control component receives the service response data returned by the target gateway. The routing control component returns the service response data to the requesting source.

7. The automatic switching method for gateway applications as described in claim 1, characterized in that, When the health detection module detects that the main gateway has recovered, it generates a switchback instruction through the switchover decision submodule, and updates the routing relationships in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback, including: The health monitoring module monitors the recovery indicator data of the main gateway, including infrastructure indicators and business indicators. Load preset recovery conditions by switching decision submodules; When the recovery indicator data meets the preset recovery conditions, a switchback command is generated by the switching decision submodule; The main gateway address is obtained by parsing the back-switch instruction through the request routing submodule; The routing submodule is requested to modify the routing relationship of the routing control component to point to the main gateway address; The routing control component is reloaded by requesting the routing submodule to make the routing relationship update effective; The request routing submodule sends a probe request to the main gateway address; When the request routing submodule receives a successful response, the switchback is marked as complete.

8. An automatic switching device for gateway applications, characterized in that, The automatic switching device for gateway applications includes: The routing control component module is used to configure the routing control component to associate with the primary gateway and the backup gateway, and to set the request entry address; The health detection module is used to perform health detection on the main gateway and the backup gateway and generate health status data. The anomaly detection and collection module is used to receive the health status data through the anomaly detection and collection submodule of the routing switching module, generate health status information, and generate a switching instruction based on the health status information through the switching decision submodule of the routing switching module. The request routing module is used to update the routing relationships in the routing control component and determine the target gateway according to the switching instruction through the request routing submodule of the routing switching module; The business request processing module is used to forward business requests to the target gateway through the request entry address; The logging and alarm module is used to record routing switching information and abnormal information and send alarm notifications. The switching decision module is used to generate a switchback instruction through the switching decision submodule when the health detection module detects that the main gateway has recovered, and to update the routing relationship in the routing control component according to the switchback instruction through the request routing submodule to complete the switchback.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and an automatic switching program for gateway applications stored in the memory and executable on the processor, wherein the automatic switching program for gateway applications, when executed by the processor, implements the steps of the automatic switching method for gateway applications as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores an automatic switching program for gateway applications, which, when executed by a processor, implements the steps of the automatic switching method for gateway applications as described in any one of claims 1-7.

Images