Distributed communication system and method based on multi-protocol message bus

Abstract

The invention relates to the technical field of distributed systems, in particular to a distributed communication system and method based on a multi-protocol message bus, and aims at realizing an intelligent message routing mechanism and providing a unified theme management scheme by constructing a unified event model and designing a pluggable protocol adaptation layer. The problems of complex integration, non-uniform interfaces and poor expansibility caused by heterogeneity of various message protocols in an existing distributed system are effectively solved. Various message protocols such as MQTT, Kafka and RabbitMQ can be seamlessly integrated, a uniform programming interface and consistent message processing experience are provided for upper-layer applications, the complexity and development and maintenance cost of system integration are remarkably reduced, meanwhile, dynamic extension of a new protocol is supported through a plug-in architecture, the flexibility and maintainability of the system are enhanced, and the system is suitable for application and popularization. And finally, simplification, unification and high efficiency of distributed communication are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed systems, and in particular to a distributed communication system and method based on a multi-protocol message bus. BACKGROUND

[0002] With the rapid development of cloud computing, microservice architecture and Internet of Things technology, modern software systems are increasingly showing distributed and loosely coupled characteristics. Against this background, message middleware plays a crucial role as a core component for realizing application decoupling, asynchronous communication and data flow processing. There are various mainstream message protocols and their corresponding middleware products on the market, such as the MQTT protocol designed for Internet of Things scenarios, Kafka for high-throughput data flow processing, and RabbitMQ (based on the AMQP protocol) supporting complex enterprise-level application message routing. These middleware, due to their different design goals, focus on protocol characteristics, performance and applicable scenarios, and together form the communication infrastructure of modern distributed systems.

[0003] However, this diversity also brings significant integration challenges. First, different message middleware adopts completely heterogeneous communication protocols, which fundamentally differ in message format, connection method, and quality of service (QoS) guarantee mechanism, making them unable to directly interoperate, forming "protocol islands". When a system needs to interact with multiple services using different protocols, developers must integrate multiple client libraries and write a large amount of repetitive and protocol-dependent code, greatly increasing the complexity and integration cost of the system. Second, the client API interfaces, programming models, and management methods provided by various middleware are not unified, requiring developers to have multiple professional knowledge, which not only raises the technical threshold but also leads to low development efficiency and increased maintenance difficulty.

[0004] To address the above problems, there are some solutions in the prior art that use protocol gateways or proxies for conversion, but these solutions often have limitations. They often only address the conversion between two specific protocols, lack a global and unified abstract perspective, and have poor generality. More importantly, these solutions mostly only solve the most basic communication connectivity problem and fail to provide a complete overall architecture that covers unified topic management, flexible message routing, life cycle control, and pluggable extension mechanisms. Therefore, there is an urgent need for a systematic solution that can mask the complexity of multiple underlying message protocols and provide standardized message communication capabilities for upper-layer applications, thereby truly realizing the simplification, unification and efficiency of distributed communication. SUMMARY

[0005] The application aims to provide a multi-protocol message bus-based distributed communication system and method, which solves the problems of complex integration, non-uniform interface and poor scalability caused by the heterogeneity of multiple message protocols in the existing distributed system.

[0006] To achieve the above-mentioned purpose, the application provides a multi-protocol message bus-based distributed communication method, comprising the following steps:

[0007] Receiving the message sent by the upper application through the unified message bus interface, and constructing a unified event model according to the received message;

[0008] The message routing module determines one or more target protocol adapters according to the topic field in the event model and the preconfigured routing strategy;

[0009] The target protocol adapter converts the unified event model into a message format of a specific protocol, and sends the message to the corresponding external message middleware through its client instance;

[0010] The target protocol adapter listens to and receives messages from the external message middleware, and converts the received specific protocol message back to the unified event model;

[0011] The message routing module routes the converted event model to all internal consumer applications that subscribe to the topic through the unified bus interface according to the topic field thereof.

[0012] Among them, the message sent by the upper application through the unified message bus interface is received, and a unified event model is constructed according to the received message, in which:

[0013] The sent message includes a topic and a payload content;

[0014] The event model includes a message unique identifier, a payload content, a message header set carrying metadata, a topic field for routing, and a protocol type field indicating a target protocol type.

[0015] Among them, the message routing module determines one or more target protocol adapters according to the topic field in the event model and the preconfigured routing strategy, in which:

[0016] The routing strategy includes a matching rule based on a topic wildcard and a filtering rule based on a message header or a payload content.

[0017] Among them, the target protocol adapter converts the unified event model into a message format of a specific protocol, and sends the message to the corresponding external message middleware through its client instance, in which:

[0018] The specific protocol includes at least one of MQTT, Kafka and RabbitMQ.

[0019] The target protocol adapter listens to and receives messages from the external message middleware, converts the received specific protocol messages back to a unified event model, and the specific steps include:

[0020] The target protocol adapter continuously listens to the subscribed topics of the external message middleware through its client instance;

[0021] Receive specific protocol messages from the external message middleware;

[0022] Parse the packet header and payload of the specific protocol message, and extract the topic, payload data and metadata;

[0023] According to the preset serialization configuration, the payload data is deserialized to obtain a Java object or a business entity;

[0024] The parsed topic is taken as the topic field, the deserialized object is taken as the payload content, the extracted metadata is filled into the message header set, and a new message unique identifier is generated to construct a complete unified event model;

[0025] The constructed unified event model is submitted to the message routing module for subsequent steps.

[0026] The message routing module routes the converted event model to all internal consumer applications that subscribe to the topic through the unified bus interface according to the topic field, and the specific steps include:

[0027] The message routing module receives the unified event model converted by the protocol adapter and extracts the topic field;

[0028] According to the topic field, query the subscription relationship registered in the topic management module to obtain a list of all internal consumer applications that subscribe to the topic or match the topic pattern, wherein the subscription relationship is registered in the topic management module by the upper application when subscribing through the unified bus interface;

[0029] If the subscription information indicates that the topic is a shared subscription topic, select a target instance from multiple consumer instances in the shared group according to the preconfigured load balancing strategy;

[0030] Send the unified event model to each consumer instance in the obtained consumer application list, or send it to the only target consumer instance selected by the load balancing strategy;

[0031] According to the indication of the quality of service level field in the unified event model, wait for the confirmation of the consumer application, and if no confirmation is received, perform a retry or error handling process after reaching the timeout time.

[0032] A distributed communication system based on a multi-protocol message bus includes a unified message bus interface, a message routing module, a protocol adaptation layer module, and a topic management module.

[0033] The unified message bus interface is used to provide a unified message publishing and subscription programming interface to upper-layer applications, receive sent messages, and construct a unified event model based on the messages.

[0034] The message routing module is connected to the unified message bus interface and is used to determine one or more target protocol adapters based on the topic field in the event model and the pre-configured routing strategy. It is also used to route the event model converted by the protocol adapter to all internal consumer applications that have subscribed to the topic through the unified message bus interface based on its topic field.

[0035] The protocol adaptation layer module, connected to the message routing module, includes multiple pluggable protocol adapters. The protocol adapters are used to convert a unified event model into a specific protocol message format and send it to the corresponding external message middleware through their client instances. They are also used to listen to and receive specific protocol messages from the external message middleware, convert them back to the unified event model, and submit them to the message routing module.

[0036] The topic management module, connected to the message routing module, is used to register, store, and manage subscription relationships, and provides topic verification, parsing, and matching functions.

[0037] This invention discloses a distributed communication system and method based on a multi-protocol message bus. By constructing a unified event model, designing a pluggable protocol adaptation layer, implementing an intelligent message routing mechanism, and providing a unified topic management scheme, it effectively solves the problems of complex integration, inconsistent interfaces, and poor scalability caused by the heterogeneity of multiple message protocols in existing distributed systems. It can seamlessly integrate multiple message protocols such as MQTT, Kafka, and RabbitMQ, providing upper-layer applications with a unified programming interface and a consistent message processing experience. This significantly reduces the complexity of system integration and development and maintenance costs. Furthermore, the pluggable architecture supports dynamic expansion of new protocols, enhancing the system's flexibility and maintainability, ultimately achieving simplified, unified, and efficient distributed communication. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0039] Figure 1 This is an architecture diagram of the distributed communication system based on a multi-protocol message bus according to the present invention.

[0040] Figure 2 is a message flow timing diagram of the present application.

[0041] Figure 3 is a subject management flow chart of the present application.

[0042] Figure 4 is a protocol adapter class diagram of the present application.

[0043] Figure 5 is a step flow chart of the distributed communication method based on the multi-protocol message bus of the present application. The present application provides a distributed communication method based on a multi-protocol message bus, comprising the following steps:

[0044] Figure 6 is a principle block diagram of the distributed communication system based on the multi-protocol message bus of the present application.

[0045] In the figure: 201-uniform message bus interface, 202-message routing module, 203-protocol adaptation layer module, 204-subject management module. DETAILED DESCRIPTION

[0046] The embodiments of the present application are described in detail below, examples of which are shown in the accompanying drawings, the embodiments described below by referring to the accompanying drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0047] The first embodiment of the present application is:

[0048] Please refer to Figures 1 to 5 , wherein, Figure 1 is an architecture diagram of the distributed communication system based on the multi-protocol message bus of the present application. Figure 2 is a message flow timing diagram of the present application. Figure 3 is a subject management flow chart of the present application. Figure 4 is a protocol adapter class diagram of the present application. Figure 5 is a step flow chart of the distributed communication method based on the multi-protocol message bus of the present application. The present application provides a distributed communication method based on a multi-protocol message bus, comprising the following steps:

[0049] S101: receiving the message sent by the upper layer application through the uniform message bus interface 201, and constructing a uniform event model according to the received message;

[0050] Specifically, when an upper-layer application needs to send a message, it first calls the system-provided unified message bus interface 201. This interface adopts object-oriented design principles and provides a set of concise and clear application programming interfaces for application developers, completely shielding the specific implementation details of various underlying message middleware protocols. Application developers do not need to care whether the message is ultimately transmitted through MQTT, Kafka, or RabbitMQ; they only need to call according to the unified interface specification, which significantly reduces the development difficulty and improves the maintainability of the code.

[0051] When the upper-layer application calls the sending interface, it needs to provide two basic parameters: the topic and the payload content. The topic is a string identifier used to identify the type or destination of the message, usually adopting a hierarchical structure, such as "sensor / temperature / room1" in the device data collection scenario. The payload content is the actual business data of the message, which can be an array of bytes, a string, or a serializable business object of any format. This design allows the application to express its communication intent in the most natural way without being forced to adapt to the constraints of a specific protocol.

[0052] After receiving the sending request, the unified message bus interface 201 immediately begins to build a unified event model. This event model is the core data structure within the system and serves as the basis for all protocol conversion and message routing operations. The event model first generates a globally unique message identifier, which is used to track and diagnose the processing status of the message throughout its life cycle. Subsequently, the interface stores the payload content provided by the application in the payload content field of the event model, which supports the storage of data objects of any type.

[0053] To support cross-protocol message routing and processing, the event model also contains a set of message headers specifically used to store metadata. This metadata can include the priority of the message, the creation timestamp, the expiration time, the target protocol type, and other application-defined attributes. The message headers are stored in the form of key-value pairs, providing great flexibility and extensibility. In particular, the protocol type field explicitly indicates which protocol the message expects to be transmitted through, providing a key decision basis for subsequent message routing.

[0054] The topic field is saved as is in the event model, which is crucial in the subsequent processing flow as it determines which protocol adapter or adapters the message is routed to. After the entire construction process is completed, a protocol-agnostic unified event model containing all necessary information is ready and can be submitted to the next processing link of the system for further processing. This unified event model design effectively solves the problem of inconsistent data representation in a multi-protocol system and lays a solid foundation for subsequent protocol conversion and message routing.

[0055] S102: The message routing module 202 determines one or more target protocol adapters according to the topic field in the event model and the preconfigured routing strategy;

[0056] Specifically, after the unified event model is constructed, the message routing module 202 begins to perform its core routing decision function. The module first extracts the topic field from the event model, which is the primary basis for routing judgment. The topic field usually adopts a hierarchical structure, with parts separated by slashes, which provides a basis for flexible routing strategies. The message routing module 202 maintains a set of preconfigured routing strategies inside, which can be dynamically updated through configuration files or management interfaces, enabling the system to adapt to different deployment environments and business needs.

[0057] The core of the routing strategy is the matching rule based on the topic, and the system supports multiple matching modes. In addition to exact matching, wildcard matching is also supported, for example, using a plus sign to represent a single-level wildcard and a hash sign to represent a multi-level wildcard, which draws on the mature topic matching mechanism in existing message middleware. In addition, the routing strategy also contains filtering rules based on message header or payload content, allowing more refined routing decisions based on message metadata attributes or actual content. These filtering rules can be combined to form complex routing conditions to meet the needs of various business scenarios.

[0058] In the process of determining the target protocol adapter, the message routing module 202 will consider multiple factors. First, the protocol type field indicates which transmission protocol the message expects to use. Second, the matching degree of the topic pattern and the protocol adapter's ability, each protocol adapter declares the range of topic patterns it can handle. In addition, the current load status of the system and the availability status of the adapter are also taken into account to ensure the rationality and reliability of the routing decision.

[0059] The message routing module 202 can obtain the instances of all available protocol adapters and their capability descriptions by querying the internally maintained adapter registry. This process employs an efficient matching algorithm that can quickly find the target protocol adapter that meets the conditions. According to the configuration of the routing strategy, a message may be routed to a single protocol adapter, or it may be routed to multiple protocol adapters at the same time, implementing message broadcast or multicast. This design enables the system to flexibly support various message distribution modes.

[0060] In special cases, if the routing module cannot find a matching target protocol adapter, or the specified protocol adapter is unavailable, the system will handle it according to the preset error handling strategy. This may include returning error information to the upstream application, temporarily storing the message in the dead letter queue for subsequent processing, or attempting to use a backup protocol adapter for message delivery. After the entire routing decision process is completed, the message routing module 202 will pass the unified event model and its determined target protocol adapter list to the next processing link, ensuring that the message can be transmitted and processed in the expected manner.

[0061] S103: The target protocol adapter converts the unified event model into a specific protocol message format and sends the message to the corresponding external message middleware through its client instance;

[0062] Specifically, when the message routing module 202 determines the target protocol adapter, the corresponding protocol adapter instance begins to perform the protocol conversion and message sending task. Each protocol adapter implements a unified adapter interface, ensuring that they can handle the unified event model in a consistent manner. The protocol conversion process first involves format conversion, and the adapter needs to convert the internal unified event model into the message format required by the specific protocol. This process includes the construction of the protocol header, the formatting of the payload data, and the setting of various protocol-specific properties.

[0063] During the conversion process, the protocol adapter carefully processes each field in the event model. The message unique identifier is mapped to the corresponding message ID field in the target protocol, ensuring the traceability of the message. The payload content is appropriately serialized according to the requirements of the target protocol, such as converted to JSON format, Protobuf binary format, or kept as a raw byte array. The metadata in the message header set is cleverly mapped to the header fields of the target protocol. Some protocols support custom header attributes, while others need to embed meta-information into the payload.

[0064] The processing of the topic field is particularly crucial, as different protocols have different specifications and restrictions on topic naming. The MQTT protocol supports a hierarchical topic structure, Kafka uses a topic and partition mechanism, and RabbitMQ uses a binding relationship between exchanges and routing keys. The protocol adapter needs to ensure that the topic name meets the syntax requirements of the target protocol, and performs appropriate conversion or encoding if necessary. For specific protocol requirements indicated by the protocol type field, the adapter sets the quality of service level, persistence flag, priority, and other parameters accordingly. Time-related parameters such as expiration time are converted to the expiration time or time-to-live settings supported by the target protocol.

[0065] After completing the format conversion, the protocol adapter establishes a connection with the external message middleware through its client instance. These client instances are usually standard client library instances for the corresponding protocol, such as the Paho client for the MQTT protocol, the Kafka producer for the Kafka protocol, and the AMQP client for the RabbitMQ protocol. The client instance is responsible for handling network communication details with the external message middleware, including connection management, authentication, reconnection mechanisms, and other aspects. The protocol adapter calls the send method of the client instance to send the converted specific protocol message to the corresponding topic or queue.

[0066] During the sending process, the protocol adapter also needs to handle various protocol-specific features. For the MQTT protocol, it needs to handle the confirmation mechanism corresponding to the quality of service level to ensure reliable message delivery; for the Kafka protocol, it needs to handle partition selection and message key settings to optimize message distribution and order; for the RabbitMQ protocol, it needs to handle exchange binding and routing key matching to achieve flexible message routing. These features need to be appropriately configured and handled based on the meta-information carried in the unified event model.

[0067] The sending operation is usually asynchronous, and the protocol adapter registers the corresponding callback function to handle the sending result. Successful sending triggers the confirmation callback, while failure triggers the error handling process. The protocol adapter needs to ensure reliable message delivery and will automatically retry according to the configured retry strategy when encountering network problems or middleware failures. After the entire sending process is completed, the protocol adapter updates the corresponding monitoring indicators to provide visual data support for system operation status, and releases related resources to ensure system stability and performance.

[0068] S104: The target protocol adapter listens to and receives messages from the external message middleware, and converts the received specific protocol messages back to the unified event model;

[0069] Specifically, when the system runs in the message receiving mode, the target protocol adapter continuously listens to the specified topic or queue in the external message middleware through its client instances. These client instances have established stable connections with the corresponding message middleware services during the system initialization phase and have registered message listeners according to the configured subscription mode. The listening process adopts an event-driven mechanism, and when new messages arrive in the external message middleware, they are actively pushed to the registered client instances, or the client instances actively pull new messages according to the configured polling interval.

[0070] After the protocol adapter receives a specific protocol message, it first performs protocol parsing work. This process needs to extract the valid message content from the original network data packet according to the specifications of the specific protocol. For the MQTT protocol, the fixed format packet header needs to be parsed to extract fields such as control packet type, quality of service flag, and reserved flag; for the Kafka protocol, the key-value pairs and partition information of each message in the message set need to be parsed; for the RabbitMQ protocol, the AMQP frame structure needs to be parsed to extract attributes such as exchange and routing key. The protocol adapter needs to accurately identify and parse these specific formats to ensure that no important protocol-specific information is lost.

[0071] After parsing is complete, the adapter begins to perform the reverse conversion process, converting the specific protocol message back to the system's internal unified event model. First, the message metadata is restored from the parsed protocol header information, and these metadata are filled into the message header collection of the unified event model. The topic information is directly set to the topic field of the event model to ensure the consistency of message routing. For the payload data, the adapter performs deserialization operations according to the pre-configured serialization configuration, converting it from the protocol-specific format to a Java object or business entity. This process may need to handle multiple data formats, such as converting JSON strings to Java objects, parsing Protobuf binary data according to predefined patterns, and directly saving or further processing raw byte arrays according to application requirements.

[0072] In the process of building the unified event model, the protocol adapter generates a new message unique identifier, which maintains a mapping relationship with the protocol internal identifier of the original message, facilitating subsequent tracking and diagnosis. At the same time, the adapter extracts information such as quality of service level, timestamp, and expiration time from the protocol-specific parameters and maps it to the corresponding fields of the unified event model. For some protocol-specific features, such as MQTT's reserved message flag, Kafka's offset information, and RabbitMQ's priority setting, the adapter converts these information into a unified metadata representation form and saves it in the message header collection.

[0073] During the conversion process, the protocol adapter needs to handle potential exceptions. When deserialization of the payload data fails, the adapter will attempt to use an alternative parsing method or retain the original data in the event model and mark it with the corresponding error flag. All conversion operations follow a unified error handling standard to ensure the stability and reliability of the system. After the conversion is complete, the protocol adapter submits the constructed unified event model to the message routing module 202 for further processing, and simultaneously sends an acknowledgment message to the external message middleware to ensure that the reliable message delivery mechanism is executed correctly. The entire receiving and conversion process maintains the integrity and consistency of the messages, laying a solid foundation for subsequent message routing and processing.

[0074] S105: The message routing module 202 routes the transformed event model to all internal consumer applications that have subscribed to the topic through the unified bus interface, based on its topic field.

[0075] Specifically, after the protocol adapter delivers the converted unified event model to the message routing module 202, the message routing module 202 immediately begins its internal distribution process. This module first extracts the topic field from the event model; this field is the key basis for internal routing. The message routing module 202 maintains a real-time subscription relationship table. This subscription information is registered and maintained by the topic management module 204 when internal consumer applications subscribe through the unified bus interface. The subscription relationship table records the mapping relationship between each topic pattern and the corresponding consumer application, including the consumer's identifier, subscription time, and related filtering conditions.

[0076] The message routing module 202 uses an efficient matching algorithm to find all internal consumer applications that have subscribed to the topic or match the topic pattern. The matching process supports multiple pattern matching rules, including exact matching and wildcard matching. For topic patterns containing wildcards, such as using an asterisk to match a single-level directory or a hash sign to match a multi-level directory, the routing module employs an optimized algorithm based on a prefix tree or hash table to quickly find all matching subscribers. This process ensures high routing efficiency even with a massive number of subscription relationships.

[0077] After obtaining the list of matching consumers, the message routing module 202 needs to determine the message distribution method based on the subscription type. For regular subscriptions, messages need to be sent to all matching consumer application instances. For shared subscriptions, messages only need to be sent to one consumer instance within the shared group, which requires enabling a load balancing mechanism. The load balancing strategy can be configured to use different algorithms such as round-robin, random, or sticky hashing to ensure that messages are reasonably distributed within the consumer group, avoiding situations where some instances are overloaded while others are idle.

[0078] During the message distribution process, the message routing module 202 maintains the state information of each consumer application, including the connection state, processing capacity, and current load situation. For offline or insufficient processing capacity consumers, the routing module will handle them according to the configured strategy, which may choose to temporarily store messages waiting for the consumer to recover, or skip the consumer and directly process the next one. This mechanism ensures the stability and reliability of the system, avoiding the impact of a single consumer exception on the overall message flow.

[0079] The actual message delivery operation is completed through a unified bus interface, and the message routing module 202 calls the delivery method defined in the interface to send the unified event model to the target consumer application. The delivery process supports both synchronous and asynchronous modes, with the synchronous mode waiting for the consumer to complete processing and return an acknowledgment, and the asynchronous mode returning immediately to continue processing the next message. For scenarios requiring reliable transmission, the routing module will wait for the acknowledgment of the consumer application according to the indication of the quality of service level field in the unified event model. If no acknowledgment is received within the specified time, the routing module will start the retry mechanism and resend the message according to the preset retry strategy.

[0080] After the entire internal distribution process is completed, the message routing module 202 updates the relevant monitoring indicators, records the routing path and processing status of the message. These monitoring data provide an important basis for system operation and maintenance, helping administrators understand message flow, consumer processing performance, and overall system operation status. At the same time, any exception that occurs during the distribution process will be recorded in the log, facilitating subsequent problem troubleshooting and system optimization. Through such a complete internal distribution mechanism, it ensures that messages can be accurately and efficiently delivered to the target consumer application, completing the last link of the entire message processing flow.

[0081] Effectively solves the problems of complex integration, non-uniform interfaces, and poor scalability caused by the heterogeneity of multiple message protocols in existing distributed systems. It can seamlessly integrate multiple message protocols such as MQTT, Kafka, RabbitMQ, etc., providing a unified programming interface and consistent message processing experience for upper-layer applications, significantly reducing the complexity of system integration and development and maintenance costs. At the same time, through the plug-in architecture, it supports dynamic expansion of new protocols, enhancing the flexibility and maintainability of the system, and ultimately achieving the simplification, unification, and efficiency of distributed communication.

[0082] The second embodiment of the present application is:

[0083] Based on the first embodiment, please refer to Figure 6 , wherein Figure 6 is the principle diagram of the distributed communication system based on the multi-protocol message bus of the present application.

[0084] The distributed communication system based on the multi-protocol message bus comprises a unified message bus interface 201, a message routing module 202, a protocol adaptation layer module 203 and a topic management module 204.

[0085] The unified message bus interface 201 is configured to provide a unified message publishing and subscribing programming interface for an upper-layer application, receive a sent message and construct a unified event model according to the message.

[0086] The message routing module 202 is connected with the unified message bus interface 201 and configured to determine one or more target protocol adapters according to a topic field in the event model and a preconfigured routing strategy, and route an event model converted by the protocol adapter to all internal consumer applications that subscribe to the topic through the unified message bus interface 201 according to the topic field.

[0087] The protocol adaptation layer module 203 is connected with the message routing module 202 and comprises a plurality of pluggable protocol adapters, which are configured to convert the unified event model into a specific protocol message format and send the specific protocol message to a corresponding external message middleware through a client instance of the protocol adapter, and listen to and receive a specific protocol message from the external message middleware, convert the specific protocol message back to the unified event model and submit the unified event model to the message routing module 202.

[0088] The topic management module 204 is connected with the message routing module 202 and configured to register, store and manage a subscribing relationship and provide a topic verification, analysis and matching function.

[0089] The distributed communication system based on the multi-protocol message bus uses the unified message bus interface 201 to receive application messages and construct a standardized event model, uses the message routing module 202 to intelligently select a target protocol adapter according to a topic and a routing strategy, uses the protocol adaptation layer to realize bidirectional conversion and communication of a plurality of message protocols (such as MQTT / Kafka / RabbitMQ) through a pluggable architecture, and uses the topic management module 204 to uniformly govern a subscribing relationship and a topic, so as to finally realize transparent routing and distribution across heterogeneous message middleware and solve the problems of integration complexity, interface inconsistency and expansibility in a multi-protocol scenario.

[0090] The above only discloses one or more preferred embodiments of the present application and cannot limit the scope of the rights of the present application. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented, and equivalent changes made according to the claims of the present application still belong to the scope covered by the present application.

Claims

1. A method of distributed communication based on a multi-protocol message bus, characterized in that, The method comprises the following steps: receiving a message sent by an upper application through a unified message bus interface, and constructing a unified event model according to the received message; determining one or more target protocol adapters according to a topic field in the event model and a preconfigured routing strategy by a message routing module; converting the unified event model into a message format of a specific protocol by the target protocol adapter, and sending the message to a corresponding external message middleware through a client instance of the target protocol adapter; listening to and receiving a message from the external message middleware by the target protocol adapter, and converting the received specific protocol message back to the unified event model; routing the converted event model to all internal consumer applications that subscribe to the topic through the unified bus interface according to the topic field of the event model by the message routing module.

2. The multi-protocol message bus based distributed communication method of claim 1, wherein, receiving a message sent by an upper application through a unified message bus interface, and constructing a unified event model according to the received message, wherein: the sent message comprises a topic and payload content; the event model comprises a message unique identifier, payload content, a message header set carrying metadata, a topic field used for routing, and a protocol type field indicating a target protocol type.

3. The multi-protocol message bus based distributed communication method of claim 2, wherein, determining one or more target protocol adapters according to a topic field in the event model and a preconfigured routing strategy by a message routing module, wherein: the routing strategy comprises a matching rule based on a topic wildcard and a filtering rule based on a message header or payload content.

4. The multi-protocol message bus based distributed communication method of claim 3, wherein, converting the unified event model into a message format of a specific protocol by the target protocol adapter, and sending the message to a corresponding external message middleware through a client instance of the target protocol adapter, wherein: the specific protocol comprises at least one of MQTT, Kafka, and RabbitMQ.

5. The multi-protocol message bus based distributed communication method of claim 4, wherein, listening to and receiving a message from the external message middleware by the target protocol adapter, and converting the received specific protocol message back to the unified event model, and the specific steps comprise: continuously listening to a topic of the external message middleware subscribed by the target protocol adapter through the client instance of the target protocol adapter; receiving a specific protocol message from the external message middleware; parsing a packet header and payload of the specific protocol message, and extracting a topic, payload data, and metadata; performing deserialization operation on the payload data according to a preset serialization configuration to obtain a Java object or a business entity; constructing a complete unified event model by taking the parsed topic as a topic field, taking the deserialized object as payload content, filling the extracted metadata into a message header set, and generating a new message unique identifier; submitting the constructed unified event model to the message routing module to perform subsequent steps.

6. The multi-protocol message bus based distributed communication method of claim 5, wherein, routing the converted event model to all internal consumer applications that subscribe to the topic through the unified bus interface according to the topic field of the event model by the message routing module, and the specific steps comprise: receiving the unified event model converted by the protocol adapter by the message routing module, and extracting a topic field thereof; querying a subscription relationship registered in a topic management module according to the topic field to obtain a list of all internal consumer applications that subscribe to the topic or match the topic pattern, wherein the subscription relationship is registered in the topic management module when the upper application initiates subscription through the unified bus interface; If the subscription information indicates that the topic is a shared subscription topic, a target instance is selected from the multiple consumer instances in the shared group according to a pre-configured load balancing strategy; The unified event model is sent to each consumer instance in the obtained list of consumer applications, or to the only target consumer instance selected by the load balancing strategy; According to the indication of the quality of service level field in the unified event model, the acknowledgment of the consumer application is waited for, and if no acknowledgment is received, a retry or error handling process is performed after a timeout time is reached.

7. A multi-protocol message bus based distributed communication system, applying the multi-protocol message bus based distributed communication method of claim 1, characterized in that, comprising a unified message bus interface, a message routing module, a protocol adaptation layer module and a topic management module; the unified message bus interface is configured to provide a unified message publishing and subscription programming interface to an upper layer application, receive a sent message and construct a unified event model according to the message; the message routing module is connected with the unified message bus interface and is configured to determine one or more target protocol adapters according to a topic field in the event model and a pre-configured routing strategy, and to route an event model converted by the protocol adapter to all internal consumer applications that subscribe to the topic through the unified message bus interface according to the topic field of the event model; the protocol adaptation layer module is connected with the message routing module and comprises a plurality of pluggable protocol adapters, which are configured to convert the unified event model into a specific protocol message format and send it to a corresponding external message middleware through a client instance thereof, and to listen to and receive a specific protocol message from the external message middleware, convert it back to the unified event model and submit it to the message routing module; the topic management module is connected with the message routing module and is configured to register, store and manage subscription relationships, and provide topic verification, resolution and matching functions.

Images