A distributed notification method based on Netty and Nacos
By using distributed notification methods from Netty and Nacos, the network pressure and slow request issues in microservice systems of large and complex software were resolved, achieving efficient and reliable message transmission, avoiding dependence on third-party middleware, and improving system stability and efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING E-SAFENET SCI & TECH CO LTD
- Filing Date
- 2023-03-30
- Publication Date
- 2026-07-07
AI Technical Summary
In large and complex distributed software systems, existing technologies suffer from high network pressure and slow page requests, especially in message processing between microservices where the need for third-party middleware leads to network pressure and slow requests.
A distributed notification method based on Netty and Nacos is adopted. Microservices register and initialize the Netty server on the Nacos server. By leveraging Nacos' service discovery and health check, dynamic configuration management, dynamic DNS service and metadata management features, combined with Netty's high-performance asynchronous event-driven NIO framework, TCP link maintenance and message push between microservices are realized, avoiding the use of third-party middleware.
It improves the efficiency and stability of notifications between microservices, reduces network pressure and overhead, and ensures efficient and reliable message delivery.
Smart Images
Figure CN116800828B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of distributed communication system technology, specifically relating to a distributed notification method based on Netty and Nacos. Background Technology
[0002] A large, complex software system is typically composed of dozens or even hundreds of microservices. These microservices can be deployed independently and are loosely coupled. Each microservice focuses on completing a single task and performing that task well. In all cases, each task represents a small business capability. Such distributed systems involve the processing of various synchronous and asynchronous messages, requiring maintenance by third-party middleware, which can lead to high network pressure and slow network requests. Summary of the Invention
[0003] The technical problem to be solved by the present invention is to overcome the existing defects and provide a distributed notification method based on Netty and Nacos to solve the problems of high network pressure and slow page requests in the above-mentioned background technology.
[0004] To achieve the above objectives, the present invention provides the following technical solution: a distributed notification method based on Netty and Nacos, comprising the following steps:
[0005] Step 1: Define the message body to be pushed and create a notification distribution service task for the message body to be pushed.
[0006] Step 2: Start the microservice. When the microservice starts, it automatically completes the Nacos service registration and reports the port of the current microservice's Netty server and the basic information of the microservice to the Nacos server. A service instance is formed on the Nacos server. After the microservice listens for the service to start, it calls the code to initialize the Netty server service, starts the Netty server and initializes the Netty server service.
[0007] Step 3: While initializing the Netty server service, start a thread monitoring task to maintain the TCP links between microservices.
[0008] Step 4: After completing Steps 2 and 3, push the message body. When the message body is sent, if any microservice sends a message to other microservices, the server of that microservice obtains the microservice cluster, then traverses the microservice cluster to obtain the session control of each microservice's server, and sends the message to other microservices through the Netty server's write operation interface.
[0009] Step 5: When other microservice Netty servers receive the message, they enter the specified Java code for processing based on the message type in the message body, and receive the message received after processing by the specified Java code, thus realizing the push of the message body.
[0010] Preferably, the message body includes message type, message data, target server, message ID, message action, and whether it is a global push identifier.
[0011] Preferably, step two further includes:
[0012] After a microservice registers with the Nacos server, it will send a heartbeat to the Nacos server at regular intervals. The heartbeat contains the name, IP address, microservice port, cluster name, and weight information of the current service instance.
[0013] Preferably, any one of the microservices is the first microservice, and the other microservices include the second microservice, the third microservice, ... the Nth microservice, where N is a positive integer greater than 1.
[0014] Preferably, in step four, while initializing the Netty server service, a thread monitoring task is started to maintain the TCP links between microservices, and this also includes:
[0015] First, the scanning task obtains a collection of Nacos instance Maps through the Nacos server interface;
[0016] Each microservice internally retrieves a Map of previously established long-lived connections from memory to compare and determine which microservices have exited and which need to connect to the Netty server. It then establishes long-lived TCP connections with the Netty server of these microservices and removes microservices that no longer exist.
[0017] Finally, the new microservice cluster is stored in memory and associated with the session control of the corresponding server, forming a new long-connection set Map, which is convenient for comparison and judgment during the next scan task.
[0018] Preferably, after receiving the heartbeat packet, the method further includes determining whether the Nacos server exists for the current service instance based on the microservice IP and microservice port.
[0019] If it exists, record the time when the heartbeat packet was sent, set the current service instance status to 'healthy', then push the microservice status change message, and then return the heartbeat interval;
[0020] If it does not exist, the microservice will register a new Nacos service until the new service instance is stored in the Nacos instance Map collection. After that, the time when the heartbeat packet was sent is recorded, the current service instance status is set to 'healthy', the latest list of microservice instances is pushed, and then the heartbeat interval is returned.
[0021] Preferably, in step two, the automatic Nacos service registration upon microservice startup refers to the microservice registering its service with the Nacos server by sending a REST request, providing its Netty server port and basic information. After receiving the registration request, the Nacos server stores the Netty server port and basic information of the microservice provided by the microservice in a Nacos instance Map collection.
[0022] Preferably, each microservice retrieves a set of previously established long-lived connections from memory to compare and determine which microservices have exited and which need to connect to the Netty server. Long-lived TCP connections are then established with the Netty server of these microservices, and microservices that no longer exist are removed. This process includes the following steps:
[0023] First, it traverses the long-connection set Map and the Nacos instance Map set of the microservices. By IP and port, it determines whether there are microservices in the long-connection set Map and the Nacos instance Map set that no longer exist, and finds the new microservices that need to establish TCP long connections.
[0024] If a microservice exists in the long-lived connection set Map of microservices, but the corresponding Netty server port of the microservice does not exist in the Nacos instance Map set, then the microservice is determined to be a non-existent microservice and is removed from the long-lived connection set Map of microservices.
[0025] If a microservice exists in the long-connection set Map of microservices, and the corresponding microservice Netty server port exists in the Nacos instance Map set, then it is determined that the microservice has already established a TCP long connection with the Netty server of the microservice in the Nacos instance Map set. In this case, the judgment is skipped, and the connection remains unchanged without any processing.
[0026] If the microservice's Netty server port exists in the Nacos instance Map collection, but the corresponding microservice does not exist in the microservice's long-connection collection Map, then it is determined that the microservice needs to be connected to the Netty server. A new microservice is then created, and this new microservice is automatically added to the microservice's long-connection collection Map, and a long-connection is established with the Netty server of the microservice in the Nacos instance Map collection.
[0027] Preferably, the time interval between the specified intervals is 1 to 3 seconds.
[0028] Preferably, in step one, after creating a notification distribution service task for the message body to be pushed, the distribution service task is received, and preparatory work is performed before the message body is sent. The preparatory work before the message body is sent includes steps two and three. When sending the message body between any microservices later, it is not necessary to repeat steps two and three.
[0029] Compared with existing technologies, this invention provides a distributed notification method based on Netty and Nacos, which has the following advantages:
[0030] This invention fully utilizes four features of Nacos: service discovery and service health checks, dynamic configuration management, dynamic DNS service, and service and metadata management. It also provides support for TCP transmission with Netty's high-performance, asynchronous event-driven NIO framework, enabling efficient and reliable communication between microservices. Through Netty + Nacos, this invention ensures more efficient and stable communication between microservices.
[0031] All parts not covered in this method are the same as or can be implemented using existing technologies. This invention has a scientific and reasonable structure, is safe and convenient to use, and provides great help to people. Attached Figure Description
[0032] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention, but do not constitute a limitation thereof. In the drawings:
[0033] Figure 1 This is a flowchart illustrating the uploading of Netty information and microservice information in a distributed notification method based on Netty and Nacos proposed in this invention.
[0034] Figure 2 This is a flowchart illustrating the processing of a heartbeat packet received in a distributed notification method based on Netty and Nacos proposed in this invention.
[0035] Figure 3 This is a flowchart illustrating the process of obtaining the registered Netty and microservice information in a distributed notification method based on Netty and Nacos proposed in this invention. Detailed Implementation
[0036] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0037] Please see Figure 1-3 This invention provides a technical solution: a distributed notification method based on Netty and Nacos, comprising:
[0038] Step one requires defining the message body to be pushed and creating a notification distribution service task for the message body to be pushed; the message body includes message type, message data, target server, message ID, message action, and whether it is a global push identifier.
[0039] Step 2: Start the microservice. When the microservice starts, it automatically completes the Nacos service registration and reports the port of the current microservice's Netty server and the basic information of the microservice to the Nacos server. A service instance is formed on the Nacos server. After the microservice listens for the service to start, it calls the code to initialize the Netty server service, starts the Netty server and initializes the Netty server service.
[0040] Step 3: While initializing the Netty server service, start a thread monitoring task to maintain the TCP links between microservices.
[0041] Step 4: After completing Step 2 and Step 3, push the message body. When the message body is sent, when any microservice sends a message to other microservices, the server of that microservice obtains the microservice cluster, then traverses the microservice cluster to obtain the session control of each microservice's server, and sends the message to other microservices through the Netty server's write operation interface.
[0042] Step five: When other microservice Netty servers receive the message, they enter the designated Java code for processing based on the message type in the message body, and receive the message received after processing by the designated Java code, thus realizing message body push. When the server receives the message sent by the microservice, it then enters the designated Java code for processing. In this way, we can complete message notification with very few messages, reduce network overhead, and achieve the final notification of this invention.
[0043] The technical solution of this invention eliminates the need for third-party middleware for information storage and transmission during message notification, thus improving notification efficiency and reducing network pressure. If we use third-party middleware, we first need to maintain its operational status, and then send the entire message in the notification process. When retrieving messages using network addresses, there is a problem of delayed information delivery. Furthermore, actively calling all microservice interfaces is time-consuming and increases the request pressure on microservices.
[0044] In step four, a microservice cluster refers to a collection of all microservices contained in a specific large and complex software. Each microservice corresponds to a specific function. The microservice cluster of this invention is a collection obtained through the Nacos server interface.
[0045] In step four, session control is generally referred to as a session. A session object stores the attributes and configuration information required for a specific user session. This ensures that variables stored in the session object are not lost when a user navigates between web pages within the application, but persist throughout the entire user session. When a user requests a web page from the application, if the user does not already have a session, the web server will automatically create one. The server will terminate the session when it expires or is abandoned.
[0046] In step four, it can be understood that any one microservice is the first microservice, or microservice A, and the other microservices include the second microservice (or microservice B), the third microservice (or microservice C)...the Nth microservice (or microservice N), where N is a positive integer greater than 1. For example, see the appendix. Figure 3 When microservice A sends a message to microservice BCD, the server of microservice A obtains the microservice cluster, then traverses the microservice cluster to obtain the session control of each microservice's server, and sends the message to microservice BCD through the Netty server's write operation interface.
[0047] In step one, after creating a notification distribution service task for the message body to be pushed, and receiving the distribution service task, preparatory work is performed before sending the message body. This preparatory work includes steps two and three. When any microservices subsequently send message bodies to each other, steps two and three do not need to be repeated. Essentially, during the information transmission process between microservices, the microservice startup process and the startup thread monitoring task are continuously maintained, eliminating the need to restart before each message body sending. The monitoring task also exists in real-time, providing a secure information transmission environment. Under this condition, the message body can be sent and transmitted freely between microservices, requiring only steps four and five. This scheme also improves message transmission efficiency and security, and reduces network pressure.
[0048] Step two further includes: After the microservice registers with the Nacos server, it sends a heartbeat packet to the Nacos server at regular intervals. The heartbeat packet is a user-defined command that periodically notifies the microservice and server of its status. It is sent at specific time intervals and includes information such as the current service instance name, IP address, microservice port, cluster name, and weight. The interval is 1-3 seconds. Sending heartbeat packets within this timeframe ensures overall control, real-time updates, and timely feedback, while preventing excessively frequent sending that could strain the network.
[0049] In step two, the automatic Nacos service registration upon microservice startup refers to the microservice registering itself with the Nacos server by sending a REST request, providing its Netty server port and basic information, such as IP address and microservice port. In this invention, this is achieved by sending heartbeat packets to provide this data. Generally, after receiving the registration request, the Nacos server stores the Netty server port and basic microservice information provided by the microservice in a Nacos instance Map collection.
[0050] When a microservice starts, it encapsulates its IP address, port, and other information into an instance object, preparing to register with the Nacos server. Before registration, the microservice encapsulates this instance object (containing IP address, port, and other information) into a BeanInfo object and creates a timed heartbeat connection mechanism. Every so often, it sends a PUT request to the Nacos server. Upon receiving the heartbeat request, the Nacos server checks if the service instance exists in its service list. If it does, it refreshes the heartbeat interval for that service instance. If not, the microservice registers a new Nacos service.
[0051] See Figure 2 After receiving the heartbeat packet, the process also includes determining whether the Nacos server instance exists based on the IP address and microservice port.
[0052] If it exists, record the time when the heartbeat packet was sent, set the current service instance status to 'healthy', then push the latest list of microservice instances, and then return the heartbeat interval;
[0053] If the service instance does not exist, a new service instance is registered through the Nacos server until it is stored in the Nacos instance Map collection. Afterward, the sending time of this heartbeat packet is recorded, the current service instance status is set to 'healthy', and the latest list of microservice instances is pushed to the system. Finally, the heartbeat interval is returned. Here, the Nacos instance Map collection refers to a collection of existing service instances stored within the program.
[0054] A service instance is a unit in a web service that handles specific service requests. Generally, a web service will have multiple service instances participating in different workflows simultaneously. At the same time, a workflow contains service instances of many different web services. Therefore, service instances correspond to specific functions and performance, as well as specific tasks.
[0055] In step four, a thread monitoring task is started simultaneously with the initialization of the Netty server service to maintain the TCP links between microservices. Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol defined by IETF RFC 793. TCP is designed to adapt to layered protocol hierarchies that support multiple network applications. Pairs of processes in host computers connected to different but interconnected computer communication networks rely on TCP for reliable communication services.
[0056] The above thread monitoring tasks also include:
[0057] First, the scanning task obtains a collection of Nacos instance Maps through the Nacos server interface;
[0058] Each microservice internally retrieves a Map of previously established long-lived connections from memory to compare and determine which microservices have exited and which Netty servers need to connect to the microservices. It then establishes long-lived TCP connections with the Netty servers of these microservices and removes microservices that no longer exist.
[0059] Finally, the new microservice cluster is stored in memory and associated with the session control of the corresponding server, forming a new long-connection set Map. This facilitates comparison and judgment during the next scan task. The comparison and judgment during the next scan task refers to re-running the thread monitoring task to determine whether any microservices have exited or whether it is necessary to connect to the Netty server of the microservices.
[0060] Each microservice internally retrieves a Map of previously established long-lived connections from memory to compare and determine which microservices have exited and which need to connect to the Netty server. It then establishes long-lived TCP connections with the Netty server for these microservices, removing those that no longer exist. The specific steps include:
[0061] First, it traverses the long-connection set Map and the Nacos instance Map set of the microservices. By using the IP and Netty port, it determines whether there are any microservices in the long-connection set Map and the Nacos instance Map set that no longer exist, and finds the new microservices that need to establish TCP long connections.
[0062] If a microservice A exists in the long-lived connection collection Map of microservices... i The value of i can be 1, 2, 3..., for example, A3, but the corresponding microservice Netty server B does not exist in the Nacos instance Map collection. i The port number is specified, and the value of i can be 1, 2, 3, ..., for example, B3. Then, the determination is made based on the port number of microservice A. i For microservices that do not exist, remove the microservice Ai from the long-link collection Map of microservices.
[0063] If a microservice Ai exists in the long-lived connection collection Map of microservices, where i can be 1, 2, 3, ..., for example, A3, and the corresponding microservice B (Netty server) exists in the Nacos instance Map collection... i The port number is specified, and the value of i can be 1, 2, 3.... For example, if B3 is specified, then the microservice has already established a long TCP connection with the Netty server of the microservice in the Nacos instance Map collection. At this time, the judgment is skipped, the connection remains unchanged, and no processing is performed.
[0064] If the Nacos instance Map collection contains port B of the microservice Netty server... i The value of i can be 1, 2, 3, ..., for example, B3, but the microservice A does not exist in the long-lived connection collection Map. iThe value of i can be 1, 2, 3.... For example, A3 requires access to the Netty server of the microservice, the creation of a new microservice, and the automatic addition of the new microservice to the long-connection collection Map of the microservice, and the establishment of a long connection with the Netty server of the microservice in the Nacos instance Map collection.
[0065] The above judgment method uses IP and Netty port for determination. First, it is based on the fact that the microservice's long-connection collection Map and the Nacos instance Map collection use the same IP address. Second, since the microservice automatically completes Nacos service registration when it starts up, it reports the port of the current microservice's Netty server to the Nacos server's metadata information. This allows the Nacos instance Map collection to obtain the registered microservice Netty and microservice information, which includes the port information of the microservice's Netty server. Therefore, when traversing the microservice's long-connection collection Map, the above judgment process can be performed.
[0066] In this invention, the Nacos instance Map collection is equivalent to a data storage center on the Nacos server, capable of storing data.
[0067] By using the thread monitoring tasks described above, non-existent microservices can be removed at any time, saving storage space. Microservices can also be updated by connecting to the Netty server of new microservices, ensuring that the microservice cluster is always in a healthy state, thereby improving work efficiency.
[0068] This invention fully utilizes four features of Nacos: service discovery and service health checks, dynamic configuration management, dynamic DNS service, and service and metadata management. It also provides support for TCP transmission with Netty's high-performance, asynchronous event-driven NIO framework, enabling efficient and reliable communication between microservices. Furthermore, it eliminates the need to rely on third-party middleware for message transmission, effectively reducing network pressure and improving the efficiency of network message transmission.
[0069] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A distributed notification method based on Netty and Nacos, comprising the following steps: Step 1: Define the message body to be pushed and create a notification distribution service task for the message body to be pushed. Step 2: Start the microservice. When the microservice starts, it automatically completes the Nacos service registration and reports the current microservice Netty server port to the Nacos server's metadata information. After the microservice listens for the service startup completion, it calls the Netty server initialization code to start the Netty server and initialize the Netty server service. Step 3: While initializing the Netty server service, start a thread monitoring task to maintain the TCP links between microservices. Step 4: When sending a message, if any microservice sends a message to another microservice, the server of that microservice obtains the microservice cluster, then traverses the microservice cluster to obtain the session control of each server, and sends the message to the other microservice through the Netty server's write operation interface. Step 5: When other microservice Netty servers receive the message, they enter the specified Java code for processing according to the message type in the message body, and receive the message received after the specified Java code has processed it, thus realizing the push of the message body; In step three, the thread monitoring task, which is started simultaneously with the initialization of the Netty server service to maintain the TCP links between services, also includes: First, the scanning task obtains a healthy microservice cluster through the Nacos server interface; Each microservice retrieves a set of previously established long connections from memory to compare and determine which microservices have exited and which need to connect to the Netty server. It then establishes long TCP connections with the Netty server of these microservices and removes microservices that no longer exist. Finally, the new microservice cluster is stored in memory and associated with the session control of the corresponding server, making it convenient for comparison and judgment in the next scan task.
2. The distributed notification method based on Netty and Nacos according to claim 1, characterized in that: The message body includes message type, message data, target server, message ID, message action, and whether it is a global push identifier.
3. The distributed notification method based on Netty and Nacos according to claim 1, characterized in that: Step two also includes: After a microservice registers with the Nacos server, it will send a heartbeat to the Nacos server at regular intervals. The heartbeat contains the name, IP address, microservice port, cluster name, and weight information of the current service instance.
4. The distributed notification method based on Netty and Nacos according to claim 1, characterized in that: The microservice is the first microservice, and the other microservices include the second microservice, the third microservice, ... the Nth microservice, where N is a positive integer greater than 1.
5. A distributed notification method based on Netty and Nacos according to claim 3, characterized in that: After receiving the heartbeat packet, the Nacos server also checks whether the current service instance exists on the Nacos server based on the microservice's IP address and port. If it exists, record the time when the heartbeat packet was sent, set the current service instance status to healthy, push the microservice status change message, and then return the heartbeat interval. If the service instance does not exist, a new service instance is registered through the Nacos server until the new service instance is stored in the instance Map collection. After that, the sending time of this heartbeat packet is recorded, the current service instance status is set to 'healthy', the latest microservice instance list is pushed, and then the heartbeat interval is returned.
6. A distributed notification method based on Netty and Nacos according to claim 1, characterized in that: In step two, the automatic Nacos service registration upon microservice startup refers to the microservice registering its service with the Nacos server by sending a REST request, providing its Netty server port and basic information. After receiving the registration request, the Nacos server stores the Netty server port and basic information of the microservice in a Nacos instance Map collection.
7. A distributed notification method based on Netty and Nacos according to claim 1, characterized in that: Each microservice internally retrieves a set of previously established long-lived connections from memory to compare and determine which microservices have exited and which need to connect to the Netty server. It then establishes long-lived TCP connections with the Netty server of these microservices, removing those that no longer exist. The specific steps include: First, it traverses the long-connection set Map and the Nacos instance Map set of the microservices. By using the IP and Netty port, it determines whether there are any microservices in the long-connection set Map and the Nacos instance Map set that no longer exist, and finds the new microservices that need to establish TCP long connections. If a microservice exists in the long-lived connection set Map of microservices, but the corresponding Netty server port of the microservice does not exist in the Nacos instance Map set, then the microservice is determined to be a non-existent microservice and is removed from the long-lived connection set Map of microservices. If a microservice exists in the long-connection set Map of microservices, and the corresponding microservice Netty server port exists in the Nacos instance Map set, then it is determined that the microservice has already established a TCP long connection with the Netty server of the microservice in the Nacos instance Map set. In this case, the judgment is skipped, and the connection remains unchanged without any processing. If the microservice's Netty server port exists in the Nacos instance Map collection, but the corresponding microservice does not exist in the microservice's long-connection collection Map, then it is determined that the microservice needs to be connected to the Netty server. A new microservice is then created, and this new microservice is automatically added to the microservice's long-connection collection Map, and a long-connection is established with the Netty server of the microservice in the Nacos instance Map collection.
8. A distributed notification method based on Netty and Nacos according to claim 3, characterized in that: The time interval mentioned above is 1 to 3 seconds.
9. A distributed notification method based on Netty and Nacos according to claim 1, characterized in that: In step one, after creating a notification distribution service task for the message body to be pushed, the distribution service task is received, and preparatory work is performed before the message body is sent. The preparatory work before the message body is sent includes steps two and three. When sending the message body between any microservices later, it is not necessary to repeat steps two and three.