An event message propagation method based on a micro-service registration center

Abstract

The present application belongs to the technical field of information dissemination, and particularly relates to an event message dissemination method based on a micro-service registration center. In the present application, a public program module is written and a configuration item is set, so as to automatically declare a receiving interface for an event receiver and add the receiving interface to custom extension metadata of the event receiver in the registration center, thereby sharing the receiving interface with other micro-service programs. Then, a local event of an event publisher is listened to by a local event listener, and after the local event is listened to, an event converter is called to convert the local event into a receiving interface of a corresponding message receiver, and a business message is sent to the corresponding event receiver through the receiving interface. By using the light message dissemination mechanism, the software architecture complexity is reduced, and the hardware resource consumption and the software service deployment and maintenance difficulty are reduced. The present application can improve the development efficiency of a message transmission system between micro-services, and reduce the maintenance cost.

Description

Technical Field

[0001] This invention belongs to the field of information dissemination technology, and in particular relates to an event message dissemination method based on a microservice registry. Background Technology

[0002] Traditional monolithic architectures concentrate all business functionalities in a single project for development and deployment. While this results in a simple architecture and low deployment costs, it also leads to high coupling (making maintenance and upgrades difficult). Microservices, on the other hand, are software architectures based on single-function components, using modular combinations to achieve loosely coupled application development. Each service typically implements a set of independent features or functions, including its own business logic and adapters. A microservice registry not only provides dynamic service discovery, service configuration, service sharing, and management, but also manages service instance metadata during microservice registration or runtime.

[0003] The connections between microservices are achieved through exposed APIs. Since services developed in a microservice architecture communicate and transmit data via API calls, changes to API addresses cannot be proactively communicated to callers. This necessitates modifications and redevelopment by the callers to accommodate the changed addresses. Furthermore, the APIs provided for inter-service calls require defining different interface addresses, resulting in a large number of APIs and complex maintenance. While existing message queue technology is relatively mature, integrating message queues is still necessary for many microservices, even for a single message propagation function, further increasing software architectural complexity, resource consumption, and deployment and maintenance difficulties.

[0004] Therefore, how to improve the development efficiency of message passing systems between microservices while reducing maintenance costs has become an urgent problem to be solved. Summary of the Invention

[0005] To address the shortcomings of the existing technologies, this invention provides an event message propagation method based on a microservice registry, which can improve the development efficiency of message passing systems between microservices while reducing maintenance costs.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: An event message propagation method based on a microservice registry includes the following steps: S1. Develop a common program module for registering event message receiving addresses based on the metadata sharing method of the registration center; and build an event converter in the common program module, which is used to convert local events into receiving interfaces that call the corresponding message receivers; the local events are business messages published by the event publishers; S2. Define a local event listener to listen for local events published by the publisher and call the event converter when a local event is detected. S3. The event receiver references the common program module in its own program and sets the receiving configuration items; the receiving configuration items include the configuration item for enabling the receiving of event messages; after the receiver enables the receiving of event messages configuration items, the common program module automatically declares a message receiving API interface as the receiving interface of the receiver, and adds the receiving interface to the custom extended metadata of the event receiver in the registry center, sharing it with other microservice programs; the other microservice programs include other event receivers and event senders; S4. The event publisher references the public program module in its own program, sets the publishing configuration items, and obtains the receiving interface of the event receiver. S5, The event publisher publishes a local event; S6. After the local event listener detects a local event, it calls the event converter to convert the local event into a receiving interface for the corresponding message receiver, and then sends the business message to the corresponding event receiver through the receiving interface.

[0007] Preferably, in S5, when the event publisher publishes a local event, it encapsulates the business message into an event data model, defines the type name of the event, and describes the data structure and parameter list of the type; Local event listeners are also used to listen to event types defined by the event publisher in S5; in S6, local event listeners process local events of the event types they listen to.

[0008] Preferably, in S5, when the event publisher publishes a local event, it also packages the event data model into a program module for the event receiver to listen to the event and use the event data model to parse parameters after receiving the event.

[0009] Preferably, in S5, when encapsulating the business message into an event data model, parameters are also defined regarding whether the business message is sent asynchronously and the number of retries when sending asynchronously.

[0010] Preferably, in S4, the publishing configuration item includes whether event publishing is enabled as defined by the publisher.

[0011] Preferably, in S4, the publishing configuration item also includes customizing the interface address of other message receivers; the other message receivers are event receivers whose receiving interfaces cannot be obtained through the registry center; in S6, the business message is also sent to the other message receivers through the interface address set in S4.

[0012] Compared with the prior art, the present invention has the following beneficial effects: 1. In this invention, a common program module is written and configured to automatically declare the receiving interface for the event receiver and add it to the event receiver's custom extended metadata in the registry center, thereby sharing it with other microservice programs, i.e., other event receivers and event senders. Then, a local event listener listens for the event publisher's local events (i.e., publishing business messages). Upon detecting a local event, an event converter is invoked to convert the local event into a call to the corresponding message receiver's receiving interface, and the business message is then sent to the corresponding event receiver through this receiving interface.

[0013] In this way, the present invention utilizes the metadata function in service registration and discovery to inform the registry center of the endpoint interface address data when the service starts. Since the metadata of services under the same registry center is shared, other services can dynamically obtain the interface address through the registry center for sending and processing business messages. This reduces the number of development, deployment, and downtime caused by changes in time and address, and improves the uninterrupted service rate. This method defines a simple event message receiving interface to receive different types of business messages from other services. Developers do not need to define and maintain many API interfaces, improving development efficiency and reducing maintenance costs. By using a lightweight message propagation mechanism, not only is the software architecture complexity reduced, but hardware resource consumption and the difficulty of software service deployment and maintenance are also reduced.

[0014] In summary, this invention can improve the development efficiency of message passing systems between microservices while reducing maintenance costs.

[0015] 2. For a large number of complex interfaces, this invention encapsulates business messages into event models and propagates different event messages through dedicated event interfaces, thereby achieving a unified message interface and standardized message structure, which simplifies communication between microservices.

[0016] 3. In addition to supporting services deployed in microservices, this invention is also compatible with services that have not used service registration and discovery and have not registered their service instance information with the registry center. Message propagation can be achieved simply by configuring the message interface addresses of other services in S4.

[0017] 4. In this invention, a method for converting message data into an event model is provided. Both the event publisher and the event receiver use the same event data model to publish and receive events in local mode, providing a standard operation for event propagation.

[0018] 5. In addition to providing an asynchronous message passing method to adapt to scenarios that require long event processing data or have long response times, this invention also provides a message passing retry mechanism to increase the message delivery rate. Attached Figure Description

[0019] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein: Figure 1 This is a flowchart from an embodiment. Detailed Implementation

[0020] The following detailed explanation illustrates the specific implementation methods: Example: like Figure 1 As shown, this embodiment discloses an event message propagation method based on a microservice registry center, including the following steps: S1. Write a public program module for registering event message receiving addresses based on the metadata sharing method of the registration center; and build an event converter in the public program module. The event converter is used to convert local events into receiving interfaces that call the corresponding message receivers; the local events are business messages published by the event publishers.

[0021] S2. Define a local event listener to listen for local events published by the publisher, and call the event converter when a local event is detected to convert the local event into a message receiver interface that calls the corresponding message receiver.

[0022] S3. The event receiver references the common program module in its own program and sets the receiving configuration items; the receiving configuration items include the configuration item for enabling the receiving of event messages; after the receiver enables the receiving of event messages configuration items, the common program module automatically declares a message receiving API interface as the receiving interface of the receiver, and adds the receiving interface to the custom extended metadata of the event receiver in the registry center, sharing it with other microservice programs; the other microservice programs include other event receivers and event senders.

[0023] S4. The event publisher references the public program module into its own program, sets the publishing configuration items, and obtains the receiving interface of the event receiver; wherein, the publishing configuration items include whether to enable event publishing as defined by the publisher, and also include the interface address of other message receivers; the other message receivers are event receivers whose receiving interfaces cannot be obtained through the registry center.

[0024] For receiver services that have not registered their instance information with the registry center or are not using a microservice architecture, the message publisher cannot obtain the event message receiving address of the receiver through the registry center. In this case, the interface address of the event receiver that needs to receive events can be manually configured into the receiver list to achieve message propagation.

[0025] S5. The event publisher publishes local events. In practice, when the event publisher publishes a local event, it encapsulates the business message into an event data model, defines the event type name, and describes the data structure and parameter list of that type.

[0026] Specifically, when an event publisher publishes a local event, it also packages the event data model into a program module for the event receiver to listen to the event and use the event data model for parameter parsing after receiving it. When encapsulating a business message into an event data model, it also defines whether the business message is sent asynchronously and the number of retries for asynchronous sending.

[0027] The local event listener defined in S2 is also used to listen for event types defined by the event publisher in S5.

[0028] S6. After the local event listener detects a local event of the type it is listening for, it calls the event converter to convert the local event into a receiving interface for the corresponding message receiver, and sends the business message to the corresponding event receiver through the receiving interface; it also sends the business message to other message receivers through the interface address set in S4.

[0029] This invention automatically declares the receiving interface for event receivers and adds it to the custom extended metadata of the event receiver in the registry center by writing a common program module and configuring its settings. This allows the interface to be shared with other microservice programs, i.e., other event receivers and event senders. Then, a local event listener monitors the local events (i.e., published business messages) of the event publisher. Upon detecting a local event, an event converter is invoked to convert the local event into a call to the receiving interface of the corresponding message receiver, and the business message is sent to the corresponding event receiver through this interface. In this way, this invention utilizes the metadata function in service registration and discovery to inform the registry center of the endpoint interface address data when the service starts. Since the metadata of services is shared under the same registry center, other services can dynamically obtain the interface address through the registry center for sending and processing business messages, reducing the number of development, deployment, and downtime caused by changes in time and address, and improving uninterrupted service rates. This method defines a simple event message receiving interface to receive different types of business messages from other services. Developers do not need to define and maintain numerous API interfaces, improving development efficiency and reducing maintenance costs. By utilizing a lightweight message propagation mechanism, not only is the complexity of the software architecture reduced, but also the consumption of hardware resources and the difficulty of deploying and maintaining software services are decreased.

[0030] In addition, for numerous and complex interfaces, this invention encapsulates business messages into event models and propagates different event messages through dedicated event interfaces, achieving a unified message interface and standardized message structure, simplifying communication between microservices. Furthermore, this invention supports not only services deployed in microservices but also services that haven't used service registration and discovery or registered their service instance information with the registry center. Message propagation can be achieved simply by configuring the message interface addresses of other services in S4. This invention provides a method for converting message data into event models, allowing both event publishers and receivers to publish and receive events locally using the same event data model, providing standard operations for event propagation. Moreover, besides providing asynchronous message delivery to adapt to scenarios requiring long event processing data or long response times, this invention also provides a message delivery retry mechanism to improve message delivery rates.

[0031] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. An event message propagation method based on a microservice registry, characterized in that, Includes the following steps: S1. Write a common program module for registering event message receiving addresses based on the metadata sharing method of the registration center; An event converter is built into the public program module. The event converter is used to convert local events into calls to the receiving interface of the corresponding message receiver. The local events are business messages published by the event publisher. S2. Define a local event listener to listen for local events published by the publisher and call the event converter when a local event is detected. S3. The event receiver references the common program module in its own program and sets the receiving configuration items; the receiving configuration items include the configuration item for enabling the receiving of event messages; after the receiver enables the receiving of event messages configuration items, the common program module automatically declares a message receiving API interface as the receiving interface of the receiver, and adds the receiving interface to the custom extended metadata of the event receiver in the registry center, sharing it with other microservice programs; the other microservice programs include other event receivers and event senders; S4. The event publisher references the public program module in its own program, sets the publishing configuration items, and obtains the receiving interface of the event receiver. S5, The event publisher publishes a local event; S6. After the local event listener detects a local event, it calls the event converter to convert the local event into a receiving interface for the corresponding message receiver, and then sends the business message to the corresponding event receiver through the receiving interface.

2. The event message propagation method based on a microservice registry center as described in claim 1, characterized in that: In S5, when an event publisher publishes a local event, it encapsulates the business message into an event data model, defines the event type name, and describes the data structure and parameter list of that type. Local event listeners are also used to listen to event types defined by the event publisher in S5; in S6, local event listeners process local events of the event types they listen to.

3. The event message propagation method based on a microservice registry center as described in claim 2, characterized in that: In S5, when an event publisher publishes a local event, it also packages the event data model into a program module, which is used by the event receiver to listen to the event and to use the event data model to parse parameters after receiving the event.

4. The event message propagation method based on a microservice registry center as described in claim 3, characterized in that: In S5, when encapsulating business messages into an event data model, parameters are also defined regarding whether the business message is sent asynchronously and the number of retries when sending asynchronously.

5. The event message propagation method based on a microservice registry center as described in claim 1, characterized in that: In S4, the publishing configuration item includes whether event publishing is enabled, as defined by the publisher.

6. The event message propagation method based on a microservice registry center as described in claim 5, characterized in that: In S4, the publishing configuration item also includes customizing the interface address of other message receivers; the other message receivers are event receivers whose receiving interfaces cannot be obtained through the registry center; in S6, business messages are also sent to other message receivers through the interface address set in S4.

Images