CN119299455A - A device and method for call transaction load balancing based on 5G new calls - Google Patents

Abstract

The invention relates to a device and a method for call transaction load balancing based on a 5G new call. The HTTP/2 response message forwarding method is characterized in that a configuration module processes configuration data, a load module receives an HTTP/2 request message sent by a user, the load module analyzes the HTTP/2 request message, obtains a transaction identifier and forwards the HTTP/2 request message to the upstream according to the transaction identifier, and forwards the upstream HTTP/2 response message to the user. The method and the device are mainly used for receiving HTTP/2 requests sent by users, and forwarding the requests to the upstream according to the transaction identifications in JSONPATH acquisition request messages, so that the problem that an open-source load balancer does not support transaction level load can be effectively solved.

Description

A device and method for call transaction load balancing based on 5G new calls

Technical Field

The present invention relates to a device and method for call transaction load balancing based on 5G new calls.

Background Art

The technical background of the present invention mainly revolves around the call transaction load balancing between 5G new call zones. Data between zones is not shared, and a call may contain multiple signaling messages. If signaling message 1 is sent to zone 1, and signaling message 2 is sent to zone 2, zone 2 cannot process it, which will eventually cause call abnormality. At present, open source load balancers such as Nginx do not support transaction-level load balancing, and can only perform message-level load balancing.

In view of the above problem, the present invention obtains the call identifier in the HTTP/2 request message through JSONPATH to associate the upstream, and forwards the signaling message with the same call identifier to the same upstream.

Summary of the invention

In view of the problems existing in the prior art, the purpose of the present invention is to provide a technical solution of a device and method for call transaction load balancing based on 5G new calls, so as to achieve call transaction load balancing between 5G new call areas.

The device for call transaction load balancing based on 5G new calls is characterized by comprising:

Configuration module: responsible for processing configuration data;

Load module: responsible for receiving the HTTP/2 request message sent by the user, then parsing the HTTP/2 request message, obtaining the transaction identifier and forwarding the HTTP/2 request message to the upstream according to the transaction identifier, and finally forwarding the upstream HTTP/2 response message to the user.

The method for call transaction load balancing based on 5G new calls is characterized in that it includes the following steps:

Step S101: The configuration module processes the configuration data;

Step S102: The load module receives the HTTP/2 request message sent by the user;

Step S103: the load module parses the HTTP/2 request message;

Step S104: the load module obtains the transaction identifier and forwards the HTTP/2 request message to the upstream according to the transaction identifier;

Step S105: The load module forwards the upstream HTTP/2 response message to the user.

The method for call transaction load balancing based on 5G new calls is characterized in that the specific implementation process of step S101 is as follows:

Step S1011, parsing the configuration file;

Configuration file parsing repeatedly obtains the configuration in the configuration file every 5 seconds, and generates transaction identifier acquisition strategy and HTTP/2 connection pool after parsing. The format of the configuration file is YAML.

Step S1012, the transaction identifier acquisition strategy is saved in the memory;

The transaction identity acquisition policy is obtained by processing the identityPolicies in the configuration file and stored in the memory as a List, with the value being a JSONPATH string.

Step S1013, creating an HTTP/2 connection object according to the upstream information;

HTTP/2 connection object refers to the object in the code of HTTP/2 session created by IP and port;

The upstream information is obtained by processing the upstreams in the configuration file. After obtaining all the upstream information, HTTP/2 connections are created and HTTP/2 connection objects are obtained.

Step S1014, the HTTP/2 connection object is saved to the connection pool;

The HTTP/2 connection pool obtains all HTTP/2 connection objects according to step S1013 and stores them in a HashMap in memory, wherein the key of the HashMap is the upstream information and the value is the HTTP/2 connection object;

Step S1015: The HTTP/2 connection pool is saved to the memory.

The method for call transaction load balancing based on 5G new calls is characterized in that in step S103, the load module parses the HTTP/2 request message. Parsing the HTTP/2 request message refers to obtaining the request body of the HTTP/2 request message, and then converting the request body into a JSON object. The JSON object refers to the object in the code after the JSON string is deserialized.

The method for call transaction load balancing based on 5G new calls is characterized in that in step S104, the load module obtains the transaction identifier according to the transaction identifier acquisition strategy, and implements load balancing according to the transaction identifier. The specific implementation process is as follows:

Step S1041, obtaining a transaction identifier according to a transaction identifier obtaining strategy;

Acquiring the transaction identifier according to the transaction identifier acquisition strategy refers to traversing the transaction identifier acquisition strategy in the memory to obtain the JSONPATH string, and then using the JSONPATH to match the JSON object obtained in step S103, if it matches, jumping out of the loop and returning the transaction identifier, if it does not match, continuing to traverse, if it does not match, then ending;

Step S1042, whether the transaction identifier is obtained, if not, proceed to step S1043, if yes, proceed to step S1044;

Step S1043, randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool;

Randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool means traversing the HTTP/2 connection pool in memory to obtain all upstream information, adding all upstream information to a List, randomly shuffling the List, obtaining the first upstream information in the List, and then obtaining the HTTP/2 connection object from the HTTP/2 connection pool in memory based on the upstream information;

Step S1044, obtaining the HTTP/2 connection object from the transaction cache using the transaction identifier as the primary key;

The transaction cache is stored in memory as a HashMap, where the key of the HashMap is the transaction identifier and the value is the HTTP/2 connection object;

Step S1045, whether the HTTP/2 connection object is obtained, if not, proceed to step S1046, if yes, proceed to step S1048;

Step S1046, randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool;

Step S1047, using the transaction identifier as the primary key and the HTTP/2 connection object as the value to save to the transaction cache;

Step S1048, forwarding the HTTP/2 request message to the corresponding upstream, where the corresponding upstream refers to the upstream corresponding to the upstream information obtained in step S1043;

Step S1049, receiving the upstream HTTP/2 response message.

The method for call transaction load balancing based on 5G new calls is characterized in that step S101 is independent of the call transaction request load process, and the main function of step S101 is to convert the configuration file into the data required for the execution of step S104. The call transaction request load process refers to step S102 in which the load module receives the HTTP/2 request message sent by the user.

The method for call transaction load balancing based on 5G new calls is characterized in that the configuration module in step S101 processes the configuration data, and the configuration data is processed to implement the configuration module for periodically obtaining the configuration in the configuration file, generating the transaction identifier acquisition strategy and HTTP/2 connection pool, and storing them in the memory of the device. The transaction identifier acquisition strategy and HTTP/2 connection pool data are both derived from the configuration file.

The method for call transaction load balancing based on 5G new calls is characterized in that the transaction identifier acquisition strategy is responsible for configuring a strategy for acquiring a transaction identifier from an HTTP/2 request message, and is obtained according to a configuration file;

The transaction identifier is a unique identifier of a call. A call includes multiple signaling messages and uses the transaction identifier to associate them.

The HTTP/2 connection pool is responsible for the management of the HTTP/2 connection pool and is created after the configuration file is processed to obtain all upstream information.

The method for call transaction load balancing based on 5G new calls is characterized in that the signaling message refers to a message used to control and manage communication sessions in a communication system.

The method for call transaction load balancing based on 5G new calls is characterized in that the upstream information refers to the URL for accessing the upstream.

The present invention obtains the call identifier in the HTTP/2 request message through JSONPATH to associate the upstream, and forwards the signaling message with the same call identifier to the same upstream.

The present invention revolves around the load balancing of call transactions between 5G new call areas. It obtains the call identifier in the HTTP/2 request message through JSONPATH to associate the upstream, and forwards the signaling messages with the same call identifier to the same upstream as the innovation point, thereby realizing the load balancing of call transactions between 5G new call areas.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a structural diagram of a load balancing device of the present invention;

Fig. 2 is a flow chart of the present invention;

FIG3 is a flow chart of the configuration module processing;

FIG4 is a flow chart showing the load module obtaining a transaction identifier and forwarding an HTTP/2 request message to an upstream according to the transaction identifier.

DETAILED DESCRIPTION

The present invention will be further described below in conjunction with the accompanying drawings:

The present invention provides a device and method for call transaction load balancing based on 5G new calls, which is mainly intended to solve the problem that the existing load balancer does not support forwarding signaling messages with the same call identifier to the same upstream.

In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

Embodiment 1

According to an embodiment of the present invention, a method for call transaction load balancing based on 5G new calls is provided. The method of the present invention is applied to the device for call transaction load balancing based on 5G new calls described in the present invention.

FIG2 is a flow chart of a method for call transaction load balancing based on 5G new calls provided in Embodiment 1 of the present invention. The method is applied to a device for call transaction load balancing based on 5G new calls.

The implementation method of the present invention is detailed in the following S101-S105, specifically:

Step S101: the configuration module processes the configuration data.

Step S101 is independent of the call transaction request load process, and its main function is to convert the configuration file into the data required for the execution of step S104.

The call transaction request load process refers to the process in which the load module receives the HTTP/2 request message sent by the user in step S102; the load module parses the HTTP/2 request message in step S103; the load module obtains the transaction identifier and forwards the HTTP/2 request message to the upstream according to the transaction identifier in step S104; and the load module forwards the upstream HTTP/2 response message to the user in step S105.

In this embodiment, the configuration data is processed and implemented in the configuration module for periodically obtaining the configuration in the configuration file, generating a transaction identifier acquisition strategy and an HTTP/2 connection pool, and then storing them in the memory of the device.

The transaction identifier acquisition strategy and HTTP/2 connection pool data are both derived from the configuration file.

The transaction identifier acquisition strategy is responsible for configuring the strategy for acquiring the transaction identifier from the HTTP/2 request message, which is obtained according to the configuration file.

A transaction identifier is a unique identifier of a call. A call contains multiple signaling messages and is associated using the transaction identifier.

Signaling messages refer to messages used in a communication system to control and manage communication sessions.

The HTTP/2 connection pool is responsible for the management of the HTTP/2 connection pool, which is created after the configuration file processes all upstream information.

Upstream information refers to the URL for accessing the upstream, such as https://10.0.0.10:8080.

The specific implementation process of step S101 is shown in FIG3 .

Step S1011, configuration file parsing:

Configuration file parsing repeatedly obtains the configuration in the configuration file every 5 seconds, and generates a transaction identifier acquisition strategy and HTTP/2 connection pool after parsing. The format of the configuration file is YAML.

Step S1012: The transaction identification acquisition strategy is saved to the memory:

The transaction identity acquisition policy is obtained by processing the identityPolicies in the configuration file and stored in the memory as a List, with the value being a JSONPATH string.

Step S1013, create an HTTP/2 connection object according to the upstream information:

The HTTP/2 connection object refers to the object in the code of the HTTP/2 session created by IP and port;

The upstream information is obtained by processing the upstreams in the configuration file. After obtaining all the upstream information, HTTP/2 connections are created and HTTP/2 connection objects are obtained.

Step S1014, the HTTP/2 connection object is saved to the connection pool:

The HTTP/2 connection pool obtains all HTTP/2 connection objects according to step S1013 and stores them in a HashMap in the memory, wherein the key of the HashMap is the upstream information and the value is the HTTP/2 connection object.

Step S1015: The HTTP/2 connection pool is saved to the memory.

Step S102: The load module receives an HTTP/2 request message sent by a user.

Step S103: the load module parses the HTTP/2 request message.

Parsing HTTP/2 request messages means obtaining the request body of HTTP/2 request messages and then converting the request body into a JSON object.

JSON object refers to the object in the code after the JSON string is deserialized.

Step S104: The load module obtains the transaction identifier and forwards the HTTP/2 request message to the upstream according to the transaction identifier.

Step S104: The load module obtains the transaction identifier according to the transaction identifier acquisition strategy, and implements load balancing according to the transaction identifier. The specific implementation process is shown in FIG4 :

Step S1041, obtaining a transaction identifier according to a transaction identifier obtaining strategy:

Acquiring the transaction identifier according to the transaction identifier acquisition strategy refers to traversing the transaction identifier acquisition strategy in the memory to obtain the JSONPATH string, and then using the JSONPATH to match the JSON object obtained in step S103, if it matches, jumping out of the loop and returning the transaction identifier, if it does not match, continuing to traverse, if it does not match, then ending;

Step S1042, whether the transaction identifier is obtained, if not, proceed to step S1043, if yes, proceed to step S1044;

Step S1043, randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool;

Randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool means traversing the HTTP/2 connection pool in memory to obtain all upstream information, adding all upstream information to a List, randomly shuffling the List, obtaining the first upstream information in the List, and then obtaining the HTTP/2 connection object from the HTTP/2 connection pool in memory based on the upstream information;

Step S1044, obtaining the HTTP/2 connection object from the transaction cache using the transaction identifier as the primary key;

The transaction cache is stored in memory as a HashMap, where the key of the HashMap is the transaction identifier and the value is the HTTP/2 connection object;

Step S1045, whether the HTTP/2 connection object is obtained, if not, proceed to step S1046, if yes, proceed to step S1048;

Step S1046, randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool; Step S1046 is the same as step S1043;

Step S1047, using the transaction identifier as the primary key and the HTTP/2 connection object as the value to save to the transaction cache;

Step S1048, forwarding the HTTP/2 request message to the corresponding upstream;

The corresponding upstream refers to the upstream corresponding to the upstream information obtained in step S1043;

Step S1049, receiving an upstream HTTP/2 response message;

Step S105: The load module forwards the upstream HTTP/2 response message to the user.

Embodiment 2

According to an embodiment of the present invention, a device for call transaction load balancing based on 5G new calls is provided, as shown in FIG1 , including a configuration module and a load module.

Configuration module: responsible for processing configuration data;

Load module: responsible for receiving the HTTP/2 request message sent by the user, parsing the HTTP/2 request message, obtaining the transaction identifier and forwarding the HTTP/2 request message to the upstream according to the transaction identifier, and finally forwarding the upstream HTTP/2 response message to the user.

The present invention supports load balancing at the call transaction level, and supports sending all signaling messages of the same call to the same upstream. Please refer to the description of the call transaction load request process in the first embodiment, and refer to steps S102 to S105.

Existing open source load balancers such as Nginx do not support transaction-level load balancing. They can only perform message-level load balancing and cannot send signaling messages of the same call to the same upstream. The device and method of the present invention are mainly used to receive HTTP/2 requests issued by users, and forward these requests to the upstream according to the transaction identifier in the request message obtained by JSONPATH, so as to send signaling messages of the same call to the same upstream, which can effectively solve the problem that open source load balancers do not support transaction-level load balancing.

Notes:

5G (fifth generation mobile communication technology) is the latest generation of mobile communication technology. Compared with the previous generation 4G (LTE), 5G provides faster data transmission speeds, lower latency and higher connection density. The design goal of 5G technology is to support future mobile communication needs, including the Internet of Things (IoT), augmented reality (AR), virtual reality (VR), autonomous driving and other applications.

YAML (YAML Ain’t Markup Language) is a human-readable data serialization format.

HashMap is a data structure that stores key-value pairs and enables fast data lookup by mapping keys to values.

JSON is a lightweight data exchange format, the full name is JavaScript Object Notation.

JSONPATH is a tool for parsing and querying JSON data, similar to XPath for XML. JsonPath allows extracting data from JSON documents through a concise syntax.

URL (Uniform Resource Locator) is an address used to locate resources on the Internet or other networks. It is a string in a specific format that contains the information needed to access resources. URLs are usually used to access various types of resources such as web pages, files, images, videos, etc.

List is a linear data structure used to store an ordered set of elements.

HTTP/2 (Hypertext Transfer Protocol version 2) is the second major version of the HTTP protocol.

IP (Internet Protocol) is the abbreviation of Internet Protocol. It is a network protocol on the Internet, used to transmit data packets in the network. The IP protocol defines the communication rules and address allocation method between network devices.

Claims (10)

1. A device for call transaction load balancing based on 5G new calls, characterized by comprising: Configuration module: responsible for processing configuration data; Load module: responsible for receiving the HTTP/2 request message sent by the user, then parsing the HTTP/2 request message, obtaining the transaction identifier and forwarding the HTTP/2 request message to the upstream according to the transaction identifier, and finally forwarding the upstream HTTP/2 response message to the user. 2. A method for call transaction load balancing based on 5G new calls, characterized in that it includes the following steps: Step S101: The configuration module processes the configuration data; Step S102: The load module receives the HTTP/2 request message sent by the user; Step S103: the load module parses the HTTP/2 request message; Step S104: the load module obtains the transaction identifier and forwards the HTTP/2 request message to the upstream according to the transaction identifier; Step S105: The load module forwards the upstream HTTP/2 response message to the user. 3. According to a method for call transaction load balancing based on 5G new calls according to claim 2, it is characterized in that the specific implementation process of step S101 is as follows: Step S1011, parsing the configuration file; Configuration file parsing repeatedly obtains the configuration in the configuration file every 5 seconds, and generates transaction identifier acquisition strategy and HTTP/2 connection pool after parsing. The format of the configuration file is YAML. Step S1012, the transaction identifier acquisition strategy is saved in the memory; The transaction identity acquisition policy is obtained by processing the identityPolicies in the configuration file and stored in the memory as a List, with the value being a JSONPATH string. Step S1013, creating an HTTP/2 connection object according to the upstream information; HTTP/2 connection object refers to the object in the code of HTTP/2 session created by IP and port; The upstream information is obtained by processing the upstreams in the configuration file. After obtaining all the upstream information, HTTP/2 connections are created and HTTP/2 connection objects are obtained. Step S1014, the HTTP/2 connection object is saved to the connection pool; The HTTP/2 connection pool obtains all HTTP/2 connection objects according to step S1013 and stores them in a HashMap in memory, wherein the key of the HashMap is the upstream information and the value is the HTTP/2 connection object; Step S1015: The HTTP/2 connection pool is saved to the memory. 4. According to a method for call transaction load balancing based on 5G new calls according to claim 2, it is characterized in that in the step S103, the load module parses the HTTP/2 request message, and parsing the HTTP/2 request message refers to obtaining the request body of the HTTP/2 request message, and then converting the request body into a JSON object, and the JSON object refers to the object in the code after the JSON string is deserialized. 5. According to a method for call transaction load balancing based on 5G new calls according to claim 2, it is characterized in that in step S104, the load module obtains the transaction identifier according to the transaction identifier acquisition strategy, and implements load balancing according to the transaction identifier, and the specific implementation process is as follows: Step S1041, obtaining a transaction identifier according to a transaction identifier obtaining strategy; Acquiring the transaction identifier according to the transaction identifier acquisition strategy refers to traversing the transaction identifier acquisition strategy in the memory to obtain the JSONPATH string, and then using the JSONPATH to match the JSON object obtained in step S103, if it matches, jumping out of the loop and returning the transaction identifier, if it does not match, continuing to traverse, if it does not match, then ending; Step S1042, whether the transaction identifier is obtained, if not, proceed to step S1043, if yes, proceed to step S1044; Step S1043, randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool; Randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool means traversing the HTTP/2 connection pool in memory to obtain all upstream information, adding all upstream information to a List, randomly shuffling the List, obtaining the first upstream information in the List, and then obtaining the HTTP/2 connection object from the HTTP/2 connection pool in memory based on the upstream information; Step S1044, obtaining the HTTP/2 connection object from the transaction cache using the transaction identifier as the primary key; The transaction cache is stored in memory as a HashMap, where the key of the HashMap is the transaction identifier and the value is the HTTP/2 connection object; Step S1045, whether the HTTP/2 connection object is obtained, if not, proceed to step S1046, if yes, proceed to step S1048; Step S1046, randomly obtaining an HTTP/2 connection object from the HTTP/2 connection pool; Step S1047, using the transaction identifier as the primary key and the HTTP/2 connection object as the value to save to the transaction cache; Step S1048, forwarding the HTTP/2 request message to the corresponding upstream, where the corresponding upstream refers to the upstream corresponding to the upstream information obtained in step S1043; Step S1049, receiving the upstream HTTP/2 response message. 6. According to claim 2, a method for call transaction load balancing based on 5G new calls is characterized in that step S101 is independent of the call transaction request load process, and the main function of step S101 is to convert the configuration file into the data required for the execution of step S104. The call transaction request load process refers to step S102 in which the load module receives the HTTP/2 request message sent by the user. 7. According to a method for call transaction load balancing based on 5G new calls according to claim 2, it is characterized in that the configuration module in step S101 processes the configuration data, and the configuration data is processed to implement the configuration module for periodically obtaining the configuration in the configuration file, generating the transaction identifier acquisition strategy and HTTP/2 connection pool, and storing them in the memory of the device, and the transaction identifier acquisition strategy and HTTP/2 connection pool data are both derived from the configuration file. 8. A method for call transaction load balancing based on 5G new calls according to claim 7, characterized in that the transaction identifier acquisition strategy is responsible for configuring a strategy for acquiring a transaction identifier from an HTTP/2 request message, and is obtained according to a configuration file; The transaction identifier is a unique identifier of a call. A call includes multiple signaling messages and uses the transaction identifier to associate them. The HTTP/2 connection pool is responsible for the management of the HTTP/2 connection pool and is created after the configuration file is processed to obtain all upstream information. 9. A method for call transaction load balancing based on 5G new calls according to claim 8, characterized in that the signaling message refers to a message used to control and manage communication sessions in a communication system. 10. A method for call transaction load balancing based on 5G new calls according to claim 8, characterized in that the upstream information refers to a URL for accessing the upstream.