Data splitting method and apparatus, device, storage medium, and program product

Abstract

Embodiments of the present application provide a data splitting method and apparatus, a device, a storage medium, and a program product. The method comprises: parsing a request message sent by a sending end to obtain a cluster diversion address and an inner layer protocol header; determining a gateway cluster corresponding to the cluster diversion address, and acquiring an address set corresponding to a plurality of gateway nodes in the gateway cluster; selecting from the address set a target address matching the inner layer protocol header, sending the request message to a target gateway node corresponding to the target address, so that the target gateway node adds to the request message a node diversion address corresponding to the target gateway node, and sends the request message to a receiving end; and receiving from the receiving end a reply message carrying the node diversion address; and sending the reply message to the target gateway node corresponding to the node diversion address, so that the target gateway node sends the reply message to the sending end.

Description

Data diversion method, device, equipment, storage medium and program product

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on November 16, 2023, with application number 202311533384.9 and application name “A data diversion method, device, equipment and storage medium”. Technical Field

[0002] The embodiments of the present application relate to the field of cloud technology, and in particular to a data diversion method, apparatus, device, storage medium, and program product.

[0003] Background of the Invention

[0004] Driven by the demands of data computing and high data availability, the volume of data requests has steadily increased. In traditional single-server architectures, a single server cannot handle all data requests, leading to performance degradation or system crashes. To address this, load balancing gateway systems and server clusters are commonly deployed in large data center networks. The load balancing gateway system distributes data requests to multiple servers within the server cluster, thereby improving data request processing efficiency.

[0005] To ensure data processing consistency, the load balancing gateway system must dispatch all packets belonging to the same connection to the same backend server for processing, achieving per connection constant (PCC). To this end, the load balancing gateway system must store a cache file identifier (cookie ID) and connection hash value for each connection. This results in excessive resource consumption, which in turn affects the stability and reliability of the load balancing gateway system.

[0006] In addition, the relevant technology can only guarantee the connection consistency of forward traffic (messages sent by the client to the server), while the reverse traffic (messages returned by the server to the client) no longer passes through the load balancing gateway system for diversion. This causes the load balancing gateway system to have deviations when counting network traffic, thereby affecting the accuracy of traffic speed limiting and causing network congestion.

[0007] Summary of the Invention

[0008] The embodiments of the present application provide a data diversion method, apparatus, device, storage medium and program product for scheduling both forward traffic and reverse traffic to the same target gateway node in a stateless manner, thereby ensuring the connection consistency of the forward traffic and reverse traffic of the same connection.

[0009] On the one hand, an embodiment of the present application provides a data offloading method, comprising:

[0010] Parse the request message sent by the sender to obtain the cluster diversion address and inner protocol header;

[0011] Determine the gateway cluster corresponding to the cluster diversion address, and obtain the address set corresponding to multiple gateway nodes in the gateway cluster;

[0012] Selecting a target address that matches the inner protocol header from the address set, and sending the request message to a target gateway node corresponding to the target address, so that the target gateway node adds a node diversion address corresponding to the target gateway node to the request message, and sends the request message to a receiving end;

[0013] receiving a reply message carrying the node diversion address from the receiving end; and

[0014] The reply message is sent to the target gateway node corresponding to the node diversion address, so that the target gateway node sends the reply message to the sending end.

[0015] On the other hand, an embodiment of the present application further provides a data offloading method, including:

[0016] Receive a request message sent by a splitter based on a target address corresponding to a target gateway node, wherein the splitter receives the request message from the sending end, parses the request message to obtain a cluster drainage address and an inner protocol header, determines the gateway cluster corresponding to the cluster drainage address, obtains an address set corresponding to multiple gateway nodes in the gateway cluster, and selects a target address that matches the inner protocol header from the address set;

[0017] After adding the node diversion address corresponding to the target gateway node to the request message, the request message is sent to the receiving end, wherein the splitter receives a reply message carrying the node diversion address from the receiving end;

[0018] receiving a reply message sent by the splitter based on the node diversion address; and

[0019] Send the reply message to the sending end.

[0020] On the other hand, an embodiment of the present application further provides a data splitting device, comprising:

[0021] The parsing module is used to parse the request message sent by the sender to obtain the cluster drainage address and inner protocol header;

[0022] A matching module is configured to determine the gateway cluster corresponding to the cluster drainage address and obtain an address set corresponding to multiple gateway nodes in the gateway cluster; select a target address that matches the inner protocol header from the address set, and send the request message to the target gateway node corresponding to the target address, so that the target gateway node adds the node drainage address corresponding to the target gateway node in the request message, and sends the request message to the receiving end;

[0023] A first receiving module is configured to receive a reply message carrying the node diversion address from the receiving end; and

[0024] The first sending module is configured to send the reply message to the target gateway node corresponding to the node diversion address, so that the target gateway node sends the reply message to the sending end.

[0025] On the other hand, an embodiment of the present application further provides a data splitting device, comprising:

[0026] A second receiving module is configured to receive a request message sent by a splitter based on a target address corresponding to a target gateway node, wherein the splitter receives the request message from the sending end, parses the request message, obtains a cluster drainage address and an inner protocol header, determines the gateway cluster corresponding to the cluster drainage address, obtains an address set corresponding to multiple gateway nodes in the gateway cluster, and selects a target address that matches the inner protocol header from the address set;

[0027] A processing module, configured to add a node diversion address corresponding to the target gateway node to the request message;

[0028] A second sending module is configured to send the request message to a receiving end, wherein the splitter receives a reply message carrying the node diversion address from the receiving end;

[0029] The second receiving module is further configured to receive a reply message sent by the splitter based on the node diversion address; and

[0030] The second sending module is further configured to send the reply message to the sending end.

[0031] On the other hand, an embodiment of the present application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned data diversion method when executing the program.

[0032] On the other hand, an embodiment of the present application further provides a computer-readable storage medium storing a computer program executable by a computer device. When the program runs on the computer device, the computer device executes the steps of the above-mentioned data diversion method.

[0033] On the other hand, an embodiment of the present application also provides a computer program product, which includes a computer program stored on a computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer device, the computer device executes the steps of the above-mentioned data diversion method.

[0034] BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments of the present application.

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0037] FIG1 is a schematic diagram of a system architecture provided in an embodiment of the present application;

[0038] FIG2 is a flow chart of a data offloading method provided in an embodiment of the present application;

[0039] FIG3 is a schematic flow diagram of a forward flow diversion method provided in an embodiment of the present application;

[0040] FIG4 is a schematic flow diagram of a reverse flow diversion method provided in an embodiment of the present application;

[0041] FIG5 is a flow chart of a data offloading method provided in an embodiment of the present application;

[0042] FIG6 is a flow chart of a data offloading method provided in an embodiment of the present application;

[0043] FIG7 is a flow chart of a data offloading method provided in an embodiment of the present application;

[0044] FIG8 is a schematic diagram of a priority backup group provided in an embodiment of the present application;

[0045] FIG9 is a schematic structural diagram of a data distribution device provided in an embodiment of the present application;

[0046] FIG10 is a schematic structural diagram of a data diversion device provided in an embodiment of the present application;

[0047] FIG11 is a schematic structural diagram of a computer device provided in an embodiment of the present application.

[0048] Implementation Method

[0049] In order to make the purpose, technical solutions and beneficial effects of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0050] For ease of understanding, the terms involved in the embodiments of the present invention are explained below.

[0051] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology based on the cloud computing business model. It can form a resource pool that can be used on demand with flexibility and convenience. The embodiments of this application use cloud technology to distribute data and achieve load balancing.

[0052] A private cloud is a cloud infrastructure with software and hardware resources built within a firewall, allowing departments within an organization or enterprise to share data center resources. In addition to hardware resources, creating a private cloud typically also requires cloud infrastructure (IaaS) and software. The data offload in the embodiments of this application is deployed within a private cloud.

[0053] VPC: Virtual Private Cloud. A dynamically configured pool of public cloud computing resources that uses encryption, tunneling, and other security procedures to transmit data between private enterprises and cloud service providers. A VPC transforms a cloud service provider's multi-tenant architecture into a single-tenant one.

[0054] VPCID: virtual private cloud identifier, is an identifier used to uniquely identify a virtual private cloud in cloud computing services.

[0055] P4: Programming Protocol Independent Packet Processors, a protocol-independent hardware programming language.

[0056] LB: Load Balance, which refers to distributing workload among multiple server nodes to improve system reliability and efficiency.

[0057] RS: Real server, in the load balancing application scenario, it is the server node located at the back end and to which the load is distributed.

[0058] PCC: Per Connection Constant, connection consistency, means that data packets in the same data flow are always scheduled to the same server node on the backend.

[0059] Stateful gateway: refers to a gateway that needs to record and maintain each network connection.

[0060] VPCGW Gateway: A Layer 4 load balancing gateway.

[0061] NAT: Network Address Translation.

[0062] FULL NAT: refers to the simultaneous conversion of the source IP address, destination IP address, source port (PORT) address, and destination port (PORT) address of the message. In load balancing applications, in NAT mode, after the splitter receives the request message sent by the client, it modifies the destination IP address of the request message to the IP address of the real server, and the destination port number of the request message to the port number of the real server. In FULL NAT mode, after the splitter receives the request message sent by the client, it modifies the source IP address of the request message to the splitter's intranet IP address, the source port number of the request message to the splitter's intranet port number, the destination IP address of the request message to the IP address of the real server, and the destination port number of the request message to the port number of the real server.

[0063] GRE: Generic Routing Encapsulation, is a network protocol used to encapsulate various network layer protocols in the network.

[0064] BGP: Border Gateway Protocol, a dynamic routing protocol used to exchange routing information between autonomous systems.

[0065] ECMP (Equal-Cost Multi-Path) is a network routing technology that allows packets to be load-balanced across multiple paths with the same cost (e.g., number of hops, bandwidth, latency, etc.). The main purpose of ECMP is to improve network availability, fault tolerance, and bandwidth utilization.

[0066] OSPF: Open Shortest Path First, is an open internal routing protocol used to transmit routing information within an autonomous system.

[0067] CPU: Central Processing Unit, central processing unit.

[0068] The following is an introduction to the design concept of the embodiments of the present application.

[0069] Currently, load balancing gateway systems are commonly deployed in large data center networks to achieve service distribution and horizontal expansion of cloud data center services. A key basic requirement of load balancing gateway systems is to achieve connection consistency.

[0070] To this end, under the relevant technology, for the first message of each connection sent by the client, the load balancing gateway system schedules to obtain the corresponding server IP address, and at the same time generates the cache file identifier (cookie id) and connection hash value corresponding to the connection, and saves the connection relationship table of the cookie id, connection hash value and server IP address. When the load balancing gateway system receives subsequent messages, it calculates the connection hash value based on the cookie id carried in the subsequent message and the message header based on the subsequent message, queries the connection relationship table, obtains the server IP address, and then forwards the subsequent message to the server based on the server IP address. The server returns the response message to the client through the ordinary gateway, and no longer passes through the load balancing gateway system for diversion.

[0071] In the above technical solution, the load balancing gateway system needs to store the cookie ID and connection hash value of each connection, which leads to excessive resource consumption of the load balancing gateway system, thereby affecting the stability and reliability of the load balancing gateway system.

[0072] Secondly, the above technical solution only guarantees the connection consistency of forward traffic (including messages sent by the client to the server), while reverse traffic (including messages returned by the server to the client) no longer passes through the load balancing gateway system for diversion. This causes the load balancing gateway system to have deviations when counting network traffic, thereby affecting the accuracy of traffic speed limiting and causing network congestion.

[0073] In view of this, an embodiment of the present application provides a data diversion method, in which, for forward traffic, the diverter parses the request message sent by the sender to obtain the cluster drainage address and the inner protocol header. Then, based on the cluster drainage address, the corresponding gateway cluster is determined, and the address set corresponding to the multiple gateway nodes contained in the gateway cluster is obtained. Then, the target address that matches the inner protocol header is selected from the address set, and the request message is sent to the corresponding target gateway node based on the target address. After the target gateway node adds the node drainage address corresponding to the target gateway node in the request message, the request message is sent to the receiving end.

[0074] For reverse traffic, the splitter receives the reply message from the receiving end that carries the node diversion address. It then sends the reply message to the target gateway node associated with the node diversion address, and the target gateway node sends the reply message to the sending end.

[0075] In an embodiment of the present application, the diverter diverts traffic through the cluster drainage address or node drainage address carried in the message, and there is no need to save the cookie ID and connection hash value of each connection. In other words, the diverter in the present application is implemented in a stateless manner, which can greatly reduce the storage resource usage, thereby improving the stability and reliability of the diverter.

[0076] Secondly, for forward traffic, the splitter dispatches the request message to the target gateway node based on the cluster drainage address in the request message and the inner protocol header of the request message, and the target gateway node forwards the request message to the receiving end. For reverse traffic, the splitter dispatches the reply message to the target gateway node based on the node drainage address corresponding to the target gateway node carried in the reply message, and the target gateway node forwards the reply message to the sending end. This ensures that both forward and reverse traffic are dispatched to the same target gateway node, ensuring the connection consistency of forward and reverse traffic on the same connection, effectively solving the problem of traffic jitter; at the same time, when counting network traffic, the accuracy is higher, thereby improving the accuracy of traffic speed limit and avoiding network congestion.

[0077] Refer to Figure 1, which is a system architecture diagram applicable to an embodiment of the present application. The system architecture at least includes a sending end 101, a traffic scheduling layer 102, a gateway cluster layer 103 and a receiving end 104.

[0078] Traffic scheduling layer 102 is used to dispatch received packets to gateway cluster layer 103. In practical applications, traffic scheduling layer 102 can deploy a single network splitter (referred to as a splitter) or a splitter cluster consisting of multiple splitters. Splitters support clustered deployment and can be horizontally expanded at will.

[0079] In some embodiments, the splitter can be implemented using a programmable switching chip, with a single splitter node capable of achieving Tbps of splitting capacity, offering advantages such as statelessness, high bandwidth, and low latency. The splitter can also be implemented using a common CPU server, a fact not specifically limited in this application. Furthermore, in the embodiments of this application, the splitter utilizes a stateless design, resulting in high stability and reliability.

[0080] The gateway cluster layer 103 includes various types of stateful or stateless gateway clusters. Deployed behind the traffic scheduling layer 102, it receives data requests dispatched by the front-end traffic scheduling layer 102. In practice, the physical topology between the gateway cluster layer 103 and the traffic scheduling layer 102 can span any Layer 3 network. The gateway cluster layer 103 also supports upgrading single-NIC gateways to multi-NIC gateways, significantly improving the overall performance of the back-end gateway.

[0081] The number of the transmitting ends 101 may be one or more, and the number of the receiving ends 104 may also be one or more. This application does not specifically limit the number of the transmitting ends 101 and the receiving ends 104.

[0082] Both the sending end 101 and the receiving end 104 can be virtual machines in a VPC cloud network. Of course, the sending end 101 and the receiving end 104 can also be terminal devices such as smartphones, tablets, laptops, desktop computers, smart home appliances, intelligent voice interaction devices, and smart car devices. The sending end 101 and the receiving end 104 can also be independent physical servers, or a server cluster or distributed system composed of multiple physical servers. They can also be cloud services that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, but are not limited to these.

[0083] Messages in the direction from the sending end 101 to the receiving end 104 can be called forward traffic, and messages in the direction from the receiving end 104 to the sending end 101 can be called reverse traffic.

[0084] In practical applications, the data diversion method in the embodiments of the present application can be applied to scenarios such as inter-node traffic distribution, lossless traffic migration between new and old clusters, cross-cluster disaster recovery, cross-availability zone / cross-region disaster recovery, and multi-tenant traffic isolation.

[0085] Based on the system architecture diagram shown in FIG1 , an embodiment of the present application provides a process of a data offloading method. As shown in FIG2 , the process of the method is interactively executed by the sending end, the splitter, the target gateway node, and the receiving end shown in FIG1 . The computer device described in the embodiment of the present application includes a splitter and a target gateway node. Specifically, the splitter is located in the traffic scheduling layer, and the target gateway node is located in the gateway cluster layer. The method includes the following steps:

[0086] Step S201: The splitter receives a request message sent by the sending end.

[0087] Specifically, the sending end can be a virtual machine in the VPC cloud network, or a terminal device, server, etc.

[0088] The request message carries the first outer protocol header, the cluster diversion address, and the inner protocol header.

[0089] In step S202, the splitter parses the request message to obtain the cluster diversion address and inner protocol header.

[0090] Specifically, the cluster diversion address refers to the Internet Protocol (IP) address (i.e., cluster_director_ip) pre-bound to the splitter for diverting traffic to the gateway cluster. Therefore, the cluster diversion address can also be called the cluster diversion IP address. Each gateway cluster in the backend gateway cluster layer can be assigned a cluster diversion address. Multiple cluster diversion addresses can be bound to a splitter to implement traffic scheduling for multiple gateway clusters in the gateway cluster layer.

[0091] In addition to binding the cluster drainage address, the splitter is also bound to the node drainage address. The node drainage address refers to the IP address (i.e., node_director_ip) pre-bound to the splitter for draining traffic to a single gateway node. Therefore, the node drainage address can also be called the node drainage IP address. For all gateway nodes in the gateway cluster layer in the backend gateway cluster layer, an independent node drainage address can be assigned. Multiple node drainage addresses can be bound to a splitter to implement traffic scheduling for multiple gateway nodes in the gateway cluster layer.

[0092] After the splitter is bound to the cluster drainage address and the node drainage address, it publishes dynamic routes of all cluster drainage addresses and all node drainage addresses to attract business traffic to the splitter.

[0093] After the splitter receives the request message sent by the sender, it parses the message protocol header of the request message to obtain the first outer protocol header and the inner protocol header. The destination IP address of the first outer protocol header is the cluster drainage address, and the inner protocol header includes: source IP address, destination IP address, identifier of the virtual private cloud where the sender is located, source port number, and destination port number.

[0094] It should be noted that although the above-mentioned cluster drainage address and node drainage address are pre-bound to the diverter, the subsequent diversion process also supports adjustment of the bound cluster drainage address and node drainage address. This application does not make specific restrictions on this.

[0095] Step S202: Determine the gateway cluster corresponding to the cluster diversion address, and obtain the address set corresponding to multiple gateway nodes in the gateway cluster.

[0096] Specifically, the diverter is provided with a diversion rule set, which includes multiple diversion rules, each of which includes a diversion address and a set of addresses of next-hop gateway nodes, wherein the diversion address types include cluster diversion addresses and node diversion addresses.

[0097] When the traffic diversion address is a cluster traffic diversion address, the next-hop gateway node address set includes the address set corresponding to multiple gateway nodes in the gateway cluster corresponding to the cluster traffic diversion address, including the addresses corresponding to each gateway node. When a traffic diverter is bound to multiple cluster traffic diversion addresses, the diversion rule set includes the diversion rules corresponding to each of the multiple cluster traffic diversion addresses.

[0098] When the diversion address is a node diversion address, the next-hop gateway node address set includes: the address of the gateway node corresponding to the node diversion address. When the splitter is bound to multiple node diversion addresses, the diversion rule set includes the diversion rules corresponding to the multiple node diversion addresses.

[0099] For example, see Table 1, which is a diversion rule table provided in an embodiment of the present application.

[0100] Table 1

[0101] The diversion rule table includes 5 diversion rules, which are numbered 1-5.

[0102] The diversion address of diversion rule 1 is: cluster diversion IP address (cluster_director_ip); the address set of the next-hop gateway node in diversion rule 1 includes: the IP address of gateway node 0 (backend_node0_ip), the IP address of gateway node 1 (backend_node1_ip), the IP address of gateway node 2 (backend_node2_ip), and the IP address of gateway node 3 (backend_node3_ip).

[0103] The diversion address of diversion rule 2 is: the node diversion IP address (node0_director_ip) corresponding to gateway node 0; the address set of the next-hop gateway node in diversion rule 2 includes: the IP address of gateway node 0 (backend_node0_ip).

[0104] The diversion address of diversion rule 3 is: the node diversion IP address (node1_director_ip) corresponding to gateway node 1; the address set of the next-hop gateway node in diversion rule 3 includes: the IP address of gateway node 1 (backend_node1_ip).

[0105] The diversion address of diversion rule 4 is: the node diversion IP address (node2_director_ip) corresponding to gateway node 2; the address set of the next-hop gateway node in diversion rule 4 includes: the IP address of gateway node 2 (backend_node2_ip).

[0106] The diversion address of diversion rule 5 is: the node diversion IP address (node3_director_ip) corresponding to gateway node 3; the address set of the next-hop gateway node in diversion rule 5 includes: the IP address of gateway node 3 (backend_node3_ip).

[0107] It should be noted that the above-mentioned diversion rule set is pre-set in the diverter, and the diversion rule set can also be adjusted during the subsequent diversion process. This application does not make any specific restrictions on this.

[0108] In some embodiments, after the diverter obtains the cluster diversion address from the request message, it obtains a first diversion rule that matches the cluster diversion address from a preset diversion rule set. The first diversion rule includes: the cluster diversion address and the address set corresponding to multiple gateway nodes contained in the corresponding gateway cluster.

[0109] Specifically, the cluster diversion address is compared with the diversion addresses of each diversion rule in the diversion rule set to determine the first matching diversion rule. Then, the address set of the next-hop gateway node corresponding to the first diversion rule in the diversion rule set is obtained, that is, the address set corresponding to multiple gateway nodes in the gateway cluster corresponding to the cluster diversion address.

[0110] Step S203: The splitter selects a target address that matches the inner protocol header from the address set.

[0111] In some embodiments, a target diversion strategy that matches the inner protocol header is selected from multiple diversion strategies; field information associated with the target diversion strategy is obtained from the inner protocol header. A hash calculation is then performed on the field information to obtain a target hash value; and an address in the address set that matches the target hash value is used as the target address.

[0112] Specifically, a set of diversion strategies is pre-set in the splitter. Different diversion strategies in the diversion strategy set correspond to different field information obtained from the inner protocol header for hash calculation, that is, the input fields of the hash algorithm are different. During the hash calculation process, the hash algorithms used include, but are not limited to, the SHA algorithm and the SM3 algorithm.

[0113] In actual applications, the diversion strategies in the diversion strategy set can be set according to actual conditions and support subsequent adjustments.

[0114] For example, see Table 2, which is a schematic diagram of a diversion strategy table provided in an embodiment of the present application.

[0115] Table 2

[0116] The header content of the above-mentioned diversion strategy table includes: a strategy name and an input field of a hash algorithm.

[0117] The diversion strategy set includes the following diversion strategies: diversion strategy based on flow granularity, diversion strategy based on service granularity, diversion strategy based on virtual private cloud granularity, and diversion strategy based on tenant granularity.

[0118] Specifically, the flow-based granularity diversion strategy refers to: using the five-tuple content in the inner protocol header of the message, namely the source IP address, destination IP address, VPCID, source port number, and destination port number, as the input field of the hash algorithm, performing hash calculation to obtain the hash value, and based on the hash value, querying the IP address of the next-hop gateway node, and then dispatching the message to the next-hop gateway node. In this way, it is ensured that messages with exactly the same five-tuple content can always be dispatched to the same gateway node at the back end. In actual applications, the flow-based granularity diversion strategy can be used as the system default diversion strategy.

[0119] The service-based traffic diversion strategy uses the VPCID, destination IP address, and destination port number in the packet's inner protocol header as input fields for a hashing algorithm. This hash value is then used to query the IP address of the next-hop gateway node and dispatch the packet to that node. This ensures that packets with the same destination IP address and destination port number are always dispatched to the same backend gateway node.

[0120] The VPC-based traffic diversion strategy uses the VPCID in the packet's inner protocol header as the input field of a hash algorithm. This hash value is then used to query the IP address of the next-hop gateway node, and the packet is then dispatched to that next-hop gateway node. This ensures that packets with the same VPCID are always dispatched to the same backend gateway node.

[0121] Tenant-based traffic diversion: The tenant identifier corresponding to the VPCID in the inner protocol header of the packet is used as the input field of the hash algorithm. A hash value is calculated. One tenant corresponds to one or more VPCIDs. Based on the hash value, the IP address of the next-hop gateway node is queried, and the packet is then dispatched to the next-hop gateway node. This ensures that packets with the same VPCID are always dispatched to the same backend gateway node.

[0122] The target diversion strategy can be selected from a set of diversion strategies or the default one. After determining the target diversion strategy, the associated field information is retrieved from the inner protocol header according to the target diversion strategy and hashed to obtain the target hash value. The IP address of the gateway node in the address set of the next-hop gateway node that has the same target hash value is used as the target address to match the inner protocol header.

[0123] In practical applications, the embodiments of the present application adopt at least the following implementation methods to select a target diversion strategy from a diversion strategy set:

[0124] In the first implementation mode, the priorities of multiple diversion strategies in the diversion strategy set are preset.

[0125] In the actual diversion process, the inner protocol header is matched with multiple diversion strategies in order from high to low priority until a matching target diversion strategy is obtained.

[0126] Specifically, first obtain the diversion strategy of the first priority, and then compare the specific value of the input field of the hash algorithm contained in the diversion strategy with the specific value of the relevant field in the inner protocol header of the request message. If they are consistent, the diversion strategy of the first priority is used as the matching target diversion strategy. If they are inconsistent, obtain the diversion strategy of the second priority and continue the matching process, and so on, until a matching target diversion strategy is found. If there is no matching target diversion strategy among multiple diversion strategies, a message indicating that traffic scheduling failed is returned.

[0127] In the second implementation mode, a diversion strategy based on flow granularity is set as the default diversion strategy of the system, and the priorities of other diversion strategies in the diversion strategy set are set.

[0128] During the actual traffic diversion process, the inner protocol header is matched against other diversion policies in descending order of priority until a matching target diversion policy is found. The specific matching method has been described above and will not be repeated here. If no matching target diversion policy is found among the other diversion policies, the flow-based diversion policy is used as the target diversion policy.

[0129] In the third embodiment, a diversion strategy (eg, a diversion strategy based on flow granularity) is selected from the diversion strategy set in advance as the system default diversion strategy. In the actual diversion process, the system default diversion strategy is directly used as the target diversion strategy.

[0130] It should be noted that the method of matching and obtaining the target diversion strategy is not limited to the above-mentioned implementation methods, and other implementation methods are also possible. This application does not make specific limitations on this.

[0131] In the actual diversion process, when the target diversion strategy is a flow-based diversion strategy, the field information obtained from the inner protocol header of the request message includes: source IP address, destination IP address, identifier of the virtual private cloud where the sender is located, source port number, and destination port number.

[0132] When the target offloading strategy is a service-based offloading strategy, the field information obtained from the inner protocol header of the request message includes: an identifier of the virtual private cloud where the sender is located, a destination IP address, and a destination port number.

[0133] When the target offload strategy is a offload strategy based on a virtual private cloud granularity, the field information obtained from the inner protocol header of the request message includes: an identifier of the virtual private cloud where the sender is located.

[0134] When the target traffic diversion strategy is a tenant-based traffic diversion strategy, the field information obtained from the inner protocol header of the request message includes: a tenant identifier corresponding to the identifier of the virtual private cloud where the sender is located.

[0135] In the embodiment of the present application, multiple diversion strategies are pre-set, such as diversion strategies based on flow granularity, diversion strategies based on service granularity, diversion strategies based on virtual private cloud granularity, and diversion strategies based on tenant granularity. Therefore, in the actual diversion process, a specific diversion strategy can be selected according to the actual situation and traffic scheduling can be performed based on the diversion strategy, thereby improving the flexibility of traffic scheduling.

[0136] In step S204, the splitter sends the request message to the target gateway node corresponding to the target address.

[0137] Specifically, the splitter modifies the destination IP address of the first outer protocol header of the request message into the target address, and then sends the request message to the corresponding target gateway node.

[0138] Step S205: The target gateway node adds the node diversion address corresponding to the target gateway node to the request message.

[0139] Step S206: The target gateway node sends the request message to the receiving end.

[0140] Specifically, after receiving the request message, the target gateway node executes its specific business logic. This logic may vary in different application scenarios. It then modifies the source IP address in the first outer protocol header of the request message to the node diversion address corresponding to the target gateway node. The request message is then sent to the corresponding receiving end.

[0141] It should be noted that in some complex gateway scenarios such as load balancing, it may be necessary to forward request messages in FULL NAT mode. At this time, the modified source IP address, destination IP address, source port number, and destination port number all refer to the source IP address, destination IP address, source port number, and destination port number in the inner protocol header. When the splitter splits traffic, it mainly dispatches the request message to the target gateway node by modifying the destination IP address of the outer protocol header of the request message. Therefore, this application supports symmetric splitting in FULL NAT mode, while ensuring the connection consistency of forward and reverse traffic.

[0142] Step S207: The splitter receives a reply message carrying the node diversion address from the receiving end.

[0143] Specifically, after receiving the request message, the receiving end obtains the node diversion address corresponding to the target gateway node from the outer protocol header of the request message. Simultaneously, the service data in the message body of the request message is processed. After processing, the receiving end generates a reply message corresponding to the request message and sends the reply message to the splitter. The reply message carries the node diversion address corresponding to the target gateway node.

[0144] The splitter parses the message protocol header of the reply message to obtain the destination IP address of the second outer protocol header, that is, the node diversion address of the target gateway node.

[0145] In step S208, the splitter sends a reply message to the target gateway node corresponding to the node diversion address.

[0146] Specifically, a second diversion rule matching the node diversion address is obtained from a preset diversion rule set, the second diversion rule including the node diversion address and the target address of the corresponding target gateway node. Then, based on the target address, a reply message is sent to the target gateway node.

[0147] In actual applications, after the diverter determines the matching second diversion rule, since the node diversion address in the second diversion rule and the target address of the target gateway node are in a one-to-one correspondence, the reply message can be sent directly to the target gateway node based on the target address.

[0148] Of course, the splitter can also select a target split strategy from the split strategy set, and then obtain the field information associated with the target split strategy from the inner protocol header. It then performs a hash calculation on the field information to obtain the target hash value. The address in the next-hop gateway node address set that matches the target hash value is used as the target address, and then the reply message is sent to the target gateway node based on the target address.

[0149] In some embodiments, before sending the reply message to the target gateway node associated with the node diversion address, the destination IP address of the second outer protocol header in the reply message is modified to the target address.

[0150] In step S209, the target gateway node sends a reply message to the sending end.

[0151] Specifically, after receiving the reply message, the target gateway node executes its specific business logic. This logic may vary in different application scenarios. It then modifies the source IP address in the second outer layer protocol header of the reply message to the cluster traffic diversion address. The reply message is then sent to the corresponding receiving end.

[0152] The above steps S201 to S206 are the forward flow diversion process, and the above steps S207 to S209 are the reverse flow diversion process. In order to more clearly illustrate the forward and reverse flow diversion process, the following examples are given in conjunction with specific implementation scenarios.

[0153] See Figure 3, which is a schematic diagram of a forward traffic diversion method provided in an embodiment of the present application. Assume that a gateway cluster in the gateway cluster layer includes four gateway nodes: gateway node 0, gateway node 1, gateway node 2, and gateway node 3. The diversion rule table in the diverter is shown in Table 1 above, and the diversion strategy table in the diverter is shown in Table 2 above. The sending end is client 301, and the receiving end is server 302.

[0154] The splitter receives the request message sent by the client 301, and parses the message protocol header of the request message to obtain the outer protocol header and the inner protocol header, wherein the destination IP address of the outer protocol header is: the cluster diversion IP address.

[0155] The traffic splitter queries the traffic diversion rule set according to the cluster diversion IP address and obtains the hit traffic diversion rule 1, that is, the address set of the next-hop gateway node includes: the IP address of gateway node 0, the IP address of gateway node 1, the IP address of gateway node 2, and the IP address of gateway node 3.

[0156] The traffic splitter selects the default flow-based traffic splitting strategy. Based on this flow-based traffic splitting strategy, it extracts the following fields from the inner protocol header of the request message: source IP address, destination IP address, VPC identifier, source port number, and destination port number. This information is then fed into a hash algorithm for calculation, yielding the target hash value.

[0157] Since the target hash value matches the IP address of gateway node 1, the destination IP address of the outer protocol header of the request message is modified to the IP address of gateway node 1, and the request message is sent to gateway node 1.

[0158] After executing the service logic, gateway node 1 modifies the source IP address of the outer protocol header of the request message to the node diversion IP address corresponding to gateway node 1, and then sends the request message to server 302.

[0159] See FIG4 , which is a schematic diagram of a reverse flow diversion method provided in an embodiment of the present application.

[0160] After server 401 processes the request message, it returns a reply message to the splitter. The splitter parses the message protocol header of the reply message and obtains the destination IP address of the outer message header as the node diversion IP address corresponding to gateway node 1.

[0161] The splitter queries the splitting rule table according to the node diversion IP address corresponding to gateway node 1, and obtains the hit splitting rule 3, that is, the address set of the next-hop gateway node includes: the IP address of gateway node 1.

[0162] Since the address set of the next-hop gateway node has only one IP address, namely the IP address of gateway node 1, the destination IP address of the outer protocol header of the reply message is modified to: the IP address of gateway node 1, and the reply message is sent to gateway node 1.

[0163] After executing the service logic, gateway node 1 modifies the source IP address of the outer protocol header of the reply message to the cluster drainage address, and then sends the reply message to client 402.

[0164] In an embodiment of the present application, the diverter diverts traffic through the cluster drainage address or node drainage address carried in the message, and there is no need to save the cookie ID and connection hash value of each connection. In other words, the diverter in the present application is implemented in a stateless manner, which can greatly reduce the storage resource usage, thereby improving the stability and reliability of the diverter.

[0165] Secondly, for forward traffic, the splitter dispatches the request message to the target gateway node based on the cluster drainage address in the request message and the inner protocol header of the request message, and the target gateway node forwards the request message to the receiving end. For reverse traffic, the splitter dispatches the reply message to the target gateway node based on the node drainage address corresponding to the target gateway node carried in the reply message, and the target gateway node forwards the reply message to the sending end. This ensures that both forward and reverse traffic are dispatched to the same target gateway node, ensuring the connection consistency of forward and reverse traffic on the same connection, effectively solving the problem of traffic jitter; at the same time, when counting network traffic, the accuracy is higher, thereby improving the accuracy of traffic speed limit and avoiding network congestion.

[0166] In some embodiments, for each gateway cluster in the gateway cluster layer, when a new gateway node is added to the gateway cluster for expansion, the set of traffic diversion rules is updated accordingly.

[0167] Specifically, the traffic diversion rule corresponding to the cluster traffic diversion address of the gateway cluster is first determined. The IP address of the new gateway node is added to the address set of the next-hop gateway node in the diversion rule. Furthermore, a node diversion address is assigned to the IP address of the new gateway node. A new diversion rule is then added to the diversion rule set. This new diversion rule includes the IP address of the new gateway node and the corresponding node diversion address. The new gateway node also stores the corresponding node diversion address locally.

[0168] When the splitter performs traffic diversion, it schedules some of the connections originally scheduled to the gateway nodes in the gateway cluster to the new gateway nodes, and the scheduling method of the remaining connections remains unchanged. This avoids the problem of forwarding offset between gateway nodes in the gateway cluster when the number of gateway nodes in the gateway cluster changes, and overall improves the stability and reliability of the backend gateway cluster.

[0169] For example, referring to FIG5 , it is assumed that the gateway cluster includes gateway node 0, gateway node 1, and gateway node 2. The diversion rule table in the diverter is shown in Table 3:

[0170] Table 3

[0171] The splitter schedules the message of connection 0 (○0) to gateway node 0, the message of connection 1 (①) to gateway node 1, the message of connection 2 (②) to gateway node 2, and the message of connection 3 (③) to gateway node 0.

[0172] When gateway node 3 is added to the gateway cluster, gateway node 3's IP address (backend_node3_ip) is added to the next-hop gateway node address set for diversion rule 1 in the diversion rule table. Diversion rule 5 is then added to the diversion rule table. The diversion address for diversion rule 5 is the node diversion IP address (node3_director_ip) corresponding to gateway node 3. The next-hop gateway node address set in diversion rule 5 includes gateway node 3's IP address (backend_node3_ip). The updated diversion rule table is shown in Table 1 and is not detailed here.

[0173] The splitter still dispatches packets from connection 0 to gateway node 0, packets from connection 1 to gateway node 1, and packets from connection 2 to gateway node 2. However, it dispatches packets from connection 3 to gateway node 3.

[0174] In some embodiments, for each gateway cluster in the gateway cluster layer, when a gateway node is deleted from the gateway cluster, the traffic diversion rule set is updated accordingly.

[0175] Specifically, first determine the traffic diversion rule containing the cluster traffic diversion address corresponding to the gateway cluster. Then, remove the IP address of the deleted gateway node from the address set of the next-hop gateway node in that diversion rule. Simultaneously, determine the traffic diversion rule containing the node traffic diversion address corresponding to the deleted gateway node, and then remove that diversion rule from the diversion rule set.

[0176] When performing traffic diversion, the splitter schedules the connections originally scheduled to the deleted gateway node to other gateway nodes in the gateway cluster, and the connections originally scheduled to other gateway nodes continue to be scheduled to these gateway nodes, thereby avoiding the problem of forwarding offset between gateway nodes in the gateway cluster when the number of gateway nodes in the gateway cluster changes, and overall improving the stability and reliability of the backend gateway cluster.

[0177] For example, referring to Figure 6, it is assumed that the gateway cluster includes gateway node 0, gateway node 1, gateway node 2, and gateway node 3. The traffic diversion rule table in the diverter is shown in Table 1 and will not be repeated here.

[0178] The splitter schedules the message of connection 0 (○0) to gateway node 0, the message of connection 1 (①) to gateway node 1, the message of connection 2 (②) to gateway node 2, and the message of connection 3 (③) to gateway node 3.

[0179] When gateway node 3 is deleted from the gateway cluster, the IP address of gateway node 3 (backend_node3_ip) is removed from the address set of the next-hop gateway node for diversion rule 1 shown in Table 1. At the same time, diversion rule 5 in Table 1 is deleted. The updated diversion rule table is shown in Table 3 and is not repeated here.

[0180] When the splitter is splitting, it still dispatches the message of connection 0 to gateway node 0, the message of connection 1 to gateway node 1, and the message of connection 2 to gateway node 2. However, it dispatches the message of connection 3 to gateway node 0.

[0181] To ensure that backend gateway nodes can achieve automatic disaster recovery when a failure occurs, the present application provides at least the following implementation methods for performing health detection on gateway nodes:

[0182] Implementation method 1: For each gateway node in the gateway cluster, a health check strategy based on automatic convergence of the dynamic routing protocol is supported, which realizes automatic disaster recovery when a gateway node fails, and the diversion rules on the diverter do not need to be modified.

[0183] The following is an example of the target gateway node:

[0184] The target gateway node obtains multiple corresponding backup gateway nodes, each backup gateway node corresponds to a backup routing priority; the backup routing priorities of the multiple backup gateway nodes are published so that when the target gateway node fails, the multiple backup gateway nodes take over the messages forwarded to the target gateway node according to the corresponding backup routing priorities.

[0185] Specifically, the target gateway node publishes a dynamic route of the IP address of the node through a dynamic routing protocol (eg, BGP protocol, OSPF protocol), and the dynamic route corresponds to the highest priority.

[0186] In the gateway cluster, every two gateway nodes are grouped into a group (and each gateway node can only belong to one group at a time), and the group where the target gateway node is located is used as the first priority backup group, and the other gateway node in the first priority backup group is the backup gateway node.

[0187] The target gateway node publishes a backup route of the IP address of the backup gateway node, and the priority of the backup route is set to the first backup priority, which is lower than the highest priority described above.

[0188] In the gateway cluster, the gateway nodes are grouped again into groups of two (and each gateway node can only belong to one group at a time), and the group where the target gateway node is located is used as the second priority backup group. The backup gateway nodes in the second priority backup group are different from the backup gateway nodes in the first priority backup group.

[0189] The target gateway node publishes a backup route of the IP address of the backup gateway node in the second priority backup group, and the priority of the backup route is set to the second backup priority, which is lower than the first backup priority.

[0190] And so on, until every other gateway node in the gateway cluster forms a priority backup group with the target gateway node.

[0191] When the target gateway node fails, the traffic of the target gateway node is taken over by the backup gateway node with the first backup priority.

[0192] If the backup gateway node with the first backup priority also fails, the traffic of the target gateway node is taken over by the backup gateway node with the second backup priority.

[0193] If the backup gateway node with the second highest backup priority also fails, the traffic from the target gateway node will be taken over by the backup gateway node with the third highest backup priority. This process continues in this order until a backup gateway node takes over the traffic from the target gateway node. If all backup gateway nodes with the highest backup priority also fail, a message indicating that traffic forwarding failed will be returned.

[0194] For example, referring to FIG7 , it is assumed that the gateway cluster includes four gateway nodes, namely: gateway node 0, gateway node 1, gateway node 2, and gateway node 3.

[0195] Gateway node 0 publishes a dynamic route of the IP address of the node through a dynamic routing protocol (eg, BGP protocol, OSPF protocol). The dynamic route corresponds to the highest priority.

[0196] Gateway node 0 is grouped into two groups in the gateway cluster, obtaining a first-priority backup group of {gateway node 0 and gateway node 1}. Gateway node 0 advertises a backup route to gateway node 1's IP address, with the corresponding priority set to the first backup priority.

[0197] Gateway node 0 is grouped into two groups in the gateway cluster to obtain the second priority backup group {gateway node 0 and gateway node 2}. Gateway node 0 publishes a backup route to the IP address of gateway node 2, with the corresponding priority set to the second backup priority.

[0198] Gateway node 0 is grouped into two groups in the gateway cluster, obtaining the second priority backup group {gateway node 0 and gateway node 3}. Gateway node 0 publishes a backup route to the IP address of gateway node 3, with the corresponding priority set to the third backup priority.

[0199] That is, the routing priority order on gateway node 0 is: IP address of gateway node 0 > IP address of gateway node 1 > IP address of gateway node 2 > IP address of gateway node 3.

[0200] During traffic scheduling, when gateway node 0 fails, the traffic of gateway node 0 is taken over by gateway node 1.

[0201] If gateway node 1 also fails, the traffic of gateway node 0 is taken over by gateway node 2.

[0202] If gateway node 2 also fails, the traffic of gateway node 0 is taken over by gateway node 3.

[0203] If gateway node 3 also fails, a message indicating traffic forwarding failure is returned.

[0204] Similarly, gateway node 1, gateway node 2, and gateway node 3 can also use the above method to publish different priority routes and take over traffic according to different priority routes. The priority table of routes of each gateway node is shown in Table 4:

[0205] Table 4

[0206] In Table 4 above, the backup groups of different priorities corresponding to gateway node 1 are: first-priority backup group {gateway node 1 and gateway node 0}; second-priority backup group {gateway node 1 and gateway node 3}; and third-priority backup group {gateway node 1 and gateway node 2}. In other words, the routing priority order on gateway node 1 is: gateway node 1's IP address > gateway node 0's IP address > gateway node 3's IP address > gateway node 2's IP address.

[0207] The backup groups of different priorities corresponding to gateway node 2 are: first-priority backup group {gateway node 2 and gateway node 3}; second-priority backup group {gateway node 2 and gateway node 0}; and third-priority backup group {gateway node 2 and gateway node 1}. In other words, the routing priority order on gateway node 2 is: gateway node 3's IP address > gateway node 0's IP address > gateway node 1's IP address > gateway node 1's IP address.

[0208] The backup groups of different priorities corresponding to gateway node 3 are: first-priority backup group {gateway node 3 and gateway node 2}; second-priority backup group {gateway node 3 and gateway node 1}; and third-priority backup group {gateway node 3 and gateway node 0}. In other words, the routing priority order on gateway node 3 is: gateway node 2's IP address > gateway node 1's IP address > gateway node 1's IP address > gateway node 0's IP address.

[0209] In an embodiment of the present application, a health check strategy based on automatic convergence of the dynamic routing protocol is used to set up backup groups with different priorities for each gateway node in the back-end gateway cluster. Therefore, when a gateway node fails, the traffic of the gateway node is automatically taken over according to different routing priorities, thereby realizing automatic disaster recovery and improving the disaster recovery capability of the back-end gateway cluster.

[0210] Implementation method 2: Support a distributed health check strategy for each gateway node in the gateway cluster. Each splitter in the traffic scheduling layer detects whether each backend gateway node is in a faulty state. When a splitter detects that a target gateway node is in a faulty state, it retrieves the first and second splitting rules associated with the target address from the splitting rule set. It then removes the target address from the address set included in the first splitting rule and removes the second splitting rule from the splitting rule set.

[0211] Specifically, the splitter traverses all diversion rules in the diversion rule set, detects whether all next-hop gateway nodes corresponding to each diversion rule are in a fault state, and updates the diversion rule set if they are in a fault state.

[0212] The following is an example of the target gateway node described above, with the next-hop gateway node as the example:

[0213] The splitter constructs an ICMP request message with the destination being the target gateway node, and then sends the ICMP request message to the target gateway node.

[0214] Determine whether an ICMP response message from the target gateway node has been received. If the ICMP response message from the target gateway node is not received for N consecutive times (configurable), it is determined that the target gateway node has failed, and the first diversion rule and the second diversion rule associated with the target gateway node are obtained from the diversion rule set. The target address (the IP address of the target gateway node) is removed from the next-hop gateway node IP address set of the first diversion rule, and the second diversion rule is deleted at the same time. If an ICMP response message from the target gateway node is received, it is determined that the target gateway node is alive and there is no need to modify the diversion rules.

[0215] It should be noted that the status detection method of other gateway nodes and the method of updating the diversion rule set are the same and will not be repeated here.

[0216] In an embodiment of the present application, a distributed health check strategy is used to perform health detection on each gateway node in the backend, and when a gateway node failure is detected, the corresponding diversion rule in the diversion rule set is automatically updated, thereby realizing automatic disaster recovery of the gateway node and improving the disaster recovery capability of the backend gateway cluster.

[0217] In a third embodiment, the splitter, in response to a delete instruction sent by the controller for a target address in a split rule set, retrieves a first split rule and a second split rule associated with the target address from the split rule set. The delete instruction is sent by the controller via a remote interface of the splitter when the controller detects that the target gateway node is in a faulty state. The splitter deletes the target address from the address set included in the first split rule and deletes the second split rule from the split rule set.

[0218] Specifically, the splitter supports a centralized health check strategy implemented by the controller. This means that the splitter does not need to independently monitor the health of backend gateway nodes. Instead, it provides a remote call interface for adding, deleting, and modifying splitting rules, with the controller performing centralized health monitoring. When a change in the status of a backend gateway node is detected, the splitting rule set across all splitters is uniformly modified through the remote call interface.

[0219] The following uses the backend gateway node as an example to illustrate the target gateway node described above:

[0220] When the controller detects that the state of the target gateway node changes from a survival state to a failure state, it calls the remote interface of the diverter, deletes the IP address of the target gateway node from the next-hop gateway node IP address set corresponding to the first diversion rule of the target gateway node, and deletes the second flow rule corresponding to the target gateway node at the same time.

[0221] When the controller detects that the state of the target gateway node changes from a faulty state to a surviving state, it calls the remote interface of the diverter, adds the IP address of the target gateway node to the next-hop gateway node IP address set corresponding to the first diversion rule of the target gateway node, and adds the second flow rule corresponding to the target gateway node to the diversion rule combination.

[0222] It should be noted that the status detection method of other gateway nodes and the method of updating the diversion rule set are the same and will not be repeated here.

[0223] In an embodiment of the present application, a centralized health check strategy is adopted to perform health detection on each gateway node in the backend, and the corresponding diversion rules in the diversion rule set are adjusted in combination with the remote interface provided by the diverter. The diverter does not need to autonomously detect the health status of the backend gateway nodes. This not only improves the disaster recovery capability of the backend gateway cluster, but also reduces the resource consumption of the diverter.

[0224] In order to better explain the embodiments of the present application, a data diversion method provided by the embodiments of the present application is introduced below in combination with a specific implementation scenario. See Figure 8. The process of this method can be interactively executed by the client, traffic scheduling layer, gateway cluster layer and server. Each diverter in the traffic scheduling layer includes: a message parsing unit, a diversion strategy unit, a traffic scheduling unit and a health check unit; the gateway cluster layer includes multiple gateway clusters, and each gateway cluster includes multiple gateway nodes.

[0225] The following describes the forwarding process of forward traffic, which includes the following steps:

[0226] In step 801, the client sends a request message to the splitter in the traffic scheduling layer.

[0227] In step 802, the message parsing unit in the splitter parses the message protocol header of the request message to obtain the cluster diversion IP address and the inner protocol header.

[0228] In step 803, the diversion strategy unit in the diverter selects diversion rules and diversion strategies based on the cluster diversion IP address and inner layer protocol header, and determines the target gateway node (i.e., gateway node 1) for traffic scheduling in the gateway cluster layer based on the diversion rules and diversion strategies.

[0229] In step 804 , the health check unit in the splitter detects the health status of the gateway node 1 .

[0230] In step 805 , the traffic scheduling unit in the splitter modifies the destination IP address of the outer protocol header of the request message to the IP address of gateway node 1 , and schedules the request message to gateway node 1 .

[0231] When a failure of gateway node 1 is detected, the request message will still be forwarded to gateway node 1. At this time, the request message will be taken over by the backup gateway node in the priority backup group corresponding to gateway node 1 to achieve automatic disaster recovery.

[0232] In step 806 , the gateway node 1 modifies the source IP address of the outer protocol header of the request message to the node diversion IP address corresponding to the gateway node 1 , and dispatches the request message to the server.

[0233] The following describes the reverse traffic forwarding process, which includes the following steps:

[0234] In step 807, the server sends the reply message to the splitter in the traffic scheduling layer.

[0235] In step 808, the message parsing unit in the splitter parses the message protocol header of the reply message to obtain the node diversion IP address and the inner protocol header.

[0236] In step 809 , the diversion strategy unit in the diverter selects diversion rules and diversion strategies based on the node diversion IP address and the inner protocol header, and determines the gateway node 1 for traffic scheduling based on the diversion rules and diversion strategies.

[0237] In step 810 , the health check unit in the splitter detects the health status of each gateway node in the gateway cluster layer.

[0238] In step 811 , the splitter modifies the destination IP address of the outer protocol header of the reply message to the IP address of gateway node 1 , and dispatches the reply message to gateway node 1 .

[0239] In step 812, gateway node 1 modifies the source IP address of the outer protocol header of the reply message to the cluster drainage IP address, and dispatches the reply message to the client.

[0240] In an embodiment of the present application, the diverter diverts traffic by carrying a cluster drainage address or a node drainage address in the message, and there is no need to save the cookie ID and connection hash value of each connection. In other words, the diverter in the present application is implemented in a stateless manner, which can greatly reduce the storage resource usage, thereby improving the stability and reliability of the diverter.

[0241] Secondly, during the traffic diversion process, the diverter dispatches the request message to the target gateway node based on the cluster drainage address and the inner protocol header of the request message. Then, by carrying the node drainage address corresponding to the target gateway node in the reply message, the reply message is also dispatched to the target gateway node. This ensures that both forward and reverse traffic are dispatched to the same target gateway node, ensuring the connection consistency of forward and reverse traffic on the same connection, effectively solving the problem of traffic jitter, and achieving higher accuracy when counting network traffic, thereby improving the accuracy of traffic speed limiting and avoiding network congestion.

[0242] Based on the same technical concept, an embodiment of the present application provides a structural diagram of a data splitting device, which is applied to a splitter. As shown in FIG9 , the device 900 includes:

[0243] Parsing module 901, used to parse the request message sent by the sender to obtain the cluster diversion address and inner protocol header;

[0244] Matching module 902 is configured to determine the gateway cluster corresponding to the cluster drainage address and obtain an address set corresponding to multiple gateway nodes in the gateway cluster; select a target address that matches the inner protocol header from the address set, and send the request message to the target gateway node corresponding to the target address, so that the target gateway node adds the node drainage address corresponding to the target gateway node to the request message, and send the request message to the receiving end;

[0245] A first receiving module 903 is configured to receive a reply message carrying the node diversion address from the receiving end; and

[0246] The first sending module 904 is configured to send the reply message to the target gateway node corresponding to the node diversion address, so that the target gateway node sends the reply message to the sending end.

[0247] Optionally, the matching module 902 is specifically configured to:

[0248] Selecting a target diversion strategy that matches the inner protocol header from multiple diversion strategies;

[0249] Acquiring field information associated with the target diversion strategy from the inner protocol header;

[0250] Perform hash calculation on the field information to obtain a target hash value;

[0251] Optionally, when the target traffic diversion strategy is a traffic diversion strategy based on flow granularity, the field information includes: the source IP address, the destination IP address, the identifier of the virtual private cloud where the sender is located, the source port number, and the destination port number in the inner protocol header;

[0252] When the target traffic diversion policy is a service-based traffic diversion policy, the field information includes: the VPC identifier, the destination IP address, and the destination port number;

[0253] When the target traffic diversion strategy is a traffic diversion strategy with virtual private cloud as the granularity, the field information includes: the identifier of the virtual private cloud;

[0254] When the target traffic diversion strategy is a tenant-based traffic diversion strategy, the field information includes: a tenant identifier corresponding to the virtual private cloud identifier.

[0255] Optionally, the parsing module 901 is specifically configured to:

[0256] Parsing the request message by message protocol header to obtain a first outer layer protocol header and the inner layer protocol header;

[0257] The destination IP address in the first outer protocol header is determined as the cluster diversion address.

[0258] The parsing module 901 is further used to:

[0259] Parsing the message protocol header of the reply message to obtain a second outer layer protocol header;

[0260] The destination IP address in the second outer protocol header is determined as the node diversion address.

[0261] Optionally, the first sending module 904 is further configured to:

[0262] Before sending the request message to the target gateway node, the destination IP address of the first outer protocol header is modified to the target address.

[0263] Before sending the reply message to the target gateway node, the destination IP address of the second outer protocol header is modified to the target address.

[0264] Optionally, the matching module 902 is specifically configured to:

[0265] A first diversion rule matching the cluster diversion address is obtained from a preset diversion rule set, where the first diversion rule includes: the cluster diversion address and the address set.

[0266] Optionally, the matching module 902 is specifically configured to:

[0267] Acquire a second diversion rule matching the node diversion address from a preset diversion rule set, wherein the second diversion rule includes: the node diversion address and the target address of the target gateway node;

[0268] Based on the target address, the reply message is sent to the target gateway node.

[0269] Optionally, a health strategy module 905 is also included;

[0270] The health policy module 905 is specifically used to:

[0271] Retrieving the first and second diversion rules associated with the target address from the diversion rule set in response to a delete instruction sent by a controller for the target address in the diversion rule set, wherein the delete instruction is sent by the controller by calling the remote interface of the diverter when detecting that the target gateway node is in a fault state;

[0272] Deleting the target address from the address set included in the first diversion rule;

[0273] Delete the second diversion rule from the diversion rule set.

[0274] Optionally, the health policy module 905 is specifically configured to:

[0275] When detecting that the target gateway node is in a fault state, acquiring the first diversion rule and the second diversion rule associated with the target address from the diversion rule set;

[0276] Deleting the target address from the address set included in the first diversion rule;

[0277] Delete the second diversion rule from the diversion rule set.

[0278] Based on the same technical concept, an embodiment of the present application provides a structural diagram of a data offload device, which is applied to a target gateway node. As shown in FIG10 , the device 1000 includes:

[0279] The second receiving module 1001 is used to receive a request message sent by the splitter based on the target address corresponding to the target gateway node, wherein the splitter receives the request message from the sending end, parses the request message, obtains the cluster drainage address and the inner protocol header, determines the gateway cluster corresponding to the cluster drainage address, obtains the address set corresponding to multiple gateway nodes in the gateway cluster, and selects the target address that matches the inner protocol header from the address set;

[0280] Processing module 1002, configured to add a node diversion address corresponding to the target gateway node to the request message;

[0281] A second sending module 1003 is configured to send the request message to a receiving end, wherein the splitter receives a reply message carrying the node diversion address from the receiving end;

[0282] The second receiving module 1001 receives a reply message sent by the splitter based on the node diversion address; and

[0283] The second sending module 1003 is further configured to send the reply message to the sending end.

[0284] Optionally, the processing module 1002 is specifically configured to:

[0285] After modifying the source Internet Protocol (IP) address of the first outer layer protocol header of the request message to the node diversion address, the request message is sent to the receiving end.

[0286] Before sending the reply message to the sending end, the source Internet Protocol (IP) address of the second outer layer protocol header of the reply message is modified to the cluster drainage address.

[0287] Optionally, the processing module 1002 is further configured to:

[0288] Acquire multiple backup gateway nodes corresponding to the target gateway node, each backup gateway node corresponding to a backup routing priority;

[0289] The backup routing priorities of the plurality of backup gateway nodes are published so that when the target gateway node fails, the plurality of backup gateway nodes take over the message forwarding to the target gateway node according to the corresponding backup routing priorities.

[0290] In an embodiment of the present application, the diverter diverts traffic through the cluster drainage address or node drainage address carried in the message, and there is no need to save the cookie ID and connection hash value of each connection. In other words, the diverter in the present application is implemented in a stateless manner, which can greatly reduce the storage resource usage, thereby improving the stability and reliability of the diverter.

[0291] Secondly, for forward traffic, the splitter dispatches the request message to the target gateway node based on the cluster drainage address in the request message and the inner protocol header of the request message, and the target gateway node forwards the request message to the receiving end. For reverse traffic, the splitter dispatches the reply message to the target gateway node based on the node drainage address corresponding to the target gateway node carried in the reply message, and the target gateway node forwards the reply message to the sending end. This ensures that both forward and reverse traffic are dispatched to the same target gateway node, ensuring the connection consistency of forward and reverse traffic on the same connection, effectively solving the problem of traffic jitter; at the same time, when counting network traffic, the accuracy is higher, thereby improving the accuracy of traffic speed limit and avoiding network congestion.

[0292] Based on the same technical concept, an embodiment of the present application provides a computer device, which can be the sending end, splitter, gateway node, or receiving end shown in Figure 1. As shown in Figure 11, the computer device includes at least one processor 1101 and a memory 1102 connected to the at least one processor. The specific connection medium between the processor 1101 and the memory 1102 is not limited in the embodiment of the present application. In Figure 11, the processor 1101 and the memory 1102 are connected via a bus as an example. Buses can be divided into address buses, data buses, control buses, etc.

[0293] In an embodiment of the present application, the memory 1102 stores instructions that can be executed by at least one processor 1101. The at least one processor 1101 can perform the steps of the above-mentioned data diversion method by executing the instructions stored in the memory 1102.

[0294] The processor 1101 is the control center of the computer device. It can connect various parts of the computer device using various interfaces and lines, and implement data diversion by running or executing instructions stored in the memory 1102 and calling data stored in the memory 1102. Optionally, the processor 1101 may include one or more processing units. The processor 1101 may integrate an application processor and a modem processor. The application processor mainly processes the operating system, user interface, and application programs, while the modem processor mainly processes wireless communications. It is understood that the modem processor may not be integrated into the processor 1101. In some embodiments, the processor 1101 and the memory 1102 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0295] The processor 1101 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0296] Memory 1102 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. Memory 1102 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. Memory 1102 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer device, but is not limited thereto. The memory 1102 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0297] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program that can be executed by a computer device. When the program runs on the computer device, the computer device executes the steps of the above-mentioned data diversion method.

[0298] Based on the same inventive concept, an embodiment of the present application provides a computer program product, which includes a computer program stored on a computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer device, the computer device executes the steps of the above-mentioned data diversion method.

[0299] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0300] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer device or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0301] These computer program instructions may also be stored in a computer-readable memory that can direct a computer device or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0302] These computer program instructions can also be loaded onto a computer device or other programmable data processing device, so that a series of operating steps are executed on the computer device or other programmable device to produce a process implemented by the computer device, so that the instructions executed on the computer device or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0303] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0304] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A data diversion method, executed by a computer device, comprising: Parse the request message sent by the sender to obtain the cluster diversion address and inner protocol header; Determine the gateway cluster corresponding to the cluster diversion address, and obtain the address set corresponding to multiple gateway nodes in the gateway cluster; Selecting a target address that matches the inner protocol header from the address set, and sending the request message to a target gateway node corresponding to the target address, so that the target gateway node adds a node diversion address corresponding to the target gateway node to the request message, and sends the request message to a receiving end; receiving a reply message carrying the node diversion address from the receiving end; and, The reply message is sent to the target gateway node corresponding to the node diversion address, so that the target gateway node sends the reply message to the sending end.

2. The method of claim 1, wherein: The selecting a target address matching the inner protocol header from the address set includes: Selecting a target diversion strategy that matches the inner protocol header from multiple diversion strategies; Acquire field information associated with the target diversion strategy from the inner protocol header; Performing hash calculation on the field information to obtain a target hash value; An address in the address set that matches the target hash value is used as the target address.

3. The method of claim 2, further comprising: When the target diversion strategy is a diversion strategy based on flow granularity, the field information includes: a source Internet Protocol IP address, a destination IP address, an identifier of the virtual private cloud where the sender is located, a source port number, and a destination port number; When the target traffic diversion strategy is a traffic diversion strategy based on service granularity, the field information includes: an identifier of the virtual private cloud where the sender is located, the destination IP address, and the destination port number; When the target traffic diversion strategy is a traffic diversion strategy with virtual private cloud as granularity, the field information includes: an identifier of the virtual private cloud where the sending end is located; When the target traffic diversion strategy is a traffic diversion strategy based on tenant granularity, the field information includes: a tenant identifier corresponding to an identifier of the virtual private cloud where the sending end is located.

4. The method according to any one of claims 1 to 3, wherein: The request message sent by the sender is parsed to obtain the cluster diversion address and the inner layer protocol header, including: Parsing the request message by message protocol header to obtain a first outer layer protocol header and the inner layer protocol header; The destination IP address in the first outer protocol header is determined as the cluster diversion address.

5. The method according to any one of claims 1 to 4, further comprising: Parsing the message protocol header of the reply message to obtain a second outer layer protocol header; The destination IP address in the second outer protocol header is determined as the node diversion address.

6. The method of claim 4, further comprising: Before sending the request message to the target gateway node, the destination IP address of the first outer protocol header is modified to the target address.

7. The method of claim 5, further comprising: Before sending the reply message to the target gateway node, the destination IP address of the second outer protocol header is modified to the target address.

8. The method according to any one of claims 1 to 7, wherein: The determining the gateway cluster corresponding to the cluster diversion address and obtaining the address set corresponding to multiple gateway nodes in the gateway cluster includes: A first diversion rule matching the cluster diversion address is obtained from a preset diversion rule set, where the first diversion rule includes: the cluster diversion address and the address set.

9. The method of claim 8, wherein: The step of sending the reply message to the target gateway node corresponding to the node diversion address includes: From the preset diversion rule set, a second diversion rule matching the node diversion address is obtained, wherein the second diversion rule includes Including: the node diversion address, the target address of the target gateway node; Based on the target address, the reply message is sent to the target gateway node.

10. The method of claim 9, further comprising: In response to a delete instruction for the target address in the diversion rule set sent by the controller, acquiring the first diversion rule and the second diversion rule associated with the target address from the diversion rule set, wherein the delete instruction is sent by calling the remote interface of the diverter when the controller detects that the target gateway node is in a fault state; Deleting the target address from the address set included in the first diversion rule; The second diversion rule is deleted from the diversion rule set.

11. The method of claim 9, further comprising: When it is detected that the target gateway node is in a fault state, acquiring the first diversion rule and the second diversion rule associated with the target address from the diversion rule set; Deleting the target address from the address set included in the first diversion rule; The second diversion rule is deleted from the diversion rule set.

12. A data diversion method, executed by a computer device, comprising: A receiving device sends a request message based on a target address corresponding to a target gateway node, wherein the device receives the request message from a sending end, parses the request message, obtains a cluster drainage address and an inner protocol header, determines a gateway cluster corresponding to the cluster drainage address, obtains an address set corresponding to multiple gateway nodes in the gateway cluster, and selects a target address that matches the inner protocol header from the address set; After adding the node diversion address corresponding to the target gateway node in the request message, the request message is sent to the receiving end, wherein the splitter receives a reply message carrying the node diversion address from the receiving end; receiving a reply message sent by the splitter based on the node diversion address; and, The reply message is sent to the sending end.

13. The method of claim 12, wherein: After adding the node diversion address corresponding to the target gateway node in the request message, sending the request message to the receiving end includes: After modifying the source Internet Protocol IP address of the first outer layer protocol header of the request message to the node diversion address, the request message is sent to the receiving end.

14. The method according to claim 12 or 13, further comprising: Before sending the reply message to the sending end, the source Internet Protocol IP address of the second outer layer protocol header of the reply message is modified to the cluster drainage address.

15. The method of any one of claims 12 to 14, further comprising: Acquire multiple backup gateway nodes corresponding to the target gateway node, each backup gateway node corresponding to a backup routing priority; The backup routing priorities of the multiple backup gateway nodes are published so that when the target gateway node fails, the multiple backup gateway nodes take over the messages forwarded to the target gateway node according to the corresponding backup routing priorities.

16. A data distribution device, comprising: The parsing module is used to parse the request message sent by the sender to obtain the cluster drainage address and inner protocol header; A matching module, configured to determine a gateway cluster corresponding to the cluster diversion address and obtain an address set corresponding to multiple gateway nodes in the gateway cluster; Selecting a target address that matches the inner protocol header from the address set, and sending the request message to a target gateway node corresponding to the target address, so that the target gateway node adds a node diversion address corresponding to the target gateway node to the request message, and sends the request message to a receiving end; A first receiving module, configured to receive a reply message carrying the node diversion address from the receiving end; and, The first sending module is used to send the reply message to the target gateway node corresponding to the node diversion address, so that the target gateway node sends the reply message to the sending end.

17. A data distribution device, comprising: A second receiving module is used to receive a request message sent by the splitter based on the target address corresponding to the target gateway node, wherein the splitter receives the request message from the sending end, parses the request message, obtains the cluster drainage address and the inner protocol header, determines the gateway cluster corresponding to the cluster drainage address, obtains the address set corresponding to multiple gateway nodes in the gateway cluster, and selects the target address matching the inner protocol header from the address set; A processing module, configured to add a node diversion address corresponding to the target gateway node in the request message; A second sending module, configured to send the request message to a receiving end, wherein the splitter receives a reply message carrying the node diversion address from the receiving end; The second receiving module is further used to receive a reply message sent by the splitter based on the node diversion address; and, The second sending module is further used to send the reply message to the sending end.

18. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the method according to any one of claims 1 to 15 are implemented.

19. A computer-readable storage medium storing a computer program executable by a computer device, wherein when the program is run on the computer device, the computer device executes the steps of the method according to any one of claims 1 to 15.

20. A computer program product, comprising a computer program stored on a computer-readable storage medium, the computer program comprising program instructions, which, when executed by a computer device, cause the computer device to perform the steps of the method according to any one of claims 1 to 15.

Images