Internet of vehicles architecture based on MQTT, service data processing method and medium

Abstract

The invention provides an Internet of Vehicles architecture based on MQTT, a business data processing method and a medium. The method comprises the following steps: receiving service data sent by a vehicle end through a load balancing cluster, carrying out load balancing on the service data, and sending the service data to servers in an MQTT cluster, thereby reducing the load of each server, ensuring the overall performance of the MQTT cluster, and improving the reliability of service data transmission; the server sends the received service data to the message-oriented middleware, and the message-oriented middleware stores the received service data, thereby realizing decoupling of the cloud and the MQTT cluster, improving the concurrency and throughput of the service data, and ensuring that the service data is not lost; and the cloud subscribes the service data of the corresponding theme from the message-oriented middleware so as to carry out service application and realize data intercommunication between the vehicle terminal and the cloud. According to the method, the performance of the Internet of Vehicles architecture is improved, reliable transmission of service data is guaranteed, and the method is particularly suitable for high-concurrency, high-throughput, complex and changeable scenes in the Internet of Vehicles.

Description

Technical Field

[0001] The present application relates to the field of vehicle networking technology, and in particular to a vehicle networking architecture based on MQTT, a business data processing method and a medium. Background Art

[0002] With the rapid development of intelligent network technology, the cloud platform, as the brain center of intelligent network, needs to solve the interconnection between vehicles, vehicles and roads, vehicles and networks, vehicles and clouds, vehicles and people, and realize comprehensive data collection and analysis for vehicles, roads, clouds, networks and people. In this scenario, the amount of data calculation is large, and the data transmission link requires low latency, low energy consumption and high availability. Traditional communication protocols such as Hypertext Transfer Protocol (Hypertext Transfer Protocol) , HTTP) cannot meet the above requirements at the same time. As the current standard protocol in the field of Internet of Things, Message Queuing Telemetry Transport (MQTT) provides a publish / subscribe message mode. MQTT has a streamlined and excellent protocol design, which can meet the requirements of low latency and low power consumption, and is suitable for vehicle systems with limited resources.

[0003] The characteristics of the Internet of Vehicles, such as fast movement, fast scene switching, and complex and changeable network conditions, put forward higher requirements for the application of the MQTT protocol on the vehicle side, cloud side, and server side. Therefore, it is particularly important to design a high-performance Internet of Vehicles architecture solution based on MQTT with high message transmission reliability. Summary of the invention

[0004] The present application provides an Internet of Vehicles architecture, a business data processing method and a medium based on MQTT, so as to improve the performance of the Internet of Vehicles architecture and ensure the reliable transmission of business data, which is particularly suitable for high concurrency, high throughput and complex and changeable scenarios in the Internet of Vehicles.

[0005] In the first aspect, the present application provides a vehicle networking architecture based on MQTT, including: a vehicle side, a cloud side, an MQTT cluster, a message middleware, and a load balancing cluster;

[0006] The load balancing cluster is used to receive the business data sent by the vehicle, load balance the business data, and then send the business data balanced to the server in the MQTT cluster;

[0007] The server is used to send received business data to the message middleware;

[0008] Message middleware, used to store received business data;

[0009] The cloud is used to subscribe to the business data of the corresponding topic from the message middleware for business applications.

[0010] In a possible implementation, the MQTT-based Internet of Vehicles architecture includes:

[0011] The indicator monitoring component is used to monitor the service status of the MQTT cluster and output abnormal alarm information when the service status is detected to be abnormal.

[0012] In a possible implementation, the server is further configured to send received business data to other servers in the MQTT cluster.

[0013] In a possible implementation, the MQTT-based Internet of Vehicles architecture further includes: a storage cluster for business data;

[0014] Correspondingly, the server is further used to: monitor whether the message middleware is offline; if it is monitored that the message middleware is offline, send the received business data to the storage cluster.

[0015] In a possible implementation, the server is further configured to monitor whether the message middleware is offline based on the heartbeat signal.

[0016] In one possible implementation, the load balancing cluster is specifically used to: load balance the received business data according to preset configuration rules, and send the business data balanced to the servers in the MQTT cluster, where the configuration rules include the minimum number of connections and / or the fastest response time.

[0017] In a second aspect, the present application provides a business data processing method, which is applied to the MQTT-based Internet of Vehicles architecture as described in any one of the first aspects, and the business data processing method includes:

[0018] The load balancing cluster receives the business data sent by the vehicle, performs load balancing on the business data, and then sends the business data balanced to the server in the MQTT cluster;

[0019] The server sends the received business data to the message middleware;

[0020] The message middleware stores the received business data;

[0021] The cloud subscribes to the business data of the corresponding topic from the message middleware for business applications.

[0022] In a possible implementation manner, the business data processing method further includes:

[0023] The indicator monitoring component monitors the service status of the MQTT cluster and outputs abnormal alarm information when the service status is detected to be abnormal.

[0024] In a third aspect, the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed, they are used to implement the above second aspect and / or various possible implementations of the second aspect.

[0025] In a fourth aspect, the present application provides a computer program product, including a computer program, which, when executed, implements the above second aspect and / or various possible implementations of the second aspect.

[0026] The MQTT-based Internet of Vehicles architecture, business data processing method and medium provided in the present application receive business data sent by the vehicle end through a load balancing cluster, and send the business data to the server in the MQTT cluster after load balancing, thereby reducing the load of each server, ensuring the overall performance of the MQTT cluster, and improving the reliability of business data transmission. Through cluster deployment, it not only prevents a single server from becoming a performance bottleneck, but also ensures uninterrupted service, further improving the availability and reliability of the Internet of Vehicles architecture; the server in the MQTT cluster sends the received business data to the message middleware, and the message middleware stores the received business data, thereby realizing the decoupling of the cloud and the MQTT cluster, reducing the pressure on the MQTT cluster, increasing the concurrency and throughput of business data, and improving the availability of the Internet of Vehicles architecture, thereby ensuring that business data is not lost; the cloud subscribes to the business data of the corresponding topic from the message middleware for business applications, thereby realizing data intercommunication between the vehicle end and the cloud. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0028] Figure 1 This is a diagram of the traditional architecture of the MQTT protocol;

[0029] Figure 2 A schematic diagram of an MQTT-based Internet of Vehicles architecture provided in one embodiment of the present application;

[0030] Figure 3 A flowchart of a business data processing method proposed in an embodiment of the present application;

[0031] Figure 4 This is a schematic diagram of an MQTT-based Internet of Vehicles architecture proposed in another embodiment of the present application.

[0032] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0033] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0034] First, the terms involved in this application are explained:

[0035] NGINX: A high-performance, versatile server software that can be used as a web server and reverse proxy server. In addition, NGINX can also be used as a load balancer to distribute requests from clients to multiple backend servers to ensure load balancing and performance optimization. NGINX is very suitable for IoT applications, as it can handle a large number of concurrent requests.

[0036] HAProxy: A free, fast and reliable load balancing software that distributes network connection requests from clients to multiple backend servers.

[0037] EMQX: A Complete , highly scalable, highly available distributed , but also supports / LwM2M One-stop IoT protocol access, EMQX natively supports a distributed cluster architecture consisting of multiple MQTT servers.

[0038] Rule Engine: refers to the SQL-based data processing component built into EMQX. When combined with data integration, it can achieve one-stop IoT data extraction, filtering, conversion, storage and processing without writing code, so as to accelerate application integration and business innovation.

[0039] MQTT: Message Queuing Telemetry Transport, as a highly specialized lightweight message transmission protocol, is designed for efficient communication between the Internet of Things (IoT), mobile applications and remote devices. MQTT is explained in detail in the following aspects:

[0040] 1. MQTT core features and advantages include:

[0041] Efficient and lightweight, MQTT significantly reduces network bandwidth usage and device energy consumption through a streamlined message structure (minimum 2 bytes), ensuring efficient data transmission.

[0042] Flexible publish / subscribe mode, which achieves complete decoupling between message senders and receivers, not only improving the scalability of the system, but also simplifying the complexity of the communication architecture.

[0043] Reliable message transmission guarantee. By providing three different levels of service quality (QoS 0, QoS 1, QoS 2), MQTT ensures the reliability of message delivery and meets various needs from non-critical to critical applications.

[0044] With a wide range of connection options, MQTT not only supports traditional TCP / IP connections, but is also compatible with emerging technologies such as TLS encrypted transmission and WebSocket, providing flexible options for diverse application scenarios.

[0045] A mature ecosystem with extensive and mature client libraries and server implementations, supporting multiple programming languages ​​and platforms, providing developers with rich resources and support.

[0046] 2. Key roles and mechanisms include:

[0047] MQTT Broker: As the core of the MQTT architecture, it is responsible for receiving messages from clients and intelligently routing them to corresponding subscribers based on the subject of the message, thus realizing centralized management and distribution of messages.

[0048] Publisher and Subscriber: As the sender and receiver of messages respectively, they interact with Broker through the MQTT protocol to achieve real-time transmission and sharing of information.

[0049] 3. The Topic mechanism includes:

[0050] MQTT uses a flexible hierarchical topic mechanism to identify and route messages. Subscribers can subscribe to topics in a fine-grained manner to receive information of interest. This mechanism greatly improves the accuracy and efficiency of message delivery.

[0051] Then, by Figure 1 The architecture of MQTT is further explained.

[0052] Figure 1 This is a diagram of the traditional architecture of the MQTT protocol. Figure 1 As shown in the figure, it includes: producers (publishers), brokers and consumers (subscribers). Based on this architecture, the transmission of messages is divided into three stages: production stage, storage stage and consumption stage. Among them:

[0053] Production phase: Messages are created at the producer and transmitted over the network to the broker.

[0054] Storage stage: The message is stored in the broker. If it is a cluster, the message will be copied to other replicas in the cluster.

[0055] Consumption phase: Consumers pull messages from brokers and transmit them to consumers over the network.

[0056] Based on the above MQTT architecture, the transmission of messages has the following reliability issues:

[0057] 1. Network transmission reliability issues, including producer to broker and broker to consumer.

[0058] 2. Reliability issues during storage and the reliability of the agent itself.

[0059] 3. The producer sends a large amount of data, and the consumer fails to process it in time, resulting in messages being discarded.

[0060] A highly available MQTT architecture is crucial to the field of Internet of Vehicles technology. The characteristics of the Internet of Vehicles, such as fast movement, fast scene switching, and complex and changeable network conditions, place higher requirements on the application of the MQTT protocol on the vehicle side, cloud side, and server side. Therefore, it is particularly important to design a high-performance MQTT architecture with high message transmission reliability to provide highly reliable guarantees for the integrity of the Internet of Vehicles business.

[0061] The MQTT-based Internet of Vehicles architecture, business data processing method and medium provided in the present application introduce a load balancing cluster and message middleware on the basis of the traditional MQTT architecture. The business data sent by the vehicle end is received through the load balancing cluster, and the received business data is load balanced before sending to the MQTT cluster, thereby ensuring that the resources of each server in the MQTT cluster are fully utilized and improving the performance and reliability of the MQTT cluster. The server in the MQTT cluster sends the received business data to the message middleware, and the received business data is stored through the message middleware. The cloud subscribes to the business data from the message middleware, thereby realizing the decoupling of the cloud and the MQTT cluster, and improving the concurrency and throughput of business data, thereby improving the performance of the Internet of Vehicles architecture and ensuring that business data is not lost.

[0062] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0063] Figure 2 The MQTT-based Internet of Vehicles architecture provided in one embodiment of the present application is as follows: Figure 2As shown in the figure, the MQTT-based Internet of Vehicles architecture includes: vehicle side, load balancing cluster, MQTT cluster, message middleware and cloud, among which:

[0064] The load balancing cluster is used to receive the business data sent by the vehicle, load balance the business data, and then send the business data balanced to the server in the MQTT cluster.

[0065] Among them, business data includes vehicle system data, vehicle user data, vehicle operation data, vehicle status data and environmental data collected by the vehicle.

[0066] The vehicle side can be regarded as the publisher of messages in the Internet of Vehicles architecture, and the business data is encapsulated in the message. It can be understood that the message consists of a header and a payload. The header contains the message type and control flag. The message types include PUBLISH, SUBSCRIBE, CONNECT, etc., and the QOS levels include QOS0, QOS1, QOS2; the payload is the actual content of the message. Depending on the message type, the payload content is also different. For example, the PUBLISH message contains the subject, message ID and message content. The message content is the business data described in this application, and the SUBSCRIBE message contains the subject filtering rules and QOS level.

[0067] For example, the vehicle sends a message with the subject "sensors / temperature" and the message content "temperature:28℃", where "temperature:28℃" is business data.

[0068] It should be noted that the message described in the embodiment of the present application includes business data.

[0069] For example, the vehicle establishes a connection with the load balancing cluster, the load balancing cluster receives messages published by the vehicle periodically or in real time, and distributes the messages to multiple servers in the MQTT cluster according to the load balancing strategy. Load balancing strategies such as polling strategy, weight strategy, least connection strategy, response time allocation strategy, etc. can be selected and used according to specific business needs and network environment to achieve the best load balancing effect, and the embodiments of this application are not specifically limited.

[0070] For example, the load balancing cluster can be a cluster that deploys NGINX service, HAProxy service or other load balancing service, and the MQTT cluster can be an EMQX cluster. Using NGINX to deploy load balancing and EMQX cluster can ensure high availability and scalability. Using NGINX to deploy load balancing and EMQX cluster has the following functions and advantages: (1) As a reverse proxy server, NGINX is located in the EMQX cluster, and initiates MQTT connection requests to the EMQX cluster on behalf of the vehicle, and processes the request on behalf of the EMQX cluster, and then returns the response of the EMQX cluster to the vehicle. Through such a setting, the EMQX cluster information is hidden, and a unified access address is provided to the vehicle. The vehicle only needs to communicate with NGINX without knowing the number and layout of EMQX clusters, thereby improving the maintainability and scalability of the Internet of Vehicles architecture. (2) NGINX can be used to terminate the SSL-encrypted MQTT connection between the vehicle and the EMQX cluster, reducing the encryption and decryption burden of the EMQX cluster, thereby providing multiple advantages such as improved performance, simplified certificate management and enhanced security. (3) NGINX has flexible load balancing strategies that use different strategies to decide to which server a request should be sent in the EMQX cluster, which helps to distribute traffic and requests and improve performance and reliability. For example, sticky load balancing can route requests to a server in the same EMQX cluster, thereby improving performance and session persistence.

[0071] Optionally, by deploying an EMQX cluster through HAProxy, you can load balance messages from the vehicle side and distribute a large number of messages to different EMQX servers in the cluster. HAProxy has the following functions and advantages when used for load balancing and EMQX clustering: (1) By hiding EMQX cluster information through reverse proxy, a unified access address is provided to the vehicle side, improving the maintainability and scalability of the Internet of Vehicles architecture. (2) It supports the termination of MQTT over TLS connections, reducing the SSL encryption computing load of the EMQX cluster, while simplifying certificate deployment and management. (3) With built-in support for the MQTT protocol, it can parse MQTT messages to implement intelligent load balancing mechanisms such as session stickiness, and identify illegal connections and discard them, thereby enhancing security protection. (4) It provides a master-slave high availability mechanism, and with the backend health check, it can achieve millisecond-level fault switching to ensure the continuous availability of services.

[0072] Optionally, when the vehicle publishes a message, the QOS level can be specified as 1 or 2 to ensure that the MQTT cluster receives the published message.

[0073] The server is used to send received business data to the message middleware.

[0074] The servers in the MQTT cluster can be regarded as agents in the MQTT-based Internet of Vehicles architecture, and the message middleware can be regarded as consumers of the MQTT-based Internet of Vehicles architecture, obtaining business data from the servers.

[0075] Specifically, the server stores multiple messages containing topics, and sends the received messages to the message middleware based on the rule engine, wherein the rules defined in the rule engine automatically trigger the sending of messages to the message middleware, and the composition of the rules includes: data source, data processing process, and destination of processing results. The data source can be, for example, a message or an event, or an external data system. The rule specifies the source of the data through the FROM clause of SQL; the data processing process, the rule describes the data processing process through SQL statements and functions, such as the WHERE clause of SQL is used to filter data, and the SELECT clause and SQL functions are used to extract and transform data; the destination of processing results, the rule can define one or more actions to process the output results of SQL. If the SQL execution passes, the rule will execute the corresponding actions in sequence, such as storing the processing results in the database or republishing them to another MQTT topic, etc. The supported actions are as follows: message republishing, console output, and sinking data into an external data system.

[0076] For example, the rule engine is used in data screening, for example, in the truck fleet management of the Internet of Vehicles, the vehicle sensors collect and report a large amount of operating data, and the application platform (cloud) only focuses on the business data when the vehicle speed is greater than 40 km / h. In this scenario, the rule engine can be used to filter the messages conditionally and send the business data that meets the conditions to the message middleware, that is, extract the speed field from the message with the topic run_information, and the screening condition is speed > 40. The rule is: SELECT speed FROM Topic = run_information WHERE speed >40.

[0077] Optionally, a persistent session can be set up on the server. Even if the server is disconnected from the vehicle, or the server is disconnected from the message middleware, the MQTT cluster still maintains the information of the vehicle and the message middleware, including subscription relationships and undelivered messages. When the vehicle or the message middleware reconnects to the server, it can continue to receive messages that were not delivered when disconnected, ensuring that messages are not lost.

[0078] Message middleware, used to store received business data.

[0079] The message middleware is deployed in a cluster, and the message middleware includes Kafka, RabbitMQ, ActiveMQ or ZeroMQ, etc. This application does not make any specific restrictions.

[0080] Among them, Kafka has high throughput and scalability. It can support the transmission of millions of messages per second, and can increase throughput and storage capacity by adding nodes. This design makes Kafka very suitable for processing large-scale data streams. Secondly, Kafka guarantees high reliability and persistent storage of data. By replicating data to multiple nodes, even if a node fails, it can ensure that data will not be lost. In addition, Kafka persists messages to disk and prevents data loss through replication and backup mechanisms. Therefore, connecting to Kafka not only ensures the ability to quickly consume mqtt messages, but also ensures the reliability of message storage.

[0081] RabbitMQ is based on the AMQP (Advanced Message Queuing Protocol) protocol and provides a persistent and reliable message delivery mechanism. It ensures that messages can be reliably transmitted between senders and receivers, and guarantees the security of messages even in the event of failures. RabbitMQ can also handle a large number of concurrent messages, making it suitable for high-concurrency scenarios and large-scale message processing. By clustering multiple RabbitMQ nodes, horizontal expansion and load balancing can be achieved, improving the throughput and reliability of message processing.

[0082] The cloud is used to subscribe to the business data of the corresponding topic from the message middleware for business applications.

[0083] The cloud obtains business data that meets the needs of business applications from the message middleware. The cloud needs to subscribe to one or more topics or queues to receive messages containing business data.

[0084] The cloud sends a subscription message containing a topic to the message middleware. For example, in Kafka, use the subscribe method to subscribe to a topic; in RabbitMQ, use the basicConsume method to subscribe to a queue. Then, the received message containing business data of the corresponding topic is used for business processing. The processing logic may include data parsing, data storage, business logic execution, etc.

[0085] For example, the cloud establishes a connection with the message middleware, and the cloud pulls or receives a message with the subject "sensors / temperature" from the message middleware. The logic for processing the message can be synchronous or asynchronous, depending on the application requirements and the characteristics of the message middleware. The cloud receives the message containing "temperature: 28℃" for business applications, such as displaying it on a large visual screen interface on the cloud platform, for alarm monitoring, etc.

[0086] In the embodiment of the present application, load balancing adopts a cluster deployment method. If the main load balancing node goes down, the vehicle end can reconnect to the backup load balancing node and continue its session to write business data without losing business data, thereby improving the reliability of business data transmission. By balancing the load of each server in the MQTT cluster, business data can be evenly written to different servers in the MQTT cluster, reducing the impact caused by the downtime of a single server, while preventing a single server from becoming a performance bottleneck. By sharing the load, each server can run efficiently, thereby improving the overall performance and response speed of the Internet of Vehicles architecture, which is beneficial to scenarios with large message volumes or many connected vehicle ends. In addition, the Internet of Vehicles architecture is constructed in a clustered manner to improve the high availability of the Internet of Vehicles architecture. In a clustered environment, if a single node fails, other nodes in the cluster will continue to run to ensure uninterrupted service. This redundancy reduces the risk of single point failures and provides a more robust and reliable network environment for IoT devices. The introduction of message middleware decouples the cloud and MQTT cluster, reduces the pressure on the MQTT cluster, improves the concurrency and throughput of business data, further guarantees the reliability of business data transmission, and reduces the risk of business data loss.

[0087] In some embodiments, the MQTT-based Internet of Vehicles architecture further includes: an indicator monitoring component for monitoring the service status of the MQTT cluster, and outputting abnormal alarm information when the service status is detected to be abnormal.

[0088] Among them, the service status of the MQTT cluster includes multiple indicators and parameters to fully reflect the operation status and performance of the cluster. For example, server health status, resource usage, connection status, message transmission status, system performance, errors and exceptions. Server health status includes whether each server is operating normally; resource usage includes CPU usage, memory usage, disk usage, network bandwidth usage, etc.; connection status includes the number of clients currently connected to each server, the number of new connections established per second, and the number of disconnected connections per second; message transmission status includes message throughput, message delay, message size, etc., and system performance includes average response time, system load, etc.; errors include the number of errors occurring per second, such as message transmission failure, connection failure, etc., and exceptions include abnormal events, such as node crashes, network partitions, and other abnormal events.

[0089] For example, the indicator monitoring component includes a collection module, a processing module and an alarm module. The indicator rules are configured on the indicator monitoring component. The collection module collects the service status of the MQTT cluster. The processing module processes and calculates the collected service status according to the indicator rules to determine whether the current service status of the MQTT cluster is normal. The alarm module determines that the current service status of the MQTT cluster is abnormal according to the preset alarm rules when certain indicators exceed the threshold, and triggers an alarm notification, such as supporting multiple notification methods such as email, SMS, and instant messaging tools. Indicator rules, for example, delivery dropped toolarge (the number of messages discarded due to length exceeding the limit when sending), delivery dropped queue full (the number of messages with QoS not 0 discarded due to message queue full when sending), and delivery dropped qos0_msg (the number of messages with QoS 0 discarded due to message queue full when sending).

[0090] The embodiment of the present application monitors the service status of the MQTT cluster to fully understand the operating status of the MQTT cluster, promptly discover and handle potential problems, ensure the stable and efficient operation of the MQTT cluster, prevent business data loss, and thus improve the performance of the Internet of Vehicles architecture.

[0091] Considering that in some embodiments in the cluster, the server is also used to: send received business data to other servers in the MQTT cluster.

[0092] After receiving the business data (business data encapsulated in the message), the server on the MQTT cluster must synchronize the business data to at least another server in the MQTT cluster to achieve synchronization of business data between servers. Only then is the business data sent by the load balancing cluster considered to be successfully written to the server.

[0093] For example, the MQTT cluster includes three servers A, B, and C. The load balancing cluster receives the business data sent by the vehicle, and sends the business data to the A, B, and C servers in a balanced manner through the relevant load balancing strategy. If the A server receives the business data a, the A server will synchronize the business data a to the B server and / or the C server. If the B server receives the business data a and the business data b sent by the load balancing cluster, the B server will synchronize the business data a and b to the C server and / or the A server, and so on. This ensures the reliability of the MQTT cluster storing business data and prevents the loss of business data stored on the server due to a server failure.

[0094] The MQTT protocol itself does not directly support clustering and message synchronization. However, when it comes to cluster deployment of MQTT, other technologies or middleware are usually needed to achieve message persistence and multi-node (node ​​refers to the server) synchronization. For example, you can use RabbitMQ message queue middleware, which supports cluster deployment and advanced message persistence strategies. In RabbitMQ, you can achieve message synchronization by configuring the synchronization strategy between cluster nodes, including options such as automatic synchronization and manual synchronization.

[0095] The embodiment of the present application realizes the synchronization of business data between servers in the MQTT cluster, ensures the reliability of the business data stored in the MQTT cluster, and thus improves the performance of the Internet of Vehicles architecture.

[0096] In some embodiments, the MQTT-based Internet of Vehicles architecture also includes: a storage cluster for business data.

[0097] The storage cluster can be a cloud storage service cluster, such as cloud storage products provided by various cloud service providers; a database service cluster, such as relational database clusters such as MySQL, PostgreSQL, memory database clusters such as Redis, Memcached, etc., and the embodiments of the present application do not make specific restrictions.

[0098] Correspondingly, the server is also used to: monitor whether the message middleware is offline; if it is detected that the message middleware is offline, send the received business data to the storage cluster.

[0099] For example, the MQTT server periodically sends Ping requests to the message middleware and monitors its response. For example, a script or monitoring tool can be used to periodically send Ping requests and check the response time and status code. If there is a response and the status code is correct, it means that the message middleware is online. Otherwise, the message middleware is offline.

[0100] Optionally, in some implementations, dedicated monitoring tools, such as Nagios, MQTT Exporter, etc., may also be used.

[0101] In another implementation, log monitoring may also be used. For example, an alarm rule may be set to trigger an alarm notification when an abnormal log (such as a connection failure, a node offline, etc.) is detected.

[0102] In yet another implementation, online monitoring may be implemented by running a custom script.

[0103] For example, by configuring relevant rules on the EMQX Dashboard, offline messages (business data received by the server during the offline period) are saved to the Redis cluster. When the message middleware goes online, it can receive these offline messages to prevent business loss due to message loss.

[0104] In the embodiment of the present application, the online status of the message middleware is monitored and the business data received by the server during the offline period is stored in the storage cluster, so as to avoid the impact of the cloud business application on the message middleware due to the lack of business data during the offline period, thereby ensuring the high availability and reliability of the Internet of Vehicles architecture.

[0105] In some embodiments, the server is further used to: monitor whether the message middleware is offline based on the heartbeat signal.

[0106] For example, by periodically sending and receiving heartbeat signals between the server and the message middleware, the status of the message middleware can be monitored in real time to reduce false alarms and delays.

[0107] In the embodiment of the present application, the online status of the message middleware can be monitored quickly and accurately by sending a heartbeat signal.

[0108] In some embodiments, the load balancing cluster is specifically used to: after load balancing the received business data according to preset configuration rules, send the business data balanced to the servers in the MQTT cluster, wherein the configuration rules include the minimum number of connections and / or the fastest response time.

[0109] The least number of connections rule includes the load balancing cluster allocating business data to the server with the least number of current connections.

[0110] For example, the load balancing cluster monitors the number of connections of each server in the MQTT cluster in real time, dynamically balances the load, and preferentially sends business data to the server with the least number of connections. The smaller the number of connections, the faster the server processing speed.

[0111] The fastest response time rule includes the load balancing cluster allocating business data to the server with the shortest response time. The shorter the response time, the faster the server processing speed.

[0112] For example, the load balancing cluster monitors the response time of each server in the MQTT cluster in real time, dynamically adjusts the distribution of business data, and preferentially sends business data to the server with the shortest response time.

[0113] In the embodiment of the present application, the received business data is load balanced by using the configuration rules, and then sent to each server in the MQTT cluster, dynamically adapting to changes in server performance, reducing the load of each server, and giving full play to the performance of each server, so as to optimize the use of MQTT cluster resources, maximize throughput, minimize response time, and avoid single point failures, thereby ensuring the overall performance of the MQTT cluster and the reliability of business data transmission and storage, thereby improving the performance of the Internet of Vehicles architecture.

[0114] Based on the above embodiments, the present application also proposes a business data processing method, which is applied to the MQTT-based Internet of Vehicles architecture. Figure 3 Describe the business data processing method, Figure 3 A flowchart of a business data processing method proposed in an embodiment of the present application.

[0115] like Figure 3 As shown, the business data processing method includes the following processing steps:

[0116] S301. The load balancing cluster receives the business data sent by the vehicle, performs load balancing on the business data, and then sends the business data balanced to the server in the MQTT cluster.

[0117] S302: The server sends the received business data to the message middleware.

[0118] S303: The message middleware stores the received business data.

[0119] S304: The cloud subscribes to the business data of the corresponding topic from the message middleware to perform business applications.

[0120] Furthermore, the business data processing method also includes: an indicator monitoring component monitors the service status of the MQTT cluster, and outputs abnormal alarm information when the service status is detected to be abnormal.

[0121] Optionally, the business data processing method further includes:

[0122] The server monitors whether the message middleware is offline; if it is detected that the message middleware is offline, the server sends the received business data to the storage cluster, and the storage cluster stores the business data.

[0123] After the message middleware goes online, it obtains business data from the storage cluster.

[0124] It should be noted that the implementation principle and beneficial effects of the embodiment of the present application are similar to the technical solutions shown in the above-mentioned MQTT-based Internet of Vehicles architecture embodiment, and will not be repeated here.

[0125] Next, the MQTT-based Internet of Vehicles architecture is described through specific embodiments. Figure 4 This is a schematic diagram of a vehicle networking architecture based on MQTT proposed in another embodiment of the present application. Figure 4 As shown in the figure, the modified Internet of Vehicles architecture includes: producer, load balancing configuration, agent, consumer, business application end, indicator monitoring component, and Redis cluster.

[0126] Producers include: Multi-access Edge Computing (edge ​​MEC), on-board TBOX controller and vehicle upload. Among them, edge MEC includes on-board radar or on-board camera, etc., and on-board TBOX controller collects and transmits various vehicle data, such as fuel consumption, engine water temperature, current vehicle speed and other real-time data. Vehicle uploads a large amount of business data such as vehicle system data, vehicle trajectory information, vehicle status data, etc.

[0127] Load balancing configuration includes: load balancing based on domain name resolution service DNS and reverse proxy service Proxy. DNS can be used together with reverse proxy server to achieve load balancing. For example, since the same name can be configured for multiple different addresses in the DNS server, the domain name and IP can be resolved by random names in the DNS service to achieve the distribution of business data on multiple Proxy reverse proxy servers. The Proxy reverse proxy server forwards the received business data to multiple servers in the backend MQTT cluster for processing, thereby achieving the purpose of load balancing and improving the availability and performance of the Internet of Vehicles architecture.

[0128] The agent includes: MQTT cluster, which is composed of multiple MQTT servers. It sends the received business data to the RabbitMQ cluster based on the rule engine. In addition, after receiving the business data, the server on the MQTT cluster must synchronize the business data to at least another server in the MQTT cluster to achieve synchronization of business data between servers, ensuring the reliability of the MQTT cluster storing business data and preventing the loss of business data stored on the server due to a server failure.

[0129] Consumers include: RabbitMQ cluster, which is composed of multiple RabbitMQ servers and stores received business data. RabbitMQ cluster realizes the decoupling of MQTT cluster and business application end.

[0130] The business application end includes: cloud control platform, telematics service provider (TSP platform) and websocket service interface. The TSP platform is mainly a vehicle communication service provider. The business application end obtains business data from the RabbitMQ cluster and performs subsequent business actions.

[0131] The indicator monitoring component monitors the service status of the MQTT cluster. For example, the indicator monitoring component includes a collection module, a processing module and an alarm module. The indicator rules are configured on the indicator monitoring component. The collection module collects the service status of the MQTT cluster. The processing module processes and calculates the collected service status according to the indicator rules to determine whether the current service status of the MQTT cluster is normal. The alarm module determines that the current service status of the MQTT cluster is abnormal according to the preset alarm rules when certain indicators exceed the threshold, and triggers an alarm notification.

[0132] The Redis cluster stores the business data received by the MQTT server during the RabbitMQ cluster offline period. For example, the server periodically sends Ping to the message middleware and monitors its response. If it finds that the message middleware is offline during 02:25:00-02:45:20, the server sends the business data received during 02:25:00-02:45:20 to the Redis cluster for storage. When the RabbitMQ cluster is online, the business data during 02:25:00-02:45:20 can be obtained from the Redis cluster to prevent business loss due to business data loss.

[0133] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0134] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0135] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0136] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0137] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0138] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0139] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0140] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0141] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0142] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A vehicle networking architecture based on MQTT, characterized in that: include: Vehicle side, cloud side, MQTT cluster, message middleware and load balancing cluster; The load balancing cluster is used to receive the business data sent by the vehicle end, and after load balancing the business data, send the business data balanced to the server in the MQTT cluster; The server is used to send the received business data to the message middleware; The message middleware is used to store received business data; The cloud end is used to subscribe to the business data of the corresponding topic from the message middleware to perform business applications.

2. The MQTT-based Internet of Vehicles architecture according to claim 1, characterized in that: Also includes: The indicator monitoring component is used to monitor the service status of the MQTT cluster and output abnormal alarm information when the service status is detected to be abnormal.

3. The MQTT-based Internet of Vehicles architecture according to claim 1 or 2, characterized in that: The server is also used to send received business data to other servers in the MQTT cluster.

4. The MQTT-based Internet of Vehicles architecture according to claim 1 or 2, characterized in that: Also included: a storage cluster for business data; Correspondingly, the server is further used to: monitor whether the message middleware is offline; if it is monitored that the message middleware is offline, send the received business data to the storage cluster.

5. The MQTT-based Internet of Vehicles architecture according to claim 4, characterized in that: The server is also used to monitor whether the message middleware is offline based on the heartbeat signal.

6. The MQTT-based Internet of Vehicles architecture according to claim 1 or 2, characterized in that: The load balancing cluster is specifically used to: load balance the received business data according to preset configuration rules, and send the business data balanced to the servers in the MQTT cluster. The configuration rules include the minimum number of connections and / or the fastest response time.

7. A business data processing method, characterized in that: Applied to the MQTT-based Internet of Vehicles architecture according to any one of claims 1 to 6, the service data processing method includes: The load balancing cluster receives the service data sent by the vehicle end, performs load balancing on the service data, and then sends the service data balanced to the server in the MQTT cluster; The server sends the received business data to the message middleware; The message middleware stores received business data; The cloud subscribes to the business data of the corresponding topic from the message middleware to perform business applications.

8. The business data processing method according to claim 7, characterized in that: The MQTT-based Internet of Vehicles architecture also includes an indicator monitoring component, and the business data processing method also includes: The indicator monitoring component monitors the service status of the MQTT cluster, and outputs abnormal alarm information when the service status is detected to be abnormal.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to claim 7 or 8 when executed.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to claim 7 or 8 when being executed.

Images