A lightweight service management system based on embedded micro-service architecture

Abstract

The application belongs to the technical field of computer software professional microservice, and specifically designs a lightweight service management system based on embedded microservice architecture, which comprises a service registration center and a client agent; the lightweight and easy-to-deploy service management technology maintains the state information of distributed services, realizes an efficient and reliable data transmission mechanism based on the connectionless mode of the UDP protocol, provides the functions of service registration center state awareness, service registration, service subscription and discovery for distributed services, realizes the high availability and data consistency of the service registration center based on the distributed database of the raft protocol, provides a Web UI interface, and facilitates real-time monitoring of the service state by microservice developers.

Description

Technical Field

[0001] The present invention belongs to the field of computer software professional microservice technology, and specifically designs a lightweight service management system based on embedded microservice architecture. Background Art

[0002] With the continuous growth of application scale in embedded environments and the widespread use of intelligent applications, in order to better manage and maintain software development and upgrades, embedded platforms introduce microservices architecture, splitting applications into independently deployed services. Each service implements specific business functions, and uses service governance components to manage services and realize business data communication between services. Among them, the service registration center is a key component in the microservices architecture.

[0003] Service registries primarily address the challenges of managing software in distributed platforms due to the large number of service instances, service state changes, and dynamic service migration. They monitor and manage service status, providing two primary functions: service registration and service discovery. Mainstream service registry implementation tools in the industry include Eureka, Consul, Zookeeper, and Etcd. Eureka components have been integrated into the microservices architecture Spring Cloud, and Zookeeper components have been integrated into Alibaba's Dubbo architecture. Etcd is widely used in Kubernetes cloud-native technology. These registry tools utilize persistent communication mechanisms, resulting in relatively complex environment dependencies, configuration, and deployment. These tools are unsuitable for microservices architectures with limited embedded platform resources and high real-time requirements. Therefore, a lightweight service management system is needed to maintain service status information in real time, support service subscription and discovery, provide instance selection strategies for services with the same name, and ensure the consistency of service data requests. Summary of the Invention

[0004] In view of this, the present invention provides a lightweight service management system based on an embedded microservice architecture, which is a lightweight and easy-to-deploy service management technology that maintains the status information of distributed services. Based on the connectionless method of the UDP protocol, it realizes an efficient and reliable data transmission mechanism, provides distributed services with service registration center status perception, service registration, service subscription and discovery functions, and a distributed database based on the Raft protocol to achieve high availability and data consistency of the service registration center. It provides a Web UI interface to facilitate microservice developers to monitor the service status in real time.

[0005] The technical solution of the present invention is:

[0006] A lightweight service management system based on embedded microservice architecture, including a service registration center and client agent;

[0007] The service registry is a distributed database based on the Raft protocol, using a master-slave collaboration approach to store service subscriptions and registration messages. The master node of the service registry component is responsible for data communication with client agents and broadcasting heartbeat messages, which are used to respond to client agent service list requests and update data.

[0008] The client proxy acts as a client exposed by the service registration center to distributed services, providing registration, subscription, and service discovery functions for service subscribers and consumers, and providing the ability to perceive and update the dynamic changes of the service address.

[0009] Furthermore, the communication mechanism between the service registry and the client agent is:

[0010] Based on the connectionless mode of UDP protocol, the lightweight service management operation mechanism is designed.

[0011] The communication mechanism can be set up in the following ways:

[0012] Establish a heartbeat awareness mechanism for the client agent and the registration center: The client agent and the registration center agree on a multicast address and port number, create a registration center heartbeat receiving task to receive the registration center's multicast messages, and the client agent uses a timer to detect the validity of the registration center.

[0013] Establish a heartbeat awareness mechanism for the registration center and client agents: When the client detects the online status of the registration center, it creates an agent heartbeat sending task and periodically sends client agent heartbeat messages to the registration center. The registration center uses a timer to detect the validity of the client agent and maintain the status information of the service subscribers and service registrants on the proxy node.

[0014] Establish a reliable transmission mechanism for service request and response messages: Service request messages include service registration messages, service subscription messages, and service attribute setting messages. Service response messages are service discovery messages sent from the registration center to the client agent. The lightweight service management system uses a method of caching historical messages and replying to confirmation messages to ensure reliable message transmission.

[0015] Establish an application-insensitive service automatic registration and subscription mechanism in the lightweight service management system.

[0016] Furthermore, the lightweight service management system has two service discovery modes: callback notification based on the service monitoring mechanism and active inquiry function.

[0017] Furthermore, for the case of multiple instances of a service with the same name, the client agent provides a first-register-first-served and first-served strategy for selecting service instances with the same name for service discovery.

[0018] Furthermore, a method for establishing a reliable transmission mechanism for service request and response messages specifically includes the following steps:

[0019] S101: The client agent increases the index number count of the service request message, puts it into the historical message queue in the order of the index number, creates a reliability sending task to send the message data, and creates a reliability receiving task to receive the confirmation message and service response message replied by the registration center;

[0020] S102: The service registration center uses a message processing task pool to process service request messages in parallel, uses the same strategy as the client proxy to cache historical messages and create a reliability message sending task to reply to the client proxy request;

[0021] S103: Every 8-12 seconds, the reliability sending task periodically traverses the historical messages cached in the message queue and sends data to the peer end until the message receiving task receives a confirmation message from the peer end. After receiving the message, the message data that was successfully sent is deleted from the historical cache using the index number in the confirmation message.

[0022] Among them: In S101-S103, all sent messages will judge the validity of the status of the other end based on the heartbeat detection mechanism. If it is in an invalid state, the reliability sending task will not send messages within this period.

[0023] Furthermore, if an exception occurs in the Dangdang registration center cluster, resulting in the loss of managed service information, the execution steps of the application-insensitive service automatic registration and subscription mechanism are as follows:

[0024] S201: The client agent detects that the center multicast heartbeat has timed out and sets the registration center to an invalid state;

[0025] S202: After the client agent senses that the registration center node is back online, the client agent re-initiates service registration and subscription requests to the center through the local cache;

[0026] Among them, if the request message sent by the agent is lost due to network instability, the service registration center queries whether the service information is stored in the database based on the service instance name list in the agent heartbeat message. Otherwise, it initiates a service request to the client agent.

[0027] Beneficial effects of the present invention:

[0028] (1) Using a connectionless communication method, a heartbeat perception mechanism is designed based on broadcast function perception. For service request and response messages, a simple and efficient reliability transmission mechanism is designed to tolerate message packet loss caused by network instability and improve the accuracy of data transmission.

[0029] (2) For service subscribers, it provides active query and callback notification capabilities for services, supports setting the same-name service instance selection strategy in the client agent, and provides two strategies: first-come-first-served and high-priority-served. For high-determinism services on embedded platforms, it ensures the consistency of service requests.

[0030] (3) For service providers, the registration center designs a heartbeat perception mechanism to monitor the status of distributed services in real time and provides web servers to support visual monitoring of services, which facilitates the early service joint testing of microservice developers.

[0031] (4) The service registration center is a distributed database based on the Raft protocol. It adopts a master-slave coordination method to provide the registration center with the ability to run multiple nodes and synchronize data, ensuring the high availability and data consistency of the registration center.

[0032] (5) Provides application-insensitive service automatic registration and subscription capabilities. In the extreme case where all nodes of the service registration center are down and service data is lost, the agent can actively initiate service registration and subscription requests based on historical cache after sensing that the center is back online, ensuring that the service is online again in an orderly manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0034] Figure 1 This is the overall software architecture diagram of the present invention;

[0035] Figure 2 This is a schematic diagram of the software operation flow based on the UDP protocol connectionless mode;

[0036] Figure 3 Schematic diagram of the reliable transmission process of service request and response messages;

[0037] Figure 4 This is a diagram of the automated registration and subscription process for services. DETAILED DESCRIPTION

[0038] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0039] The following describes the embodiments of the present disclosure through specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.

[0040] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement an apparatus and / or practice a method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this apparatus and / or practice this method.

[0041] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The illustrations only show components related to the present disclosure and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0042] Additionally, in the following description, specific details are provided to provide a thorough understanding of the examples. However, one skilled in the art will appreciate that the aspects described can be practiced without these specific details.

[0043] In one embodiment of the present invention, a lightweight service management system based on an embedded microservice architecture is proposed, comprising a service registration center and a client agent;

[0044] The service registry is a distributed database based on the Raft protocol, using a master-slave collaboration approach to store service subscriptions and registration messages. The master node of the service registry component is responsible for data communication with client agents and broadcasting heartbeat messages, which are used to respond to client agent service list requests and update data.

[0045] The client proxy acts as a client exposed by the service registration center to distributed services, providing registration, subscription, and service discovery functions for service subscribers and consumers, and providing the ability to perceive and update the dynamic changes of the service address.

[0046] In this embodiment, the communication mechanism between the service registration center and the client agent is:

[0047] Based on the connectionless mode of UDP protocol, the lightweight service management operation mechanism is designed.

[0048] The communication mechanism can be set up in the following ways:

[0049] Establish a heartbeat awareness mechanism for the client agent and the registration center: The client agent and the registration center agree on a multicast address and port number, create a registration center heartbeat receiving task to receive the registration center's multicast messages, and the client agent uses a timer to detect the validity of the registration center.

[0050] Establish a heartbeat awareness mechanism for the registration center and client agents: When the client detects the online status of the registration center, it creates an agent heartbeat sending task and periodically sends client agent heartbeat messages to the registration center. The registration center uses a timer to detect the validity of the client agent and maintain the status information of the service subscribers and service registrants on the proxy node.

[0051] Establish a reliable transmission mechanism for service request and response messages: Service request messages include service registration messages, service subscription messages, and service attribute setting messages. Service response messages are service discovery messages sent from the registration center to the client agent. The lightweight service management system uses a method of caching historical messages and replying to confirmation messages to ensure reliable message transmission.

[0052] Establish an application-insensitive service automatic registration and subscription mechanism in the lightweight service management system.

[0053] In this embodiment, the lightweight service management system has two service discovery modes: callback notification based on the service monitoring mechanism and active inquiry function.

[0054] In this embodiment, for the case of multiple instances of a service with the same name, the client agent provides a first-register-first-served and high-priority-first-served service instance selection strategy for service discovery.

[0055] In this embodiment, the method for establishing a reliable transmission mechanism for service request and response messages specifically includes the following steps:

[0056] S101: The client agent increases the index number count of the service request message, puts it into the historical message queue in the order of the index number, creates a reliability sending task to send the message data, and creates a reliability receiving task to receive the confirmation message and service response message replied by the registration center;

[0057] S102: The service registration center uses a message processing task pool to process service request messages in parallel, uses the same strategy as the client proxy to cache historical messages and create a reliability message sending task to reply to the client proxy request;

[0058] S103: Every 8-12 seconds, the reliability sending task periodically traverses the historical messages cached in the message queue and sends data to the peer end until the message receiving task receives a confirmation message from the peer end. After receiving the message, the message data that was successfully sent is deleted from the historical cache using the index number in the confirmation message.

[0059] Among them: In S101-S103, all sent messages will judge the validity of the status of the other end based on the heartbeat detection mechanism. If it is in an invalid state, the reliability sending task will not send messages within this period.

[0060] In this embodiment, an abnormality in the Dangdang registration center cluster causes the loss of managed service information. The execution steps of the application-insensitive service automatic registration and subscription mechanism are as follows:

[0061] S201: The client agent detects that the center multicast heartbeat has timed out and sets the registration center to an invalid state;

[0062] S202: After the client agent senses that the registration center node is back online, the client agent re-initiates service registration and subscription requests to the center through the local cache;

[0063] Among them, if the request message sent by the agent is lost due to network instability, the service registration center queries whether the service information is stored in the database based on the service instance name list in the agent heartbeat message. Otherwise, it initiates a service request to the client agent.

[0064] The overall architecture of this embodiment mainly includes two software components: the registration center and the client agent. The software functions are as follows:

[0065] Registration Center: It runs as an independent process in a cluster on multiple nodes. While maintaining the service status, it responds to the service requests of the client agent and updates the data. It provides a web server and supports users to monitor the service operation status through the UI interface.

[0066] Client agent: As the client of the registration center, it is linked to the server in the form of a static library, providing service subscription and discovery functions for service subscribers. In response to the increase of service instances and dynamic changes in service addresses, it provides cache updates, callback notifications, and active query functions for service addresses; it provides registration services and setting service survival cycles for service providers.

[0067] In the environment of limited network resources on embedded platforms, a lightweight service management and operation mechanism based on the UDP protocol connectionless mode is designed for message transmission between the client agent and the registration center. The main steps include:

[0068] (1) Establish a heartbeat perception mechanism for the client agent to the registration center: the client agent and the registration center negotiate a unified multicast address and multicast port number in the configuration file, and periodically broadcast its own node address information in the distributed system. The client agent initializes the creation of multicast messages to receive multicast messages from the task processing center, and uses a timer to determine whether the center's multicast message has timed out, thereby determining the center's survival status.

[0069] (2) Establish a heartbeat perception mechanism for the registration center to the client agent: After the client agent perceives the central node, it creates an agent heartbeat message sending task and periodically sends the client agent heartbeat information to the registration center. The registration center uses a timer to maintain the client agent status information, and then maintains the status information of the service subscribers and service registrants on the proxy node based on the heartbeat message.

[0070] The client agent heartbeat information mainly includes the service instance information and service life cycle information registered through the agent node. The service instance information mainly refers to the service instance name registered by the agent node. The service life cycle is used to set the service heartbeat timeout for the registration center.

[0071] The service registration center maintains the service status based on the proxy heartbeat. If the proxy heartbeat times out, all service instances of the node will be taken offline, and the service subscribers of the node will no longer be notified of the service discovery messages they have subscribed to until the proxy heartbeat returns to normal.

[0072] (3) Establish a reliable transmission mechanism for service request and response messages: Service request messages mainly include service registration messages, service subscription messages, and service attribute setting messages. Service response messages mainly refer to service discovery messages that the center replies to the client agent. The service management component uses the method of caching historical messages and replying confirmation messages to ensure reliable message transmission.

[0073] (4) Establish an automatic registration and subscription mechanism for services: To avoid extreme situations that may cause all central nodes to crash and thus result in the loss of all service information managed by the center, the client agent locally caches the registered service instance information, perceives the online status of the service registration center, and accepts the query request from the registration center, and then sends the service registration and subscription related information to the registration center again through the local cache.

[0074] (5) In response to the increase in service instances and the dynamic changes in service addresses, two ways of discovering services are provided to service subscribers: callback notification based on the service monitoring mechanism and active inquiry function.

[0075] (6) For the case of multiple instances of a service with the same name, the client agent provides a policy setting for selecting service instances with the same name for service discovery. The service registration center pushes a list of valid service instances with the same name that the service subscriber is concerned about to the client agent. The client agent can provide the best service to the subscriber based on the service online timing or service priority.

[0076] See Figure 1-Figure 4 This embodiment provides a lightweight, efficient and reliable service management technology. The software architecture mainly includes two software components: client agent and service registration center. The overall architecture is as follows: Figure 1 As shown in the figure, the service registration center component is a distributed database based on the Raft protocol, which adopts a master-slave coordination method to store service subscription and registration messages. The master node is responsible for data communication with the client agent, broadcasting heartbeat messages, responding to the client agent's service list requests and updating data; the client agent component serves as the client exposed by the service registration center to distributed services, providing registration service, subscription service, and discovery service functions for service subscribers and consumers, and providing the ability to perceive and update the service address for dynamic changes.

[0077] like Figure 2 The following is a flowchart of the software operation based on the UDP protocol connectionless mode, which is mainly divided into the following six steps:

[0078] Step 1: Establish a heartbeat perception mechanism for the client agent to the registration center. The client agent and the registration center node negotiate a consistent multicast address and port number, create a registration center heartbeat receiving task to receive the registration center's multicast messages, and use a timer to detect the validity of the registration center.

[0079] Step 2: Establish a heartbeat perception mechanism for the registration center to the client agent. After the client perceives the online status of the registration center, it creates an agent heartbeat sending task and periodically sends client agent heartbeat messages to the registration center. The registration center uses a timer to detect the validity of the client agent, and then maintains the status information of the service subscribers and service registrants on the proxy node.

[0080] Step 3: Establish a reliable transmission mechanism for service request and response messages. Service request messages mainly include service registration messages, service subscription messages, and service attribute setting messages. Service response messages mainly refer to service discovery messages that the center replies to the client agent. This system software uses the method of caching historical messages and replying confirmation messages to ensure reliable message transmission.

[0081] Step 4: To address the situation where service data is lost due to registration center node failure, establish an application-insensitive service automatic registration and subscription mechanism.

[0082] Step 5: In order to enable service subscribers to obtain the latest service instance information more efficiently, two ways for service subscribers to discover services are provided: callback notification based on the service monitoring mechanism and active inquiry function.

[0083] Step 6: For the case of multiple instances of the same-name service, the client agent provides a selection strategy for the service instance with the same name for service discovery, and provides the optimal service instance for the service subscriber.

[0084] In this embodiment, the reliable transmission process of the service request and response messages mentioned in step 3 mainly includes:

[0085] In step 3.1, when the service calls the service request interface of the client agent, the client agent counts the index number of the service request message, puts it into the historical message queue in the order of the index number, creates a reliability sending task to be responsible for sending the message data, and creates a reliability receiving task to be responsible for receiving the confirmation message and service response message replied by the registration center.

[0086] In step 3.2, the service registration center uses a message processing task pool to process service request messages in parallel, uses the same strategy to cache historical messages and creates a reliability message sending task, which is responsible for replying to service discovery messages from service subscribers.

[0087] In step 3.3, the reliability sending task periodically traverses the historical messages cached in the message queue every 10 seconds and sends data to the peer end until the message receiving task receives the confirmation message from the peer end. The successfully sent message data is deleted from the historical cache using the index number in the confirmation message.

[0088] In step 3.4, all sent messages will use the heartbeat detection mechanism to determine the validity of the peer status. If the peer status is invalid, the reliability sending task will not send messages during this period to avoid occupying network bandwidth.

[0089] In this embodiment, the automated registration and subscription process triggered by the restart of the center after the abnormality mentioned in step 4 mainly includes:

[0090] In step 4.1, the registration center cluster fails, causing the loss of managed service information. The client agent detects that the center's multicast heartbeat has timed out and sets the registration center to an invalid state.

[0091] In step 4.2, after the client agent senses that the registration center node is back online, the client agent re-initiates service registration and subscription requests to the center through the local cache;

[0092] In step 4.3, if the request message sent by the proxy is lost due to network instability, the service registration center queries whether the service information is stored in the database based on the service instance name list in the proxy heartbeat message. Otherwise, it asks the client proxy whether it needs to initiate a registration request to ensure reliable transmission of service messages.

[0093] In this embodiment, the two service discovery functions mentioned in step 5 are specifically implemented as follows:

[0094] (1) The callback notification function based on the service monitoring mechanism means that the registration center updates the service instance information by processing the service registration request, monitors the service status changes through the heartbeat detection mechanism, and pushes the updated valid service instance information to the service subscriber. The service subscriber perceives the service online through the registration service discovery callback function;

[0095] (2) The active query function based on the service monitoring mechanism means that the service subscriber calls the query interface to block and wait for the service discovery response from the registration center, and supports setting the blocking waiting timeout.

[0096] In this embodiment, the same-name service instance selection strategy mentioned in step 6 mainly includes two strategies: first-registered first-served and high-priority first-served. The strategy descriptions are as follows:

[0097] (1) First-come, first-served: When service instances with the same name have the same service priority, the service instance that comes online first is the best service.

[0098] (2) High priority service first: If a service with the same name has high and low priority, the service instance with the higher priority will be the primary service.

[0099] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A lightweight service management system based on embedded microservice architecture, characterized in that: Includes service registry and client proxy; The service registration center is a distributed database based on the Raft protocol, which uses a master-slave collaboration to store service subscriptions and registration messages. The master node of the service registration center component is responsible for data communication with the client agent and broadcasting heartbeat messages, which is used to respond to the client agent's service list request and update data. The client agent, as the client exposed by the service registration center to distributed services, provides service subscribers and consumers with registration, subscription and service discovery functions, and provides the ability to perceive and update the service address for dynamic changes in the service address. The communication mechanism between the service registration center and the client agent is a connectionless method based on the UDP protocol. The lightweight service management operation mechanism is designed. The setting method of the communication mechanism includes: establishing a heartbeat perception mechanism of the client agent to the registration center: the client agent and the registration center agree on the multicast address and port number, create a registration center heartbeat receiving task to receive the multicast message of the registration center, and the client agent uses a timer to detect the validity of the registration center; establishing a heartbeat perception mechanism of the registration center to the client agent: when the client perceives the online status of the registration center, it creates an agent heartbeat sending task and periodically sends the client agent heartbeat message to the registration center. The registration center uses a timer to detect the validity of the client agent, and then maintains the status information of the service subscribers and service registrants on the proxy node; Establish a reliable transmission mechanism for service request and response messages: service request messages include service registration messages, service subscription messages and service attribute setting messages. Service response messages are service discovery messages replied by the registration center to the client agent. The lightweight service management system adopts the method of caching historical messages and replying confirmation messages to ensure the reliable transmission of messages. An application-insensitive service automatic registration and subscription mechanism is established in the lightweight service management system. For the case of multiple instances of the same-name service, the client agent provides a first-register-first-served and high-priority-first-served service instance selection strategy for service discovery.

2. The lightweight service management system based on embedded microservice architecture according to claim 1 is characterized in that: The lightweight service management system has two service discovery modes: callback notification based on the service monitoring mechanism and active inquiry function.

3. The lightweight service management system based on embedded microservice architecture according to claim 2 is characterized in that: The method for establishing a reliable transmission mechanism for service request and response messages specifically includes the following steps: S101: The client agent increases the index number count of the service request message, puts it into the historical message queue in the order of the index number, creates a reliability sending task to send the message data, and creates a reliability receiving task to receive the confirmation message and service response message replied by the registration center; S102: The service registration center uses a message processing task pool to process service request messages in parallel, uses the same strategy as the client proxy to cache historical messages and create a reliability message sending task to reply to the client proxy request; S103: Every 8-12 seconds, the reliability sending task periodically traverses the historical messages cached in the message queue and sends data to the peer until the message receiving task receives a confirmation message from the peer. After receiving the message, the message data that was successfully sent is deleted from the historical cache using the index number in the confirmation message. Among them: In S101-S103, all sent messages will judge the validity of the status of the other end based on the heartbeat detection mechanism. If it is in an invalid state, the reliability sending task will not send messages within this period.

4. The lightweight service management system based on embedded microservice architecture according to claim 3 is characterized in that: If an exception occurs in the Dangdang Registry Center cluster, resulting in the loss of managed service information, the application-insensitive automated service registration and subscription mechanism will be executed as follows: S201: The client agent detects that the center multicast heartbeat has timed out and sets the registration center to an invalid state; S202: After the client agent senses that the registration center node is back online, the client agent re-initiates service registration and subscription requests to the center through the local cache; Among them, if the request message sent by the agent is lost due to network instability, the service registration center queries whether the service information is stored in the database based on the service instance name list in the agent heartbeat message. Otherwise, it initiates a service request to the client agent.

Images