Message processing method, system and equipment for message middleware and medium

Abstract

The invention discloses a message processing method for message-oriented middleware, which comprises the following steps of: in response to a registration request received by a management platform, determining the type of to-be-registered message-oriented middleware according to the registration request; obtaining and activating a corresponding adapter according to the type of the message middleware; acquiring a binder interface and a message processing interface of the adapter; and establishing connection between the message producer and the message consumer and the corresponding message middleware based on the binder interface, and processing a message sent by the message producer to the message middleware and a message sent by the message middleware to the message consumer based on the message processing interface. The invention further discloses a system, computer equipment and a readable storage medium. According to the scheme provided by the invention, unified access and management of various message middleware are realized by developing and packaging the adapter assembly.

Description

Technical Field

[0001] The present invention relates to the field of message processing, and particularly to a method, system, device, and storage medium for a message middleware to process messages. Background Art

[0002] As a key component for implementing asynchronous message passing in a distributed system, a message middleware undertakes responsibilities such as message production, consumption, routing, and storage. With the wide application of distributed systems, higher requirements are put forward for the scalability and flexibility of the message middleware.

[0003] However, traditional message middleware service access methods usually have problems such as complex access processes, poor scalability, and high maintenance costs. Therefore, a message middleware service access method that can simplify the access process, improve service scalability, and reduce maintenance costs is needed. Summary of the Invention

[0004] In view of this, in order to overcome at least one aspect of the above problems, an embodiment of the present invention provides a method for a message middleware to process messages, including the following steps:

[0005] In response to the management platform receiving a registration request, determining the type of the message middleware to be registered according to the registration request;

[0006] Obtaining and activating a corresponding adapter according to the type of the message middleware;

[0007] Obtaining the binder interface and message processing interface of the adapter;

[0008] Based on the binder interface, establishing connections between message producers and message consumers and the corresponding message middleware, and processing messages sent by the message producers to the message middleware and messages sent by the message middleware to the message consumers based on the message processing interface.

[0009] In some embodiments, establishing connections between message producers and message consumers and the corresponding message middleware based on the binder interface further includes:

[0010] Creating a message channel using the binder interface;

[0011] Receiving messages sent by the message producers and / or the message middleware based on the message channel, and sending messages to the message consumers.

[0012] In some embodiments, it further includes:

[0013] Receiving configuration parameters for the adapter on the management platform and sending them to the adapter, where the configuration parameters include connection parameters, authentication parameters, and message configuration parameters.

[0014] In some embodiments, it further includes:

[0015] Configure the configuration interface of the adapter based on the connection parameter and the authentication parameter;

[0016] Configure the resource creation interface of the adapter based on the message configuration parameter.

[0017] In some embodiments, it further includes:

[0018] Use the adapter to collect the service status and operation parameter information of the message middleware;

[0019] Send the collected service status and operation parameter information to the message service status interface of the management platform;

[0020] In response to the message service status interface of the management platform receiving the service status and operation parameter information, parse and display it.

[0021] In some embodiments, it further includes:

[0022] In response to detecting that the message middleware is unavailable, execute a pre-configured exception policy;

[0023] In response to the message middleware still being unavailable after executing the pre-configured exception policy, record the exception information and send a warning notification.

[0024] In some embodiments, it further includes:

[0025] Dynamically allocate and adjust the resources of the message middleware service based on the operation parameter information.

[0026] Based on the same inventive concept, according to another aspect of the present invention, embodiments of the present invention further provide a system for a message middleware to process messages, including:

[0027] A receiving module, configured to determine the type of the message middleware to be registered according to the registration request in response to the management platform receiving the registration request;

[0028] A first obtaining module, configured to obtain and activate a corresponding adapter according to the type of the message middleware;

[0029] A second obtaining module, configured to obtain the binder interface and the message processing interface of the adapter;

[0030] A processing module, configured to establish connections between a message producer and a message consumer and corresponding message middleware based on the binder interface, and process messages sent by the message producer to the message middleware and messages sent by the message middleware to the message consumer based on the message processing interface.

[0031] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer device, including:

[0032] At least one processor; and

[0033] A memory, the memory stores a computer program that can run on the processor, and when the processor executes the program, it executes the steps of any of the above methods for processing messages by the message middleware.

[0034] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it executes the steps of any of the above methods for processing messages by the message middleware.

[0035] One of the beneficial technical effects of the present invention is as follows:

[0036] The first step is to receive a registration request through the management platform and identify the message middleware type. It supports the access of multiple different types of message middleware, enhancing the compatibility and scalability of the system. This step realizes the automatic identification of the message middleware type, reduces manual intervention, and improves the registration efficiency. All registration operations of the message middleware are completed through the management platform, facilitating unified management and monitoring. The second step is to encapsulate different types of message middleware through the adapter component, abstracting the heterogeneous message middleware characteristics into a unified standard interface, simplifying the system design. The design of the adapter supports dynamic addition or replacement, and can support new types of message middleware without modifying the core logic, enhancing the adaptability of the system. The adapter isolates the upper-layer application from the implementation details of the specific message middleware, reducing the system complexity and the impact caused by the upgrade or replacement of the message middleware. The separation of the binder interface and the message processing interface in the third step makes the functions clearer, facilitating development, testing, and maintenance. The binder interface is responsible for establishing connections, and the message processing interface is responsible for sending and receiving messages. This division of responsibilities improves the readability and maintainability of the code. Through clear function division, different interfaces can be optimized to improve the overall performance. The fourth step is to establish a stable connection through the binder interface to ensure that message producers and consumers can communicate with the message middleware reliably. The message processing interface is specifically used for sending and receiving messages and can efficiently handle a large number of message transfer tasks. This step supports multiple message transfer modes (such as point-to-point, publish / subscribe, etc.) to meet the requirements of different business scenarios. During the message transfer process, exceptions can be captured through the binder interface and the message processing interface, and corresponding processing strategies (such as retry, warning, etc.) can be executed to improve the stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other embodiments can be obtained based on these drawings without creative efforts.

[0038] Figure 1 It is a flowchart showing the method for a message middleware to process messages provided by an embodiment of the present invention;

[0039] Figure 2 It is a structural diagram of a system for a message middleware to process messages provided by an embodiment of the present invention;

[0040] Figure 3 It is a structural diagram of a computer device provided by an embodiment of the present invention;

[0041] Figure 4Schematic diagram of the computer-readable storage medium provided by the embodiment of the present invention. Detailed implementation manners

[0042] To make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the following further describes the embodiments of the present invention in detail with reference to specific embodiments and the accompanying drawings.

[0043] It should be noted that all the expressions using "first" and "second" in the embodiments of the present invention are used to distinguish two entities or parameters with the same name but different, so it can be seen that "first" and "second" are only for the convenience of expression and should not be construed as a limitation on the embodiments of the present invention. This will not be repeated in the subsequent embodiments.

[0044] According to one aspect of the present invention, an embodiment of the present invention proposes a method for a message middleware to process messages, as Figure 1 shown, which may include the steps:

[0045] S1, in response to the management platform receiving a registration request, determining the type of the message middleware to be registered according to the registration request.

[0046] In step S1, the core is to receive a registration request from a user or a system through the management platform and parse the request to identify the specific type of the message middleware to be registered. The specific process includes the following aspects:

[0047] Source of the registration request:

[0048] The registration request can be initiated by developers, operation and maintenance personnel or automated tools.

[0049] The request usually contains key information about the message middleware to be registered, such as name, version number, protocol type (such as Kafka, RabbitMQ, RocketMQ, etc.) and other necessary configuration parameters.

[0050] Parsing the registration request:

[0051] The management platform parses the received registration request and extracts the key fields therein, such as the type identifier of the message middleware (such as kafka, rabbitmq, etc.).

[0052] If necessary information is missing in the registration request, the management platform will return an error prompt or require the information to be completed.

[0053] Determining the type of the message middleware:

[0054] According to the parsing result, the management platform determines which type the message middleware to be registered belongs to (such as Kafka, RabbitMQ, etc.).

[0055] This judgment will directly affect the subsequent selection and activation operations of the adapter.

[0056] Support for dynamic expansion:

[0057] The design of the management platform allows for the addition of support for other types of message middleware. It only requires adding the corresponding adapter components to the system and updating the type recognition logic of the management platform.

[0058] By clearly identifying the message middleware type, the system can flexibly support the access requirements of multiple different message middleware and adapt to diverse business scenarios. Centralizing the identification of the message middleware type in the management platform avoids the need for developers to manually handle complex configurations, thereby reducing the access threshold. The design of the management platform supports dynamic expansion. In the future, if new message middleware types need to be accessed, only the corresponding adapter components need to be added and the recognition logic updated, without the need for large-scale modification of the existing code. All registration operations for message middleware are completed through the management platform, facilitating unified management and monitoring and reducing the complexity brought by decentralized management. The automated type recognition mechanism reduces manual intervention and the risk of errors caused by misjudgment or omission. In a multi-tenant environment, different tenants may use different types of message middleware. Through this step, the system can accurately identify the needs of each tenant and provide personalized access services.

[0059] Suppose an enterprise is running multiple distributed applications that use Kafka and RabbitMQ as message middleware respectively. To uniformly manage these message middleware, the enterprise introduces the management platform in this method. When a new application based on RocketMQ needs to be added, the development team only needs to send a registration request containing RocketMQ-related information to the management platform. After receiving the request, the management platform automatically identifies that the message middleware type to be registered is RocketMQ and initiates the subsequent adapter selection and connection establishment process.

[0060] This mechanism not only simplifies the access process for adding new message middleware but also ensures the unity and stability of the entire system.

[0061] S2. Obtain and activate the corresponding adapter according to the type of the message middleware.

[0062] In step S2, the core is to select and activate the adapter component that matches the message middleware type determined in the previous step. The specific process includes the following aspects:

[0063] The role of the adapter:

[0064] The adapter is a component that encapsulates the implementation details of a specific message middleware and is responsible for mapping the functions of that message middleware to a unified standard interface.

[0065] It shields the differences between different message middleware, enabling upper-layer applications to not need to care about the specific implementation at the bottom layer.

[0066] Adapter selection mechanism:

[0067] According to the message middleware type determined in step S1 (such as Kafka, RabbitMQ, etc.), the system selects an adapter that matches this type from the predefined adapter pool.

[0068] If the adapter has not been loaded or initialized, it will be dynamically loaded and necessary initialization operations will be completed.

[0069] Adapter activation:

[0070] Activating the adapter means preparing it for use, which usually includes the following operations:

[0071] Loading the configuration parameters of the adapter (such as connection information, authentication information, etc.).

[0072] Initializing the internal state and resources of the adapter (such as creating a connection pool, allocating queues, etc.).

[0073] Registering the adapter to the runtime environment of the management platform for subsequent calls.

[0074] Support for dynamic expansion:

[0075] The system allows new adapter components to be added to support new message middleware types. Just develop the adapter according to the standard interface and add it to the adapter pool.

[0076] Version control and compatibility:

[0077] Different versions of message middleware may require different adapters. The system distinguishes adapters through version identifiers and ensures that the correct adapter can be selected when upgrading or switching message middleware.

[0078] The functions of different message middleware are abstracted into a unified standard interface through an adapter, which simplifies the development complexity of upper-layer applications. Upper-layer applications do not need to care about the specific implementation details of the underlying message middleware and can complete the message passing task by simply calling the standardized interface. It supports dynamically adding or replacing adapter components to adapt to different types of middleware and service requirements. When a new type of message middleware needs to be supported, only the corresponding adapter needs to be developed without modifying the core logic. The design of the adapter enables the system to flexibly handle the access requirements of multiple message middleware and meet the requirements of diverse business scenarios. The centralized adapter management mechanism reduces manual intervention and improves maintenance efficiency. If a certain message middleware needs to be upgraded or replaced, only the corresponding adapter component needs to be updated without affecting other parts. The exception handling logic of the message middleware is encapsulated inside the adapter, which can execute strategies such as retrying and warning when errors occur, thus improving the reliability of the overall system. In a multi-tenant environment, different tenants may use different types of message middleware. Through the adapter selection mechanism, the system can accurately identify the needs of each tenant and provide personalized access services.

[0079] Suppose an enterprise is running multiple distributed applications that use Kafka and RabbitMQ as message middleware respectively. To uniformly manage these message middleware, the enterprise introduces the management platform in this method. When a new application based on RocketMQ needs to be added, the system will select the adapter component corresponding to RocketMQ in the adapter pool according to the RocketMQ type identified in step S1.

[0080] Next, the system will load the configuration parameters of the adapter (such as the connection address and authentication information of RocketMQ) and complete the initialization operation (such as creating a connection pool). Finally, the activated adapter is registered into the runtime environment of the management platform so that it can be called by upper-layer applications.

[0081] This mechanism not only realizes the rapid access to RocketMQ but also ensures the unity and stability of the entire system. At the same time, if other types of message middleware (such as ActiveMQ) need to be supported in the future, only the corresponding adapter needs to be developed and added to the adapter pool without modifying other parts of the existing system.

[0082] S3. Obtain the binder interface and message processing interface of the adapter.

[0083] In step S3, the core is to obtain two key interfaces provided by the adapter component - the binder interface and the message processing interface through the adapter component and prepare for subsequent message passing operations. The specific process includes the following aspects:

[0084] Function of the binder interface:

[0085] The binder interface is responsible for establishing connections between message producers and consumers and the message middleware.

[0086] It provides functions such as creating message channels, managing connection status, and configuring queues or topics.

[0087] For example, in Kafka, the binder interface may be used to create client instances for producers and consumers and specify the target topic.

[0088] Functions of the message processing interface:

[0089] The message processing interface is responsible for handling message sending and receiving operations.

[0090] It defines how to send messages from producers to the message middleware and how to receive messages from the message middleware and deliver them to consumers.

[0091] In addition, it may also include functions such as message format conversion, serialization / deserialization, etc. to ensure the correct delivery of messages between different systems.

[0092] Ways to obtain the interfaces:

[0093] After activation, the adapter component exposes the binder interface and the message processing interface.

[0094] The system obtains these interfaces by calling the standard methods of the adapter and binds them to specific business logics.

[0095] Function separation of the interfaces:

[0096] The binder interface focuses on connection management and channel configuration, while the message processing interface focuses on message sending and receiving.

[0097] This function separation makes the design of the interfaces clearer and facilitates development, testing, and maintenance.

[0098] Support for advanced features:

[0099] The adapter may encapsulate some advanced features in the binder interface and the message processing interface, such as transactional messages, delayed messages, batch message processing, etc.

[0100] These features can be enabled through additional parameters or configuration options in the interfaces.

[0101] Separate the functions of connection management (binder interface) and message processing (message processing interface), making the system structure clearer and facilitating development and maintenance. Developers can optimize different interfaces independently to improve overall performance. The design of the binder interface and the message processing interface allows for flexible configuration of the behavior of the message middleware, such as specifying queues, topics, message formats, etc. Support multiple message delivery modes (such as point-to-point, publish / subscribe, etc.) to meet the needs of different business scenarios. Through the design of standardized interfaces, the adapter can easily support newly added advanced features (such as transactional messages, delayed messages, etc.) without modifying the core logic. Different types of adapters can reuse the same interface specifications, further enhancing the scalability of the system. The binder interface and the message processing interface encapsulate the specific implementation details of the underlying message middleware, and the upper-layer application only needs to call the standardized interface to complete complex operations. This abstraction reduces the learning cost and development difficulty of developers. An error handling mechanism (such as retry strategy, exception capture, etc.) can be integrated into the message processing interface to ensure the reliability of message delivery. The binder interface can monitor the connection status and dynamically adjust resource allocation to avoid service interruptions caused by connection problems. The binder interface and the message processing interface support dynamically configurable parameters (such as queue size, message timeout time, etc.), enabling the system to flexibly adjust its behavior according to actual needs.

[0102] Suppose an e-commerce system needs to use Kafka as the message middleware to process order events. Through step S2, the system has activated the corresponding adapter component for Kafka. Next, in step S3, the system will obtain the following interfaces from this adapter:

[0103] Binder interface: Used to create client instances of Kafka producers and consumers and specify the target topic (such as order-events).

[0104] Message processing interface: Used to send order events to the Kafka topic and receive the processed results from the Kafka topic.

[0105] The specific process is as follows:

[0106] The system calls the binder interface to create producer and consumer instances and configure relevant parameters (such as the number of partitions, replication factor, etc.).

[0107] The system serializes the order events into JSON format through the message processing interface and sends them to the Kafka topic.

[0108] Subsequent services consume messages from the Kafka topic, and after processing, write the results back to another topic.

[0109] The system receives the processing results through the message processing interface and updates the order status.

[0110] This mechanism not only simplifies the access and use of Kafka but also ensures the reliability and efficiency of message delivery. If it is necessary to switch to other message middleware (such as RabbitMQ) in the future, only the adapter component needs to be replaced without modifying the upper-layer business logic.

[0111] S4. Establish connections between the message producer and the message consumer and the corresponding message middleware based on the binder interface, and process the messages sent by the message producer to the message middleware and the messages sent by the message middleware to the message consumer based on the message processing interface.

[0112] In step S4, the core is to utilize the binder interface and the message processing interface to complete the key operations of message delivery, including establishing connections, sending messages, and receiving messages. The following is a detailed description of the specific process:

[0113] Establishing a connection based on the binder interface:

[0114] The binder interface is responsible for creating and managing the connections between the message producer and consumer and the message middleware.

[0115] It initializes the client instances of the producer and consumer through configuration parameters (such as connection addresses, authentication information, queue or topic names, etc.).

[0116] For example, in Kafka, the binder interface may be used to create KafkaProducer and KafkaConsumer objects and specify the target topic.

[0117] Sending messages based on the message processing interface:

[0118] The message processing interface defines how to send messages from the producer to the message middleware.

[0119] It is responsible for serializing the message content (such as converting a JSON object into a byte array) and sending the message to the target queue or topic by calling the channel provided by the binder interface.

[0120] During the sending process, the message processing interface can also perform some advanced operations, such as transactional messages, delayed messages, or batch sending.

[0121] Receiving messages based on the message processing interface:

[0122] The message processing interface also defines how to receive messages from the message middleware and deliver them to the consumer.

[0123] It is responsible for deserializing the message content (such as restoring a byte array to a JSON object) and passing it to the upper-layer application for further processing.

[0124] During the receiving process, the message processing interface can support multiple consumption modes (such as manual confirmation, automatic confirmation) to meet different business requirements.

[0125] Dynamic adjustment and error handling:

[0126] If an exception occurs during message delivery (such as network interruption, message format error, etc.), the message processing interface will catch the exception and trigger predefined handling strategies (such as retry, logging, sending warning notifications, etc.).

[0127] The binder interface can dynamically adjust the connection status (such as re - establishing a connection, releasing resources) to ensure the stability of the system.

[0128] Support for multi - threading and high concurrency:

[0129] The designs of the binder interface and the message processing interface generally support multi - threaded operations and can handle requests from multiple producers and consumers simultaneously.

[0130] This design enables the system to efficiently handle high - concurrency scenarios, such as the peak order period in an e - commerce system.

[0131] Through the collaboration of the binder interface and the message processing interface, the system can quickly establish connections and complete message sending and receiving operations. It supports multiple message delivery modes (such as point - to - point, publish / subscribe) and advanced features (such as transactional messages, delayed messages) to meet complex business requirements. The message processing interface integrates a complete error - handling mechanism that can execute strategies such as retry and warning when an exception occurs, avoiding service interruptions caused by single - point failures. The binder interface can dynamically monitor the connection status and adjust resource allocation in a timely manner to ensure the stable operation of the system. The binder interface and the message processing interface encapsulate the specific implementation details of the underlying message middleware, and developers only need to call standardized interfaces to complete complex operations. This abstraction reduces the development difficulty and the possibility of human errors. The designs of the binder interface and the message processing interface support dynamic adjustment of parameters (such as queue size, timeout, etc.), enabling the system to flexibly adjust its behavior according to actual needs. Different types of adapters can reuse the same interface specifications, further enhancing the scalability of the system. The designs of the binder interface and the message processing interface generally support multi - threaded operations and can handle requests from a large number of producers and consumers simultaneously. This design enables the system to efficiently handle high - concurrency scenarios and improve overall performance. The message processing interface can record detailed log information (such as message ID, sending time, receiving time, etc.) during message delivery, facilitating subsequent monitoring and problem troubleshooting. The binder interface can provide real - time data on the connection status and resource usage, helping operation and maintenance personnel optimize system performance.

[0132] Suppose a financial system needs to use RabbitMQ as a message middleware to process transaction events. Through step S3, the system has obtained the binder interface and the message processing interface. Next, in step S4, the system will perform the following operations:

[0133] Establish a connection:

[0134] The system creates client instances of RabbitMQ producers and consumers through the binder interface and specifies the target queue (such as transaction-queue).

[0135] Send a message:

[0136] The system serializes the transaction event into JSON format through the message processing interface and sends it to the RabbitMQ queue.

[0137] During the sending process, the message processing interface executes the transactional message mechanism to ensure the reliability of message delivery.

[0138] Receive a message:

[0139] Subsequent services consume messages from the RabbitMQ queue and write the results back to another queue after processing.

[0140] The system receives the processing result through the message processing interface and updates the transaction status.

[0141] Error handling:

[0142] If a network interruption occurs during the message delivery process, the message processing interface will catch the exception and execute a retry strategy.

[0143] If multiple retries fail, the system will record detailed logs and send a warning notification to the operations and maintenance personnel.

[0144] This mechanism not only realizes efficient processing of transaction events but also ensures the reliability and stability of the system. If it is necessary to switch to other message middleware (such as Kafka) in the future, only the adapter component needs to be replaced without modifying the upper-layer business logic.

[0145] In summary, in the first step, the management platform receives the registration request and identifies the message middleware type, supporting the access of multiple different types of message middleware, enhancing the compatibility and scalability of the system. This step realizes the automatic identification of the message middleware type, reduces manual intervention, and improves the registration efficiency. The registration operations of all message middleware are completed through the management platform, which is convenient for unified management and monitoring. In the second step, the adapter component encapsulates different types of message middleware, abstracting the heterogeneous message middleware features into a unified standard interface, simplifying the system design. The design of the adapter supports dynamic addition or replacement, and can support new types of message middleware without modifying the core logic, improving the adaptability of the system. The adapter isolates the upper-layer application from the implementation details of the specific message middleware, reducing the system complexity and the impact caused by the upgrade or replacement of the message middleware. In the third step, the separation of the binder interface and the message processing interface makes the functions clearer, facilitating development, testing, and maintenance. The binder interface is responsible for establishing connections, and the message processing interface is responsible for sending and receiving messages. This division of responsibilities improves the readability and maintainability of the code. Through clear function division, different interfaces can be optimized to improve the overall performance. In the fourth step, a stable connection is established through the binder interface to ensure that message producers and consumers can communicate with the message middleware reliably. The message processing interface is specifically used for sending and receiving messages and can efficiently handle a large number of message passing tasks. This step supports multiple message passing modes (such as point-to-point, publish / subscribe, etc.) to meet the requirements of different business scenarios. During the message passing process, exceptions can be captured through the binder interface and the message processing interface, and corresponding processing strategies (such as retry, warning, etc.) can be executed to improve the stability of the system.

[0146] In some embodiments, establishing the connections between the message producer and the message consumer and the corresponding message middleware based on the binder interface further includes:

[0147] Creating a message channel by using the binder interface;

[0148] Receiving messages sent by the message producer and / or the message middleware based on the message channel, and sending messages to the message consumer.

[0149] Specifically, before the adapter, since each message middleware has different design intents, technical positions, application scenarios, etc., there are also huge differences in specific implementations. This makes it very cumbersome to directly interact with different message middleware. Moreover, when the message middleware service is upgraded or the message middleware service is replaced and migrated, the cost is also very high. The present invention provides an adapter development framework to isolate each message middleware from the upper-layer application, without paying too much attention to the details of the message middleware, for simplifying the process of adapting the message middleware. Developers only need to implement the adapter interface defined in the standard interface to access a specific type of message middleware service into the system. Only one adapter component needs to be developed for each type of message middleware. Inside the adapter component, the implementation details of the specific message middleware are encapsulated, such as connection management, security authentication mechanism, message format conversion, etc. In addition, for some advanced features of the message middleware, such as message order guarantee, transactional messages, delayed messages, etc., additional configuration options are provided so that developers can make full use of these features to meet complex business requirements.

[0150] The adapter can implement standard interfaces such as the binder interface, message processing interface, adapter configuration interface, and resource creation interface.

[0151] Among them, the binder interface can provide function implementations such as creating a message channel, sending and receiving messages. The message channels of the producer and consumer are bound through the binder to connect to the external message middleware. When the message producer sends a message to the message channel, the message destination and property configuration are passed in and bound to the message channel. When the message consumer receives a message from the message channel, the message middleware target is specified, that is, from where to receive the message.

[0152] The message processing interface can define how to send a message to the message middleware and define how to process the message received from the message middleware. For example, it includes message format conversion. In the message format conversion, a message type identifier is defined, allowing the type of the message content to be specified in a configured manner, and supporting conversions such as String and byte[], object and byte[], JSON and POJO, etc.

[0153] The adapter configuration interface can provide configuration options for the adapter, such as connection factory, channel configuration, authentication information, message order, transactional messages, delayed messages, etc. The security authentication mechanism includes but is not limited to, for example, SASL / PLAN and SASL / SCRM of Kafka; ACL of RocketMQ, etc.

[0154] The resource creation interface can define how to allocate resources for the target message middleware. For example, create and configure the required resources in the message middleware, such as topics, queues, or switches, etc.

[0155] In some embodiments, it further includes:

[0156] Based on the management platform receiving configuration parameters for the adapter and sending them to the adapter, where the configuration parameters include connection parameters, authentication parameters, and message configuration parameters.

[0157] In some embodiments, it further includes:

[0158] Configure the configuration interface of the adapter based on the connection parameters and the authentication parameters;

[0159] Configure the resource creation interface of the adapter based on the message configuration parameters.

[0160] In some embodiments, it further includes:

[0161] Use the adapter to collect the service status and operation parameter information of the message middleware;

[0162] Send the collected service status and operation parameter information to the message service status interface of the management platform;

[0163] In response to the message service status interface of the management platform receiving the service status and operation parameter information, perform parsing and display.

[0164] In some embodiments, it further includes:

[0165] In response to detecting that the message middleware is unavailable, execute a pre-configured exception policy;

[0166] In response to the message middleware still being unavailable after executing the pre-configured exception policy, record the exception information and send a warning notice.

[0167] In some embodiments, it further includes:

[0168] Dynamically allocate and adjust the resources of the message middleware service based on the operation parameter information.

[0169] Specifically, an intuitive and easy-to-use user interface can be provided to display and manage all registered adapter components. This interface provides graphical operation support for functions such as registration, configuration, monitoring, and scheduling. Users register new message middleware services through the user interface or API interface of the access management platform. When registering, relevant configuration information of the adapter component needs to be provided, such as name, type, version, etc. After successful registration, users can use the configuration interface or API interface provided by the access management platform to configure the message middleware service. The configuration content includes connection information, authentication information, queue / topic settings, and other business-related parameters, etc. After configuration is completed, the access management platform will save these configuration information and apply it to the corresponding adapter components. The verification process includes checking the legality of configuration parameters, testing the connection with the message middleware, and performing some basic message sending and receiving operations, etc. After verification is passed, this message middleware service can be officially put into use.

[0170] Dynamic configuration management of message middleware services can be realized in the management platform. When the message middleware service is upgraded or replaced, it allows users to dynamically configure the message middleware by modifying the configuration parameters of the adapter component without restarting the system, reducing the impact on system services. These configuration parameters can include connection information, authentication information, topic settings, etc.

[0171] There are significant differences in the design and implementation methods of different types of message middleware. Interacting with each message middleware service separately to collect performance information would be very cumbersome. Even between different versions of the same type of message middleware, there may be differences. Currently, there is no interface to collect this information. However, performance monitoring and tuning are of great significance in the process of using message middleware. Collect and display key performance indicators of message middleware services, such as service status, message throughput, latency, loss rate, etc., to support the normal operation of the system's services. At the same time, provide the setting of warning thresholds, and send warning messages and tuning suggestions when the set thresholds are exceeded to optimize performance.

[0172] The management platform can provide monitoring of the message middleware service status. Provide a message service status interface to collect information about the message service, including but not limited to service status (running or down), system topics, memory occupancy, disk I / O, etc., according to different types of message middleware.

[0173] The management platform can also provide monitoring of message service clients. For example, the status of the client (online or offline), connection status (including the number of connections, connection time, etc.). And it supports dynamic adjustment according to the actual resource situation. For example, disconnect offline clients, or disconnect clients that are in an online state but have been idle for a long time to release resources.

[0174] The management platform can also provide message service queue monitoring. The queue monitoring collection interface of the general message service is used to obtain, for example, the status of the queue, subscriber information of the queue, throughput, latency, loss rate, accumulation volume, etc. of the queue information. Even if some message middleware does not have the concept of "queue", such as Kafka, it will be converted in the interface and return information that can be understood by users. The abnormal status detected in each of the above steps will send warning messages and provide optimization suggestions.

[0175] The management platform can also provide a perfect error handling mechanism, support configuring exception handling strategies, including exception retry configurations: interval retry (for example, execute once every 3s, execute 3 times), timed retry, exception warning recipients; and record all exception situations and error information, providing detailed log query and analysis functions so that developers can quickly locate and solve problems.

[0176] The error handling mechanism includes exception retry and instant warning. When an exception occurs, it supports retrying according to the exception strategy. If the retry fails, an instant warning will be sent to notify relevant personnel, and at the same time, detailed exception information will be recorded. Provide an exception query function to query detailed exception information and support operations on exceptions. For example: if it is confirmed through analysis that the exception has no impact on the system, an ignore operation can be executed to ignore this exception, and the ignored exception will be removed from the retry list.

[0177] For example, during operation, if the message middleware service is unavailable and the message is unreachable, the pre-configured exception strategy will be executed first. If it fails to execute successfully, the exception will be notified to the configured exception recipient, and detailed exception information during the process will be recorded.

[0178] The management platform can also implement a dynamic scheduling algorithm to dynamically allocate and adjust the resources of the message middleware service according to the business requirements of the system. At the same time, adopt a load balancing strategy to ensure that the load is evenly distributed among message middleware, improving the overall performance and stability of the system.

[0179] For example, if the data volume of the system business is very large during a certain period of time, if all are executed in one message middleware service, the execution efficiency is not high. If multiple message middleware services are connected at this time, these services will be distributed to multiple message middleware services for execution according to the resource situation of the message middleware service. If only one message middleware service is connected, it will also be dynamically allocated to multiple queues for execution according to the priority to ensure that high-priority services are executed first and the execution efficiency is improved.

[0180] The management platform can also adopt security measures such as identity authentication, access control, and data encryption to protect sensitive information and prevent malicious attacks. Ensure the confidentiality, integrity, and availability of messages during transmission and storage.

[0181] The present invention defines the access standard interfaces for message middleware services. These interfaces not only cover the core functions such as message production, consumption, routing, storage, and management, but also specify in detail the data formats of the interfaces, interaction protocols, exception handling mechanisms, and performance requirements. In addition, the interface design takes into account version control and compatibility to ensure a smooth transition during interface upgrades and reduce the impact on the accessing services. Moreover, to ensure the compatibility and scalability of the interfaces, a version control strategy is implemented. Each interface should have a unique version number to maintain backward compatibility when the interface is upgraded or modified.

[0182] Secondly, the present invention provides a development framework and guidelines for adapter components to encapsulate the implementation details of message middleware services of specific types or protocols. By implementing the access standard interfaces, the adapter components uniformly map the characteristics of different message middleware services onto the standard interfaces, thus achieving unified access and invocation of services. The adapter components also support the abstraction and encapsulation of advanced features of message middleware services, such as message order guarantee, transactional messages, delayed messages, and batch message processing, etc., to meet more complex business requirements.

[0183] Thirdly, the present invention constructs an access management platform that provides a visual operation interface or API interfaces for managing functions such as registration, configuration, monitoring, and scheduling of adapter components. The access management platform has good scalability and maintainability, supports dynamically adding, deleting, or modifying adapter components, and takes effect without restarting the system. The platform also provides rich monitoring and diagnostic functions, which can understand the running status, performance metrics, and exception situations of the services in real time, helping developers quickly locate and solve problems.

[0184] Fourthly, in terms of service registration and configuration, the present invention provides a set of flexible and easy-to-use mechanisms. Service providers can register and configure adapter components through the access management platform, and set configuration parameters such as connection information, authentication information, and queues or topics of the message middleware. The platform supports dynamic loading and updating functions based on configuration files, enabling service providers to adjust configuration parameters without restarting the system to meet the ever-changing business requirements.

[0185] Finally, in terms of service scheduling, the present invention adopts a load balancing algorithm and a dynamic weight adjustment strategy to achieve uniform distribution and efficient utilization of message middleware services. The scheduling mechanism takes into account the system load conditions and business requirements, and can dynamically adjust the resource allocation and priority settings of services to ensure the stability and performance of the system. At the same time, the present invention also provides error handling and logging mechanisms, which can capture and record error information. These mechanisms also support classification processing of exception situations, archiving, and analysis functions of error logs, helping developers quickly locate and solve problems.

[0186] In summary, the present invention provides an extensible method for accessing message middleware services by defining an access standard interface, developing adapter components, building an access management platform, and implementing functions such as service registration, configuration, and scheduling. This method not only simplifies the access process of message middleware services, improves the scalability of the system, and reduces maintenance costs, but also adapts to changing business requirements and technical environments. Through the implementation of the present invention, enterprises can quickly integrate different message middleware services onto a unified platform for management and scheduling, improving the overall performance and reliability of the system.

[0187] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention also provides a system 400 for a message middleware to process messages, as Figure 2 shown, including:

[0188] A receiving module 401, configured to determine the type of the message middleware to be registered according to the registration request in response to the management platform receiving the registration request;

[0189] A first acquisition module 402, configured to acquire and activate a corresponding adapter according to the type of the message middleware;

[0190] A second acquisition module 403, configured to acquire the binder interface and the message processing interface of the adapter;

[0191] A processing module 404, configured to establish connections between message producers and message consumers and corresponding message middleware based on the binder interface, and process messages sent by the message producers to the message middleware and messages sent by the message middleware to the message consumers based on the message processing interface.

[0192] In some embodiments, establishing connections between message producers and message consumers and corresponding message middleware based on the binder interface further includes:

[0193] Creating a message channel using the binder interface;

[0194] Receiving messages sent by the message producers and / or the message middleware based on the message channel, and sending messages to the message consumers.

[0195] In some embodiments, it further includes:

[0196] Receiving configuration parameters for the adapter based on the management platform and sending them to the adapter, where the configuration parameters include connection parameters, authentication parameters, and message configuration parameters.

[0197] In some embodiments, it further includes:

[0198] Configure the configuration interface of the adapter based on the connection parameters and the authentication parameters;

[0199] Configure the resource creation interface of the adapter based on the message configuration parameters.

[0200] In some embodiments, it further includes:

[0201] Use the adapter to collect the service status and operation parameter information of the message middleware;

[0202] Send the collected service status and operation parameter information to the message service status interface of the management platform;

[0203] In response to the message service status interface of the management platform receiving the service status and operation parameter information, parse and display it.

[0204] In some embodiments, it further includes:

[0205] In response to detecting that the message middleware is unavailable, execute a pre-configured exception policy;

[0206] In response to the message middleware still being unavailable after executing the pre-configured exception policy, record the exception information and send a warning notice.

[0207] In some embodiments, it further includes:

[0208] Dynamically allocate and adjust the resources of the message middleware service based on the operation parameter information.

[0209] Based on the same inventive concept, according to another aspect of the present invention, as Figure 3 shown, an embodiment of the present invention further provides a computer device 501, including:

[0210] At least one processor 520; and

[0211] A memory 510, the memory 510 stores a computer program 511 that can run on the processor, and when the processor 520 executes the program, it executes the steps of any of the above methods for the message middleware to process messages.

[0212] Based on the same inventive concept, according to another aspect of the present invention, as Figure 4 shown, an embodiment of the present invention further provides a computer-readable storage medium 601, the computer-readable storage medium 601 stores a computer program 610, and when the computer program 610 is executed by a processor, it executes the steps of any of the above methods for the message middleware to process messages.

[0213] Finally, it should be noted that those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods.

[0214] In addition, it should be understood that the computer-readable storage medium herein (e.g., memory) can be a volatile memory or a non-volatile memory, or can include both volatile memory and non-volatile memory.

[0215] Those skilled in the art will also understand that the various exemplary logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, a general description of the functions of various illustrative components, blocks, modules, circuits, and steps has been given. Whether this function is implemented as software or hardware depends on the specific application and the design constraints imposed on the overall system. The functions that those skilled in the art can implement in various ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the disclosure of the embodiments of the present invention.

[0216] The above are the exemplary embodiments disclosed by the present invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the disclosure of the embodiments of the present invention as defined by the claims. The functions, steps, and / or actions of the method claims according to the disclosed embodiments herein do not need to be performed in any specific order. In addition, although the elements disclosed in the embodiments of the present invention can be described or claimed in individual form, they can also be understood as plural unless explicitly limited to the singular.

[0217] It should be understood that as used herein, unless the context clearly supports an exception, the singular form "a" is also intended to include the plural form. It should also be understood that the "and / or" used herein refers to any and all possible combinations of one or more of the associated listed items.

[0218] The serial numbers of the disclosed embodiments of the present invention above are only for description and do not represent the superiority or inferiority of the embodiments.

[0219] Those of ordinary skill in the art can understand that all or part of the steps of implementing the above embodiments can be completed by hardware, or can be completed by instructing relevant hardware through a program. The program can be stored in a computer-readable storage medium, and the above-mentioned storage medium can be a read-only memory, a disk, an optical disc, etc.

[0220] Those of ordinary skill in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the disclosure of the embodiments of the present invention (including the claims) is limited to these examples; under the concept of the embodiments of the present invention, the technical features in the above embodiments or different embodiments can also be combined, and there are many other variations in different aspects of the embodiments of the present invention as above, which are not provided in detail for the sake of brevity. Therefore, any omission, modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of the present invention shall be included within the protection scope of the embodiments of the present invention.

Claims

1. A method for processing messages by a message middleware, characterized in that: The following steps are involved: In response to the management platform receiving the registration request, determining the type of the message middleware to be registered according to the registration request; Obtain and activate the corresponding adapter according to the type of the message middleware; Obtaining the adapter's binder interface and message processing interface; The connection between the message producer and the message consumer and the corresponding message middleware is established based on the binder interface, and the message sent by the message producer to the message middleware and the message sent by the message middleware to the message consumer are processed based on the message processing interface.

2. The method according to claim 1, characterized in that Establishing a connection between the message producer and the message consumer and the corresponding message middleware based on the binder interface further includes: Creating a message channel using the binder interface; Receive the message sent by the message producer and / or the message middleware based on the message channel, and send the message to the message consumer.

3. The method according to claim 1, characterized in that Also includes: The configuration parameters for the adapter are received based on the management platform and sent to the adapter, wherein the configuration parameters include connection parameters, authentication parameters and message configuration parameters.

4. The method according to claim 3, characterized in that Also includes: configuring a configuration interface of the adapter based on the connection parameters and the authentication parameters; The resource creation interface of the adapter is configured based on the message configuration parameters.

5. The method according to claim 1, characterized in that Also includes: Using the adapter to collect the service status and operation parameter information of the message middleware; Sending the collected service status and operating parameter information to the message service status interface of the management platform; In response to the message service status interface of the management platform receiving the service status and operation parameter information, the service status and operation parameter information are parsed and displayed.

6. The method according to claim 5, characterized in that Also includes: In response to detecting that the message middleware is unavailable, executing a pre-configured exception strategy; In response to the message middleware still being unavailable after executing the pre-configured exception strategy, the exception information is recorded and an early warning notification is sent.

7. The method according to claim 5, characterized in that Also includes: The resources of the message middleware service are dynamically allocated and adjusted based on the operation parameter information.

8. A system for processing messages using a message middleware, characterized in that: include: A receiving module, configured to determine the type of message middleware to be registered according to the registration request in response to the management platform receiving the registration request; A first acquisition module, configured to acquire and activate a corresponding adapter according to the type of the message middleware; A second acquisition module is configured to acquire a binder interface and a message processing interface of the adapter; The processing module is configured to establish a connection between the message producer and the message consumer and the corresponding message middleware based on the binder interface, and to process the message sent by the message producer to the message middleware and the message sent by the message middleware to the message consumer based on the message processing interface.

9. A computer device comprising: at least one processor; as well as A memory storing a computer program executable on the processor, wherein the processor executes the steps of the method according to any one of claims 1 to 7 when executing the program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are performed.

Images