Vehicle-road cloud long connection communication method, device and system

Abstract

The invention provides a vehicle-road cloud long connection communication method, device and system, and the method comprises the steps: collecting the load conditions of a plurality of online servers in a connection service cluster, each online server being used for enabling a vehicle end device or a road side device to be connected with a cloud control service cluster through a long connection channel; calculating capacity expansion and contraction evaluation parameters according to the load conditions of the plurality of online servers; determining whether the capacity expansion and shrinkage evaluation parameter meets a preset capacity expansion and shrinkage triggering condition or not; if the preset capacity expansion and contraction triggering condition is met, executing a capacity expansion and contraction script corresponding to the preset capacity expansion and contraction triggering condition so as to determine a target server from the connection service cluster, and updating a load balancing pool according to the target server; the updated load balancing pool is used for carrying out load balancing on the online request from the vehicle end equipment or the road side equipment. Through an automatic capacity expansion and contraction mechanism, if a preset capacity expansion and contraction triggering condition is met, the load balancing pool is updated, and the problem of full allocation of server resources during vehicle on-line peak and valley is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle networking, and more particularly, to a vehicle-road-cloud long connection communication method, device and system. Background Art

[0002] Vehicle-road-cloud integration requires access to and integration of roadside data, vehicle-end data, and cloud data. Among them, various devices will report data to the cloud at a high frequency of 1-10 Hz as needed. In this process, a large amount of real-time data will be generated, and each type of data will have characteristics such as periodicity, security, real-time performance, and reliability. Therefore, this requires the server to have the capabilities of high real-time performance, high reliability, high security, dynamic scaling, and divide-and-conquer for data processing.

[0003] The existing long connection technology maintains a persistent communication channel between the client and the server. Through an optimized connection management strategy, a low-latency and efficient message push and data synchronization solution can be achieved. However, due to the high-speed movement and complex network environment, problems such as bandwidth occupation and server load are likely to occur, so it cannot meet the specific requirements of the vehicle-road-cloud integration field at the same time. Summary of the Invention

[0004] The purpose of the present invention is to provide a vehicle-road-cloud long connection communication method, device and system for the above-mentioned deficiencies in the existing technology, so as to update the load balancing pool through an automatic scaling mechanism if the preset scaling trigger condition is met, and solve the problem of full allocation of server resources during peak and trough periods of vehicle online.

[0005] To achieve the above purpose, the technical solutions adopted in the embodiments of the present application are as follows:

[0006] In a first aspect, an embodiment of the present application provides a vehicle-road-cloud long connection communication method, which is applied to a main server in a connection service cluster in a vehicle-road-cloud communication system. The method includes:

[0007] Collect the load conditions of multiple online servers in the connection service cluster, where each online server is used to enable vehicle-end devices or roadside devices to connect to the cloud control service cluster through a long connection channel;

[0008] Calculate a scaling evaluation parameter according to the load conditions of the multiple online servers;

[0009] Determine whether the scaling evaluation parameter meets a preset scaling trigger condition;

[0010] If the preset scaling trigger condition is satisfied, execute the scaling script corresponding to the preset scaling trigger condition to determine a target server from the connection service cluster, and update the load balancing pool according to the target server; the updated load balancing pool is used to perform load balancing on the online requests from vehicle-side devices or roadside devices.

[0011] In an alternative embodiment, the load condition includes: load parameters in at least one dimension; the calculating of the scaling evaluation parameter according to the load conditions of the multiple already online servers includes:

[0012] Calculate the scaling index for each dimension according to the load parameters of the multiple already online servers in each dimension;

[0013] Perform a weighted sum operation on the scaling indexes in the at least one dimension to obtain the scaling evaluation parameter.

[0014] In an alternative embodiment, the load parameters in the at least one dimension include: the number of long connections, the occupancy rate of processing resources, the occupancy rate of memory resources, the number of transactions processed per second, the number of queries per second, and network bandwidth;

[0015] Correspondingly, the scaling indexes in the at least one dimension include: long connection index, processing resource occupancy index, memory resource occupancy index, number of transactions processed per second index, number of queries per second index, and network bandwidth index.

[0016] In an alternative embodiment, the "if the preset scaling trigger condition is satisfied, execute the scaling script corresponding to the preset scaling trigger condition to determine a target server from the connection service cluster, and update the load balancing pool according to the target server" includes:

[0017] If the preset expansion trigger condition is satisfied, execute the preset expansion execution script to determine the target server from the idle servers in the connection service cluster;

[0018] Trigger the target server to start, so that after the target server finishes starting, send a registration request for the target server to a preset registration center, and the preset registration center adds the target server to the online server list according to the registration request. The reverse proxy server listens to the online server list and adds the target server to the load balancing pool of the reverse proxy server.

[0019] In an alternative embodiment, the "if the preset scaling trigger condition is satisfied, execute the scaling script corresponding to the preset scaling trigger condition to determine a target server from the connection service cluster, and update the load balancing pool according to the target server" includes:

[0020] If a preset capacity reduction trigger condition is satisfied, a preset capacity reduction execution script is executed to determine a first server and a second server from the connection service cluster as the target servers;

[0021] The first server sends a migration notice to each device connected to the first server. The migration notice includes information about the second server and information about the migration time window. The migration notice is used to cause each device to go offline from the first server and migrate and reconnect to the second server within the migration time window;

[0022] The first server sends a deregistration request for the first server to a preset registration center, so that the preset registration center deletes the first server from the online server list according to the deregistration request. A reverse proxy server listens to the online server list and deletes the first server from the load balancing pool of the reverse proxy server.

[0023] In an alternative embodiment, the first server is further configured to trigger a message compensation mechanism if it does not receive a migration response returned by at least one device or the received migration response does not meet a preset response condition, and the migration time window is missed, so as to store the migration notice in a preset message queue, so that each device obtains the migration notice from the preset message queue.

[0024] In an alternative embodiment, the migration notice is further used to cause each device to migrate both the connection context information and session data with the first server to the second server.

[0025] In an alternative embodiment, the long connection channel includes a first long connection channel and a second long connection channel. The first long connection channel is used to transmit the reported data of the vehicle terminal device or the roadside device, and the second long connection channel is used to transmit the data sent by the cloud control service cluster to the vehicle terminal device or the roadside device.

[0026] In a second aspect, an embodiment of the present application further provides a vehicle-road-cloud long connection communication device, which is applied to a main server in a connection service cluster in a vehicle-road-cloud communication system. The device includes:

[0027] An acquisition module, configured to acquire the load conditions of multiple already online servers in the connection service cluster, where each already online server is used to enable a vehicle terminal device or a roadside device to connect to a cloud control service cluster through a long connection channel;

[0028] A calculation module, configured to calculate a scaling evaluation parameter according to the load conditions of the multiple already online servers;

[0029] A determination module, configured to determine whether the scaling evaluation parameter meets a preset scaling trigger condition;

[0030] An execution module, configured to, if the preset scaling trigger condition is met, execute a scaling script corresponding to the preset scaling trigger condition to determine a target server from the connection service cluster, and update a load balancing pool according to the target server; the updated load balancing pool is used for load balancing of online requests from vehicle-side devices or roadside devices.

[0031] In a third aspect, an embodiment of the present application further provides a vehicle-road-cloud long-connection communication system, where the vehicle-road-cloud long-connection communication system includes: a proxy service cluster, a connection service cluster, a cloud control service cluster, and a preset registration center. The preset registration center is respectively connected to the proxy service cluster and the connection service cluster. The proxy service cluster includes: at least one reverse proxy server, and the connection service cluster includes: multiple servers. Each reverse proxy server is configured to connect a vehicle-side device or a roadside device to a corresponding server, and each server is configured to connect a cloud control server in the cloud control service cluster. Among the multiple servers, there is a primary server, and the primary server is configured to execute the method for vehicle-road-cloud long-connection communication according to any one of the first aspects above.

[0032] The beneficial effects of the present application are:

[0033] An embodiment of the present application provides a vehicle-road-cloud long-connection communication method, device, and system. The method includes: collecting the load conditions of multiple already-online servers in a connection service cluster, where each already-online server is configured to enable a vehicle-side device or a roadside device to connect to a cloud control service cluster through a long connection channel; calculating a scaling evaluation parameter according to the load conditions of the multiple already-online servers; determining whether the scaling evaluation parameter meets a preset scaling trigger condition; if the preset scaling trigger condition is met, executing a scaling script corresponding to the preset scaling trigger condition to determine a target server from the connection service cluster, and updating a load balancing pool according to the target server; the updated load balancing pool is used for load balancing of online requests from vehicle-side devices or roadside devices.

[0034] The method of the present application realizes the access of data of vehicle-side devices or roadside devices to the cloud, that is, the cloud control service cluster, in a long connection manner, solves the disadvantages of traditional short connections with low efficiency of one request and one response. In addition, through an automatic scaling mechanism, if a preset scaling trigger condition is met, the load balancing pool is updated, which solves the problem of full allocation of server resources during peak and trough periods of vehicle online access, significantly reduces the resource occupancy of the vehicle-road-cloud long-connection communication system, and improves the utilization rate of the vehicle-road-cloud long-connection communication system. Description of the Drawings

[0035] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present invention and should not be regarded as limiting the scope. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0036] Figure 1 Schematic diagram of a vehicle-road-cloud long connection communication system provided by an embodiment of the present application;

[0037] Figure 2 One of the schematic flowcharts of a vehicle-road-cloud long connection communication method provided by an embodiment of the present application;

[0038] Figure 3 Another schematic flowchart of a vehicle-road-cloud long connection communication method provided by an embodiment of the present application;

[0039] Figure 4 Another schematic flowchart of a vehicle-road-cloud long connection communication method provided by an embodiment of the present application;

[0040] Figure 5 Another schematic flowchart of a vehicle-road-cloud long connection communication method provided by an embodiment of the present application;

[0041] Figure 6 Schematic diagram of the functional modules of a vehicle-road-cloud long connection communication device provided by an embodiment of the present application. Detailed implementation manners

[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention.

[0043] Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the present application claimed, but merely represents the selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0044] In the description of the present application, it should be noted that if terms such as "upper", "lower", etc. are used to indicate the orientation or positional relationship, they are based on the orientation or positional relationship shown in the drawings, or the orientation or positional relationship in which the products of this application are usually placed during use. This is only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation to the present application.

[0045] In addition, terms such as "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances, so that the embodiments of the present invention described here can be implemented in an order other than those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0046] It should be noted that, without conflict, the features in the embodiments of the present application can be combined with each other.

[0047] In order to realize the sharing, collaborative perception and intelligent decision-making of traffic information through data interaction among vehicles (cars), roadside infrastructure (roads), and cloud platforms (clouds), the embodiments of the present application provide a possible implementation manner of a vehicle-road-cloud long-connection communication system. Figure 1 It is a schematic diagram of a vehicle-road-cloud long-connection communication system provided by the embodiments of the present application. As Figure 1 shown, the vehicle-road-cloud long-connection communication system includes: a proxy service cluster, a connection service cluster, a cloud control service cluster, and a preset registration center. Among them, the preset registration center is respectively connected to the proxy service cluster and the connection service cluster. The proxy service cluster includes: at least one reverse proxy server. The connection service cluster includes: multiple servers. Each reverse proxy server is used to connect a vehicle-end device or a roadside device and the corresponding server. Each server is used to connect a cloud control server in the cloud control service cluster. Among the multiple servers, there is a main server.

[0048] Among them, the long connection communication system can achieve stable and efficient long connection communication between vehicle-end devices (such as communication modules in vehicles), roadside devices (such as traffic monitoring base stations by the roadside, etc.) and the cloud control service cluster. Currently, the existing technology also provides a vehicle-road-cloud short connection communication system, which adopts a request-response mode and needs to establish a temporary connection before each communication. Although it is simple to implement, the frequent connection establishment and closing will cause relatively high latency. Therefore, compared with the short connection communication, the long connection of the vehicle-road-cloud long connection communication system of this application can maintain a persistent communication channel between the vehicle-end client, the roadside client and the server. Through the optimized connection management strategy, low-latency and efficient message push and data synchronization can be achieved.

[0049] The proxy service cluster includes at least one reverse proxy server. Each reverse proxy server acts as an intermediate bridge, responsible for connecting the vehicle-end device or the roadside device to the corresponding server. Each reverse proxy server receives requests from the vehicle-end device or the roadside device and forwards these requests to the corresponding server in the connection service cluster. At the same time, each reverse proxy server also receives the responses returned by the server and forwards them back to the vehicle-end device or the roadside device. In this way, the reverse proxy server hides the real architecture of the backend connection service cluster and provides a unified access interface externally, playing roles such as load balancing and security protection.

[0050] The cloud control service cluster receives the data uploaded by the vehicle-end device or the roadside device through the connection service cluster, and analyzes, processes and stores it. At the same time, it also generates corresponding instructions or data according to the business logic and issues them to the vehicle-end device or the roadside device through the connection service cluster to achieve remote monitoring and control of the vehicle or roadside facilities. For example, the cloud control service cluster can analyze the traffic congestion situation according to the location and speed information of multiple vehicles collected, and send detour suggestions to the relevant vehicles.

[0051] In addition, when the number of connected vehicles is huge and a large amount of real-time data floods into the vehicle-road-cloud long connection communication system, if only relying on a single server to process this data, its processing capacity will become a bottleneck, resulting in data processing latency and unable to meet the real-time requirements. Therefore, introducing a microservice cluster as a consumer group and using multiple server instances to process data in parallel can effectively improve the data processing efficiency and ensure the real-time response ability of the system.

[0052] Specifically, when the cloud control service cluster shakes hands or conducts the first communication with the connection service cluster, the cloud request needs to carry the service group name. The service group name is similar to a grouping identifier, which groups server instances that handle similar business logics or belong to the same type of function. For example, one group of servers is responsible for handling business related to vehicle location data, and another group is responsible for handling business related to vehicle fault diagnosis data. Different business groups correspond to different service group names, and at the same time, a unique ID within the service group is carried to uniquely identify each server instance within a specific service group. This helps to distinguish different servers within the group and ensure that data can be accurately distributed to the corresponding instances for processing.

[0053] Process massive data in units of service groups. This means that when massive real-time data floods into the vehicle-road-cloud long connection communication system, the data will be divided according to service groups. Data belonging to the same service group will be dispersed to each server instance within that service group. For example, for the service group that processes vehicle location data, real-time location data of different vehicles will be evenly distributed to multiple servers within that service group. By dispersing the data to each server instance within the same group, parallel processing is achieved. Multiple servers process the data simultaneously, greatly improving the overall data processing efficiency. Compared with a single server processing all data sequentially, parallel processing can significantly shorten the processing time and meet the timeliness requirements for processing massive real-time data. In addition, service instances within different service groups can process the same real-time data repeatedly. This is because different service groups have different business logics. For example, for a piece of real-time vehicle location data, one service group may use it to draw a real-time traffic flow map, while another service group may use it to analyze whether the vehicle's driving trajectory conforms to the specified route. Each service group independently processes the same data based on its own business needs to achieve its specific business goals.

[0054] The connection service cluster consists of multiple servers, including a primary server, and the remaining servers work in coordination with the primary server. The primary server is responsible for executing the methods of vehicle-road-cloud long connection communication. Other servers are mainly responsible for establishing long connection channels with vehicle-side devices or roadside devices, enabling vehicle-side devices or roadside devices to connect to the cloud control service cluster, and at the same time handling communication tasks related to these connections, such as data sending and receiving. For example, when a vehicle-side device connects to a certain server through a reverse proxy server, that server will maintain a long connection with the vehicle-side device to ensure that the vehicle-side device can report data to the cloud control service cluster in real time and receive data sent by the cloud control service cluster.

[0055] The preset registration center is used to maintain a list recording all online servers. When a registration request from a server is received, the server is added to the list of online servers. At this time, the reverse proxy server monitors the list of online servers. When it detects that a new server has been added to the list of online servers, the server is added to the load balancing pool. Similarly, when a deregistration request from a server is received, the server is deleted from the list of online servers. At this time, the reverse proxy server monitors the list of online servers. When it detects that a server has been deleted from the list of online servers, the server is also deleted from the load balancing pool.

[0056] In addition, when establishing a long connection between the vehicle-side device or roadside device and the cloud, it is necessary to verify the token during the handshake or the first communication to verify the legitimacy of the device or client and prevent unauthorized access. Specifically, the vehicle-side device or roadside device sends a request containing the token to the cloud, and the cloud verifies the validity of the token. If it is valid, the connection is established; otherwise, it is rejected, ensuring that only legitimate devices can access the cloud service and improving system security. After the long connection is established, the vehicle-side device or roadside device maintains the connection activity by periodically sending heartbeat messages and detects the connection status in a timely manner. Specifically, heartbeat messages are sent to the cloud at fixed intervals, and the cloud responds after receiving them. If the heartbeat or response is not received, the connection is considered abnormal and measures are taken to help the vehicle-road-cloud long connection communication system quickly discover and handle connection problems, ensuring high service availability.

[0057] When the vehicle-side device establishes a long connection with the cloud, it is called vehicle online. The number of vehicles online is jointly affected by various factors, such as the periodicity shown during peak commuting hours, the impact of bad weather, and the peak of entering and leaving the city during major holidays. In order to flexibly cope with the impact of the high and low changes in the number of vehicles online on the server pressure and make full use of server resources, the embodiment of the present application also provides a vehicle-road-cloud long connection communication method, which is applied to the main server in the connection service cluster of the vehicle-road-cloud communication system. Specifically, the main server collects the load conditions of multiple already online servers in the connection service cluster, calculates the scaling evaluation parameters to determine whether the preset scaling trigger conditions are met, and executes the corresponding scaling script when the conditions are met to determine the target server and update the load balancing pool. Through the automatic scaling mechanism, the problem of fully allocating server resources during peak and trough periods of vehicle online is solved.

[0058] Next, a vehicle-road-cloud long connection communication method provided by the embodiment of the present application will be explained in detail through specific examples with reference to the accompanying drawings. Figure 2 It is one of the flow diagrams of a vehicle-road-cloud long connection communication method provided by the embodiment of the present application; as Figure 2 shown, the method includes:

[0059] S101. Collect the load conditions of multiple online servers in the connection service cluster.

[0060] Among them, each online server is used to enable the vehicle terminal device or roadside device to connect to the cloud control service cluster through a long connection channel.

[0061] In this embodiment, each server in the connection service cluster is provided with a monitoring service, so each server can regularly collect the load conditions of its own server through the monitoring control.

[0062] Each online server undertakes the task of enabling the vehicle terminal device (such as the communication unit on the vehicle) or roadside device (such as the base station by the roadside, etc.) to connect to the cloud control service cluster through a long connection channel. The main server collects the load conditions of multiple online servers at the current moment through the monitoring component to comprehensively understand the operation status of the entire connection service cluster.

[0063] S102. Calculate the scaling evaluation parameter according to the load conditions of multiple online servers.

[0064] S103. Determine whether the scaling evaluation parameter meets the preset scaling trigger condition.

[0065] S104. If the preset scaling trigger condition is met, execute the scaling script corresponding to the preset scaling trigger condition to determine the target server from the connection service cluster and update the load balancing pool according to the target server.

[0066] Among them, the updated load balancing pool is used to perform load balancing on the online requests from the vehicle terminal device or roadside device.

[0067] Specifically, according to the load conditions of multiple online servers collected, calculate the scaling evaluation parameter, which is used to judge whether it is necessary to expand (add servers) or contract (reduce servers) at this time. Then the main server will judge whether the scaling evaluation parameter meets the preset scaling trigger condition. If it is met, execute the corresponding scaling script. If not, keep using the load balancing pool at the current moment, wait for the next moment to collect the load conditions of multiple online servers, calculate the scaling evaluation parameter, and judge whether it meets the preset scaling trigger condition.

[0068] If the scaling trigger condition is met, the main server will execute the corresponding scaling script, determine the target server from the connection service cluster, and update the load balancing pool according to the target server. The updated load balancing pool will be used to perform load balancing on the online requests from the vehicle terminal device or roadside device. For example, if it is determined that the expansion trigger condition is met, add the target server to the load balancing pool. If the contraction trigger condition is met, remove the target server from the load balancing pool.

[0069] In summary, the embodiment of the present application provides a vehicle-road-cloud long connection communication method, which includes: collecting the load conditions of multiple online servers in the connection service cluster, where each online server is used to enable vehicle-side devices or roadside devices to connect to the cloud control service cluster through a long connection channel; calculating scaling evaluation parameters according to the load conditions of the multiple online servers; determining whether the scaling evaluation parameters meet the preset scaling trigger conditions; if the preset scaling trigger conditions are met, executing the scaling script corresponding to the preset scaling trigger conditions to determine the target server from the connection service cluster, and updating the load balancing pool according to the target server; the updated load balancing pool is used to perform load balancing on the online requests from vehicle-side devices or roadside devices.

[0070] The method of the present application realizes the data of vehicle-side devices or roadside devices accessing the cloud, that is, the cloud control service cluster, in the form of long connections, solves the disadvantages of traditional short connections with low efficiency of one request and one response. In addition, through an automatic scaling mechanism, if the preset scaling trigger conditions are met, the load balancing pool is updated, which solves the problem of full allocation of server resources during peak and trough vehicle online periods, significantly reduces the resource occupancy of the vehicle-road-cloud long connection communication system, and improves the utilization rate of the vehicle-road-cloud long connection communication system.

[0071] Another possible implementation of the vehicle-road-cloud long connection communication method is also provided in the embodiment of the present application. The load condition includes: load parameters in at least one dimension. Figure 3 This is the second flow chart of the vehicle-road-cloud long connection communication method provided by the embodiment of the present application. As Figure 3 shown, calculating the scaling evaluation parameters according to the load conditions of multiple online servers includes:

[0072] S201. Calculate the scaling index for each dimension according to the load parameters of multiple online servers in each dimension.

[0073] S202. Perform a weighted sum operation on the scaling indexes in at least one dimension to obtain the scaling evaluation parameters.

[0074] In this embodiment, the load parameters in different dimensions are converted into parameters that can be used to measure the scaling requirements.

[0075] Optionally, the load parameters in at least one dimension include: the number of long connections, the occupancy rate of processing resources, the occupancy rate of memory resources, the number of transactions processed per second, the number of queries per second, and the network bandwidth; the corresponding scaling indexes in at least one dimension include: the long connection index, the processing resource occupancy index, the memory resource occupancy index, the number of transactions processed per second index, the number of queries per second index, and the network bandwidth index.

[0076] Among them, the number of transactions processed per second indicates the number of transactions that the server can complete per second. A transaction usually refers to a complete operation, such as a write or update to a database. The number of queries per second indicates the number of query requests that the server can process per second. A query usually refers to a read operation, such as a query to a database. The memory resource occupancy rate indicates the percentage of the total memory currently used by the server. The network bandwidth indicates the amount of data that the server can transmit in network communication, usually expressed in bits per second.

[0077] Taking the memory resource occupancy rate as an example, the memory resource occupancy metric is CPU avg The calculation formula is expressed as:

[0078]

[0079] Among them, CPU i represents the memory resource occupancy rate of the i-th server, and N represents the number of online servers.

[0080] If the scaling metrics calculated for at least one dimension include: the memory resource occupancy metric CPU avg 、the number of transactions processed per second metric TPS avg 、the number of queries per second metric QPS avg then perform a weighted sum operation on the scaling metrics for at least one dimension to obtain the scaling evaluation parameter, which is expressed as follows:

[0081] Score = w1 × CPU avg + w2 × TPS avg + w3 × QPS avg

[0082] Among them, the weights w1, w2, and w3 can be adjusted according to business requirements.

[0083] For each dimension's load parameter collected, calculate the corresponding scaling metric respectively. These metrics can more intuitively reflect the impact degree of the server load on each dimension for scaling. For example, the more long connections there are, it may mean greater server pressure, the corresponding long connection metric may be higher, and the need for scaling may be more urgent.

[0084] The impact degrees of the scaling metrics of different dimensions on the overall server load status may be different. Therefore, through the weighted sum operation, different weights are assigned to the scaling metrics of each dimension, and then they are added together to obtain the scaling evaluation parameter. For example, if the processing resource occupancy rate has a greater impact on the server performance, then the weight of its corresponding scaling metric may be set higher.

[0085] In the method provided by the embodiments of the present application, according to the load parameters of multiple online servers in each dimension, the scaling indicator for each dimension is calculated; a weighted sum operation is performed on the scaling indicators of at least one dimension to obtain a scaling evaluation parameter. This scaling evaluation parameter comprehensively considers the load conditions of multiple dimensions and can more comprehensively and accurately reflect whether the server needs to perform scaling operations.

[0086] The embodiments of the present application also provide another possible implementation manner of the vehicle-road-cloud long connection communication method. Figure 4 It is the third flowchart of a vehicle-road-cloud long connection communication method provided by the embodiments of the present application. As Figure 4 shown, if the preset scaling trigger condition is satisfied, the scaling script corresponding to the preset scaling trigger condition is executed to determine the target server from the connection service cluster, and the load balancing pool is updated according to the target server, including:

[0087] S301. If the preset expansion trigger condition is satisfied, execute the preset expansion execution script to determine the target server from the idle servers in the connection service cluster.

[0088] S302. Trigger the target server to start. After the target server starts up, send a registration request for the target server to the preset registration center. The preset registration center adds the target server to the online server list according to the registration request. The reverse proxy server listens to the online server list and adds the target server to the load balancing pool of the reverse proxy server.

[0089] In this embodiment, if the scaling evaluation parameter is greater than or equal to the first threshold, and the first threshold can be set to 75%, it is determined that the preset expansion trigger condition is satisfied, and expansion is immediately triggered or expansion is triggered continuously for more than the specified time. When the scaling evaluation parameter satisfies the preset expansion trigger condition, it means that the current load of the online servers is too heavy and server resources need to be increased. At this time, the main server executes the preset expansion execution script and selects one from the idle servers in the connection service cluster as the target server. These idle servers are prepared in advance and are in a standby state, ready to be put into use at any time to meet the business growth needs.

[0090] After determining the target server, the main server triggers its start. After the target server starts up, it will send a registration request, that is, a registration request, to the preset registration center Zookeeper. The preset registration center adds the target server to the online server list according to the registration request. The reverse proxy server listens to the online server list and adds the target server to the load balancing pool.

[0091] It should be noted that during the establishment of the long connection between the vehicle-side device or roadside device and the cloud server, the reverse proxy server relies on a load balancer (such as Nginx, HAProxy, or the load balancing service of the cloud platform) to achieve migration. When it comes to the scaling of servers, the load balancer needs to be adjusted accordingly to ensure the normal migration of device connections and the continuity of services. In addition, during the establishment of the long connection between the client and the server, the client may interact with the server in a series of ways, generating some session information, such as the user's login status, operation records, etc. To ensure that the client does not lose this session information during the server migration process, it is necessary to perform persistent processing on the session.

[0092] In the method provided by the embodiments of the present application, if a preset expansion trigger condition is met, a preset expansion execution script is executed to determine a target server from the idle servers in the connection service cluster; the target server is triggered to start, so that after the target server starts up, it sends a registration request for the target server to a preset registration center. The preset registration center adds the target server to the online server list according to the registration request. The reverse proxy server listens to the online server list and adds the target server to the load balancing pool of the reverse proxy server. The load balancing pool is responsible for reasonably allocating the online requests from the vehicle-side device or roadside device. The newly added target server also participates in the request processing from now on, thereby realizing the expansion of the entire connection service cluster and improving the system processing ability.

[0093] The embodiments of the present application also provide another possible implementation manner of the vehicle-road-cloud long connection communication method. Figure 5 It is the fourth flow chart of the vehicle-road-cloud long connection communication method provided by the embodiments of the present application. As Figure 5 shown, if a preset scaling trigger condition is met, a scaling script corresponding to the preset scaling trigger condition is executed to determine a target server from the connection service cluster and update the load balancing pool according to the target server, including:

[0094] S401. If a preset shrinking trigger condition is met, a preset shrinking execution script is executed to determine a first server and a second server in the connection service cluster as target servers.

[0095] S402. The first server sends a migration notice to each device connected to the first server.

[0096] Among them, the migration notice includes: information about the second server and information about the migration time window. The migration notice is used to make each device go offline from the first server and migrate and reconnect to the second server within the migration time window.

[0097] S403. Send a deregistration request for the first server to a preset registration center, so that the preset registration center deletes the first server from the online server list according to the deregistration request. The reverse proxy server monitors the online server list and deletes the first server from the load balancing pool of the reverse proxy server.

[0098] In this embodiment, if the scaling evaluation parameter is less than or equal to the second threshold, and the first threshold can be set to 35%, it is determined that the preset scaling trigger condition is met, and scaling is immediately triggered or scaling is triggered after exceeding the specified time. When the scaling evaluation parameter meets the preset scaling trigger condition, it indicates that the server resources in the current connection service cluster are relatively surplus, and scaling is required to improve resource utilization. The master server executes a preset scaling execution script and selects two servers from the connection service cluster, denoted as the first server and the second server respectively as the target servers. The selection of these two servers may be based on various factors, such as load conditions, the number of connected devices, etc.

[0099] After receiving the scaling instruction, the first server sends a migration notice to each vehicle-side device or roadside device it is connected to. The migration notice contains information about the second server (such as address, port, etc.) so that each device knows which server to migrate the data to; it also contains information about the migration time window, which stipulates the time period for the device to perform the migration operation. After receiving the notice, each device will take the initiative to go offline from the first server and try to reconnect to the second server within the specified migration time window. This can ensure that during the scaling process, the communication between the device and the cloud control service cluster can continue, minimizing the interference to the business.

[0100] When all the devices connected to the first server have successfully migrated to the second server, the first server sends a registration request, that is, a deregistration request, to the preset registration center. The preset registration center deletes the first server from the online server list according to the deregistration request. The reverse proxy server monitors the online server list and also deletes the first server from the load balancing pool.

[0101] Optionally, the first server is further configured to trigger a message compensation mechanism to store the migration notice in a preset message queue if it does not receive or the migration responses returned by at least one device do not meet the preset response conditions, and the migration time window is missed, so that each device can obtain the migration notice from the preset message queue.

[0102] Among them, after the first server sends a migration notice to each device, it will wait for the device to return a migration response. If the first server does not receive responses from some devices, or the received responses do not meet the preset conditions (such as response timeouts, response content not meeting requirements, etc.), and the migration time window has passed, at this time, the first server will trigger a message compensation mechanism. It stores the migration notice in a preset message queue, and the device can obtain the migration notice from this message queue and then perform the migration operation according to the notice requirements. This can avoid migration failures caused by some abnormal devices and ensure the smooth completion of the entire scaling-down process.

[0103] Specifically, when the client of each device fails to correctly respond to the migration notice and misses the migration time window, at this time, the client of each device disconnects the long connection with the server and triggers a will message. The server receives the will message and triggers the compensation mechanism.

[0104] For example, when the client of the device establishes a connection with the first server using TCP or other long connection protocols based on TCP, a reconnection retry mechanism in the abnormal disconnection state is set in the logical configuration. The client of the device will try to reconnect to the server. By trying to re-establish the connection multiple times, it ensures the continuity of communication as much as possible, and then delivers the migration notice to the client with the greatest ability.

[0105] If the long connection is established in the way of Message Queuing Telemetry Transport (MQTT), when establishing the connection, the server will subscribe to the unique will message topic corresponding to the client one by one. The will message in the MQTT protocol is a special mechanism. When the client establishes a connection with the server, the will message can be set. If the client is abnormally disconnected (such as sudden power failure, instantaneous network interruption, etc.), the server will receive the will message preset by the client and thus learn about the abnormal disconnection notice of the client. At the same time, the client will subscribe to a more general and common topic. The role of this general topic is to ensure that the client that has not been successfully migrated can receive the migration notice when reconnecting. When the client reconnects to the server due to various reasons after disconnecting, it can obtain the migration notice-related information through the subscribed general topic. For example, after the vehicle device reconnects to the server, it receives the migration notice through the subscribed general topic and then performs the migration operation according to the notice requirements. This mechanism ensures that even if the client has abnormal situations such as connection interruption during the migration process, it can still obtain the necessary migration information after reconnecting and continue to complete the migration process.

[0106] Then, the client of the device can query the migration notification from the preset message queue through the Web API interface designed based on the REST (Representational State Transfer) architectural style, so as to obtain the server address of the second server.

[0107] Optionally, the migration notification is also used to cause each device to migrate both the connection context information and session data with the first server to the second server.

[0108] Specifically, when each device receives the migration notification and performs the migration operation, it not only needs to reconnect to the second server, but also needs to migrate the connection context information with the first server (such as the time when the connection is established, the connection status, etc.) and session data (such as the ongoing business interaction data, etc.) to the second server together. In this way, when the device reconnects to the second server, it can continue the previous business operations as if no migration has occurred, ensuring that the business is not affected and improving the user experience.

[0109] In the method provided by the embodiment of the present application, if the preset shrinkage trigger condition is satisfied, a preset shrinkage execution script is executed to determine the first server and the second server as the target servers from the connection service cluster; a migration notification is sent to each device connected to the first server through the first server, and the migration notification includes: information of the second server and information of the migration time window, and the migration notification is used to cause each device to go offline from the first server and migrate and reconnect to the second server within the migration time window; a cancellation request for the first server is sent to the preset registration center through the first server, so that the preset registration center deletes the first server from the online server list according to the cancellation request, and the reverse proxy server listens to the online server list and deletes the first server from the load balancing pool of the reverse proxy server. At this time, when the load balancing pool allocates the online requests of the vehicle-mounted device or roadside device, it will no longer allocate the requests to the first server, thus completing the shrinkage operation of the connection service cluster and optimizing the resource configuration.

[0110] The embodiment of the present application also provides another possible implementation manner of the vehicle-road-cloud long connection communication method. The long connection channel includes: a first long connection channel and a second long connection channel. The first long connection channel is used to transmit the reported data of the vehicle-mounted device or roadside device, and the second long connection channel is used to transmit the data sent by the cloud control service cluster to the vehicle-mounted device or roadside device.

[0111] In this embodiment, in order to optimize data transmission between vehicle-end devices or roadside devices and the cloud control service cluster, the system sets up two long connection channels. The first long connection channel is specifically used to transmit data reported by vehicle-end devices or roadside devices to the cloud control service cluster, such as the real-time position of a vehicle, traffic flow information collected by roadside devices, etc. Among them, the first long connection channel adopts a low-latency configuration and ensures timeliness by immediately refreshing the data channel buffer.

[0112] The second long connection channel is responsible for transmitting data sent by the cloud control service cluster to vehicle-end devices or roadside devices, such as remote control instructions, road condition information push, etc. Among them, the second long connection channel adopts a high-reliability configuration. Taking TCP as an example, through the acknowledgment response mechanism, timeout retransmission mechanism, and connection management mechanism, delivery is ensured. Through this division of labor, data transmission can be made more orderly, data conflicts can be avoided, and the efficiency and reliability of the entire communication system can be improved.

[0113] The following continues to explain the vehicle-road-cloud long connection communication device provided in any of the above embodiments of the present application. Its specific implementation process and the resulting technical effects are the same as those in the corresponding method embodiments described above. For the sake of brief description, for the parts not mentioned in this embodiment, reference can be made to the corresponding content in the method embodiments.

[0114] Figure 6 It is a schematic diagram of the functional modules of a vehicle-road-cloud long connection communication device provided in an embodiment of the present application. As Figure 6 shown, it is applied to the main server in the connection service cluster of the vehicle-road-cloud communication system. The vehicle-road-cloud long connection communication device 100 includes:

[0115] An acquisition module 110, configured to acquire the load conditions of multiple online servers in the connection service cluster, where each online server is used to enable vehicle-end devices or roadside devices to connect to the cloud control service cluster using a long connection channel;

[0116] A calculation module 120, configured to calculate scaling evaluation parameters according to the load conditions of multiple online servers;

[0117] A determination module 130, configured to determine whether the scaling evaluation parameters meet a preset scaling trigger condition;

[0118] An execution module 140, configured to, if the preset scaling trigger condition is met, execute a scaling script corresponding to the preset scaling trigger condition to determine a target server from the connection service cluster and update the load balancing pool according to the target server; the updated load balancing pool is used to perform load balancing on the online requests from vehicle-end devices or roadside devices.

[0119] Optionally, the computing module 120 is further configured to calculate the scaling metrics for each dimension according to the load parameters of multiple online servers in each dimension; perform a weighted sum operation on the scaling metrics of at least one dimension to obtain a scaling evaluation parameter.

[0120] Optionally, the load parameters of at least one dimension include: the number of long connections, the occupancy rate of processing resources, the occupancy rate of memory resources, the number of transactions processed per second, the number of queries per second, and network bandwidth; the corresponding scaling metrics of at least one dimension include: long connection metrics, processing resource occupancy metrics, memory resource occupancy metrics, number of transactions processed per second metrics, number of queries per second metrics, and network bandwidth metrics.

[0121] Optionally, the execution module 140 is further configured to, if a preset expansion trigger condition is satisfied, execute a preset expansion execution script to determine a target server from the idle servers in the connection service cluster; trigger the target server to start, so that after the target server finishes starting, send a registration request for the target server to a preset registration center, and the preset registration center adds the target server to the online server list according to the registration request, and the reverse proxy server listens to the online server list and adds the target server to the load balancing pool of the reverse proxy server.

[0122] Optionally, the execution module 140 is further configured to, if a preset scaling-down trigger condition is satisfied, execute a preset scaling-down execution script to determine a first server and a second server as target servers from the connection service cluster; send a migration notice to each device connected to the first server through the first server, the migration notice includes: information about the second server and information about the migration time window, and the migration notice is used to enable each device to go offline from the first server and migrate and reconnect to the second server within the migration time window; send a deregistration request for the first server to a preset registration center through the first server, so that the preset registration center deletes the first server from the online server list according to the deregistration request, and the reverse proxy server listens to the online server list and deletes the first server from the load balancing pool of the reverse proxy server.

[0123] Optionally, the first server is further configured to trigger a message compensation mechanism to store the migration notice in a preset message queue if it does not receive or the migration responses returned by at least one device do not meet the preset response conditions, and the migration time window is missed, so that each device can obtain the migration notice from the preset message queue.

[0124] Optionally, the migration notice is further used to enable each device to migrate both the connection context information and session data with the first server to the second server.

[0125] Optionally, the long connection channel includes: a first long connection channel and a second long connection channel. The first long connection channel is used to transmit the reported data of the vehicle-side device or the roadside device, and the second long connection channel is used to transmit the data sent by the cloud control service cluster to the vehicle-side device or the roadside device.

[0126] The above device is used to execute the method provided in the foregoing embodiment, and its implementation principle and technical effect are similar, and will not be elaborated here.

[0127] The above modules may be one or more integrated circuits configured to implement the above method. For example: one or more application specific integrated circuits (ASICs), or, one or more microprocessors, or, one or more field programmable gate arrays (FPGAs), etc. Again, when the above module is implemented in the form of a processing element scheduling program code, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. Again, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0128] The above is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, and all of them should be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A vehicle-road-cloud long connection communication method, characterized in that Applied to the main server in the connection service cluster of the vehicle-road-cloud communication system, the method includes: Collect the load conditions of multiple online servers in the connection service cluster, where each online server is used to enable vehicle-side devices or roadside devices to connect to the cloud control service cluster using long connection channels; Calculate the scaling evaluation parameters based on the load conditions of the multiple online servers; Determine whether the scaling evaluation parameters meet the preset scaling trigger conditions; If the preset scaling trigger conditions are met, execute the scaling script corresponding to the preset scaling trigger conditions to determine the target server from the connection service cluster, and update the load balancing pool according to the target server; the updated load balancing pool is used to perform load balancing on the online requests from vehicle-side devices or roadside devices.

2. The method according to claim 1, wherein The load condition includes: load parameters in at least one dimension; the calculating the scaling evaluation parameters based on the load conditions of the multiple online servers includes: Calculate the scaling indicators for each dimension according to the load parameters of the multiple online servers in each dimension; Perform a weighted sum operation on the scaling indicators in the at least one dimension to obtain the scaling evaluation parameters.

3. The method according to claim 2, wherein The load parameters in the at least one dimension include: the number of long connections, the occupancy rate of processing resources, the occupancy rate of memory resources, the number of transactions processed per second, the number of queries per second, and network bandwidth; Correspondingly, the scaling indicators in the at least one dimension include: long connection indicators, processing resource occupancy indicators, memory resource occupancy indicators, number of transactions processed per second indicators, number of queries per second indicators, and network bandwidth indicators.

4. The method according to claim 1, wherein The "if the preset scaling trigger conditions are met, execute the scaling script corresponding to the preset scaling trigger conditions to determine the target server from the connection service cluster, and update the load balancing pool according to the target server" includes: If the preset expansion trigger conditions are met, execute the preset expansion execution script to determine the target server from the idle servers in the connection service cluster; Trigger the target server to start, so that after the target server finishes starting, send a registration request for the target server to the preset registration center, and the preset registration center adds the target server to the online server list according to the registration request. The reverse proxy server listens to the online server list and adds the target server to the load balancing pool of the reverse proxy server.

5. The method according to claim 1, characterized in that The "if the preset scaling trigger conditions are met, execute the scaling script corresponding to the preset scaling trigger conditions to determine the target server from the connection service cluster, and update the load balancing pool according to the target server" includes: If the preset scaling-down trigger conditions are met, execute the preset scaling-down execution script to determine the first server and the second server in the connection service cluster as the target servers; Send migration notifications to each device connected to the first server through the first server. The migration notifications include: information about the second server and information about the migration time window. The migration notifications are used to cause each device to go offline from the first server and migrate and reconnect to the second server within the migration time window. Send a deregistration request for the first server to a preset registration center through the first server, so that the preset registration center deletes the first server from the online server list according to the deregistration request. The reverse proxy server monitors the online server list and deletes the first server from the load balancing pool of the reverse proxy server.

6. The method according to claim 5, wherein The first server is further configured to trigger a message compensation mechanism if it does not receive a migration response returned by at least one device or the received migration response does not meet the preset response conditions, and the migration time window is missed. The message compensation mechanism is used to store the migration notifications in a preset message queue, so that each device can obtain the migration notifications from the preset message queue.

7. The method according to claim 5, characterized in that, The migration notifications are further used to cause each device to migrate the connection context information and session data with the first server to the second server.

8. The method according to claim 1, characterized in that, The long connection channel includes: a first long connection channel and a second long connection channel. The first long connection channel is used to transmit the reported data of the vehicle-side device or the roadside device, and the second long connection channel is used to transmit the data sent from the cloud control service cluster to the vehicle-side device or the roadside device.

9. A vehicle-road-cloud long-connection communication device, characterized in that, Applied to the primary server in the connection service cluster of the vehicle-road-cloud communication system, the device includes: An acquisition module, configured to acquire the load conditions of multiple online servers in the connection service cluster, where each online server is used to enable a vehicle-side device or a roadside device to connect to the cloud control service cluster using a long connection channel. A calculation module, configured to calculate a scaling evaluation parameter according to the load conditions of the multiple online servers. A determination module, configured to determine whether the scaling evaluation parameter meets a preset scaling trigger condition. An execution module, configured to execute a scaling script corresponding to the preset scaling trigger condition if the preset scaling trigger condition is met, to determine a target server from the connection service cluster and update the load balancing pool according to the target server. The updated load balancing pool is used to perform load balancing on the online requests from vehicle-side devices or roadside devices.

10. A vehicle-road-cloud long-connection communication system, characterized in that The vehicle-road-cloud long-connection communication system includes: a proxy service cluster, a connection service cluster, a cloud control service cluster, and a preset registration center. Among them, the preset registration center is respectively connected to the proxy service cluster and the connection service cluster. The proxy service cluster includes: at least one reverse proxy server. The connection service cluster includes: multiple servers. Each reverse proxy server is used to connect the vehicle-side device or the roadside device and the corresponding server. Each of the servers is used to connect to the cloud control server in the cloud control service cluster. Among the multiple servers, there is a main server, and the main server is used to execute the method of vehicle-road-cloud long-connection communication according to any one of claims 1-8 above.

Images