CN112596933B - Micro-service system based on message event communication - Google Patents
Micro-service system based on message event communication Download PDFInfo
- Publication number
- CN112596933B CN112596933B CN202110217201.7A CN202110217201A CN112596933B CN 112596933 B CN112596933 B CN 112596933B CN 202110217201 A CN202110217201 A CN 202110217201A CN 112596933 B CN112596933 B CN 112596933B
- Authority
- CN
- China
- Prior art keywords
- message
- event
- service
- events
- central
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
Abstract
The invention discloses a micro-service system based on message event communication, which comprises a plurality of clients and a central event server; events are pushed to a central event server uniformly, the performance is improved by adopting MQ mechanism transfer, a plurality of API requests are avoided, the scheme of close coupling relation between complex and messy micro-services is converted into a simple, clear and easily maintained and expanded management scheme through the mode of forwarding and inquiring the central event server, and simultaneously event data are described in a universal format by standardizing event standards so as to provide interoperability among cross-service, platforms and systems.
Description
Technical Field
The invention relates to the field of communication processing, in particular to the technical field of cloud conferences, and more particularly relates to an event notification scheme for opening, modifying and deleting an account number of a user, changing customer information and the like.
Background
Traditional application development in the prior art is generally performed in a monolithic architecture. The single framework has the characteristics of simple project framework, low early development cost and short period, and is a preferred choice of small projects. However, since all functions are integrated in one project, the traditional monolithic application has problems in terms of expandability, reliability, adaptability, high deployment cost and the like, and for relatively large-scale projects, the monolithic architecture is not enough to support various requirements of informatization construction on construction period quality and strain capacity. Therefore, the development of the entire development system is now beginning to be carried out using the widely popular adoption microservice architecture.
However, the microservice architecture, while providing a range of benefits, also presents several challenges. In addition to the inherent complexity of the distributed system, the services are more and more, the connection between the services is tighter and tighter, the higher the coupling, the poorer the independence of the services, and the higher the requirement on operation and maintenance is also provided, and a series of services are required to be adjusted by a small change. For example, the service a, the service B, the service C, and the like need to be notified when the account is opened, modified, and deleted, and corresponding adjustment is needed if a service D is added. And the pressure on the server generating the event is also large, so that the notification can not be sent out in time and the notification can be realized by calling APIs of different services for many times. Moreover, the API of each service may be different, which requires additional coding to implement, and thus imposes unnecessary burden on developers. Currently, notification between each service is notified to each server in a restful manner. Each service provides an API interface to receive notifications. When the event is generated, the API of each server is called to complete the notification. And the servers perform corresponding processing after receiving the notification. As the demand for services increases, micro-services also increase, and when a service is newly added, a corresponding addition needs to be made on the event generation server to support the new service.
Disclosure of Invention
To solve at least one of the above technical problems, the present invention changes to a unified event communication technology to reduce the dependency relationship between services, and at the same time, specifies the event standard to describe the event data in a universal format to provide interoperability across services, platforms and systems. The invention provides a micro-service system based on message event communication, which comprises a plurality of clients and a central event server;
each client corresponds to a service, and the central event server performs data updating on the services on the clients in a mode of sending message events so as to decouple the dependence among the services on the plurality of clients, wherein all the message events adopt the standard of cloudEvents; the communication between the services on the plurality of clients adopts a lightweight communication mechanism; three message queues are stored on a client where each service is located, wherein the three message queues comprise a temporary message event queue, an unsubscribed message event queue and a message event sending queue; the temporary message event queue stores temporary message events representing configuration changes caused by centralized test operation among services; the unsubscribed message event queue for storing message events for which service log information changes are not subscribed to,
the message event sending queue stores message events to be sent which are subscribed, and is set to send the subscribed message events to the central event server;
the central event server stores a logical relationship mapping chart of each service, and receives, processes, circulates and transmits message events based on the logical relationship of each service;
the service is specifically a micro service, the message event is used for micro service notification, and an MQ mechanism is adopted between the client and the central event server to provide transit service of the message event.
Further wherein the interim message event queue, when identified as a coordination test, sends the interim message event to a central event server as a microservice notification message event.
Further, each client where the service is located uniquely, continuously and incrementally numbers the message events to be sent by the client; the central event server receives the message events and stores the maximum sequence number at the central event server for each client that has sent and been correctly received a message event.
Further, the central event server stores message events of each service, the message events are stored in a sequence to be sent and a cache backup queue, the central event server is simultaneously provided with a loss queue, the cache backup sequence is used for storing the message events received by the central event server, and the sequence to be sent is used for storing each subscribed message event and the message event to be sent; the miss queue holds sequence numbers for message events that are less than the maximum sequence number and have not been received.
Further, the client where the service is located serves as a subscriber of the message event and subscribes to the topic of the message event from the central event server.
Further, the client can perform format conversion on the message event in real time, wherein the converted format is in a json form.
Further, the central event server broadcasts the message event to all clients subscribed to the topic in the form of a page message.
Further, when the central event server receives the information of subscribing the message event, whether the subscribed message event is stored is judged, and when the central event server judges that the subscribed message event is not stored locally, a query request is constructed according to the topic key words of the subscribed message event, and the query request is broadcasted to the client related to the subscribed message event.
Further, the client pushes the message event to the central event server according to the difference of the priority or the subscription number.
Further, the message event is specifically a message notification event of a parameter configuration change in the microservice. The invention aims to reduce the dependence of each service, reduce coupling and improve the independence of each service. Maintenance and deployment are facilitated. While the canonical event standard describes event data in a common format to provide interoperability across services, platforms, and systems.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 is a schematic diagram of a prior art microservice call logic.
FIG. 2 is a schematic diagram of the micro-service invocation logic of the present invention.
Fig. 3 is a schematic diagram of the system of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention. Those skilled in the art will appreciate that message queues, message sequences, event notifications and event message notifications, and that different expressions have the same meaning in the present scenario for the specific context.
Example 1
As shown in fig. 1, the microservice architecture style is a method for developing a single application into a set of small services, each running in its own process, and the communication between services uses a lightweight communication mechanism (usually using HTTP resource API). These services are built around business capabilities and can be deployed independently through fully automated deployment mechanisms. These services share a minimal centralized management, and services can be developed in different languages, using different data storage technologies. And each system informs each service mode through a restful API mode. The calling among all the services is complex, disordered and difficult to maintain and deploy, and the whole body is dragged.
For this reason, the present application provides a method and a system for executing services based on a message communication manner, as shown in fig. 2, in the present solution, all services perform data exchange through a central event server, decoupling the dependency between the services, and all message service events also adopt the standard of cloudEvents, which provides SDKs of each programming language, thereby facilitating the docking of research and development personnel. Communication efficiency may also be improved by a unified standard. The developer only needs to pay attention to the business itself, and when the information in a certain service changes, the developer pushes a message event to the central event server in a message event notification mode. In the central event server, the logic relation mapping chart of each service is stored for each service application, and the central event server is used for undertaking the tasks of receiving, processing, circulating and sending the message events. The central event server includes a resource manager for creating a message event transmission sequence, receiving service identification, ID, information in the message event, and mapping an identifier of a current message queue to an identifier of a service in a target message queue for use with the target message queue service.
As shown in fig. 3, the message event communication-based microservice system includes a plurality of clients and a central event server.
Preferably, the client where each service is located stores three message queues, the three message queues perform message event pushing on the central event server according to different priorities or subscription numbers, the message notification sequence stores a temporary event message pushing event, and the temporary event message pushing event is a message event representing the setting change during the test operation of the service set; sending the interim message push event to a central event server when in a coordinated or centralized test; the interim message event may optionally be a microservice message event.
One of the message queues stores log information records which are not subscribed, the log information records correspond to message events, one of the message queues stores message event subscription events which are set with a threshold, optionally, the set threshold is a single subscription message, the single subscription message is directly sent to a client which is subscribed with the corresponding service by the client which is subscribed with the service, and when the number of subscriptions is greater than the set threshold, the event message is sent to the central event server. An alternative scenario is to prefer this approach when both microservices are in the same client.
The message event may also be specifically a message notification event, the central event server stores message events of each service, the message events are stored in a queue to be sent and a cache backup queue, in addition, the central event service is further provided with a loss queue, the cache backup sequence is used for storing the message events received by the central event server, and the sequence to be sent is used for storing each subscribed message event and executing sending.
The message event can be packaged into message data to be sent, each client at which the service is located uniquely, continuously and progressively numbers the message to be sent, and the maximum sequence number of the message which is sent and correctly received by each client is stored on the central event server, and the maximum sequence number immediately shows the sequence number of the next message to be received; the central event server also establishes a circular queue for each client that holds sequence numbers that are less than the maximum sequence number and for which no message notifications are received, referred to as a miss queue. If the received message is equal to the maximum sequence number, it may be sent to the client corresponding to the subscribed service. If the message less than the maximum serial number is received, searching a lost queue, and if the message is received for the first time in the lost queue, sending the message to a client machine corresponding to the subscription service; if not in the loss queue, the message is a retransmit message, which is discarded; if the sequence number of the received message is greater than the maximum sequence number, the message is sent to the client subscribing to the service, and messages between the sequence number and the maximum sequence number (including the maximum sequence number) of the message are added to the miss queue.
And the central event server stores the received message sent by the client where the service is located. When a client of a newly subscribed server receives a request, the client of the corresponding service sends the request to the central event server when the client of the subscribed service needs to inquire or re-subscribe the message event of the corresponding service, and when the client of the subscribed service executes data inquiry, the client of the subscribed service sends the request to the central event server.
The central event server may optionally include a message proxy server, which serves as an event-driven backbone and is responsible for message topic management, subscription management, message reception and broadcast, and the like. The client of the service can optionally send the real-time event information with the subscription relationship to the topic of the message proxy server in a message form. The client machine where other services are located serves as a subscriber of the message, and subscribes a related theme to the message proxy server through the central event server, optionally, when the client machine where the services are located can perform format conversion on the event in real time, the converted format can be selected to be a json form, and the optional central event server broadcasts the event change message to all the client machines subscribing the theme in a page message form; after the client receives the broadcast, the client updates the display of the relevant status of the service. The central event server optionally stores a subscription relationship association graph, and the optional subscription relationship may be based on a subscription with a service or based on variable setting in logic development.
The central event server judges whether the subscribed service message events are stored in the local message queue according to the subscription relation correlation diagram of the sending queue and the balance relation between the message inquired by the client of the subscription service and different sub-server units and through the response time and the transmission efficiency stored in the subscribed sub-server units to switch, when judging that the subscribed service message events do not exist locally, a query request is constructed according to the topic keywords of the message, the data query is executed on the local data, the transmission and the load balance of the client where the service is located are carried out, when the one-to-one corresponding subscription relation exists, the notification of the subscribed message events is directly taken over, when the message events corresponding to the topic events do not exist, the query sending request is forwarded to the client where the corresponding service is located, the client where the specified service is located sends the topic event message events, and sending the information to a central event server, and forwarding the information to a client where the service subscribed to the information event is located by the central event server.
The optional one-to-one corresponding subscription relationship is forwarded and inquired by the central event server, a scheme of a tight coupling relationship between complex and messy micro-services is converted into a simple, clear and easy-to-maintain, expanded and communicated management scheme, events are uniformly pushed to MQ for transfer, the performance is improved, and a plurality of API requests are avoided.
In the optional application scenario, a producer and consumer mode is adopted in a mode of publishing and subscribing, the service for generating the event is the producer, and the service for receiving the event is the consumer. According to the scheme, MQ is used as an event transit service, and cloudEvents are used as a specification of describing event data in a general format. The producer needs to construct data of the generated events according to the clooudEvents standard and push the data to MQ, and then the data is read by the subscribed consumers and analyzed and processed according to the clooudEvents standard. The producer does not need to be concerned about how many consumers there are, for example: and if the user leaves the job event, the consumer subscribing to the event has other business systems besides the user management system, and can receive the event leaving the job only by subscribing. The consumer also need not be concerned with which producer the event originated, for example: the administrator can modify the user profile in the management center, and the user can modify the personal profile in the client. The consumer only needs to subscribe to the event of the user profile modification, and the corresponding event can be received no matter where the user profile is modified.
Alternatively, the main purpose of setting up message queues is to provide routing and to ensure reliable delivery of messages. When sending a message queue, if the recipient is unavailable, the message queue will hold the message until successfully delivered. Optional message queue options, the MQ may be employed to provide a common set of APIs for applications to call and a common set of messaging semantics to ensure that messages must be delivered and only delivered once. Message queue communications are asynchronous and reliable. Optionally, the micro service system platform based on message communication may be based on WSE2.0 architecture, and write various self-defined classes through a programmable interface provided by the platform, and then implement the function of sending and receiving SOAP messages based on message queues through the classes, and implement that the message queues use MSMQ by using Win platform and NET technology.
Example 2
Based on the examples described above, the features relating to the method steps in one embodiment can be implemented by a computer device/system provided by the present invention, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement any one of the methods in the embodiments described above.
It will be understood by those skilled in the art that all or part of the processes in the methods of the embodiments described above may be implemented by a computer program to instruct associated hardware, where the program may be stored in a non-volatile computer-readable storage medium, and in the embodiments of the present invention, the program may be stored in the storage medium of a computer system and executed by at least one processor in the computer system to implement the processes including the embodiments of the video playing methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.
Accordingly, a storage medium is also provided, on which a computer program is stored, wherein the program, when executed by a processor, implements the method steps as referred to in any of the embodiments above.
The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (7)
1. A microservice system based on message event communication, characterized by:
the message event communication-based micro-service system comprises a plurality of clients and a central event server;
each client corresponds to a service, and the central event server performs data updating on the services on the clients in a mode of sending message events so as to decouple the dependence among the services on the plurality of clients, wherein all the message events adopt the standard of cloudEvents; the communication between the services on the plurality of clients adopts a lightweight communication mechanism; three message queues are stored on a client where each service is located, wherein the three message queues comprise a temporary message event queue, an unsubscribed message event queue and a message event sending queue; the temporary message event queue stores temporary message events representing configuration changes caused by centralized test operation among services; the unsubscribed message event queue for storing message events for which service log information changes are not subscribed to,
the message event sending queue stores message events to be sent which are subscribed, and is set to send the subscribed message events to the central event server;
the central event server stores a logical relationship mapping chart of each service, and receives, processes, circulates and transmits message events based on the logical relationship of each service;
the client where each service is located uniquely, continuously and incrementally numbers the message events to be sent by the client; the central event server receives the message events, and stores the maximum sequence number of each client which has sent and correctly received the message events on the central event server; the central event server stores message events of various services, the message events are stored in a to-be-sent sequence and a cache backup queue, the central event server is simultaneously provided with a loss queue, the cache backup sequence is used for storing the message events received by the central event server, and the to-be-sent sequence is used for storing various subscribed message events and the message events to be sent; the loss queue maintains sequence numbers of message events that are less than a maximum sequence number and have not been received;
the service is specifically a micro service, the message event is used for micro service notification, and an MQ mechanism is adopted between the client and the central event server to provide transfer service of the message event; the interim message event queue, when identified as a coordination test, sends the interim message event to a central event server as a microservice notification message event.
2. The system of claim 1, wherein: the client where the service is located serves as a subscriber of the message event and subscribes to the topic of the message event from the central event server.
3. The system of claim 2, wherein: the client can perform format conversion on the message event in real time, and the converted format is a json form.
4. The system of claim 3, wherein: and the central event server broadcasts the message event to all clients subscribed with the theme in the form of page message.
5. The system of claim 4, wherein: when the central event server receives the information of subscribing the message event, whether the subscribed message event is stored is judged, and when the central event server judges that the subscribed message event is not stored locally, a query request is constructed according to the topic key words of the subscribed message event, and the query request is broadcasted and sent to the client machine related to the subscribed message event.
6. The system of claim 5, wherein: and the client pushes the message event to the central event server according to different priorities or subscription numbers.
7. The system as claimed in any one of claims 1-6, wherein: the message event is specifically a message notification event of parameter configuration change in the microservice.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110217201.7A CN112596933B (en) | 2021-02-26 | 2021-02-26 | Micro-service system based on message event communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110217201.7A CN112596933B (en) | 2021-02-26 | 2021-02-26 | Micro-service system based on message event communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112596933A CN112596933A (en) | 2021-04-02 |
| CN112596933B true CN112596933B (en) | 2021-05-14 |
Family
ID=75207518
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110217201.7A Active CN112596933B (en) | 2021-02-26 | 2021-02-26 | Micro-service system based on message event communication |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112596933B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113641400A (en) * | 2021-08-10 | 2021-11-12 | 广州鲁邦通智能科技有限公司 | Method for sharing micro-service public resource by multi-version service, API gateway and management system |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111679918A (en) * | 2019-03-11 | 2020-09-18 | 华为技术有限公司 | Message transmission method and device |
| CN111866191A (en) * | 2020-09-24 | 2020-10-30 | 深圳市易博天下科技有限公司 | Message event distribution method, distribution platform, system and server |
| US20200401991A1 (en) * | 2019-04-11 | 2020-12-24 | Caastle, Inc. | Systems and methods for electronic platform for transactions of wearable items |
-
2021
- 2021-02-26 CN CN202110217201.7A patent/CN112596933B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111679918A (en) * | 2019-03-11 | 2020-09-18 | 华为技术有限公司 | Message transmission method and device |
| US20200401991A1 (en) * | 2019-04-11 | 2020-12-24 | Caastle, Inc. | Systems and methods for electronic platform for transactions of wearable items |
| CN111866191A (en) * | 2020-09-24 | 2020-10-30 | 深圳市易博天下科技有限公司 | Message event distribution method, distribution platform, system and server |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112596933A (en) | 2021-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105472042B (en) | The message-oriented middleware system and its data transferring method of WEB terminal control | |
| JP4521003B2 (en) | Apparatus and associated method for facilitating delivery and processing of push content | |
| CN112527525B (en) | Distributed event bus processing method, terminal and medium based on message queue | |
| US6868544B2 (en) | Method and system for general-purpose interactive notifications | |
| CN111258723B (en) | Transaction processing method, device, system, medium and equipment of distributed system | |
| CN113891114B (en) | Transcoding task scheduling method and device | |
| CN112596933B (en) | Micro-service system based on message event communication | |
| CN108289055B (en) | Distributed real-time chat system and method based on Redis subscription service | |
| CN110138753B (en) | Distributed message service system, method, apparatus, and computer-readable storage medium | |
| CN106899605B (en) | Communication method and device based on STOMP protocol | |
| CN114338769A (en) | Access request processing method and device | |
| CN111124717A (en) | Message delivery method, system and computer storage medium | |
| WO2022126837A1 (en) | Intelligent scheduling system for video monitoring service | |
| CN111475315A (en) | Server and subscription notification push control and execution method | |
| CN116800787A (en) | Vehicle-mounted communication method and system based on Ethernet communication protocol | |
| CN114938388B (en) | Distributed data transmission method, device, system and storage medium | |
| CN111049915A (en) | Message queue agent grid under container cloud and method | |
| CN115103017B (en) | Message middleware processing system and method | |
| CN115509716A (en) | Task scheduling method, system and storage medium | |
| CN114885020A (en) | Data transmission system and method | |
| CN115334155A (en) | Message queue agent method and device | |
| EP3920035B1 (en) | Message transmission/reception method, communication device, and program | |
| CN115834691B (en) | Distributed publishing and subscribing method and device, electronic equipment and storage medium | |
| US11777878B1 (en) | Message routing based on unavailability | |
| US20230171830A1 (en) | Apparatus and method for configuring data communication between robot components in different networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |