CN111131425B - Distributed system and communication method for distributed system - Google Patents
Distributed system and communication method for distributed system Download PDFInfo
- Publication number
- CN111131425B CN111131425B CN201911312649.6A CN201911312649A CN111131425B CN 111131425 B CN111131425 B CN 111131425B CN 201911312649 A CN201911312649 A CN 201911312649A CN 111131425 B CN111131425 B CN 111131425B
- Authority
- CN
- China
- Prior art keywords
- event message
- message
- micro server
- event
- micro
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Abstract
The system comprises a plurality of micro servers which are in communication connection through a message middleware, wherein a first micro server is used for matching characteristic information of a receiving party in an event message with characteristic information of each micro server when the event message corresponding to a local event is obtained so as to determine the receiving party of the event message; when the receiver is not the first micro server, sending the event message to the message middleware, so that the receiver can receive the event message through the message middleware; the second micro server is used for acquiring the event message in the message middleware and matching the characteristic information of the receiver in the event message with the characteristic information of the second micro server; and when the receiver is determined to be the second micro server according to the matching result, responding to the event message and issuing a local event corresponding to the event message.
Description
Technical Field
The present disclosure relates to the field of communications technologies, and in particular, to a distributed system and a communication method for the distributed system.
Background
In a continuously developed large-scale application, new service requirements and functions are continuously increased, the technology is continuously evolved, the technical architectures adopted by functional subsystems constructed by different teams may be different, and the development, deployment and operation modes of the subsystems are greatly different. If there is no uniform service framework inside the enterprise to perform the intercommunication in the technical layer, the development and operation and maintenance efficiency will be greatly restricted.
The traditional vertical application architecture can be improved by adopting a distributed service framework, but the communication mode among the micro servers in the distributed system in the mode is lack of flexibility, and the resource occupation rate is high.
Disclosure of Invention
An object of the present disclosure is to provide a distributed system and a communication method of the distributed system, so as to solve the above-mentioned related technical problems.
To achieve the above object, in a first aspect of the present disclosure, a distributed system is provided, the system including a plurality of micro servers, the micro servers being communicatively connected to each other through message middleware, wherein,
the first micro server is used for matching the characteristic information of the receiver in the event message with the characteristic information of each micro server to determine the receiver of the event message when the event message corresponding to the local event is acquired; when the receiver is not the first micro server, sending the event message to the message middleware, so that the receiver can receive the event message through the message middleware;
the second micro server is used for acquiring the event message in the message middleware and matching the characteristic information of the receiver in the event message with the characteristic information of the second micro server; and when the receiver is determined to be the second micro server according to the matching result, responding to the event message and issuing a local event corresponding to the event message.
Optionally, the first micro server is further configured to:
acquiring registration information of each micro server from a registration center;
and generating characteristic information corresponding to each micro server according to each registration information.
Optionally, the sending, by the first micro server, the event message to the message middleware includes: the first micro server takes the characteristic information of the first micro server as the publishing source characteristic information in the event message; determining an available target receiver from the receivers according to the state information of each micro server, wherein the state information is acquired from a registry and is used for representing the running state of the corresponding micro server; and updating the characteristic information in the event message according to the characteristic information of the target receiver, and sending the updated event message to the message middleware.
Optionally, the event message further includes type identification information, and the second micro server is further configured to determine that the event message is of a preset type according to the type identification information of the event message before matching receiver feature information in the target event message with feature information of the second micro server.
Optionally, the event message further includes publishing source feature information, and the second micro server is further configured to send, to the message middleware, a response event message indicating that the target event message is successfully received.
In a second aspect of the embodiments of the present disclosure, a communication method of a distributed system is provided, where the method includes:
when a first micro server of the distributed system acquires an event message corresponding to a local event, matching receiver characteristic information in the event message with characteristic information of each micro server to determine a receiver of the event message;
when the receiver is not the first micro server, sending the event message to a message middleware, so that the receiver can receive the event message through the message middleware;
a second micro server of the distributed system acquires an event message in a message middleware and matches receiver characteristic information in the event message with characteristic information of the second micro server;
and when the receiver is determined to be the second micro server according to the matching result, responding to the event message and issuing a local event corresponding to the event message.
Optionally, the feature information of each micro server is obtained by the first micro server by:
acquiring registration information of each micro server from a registration center;
and generating characteristic information corresponding to each micro server according to each registration information.
Optionally, the sending the event message to a message middleware includes:
taking the characteristic information of the first micro server as the publishing source characteristic information in the event message;
determining an available target receiver from the receivers according to the state information of each micro server, wherein the state information is acquired from a registry and is used for representing the running state of the corresponding micro server;
and updating the characteristic information in the event message according to the characteristic information of the target receiver, and sending the updated event message to a message middleware.
Optionally, the event message further includes type identification information, and before the receiver feature information in the target event message is matched with the feature information of the second micro server, the method further includes:
and the second micro server determines the event message to be a preset type according to the type identification information of the event message.
Optionally, the event message further includes publishing source feature information, and the method further includes:
and the second micro server sends a response event message representing that the target event message is successfully received to the message middleware.
The technical scheme at least comprises the following technical effects:
the first micro server is used as an event message sender, and when the event message is required to be sent, the event message can be packaged according to the data content required to be sent and a sending destination terminal, and a corresponding local event is issued. Further, when the first micro server monitors the local event, the first micro server may obtain an event message corresponding to the local event, and then determine a receiver of the event message according to receiver characteristic information in the event message. Finally, upon determining that the recipient is not the first micro server, the first micro server may send the event message to a message middleware, enabling a second micro server to receive the event message by listening to the message middleware. Therefore, the micro servers in the distributed system can perform bidirectional message transmission through one message middleware, so that the coupling degree between the micro servers and the message middleware can be reduced, resources are saved, and the flexibility of communication is guaranteed.
Additional features and advantages of the disclosure will be set forth in the detailed description which follows.
Drawings
The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure, but do not constitute a limitation of the disclosure. In the drawings:
fig. 1 is a block diagram of a distributed system shown in an exemplary embodiment of the present disclosure.
Fig. 2 is a schematic structural diagram of a distributed system according to an exemplary embodiment of the present disclosure.
Fig. 3 is a flowchart illustrating a communication method of a distributed system according to an exemplary embodiment of the disclosure.
Fig. 4 is a flowchart illustrating a communication method of a distributed system according to an exemplary embodiment of the disclosure.
Fig. 5 is a flowchart illustrating a communication method of a distributed system according to an exemplary embodiment of the disclosure.
Fig. 6 is a flowchart illustrating a communication method of a distributed system according to an exemplary embodiment of the disclosure.
Fig. 7 is a block diagram of an electronic device shown in an exemplary embodiment of the present disclosure.
Detailed Description
The following detailed description of specific embodiments of the present disclosure is provided in connection with the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating the present disclosure, are given by way of illustration and explanation only, not limitation.
Before introducing the communication method provided by the present disclosure, an application scenario of each embodiment of the present disclosure is introduced first, and each embodiment of the present disclosure may be applied to a distributed system to implement bidirectional communication between micro servers in the distributed system. The distributed system may be, for example, an enterprise management system, a game system, or other systems that require data synchronization. Different micro servers assume different functions, for example, in an enterprise management system, a financial module may be integrated into one micro server, a personnel module may be integrated into another micro server, and a business processing module may be integrated into other micro servers, and when a data update occurs (for example, there is a personnel change in the personnel module), other micro servers may need to synchronize the updated data (for example, the financial module needs to update data for the personnel change), or may not need to synchronize the updated data (for example, the business processing module does not need to update data for the personnel change).
To enable communication between microservers in a distributed system, the present disclosure provides a distributed system, illustrated with reference to the block diagram of one distributed system shown in fig. 1. The system may include message middleware and a plurality of micro servers (only exemplified by micro server 1, micro server 2, and micro server 3 in the figure), wherein each micro server may issue events as a first micro server or process events as a second micro server. That is, each micro server in the distributed system may publish its own event message and obtain the event message from the message middleware.
The first micro server is used for matching receiver characteristic information in the event message with characteristic information of each micro server to determine a receiver of the event message when the event message corresponding to the local event is acquired; when the receiver is not the first micro server, sending the event message to the message middleware, so that the receiver can receive the event message through the message middleware;
the second micro server is used for acquiring the event message in the message middleware and matching the characteristic information of the receiver in the event message with the characteristic information of the second micro server; and when the receiver is determined to be the second micro server according to the matching result, responding to the event message and issuing a local event corresponding to the event message.
Specifically, for the event message, the event message may be encapsulated by the first micro server. It should be appreciated that in the microserver, publication of a messaging event is derived from a published local event. For example, when the first micro server needs to send data to the second micro server, the first micro server may encapsulate data information that needs to be sent and feature information of the second micro server (i.e., feature information of a receiver) to obtain the event message, and issue a local event according to the event message. The first micro server may store therein characteristic information of each micro server associated with the first micro server. In addition, the first micro server can also monitor a local event, and can analyze a corresponding event message when the local event is monitored. Furthermore, the receiver characteristic information in the analysis result can be matched with the characteristic information of each micro server, and after the receiver of the event message is determined to be the second micro server, the event message is sent to the message middleware.
In addition, when the receiving party is the first micro server, the first micro server may issue a corresponding local event according to the event message, and further perform corresponding service logic processing.
For the message middleware, the message middleware can send the event message sent by the micro server to all the micro servers at regular time, and the micro servers can also monitor the event message in the message middleware in real time or acquire the event message from the message middleware at regular time.
In an embodiment, the encapsulated data information may further include event handling information for characterizing which data update is performed by the first micro server. The event handling information may also be in the form of an event type combined with variable data when predefined events exist in the system. For example, when a user data is newly added to the first micro server, an event processing information indicating the newly added user data of other micro servers may be generated according to the data update information of the newly added event; or, the code of the event of newly-added user data may be predefined as a1 in the system, and the event processing information may be the combination of the code a1 and the data specifically required to be operated.
For the receiver characteristic information, the receiver characteristic information may include one or more of a micro server name, an IP (Internet Protocol), and a port. It should be understood that in implementation, multiple micro servers may be located on the same host, sharing the same IP, but the ports of different micro servers on the same host are different. Similarly, multiple micro servers having the same micro server name may also have port and/or IP differences from each other. Thus, a micro server can be uniquely identified based on the micro server name, IP, and port.
In addition, for an event message to be sent, the receiver may also include one or more. When the receiver is one, the receiver can be characterized by combining the determined micro server name, IP and port. When the number of the receivers is multiple, the pair of receivers can be characterized by an ant path. For example, the characteristic information of the receiving party may be "order service: 127.0.0.1:8080 ", the destination server of the event message is the micro server named order service, IP is 127.0.0.1, port is 8080. Similarly, for the case where the recipient is multiple servers, can the corresponding wildcard "? ", etc. represent the recipient characteristic information. For example, the address information of the destination server in the event message may be 127.0.0.1:, and the destination server of the event message is all micro servers with an IP of 127.0.0.0.1, including but not limited to 127.0.0.1:8080 and 127.0.0.1: 8090.
That is, for the second micro server, there may be address information of a plurality of micro servers as the receiving party in the event message acquired by the second micro server from the message middleware. In specific implementation, when the second micro server acquires the event message in the message middleware, the second micro server may match the receiver characteristic information in the event message with the characteristic information of the second micro server. If one of the characteristic information of the receiver in the event message is consistent with the characteristic information of the second server, the second micro server may issue a local event corresponding to the event message in response to the event message.
In the distributed system, the first micro server is used as an event message sender, and when the event message needs to be sent, the event message can be encapsulated according to the data content and the sending destination end, and the corresponding local event is issued. Further, when the first micro server monitors the local event, the first micro server may obtain an event message corresponding to the local event, and then determine a receiver of the event message according to receiver characteristic information in the event message. Finally, upon determining that the recipient is not the first micro server, the first micro server may send the event message to a message middleware, enabling a second micro server to receive the event message by listening to the message middleware. Therefore, the micro servers in the distributed system can perform bidirectional message transmission through one message middleware, so that the coupling degree between the micro servers and the message middleware can be reduced, resources are saved, and the flexibility of communication is guaranteed.
In a possible embodiment, the first micro server is further configured to:
acquiring registration information of each micro server from a registration center;
and generating characteristic information corresponding to each micro server according to each registration information.
For example, referring to the structural diagram of a distributed system shown in fig. 2, when registering with the registry, app1 may initialize a local application and encapsulate local application information. In addition, at registration time, the app1 may also pull registration information of other registered micro servers in the registry. For example, the app1 may pull registration information of the app2, the app3, the app4, the app5, and the app6 from the registry, package each registration information, and store a packaged result locally to the app 1.
In this way, the app1 obtains the event message body corresponding to the local event, and may determine the recipient of the event message by matching the recipient feature information in the event message with the feature information of each micro server stored locally.
It should be noted that each micro server in the distributed system can issue events as a first micro server or process events as a second micro server. That is, in the distributed system, each micro server may be configured to:
acquiring registration information of each micro server from a registration center;
and generating characteristic information corresponding to each micro server according to each registration information.
In addition, the micro server may be down while running, and in this case, the event message should be prevented from being sent to the micro server.
Thus, in one possible embodiment, the first micro server sending the event message to the message middleware comprises:
the first micro server takes the characteristic information of the first micro server as the publishing source characteristic information in the event message;
determining an available target receiver from the receivers according to the state information of each micro server, wherein the state information is acquired from a registry and is used for representing the running state of the corresponding micro server;
and updating the characteristic information in the event message according to the characteristic information of the target receiver, and sending the updated event message to the message middleware.
Still taking fig. 2 as an example for illustration, after parsing the event message corresponding to the monitored local event, the app1 determines that the recipient characteristic information of the event message includes the app 2-6. The app1 may also determine the operational status of the app2-5 through the registry before sending the event message to messaging middleware. If the apps 3 and 5 are in the downtime state, the apps 1 may use their own feature information as the publishing source information of the event message, update the recipient information in the event message, and use the feature information of the apps 2, apps 4 and apps 6 that are in the available state as the recipient feature information. By adopting the mode, when the micro server issues the event message to the message middleware each time, the state of a receiver of the event message can be determined through the registration center, so that the event message can be sent only to the micro server capable of normally receiving the event message, the probability of successfully receiving the event message is improved, and the effect of reducing the resource cost is achieved.
In addition, in another possible implementation manner, when the first micro server encapsulates the event message, the first micro server may also first obtain an operating state of a receiver of the event message through a registry, and encapsulate feature information of the receiver into the event message for the receiver capable of normally receiving the event message, thereby further improving a probability that the event message is successfully received, and reducing resource overhead.
It should be noted that the registry does not obtain the operating status of the micro server in real time, and in one embodiment, the app4 may also be down during the process of sending the event message to the apps 2, 4 and 6. In this case, the app1 cannot determine whether the event message was successfully received.
Therefore, in a possible implementation, the second micro server is further configured to send a response event message to the message middleware, wherein the response event message is indicative of successful reception of the target event message.
As explained above for the previous embodiment, apps 2, 6 may encapsulate a response event message to characterize the target event message as successfully received after successfully receiving the apply message through the message middleware. The release source feature information in the response event message is the feature information of the app2 and the app6, respectively, and the recipient feature information in the response event message is the feature information of the app 1.
In this way, the app1 can determine that the app4 did not successfully receive the target event message in response to receiving the response event message, and can then make a reissue of the target event message to the app4 in a subsequent process. In this way, the usability of the micro server communication process can be improved.
Optionally, the event message further includes type identification information, and the second micro server is further configured to determine that the event message is of a preset type according to the type identification information of the event message before matching the receiver characteristic information in the target event message with the characteristic information of the second micro server.
The preset type may be a general event message type or a custom message type. Still taking fig. 2 as an example, 6 micro servers, respectively denoted app1-6, are included in the distributed system, with message type M1 being customized among micro server apps 1-6. In this way, the micro server app1-6 may listen to an event message in the message middleware at runtime, where, when parsing the listened event message, the type of the event message may be determined first, and for an event message whose event message type is not M1, no subsequent processing is performed.
That is, the micro server app1-6 can ignore event messages of other micro servers that are heard, thereby being able to reduce interference from other micro servers outside the distributed system. Meanwhile, by adopting the mode, the micro servers in the distributed system can be further divided, and the flexibility of communication among the micro servers is improved.
The present disclosure also provides a communication method of a distributed system, which is illustrated with reference to fig. 3, and includes:
s31, when acquiring an event message corresponding to a local event, a first micro server of the distributed system matches the receiver characteristic information in the event message with the characteristic information of each micro server to determine the receiver of the event message;
s32, when the receiver is not the first micro server, the event message is sent to a message middleware, so that the receiver can receive the event message through the message middleware;
s33, the second micro server of the distributed system obtains the event message in the message middleware and matches the receiver characteristic information in the event message with the characteristic information of the second micro server;
s34, when the receiver is determined to be the second micro server according to the matching result, responding to the event message, and issuing a local event corresponding to the event message.
With regard to the steps in the above embodiments, the detailed implementation of each step has been described in detail in the embodiments related to the distributed system, and will not be elaborated herein.
By adopting the technical scheme, the first micro server is used as an event message sender, and when the event message is required to be sent, the event message can be packaged according to the data content required to be sent and a sending destination terminal, and the corresponding local event is issued. Further, when the first micro server monitors the local event, the first micro server may obtain an event message corresponding to the local event, and then determine a receiver of the event message according to receiver characteristic information in the event message. Finally, upon determining that the recipient is not the first micro server, the first micro server may send the event message to a message middleware, enabling a second micro server to receive the event message by listening to the message middleware. Therefore, the micro servers in the distributed system can perform bidirectional message transmission through one message middleware, so that the coupling degree between the micro servers and the message middleware can be reduced, resources are saved, and the flexibility of communication is guaranteed.
The present disclosure also provides a communication method of a distributed system, which is applied to a first micro server as an event message sender, where the first micro server may be any micro server in the distributed system, and with reference to a flowchart of the communication method of the distributed system shown in fig. 4, the method includes:
s41, when acquiring the event message corresponding to the local event, matching the receiver characteristic information in the event message with the characteristic information of each micro server to determine the receiver of the event message;
and S42, if the receiver is not the first micro server, sending the event message to a message middleware, so that the receiver can receive the event message through the message middleware.
Specifically, in step S41, the event message may be encapsulated by the first micro server. It should be appreciated that in the microserver, publication of a messaging event is derived from a published local event. For example, when the first micro server needs to send data to the second micro server, the first micro server may encapsulate data information that needs to be sent and feature information of the second micro server (i.e., feature information of a receiver) to obtain the event message, and issue a local event according to the event message. The first micro server may store therein characteristic information of each micro server associated with the first micro server. In addition, the first micro server can also monitor a local event, analyze the corresponding event message when the local event is monitored, match the receiver characteristic information in the analysis result with the characteristic information of each micro server, and send the event message to the message middleware after the receiver of the event message is determined to be the second micro server.
In one embodiment, the encapsulated data information may include event handling information for characterizing which data update is performed by the first micro server. When there is a predefined event in the system, it can also be in the form of a combination of event type and variable data. For example, when a new user data is added to the first micro server, event processing information indicating the new user data of other micro servers can be generated according to the data updating information of the new event; or, the code of the event of newly-added user data may be predefined as a1 in the system, and the event processing information may be the combination of the code a1 and the data specifically required to be operated.
For the receiver characteristic information, the receiver characteristic information may include one or more of a micro server name, an IP (Internet Protocol), and a port. It should be understood that in an implementation, multiple micro servers may be located on the same host, sharing the same IP, but the ports of different micro servers on the same host are different. Similarly, multiple micro servers having the same micro server name may also have port and/or IP differences from each other. Thus, a micro server can be uniquely identified based on the micro server name, IP, and port.
In addition, for an event message to be sent, the receiver may also include one or more. When the receiver is one, the receiver can be characterized by combining the determined micro server name, IP and port. When the number of the receivers is plural, the pair of receivers may be characterized by an ant path. For example, the characteristic information of the receiving party may be "order service: 127.0.0.1:8080 ", the destination server of the event message is the micro server named order service, IP is 127.0.0.1, port is 8080. Similarly, for the case where the recipient is multiple servers, can one pass the corresponding wildcard "? ", etc. represent the recipient characteristic information. For example, the address information of the destination server in the event message may be 127.0.0.1:, and the destination server of the event message is all micro servers with an IP of 127.0.0.0.1, including 127.0.0.1:8080 and 127.0.0.1: 8090.
In step S42, if the receiving party is the first micro server, the first micro server may issue a local event according to the event message, and further perform corresponding service logic processing.
By adopting the communication method, the first micro server is used as an event message sender, and when the event message is required to be sent, the event message can be packaged according to the data content required to be sent and the sending destination, and the corresponding local event is issued. Further, when the micro server monitors the local event, the micro server may obtain an event message corresponding to the local event, and then determine a receiver of the event message according to receiver characteristic information in the event message. Finally, upon determining that the recipient is not the first micro server, the first micro server may send the event message to a message middleware, thereby enabling the recipient to receive the event message by listening to the message middleware. That is to say, a plurality of micro servers can perform bidirectional message transmission through one message middleware, so that the coupling degree between the micro servers and the message middleware can be reduced, resources are saved, and meanwhile, the flexibility of communication is ensured.
In a possible implementation manner, the characteristic information of the micro server in step S41 is obtained by:
acquiring registration micro server information of a registration center;
and generating characteristic information corresponding to each micro server according to the information of each registered micro server.
Taking fig. 2 as an example, app1 may initialize a local application and encapsulate local application information when registering with the registry. In addition, at registration time, the app1 may also pull registration information of other registered micro servers in the registry. For example, the app1 may pull registration information of the app2, the app3, the app4, the app5, and the app6 from a registry, package each registration information, and store a packaged result locally to the app 1.
In this way, the app1 obtains the event message body corresponding to the local event, and may determine the recipient of the event message by matching the recipient feature information in the event message with the feature information of each micro server stored locally.
It is noted that the micro server may also be down while running, in which case sending event messages to it should be avoided.
Therefore, in a possible implementation, the event message further includes publishing source characteristic information, and the communication method is applied to a first micro server as an event message sender, and the method includes:
s51, when acquiring the event message corresponding to the local event, matching the receiver characteristic information in the event message with the characteristic information of each micro server to determine the receiver of the event message;
s52, if the receiver is not the first micro server, the characteristic information of the first micro server is used as the characteristic information of the issuing source in the event message;
s53, determining an available target receiver from the receivers according to the state information of each micro server; the state information is acquired from a registration center and is used for representing the running state of the corresponding micro server;
s54, according to the characteristic information of the target receiver, updating the characteristic information in the event message, and sending the updated event message to a message middleware.
Taking fig. 2 as an example for illustration, after the app1 parses the event message corresponding to the monitored local event, it is determined that the characteristic information of the receiver of the event message includes the app 2-6. The app1 may also determine the operating state of the app2-5 through the registry before sending the event message to messaging middleware. If the apps 3 and 5 are in the downtime state, the apps 1 may use their own feature information as the publishing source information of the event message, update the recipient information in the event message, and use the feature information of the apps 2, apps 4 and apps 6 that are in the available state as the recipient feature information. By adopting the mode, when the micro server issues the event message to the message middleware each time, the state of a receiver of the event message can be determined through the registration center, so that the event message can be sent only to the micro server capable of normally receiving the event message, the probability of successfully receiving the event message is improved, and the effect of reducing the resource cost is achieved.
In another possible implementation manner, when encapsulating the event message, the first micro server may also first obtain an operating state of a receiver of the event message through a registry, and encapsulate feature information of the receiver into the event message for the receiver capable of normally receiving the event message, thereby further improving the probability of successfully receiving the event message and reducing resource overhead.
It should be noted that the event message may further include time information, event message ID information, event message status information (e.g., sending status, receiving status), and the like. For example, the event message includes event message state information, the first micro server may further determine the state information of the event message after acquiring the event message corresponding to the local event, and if the state information of the event message is a receiving state, the processing is not performed, and the configuration and the form of the event message are not limited in the present disclosure.
The present disclosure also provides another communication method of a distributed system, which is applied to a second micro server as an event message receiver, where the second micro server may be any micro server in the distributed system, and with reference to a flowchart of a communication method shown in fig. 6, the method includes:
s61, acquiring a target event message in the message middleware, and matching the receiver characteristic information in the target event message with the characteristic information of the second micro server;
and S62, if the receiver is determined to be the second micro server according to the matching result, responding to the target event message and issuing a preset local event corresponding to the target event message.
Specifically, in step S61, the event message may be packaged by the first micro server as the sender of the event message. When the first micro server needs to send data to the second micro server, the first micro server may encapsulate data information that needs to be sent and feature information of the second micro server (i.e., feature information of a receiver), so as to obtain the event message. And after determining that the receiver of the event message is not the first micro server, sending the event message to a message middleware.
The second micro server may monitor the message middleware, analyze the monitored event message, match receiver characteristic information in the target event message obtained by the analysis with characteristic information of the second micro server, and issue a preset local event corresponding to the target event message in response to the target event message if the receiver is determined to be the second micro server according to a matching result.
As described above, the second micro server may be any micro server in the distributed system, and the second micro server may also be the same micro server as the first micro server. That is to say, with the communication method provided by the present application, multiple micro servers can communicate with each other through the same message middleware, and the sender of each event message can encapsulate the feature information of the receiver in the event message and send the event message to the message middleware. Correspondingly, the receiver of each event message can acquire the corresponding event message for processing by monitoring the message middleware. In the distributed system, each micro server can be a sender or a receiver of the event message, so that asynchronous bidirectional communication of a plurality of micro servers is realized through one message middleware, resources are saved, and the flexibility of communication is guaranteed.
In a possible implementation manner, the event message further includes type identification information, and before the step S61, the communication method further includes:
and determining the event message as a preset type according to the type identification information of the event message.
The preset type may be a general event message type or a custom message type. Still taking fig. 2 as an example, 6 micro servers, respectively denoted app1-6, are included in the distributed system, with message type M1 being customized among micro server apps 1-6. In this way, the micro server app1-6 may listen to an event message in the message middleware at runtime, where, when parsing the listened event message, the type of the event message may be determined first, and for an event message whose event message type is not M1, no subsequent processing is performed.
That is, micro server app1-6 may ignore event messages heard from other micro servers, thereby reducing interference from other micro servers outside the distributed system. Meanwhile, by adopting the mode, the micro servers in the distributed system can be further divided, and the flexibility of communication among the micro servers is improved.
In another possible embodiment, before the obtaining a target event message in message middleware and matching receiver characteristic information in the target event message with the characteristic information of the second micro server, the method includes:
acquiring registration micro server information of a registration center;
and generating characteristic information corresponding to each micro server according to the information of each registered micro server.
Taking fig. 2 as an example, when registering with the registry, app1 may initialize a native application and encapsulate native application information. In addition, at the time of registration, app1 may also pull registration information of other registered micro servers in the registry. For example, the app1 may pull registration information of the app2, the app3, the app4, the app5, and the app6 from the registry, package each registration information, and store a packaged result locally to the app 1.
In this way, when the app1 acquires the event message body corresponding to the local event, it may determine the recipient of the event message by matching the recipient feature information in the event message with the feature information of each micro server stored locally.
In some scenarios, the micro server may also be down while running, in which case sending event messages to it should be avoided.
Referring to fig. 2, after parsing an event message corresponding to a monitored local event, the app1 determines that recipient characteristic information of the event message includes the app 2-6. The app1 may also determine the operational status of the app2-5 through the registry before sending the event message to messaging middleware. If the apps 3 and 5 are in the downtime state, the apps 1 may use their own feature information as the publishing source information of the event message, update the recipient information in the event message, and use the feature information of the apps 2, apps 4 and apps 6 that are in the available state as the recipient feature information.
It should be noted that the registry does not obtain the operating status of each micro server in real time, and in an embodiment, the app4 may also be down during the process of sending the event message to the apps 2, 4, and 6. In this case, the app1 cannot determine whether the event message was successfully received.
Thus, in a possible implementation, the event message further includes publishing source characteristic information, and the method further includes:
and sending a response event message which represents that the target event message is successfully received to the message middleware.
As explained above for the previous embodiment, apps 2, 6 may encapsulate a response event message to characterize the target event message as successfully received after successfully receiving the apply message through the message middleware. The release source feature information in the response event message is the feature information of the app2 and the app6, respectively, and the recipient feature information in the response event message is the feature information of the app 1.
In this way, the app1 can determine that app4 did not successfully receive the target event message in response to receiving the response event message, and can then make a reissue of the target event message to the app4 in a subsequent process. In this way, the usability of the micro server communication process can be improved.
It is further noted that, for simplicity of description, the above-mentioned method embodiments are all expressed as a series of combinations of acts, but those skilled in the art will recognize that the present invention is not limited by the order of acts described. Further, those skilled in the art will appreciate that the embodiments described in this specification are presently preferred and that no particular act is required to implement the invention.
Fig. 7 is a block diagram illustrating an electronic device 700 in accordance with an example embodiment. For example, electronic device 700 may be provided as a microserver. Referring to fig. 7, an electronic device 700 includes a processor 722, which may be one or more in number, and a memory 732 for storing computer programs that are executable by the processor 722. The computer programs stored in memory 732 may include one or more modules that each correspond to a set of instructions. Further, the processor 722 may be configured to execute the computer program to perform the communication method for the distributed system of the first micro server or the second micro server described above.
Additionally, the electronic device 700 may also include a power component 726 that may be configured to perform power management of the electronic device 700 and a communication component 750 that may be configured to enable communication, e.g., wired or wireless communication, of the electronic device 700. The electronic device 700 may also include input/output (I/O) interfaces 758. The electronic device 700 may operate based on an operating system, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, etc., stored in memory 732.
In another exemplary embodiment, there is also provided a computer readable storage medium including program instructions which, when executed by a processor, implement the steps of the above-described communication method for a distributed system of a first micro server or a second micro server. For example, the computer readable storage medium may be the memory 832 including program instructions described above that are executable by the processor 822 of the electronic device 800 to perform the communication method shown in fig. 1.
In an exemplary embodiment, a computer program product is also provided, which comprises a computer program executable by a programmable apparatus, the computer program having code portions for performing the above-described communication method for a distributed system of first micro servers when executed by the programmable apparatus.
In another exemplary embodiment, a computer program product is also provided, which comprises a computer program executable by a programmable apparatus, the computer program having code portions for performing the above-described communication method for a distributed system of second micro servers when executed by the programmable apparatus.
The preferred embodiments of the present disclosure are described in detail above with reference to the accompanying drawings, however, the present disclosure is not limited to the specific details in the above embodiments, and various simple modifications may be made to the technical solution of the present disclosure within the technical idea of the present disclosure, and these simple modifications all belong to the protection scope of the present disclosure.
It should be noted that, in the above embodiments, the various features described in the above embodiments may be combined in any suitable manner, and in order to avoid unnecessary repetition, various possible combinations will not be further described in the present disclosure.
In addition, any combination of various embodiments of the present disclosure may be made, and the same should be considered as the disclosure of the present disclosure, as long as it does not depart from the spirit of the present disclosure.
Claims (10)
1. A distributed system comprising a plurality of micro-servers communicatively coupled via message middleware and each micro-server serving as a first micro-server to issue its own event message and/or serving as a second micro-server to retrieve an event message from the message middleware, wherein,
the first micro server is used for generating event processing information according to the data updating information when data updating occurs, and obtaining data information to be sent according to the event processing information, wherein the event processing information is used for indicating other micro servers to update data in the first micro server; packaging data information to be sent and characteristic information of a receiver to obtain an event message, and issuing a local event according to the event message;
the first micro server is further used for matching the characteristic information of the receiver in the event message with the characteristic information of each micro server when the event message corresponding to the local event is obtained so as to determine the receiver of the event message; when the receiver is not the first micro server, sending the event message to the message middleware, so that the receiver can receive the event message through the message middleware;
the second micro server is used for acquiring the event message in the message middleware and matching the characteristic information of the receiver in the event message with the characteristic information of the second micro server; and when the receiver is determined to be the second micro server according to the matching result, responding to the event message, issuing a local event corresponding to the event message, and acquiring data update made in the first micro server according to event processing information encapsulated in the event message.
2. The system of claim 1, wherein the first micro-server is further configured to:
acquiring registration information of each micro server from a registration center;
and generating characteristic information corresponding to each micro server according to each registration information.
3. The system of claim 1, wherein the first micro server sending the event message to the message middleware comprises: the first micro server takes the characteristic information of the first micro server as the publishing source characteristic information in the event message; determining an available target receiver from the receivers according to the state information of each micro server, wherein the state information is acquired from a registry and is used for representing the running state of the corresponding micro server; and updating the characteristic information in the event message according to the characteristic information of the target receiver, and sending the updated event message to the message middleware.
4. The system of claim 1, wherein the event message further includes type identification information, and the second micro server is further configured to determine that the event message is of a preset type according to the type identification information of the event message before matching receiver characteristic information in the target event message with the characteristic information of the second micro server.
5. The system of claim 1, wherein the event message further comprises publishing source characteristic information, and wherein the second micro server is further configured to send a response event message to the message middleware indicating successful receipt of the target event message.
6. A communication method for a distributed system, wherein the distributed system includes a plurality of micro servers, the micro servers are communicatively connected via message middleware, and each micro server issues an event message of itself as a first micro server and/or acquires an event message from the message middleware as a second micro server, wherein the method includes:
when the first micro server updates data, event processing information is generated according to the data updating information, data information to be sent is obtained according to the event processing information, and the event processing information is used for indicating other micro servers to update the data in the first micro server;
the first micro server packages data information to be sent and characteristic information of a receiver to obtain an event message, and issues a local event according to the event message;
when the first micro server obtains an event message corresponding to a local event, matching receiver characteristic information in the event message with characteristic information of each micro server to determine a receiver of the event message;
the first micro server sends the event message to a message middleware when the receiver is not the first micro server, so that the receiver can receive the event message through the message middleware;
the second micro server acquires an event message in the message middleware and matches the characteristic information of a receiver in the event message with the characteristic information of the second micro server;
and when the second micro server determines that the receiver is the second micro server according to the matching result, responding to the event message, issuing a local event corresponding to the event message, and acquiring data update made in the first micro server according to event processing information encapsulated in the event message.
7. The method of claim 6, wherein the feature information of each of the micro-servers is obtained by the first micro-server by:
acquiring registration information of each micro server from a registration center;
and generating characteristic information corresponding to each micro server according to each registration information.
8. The method of claim 6, wherein sending the event message to a message middleware comprises:
taking the characteristic information of the first micro server as the publishing source characteristic information in the event message;
determining an available target receiver from the receivers according to the state information of each micro server, wherein the state information is acquired from a registry and is used for representing the running state of the corresponding micro server;
and updating the characteristic information in the event message according to the characteristic information of the target receiver, and sending the updated event message to a message middleware.
9. The method of claim 6, wherein the event message further comprises type identification information, and before the matching of the recipient characteristic information in the target event message with the characteristic information of the second micro server, the method further comprises:
and the second micro server determines the event message to be a preset type according to the type identification information of the event message.
10. The method of claim 6, wherein the event message further comprises publication source feature information, and wherein the method further comprises:
and the second micro server sends a response event message representing that the target event message is successfully received to the message middleware.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911312649.6A CN111131425B (en) | 2019-12-18 | 2019-12-18 | Distributed system and communication method for distributed system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911312649.6A CN111131425B (en) | 2019-12-18 | 2019-12-18 | Distributed system and communication method for distributed system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111131425A CN111131425A (en) | 2020-05-08 |
| CN111131425B true CN111131425B (en) | 2022-08-30 |
Family
ID=70498326
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911312649.6A Active CN111131425B (en) | 2019-12-18 | 2019-12-18 | Distributed system and communication method for distributed system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111131425B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106211255A (en) * | 2016-07-26 | 2016-12-07 | 北京交通大学 | A kind of Wireless ad hoc networks layer and the combined optimization method of MAC layer |
| CN106453288A (en) * | 2016-09-29 | 2017-02-22 | 上海和付信息技术有限公司 | Asynchronous mode supporting distributed micro service framework system and implementation method thereof |
| CN107657532A (en) * | 2016-07-25 | 2018-02-02 | 武汉票据交易中心有限公司 | The processing method and system of a kind of operation flow |
| CN109714358A (en) * | 2019-01-15 | 2019-05-03 | 广东工业大学 | A kind of injection molding MES cloud platform of micro services |
| CN109885334A (en) * | 2018-12-30 | 2019-06-14 | 贝壳技术有限公司 | Connection component, message sending, receiving method and edition compatibility system |
| US10484251B1 (en) * | 2015-11-24 | 2019-11-19 | SRB Technologies, Inc. | Protocol agnostic message oriented middleware for IoT, SaaS and enterprise integration |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9241044B2 (en) * | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
-
2019
- 2019-12-18 CN CN201911312649.6A patent/CN111131425B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10484251B1 (en) * | 2015-11-24 | 2019-11-19 | SRB Technologies, Inc. | Protocol agnostic message oriented middleware for IoT, SaaS and enterprise integration |
| CN107657532A (en) * | 2016-07-25 | 2018-02-02 | 武汉票据交易中心有限公司 | The processing method and system of a kind of operation flow |
| CN106211255A (en) * | 2016-07-26 | 2016-12-07 | 北京交通大学 | A kind of Wireless ad hoc networks layer and the combined optimization method of MAC layer |
| CN106453288A (en) * | 2016-09-29 | 2017-02-22 | 上海和付信息技术有限公司 | Asynchronous mode supporting distributed micro service framework system and implementation method thereof |
| CN109885334A (en) * | 2018-12-30 | 2019-06-14 | 贝壳技术有限公司 | Connection component, message sending, receiving method and edition compatibility system |
| CN109714358A (en) * | 2019-01-15 | 2019-05-03 | 广东工业大学 | A kind of injection molding MES cloud platform of micro services |
Non-Patent Citations (1)
| Title |
|---|
| 微服务体系结构实现框架综述;辛园园等;《计算机工程与应用》;20181001(第19期);第3节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111131425A (en) | 2020-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108965484B (en) | Internet of things data transmission method, system and terminal | |
| CN110311983B (en) | Service request processing method, device and system, electronic equipment and storage medium | |
| US20200382578A1 (en) | Communication Method, System and Apparatus | |
| US20040186918A1 (en) | Method and apparatus for dispatching incoming data in a multi-application terminal | |
| CN112039796B (en) | Data packet transmission method and device, storage medium and electronic equipment | |
| EP4340333A1 (en) | Communication protocol conversion method, and device, system, and gateway device | |
| CN108696601A (en) | Detect the hardware address conflict in computer network | |
| WO2021057802A1 (en) | Das system management method and device, electronic device, and storage medium | |
| CN111294235A (en) | Data processing method, device, gateway and readable storage medium | |
| CN110545230B (en) | Method and device for forwarding VXLAN message | |
| CN113254103A (en) | Application function implementation method and device and storage medium | |
| GB2580421A (en) | Electronic message translation management | |
| CN111435947A (en) | Electronic message control | |
| CN113162836B (en) | Virtual local area network communication method and device, cloud server, medium and electronic equipment | |
| CN111131425B (en) | Distributed system and communication method for distributed system | |
| CN117176633A (en) | Bus cross-device communication method, device, equipment and storage medium | |
| KR20200087673A (en) | Electronic message adaptation | |
| CN114979144B (en) | Cloud edge communication method and device and electronic equipment | |
| CN115756877A (en) | Resource synchronization method, device, equipment and storage medium | |
| CN114398035A (en) | Method, apparatus, device and computer readable medium for providing service using component | |
| CN112995095B (en) | Data processing method, device and computer readable storage medium | |
| CN114584615A (en) | Cloud service collaborative interaction method, device and equipment | |
| US20180227720A1 (en) | Method and system for providing information data | |
| CN116437377A (en) | Communication method, system, electronic device and medium for device control communication protocol | |
| CN112929453A (en) | Method and device for sharing session data |
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 |