Message processing method, device, electronic device and storage medium

Abstract

The embodiments of the present application disclose a message processing method, device, electronic device and storage medium. The method is applied to a system including a message integration end and a message consumption end, including: monitoring event messages of the message integration end, the event messages including service internal event messages and cross-service event messages; based on the listeners corresponding to the service internal event messages and cross-service event messages, sending the event messages to the adapter of the message consumption end; determining the target processor corresponding to the event message based on the event class of the event message through the adapter; processing the event message based on the target processor to obtain the processing result corresponding to the event message. The embodiments of the present application enable each listener to be responsible for monitoring event messages of a specific type and forwarding them to the corresponding processor for processing, so that the business logic of the system is clearer, easier to understand and maintain.

Description

Technical Field

[0001] The present application relates to the technical field of communication architecture, and in particular to a message processing and generating method, device, electronic device, and computer-readable storage medium. Background Art

[0002] With the advancement of technology, the Bocsoft Framework Works (BFW) software framework, a standardized Java application development platform, provides a rich set of technical components, including multi-channel integration, user permission control, transaction processing, component-based asset management and reuse, and third-party technology integration. It also provides a standard MVC programming model and transaction processing flow. BFW can process user-submitted transactions.

[0003] Existing software frameworks solely use message middleware as a message bus, such as Kafka and RabbitMQ. Although message middleware has high performance and high throughput, using it for internal service communication wastes resources and lacks business scalability. There is no unified business architecture design for message sending and receiving, which increases the difficulty of code development and management. Summary of the Invention

[0004] To solve the above technical problems, embodiments of the present application provide a message processing method and device, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] According to one aspect of an embodiment of the present application, a message processing method is provided, which is applied to a system including a message integration end and a message consumption end, including: monitoring event messages of the message integration end, the event messages including service internal event messages and cross-service event messages; sending the event messages to an adapter of the message consumption end based on the listeners corresponding to the service internal event messages and the cross-service event messages; determining, through the adapter, a target processor corresponding to the event message based on the event class of the event message; processing the event message based on the target processor to obtain a processing result corresponding to the event message.

[0006] According to one aspect of an embodiment of the present application, the internal service message includes an asynchronous event message, and the method further includes: sending the asynchronous event message to the adapter of the message consumer end through a listener; determining the target processor through the adapter based on the event class corresponding to the asynchronous event message; and sending the asynchronous event message to a thread pool to implement asynchronous processing of the asynchronous event message based on the thread pool.

[0007] According to one aspect of an embodiment of the present application, the method also includes: sending the cross-service event message to a preset processor to obtain status data corresponding to the cross-service event message through the preset processor; if the status data indicates that the cross-service event message is not processed, sending the cross-service event message to the target processor.

[0008] According to one aspect of an embodiment of the present application, the status data includes an identity identifier corresponding to the cross-service event message, and the method further includes: obtaining a content hash value corresponding to the cross-service event message based on the identity identifier, the content hash value being in the consumption history record of the cross-service event message; if the content hash value is empty, the result of the cross-service event message being unprocessed is obtained.

[0009] According to one aspect of an embodiment of the present application, before processing the event message based on the target processor and obtaining the processing result corresponding to the event message, the method also includes: obtaining the message format, message content and message source of the event message; if the event message is determined to be legal based on the message format, the message content and the message source, converting the message format of the event message into a target message format; and sending the event message in the target message format to the target processor.

[0010] According to one aspect of an embodiment of the present application, determining the target processor corresponding to the event message based on the event class of the event message through the adapter includes: obtaining the event class corresponding to the event message and the subclass of the event class through the adapter; and determining the target processor corresponding to the event message based on a preset mapping relationship between the event class and the subclass of the event class and the processor.

[0011] According to one aspect of an embodiment of the present application, the method further includes: determining the business scenario and message routing corresponding to the event message based on the event class and the event subclass; and determining the target processor corresponding to the event message based on the business scenario and the message routing.

[0012] According to one aspect of an embodiment of the present application, the device is applied to a system including a message integration end and a message consumption end, and includes: a monitoring module for monitoring event messages of the message integration end, wherein the event messages include service internal event messages and cross-service event messages; a sending module for sending the event messages to an adapter of the message consumption end based on the listeners corresponding to the service internal event messages and the cross-service event messages; a determination module for determining the target processor corresponding to the event message based on the event class of the event message through the adapter; and a processing module for processing the event message based on the target processor to obtain a processing result corresponding to the event message.

[0013] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the message processing method as described above.

[0014] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer executes the message processing method described above.

[0015] According to one aspect of an embodiment of the present application, a computer program product is further provided, including a computer program, which implements the steps in the message processing method described above when executed by a processor.

[0016] In the technical solution provided in the embodiments of the present application, by monitoring the service internal event messages and cross-service messages of the message integration end and sending them to their corresponding listeners, it is achieved that by decoupling the sender and receiver of the message, it is easier to add new services or modify existing services without the need for large-scale reconstruction of the overall architecture. Then, by defining multiple listeners and processors, complex business logic can be handled flexibly, and each listener can be responsible for listening to a specific type of event message and forwarding it to the corresponding processor for processing, making the system's business logic clearer, easier to understand and maintain.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings are incorporated into and constitute a part of the specification, illustrating embodiments consistent with the present application and, together with the specification, serving to explain the principles of the present application. It is obvious that the drawings described below are merely some embodiments of the present application, and a person of ordinary skill in the art can derive other drawings based on these drawings without inventive effort. In the drawings:

[0019] Figure 1 This is a schematic diagram of an implementation environment for message processing shown in an exemplary embodiment of the present application;

[0020] Figure 2 is a flowchart of a message processing method shown in an exemplary embodiment of the present application;

[0021] Figure 3is a flowchart of a message processing method shown in another exemplary embodiment of the present application;

[0022] Figure 4 is a flowchart of a message processing method shown in another exemplary embodiment of the present application;

[0023] Figure 5 is a flowchart of a message processing method shown in another exemplary embodiment of the present application;

[0024] Figure 6 is a flowchart of a message processing method shown in another exemplary embodiment of the present application;

[0025] Figure 7 is a flowchart of a message processing method shown in another exemplary embodiment of the present application;

[0026] Figure 8 is a flowchart of a message processing method shown in another exemplary embodiment of the present application;

[0027] Figure 9 is a schematic diagram showing the relationship between a processor and an event class according to an exemplary embodiment of the present application;

[0028] Figure 10 is a schematic diagram of a message processing architecture shown in an exemplary embodiment;

[0029] Figure 11 is a block diagram of a message processing device shown in an exemplary embodiment of the present application;

[0030] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0031] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0032] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0033] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0034] In this application, "plurality" refers to two or more. "And / or" describes the relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0035] First, it's important to note that a message bus is a middleware technology used to enable communication between components or services in a distributed system. It's similar to a data bus on a motherboard, capable of data transmission and exchange. However, the parties don't communicate directly, but instead use the bus as a standard communication interface. A message bus is a cross-process communication mechanism used to pass messages between upstream and downstream processes. It can connect nodes in a distributed system with a lightweight messaging system, integrating Java's event handling mechanisms with messaging middleware functionality to manage and propagate messages between distributed systems. A message bus can be applied to areas such as SOA (Service-Oriented Architecture) and EIP (Enterprise Integration Patterns), and is a powerful tool for decoupling systems. Its main features are: decoupling: the message bus can effectively decouple publishers and subscribers, decoupling upstream and downstream message delivery into two parts, so that upstream message sending only relies on the message bus, and does not need to rely on other services logically or physically; scalability: the message bus can be easily expanded to support more components and message types, adapting to the growing needs of distributed systems; elasticity: providing buffers between components to improve the elasticity and fault tolerance of the system; reliability: ensuring reliable message transmission through mechanisms such as message landing, message timeout, retransmission, and confirmation.

[0036] Figure 1 This is a schematic diagram of a message processing framework shown in an exemplary embodiment of the present application. Figure 1 As shown, the framework structure of message processing includes a message integration terminal 100, wherein the message integration terminal includes multiple message pushers and listeners, which can listen to event messages from specific types from different todays, and then the listener sends the monitored event messages to the message consumption terminal 200. Specifically, the listener sends the monitored event messages to the adapter of the message consumption terminal, so that the adapter can determine the target processor corresponding to the event message based on the event class corresponding to the event message, and then process the event message through the target processor to obtain the processing result corresponding to the event message.

[0037] Among them, message pushers can include the following:

[0038] a) SyncEventPusher: Purpose: Enables instant messaging within services, ensuring rapid message delivery and processing. Suitable for scenarios requiring high timeliness. Mechanism: Directly delivers events to listeners (EventListeners), reducing queue waiting time and prioritizing processing speed and efficiency.

[0039] b) AsyncEventPusher (asynchronous event pusher) is used to handle tasks within the service that do not require immediate feedback, such as background data processing and logging. Events are pushed to the message queue and then processed asynchronously by consumers, improving the system's processing capabilities and effectively sharing instantaneous high loads.

[0040] c) KafkaMessagePusher (Kafka message pusher), supports high-throughput distributed scenarios and is suitable for cross-service and cross-data center communication. Through Kafka's distributed messaging system, events can be stably and reliably delivered to multiple service consumers, supporting data persistence and partitioning, and enhancing the scalability and fault tolerance of messaging.

[0041] Listeners can include: a) EventListener, which receives events from synchronous or asynchronous pushers and performs preliminary processing or distribution. It is suitable for handling quick responses or simple internal service messages; b) KafkaMessageConsumer, which specifically consumes messages pushed via Kafka. Kafka's high performance ensures efficient cross-service communication in distributed systems, while its idempotence design and development guarantee reliable message consumption.

[0042] Existing software frameworks use message middleware alone as a message bus, such as Kafka, RabbitMQ, etc. Although message middleware has high performance and high throughput, it is used for internal communication in services, which will cause a waste of resources. At the same time, it lacks business scalability. There is no unified business architecture design for sending and receiving messages, which increases the difficulty of code development and management. The problems pointed out above are generally applicable in general message processing scenarios. In order to solve these problems, the embodiments of the present application respectively propose a message processing method, a message processing device, an electronic device, a computer-readable storage medium and a computer program product, which will be described in detail below.

[0043] See also Figure 2 , Figure 2This is a flowchart of a message processing method shown in an exemplary embodiment of the present application. This method can be applied to Figure 1 It should be understood that the implementation environment shown is that the method can also be applied to other exemplary implementation environments and specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0044] like Figure 2 As shown, in an exemplary embodiment, applied to a system including a message integration end and a message consumption end, the specific implementation process of message processing may also include steps S210 to S240, which are described in detail as follows:

[0045] Step S210: monitor event messages from the message integration terminal, where the event messages include service internal event messages and cross-service event messages.

[0046] Specifically, the event messages received by the message integration terminal are monitored. These event messages include event messages pushed by the service's internal message pusher as well as cross-service event messages pushed by external systems. Internal event messages are messages generated and processed within a single service. These messages are typically used for communication between different components within a service, such as between the business logic layer and the data access layer. Cross-service event messages are events transmitted between different services, used to achieve decoupling and asynchronous communication between services.

[0047] For example, an event bus pattern is used to transmit events between different components within a service. An event bus allows for a publish / subscribe model, where one component publishes events, and other components can subscribe to and respond to them. In some scenarios, the observer pattern can be used to implement event monitoring. For example, an object (a subject) maintains a list of dependent objects (observers). When this object changes its state, it notifies all dependent objects, thereby implementing event message monitoring. For cross-service messaging, a message queue (such as RabbitMQ or Kafka) is often used to transmit event messages between services. Service A sends an event message to a queue, and service B subscribes to the queue and processes the message. This approach achieves high reliability and scalability, similar to a message queue, but with a focus on event publishing and subscription. Service A publishes an event, and any service interested in the event can subscribe to receive notifications. In a service mesh, inter-service communication and event delivery can be implemented through sidecar proxies. While a service mesh primarily handles network requests between services, it can also be configured to listen for and forward event messages.

[0048] Step S220 : Based on the listeners corresponding to the service internal event message and the cross-service event message, the event message is sent to the adapter of the message consumption end.

[0049] Specifically, the monitored event messages can be sent to the adapter according to different listeners. As mentioned in the above embodiment, the listeners corresponding to the internal event messages of the service and the listeners corresponding to the cross-service event messages are different, and then the event messages are sent to the adapter according to the listeners corresponding to the event messages.

[0050] For example, in distributed systems, event-driven architecture (EDA) is a common design pattern that uses asynchronous events to communicate information between different parts of the system. In this architecture, events occurring between or within services trigger listeners that listen to these events. These listeners then process the events or pass them on to other components. To efficiently send event messages to adapters consuming messages, it's necessary to clearly define the data structures of intra-service and inter-service events. These events typically contain the event type, event data (e.g., in JSON or XML format), and possibly other metadata (e.g., timestamp, event source, etc.). For each event type, a listener is created. The listener is responsible for receiving the event and performing specific processing logic. This logic may include validating the event data, converting data formats, or invoking other services. A message queue (e.g., RabbitMQ, Kafka) or an event bus (e.g., Apache Kafka, Azure Event Hubs) is used as an intermediate storage and routing system for event messages. These systems ensure asynchronous message processing, high availability, and scalability.

[0051] The adapter pattern is a structural design pattern used to convert a class's interface into another interface expected by the client. In event-driven architectures, adapters are often used to convert event messages from one format or protocol to another to accommodate different consumers. Adapters are implemented based on the needs of message consumers. These adapters receive messages from a message queue or event bus, parse the message content, convert it to the format required by the consumer, and then call the consumer's API or method.

[0052] Step S230: The adapter determines the target processor corresponding to the event message based on the event class of the event message.

[0053] Specifically, the adapter first listens to event messages from the message middleware. When messages arrive, the adapter receives them and stores them in an internal buffer or processes them directly. The adapter needs to parse the event messages to extract key information, especially the event class (that is, the type or identifier of the event). The event class can be a field of the message or part of the message body, depending on the definition and format of the event message. The adapter maintains a mapping table or strategy internally to map event classes to corresponding target processors. This mapping table can be configured when the adapter is initialized, and can also be dynamically updated to adapt to new event types or processor changes.

[0054] The mapping between event classes and processors includes static mapping and dynamic mapping. Static mapping refers to directly defining the mapping relationship between event classes and processors in the adapter code, while dynamic mapping refers to dynamically obtaining the mapping relationship through configuration files, databases, or external services.

[0055] Step S240: Process the event message based on the target processor to obtain a processing result corresponding to the event message.

[0056] Specifically, once the target handler corresponding to the event message is determined, the adapter calls the corresponding method of the handler to process the event. This typically involves passing the event message as a parameter to the handler method and may include exception handling and result collection. After the target handler processes the event, it may produce some results or require some subsequent operations (such as sending a response, updating a database, etc.). The adapter is responsible for processing these results or performing subsequent operations and feeding back the necessary information to the message middleware or caller.

[0057] In this embodiment, by monitoring the service internal event messages and cross-service messages of the message integration terminal and sending them to their corresponding listeners, it is achieved that by decoupling the sender and receiver of the message, it is easier to add new services or modify existing services without the need for large-scale reconstruction of the overall architecture. Then, by defining multiple listeners and processors, degaussing processing can flexibly handle complex business logic. Each listener can be responsible for listening for a specific type of event message and forwarding it to the corresponding processor for processing. This approach makes the system's business logic clearer, easier to understand and maintain.

[0058] Further, based on the above embodiment, please refer to Figure 3 In one of the exemplary embodiments provided in this application, the above-mentioned service internal message includes an asynchronous event message. The specific implementation process of the above-mentioned message processing method may further include steps S310 to S330, which are described in detail as follows:

[0059] Step S310, sending the asynchronous event message to the adapter of the message consumer through the listener;

[0060] Step S320, determining the target processor based on the event class corresponding to the asynchronous event message through the adapter;

[0061] Step S330: Send the asynchronous event message to the thread pool to implement asynchronous processing of the asynchronous event message based on the thread pool.

[0062] Specifically, the AsyncEventPusher on the message integration side can be used to handle tasks within the service that don't require immediate feedback, such as background data processing and logging. Events are pushed to a message queue and then processed asynchronously by consumers, improving system processing capacity and effectively distributing transient high loads. Listeners, in turn, monitor asynchronous events occurring in the system. When events occur, the listener captures them, encapsulates them into event messages, and sends them to the adapter. This process may involve placing event messages into a message queue (such as RabbitMQ or Kafka) or directly sending them to the adapter via some form of inter-process communication (IPC) mechanism. The adapter is a middleware component that receives asynchronous event messages from the listener and, based on the event class (or type) in the event message, determines the target handler to invoke to handle the event. Once the adapter determines the target handler, it sends the asynchronous event message to the thread pool. This typically involves encapsulating the event message into a task and submitting it to the thread pool for execution. Worker threads in the thread pool process these tasks in parallel or serially. Each task invokes its corresponding target handler to process the event message. Because processing occurs asynchronously in a thread pool, it does not block the original event delivery process. A thread pool is a concurrent framework based on pooling technology that manages a group of worker threads. This allows the system to efficiently execute a large number of concurrent tasks while reducing the overhead of thread creation and destruction. Furthermore, the adapter typically maintains a mapping table or rule set that maps event classes to corresponding target handlers. This mapping can be statically configured or dynamically generated.

[0063] In this embodiment, by sending messages to the thread pool for asynchronous processing, the system can immediately respond to new requests or operations without waiting for the current event processing to be completed, which greatly improves the responsiveness and throughput of the system. The design of listeners and adapters enables the system to flexibly handle different types of asynchronous events, which can improve the scalability and flexibility of the system. In addition, the use of listeners, adapters and thread pools enhances the decoupling between system components and can improve the maintainability of the system.

[0064] Further, based on the above embodiment, please refer to Figure 4 In one of the exemplary embodiments provided in this application, the specific implementation process of the above message processing method may further include step S410 and step S420, which are described in detail as follows:

[0065] Step S410: Send the cross-service event message to a preset processor, so as to obtain status data corresponding to the cross-service event message through the preset processor.

[0066] Specifically, the adapter can include a pre-defined handler for event preprocessing. This pre-defined handler ensures data quality and format consistency at the consumer end of incoming messages and also facilitates debugging and monitoring of message flows. Furthermore, as the system evolves, more message processing methods may be added. Adapters make these changes more flexible, requiring only adjustments to the adapter layer without requiring major changes to business logic or other system components, resulting in highly scalable architecture.

[0067] For example, in software development or system design, EventHandlerAdaptor plays a crucial role. Within EventHandlerAdaptor, a series of pre-processing operations are designed and developed. For example, methods like eventMessageCheck, formatConvert, and operationLog typically handle different aspects or stages of a specific event. These are described below:

[0068] eventMessageCheck(Event) Function Description: The primary purpose of the eventMessageCheck method is to validate or check incoming event messages. This may include checking whether the message format is correct, whether the message content conforms to expected specifications, and whether the message source is trustworthy. Depending on the check results, this method may return different values ​​or throw exceptions to indicate whether the message is valid or requires further processing. Application Scenario: In event-driven systems, ensure that only valid messages are processed further. Pre-validate received messages on the consumer side of API calls or message queues.

[0069] formatConvert(Event) Function Description: The formatConvert method is responsible for converting incoming event messages from one format to another. This conversion may involve converting data structures, data types, or encodings. This method is often used to resolve data format incompatibilities between different systems or components. Application Scenario: In a microservices architecture, data exchange between different services may require a unified data format. When interacting with external systems (such as third-party APIs), this method converts internal data formats to the format required by the external system.

[0070] operationLog(Event) Function Description: The operationLog method is used to log the operations associated with an incoming event. This may include the type of operation, the timestamp of the operation, the result of the operation (success or failure), and any relevant user information (if the event was triggered by a user). This method is crucial for system monitoring, troubleshooting, and auditing. Application Scenarios: Anywhere system operations need to be tracked and recorded. In systems that need to comply with specific regulations or standards (such as GDPR and HIPAA), logging user behavior or sensitive operations is essential.

[0071] These three methods (eventMessageCheck, formatConvert, and operationLog) play distinct roles in event processing, but together they constitute key steps in the event processing pipeline. They ensure event correctness, interchangeability, and traceability, and are essential components for building reliable, efficient, and scalable systems. In practice, the implementation details and specific logic of these methods may vary depending on the system's requirements and constraints.

[0072] Step S420: If the status data indicates that the cross-service event message is not processed, the cross-service event message is sent to the target processor.

[0073] Specifically, the system needs to continuously monitor the status of cross-service event messages. This is usually achieved by querying the metadata of the database, cache, or message queue. When the system detects that the status data of a cross-service event message indicates that the message has not been processed, further actions will be triggered. Based on the type, content, or other metadata of the event message, the system needs to determine which service or component (ie, the target processor) should process the message. If the target processor successfully processes the message and returns a successful response, the system should update the status of the message to "processed". It is also necessary to ensure that the target processor can process duplicate messages to avoid side effects caused by message retries, set a reasonable timeout for message processing, and execute the retry logic after the timeout.

[0074] Idempotence is a crucial concept in distributed systems and event-driven architectures. It ensures that an operation (such as message processing) remains consistent regardless of how many times it is executed. This is particularly important for handling duplicate messages, network retransmissions, and user errors.

[0075] In this embodiment, by using a pre-configured processor to perform status checks on cross-service event messages, we can ensure that messages are verified before being sent to the target processor, avoiding duplicate or missed processing and thus improving the overall reliability and stability of the system. Using the pre-configured processor as an intermediary layer makes it easier to add or modify the processing logic for cross-service event messages without having to directly modify the target processor code. This design makes the system more modular and enhances its scalability and flexibility.

[0076] Further, based on the above embodiment, please refer to Figure 5 In one of the exemplary embodiments provided in this application, the state data includes an identity identifier corresponding to the cross-service event message, and the message processing process may further include steps S510 and S520, which are described in detail as follows:

[0077] Step S510: Obtain a content hash value corresponding to the cross-service event message based on the identity identifier, where the content hash value is recorded in the consumption history of the cross-service event message;

[0078] Step S520: If the content hash value is empty, a result indicating that the cross-service event message is not processed is obtained.

[0079] Specifically, when processing cross-service event messages, using identifiers (such as message IDs, event type IDs, etc.) to associate and obtain the content hash value of a specific message is an effective way to verify whether the message has been processed. A content hash value (such as MD5, SHA-1, SHA-256, etc.) is a data summary that can uniquely represent the content of a piece of data. Even if the data changes slightly, its hash value will be significantly different.

[0080] When a cross-service event message is received, the identity of the message (such as the message ID) is first parsed. Using the identity as the query condition, the corresponding content hash value is searched in the consumption history of the cross-service event message. This consumption history may be stored in the metadata of the database, cache, or message queue. The query result will return information related to the content hash value. If the query result is empty (that is, the corresponding content hash value is not found), it means that the cross-service event message has not been processed. Based on the query results, the system can make logical judgments. If the content hash value is empty, the message is marked as "unprocessed"; if the content hash value exists, the processing status of the message (such as "processed", "processing", etc.) can be further judged as needed.

[0081] If it is determined that the cross-service event message is not processed, the system should send the message to the target processor for processing. Before or after processing the message, the system should update the consumption history and associate the newly generated content hash value with the message identity so that the message processing status can be verified in the future.

[0082] In this embodiment, the content hash value serves as a unique identifier for cross-service event messages, ensuring the uniqueness and accuracy of messages during transmission and processing. By comparing hash values, the system can accurately identify whether the same message has already been processed, avoiding duplicate processing and ensuring idempotence of message processing.

[0083] Further, based on the above embodiment, please refer to Figure 6 In an exemplary embodiment of the present application, before the adapter determines the target processor corresponding to the event message based on the event class of the event message, the specific implementation process of the message processing may further include steps S610 to S630, which are described in detail as follows:

[0084] Step S610, obtaining the message format, message content and message source of the event message;

[0085] Step S620: If the event message is determined to be legitimate based on the message format, message content, and message source, the message format of the event message is converted into the target message format;

[0086] Step S630: Send the event message in the target message format to the target processor.

[0087] Specifically, after receiving the event message sent by the listener, the adapter needs to verify the message format, message content and message source of the event message, among which the message format: this usually refers to the message encoding method, structure definition (such as JSON, XML, Protobuf, etc.) and possible version information; the message content: the actual data part of the message, which contains the information to be transmitted; and the message source: refers to the identifier of the service or system that sent the message, which is used to verify whether the source of the message is trustworthy.

[0088] Next, check that the message conforms to the expected encoding and structure. For example, if the expected message format is JSON, check that the message is a valid JSON string. Verify that the message content meets the business logic requirements. This may include checking that required fields are complete and that field values ​​are within a reasonable range. Confirm that the message source is trustworthy. This can be achieved by comparing the source identifier in the message with a list of known legitimate sources.

[0089] If the event message passes the validity verification and its original format does not match the format required by the target processor, the message format needs to be converted to the target message format. The conversion process may include parsing the original message, reconstructing the message according to the target format, and possible data conversion (such as data type conversion, field renaming, etc.). The converted message can then be sent to the target processor through the communication protocol supported by the target processor (such as HTTP, gRPC, message queue, etc.).

[0090] In this embodiment, by verifying the legitimacy of the message format, message content, and message source of the event message, illegal messages or malicious attacks can be effectively prevented from entering the system. Different systems or services may support different message formats. Converting the message format of the event message to the target message format can ensure that the message can be smoothly transmitted and processed between different systems or services. This conversion mechanism enhances the compatibility of the system and enables more flexible integration and expansion of the system. The target processor may have optimized processing for messages in a specific format. After converting the event message to the target message format, the optimized processing capabilities of the target processor can be fully utilized to improve the efficiency of message processing.

[0091] Further, based on the above embodiment, please refer to Figure 7 In one of the exemplary embodiments provided in this application, the specific implementation process of determining the target processor corresponding to the event message based on the event class of the event message by the adapter may further include steps S710 and S720, which are described in detail as follows:

[0092] Step S710: Obtain the event class and subclass of the event class corresponding to the event message through the adapter;

[0093] Step S720 : determining a target processor corresponding to the event message based on a preset mapping relationship between the event class and its subclasses and the processor.

[0094] Specifically, the adapter acts as an intermediary, parsing event messages and extracting key information, particularly the event class and possible event subclasses. This information is typically contained in the message content or headers, following certain naming conventions or structure definitions. The adapter parses the message based on the event message format (such as JSON, XML, etc.) and predefined parsing rules to identify the event class and subclass. Systems or applications typically maintain a mapping table or logic that defines the correspondence between event classes and their subclasses and specific handlers. This mapping can be static (e.g., stored in a database or configuration file) or dynamic (e.g., generated dynamically through a service discovery mechanism). Once the adapter determines the event class and subclass of an event message, it uses this information to locate the corresponding handler in the mapping table. This lookup process may involve a simple key-value query or more complex logic to handle issues such as fuzzy matching and version compatibility.

[0095] Based on this mapping, the adapter can then determine the target processor to handle the event message. This processor is specifically designed to handle this type of event message and has all the logic and resources necessary to process the event. Once the target processor is determined, the adapter can send the event message (possibly after some necessary transformation or encapsulation) to the target processor for processing. The target processor will receive the message, execute the corresponding business logic, and possibly generate some response or results, which can be further used by other systems or components.

[0096] In this embodiment, the processor that processes the message is dynamically determined based on the specific type and subclass of the event message. This means that when a new event type or processor needs to be added, it is only necessary to update the preset mapping relationship without modifying the existing processing logic, thereby improving the flexibility and scalability of the system. The mapping relationship between the event class and the processor is managed by an adapter. This design maintains a certain degree of decoupling between the sender and receiver of the event message. Event messages may need to trigger different processing logic based on their type and subclass. This complex event processing logic can be easily implemented by parsing the event message and determining the corresponding target processor through the adapter. Each processor can focus on processing a specific type of event, thereby improving processing efficiency and accuracy.

[0097] Further, based on the above embodiment, please refer to Figure 8 In one of the exemplary embodiments provided in this application, the specific implementation process of the above message processing method may further include steps S810HE and S820, which are described in detail as follows:

[0098] Step S810: Determine the business scenario and message routing corresponding to the event message based on the event class and event subclass;

[0099] Step S820: Determine the target processor corresponding to the event message based on the business scenario and message routing.

[0100] Specifically, the system first extracts the event class (such as order processing, user login, etc.) and specific event (such as order creation, successful order payment, etc.) from the event message. This information is typically contained in the message content or header and follows certain naming conventions or structure definitions. Based on the event class and event, the system uses pre-defined mapping logic or mapping tables to identify the business scenario corresponding to the event message. A business scenario is a combination of related events and business logic that together achieve a business goal or process. Message routing refers to the path or method by which event messages are transmitted within or across systems. It determines how event messages are sent to the correct processing unit (such as a service, component, or microservice). Based on the business scenario, the system can define message routing rules. These rules may be based on various factors, such as event type, business logic, system architecture, and service availability. Rules may exist in a static configuration or be generated through dynamic service discovery mechanisms. Once the message route is determined, the system can follow the route to locate the target processor. The target processor is the service or component responsible for processing the event message and contains the business logic and resources required to handle the event. In some cases, there may be multiple candidate processors that can handle the same event type. At this point, the system may need to select the most appropriate processor based on additional factors (such as load balancing, service priority, processor capabilities, etc.).

[0101] like Figure 9 As shown, Figure 9 This is an inheritance diagram of the processor and event class shown in an exemplary embodiment of the present application, such as Figure 9As shown in the figure, the integration between the Handler class and the Event class is clearly demonstrated. By using the Event class as a template for all Handlers, event handling in the system becomes standardized. This standardization ensures that all events are handled in the same way, regardless of their source or type. At the same time, the system can handle a variety of different events in a type-safe, efficient, and flexible manner, while keeping the code concise and easy to maintain. This approach is suitable for applications that need to handle multiple types of events and require a highly scalable and flexible system.

[0102] In this embodiment, by automatically identifying and parsing the event class and event itself in an event message, the system can intelligently infer the business scenario to which the event message belongs and the message routing that should be adopted. Different business scenarios may require different processing logic and processors. By associating business scenarios with message routing and processors, the system can flexibly respond to different business needs. With clear business scenarios and message routing, the system can more accurately route event messages to the target processor, improving the efficiency and accuracy of message processing.

[0103] Figure 10 This is a brief flowchart of message processing in the navigation interface under an exemplary application scenario. The message integration end integrates the received event messages, wherein the event messages include synchronous event information and asynchronous event messages in the service internal messages, and Kafka messages in the cross-service messages. Then, the message consumer end listens to the event messages through the corresponding listener, which includes listening to the service internal messages through the listener and listening to the cross-service messages through the Kafka listener. Then, the monitored event messages are sent to the adapter of the message consumer end through the listener to determine the target processor of each event message through the adapter, and, in the service internal messages, the adapter will send the asynchronous event message to the thread pool to realize the asynchronous processing of the asynchronous event message by the target processor. For the detailed implementation process of message processing, please refer to the records in the aforementioned embodiments, which will not be repeated here.

[0104] Figure 11 This is a block diagram of a message processing device shown in an exemplary embodiment of the present application. The device can be applied to Figure 1 The device may also be applicable to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0105] like Figure 11As shown, the exemplary message processing device includes: a monitoring module 1110, which is used to monitor event messages of the message integration end, and the event messages include service internal event messages and cross-service event messages; a sending module 1120, which is used to send the event message to the adapter of the message consumption end based on the listeners corresponding to the service internal event message and the cross-service event message; a determination module 1130, which is used to determine the target processor corresponding to the event message based on the event class of the event message through the adapter; and a processing module 1140, which is used to process the event message based on the target processor to obtain the processing result corresponding to the event message.

[0106] According to one aspect of an embodiment of the present application, the sending module 1120 is also used to send the asynchronous event message to the adapter of the message consumer end through the listener; determine the target processor through the adapter based on the event class corresponding to the asynchronous event message; and send the asynchronous event message to the thread pool to realize asynchronous processing of the asynchronous event message based on the thread pool.

[0107] According to one aspect of an embodiment of the present application, the determination module 1130 is also used to send the cross-service event message to a preset processor to obtain status data corresponding to the cross-service event message through the preset processor; if the status data indicates that the cross-service event message is not processed, the cross-service event message is sent to the target processor.

[0108] According to one aspect of an embodiment of the present application, the determination module 1130 is also used to obtain the content hash value corresponding to the cross-service event message based on the identity identifier, and the content hash value is recorded in the consumption history of the cross-service event message; if the content hash value is empty, the result of the cross-service event message being unprocessed is obtained.

[0109] According to one aspect of an embodiment of the present application, the determination module 1130 is also used to obtain the message format, message content and message source of the event message; if the event message is determined to be legal based on the message format, message content and message source, the message format of the event message is converted into a target message format; and the event message in the target message format is sent to the target processor.

[0110] According to one aspect of an embodiment of the present application, the determination module 1130 is also used to obtain the event class and subclass of the event class corresponding to the event message through the adapter; and determine the target processor corresponding to the event message based on the preset mapping relationship between the event class and the subclass of the event class and the processor.

[0111] According to one aspect of an embodiment of the present application, the determination module 1130 is further used to determine the business scenario and message routing corresponding to the event message based on the event class and event subclass; and determine the target processor corresponding to the event message based on the business scenario and message routing.

[0112] It should be noted that the message processing device provided in the above embodiment and the message processing method provided in the above embodiment are based on the same concept. The specific manner in which each module and unit performs operations has been described in detail in the method embodiment and will not be repeated here. In actual applications, the message processing device provided in the above embodiment can distribute the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0113] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, which, when executed by one or more processors, enables the electronic device to implement the message processing method provided in the above-mentioned embodiments.

[0114] Figure 12 The following is a schematic diagram showing the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application. Figure 12 The computer system 1200 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0115] like Figure 12 As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1202 or the program loaded from the storage part 1208 to the random access memory (RAM) 1203, such as executing the method in the above embodiment. Various programs and data required for system operation are also stored in the RAM 1203. The CPU 1201, ROM 1202 and RAM 1203 are connected to each other via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0116] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, and the like; an output section 1207 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 1208 including a hard disk; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as needed. Removable media 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1210 as needed, so that computer programs read from the removable media can be installed in the storage section 1208 as needed.

[0117] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1209, and / or installed from a removable medium 1211. When the computer program is executed by the central processing unit (CPU) 1201, the various functions defined in the system of the present application are executed.

[0118] It should be noted that the computer-readable medium shown in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable computer program. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0119] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0120] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0121] Another aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the message processing method described above. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist independently and not be incorporated into the electronic device.

[0122] Another aspect of the present application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the message processing method provided in each of the above embodiments.

[0123] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. Ordinary technicians in this field can easily make corresponding changes or modifications based on the main ideas and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A message processing method, characterized in that: Applicable to systems including message integration and message consumption, including: Monitor event messages from the message integration end, including service internal event messages and cross-service event messages; Based on the listeners corresponding to the service internal event message and the cross-service event message, the event message is sent to the adapter of the message consumer end; the adapter is used to convert the format of the event message to adapt to different message consumers; Obtaining the event class corresponding to the event message and the subclass of the event class through the adapter; Determining a target processor corresponding to the event message based on a preset mapping relationship between the event class and a subclass of the event class and the processor; The target processor processes the event message to obtain a processing result corresponding to the event message.

2. The method according to claim 1, wherein The service internal message includes an asynchronous event message, and the method further includes: Sending the asynchronous event message to the adapter of the message consumer through the listener; Determining a target processor by the adapter based on an event class corresponding to the asynchronous event message; The asynchronous event message is sent to a thread pool, so as to implement asynchronous processing of the asynchronous event message based on the thread pool.

3. The method according to claim 1, wherein The method further comprises: Sending the cross-service event message to a preset processor, so as to obtain, through the preset processor, status data corresponding to the cross-service event message; If the status data indicates that the cross-service event message is not processed, the cross-service event message is sent to the target processor.

4. The method according to claim 3, wherein The state data includes an identity corresponding to the cross-service event message, and the method further includes: Obtaining a content hash value corresponding to the cross-service event message based on the identity identifier, where the content hash value is recorded in a consumption history record of the cross-service event message; If the content hash value is empty, a result is obtained in which the cross-service event message is not processed.

5. The method according to claim 1, wherein Before processing the event message based on the target processor to obtain a processing result corresponding to the event message, the method further includes: Obtaining the message format, message content, and message source of the event message; If the event message is determined to be legitimate based on the message format, the message content, and the message source, converting the message format of the event message into a target message format; Sending the event message in the target message format to the target processor.

6. The method according to claim 1, wherein The method further comprises: Determining a business scenario and a message route corresponding to the event message based on the event class and the subclass of the event; A target processor corresponding to the event message is determined based on the business scenario and the message routing.

7. A message processing device, characterized in that: Applied to a system including a message integration end and a message consumption end, the device includes: A monitoring module, configured to monitor event messages from the message integration terminal, wherein the event messages include service internal event messages and cross-service event messages; A sending module, configured to send the event message to an adapter of a message consumer based on the listeners corresponding to the service internal event message and the cross-service event message; the adapter is configured to convert the format of the event message to adapt to different message consumers; a determination module configured to obtain, through the adapter, an event class and a subclass of the event class corresponding to the event message; and determine a target processor corresponding to the event message based on a preset mapping relationship between the event class and the subclass of the event class and the processor; The processing module is used to process the event message based on the target processor to obtain a processing result corresponding to the event message.

8. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the message processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that Computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the message processing method according to any one of claims 1 to 6.

Images