Message processing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a message processing method and device, electronic equipment and a storage medium. The method is applied to a system comprising a message integration end and a message consumption end. The method comprises the following steps: monitoring event messages of the message integration end, wherein the event messages comprise service internal event messages and cross-service event messages; based on the monitors corresponding to the service internal event message and the cross-service event message, sending the event message to an adapter of a message consumption end; determining a target processor corresponding to the event message based on the event class of the event message through the adapter; and processing the event message based on the target processor to obtain a processing result corresponding to the event message. According to the embodiment of the invention, each monitor can be responsible for monitoring event messages of a specific type and forwarding the event messages to the corresponding processor for processing, so that the service logic of the system is clearer and is easy 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 generation method, device, electronic device, and computer-readable storage medium. Background Art

[0002] With the development of technology, the software framework (BocsoftFrameWork, referred to as BFW) is a Java application standardized development platform that provides a wealth of technical components, including multi-channel integration, user authority control, transaction processing, componentized asset management and reuse, third-party technology integration, etc., and provides a set of standard MVC programming models and transaction processing procedures. Through BFW, transactions submitted by users can be processed.

[0003] Existing software frameworks use message middleware alone as the message bus, such as Kafka and RabbitMQ. Although message middleware has high performance and high throughput, using it for internal service communication will cause waste of resources and lack business scalability. There is no unified business architecture design for sending and receiving messages, 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 respectively; determining, by 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 service internal message includes an asynchronous event message, and the method also 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; 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 also 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, a result of the cross-service event message being unprocessed is obtained.

[0009] According to one aspect of an embodiment of the present application, before the event message is processed based on the target processor to obtain a processing result corresponding to the event message, the method also includes: obtaining a 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; 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 also includes: determining the business scenario and message routing corresponding to the event message based on the event class and the event subclass; 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 a 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 as described above.

[0015] According to one aspect of an embodiment of the present application, a computer program product is also provided, including a computer program, which implements the steps in the message processing method as 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 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, complex business logic can be flexibly handled, 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 business logic of the system 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 drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0019] Figure 1 It 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] Fig. 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] Fig.10 is a schematic diagram of a message processing architecture shown in an exemplary embodiment;

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

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

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

[0032] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or 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 only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0034] The term "multiple" as used in this application refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0035] First of all, it should be noted that the message bus is a middleware technology used to implement communication between components or services in a distributed system. It is similar to the data bus on the motherboard, with the ability to transmit and interact with data, but the parties do not communicate directly, but use the bus as a standard communication interface. The message bus is a cross-process communication mechanism for transmitting messages between upstream and downstream. It can link the nodes of a distributed system with a lightweight messaging system, integrate Java's event processing mechanism and the functions of the messaging middleware, and manage and propagate messages between distributed systems. The message bus can be applied to fields such as SOA (Service-Oriented Architecture) and EIP (Enterprise Integration Pattern), and is a powerful tool for decoupling between 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 the upstream message sending only needs to rely on the message bus, and does not need to rely on other services logically and physically; scalability: the message bus can be easily expanded to support more components and message types, and adapt 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 transmission of messages through mechanisms such as message landing, message timeout, retransmission, and confirmation.

[0036] Figure 1 FIG. 1 is a schematic diagram of a message processing framework structure 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 days, and then the listener sends the listened event messages to the message consumption terminal 200. Specifically, the listener sends the listened event messages to the adapter of the message consumption terminal, so that the adapter determines the target processor corresponding to the event message based on the event class corresponding to the event message, and then processes 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 (Synchronous Event Pusher), purpose: to achieve instant communication within the service, to ensure the rapid delivery and processing of messages, suitable for scenarios with high timeliness requirements. Mechanism: directly pass events to listeners (EventListener), reducing the waiting time of messages in the queue, giving priority to 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 the consumer, which improves the system's processing capabilities and effectively distributes instantaneous high loads.

[0040] c) KafkaMessagePusher supports high-throughput distributed scenarios and is suitable for cross-service and cross-data center communications. 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 processing quick responses or simpler internal service messages; b) KafkaMessageConsumer, which consumes messages pushed through Kafka. Kafka's high performance ensures the efficiency of cross-service communication in distributed systems, and the reliability of message consumption is guaranteed through the design and development of idempotence mechanisms.

[0042] In existing software frameworks, message middleware is used 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 of services, which will cause waste of resources and lack business scalability. There is no unified business architecture design for sending and receiving messages, which increases the difficulty of code development and management. The above-mentioned problems 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 2is a flowchart of a message processing method shown in an exemplary embodiment of the present application. The 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 be 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, monitoring event messages of the message integration terminal, where the event messages include service internal event messages and cross-service event messages.

[0046] Specifically, by monitoring the event messages received by the message integration terminal, these event messages include event messages pushed by the service internal message pusher and cross-service event messages pushed by the service external system. Service internal event messages refer to messages generated and processed within a single service. And these messages are usually used for communication between different components within the service, such as communication between the business logic layer and the data access layer. Cross-service event messages refer to events transmitted between different services, which are used to achieve decoupling and asynchronous communication between services.

[0047] For example, an event bus pattern is used to pass events between different components within a service. The event bus allows a publish / subscribe model, where one component publishes events and other components can subscribe to these events and respond. In some scenarios, the observer pattern can be used to implement event monitoring. For example, an object (subject) maintains a list of objects (observers) that depend on it. When this object changes its state, it notifies all objects that depend on it, that is, to implement event message monitoring. On the other hand, for cross-service messages, message queues (such as RabbitMQ, Kafka, etc.) are generally used to pass event messages between different services. Service A sends event messages to the queue, and service B subscribes to the queue and processes the message. This approach can achieve high reliability and scalability, similar to message queues, but more focused on event publishing and subscription. Service A publishes an event, and any service interested in the event can subscribe and receive notifications. Then, in the service mesh, communication and event delivery between services can be implemented through the Sidecar proxy. Although the service mesh is mainly used to handle network requests between services, it can also be configured to listen to 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 are different from the listeners corresponding to the cross-service event messages. 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 transmits information between different parts of the system through asynchronous events. In this architecture, when events occur between services or within services, listeners that listen to these events are triggered, and these listeners further process the events or pass the events to other components. In order to effectively send event messages to the adapters on the message consumer side, it is necessary to clearly define the data structure of internal service events and inter-service events. These events usually contain event types, event data (such as JSON or XML format), and possible other metadata (such as timestamps, event sources, etc.). Create corresponding listeners for each event type. The listener is responsible for receiving events and performing specific logical processing. These logics may include validating event data, converting data formats, calling other services, etc. Use message queues (such as RabbitMQ, Kafka) or event buses (such as Apache Kafka, Azure Event Hubs) as intermediate storage and routing systems for event messages. These systems can ensure asynchronous processing, high availability, and scalability of messages.

[0051] Among them, the adapter pattern is a structural design pattern used to convert the interface of a class into another interface expected by the client. In an event-driven architecture, adapters are usually used to convert event messages from one format or protocol to another format or protocol to adapt to different consumer ends, and implement corresponding adapters according to the needs of the message consumer end. These adapters can receive messages from message queues or event buses, parse the message content, convert it to the format required by the consumer end, and then call the API or method of the consumer end.

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

[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 message 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 from event classes to 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 processor corresponding to the event message is determined, the adapter will call the corresponding method of the processor to handle the event. This usually involves passing the event message as a parameter to the method of the processor, and may include exception handling and result collection. After the target processor processes the event, it may produce some results or need to perform some subsequent operations (such as sending a response, updating a database, etc.). The adapter needs to be 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 the 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 large-scale reconstruction of the overall architecture, and then by defining multiple listeners and processors, the degaussing process can flexibly handle complex business logic. Each listener can be responsible for listening to a specific type of event message and forwarding it to the corresponding processor for processing. This method makes the business logic of the system clearer, easier to understand and maintain.

[0058] Further, based on the above embodiments, please refer to Figure 3 In one of the exemplary embodiments provided in the present application, the above service internal message includes an asynchronous event message, and the specific implementation process of the above message processing method may also 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 end 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, sending 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 asynchronous event pusher (AsyncEventPusher) on the message integration end can be 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, which improves the system's processing capacity and effectively distributes instantaneous high loads. Then the listener is responsible for listening to asynchronous events that occur in the system. When events occur, the listener captures these events and encapsulates them into event messages. The listener sends the captured event messages to the adapter. This process may involve putting the event message into a message queue (such as RabbitMQ, Kafka, etc.) or directly sending it to the adapter through some form of IPC (inter-process communication) mechanism. The adapter is a middleware component that receives asynchronous event messages from the listener and determines which target processor should be called to process the event based on the event class (or type) in the event message. Once the adapter determines the target processor, it sends the asynchronous event message to the thread pool. This usually means encapsulating the event message into a task and submitting it to the thread pool for execution. The worker threads in the thread pool process these tasks in parallel or serially. Each task calls its corresponding target processor to process the event message. Since the processing is done asynchronously in the thread pool, the original event sending process will not be blocked. Among them, the thread pool is a concurrent framework based on pooling technology, which is used to manage a group of worker threads. It allows the system to efficiently execute a large number of concurrent tasks while reducing the overhead of thread creation and destruction. In addition, the adapter usually maintains a mapping table or rule set to map event classes to corresponding target processors. 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 embodiments, please refer to Figure 4 In one of the exemplary embodiments provided in the present 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: sending 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 preset processor for event preprocessing, which can ensure the consistency of data quality and format of the incoming message consumer, and also help debug and monitor the message flow. At the same time, as the system develops in the future, more message processing methods may be added. The adapter makes these changes more flexible, and only needs to adjust the adapter layer, without major changes to the business logic or other system components, and has strong scalability.

[0067] For example, in software development or system design, EventHandlerAdaptor plays a vital role. In EventHandlerAdaptor, a series of pre-processing operations are designed and developed. For example, methods such as eventMessageCheck, formatConvert, and operationLog are usually functions that handle different aspects or stages of a specific event. The specific introduction is as follows:

[0068] eventMessageCheck(Event) Function Description: The main purpose of the eventMessageCheck method is to verify or check the incoming event message. This may include checking whether the format of the message is correct, whether the content of the message meets the expected specifications, whether the source of the message is credible, etc. The method may return different values ​​or throw exceptions based on the check results to indicate whether the message is valid or needs further processing. Application scenario: In an event-driven system, ensure that only valid messages are further processed. On the consumer side of an API call or message queue, pre-verify the received message.

[0069] formatConvert(Event) Function Description: The formatConvert method is responsible for converting the incoming event message from one format to another. This conversion may include data structure conversion, data type conversion, encoding conversion, etc. This method is usually used to solve the problem of incompatible data formats between different systems or components. Application scenario: In a microservice architecture, it may be necessary to unify the data format when exchanging data between different services. When interacting with external systems (such as third-party APIs), convert the internal data format to the format required by the external system.

[0070] operationLog(Event) Function Description: The operationLog method is used to record the operation log related to the incoming event (Event). This may include the type of operation, the timestamp of the operation, the result of the operation (success or failure), related user information (if the event was triggered by the user), etc. This method is essential for system monitoring, troubleshooting, and auditing. Application scenario: Anywhere you need to track and record system operation behavior. In systems that need to comply with specific regulations or standards (such as GDPR, HIPAA, etc.), record user behavior or sensitive operations.

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

[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 a 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 (i.e., 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 an important concept in distributed systems and event-driven architectures. It ensures that no matter how many times an operation (such as message processing) is executed, its effect is the same as if it were executed once, that is, the result remains consistent. This is especially important for handling duplicate messages, network retransmissions, user errors, etc.

[0075] In this embodiment, by using a preset processor to check the status of the cross-service event message, it can be ensured that the message has been verified before being sent to the target processor, avoiding repeated processing or missing processing, thereby improving the overall reliability and stability of the system. By using the preset processor as an intermediate layer, it is easier to add or modify the processing logic of the cross-service event message without directly modifying the code of the target processor. This design makes the system more modular and enhances the scalability and flexibility of the system.

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

[0077] Step S510, obtaining a 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;

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

[0079] Specifically, when processing cross-service event messages, using an identifier (such as a message ID, event type ID, 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 summary of data that can uniquely represent the content of a piece of data. Even if the data changes slightly, its hash value will be very 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 identity of the message so that the processing status of the message can be verified in the future.

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

[0083] Further, based on the above embodiments, 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 a 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, where the message format usually refers to the message encoding method, structure definition (such as JSON, XML, Protobuf, etc.) and possible version information, the message content is 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 credible.

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

[0089] If the event message passes the legality 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, where 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.). Then, the converted message can 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 the system to be more flexibly integrated and expanded. 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 capability of the target processor can be fully utilized to improve the efficiency of message processing.

[0091] Further, based on the above embodiments, please refer to Figure 7 In one of the exemplary embodiments provided in the present 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 also include step S710 and step S720, which are described in detail as follows:

[0092] Step S710, obtaining the event class and the 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 the subclass of the event class and the processor.

[0094] Specifically, the adapter plays the role of an intermediary here. It is responsible for parsing the event message and extracting key information from it, especially the event class (Event Class) and possible event subclasses (EventSubclass) to which the event message belongs. This information is usually contained in the content or header of the message and follows certain naming conventions or structure definitions. The adapter parses the message according to the format of the event message (such as JSON, XML, etc.) and the predetermined parsing rules to identify the event class and event subclass. In the system or application, a mapping table or mapping logic is usually maintained to define the correspondence between the event class and its subclasses and specific processors. This mapping relationship can be static (such as stored in a database or configuration file) or dynamic (such as dynamically generated through a service discovery mechanism). Once the adapter determines the event class and subclass of the event message, it uses this information to find the corresponding processor in the mapping table. This search process may involve simple key-value pair queries, or it may require more complex logic to handle issues such as fuzzy matching and version compatibility.

[0095] Then, based on the above mapping relationship, the adapter can determine the target processor to handle the event message. This processor is specially designed to handle this type of event message and has all the logic and resources required to handle the event. Once the target processor is determined, the adapter can send the event message (possibly after some necessary conversion or encapsulation) to the target processor for processing. The target processor will receive the message, execute the corresponding business logic, and may generate some responses 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, which 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 an adapter. Each processor can focus on processing a specific type of event, thereby improving processing efficiency and accuracy.

[0097] Further, based on the above embodiments, please refer to Figure 8 In one of the exemplary embodiments provided in the present 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, determining 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, first, extract the event class (such as order processing, user login, etc.) and specific events (such as order creation, order payment success, etc.) from the event message. This information is usually contained in the content or header of the message and follows certain naming conventions or structural definitions. According to the event class and event, the system identifies the business scenario corresponding to the event message through a preset mapping logic or mapping table. A business scenario refers to a combination of a series of related events and business logic that together complete a certain business goal or process. Message routing refers to the path or method by which event messages are transmitted within a system or across systems. It determines how event messages are sent to the correct processing unit (such as services, components, microservices, etc.). Based on the business scenario, the system can formulate rules for message routing. These rules may be based on a variety of factors, such as event type, business logic, system architecture, service availability, etc. Rules may exist in the form of static configuration or may be generated through a dynamic service discovery mechanism. Once the message route is determined, the system can find the target processor along the route. The target processor is the service or component responsible for processing the event message, which contains the business logic and resources required to process the event. In some cases, there may be multiple candidate processors that can handle the same type of event. 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 Fig. 9 As shown, Fig. 9 is an inheritance diagram of a processor and an event class shown in an exemplary embodiment of the present application, such as Fig. 9As shown in the figure, the integration relationship between the Handler class and the Event class is clearly visible. By using the Event class as a template for all Handlers, event processing in the system becomes standardized. This standardization ensures that all events are processed 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 want the system to have high scalability and flexibility.

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

[0103] Fig.10 It 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, so as 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] Fig.11 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, and this embodiment does not limit the implementation environment to which the device is applicable.

[0105] like Fig.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 messages to the 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 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 implement 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, determination module 1130 is also used to obtain a content hash value corresponding to a cross-service event message based on an identity identifier, and the content hash value is in a consumption history record of the cross-service event message; if the content hash value is empty, a result that the cross-service event message is 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 also used to determine the business scenario and message route 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 route.

[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 belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment, and will not be repeated here. In practical 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, when the one or more programs are executed by one or more processors, the electronic device implements the message processing method provided in the above-mentioned embodiments.

[0114] Fig.12 The structure diagram of the computer system suitable for implementing the electronic device of the embodiment of the present application is shown. It should be noted that: Fig.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 Fig.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. In the RAM 1203, various programs and data required for system operation are also stored. The CPU 1201, the ROM 1202 and the RAM 1203 are connected to each other through the bus 1204. The 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, etc.; an output section 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. 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. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1210 as needed so that a computer program read therefrom is installed into 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 through a communication section 1209, and / or installed from a removable medium 1211. When the computer program is executed by a central processing unit (CPU) 1201, 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 embodiment 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 may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. 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, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. A computer program contained on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0119] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order 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 a 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. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0121] Another aspect of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the message processing method as described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0122] Another aspect of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes 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. A person skilled in the art can easily make corresponding changes or modifications based on the main concept 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; Determining, by the adapter, a target processor corresponding to the event message based on the event class of the event message; The event message is processed based on the target processor to obtain a processing result corresponding to the event message.

2. The method according to claim 1, characterized in that 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 end 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 to implement asynchronous processing of the asynchronous event message based on the thread pool.

3. The method according to claim 1, characterized in that The method further comprises: Sending 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; 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, characterized in that The state data includes an identity corresponding to the cross-service event message, and the method further includes: Acquire 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, the result that the cross-service event message is not processed is obtained.

5. The method according to claim 1, characterized in that Before the target processor processes the event message and obtains 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 an event message in the target message format to the target processor.

6. The method according to claim 1, characterized in that The step of determining, by the adapter, a target processor corresponding to the event message based on the event class of the event message comprises: Obtaining the event class corresponding to the event message and the subclass of the event class through the adapter; The target processor corresponding to the event message is determined based on a preset mapping relationship between the event class and a subclass of the event class and a processor.

7. The method according to claim 6, characterized in that The method further comprises: Determine the business scenario and message routing 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.

8. 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, used to monitor event messages of the message integration terminal, wherein the event messages include service internal event messages and cross-service event messages; A sending module, used to send the event message to the adapter of the message consumption end based on the listeners corresponding to the internal event message of the service and the cross-service event message respectively; A determination module, configured to determine a target processor corresponding to the event message based on the event class of the event message through the adapter; 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.

9. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, enables the electronic device to implement the message processing method as described in any one of claims 1 to 7.

10. 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 7.

Images