Session state synchronization method, device, system and storage medium

Abstract

Embodiments of the present application provide a session state synchronization method, device, system and storage medium. In the embodiments of the present application, for a service group containing multiple service nodes under a Serverless architecture, at least one flow management group is added between the service group and its corresponding service acceleration node, and a flow management node in the at least one flow management group is responsible for session state synchronization between the multiple service nodes in the service group, so that the service nodes are released from the topology awareness and session state synchronization tasks, and at the same time, the session states between the service nodes are kept synchronized.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a session state synchronization method, device, system and storage medium. Background Technology

[0002] With the development of serverless technology in the cloud computing field, more and more services in the cloud are being deployed using serverless architecture, such as Network Function Virtualization (NFV) network elements. In this way, NFV network elements do not need to be aware of the existence of servers and can obtain network, computing and storage resources on demand, with the characteristics of on-demand elasticity, availability redundancy and load balancing.

[0003] To avoid single points of failure and achieve disaster recovery, NFV network elements provide services externally in the form of service groups. NFV network elements within the same service group serve as backups for each other. For stateful NFV network elements, such as Network Address Translation (NAT) and Load Balancing (LB), topology awareness is required, and session state synchronization is performed based on the topology awareness results. In this way, if one NFV network element fails, other NFV network elements can continue to provide services based on the synchronized session state, achieving disaster recovery. However, in a serverless architecture, synchronizing session state between NFV network elements is a major challenge. Summary of the Invention

[0004] This application provides a method, device, system, and storage medium for synchronizing session state in a serverless architecture to achieve session state synchronization between service nodes.

[0005] This application provides a session state synchronization system, including: a service acceleration node corresponding to a target service group and at least one flow management group. The target service group includes multiple service nodes, and a flow management group includes at least one flow management node. The service acceleration node is used to send a message to be processed to the flow management node in the at least one flow management group. The message to be processed is a message that needs to be processed by the service nodes in the target service group. The flow management node in the at least one flow management group is used to send the message to be processed to a first service node in the target service group, so that the first service node can generate session state information of the message to be processed, receive the session state information returned by the first service node, and synchronize the session state information with other service nodes in the target service group.

[0006] This application also provides a session state synchronization method, applied to a first-level management node within a first-level management group. The method includes: receiving a pending message sent by a service acceleration node, wherein the pending message is a message that needs to be processed by a service node within a target service group; sending the pending message to a first service node within the target service group so that the first service node can generate session state information for the pending message; receiving the session state information returned by the first service node for the pending message, and synchronizing the session state information with other service nodes within the target service group.

[0007] This application also provides a session state synchronization method, applied to non-first-line management nodes within a first-line management group. The method includes: receiving session state information sent by the previous-line management node within the first-line management group, wherein the session state information is sent by the first service node within the target service group to the first-line management nodes within the first-line management group for a message to be processed; and synchronizing the session state information with other service nodes within the target service group when the non-first-line management node is a second-line management node; wherein, among the flow management nodes within the first-line management group, a chain relationship is formed starting from the first-line management node, and the second-line management node is a flow management node at a specific position in the chain relationship.

[0008] This application also provides a session state synchronization method applied to a third flow management node. The method includes: receiving a reverse flow table entry sent by a first flow management node in a first flow management group, wherein the reverse flow table entry is generated based on the inbound flow table entry corresponding to the message to be processed; receiving a reverse flow message of the message to be processed sent by a service acceleration node; and sending a reverse flow table entry to the service acceleration node based on the reverse flow message, so that the service acceleration node can accelerate the processing of the reverse flow message and its subsequent messages.

[0009] This application also provides a session state synchronization device, including: a memory and a processor; the memory for storing a computer program; and the processor, coupled to the memory, for executing the computer program to implement the steps in the session state synchronization method provided in this application.

[0010] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps in the session state synchronization method provided in this application.

[0011] In this embodiment of the application, for a service group containing multiple service nodes in a serverless architecture, at least one flow management group is added between the service group and its corresponding service acceleration node. The flow management node in the at least one flow management group is responsible for synchronizing the session state among the multiple service nodes in the service group, thereby freeing the service nodes from the tasks of topology awareness and session state synchronization, while keeping the session state of each service node synchronized.

[0012] Furthermore, since these service nodes store the same session state information, when one service node fails, other service nodes can continue to provide corresponding services to users based on the locally maintained session state information, thus achieving disaster recovery backup. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0014] Figure 1 A schematic diagram of the structure of a session state synchronization system based on chain-like packet passing provided for an exemplary embodiment of this application;

[0015] Figure 2 A schematic diagram of the structure of a session state synchronization system provided in an exemplary embodiment of this application;

[0016] Figure 3a A schematic diagram of the structure of a session state synchronization system provided as another exemplary embodiment of this application;

[0017] Figure 3b A schematic diagram of the structure of a session state synchronization system provided as another exemplary embodiment of this application;

[0018] Figure 4 A schematic diagram of the structure of a flow management node provided for an exemplary embodiment of this application;

[0019] Figure 5a A flowchart illustrating a session state synchronization method provided for an exemplary embodiment of this application;

[0020] Figure 5b A flowchart illustrating another session state synchronization method provided for an exemplary embodiment of this application;

[0021] Figure 5c A flowchart illustrating yet another session state synchronization method provided as an exemplary embodiment of this application;

[0022] Figure 6A schematic diagram of a session state synchronization device provided as another exemplary embodiment of this application;

[0023] Figure 7 A schematic diagram of the structure of a session state synchronization device provided as another exemplary embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0026] In a serverless architecture, to achieve disaster recovery, stateful NFV network elements within the same service group need to be topology-aware and synchronize session states based on the perceived topology. However, for NFV network elements, topology awareness and session state synchronization based on the perceived topology are quite difficult in a serverless architecture. To address this technical challenge, the following embodiments of this application provide several solutions. These solutions can be applied not only to NFV network elements but also to other cloud service instances that can provide a certain cloud service. In these embodiments, cloud service instances deployed using a serverless architecture and capable of providing a certain cloud service are collectively referred to as service nodes or service units. Furthermore, the solutions provided in these embodiments are primarily described for service nodes or service units employing fast / slow speed separation logic.

[0027] The use of fast / slow speed separation logic for service nodes or service units refers to offloading some or all of the functions implemented by the service nodes (e.g., functions with low change frequency, long iteration cycles, or general-purpose functions) to service acceleration nodes, which then provide acceleration services to the service nodes. The service acceleration nodes can be hardware or software acceleration modules, without limitation. Preferably, the service acceleration nodes can be implemented based on programmable hardware, such as application-specific integrated circuits (ASICs), system-on-chips (SoCs), field-programmable gate arrays (FPGAs), or complex programmable logic devices (CPLDs).

[0028] This application first presents a solution that requires NFV network elements to participate in the state synchronization process. For example... Figure 1 As shown in the diagram, taking NFV network elements implemented as Service Unit 1, Service Unit 2, and Service Unit 3 as an example, Service Unit 1, Service Unit 2, and Service Unit 3 have a chain relationship, such as Service Unit 1 -> Service Unit 2 -> Service Unit 3. The chain-like packet passing mode with messages is adopted. In this mode, the message that needs to be processed enters from the service acceleration node. If the service acceleration node cannot accelerate the processing of the message, based on the above chain relationship, the message is reported to Service Unit 1. Then, starting from Service Unit 1, it passes through Service Unit 2 and Service Unit 3 in sequence. Finally, Service Unit 3 gives the processing result of the message and returns the processing result to the service acceleration node. The service acceleration node processes the message according to the processing result and then sends it out.

[0029] exist Figure 1 In the chain-like packet passing mode shown, each service unit is linked together and can perceive its adjacent service units. Furthermore, packets need to pass through each service unit sequentially. After perceiving a packet, each service unit processes it and maintains the corresponding session state locally. The last service unit in the chain then feeds back the processing result to the service acceleration node, ensuring session state synchronization among the service units. Figure 1The proposed solution has the following problems: 1) The entire process is limited by the message size, resulting in limited synchronized content; 2) A single point of failure in any service unit will affect the availability of the system, leading to low availability. Therefore, it is challenging to directly involve service units in the state synchronization process while avoiding single points of failure. In other words, in a serverless architecture, synchronizing session state between service nodes within the same service group is a major challenge.

[0030] Based on the above, this application proposes another solution. In this solution, for a service group containing multiple service nodes in a Serverless architecture, at least one flow management group is added between the service group and its corresponding service acceleration node. The flow management node in the at least one flow management group is responsible for synchronizing the session state among the multiple service nodes in the service group. This frees the service nodes from topology awareness and session state synchronization tasks, allowing them to focus more on service functions. Simultaneously, it ensures that the session state of each service node remains synchronized, solving the state synchronization problem faced by service nodes within the same service group in a Serverless architecture. Furthermore, since these service nodes store the same session state information, when one service node fails, other service nodes can continue to provide services to users based on the locally maintained session state information, achieving disaster recovery.

[0031] The following describes in detail another solution provided by the embodiments of this application, with reference to the accompanying drawings.

[0032] Figure 2 This is a schematic diagram of the structure of a session state synchronization system provided for an exemplary embodiment of this application. For example... Figure 2 As shown, the system includes: a service acceleration node 10 corresponding to any service group 30 and at least one flow management group 20, wherein the number of service groups 30 can be one or more. Service groups 30 may belong to the session state synchronization system provided in this embodiment, or they may not belong to the session state synchronization system provided in this embodiment.

[0033] In this embodiment, each service group 30 corresponds to a service acceleration node 10 and at least one flow management group 20. Different service groups 30 may correspond to the same service acceleration node 10 or different service acceleration nodes 10, depending on the application requirements. Similarly, different service groups may correspond to the same flow management group 20 or different flow management groups 20. One service group 30 may correspond to one or more flow management groups 20, and one flow management group 20 may provide session state synchronization services for one or more service groups 30. The correspondence between service groups 30 and flow management groups 20 is not limited.

[0034] In this embodiment, each service group 30 includes multiple service nodes 301. Service nodes 301 are nodes that can provide cloud computing services; for example, service nodes can be stateful NFV network elements, such as NAT and LB elements. The service acceleration node 10, also known as the FastPath of service group 30, provides acceleration services to the service nodes within service group 30. That is, after a packet arrives at the service acceleration node, the service acceleration node can directly process the packet based on locally maintained session state information (such as some flow table entries) without reporting the packet to the service node. Each flow management group 20 includes at least one flow management node, which provides session state synchronization services to service group 30. That is, for a given session, it synchronizes session state information among the service nodes within the service group, enabling each service node to maintain the same session state information even without interaction regarding session state information. In this embodiment, the service acceleration node 10 is communicatively connected to at least one flow management node in flow management group 20, and at least one flow management node in flow management group 20 is communicatively connected to the service nodes in service group 30.

[0035] In this embodiment, a session refers to the information exchange process between network nodes. To complete information exchange, network nodes need to establish a temporary connection, or "session connection," between session layer entities according to certain rules. For example, a session connection can be a TCP connection, a UDP connection, or a QIUC connection, etc., without limitation. Once a session connection is established, the service acceleration node can maintain the session state information corresponding to that session connection and provide acceleration services to the service node based on the maintained session state information. However, in practical applications, the session state information of a session connection may change, or the service acceleration node may not have maintained the session state information corresponding to the session connection locally. In this case, the service acceleration node will be unable to provide acceleration services to the service node; that is, upon receiving a packet, it needs to report it to the service node for processing. Further, the service node processes the packet and generates session state information corresponding to the session connection to which the packet belongs. It then returns this session state information to the service acceleration node, which uses this session state information to accelerate the processing of the packet and subsequent packets within that session connection.

[0036] Depending on the service node, the packet processing logic differs, and consequently, the session state information generated by the service node varies. For example, when the service node is implemented as a load balancer (LB) element, the LB element is responsible for providing load balancing services, and the session state information is load balancing-related information, including but not limited to load balancing algorithms or rules. When the service node is implemented as a NAT element, the NAT element is responsible for providing address translation services, and the session state information is address translation-related information, including but not limited to address translation rules or IP addresses before and after address translation. When the service node is implemented as a virtual switch, the virtual switch is responsible for packet forwarding, and the session state information is packet forwarding-related information, including but not limited to encryption algorithms, decryption algorithms, and forwarding flow tables.

[0037] In this model, service acceleration nodes are considered fast paths, while service nodes within a service group are considered slow paths. For disaster recovery, multiple service nodes within the same service group on the slow path are mutually backups of each other. Service nodes need to maintain synchronized session state information so that when one service node fails, other service nodes can continue to provide services based on the maintained session state information.

[0038] In this embodiment, a flow management node is added, and the flow management nodes are organized and managed in the form of flow management groups. The system in this embodiment has at least one flow management group, which provides session state synchronization services to at least one service group. The flow management nodes can be pre-grouped, and a corresponding flow management group can be pre-assigned to each service group. Each service group can have one or more flow management groups, and different service groups can have the same or different flow management groups. The grouping method of the flow management groups and the allocation method between service groups and flow management groups are not limited; illustrative examples can be found in the following embodiments. In this embodiment, for each service group 30, at least one flow management group 20 is added between the service group 30 and its corresponding service acceleration node 10. Each flow management group 20 includes at least one flow management node 201. Figure 2 The illustration uses multiple flow management nodes 201 as an example, but it is not limited to this. Flow management nodes 201 in at least one flow management group 20 are responsible for synchronizing the state among multiple service nodes in service group 30.

[0039] For any service group, the process of synchronizing session states among service nodes within that service group through a flow management node in at least one corresponding flow management group is the same or similar. In this embodiment, taking any service group as an example, for ease of description and distinction, this service group is referred to as the target service group. That is, the target service group in this embodiment can be any service group in the session state synchronization system. The target service group contains multiple service nodes, which implement the same or similar service functions, and disaster recovery backup can be achieved among the multiple service nodes. Here, "multiple" refers to two or more.

[0040] Specifically, in the fast / slow speed separation logic, the packet first arrives at the service acceleration node 10. The service acceleration node 10 determines whether it maintains the session state information corresponding to the packet locally. If it does, it can directly accelerate the packet processing based on the session state information. If it does not maintain the session state information, it needs to report the packet to the service node in the target service group for processing. In this embodiment, for ease of distinction and description, the packet that needs to be processed by the service node in the target service group is called the pending processing packet. The service acceleration node does not directly report the pending processing packet to the service node in the target service group, but instead sends the pending processing packet to at least one flow management node in a flow management group. The flow management node in the at least one flow management group then sends the pending processing packet to the first service node in the target service group, so that the first service node can generate the session state information corresponding to the pending processing packet. The session state information in this embodiment includes some information required for the service node or service acceleration node to process the packet, such as some flow table information. The first service node generates session state information for the message to be processed and sends the session state information to at least one flow management node in the flow management group; the flow management node in the at least one flow management group receives the session state information returned by the first service node and synchronizes the session state information with other service nodes in the target service group, thereby enabling the first service node to maintain the same session state information with other service nodes and realizing the synchronization of session state.

[0041] In this embodiment, it is not limited to which flow management nodes(s) within at least one flow management group provide session synchronization services to the service nodes in the target service group. In an optional embodiment, the service acceleration node can select a first flow management node from at least one flow management group and send the message to be processed to the first flow management node, wherein the first flow management node belongs to the first flow management group. Accordingly, the first flow management node can receive the message to be processed sent by the service acceleration node, and then provide session synchronization services to the service nodes in the target service group either by itself or by the first flow management node in cooperation with other flow management nodes within at least one flow management group. That is, the first flow management node sends the message to be processed to the first service node within the target service group so that the first service node can generate session state information corresponding to the message to be processed, receive the session state information returned by the first service node, and synchronize the session state information to other service nodes within the target service group. This can be performed by the first flow management node alone or by the first flow management node in cooperation with other flow management nodes within at least one flow management group. The implementation method of the service acceleration node selecting the first flow management node is not limited, and will be described in detail below.

[0042] In terms of how to select flow management nodes, you can directly select the first flow management node from at least one flow management group, and then use the flow management group to which the first flow management node belongs as the first flow management group. Alternatively, you can first select the first flow management group from at least one flow management group, and then select the first flow management node from within the first flow management group. Whether selecting the first flow management node or the first flow management group, certain selection strategies can be employed.

[0043] The method of selecting the first flow management node from at least one flow management group is the same as or similar to the implementation of selecting the first flow management node from the first flow management group. For simplicity, the following example illustrates the method of selecting the first flow management node. For instance, a flow management node can be randomly selected from the flow management nodes included in at least one flow management group, and this randomly selected flow management node is taken as the first flow management node. Another example is selecting the first flow management node based on a packet hash algorithm. Specifically, a 5-tuple is obtained from the packet to be processed, a hash calculation is performed on the 5-tuple to obtain the corresponding key, and based on the pre-maintained association between the key and the flow management node, the flow management node associated with the key corresponding to the 5-tuple is taken as the first flow management node. Yet another example is selecting the first flow management node based on the resource usage status of each flow management node. For instance, the first flow management node can be selected from flow management nodes whose load is less than a load threshold (i.e., light load), network latency is less than a set latency threshold (i.e., low network latency), or bandwidth is greater than a set bandwidth threshold (i.e., sufficient bandwidth resources).

[0044] One implementation method for selecting the first flow management group from at least one flow management group is as follows: For example, the first flow management group can be randomly selected from at least one flow management group; another example is that the first flow management group can be selected based on the resource usage status of each flow management group, for example, the first flow management group can be selected from flow management groups whose overall load is less than a specific load threshold, whose overall network latency is less than a set latency threshold, or whose overall bandwidth is greater than a set bandwidth threshold; yet another example is that the flow management group with a larger number of nodes, whose address location is closer to the target service group, or whose network transmission distance is shorter can be selected as the first flow management group based on information such as the number of flow management nodes contained in each flow management group, geographical location, and network transmission distance.

[0045] In this embodiment, the actions that a flow management node in at least one flow management group needs to perform to provide session state synchronization services to service nodes in a target service group are divided into two categories according to their functions. The first category, action A1, involves sending the message to be processed to the first service node and receiving the session state information returned by the first service node for the message to be processed; this is referred to as obtaining the session state information. The second category, action A2, involves synchronizing the session state information corresponding to the processed message with other service nodes in the target service group; this is referred to as synchronizing the session state information. This embodiment does not limit which flow management node(s) in at least one flow management group executes actions A1 and A2. The following provides an illustrative example of how a flow management node in at least one flow management group executes actions A1 and A2.

[0046] Example X1: Actions A1 and A2 are executed by different flow management nodes in multiple flow management groups.

[0047] For example, actions A1 and A2 are executed by flow management nodes in two flow management groups, b1 and b2. The flow management node in flow management group b1 is responsible for executing action A1 and synchronizing session state information to the flow management nodes in flow management group b2. The flow management nodes in flow management group b2 are then responsible for executing action A2. For instance, one flow management node in flow management group b1 can execute action A1; this node could be the first flow management node selected by the service acceleration node. This flow management node then synchronizes session state information to the flow management nodes in flow management group b2, and one or more flow management nodes in flow management group b2 execute action A2. In the case where multiple flow management nodes in flow management group b2 cooperate to execute action A2, for example, two flow management nodes execute action A2, namely flow management node B1 and flow management node B2. The number of other service nodes in the target service group, excluding the first service node, is three. Flow management node B1 synchronizes session state information for one of the service nodes, and flow management node B2 synchronizes session state information for the other two service nodes. In this example, two flow management groups, b1 and b2, are used as examples, but it is not limited to two flow management groups. It can also be that the flow management nodes in three or more flow management groups cooperate to complete actions A1 and A2.

[0048] Example X2: Actions A1 and A2 are executed by a flow management node in a flow management group.

[0049] For example, the service acceleration node can select the first-level management node. The first-level management node receives the pending message sent by the service acceleration node, sends the pending message to the first service node in the target service group, so that the first service node can generate the session state information corresponding to the pending message, receive the session state information returned by the first service node for the pending message, and synchronize the session state information with other service nodes in the target service group.

[0050] Example X3: Actions A1 and A2 are executed by multiple flow management nodes in a flow management group.

[0051] For example, a service acceleration node can select a first-level management node, which belongs to a first-level management group, which also includes a second-level management node. The first-level management node can cooperate with the second-level management node to provide session state synchronization services for service nodes within the target service group. That is, the two cooperate to send pending messages to the first service node within the target service group, receive session state information returned by the first service node for the pending messages, and synchronize the session state information with other service nodes within the target service group.

[0052] The implementation of the first-line management node and the second-line management node cooperating to send the message to be processed to the first service node in the target service group, receive the session state information returned by the first service node for the message to be processed, and synchronize the session state information to other service nodes in the target service group is not limited. An exemplary description follows.

[0053] Example Y1: The first-level management node sends the packets to be processed to the first service node within the target service group and receives the session state information returned by the first service node for the packets. The first-level management node directly synchronizes the session state information with the second-level management node, and the second-level management node synchronizes the session state information with other service nodes within the target service group. In this way, both the first and second-level management nodes within the first-level management group maintain the same session state information. Therefore, when the first-level management node fails, the second-level management node can continue to provide session state synchronization services to the target service group based on its locally maintained session state information, achieving a certain degree of disaster recovery. In this embodiment, the first-level management node can determine the second-level management node. For example, the second-level management node may be a pre-defined flow management node, or a selection method for the second-level management node may be pre-defined, and each flow management node stores this selection method. Based on this, the first-level management node can select the second-level management node from its own first-level management group according to the stored selection method. The selection method may be, but is not limited to, selecting a flow management node with a specific IP address, a load less than a set load threshold, or bandwidth resources greater than a set bandwidth threshold from other flow management nodes as the second-level management node.

[0054] Example Y2:The first-level management node sends the packets to be processed to the first service node within the target service group and receives the session state information returned by the first service node for the packets. The first-level management node also synchronizes the session state information with other flow management nodes within the first-level management group, including the second-level management node, which synchronizes the session state information with the other service nodes within the target service group. In this way, all flow management nodes within the first-level management group maintain the same session state information. Therefore, when a flow management node fails, the other flow management nodes can continue to provide session state synchronization services to the target service group based on their locally maintained session state information, achieving disaster recovery. In this embodiment, the first-level management node does not need to know which node is the second-level management node; other flow management nodes have the ability to determine whether they are the second-level management node. For example, each flow management node can maintain conditions or rules for determining whether it is the second-level management node, thereby determining its own status. In this embodiment, the second-level management node refers to the flow management node within the first-level management group responsible for synchronizing session state information with the other service nodes within the target service group. The conditions or rules for determining whether a node is a second-level flow management node may include, but are not limited to: whether it is a flow management node with a specific IP address, whether it is a flow management node with a load less than a set load threshold, whether it is a flow management node with bandwidth resources greater than a set bandwidth threshold, and whether it is a flow management node at a specific position in the chain relationship when flow management nodes form a chain relationship.

[0055] like Figure 3a As shown, the first service node is implemented as SD1, and the other service nodes are implemented as SD2. There can be multiple SD2 nodes. The first flow management node is implemented as FC1, and the other flow management nodes are implemented as FC2 and FC3. The second flow management node is implemented as FC3. Flow management node FC2 is referred to as the intermediate flow management node. Figure 3a This is merely an example and is not limited to. Furthermore, Figure 3aThe process includes steps 1-8. Step 1 involves the service acceleration node failing to directly process the packet to be processed, for example, if the flow table corresponding to a mismatch is not found, and reporting the packet to be processed to the first flow management node FC1 within the first flow management group. Step 2 involves the first flow management node FC1 reporting the packet to be processed to the first service node SD1 in the target service group. Step 3 involves the first service node processing the packet to be processed accordingly and generating session state information. Step 4 involves the first service node SD1 synchronizing the session state information to the first flow management node FC1. Step 5 involves the first flow management node FC1 synchronizing the session state information to the service acceleration node. Step 6 involves the first flow management node FC1 synchronizing the session state information to the intermediate flow management node FC2. Step 7 involves the intermediate flow management node FC2 synchronizing the session state information to the second flow management node FC3. Step 8 involves the second flow management node FC3 synchronizing the session state information to the other service nodes SD2 in the target service group. It should be noted that the execution order of steps 5 and 6 is not limited; they can be executed sequentially or in parallel.

[0056] The implementation method for the first-flow management node to synchronize session state information with other flow management nodes in the first-flow management group is not limited, and the following is an example description.

[0057] Example Z1: The first-level management nodes synchronize session state information with other flow management nodes within the first-level management group. Combined with... Figure 3a As shown, the first flow management node FC1 directly synchronizes session state information to the flow management node FC2, and the first flow management node FC1 directly synchronizes session state information to the flow management node FC3, without needing to go through the flow management node FC2.

[0058] Example Z2: Within the first-level management group, multiple flow management nodes synchronize session state information in a chain-like sequence, starting from the first-level management node. For example... Figure 3a As shown, a chain relationship is formed between the first flow management node FC1, the intermediate flow management node FC2, and the second flow management node FC3. The implementation form of the chain relationship is not limited. For example, the chain relationship between multiple flow management nodes within the first flow management group is deterministic, i.e., the first node, the next node after the first node, the next node after the next node, and so on, until the tail node is determined, forming a linear chain relationship. The first flow management node can be any flow management node in this linear chain relationship, depending on the selection algorithm used for the service acceleration node; correspondingly, the second flow management node can be a flow management node located at a specific position in this chain relationship, such as the tail node, the first node, or a flow management node in a third position, etc.

[0059] For example, multiple flow management nodes within the first-flow management group form a circular chain relationship. The first and last nodes in the circular chain relationship are related to the selection of the first-flow management nodes. For example, in a circular chain relationship, there are three flow management nodes, identified by m1, m2, and m3 respectively. The circular chain relationship is represented as: m1 → m2 → m3 → m1. If the first flow management node is implemented as flow management node m1, then flow management node m1 is the head node, and flow management node m3 is the tail node. The session state information is synchronized starting from flow management node m1 in the chain relationship m1 → m2 → m3. If the first flow management node is implemented as flow management node m2, then flow management node m2 is the head node, and flow management node m1 is the tail node. The session state information is synchronized starting from flow management node m2 in the chain relationship m2 → m3 → m1. If the first flow management node is implemented as flow management node m3, then flow management node m3 is the head node, and flow management node m2 is the tail node. The session state information is synchronized starting from flow management node m3 in the chain relationship m3 → m1 → m2.

[0060] The second flow management node can be selected from the first flow management node, or it can be the last flow management node in the chain relationship, or it can be an intermediate node in the chain relationship. For example, the chain relationship includes 7 nodes, the first flow management node is the head node, the seventh flow management node is the tail node, and the other flow management nodes are intermediate nodes. The second flow management node can be any one of the intermediate nodes.

[0061] Regarding Example Y2 above, in addition to synchronizing session state information with other flow management nodes within the first flow management group, the first-flow management node can also synchronize pending messages to other flow management nodes. This ensures that all flow management nodes within the first flow management group maintain the same session state information and pending messages. Therefore, when the first-flow management node fails, other flow management nodes can continue to provide session state synchronization services to the target service group based on their locally maintained session state information and pending messages, achieving disaster recovery backup. Specifically, the first-flow management node synchronizes session state information and pending messages with other flow management nodes within the first flow management group. The method for synchronizing session state information can be referenced in Examples Z1 and Z2, and the implementation method for synchronizing pending messages is the same as or similar to that for synchronizing session state information, as described above. Synchronizing session state information and synchronizing pending messages can be achieved in the same communication process or in different communication processes. In this embodiment, when the second flow management node among the other flow management nodes receives the message to be processed and the session state information, it can synchronize the session state information with other service nodes in the target service group, and can also provide the message to be processed to other service nodes in the target service group.

[0062] In this embodiment, the presentation method of session state information is not limited. In an optional embodiment, session state information can be presented as flow table entries, which include a matching field (key) and an action. The matching field can be related to the message to be processed, for example, it can be information such as the 5-tuple or 3-tuple of the message to be processed, or it can be a hash calculation performed on the 5-tuple or 3-tuple, with the result of the hash calculation used as the matching field. The actions included in the session state information also vary depending on the type and function of the service node. For example, when the service node is implemented as an LB (Load Balancer) network element, the session state information is implemented as load balancing information. The actions included in the load balancing information could be rewriting the header of the packet to be processed and forwarding the packet to the corresponding network node. As another example, when the service node is implemented as a NAT (Network Address Translation) network element, the session state information is implemented as address translation information. The actions included in the address translation information could be converting the source address of the packet to be processed from an internal private network address to an external public network address. As yet another example, when the service node is implemented as a virtual switch, the session state information is implemented as packet processing information. The actions included in the packet processing information could be passing, discarding, encrypting, or decrypting.

[0063] A session connection contains two data streams, one for incoming and one for outgoing. For example, when a session connection is established between a first network node and a second network node, the data stream in which the first network node sends messages to the second network node based on the session connection is called the incoming stream, and the data stream in which the second network node returns messages to the first network node based on the session connection is called the outgoing stream.

[0064] Optionally, the session state information returned by the first service node for the packet to be processed may include inbound flow table entries, so that the service acceleration node can accelerate the processing of inbound flow packets. Based on this, the first flow management node can also send session state information (such as inbound flow table entries) to the service acceleration node, and the service acceleration node can accelerate the processing of the packet to be processed and its subsequent packets according to the inbound flow table entries, without reporting to the service node.

[0065] Optionally, considering session consistency technology, it is necessary to ensure that inbound and reverse flows are processed by the same service node. To guarantee session consistency, the first flow management node can generate reverse flow entries based on the inbound flow entries issued by the first service node and synchronize these reverse flow entries to the third flow management node. The third flow management node then provides the reverse flow entries to the service acceleration node on behalf of the first service node, eliminating the need to report the reverse flow packets corresponding to the pending packets back to the first service node. Since the reverse flow entries are generated based on the inbound flow entries provided by the first service node, it is equivalent to the reverse flow entries being provided by the first service node. Therefore, it can be considered that both inbound and reverse flows are processed by the first service node, ensuring session consistency while reducing the load on the first service node. The third flow management node refers to the flow management node selected by the service acceleration node to be responsible for reporting reverse flow packets. The implementation method for the first-flow management node to generate reverse flow entries based on inbound flow entries is not limited. For example, both inbound and reverse flow entries include matching fields and actions. The matching fields of the inbound flow entries correspond to the packets to be processed, and the matching fields of the reverse flow entries correspond to the reverse flow packets corresponding to the packets to be processed. Therefore, the matching fields of the reverse flow entries can be determined based on the matching fields of the inbound flow entries and the correspondence between the packets to be processed and the reverse flow packets. The actions of the reverse flow entries are adapted to the actions of the inbound flow entries. For example, if the action of the inbound flow entries is address translation, converting IP1 address to IP2 address, then the action of the reverse flow entries can be converting IP2 address to IP1 address.

[0066] Before synchronizing reverse flow table entries to the third flow management node, the first-flow management node needs to select a third flow management node. To ensure accurate selection, the first-flow management node can employ the flow management node selection algorithm used by the service acceleration node, simulating the service acceleration node selecting a third flow management node from at least one flow management group. Then, it synchronizes the reverse flow table entries to the third flow management node, enabling the third flow management node to provide reverse flow table entries to the service acceleration node when the service acceleration node receives the reverse flow packet corresponding to the packet to be processed.

[0067] Optionally, when the service acceleration node receives the reverse flow packet corresponding to the packet to be processed, it can use a flow management node selection algorithm to select a third flow management node from at least one flow management group and send the reverse flow packet to the third flow management node. Accordingly, the third flow management node receives the reverse flow packet and returns the reverse flow table entry corresponding to the reverse flow packet to the service acceleration node. Accordingly, the service acceleration node can accelerate the processing of the reverse flow packet and its subsequent packets based on the reverse flow table entry.

[0068] In this embodiment, the flow management group to which the third flow management node belongs is not limited; any flow management node within at least one flow management group corresponding to the target service group is acceptable. The third flow management node may belong to the same flow management group as the first flow management node, or the third flow management node and the first flow management node may belong to different flow management groups.

[0069] In an optional embodiment, in order to achieve disaster recovery backup of reverse flow table entries, the third flow management node can also synchronize the reverse flow table entries to other flow management nodes in its flow management group. In this way, when the third flow management node fails, other flow management nodes can continue to provide reverse flow table entries to the service acceleration node.

[0070] exist Figure 3b The diagram shows flow management d1 and flow management group d2. Flow management group d1 includes flow management nodes FC1, FC2, and FC4, FC5, and FC6. Figure 3b The example demonstrates nine steps: Step 1, the service acceleration node cannot directly accelerate the processing of the packet to be processed, for example, if the corresponding inbound flow table entry is not matched, and reports the packet to be processed to the first flow management node FC1; Step 2, the first flow management node FC1 reports the packet to be processed to the first service node SD1; Step 3, the first service node processes the packet to be processed accordingly and generates the corresponding inbound flow table entry for the packet to be processed; Step 4, the first service node SD1 synchronizes the inbound flow table entry to the first flow management node FC1; Step 5, the first flow management node FC1 synchronizes the inbound flow table entry to the service acceleration node; Step 6, the first flow management node FC1 generates... Step 7: The first flow management node FC1 sends the reverse flow table entry of the message to be processed to the third flow management node FC4; Step 8: The service acceleration node receives the reverse flow message corresponding to the message to be processed, but cannot directly accelerate the reverse flow message, for example, if no matching reverse flow table entry is found, it reports the reverse flow message to the third flow management node FC4; Step 9: The third flow management node FC4 provides the reverse flow table entry corresponding to the message to be processed to the service acceleration node; Step 10: The third flow management node FC4 synchronizes the reverse flow table entry to the flow management node FC5; Step 11: The flow management node FC5 synchronizes the reverse flow table entry to the flow management node FC6. Figure 3b In the process, the first flow management node FC1 will also synchronize session state information to the flow management node FC2, and the flow management node FC2 will also synchronize session state information to the flow management node FC3.

[0071] In an optional embodiment, the session state synchronization system of this embodiment further includes: a system management node, which manages the flow management nodes existing in the system, for example, responsible for dividing multiple flow management nodes in the system into at least one flow management group, maintaining the identifier, status, and other information of the flow management nodes in each flow management group; and assigning at least one corresponding flow management group to each service group, maintaining the correspondence between each service group and the flow management group. Furthermore, the system management node can also synchronize relevant control plane information between flow management nodes, service nodes, and service acceleration nodes, such as synchronizing the flow management node selection algorithm used by the corresponding service acceleration node to the flow management node.

[0072] The grouping method for dividing multiple flow management nodes in the system into at least one flow management group is not limited. For example, flow management nodes can be grouped based on their geographical location, resource quantity, or the number of nodes in a flow management group. Resource quantity can be computing resources such as CPUs or GPUs, storage resources such as memory and hard drives, or network resources such as bandwidth. For instance, flow management nodes with geographical locations less than a set distance threshold can be grouped into one flow management group. Alternatively, multiple flow management nodes can be grouped based on their resource quantity, with the goal of the total resource quantity of the flow management group meeting a set resource quantity condition. Another example is grouping multiple flow management nodes based on the goal of the number of nodes in the flow management group meeting a set number threshold, or randomly dividing multiple flow management nodes to obtain multiple flow management groups. Furthermore, grouping can be flexible according to application layer requirements. For instance, if the application layer requires the total resource quantity of a flow management group to be no less than 10 GPUs and 2TB of storage resources, then the flow management nodes in the flow management group can be determined based on the resource quantity of each flow management node, ensuring that the computing resources of each flow management node are greater than 10 GPUs and the storage resources are greater than 2TB.

[0073] It does not limit the allocation relationship and allocation method of assigning at least one corresponding flow management group to the target service group from multiple flow management groups.

[0074] For example, the number of flow management groups can be determined based on the number of service nodes in the target service group. For instance, a flow management node can be assigned to each service node in the target service group, and the flow management group to which the flow management node belongs can be considered as at least one flow management group assigned to the target service group. Alternatively, at least one flow management group can be randomly assigned to the target service group. Another example is assigning flow management groups based on user needs. For instance, users can submit requirements through the management interface, indicating their resource requirements or geographical location requirements for flow management groups. Accordingly, flow management groups can be assigned to the target service group based on these requirements. Yet another example is implementing the selection of flow management groups for service groups as a selection service. Users can view available flow management group specifications on the service page. Each flow management group specification corresponds to a service fee and a certain amount of resources. Then, the corresponding flow management group can be assigned to the target service group based on the flow management group specification selected by the user.

[0075] In one alternative embodiment, the implementation structure of the flow management node is not limited. Figure 4 An exemplary diagram illustrates the internal structure of a flow management node, such as... Figure 4 As shown, the flow management node 201 includes: a flow table management module 201a, a topology management module 201b, and an action preprocessing module 201c. The flow table management module 201a is mainly used to receive pending messages sent by service acceleration nodes, report pending messages to service nodes, receive session state information returned by pending messages, and synchronize session state information to the second or other flow management nodes. The topology management module 201b is mainly used to maintain the correspondence between the flow management group to which the flow management node belongs and the service group, maintain the connection relationship between each flow management node in the flow management group and the service nodes in the service group, maintain the correspondence between the flow management node and other flow management nodes in its flow management group, and also maintain the correspondence between the service group and the service acceleration node, so as to realize topology awareness of service nodes in the service group and topology awareness between flow management nodes in the flow management group. The action preprocessing module 201c is mainly used to generate reverse flow table entries based on incoming flow table entries and synchronize the reverse flow table entries to the third management node.

[0076] In this embodiment, the synchronization of session state information and the synchronization of reverse flow table entries can be carried by state synchronization messages different from those of the messages to be processed. However, the format of the state synchronization messages is not limited; it can be any message format capable of carrying session state information, reverse flow table entries, and other information. In an optional embodiment, when synchronizing session state or reverse flow table entries between the service acceleration node and the flow management node, between the flow management node and the service node, and between the flow management nodes, the Generic Network Virtualization Encapsulation (GENEVE) virtualization tunnel communication technology can be used, and some message formats are defined as shown in Tables 1-5 below.

[0077] Table 1. Session synchronization content based on GENEVE

[0078]

[0079] Table 2. Session Synchronization Based on GENEVE Inner Layer

[0080]

[0081] The message formats shown in Tables 1 and 2 are primarily used for synchronizing session state information and reversing flow table entries between flow management nodes. The difference between Tables 1 and 2 is that the message format in Table 1 transmits session state information, while the message format in Table 2 can not only transmit session state information but also carry messages to be processed simultaneously. For example, Figure 3a Steps 6 and 7 in the process, Figure 3b Steps 7, 10, and 11 can use the session synchronization message format in Table 1 or Table 2.

[0082] The message formats shown in Tables 1 and 2 contain three message fields (GENEVE OPTION):

[0083] 1. Class = 0x137, Type = 0x51 or Type = 0x52;

[0084] a. When Type = 0x51, it means that the state synchronization message includes: session state information, which is carried in the Session Action Body field (which can be referred to as session content) in Table 1 and Table 2;

[0085] b. When Type = 0x52, it indicates that the state synchronization message includes: session state information and pending message, wherein the pending message can be encapsulated in the GENEVE inner payload field.

[0086] 2. Class=0x137, Type=0x02 indicates that it carries the metadata of the state synchronization message, that is, the state synchronization message cache (cookie) on the flow management node (FC). This cache is provided to the service node by the flow management node when a mismatch is reported to the service node.

[0087] 3. Class=0x137, Type=0x66 indicates that the Session Action Body field is included.

[0088] It should be noted that the message formats shown in Tables 1 and 2 also include the following fields: V = 0, indicating that the version number is 0; Opt Len = *|O||C|, where Opt Len represents the length of the Variable Length Option; O indicates that this is an Operations Administration and Maintenance (OAM) packet; C indicates that there are one or more critical options in the Variable Length Option; Rsvd is a reserved field; Protocol Type; and VNI is the Virtual Network Identifier.

[0089] The Session Action Body field in the message formats shown in Tables 1 and 2 can adopt the format shown in Table 3 below, but is not limited to this.

[0090] Table 3. Format of Session Action Body

[0091]

[0092] The conversation action body field is divided into two parts: (ActType) = 0x71 represents the conversation content;

[0093] 1. The first part, Session Type (ActType) = 0x71 indicates the session content. ActType = 0x72 indicates that when the service node synchronizes session state information with the flow management node, the service node can modify the session content according to the message. ActLen is used to indicate the length of the session content, and ActBody indicates the specific session content to be modified.

[0094] 2. The second part, DataType, indicates the type of data to be modified. For example, whether the IP address to be modified is the source address or the destination address. DataOff indicates the content after modification, such as the modified source address or destination address.

[0095] The different values ​​for the DataType field indicate different objects that can be modified, and the length of the modified object will also vary. Below, we'll use modifying an IP address as an example, defining the DataType field as follows:

[0096] 1) DataType = 0x1: indicates that the Tunnel Src IPv4 (tunnel source IPv4 address) has been modified, with a length of 4 bytes;

[0097] 2) DataType = 0x2: indicates modification of Tunnel Dst IPv4 (tunnel destination IPv4 address), length 4 (bytes);

[0098] 3) DataType = 0x3: indicates that the Tunnel Src IPv6 (tunnel source IPv6 address) has been modified, with a length of 16 bytes;

[0099] 4) DataType = 0x4: This indicates that the Tunnel Dst IPv6 (tunnel destination IPv6 address) has been modified, with a length of 16 bytes.

[0100] Table 4 below shows the message format used by the flow management node to synchronize session state information with other service nodes in the target service group.

[0101] Table 4

[0102]

[0103] Table 5 below shows the messages used by the first-level management node to synchronize pending messages to the first service node. The difference between Table 5 and Table 2 is that Table 5 does not include the session action body field and its corresponding other fields. For explanations of the same fields, please refer to the above. In the message format shown in Table 5, the pending message is encapsulated in the Inner payload field.

[0104] Table 5

[0105]

[0106]

[0107] In addition to providing a system embodiment, this application also provides a session state synchronization method. The process of the session state synchronization method provided in this application embodiment will be described from the perspectives of the first-level management node, non-first-level management node and third-level management node in the first-level management group.

[0108] Figure 5a A session state synchronization method is provided for an example implementation of this application. This method is applied to the first-level management node within the first-level management group, such as... Figure 5a As shown, the method includes:

[0109] 501a. Receive pending messages sent by the service acceleration node. The pending messages are messages that need to be processed by the service nodes in the target service group.

[0110] 502a. Send the message to be processed to the first service node in the target service group so that the first service node can generate the session state information of the message to be processed.

[0111] 503a. Receive the session status information returned by the first service node for the message to be processed, and synchronize the session status information with other service nodes in the target service group.

[0112] In one optional embodiment, synchronizing session state information to other service nodes within the target service group includes: synchronizing session state information to a second-stream management node within the first-stream management group, so that the second-stream management node synchronizes session state information to other service nodes within the target service group.

[0113] In one optional embodiment, synchronizing session state information to a second flow management node within a first flow management group includes: synchronizing session state information between multiple flow management nodes within the first flow management group, starting from the first flow management node and proceeding sequentially in a chain relationship until the second flow management node, where the second flow management node is a flow management node at a specific position in the chain relationship.

[0114] In one optional embodiment, synchronizing session state information in a chain-like order from the first-level management node to the second-level management node includes: sending state synchronization messages to the next-level management node in a chain-like order from the first-level management node until the state synchronization message is sent to the second-level management node, wherein the state synchronization message contains at least session state information.

[0115] In an optional embodiment, the state synchronization message also includes a pending message.

[0116] In an optional embodiment, the session state information includes an inbound flow table entry corresponding to the message to be processed. The method provided in this application embodiment further includes: sending the inbound flow table entry to a service acceleration node so that the service acceleration node can accelerate the processing of the message to be processed and its subsequent messages according to the inbound flow table entry.

[0117] In an optional embodiment, the method provided in this application further includes: generating a reverse flow table entry based on an inbound flow table entry; simulating a service acceleration node selecting a third flow management node from at least one flow management group, wherein at least one flow management group includes a first flow management group; and synchronizing the reverse flow table entry to the third flow management node so that the third flow management node can provide the reverse flow table entry to the service acceleration node when the service acceleration node receives a reverse flow packet corresponding to the packet to be processed.

[0118] In one optional embodiment, the third flow management node and the first flow management node belong to the same flow management group, or the third flow management node and the first flow management node belong to different flow management groups.

[0119] Figure 5b Another session state synchronization method provided for an exemplary implementation of this application, which is applied to non-first-level management nodes within a first-level management group, such as... Figure 5b As shown, the method includes:

[0120] 501b. Receive session status information sent by the previous management node in the first-level management group. The session status information is sent by the first service node in the target service group to the first-level management node in the first-level management group for the message to be processed.

[0121] 502b. When the non-first-line management node is the second-line management node, synchronize session state information to other service nodes in the target service group; wherein, among the flow management nodes in the first-line management group, a chain relationship is formed starting from the first-line management node, and the second-line management node is the flow management node at a specific position in the chain relationship.

[0122] In an optional embodiment, the method provided in this application further includes: synchronizing session state information to the next-level management node when the non-first-level management node is not the second-level management node.

[0123] Figure 5c This application provides another session state synchronization method for an example implementation of the present application, which is applied to a third-stream management node, such as... Figure 5c As shown, the method includes:

[0124] 501c. Receive reverse flow table entries sent by the first-line management nodes within the first-line management group. The reverse flow table entries are generated based on the inbound flow table entries corresponding to the messages to be processed.

[0125] 502c, Reverse flow message of the pending message sent by the service acceleration node;

[0126] 503c. Send reverse flow table entries to the service acceleration node based on the reverse flow message, so that the service acceleration node can accelerate the processing of the reverse flow message and its subsequent messages.

[0127] In an optional embodiment, the method provided in this application further includes: synchronizing the reverse flow table entries to other flow management nodes within the flow management group where the third flow management node is located.

[0128] Regarding the embodiments provided in this application Figures 5a-5c The detailed implementation methods and beneficial effects of each step in the method shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0129] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 501a to 503a can be device A; or the execution subject of steps 501a and 502a can be device A, and the execution subject of step 503a can be device B; and so on.

[0130] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 501a, 502a, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0131] Figure 6 A schematic diagram of a session state synchronization device provided as an exemplary embodiment of this application is shown. This device corresponds to the first-stream management node within a first-stream management group, such as... Figure 6 As shown, the device includes a transceiver module 61 and a synchronization module 62.

[0132] The transceiver module 61 is used to receive pending messages sent by the service acceleration node. The pending messages are messages that need to be processed by the service nodes in the target service group.

[0133] The transceiver module 61 is also used to send the message to be processed to the first service node in the target service group so that the first service node can generate the session state information of the message to be processed, and to receive the session state information returned by the first service node for the message to be processed.

[0134] Synchronization module 62 is used to synchronize session state information with other service nodes within the target service group.

[0135] In an optional embodiment, the synchronization module 62 is specifically used to: synchronize session state information to the second-stream management node within the first-stream management group, so that the second-stream management node can synchronize session state information to other service nodes within the target service group.

[0136] In an optional embodiment, the synchronization module 62 is specifically used to: synchronize session state information between multiple flow management nodes in the first flow management group, starting from the first flow management node and proceeding in a chain-like order until the second flow management node, where the second flow management node is a flow management node at a specific position in the chain-like relationship.

[0137] In an optional embodiment, the synchronization module 62 is specifically used to: send state synchronization messages to the next first-level management node in a chain-like order starting from the first-level management node, until the state synchronization message is sent to the second-level management node, wherein the state synchronization message contains at least session state information.

[0138] In an optional embodiment, the state synchronization message also includes a pending message.

[0139] In an optional embodiment, the session state information includes an inbound flow table entry corresponding to the message to be processed. The transceiver module 61 is further configured to: send the inbound flow table entry to the service acceleration node so that the service acceleration node can accelerate the processing of the message to be processed and its subsequent messages according to the inbound flow table entry.

[0140] In an optional embodiment, the apparatus further includes a generation module and a selection module. The generation module is configured to generate reverse flow entries based on inbound flow entries; the selection module is configured to simulate a service acceleration node selecting a third flow management node from at least one flow management group, wherein at least one flow management group includes a first flow management group; the synchronization module is further configured to synchronize the reverse flow entries to the third flow management node, so that the third flow management node can provide the reverse flow entries to the service acceleration node when the service acceleration node receives the reverse flow message corresponding to the message to be processed.

[0141] In one optional embodiment, the third flow management node and the first flow management node belong to the same flow management group, or the third flow management node and the first flow management node belong to different flow management groups.

[0142] This application provides an exemplary embodiment of another session state synchronization device, which corresponds to a non-first-stream management node within a first-stream management group. The structure of this device is similar to... Figure 6 For identical or similar structures, please refer to [reference needed]. Figure 6 The apparatus shown.

[0143] The session state synchronization device provided in this embodiment includes a transceiver module and a synchronization module. The transceiver module receives session state information sent by the previous-level management node within the first-level management group. This session state information is sent by the first service node within the target service group to the first-level management nodes within the first-level management group for a message to be processed. The synchronization module synchronizes the session state information with other service nodes within the target service group when the non-first-level management node is a second-level management node.

[0144] In an optional embodiment, the synchronization module is further configured to: synchronize session state information to the next-level management node when the non-first-level management node is not the second-level management node.

[0145] This application provides another session state synchronization device in an exemplary embodiment, the device corresponding to a third stream management node, the structure of which is similar to... Figure 6 For identical or similar structures, please refer to [reference needed]. Figure 6 The apparatus shown.

[0146] The session state synchronization device provided in this embodiment includes a transceiver module and a synchronization module. The transceiver module receives reverse flow table entries sent by the first-flow management node within the first-flow management group. These reverse flow table entries are generated based on the inbound flow table entries corresponding to the packets to be processed. The transceiver module also receives reverse flow packets of the packets to be processed sent by the service acceleration node. The synchronization module sends reverse flow table entries to the service acceleration node based on the reverse flow packets, enabling the service acceleration node to accelerate the processing of the reverse flow packets and their subsequent packets.

[0147] In an optional embodiment, the synchronization module is further configured to synchronize reverse flow entries to other flow management nodes within the flow management group where the third flow management node is located.

[0148] Figure 7 A schematic diagram of a session state synchronization device provided as an exemplary embodiment of this application is shown. This device is implemented as a first-stream management node within a first-stream management group, such as... Figure 7 As shown, the device includes a memory 74 and a processor 75.

[0149] Memory 74 is used to store computer programs and can be configured to store various other data to support operation on the session state synchronization device. Examples of this data include instructions for any application or method used to operate on the session state synchronization device.

[0150] The processor 75, coupled to the memory 74, is used to execute a computer program in the memory 74 for: receiving a message to be processed sent by a service acceleration node, the message to be processed being a message that needs to be processed by a service node within the target service group; sending the message to be processed to a first service node within the target service group so that the first service node can generate session state information for the message to be processed, and receiving session state information returned by the first service node for the message to be processed; and synchronizing session state information with other service nodes within the target service group.

[0151] In an optional embodiment, when the processor 75 synchronizes session state information with other service nodes in the target service group, it is specifically used to: synchronize session state information with the second-stream management node in the first-stream management group, so that the second-stream management node synchronizes session state information with other service nodes in the target service group.

[0152] In an optional embodiment, when the processor 75 synchronizes session state information to the second stream management node within the first stream management group, it specifically performs the following: among multiple stream management nodes within the first stream management group, the session state information is synchronized sequentially in a chain relationship, starting from the first stream management node and continuing to the second stream management node, where the second stream management node is a stream management node at a specific position in the chain relationship.

[0153] In an optional embodiment, when the processor 75 synchronizes session state information in a chain-like order starting from the first-level management node until the second-level management node, it specifically performs the following: starting from the first-level management node, it sends state synchronization messages to the next-level management node in a chain-like order until the state synchronization messages are sent to the second-level management node, wherein the state synchronization messages contain at least session state information.

[0154] In an optional embodiment, the state synchronization message also includes a pending message.

[0155] In an optional embodiment, the session state information includes an inbound flow table entry corresponding to the message to be processed, and the processor 75 is further configured to: send the inbound flow table entry to the service acceleration node so that the service acceleration node can accelerate the processing of the message to be processed and its subsequent messages according to the inbound flow table entry.

[0156] In an optional embodiment, the processor 75 is further configured to: generate a reverse flow table entry based on the inbound flow table entry; and simulate a service acceleration node selecting a third flow management node from at least one flow management group, wherein the at least one flow management group includes the first flow management group;

[0157] The reverse flow table entries are synchronized to the third-party flow management node so that the third-party flow management node can provide reverse flow table entries to the service acceleration node when the service acceleration node receives the reverse flow message corresponding to the message to be processed.

[0158] In one optional embodiment, the third flow management node and the first flow management node belong to the same flow management group, or the third flow management node and the first flow management node belong to different flow management groups.

[0159] Furthermore, such as Figure 7 As shown, the session state synchronization device also includes other components such as a communication component 76, a display 77, a power supply component 78, and an audio component 79. Figure 7 The diagram only shows a portion of the components and does not imply that the session state synchronization device only includes... Figure 7 The components shown. Additionally... Figure 7 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the session state synchronization device. The session state synchronization device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the session state synchronization device in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 7 The components within the dashed box; if the session state synchronization device in this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include... Figure 7 The component within the dashed box.

[0160] This application embodiment also provides a session state synchronization device, which can be implemented as a non-first-level management node within a first-level management group. The implementation structure of this session state synchronization device is similar to... Figure 7 The implementation structure of the session state synchronization device shown is the same or similar, and can be referred to. Figure 7 The diagram illustrates the structural implementation of the session state synchronization device. The session state synchronization device provided in this embodiment is related to... Figure 7 The main difference between the session state synchronization devices in the illustrated embodiments lies in the different functions implemented by the computer programs stored in the memory executed by the processor. For the session state synchronization device provided in this embodiment, the computer programs executed by the processor can be used to: receive session state information sent by the previous management node within the first-level management group; the session state information is sent by the first service node within the target service group to the first-level management node within the first-level management group for the message to be processed; and synchronize session state information with other service nodes within the target service group when the non-first-level management node is the second-level management node.

[0161] In an optional embodiment, the processor is further configured to: synchronize session state information to the next-level management node when the non-first-level management node is not the second-level management node.

[0162] This application embodiment also provides a session state synchronization device, which can be implemented as a third-stream management node. The implementation structure of the session state synchronization device is similar to... Figure 7 The implementation structure of the session state synchronization device shown is the same or similar, and can be referred to. Figure 7 The diagram illustrates the structural implementation of the session state synchronization device. The session state synchronization device provided in this embodiment is related to... Figure 7 The main difference between the session state synchronization devices in the illustrated embodiments lies in the different functions implemented by the computer programs stored in the memory executed by the processor. For the session state synchronization device provided in this embodiment, the computer programs executed by the processor in the memory can be used to: receive reverse flow table entries sent by the first flow management node within the first flow management group, where the reverse flow table entries are generated based on the inbound flow table entries corresponding to the message to be processed; receive reverse flow messages of the message to be processed sent by the service acceleration node; and send reverse flow table entries to the service acceleration node based on the reverse flow messages, so that the service acceleration node can accelerate the processing of the reverse flow messages and their subsequent messages.

[0163] In an optional embodiment, the processor is further configured to: synchronize reverse flow table entries to other flow management nodes within the flow management group where the third flow management node is located.

[0164] The detailed implementation methods and beneficial effects of the session state synchronization device provided in this application have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0165] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can perform the above-described functions. Figures 5a-5c The steps shown in the method embodiment can be performed by the session state synchronization device.

[0166] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0167] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0168] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0169] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0170] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

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

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

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

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

[0175] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0176] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0177] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0178] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0179] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A session state synchronization system, characterized in that, include: A service acceleration node corresponding to a target service group and at least one flow management group, wherein the target service group includes multiple service nodes and a flow management group includes at least one flow management node; The service acceleration node is used to send the message to be processed to the flow management node in the at least one flow management group, and the message to be processed is a message that needs to be processed by the service node in the target service group. The flow management node in at least one flow management group is used to send the message to be processed to the first service node in the target service group, so that the first service node can generate session state information of the message to be processed, receive the session state information returned by the first service node, and synchronize the session state information to other service nodes in the target service group.

2. The system according to claim 1, characterized in that, The service acceleration node is specifically used to: select a first flow management node from the at least one flow management group, and send the message to be processed to the first flow management node, wherein the first flow management node belongs to the first flow management group.

3. The system according to claim 2, characterized in that, The first flow management node is configured to send the message to be processed to the first service node, receive session status information returned by the first service node, and synchronize the session status information to the second flow management node in the first flow management group, so that the second flow management node can synchronize the session status information to the other service nodes. The second flow management node is different from the first flow management node.

4. The system according to claim 3, characterized in that, When the first flow management node synchronizes the session state information to the second flow management node, it is specifically used to: synchronize the session state information between the flow management nodes in the first flow management group in a chain-like order starting from the first flow management node until the second flow management node, where the second flow management node is a flow management node at a specific position in the chain-like relationship.

5. The system according to any one of claims 1-4, characterized in that, The session state information includes: an inbound flow table entry corresponding to the message to be processed, and the first flow management node is further used for: A reverse flow table entry is generated based on the inbound flow table entry, and the service acceleration node is simulated to select a third flow management node from the at least one flow management group. The reverse flow table entry is synchronized to the third flow management node so that the third flow management node can provide the reverse flow table entry to the service acceleration node when the service acceleration node receives the reverse flow packet corresponding to the packet to be processed.

6. A session state synchronization method, characterized in that, The method, applied to first-level management nodes within a first-level management group, includes: Receive pending messages sent by service acceleration nodes, wherein the pending messages are messages that need to be processed by service nodes within the target service group; The message to be processed is sent to the first service node in the target service group so that the first service node can generate the session state information of the message to be processed. The system receives session status information returned by the first service node for the message to be processed, and synchronizes the session status information with other service nodes in the target service group.

7. The method according to claim 6, characterized in that, Synchronizing the session state information with other service nodes within the target service group includes: The session state information is synchronized to the second flow management node within the first flow management group, so that the second flow management node can synchronize the session state information to other service nodes within the target service group.

8. The method according to claim 7, characterized in that, Synchronizing the session state information to the second flow management node within the first flow management group includes: Among multiple flow management nodes in the first flow management group, the session state information is synchronized sequentially in a chain relationship, starting from the first flow management node and continuing to the second flow management node, where the second flow management node is a flow management node at a specific position in the chain relationship.

9. The method according to any one of claims 6-8, characterized in that, The session state information includes an inbound flow table entry corresponding to the message to be processed, and the method further includes: The incoming flow table entry is sent to the service acceleration node so that the service acceleration node can accelerate the processing of the packet to be processed and its subsequent packets according to the incoming flow table entry.

10. The method according to claim 9, characterized in that, Also includes: Generate reverse flow entries based on the inflow entries; The simulated service acceleration node selects a third flow management node from at least one flow management group corresponding to the target service group, wherein the at least one flow management group includes the first flow management group; The reverse flow table entry is synchronized to the third flow management node so that the third flow management node can provide the reverse flow table entry to the service acceleration node when the service acceleration node receives the reverse flow message corresponding to the message to be processed.

11. The method according to claim 10, characterized in that, The third flow management node belongs to the same flow management group as the first flow management node, or the third flow management node belongs to a different flow management group than the first flow management node.

12. A session state synchronization method, characterized in that, The method, applied to non-first-level management nodes within a first-level management group, includes: Receive session status information sent by the previous management node in the first-level management group. The session status information is sent by the first service node in the target service group to the first-level management node in the first-level management group for the message to be processed. If the non-first-line management node is a second-line management node, the session state information is synchronized to other service nodes within the target service group. Among them, a chain relationship is formed between the flow management nodes in the first flow management group, starting from the first flow management node, and the second flow management node is a flow management node at a specific position in the chain relationship.

13. The method according to claim 12, characterized in that, Also includes: If the non-first-level management node is not a second-level management node, the session state information is synchronized to the next-level management node.

14. A session state synchronization method, characterized in that, Applied to a third-stream management node, the method includes: Receive reverse flow table entries sent by the first-line management nodes within the first-line management group, wherein the reverse flow table entries are generated based on the inbound flow table entries corresponding to the messages to be processed; Receive the reverse flow message of the message to be processed sent by the service acceleration node; The reverse flow table entry is sent to the service acceleration node according to the reverse flow message, so that the service acceleration node can accelerate the processing of the reverse flow message and its subsequent messages.

15. A session state synchronization device, characterized in that, include: Memory and processor; The memory is used to store a computer program; the processor, coupled to the memory, is used to execute the computer program to implement the steps of the method according to any one of claims 6-11, 12-13 and 14.

16. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 6-11, 12-13 and 14.

Images