Lightweight service management system based on embedded micro-service architecture

Abstract

The invention belongs to the technical field of computer software professional micro-services, and particularly designs a lightweight service management system based on an embedded micro-service architecture, which comprises a service registration center and a client agent, the distributed service management system is a lightweight and easy-to-deploy service management technology, maintains state information of distributed services, realizes an efficient and reliable data transmission mechanism based on a connectionless mode of a UDP protocol, provides service registration center state perception, service registration and service subscription and discovery functions for the distributed services, and provides a distributed database based on an raft protocol. High availability and data consistency of the service registration center are achieved, a Web UI interface is provided, and a micro-service developer can conveniently monitor the service state in real time.

Description

Technical Field

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

[0002] With the continuous growth of application scale in embedded environments and the widespread application of intelligent applications, in order to better manage and maintain software development and upgrades, embedded platforms introduce microservice architecture, split 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 microservice architecture.

[0003] The service registration center is mainly aimed at the problem that the large number of service instances, service status changes, and dynamic service migration in the distributed platform make the software difficult to manage. It monitors and manages the status of services and provides two main functions: service registration and service discovery. The mainstream service registration center implementation tools in the industry mainly include Eureka, Consul, Zookeeper, and Etcd. Among them, the Eureka component has been integrated into the microservice architecture Spring Cloud, the Zookeeper component has been integrated into Alibaba's Dubbo architecture, and Etcd is widely used in Kubernetes cloud native technology. These registration center tools use a long connection communication mechanism, and the environment dependence, configuration, and deployment are relatively complex. They are not suitable for microservice architectures with limited embedded platform resources and high real-time requirements. It is necessary to design a lightweight service management system 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, an efficient and reliable data transmission mechanism is implemented, and the functions of service registration center status perception, service registration, service subscription and discovery are provided for distributed services. A distributed database based on the raft protocol realizes high availability and data consistency of the service registration center, and 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 a client agent;

[0007] The service registration center is a distributed database based on the raft protocol. It uses a master-slave collaboration method 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 the 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 proxy is:

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

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

[0012] Establish a heartbeat perception mechanism for the client agent to the registration center: the client agent and the registration center agree on the multicast address and port number, create a heartbeat receiving task for the registration center to receive the multicast message of the registration center, and the client agent uses a timer to detect the validity of the registration center;

[0013] Establish a heartbeat perception mechanism for 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 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;

[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 that the registration center replies to the client agent. The lightweight service management system uses the method of caching historical messages and replying to confirmation messages to ensure reliable message transmission.

[0015] Establish an application-insensitive service automation 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 the same-name service, the client proxy provides a first-register-first-served and high-priority-first-served service instance selection strategy 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 proxy 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, and replies 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 until the message receiving task receives a confirmation message from the peer. After receiving the message, the successfully sent message data 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 party 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, the abnormality of 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:

[0024] S201: The client agent senses 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 initiates a service registration and subscription request to the center again through the local cache;

[0026] 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 initiates a service request to the client proxy.

[0027] Beneficial effects of the present invention:

[0028] (1) A connectionless communication method is adopted, and 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 a selection strategy for service instances with the same name in the client proxy, and provides two strategies: first-come-first-served and high-priority first-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 a web server 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, thereby ensuring the high availability and data consistency of the registration center.

[0032] (5) It provides application-insensitive automated service registration and subscription capabilities. In the event that all nodes of the service registration center crash and service data is lost, the agent can proactively initiate service registration and subscription requests based on historical cache after sensing that the center is back online, ensuring that the service is back online 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 drawings required for use in the embodiments will be briefly introduced below. 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 creative work.

[0034] Figure 1 It 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 A 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 the following embodiments and features in the embodiments can be combined with each other without conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the 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 the present 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 the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this device 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 rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0042] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may 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, including a service registration center and a client agent;

[0044] The service registration center is a distributed database based on the raft protocol. It uses a master-slave collaboration method 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 the 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, a lightweight service management and operation mechanism is designed.

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

[0049] Establish a heartbeat perception mechanism for the client agent to the registration center: the client agent and the registration center agree on the multicast address and port number, create a heartbeat receiving task for the registration center to receive the multicast message of the registration center, and the client agent uses a timer to detect the validity of the registration center;

[0050] Establish a heartbeat perception mechanism for 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 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;

[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 that the registration center replies to the client agent. The lightweight service management system uses the method of caching historical messages and replying to confirmation messages to ensure reliable message transmission.

[0052] Establish an application-insensitive service automation 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 proxy provides a first-register-first-served and high-priority-first-served policy for selecting service instances with the same name 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 proxy 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, and replies 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 until the message receiving task receives a confirmation message from the peer. After receiving the message, the successfully sent message data 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 party 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, the abnormality of the Dangdang registration center cluster causes the loss of the managed service information, and the execution steps of the application-insensitive service automatic registration and subscription mechanism are as follows:

[0061] S201: The client agent senses 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 initiates a service registration and subscription request to the center again through the local cache;

[0063] 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 initiates a service request to the client proxy.

[0064] The overall architecture of this embodiment mainly includes two software components: a registration center and a 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. It provides cache update, callback notification and active query functions for the increase of service instances and dynamic changes of service addresses; it provides registration services and setting service survival cycles for service providers.

[0067] Aiming at the environment with limited network resources of embedded platform, a lightweight service management and operation mechanism based on UDP protocol connectionless mode is designed for the message transmission between client agent and registration center, which mainly includes the following steps:

[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 a proxy 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 proxy heartbeat information mainly includes the service instance information and service life cycle information registered through the proxy node. The service instance information mainly refers to the service instance name registered by the proxy 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 are taken offline, and the node service subscribers are no longer notified of the service discovery messages 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 to confirmation messages to ensure reliable message transmission.

[0073] (4) Establish an automated 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 proxy locally caches the registered service instance information, senses 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 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 proxy 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 proxy. The client proxy can provide the best service to the subscriber based on the service online sequence or service priority.

[0076] See also 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. It uses 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 request and updating data; the client agent component, as the client exposed by the service registration center to the distributed service, provides registration service, subscription service, and discovery service functions for service subscribers and consumers, and provides the ability to perceive and update the service address for dynamic changes in the service address.

[0077] like Figure 2 The following is a flowchart of the software operation based on the UDP protocol connectionless design, 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 to confirmation messages to ensure reliable transmission of messages.

[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 discovery methods for service subscribers are provided: callback notification based on the service monitoring mechanism and active inquiry function.

[0083] Step 6: For multiple instances of the same-name service, the client proxy provides a selection strategy for the service instance of the same name discovered by the service, and provides the best service instance for the service subscriber.

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

[0085] 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 create reliability message sending tasks, and is responsible for replying to service discovery messages from service subscribers.

[0087] 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 other end until the message receiving task receives the confirmation message from the other 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 determine the validity of the peer status based on the heartbeat detection mechanism. If it is in a failed state, the reliability sending task will not send messages during this period to avoid occupying network bandwidth.

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

[0090] Step 4.1: The registration center cluster is abnormal, resulting in the loss of managed service information. The client agent senses that the center multicast heartbeat has timed out and sets the registration center to an invalid state.

[0091] Step 4.2: After the client agent senses that the registration center node is back online, the client agent initiates service registration and subscription requests to the center again 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 change 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 description is 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 is only a specific implementation of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present disclosure should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope 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. It uses a master-slave collaboration method 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 the data. 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.

2. The lightweight service management system based on embedded microservice architecture according to claim 1 is characterized in that: The communication mechanism between the service registry and the client proxy is: Based on the connectionless mode of UDP protocol, a lightweight service management and operation mechanism is designed. The communication mechanism can be set up in the following ways: Establish a heartbeat perception mechanism for the client agent to the registration center: the client agent and the registration center agree on the multicast address and port number, create a heartbeat receiving task for the registration center to receive the multicast message of the registration center, and the client agent uses a timer to detect the validity of the registration center; Establish a heartbeat perception mechanism for 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 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; 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 that the registration center replies to the client agent. The lightweight service management system uses the method of caching historical messages and replying to confirmation messages to ensure reliable message transmission. Establish an application-insensitive service automation registration and subscription mechanism in the lightweight service management system.

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

4. The lightweight service management system based on embedded microservice architecture according to claim 3 is characterized in that: For the case of multiple instances of the same-name service, the client proxy provides a first-register-first-served and high-priority-first-served service instance selection strategy for service discovery.

5. The lightweight service management system based on embedded microservice architecture according to claim 4 is characterized in that: The method for establishing a reliable transmission mechanism for service request and response messages specifically comprises the following steps: S101: The client proxy 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, and replies 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 successfully sent message data 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 party based on the heartbeat detection mechanism. If it is in an invalid state, the reliability sending task will not send messages within this period.

6. The lightweight service management system based on embedded microservice architecture according to claim 5 is characterized in that: The abnormality of 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: S201: The client agent senses 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 initiates a service registration and subscription request to the center again through the local cache; 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 initiates a service request to the client proxy.

Images