Optimized registration method and system based on micro-service architecture

Abstract

The invention discloses an optimized registration method and system based on a micro-service architecture. The invention relates to the technical field of Nacos systems. The health monitoring center is started and starts to send a health examination request to a downstream service at regular time; the gateway access layer service receives a client request; obtaining a network address of a target service instance through a Nacos service discovery mechanism according to a service name in the request; then forwarding the request to a target service instance for processing; when the configuration information is changed, the Nacos configuration management center pushes an update notification to all subscribed service instances; the service instance pulls the latest configuration information and updates the local cache; according to the method, a secondary hand waving mechanism is implemented in Nacos cluster node, gateway service and downstream service communication, so that the offline condition of the downstream service can be accurately judged, and the problem of data inconsistency caused by node faults or network partition is avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of Nacos systems, and more particularly to a fault recovery mechanism of a Nacos system, and more particularly to an optimized registration method and system based on a microservice architecture. Background Art

[0002] In the Nacos distributed system, the current fault recovery mechanism is primarily based on periodic data synchronization and backup. While this mechanism can provide a certain degree of data protection under normal operating conditions, its effectiveness is significantly limited in the face of sudden network outages or unforeseen hardware failures, which can lead to the loss of critical data or unexpected service interruptions, thus affecting the overall reliability and availability of the system. To address this issue, a number of existing technologies have attempted to address this technical issue, such as:

[0003] CN202310108980.6 discloses a method and system for massive data security monitoring based on artificial intelligence (publication date: June 23, 2023); CN202310324516.0 discloses a method and system for service governance of microservices (publication date: March 27, 2023); These existing technologies focus on improving the fault tolerance of the system by enhancing cluster redundancy. Specifically, this is done by deploying multiple data copies to ensure that the system can continue to operate and provide services even if some nodes fail. In addition, based on the Raft protocol, through mechanisms such as leader election, log replication, and security assurance, the consistent state of data copies in the cluster is ensured, thereby enhancing the stability of the system and data reliability.

[0004] However, while these measures have improved the robustness of the system to a certain extent, they still face several limitations when handling data recovery in extreme situations. The frequency and efficiency of periodic data synchronization are key factors affecting the speed of data recovery. In scenarios with high-frequency data changes, improper synchronization cycles may result in the latest data not being backed up in a timely manner, leading to data loss when a failure occurs. Even with the Raft protocol, under extreme network conditions (such as prolonged network partitions) or severe hardware failures, log replication and leader election processes may be significantly delayed, affecting the speed and integrity of data recovery.

[0005] To this end, the present invention proposes an optimized registration method and system based on a microservice architecture. Summary of the Invention

[0006] In view of this, the present invention aims to provide an optimized registration method and system based on a microservice architecture to solve or alleviate the technical problems existing in the prior art, namely, how to maintain high data consistency and quickly restore services when the Nacos system faces extreme failures, especially to reduce failure recovery time and prevent data loss. The technical solution of the present invention is achieved as follows:

[0007] First, the optimized registration method based on the microservice architecture:

[0008] (1) Overview:

[0009] This invention aims to build a distributed service governance system with high availability, dynamic configuration, and rapid recovery. By integrating gateway access layer services, the Nacos cluster, and downstream service instances, unified service registration, discovery, and invocation are achieved, ensuring efficient system operation. As a core component, the Nacos cluster not only provides service registration and discovery functions, but also implements dynamic configuration management and health monitoring, enabling the system to flexibly adjust configuration and routing strategies based on actual conditions. At the same time, this solution focuses on the system's fault tolerance and recovery capabilities. By introducing additional protection mechanisms such as snapshots, push-to-empty protection, and secondary wave, it effectively addresses potential risks such as network anomalies and service instance fluctuations. These mechanisms ensure that the system can quickly recover in the event of a failure, maintaining service continuity and stability.

[0010] (2) Technical solution:

[0011] To achieve the above technical goals, when receiving a system activation command (a user or automated script sends a startup command to the system through a command line, graphical interface, or remote interface), the gateway access layer loads the configuration file and initializes the network communication module; starts the HTTP server and listens on the specified port; starts the Nacos service registration center and loads the existing service registration information; starts the configuration management center, loads and caches the configuration information, and then begins to execute the following steps:

[0012] 2.1 Step S1, Nacos cluster service and downstream service instances are started:

[0013] The health monitoring center sends health check requests to downstream services at regular intervals; each microservice instance receives the startup instruction and loads the application configuration, registers its own information (service name, instance ID and network address) with the Nacos service registration center, and subscribes to the required configuration information.

[0014] 2.1.1 Step S100, start the Nacos cluster service:

[0015] Start each node in the Nacos cluster and configure the network address, port, and data directory of each node. Use the Raft algorithm to elect the leader node to ensure that there is only one leader node in the cluster responsible for processing client requests and synchronizing the internal state of the cluster. After the leader node is successfully elected, the nodes in the cluster synchronize data consistency to ensure that the service registration information and configuration information on all nodes remain consistent.

[0016] 2.1.2 Step S101: Downstream service instance startup and registration

[0017] When the downstream service instance starts, it loads the application configuration information, including the service name, port, and log level;

[0018] The downstream service instance sends a service registration request to the Nacos service registration center, including detailed information about the service instance (service name, instance ID, and network address);

[0019] After receiving the registration request, the Nacos service registration center verifies and returns the registration result. If the registration is successful, the service instance is added to the service list.

[0020] The Nacos service registration center maintains a subscription list of configuration information and pushes configuration information changes to subscribers in real time;

[0021] Downstream service instances set up configuration update listeners.

[0022] 2.1.3 Step S102: Health monitoring center performs regular health checks:

[0023] The health monitoring center periodically sends health check requests to downstream service instances. After receiving the health check requests, the downstream service instances return their own health status information.

[0024] 2.2 Step S2, service discovery and invocation:

[0025] The gateway access layer service receives the client request; based on the service name in the request, it obtains the network address of the target service instance through the Nacos service discovery mechanism; then forwards the request to the target service instance for processing; when the configuration information changes, the Nacos configuration management center pushes update notifications to all subscribed service instances; the service instance pulls the latest configuration information and updates the local cache; and adjusts the service behavior based on the new configuration information.

[0026] 2.2.1 Step S200: Gateway access layer receives request

[0027] The gateway access layer service receives the request from the client.

[0028] Input: HTTP / HTTPS request sent by the client;

[0029] Output: parsed request object;

[0030] S2010, listens to the specified port and waits for client requests.

[0031] S2011, receiving and parsing the request, extracting the service name, path and parameter information in the request.

[0032] 2.2.2 Step S201, Service Discovery:

[0033] According to the service name in the request, the network address of the target service instance is obtained through the Nacos service discovery mechanism.

[0034] Input: Parsed request object (including service name).

[0035] Output: The network address of the target service instance (such as IP address and port).

[0036] S2010, use the Nacos client library to query the Nacos service registration center according to the service name.

[0037] S2011, obtain a list of available service instances and select a target service instance according to the load balancing policy.

[0038] S2012, obtain the network address of the target service instance.

[0039] 2.2.3 Step S202, request forwarding:

[0040] Forward the request to the target service instance for processing.

[0041] Input: The network address of the target service instance, the parsed request object.

[0042] Output: Forwarded response (from the target service instance).

[0043] S2020: Construct a forwarding request and encapsulate the original request information in a new request.

[0044] S2021, sends the request to the network address of the target service instance through the HTTP / HTTPS protocol.

[0045] S2022, wait for and receive a response from the target service instance.

[0046] 2.2.4 Step S203, configuration information update notification:

[0047] When configuration information changes, the Nacos Configuration Management Center pushes update notifications to all subscribed service instances.

[0048] Input: Configuration update events from the Nacos Configuration Management Center.

[0049] Output: Update notification message.

[0050] S2030, Nacos Configuration Management Center monitors configuration information changes.

[0051] S2031: When configuration information changes, an update notification message is generated.

[0052] S2032: Push the update notification message to all service instances that subscribe to the configuration information.

[0053] 2.2.5 Step S204: Service instance pulls configuration update:

[0054] The service instance pulls the latest configuration information and updates the local cache.

[0055] Input: Update notification message.

[0056] Output: The updated local configuration cache.

[0057] S2040: After receiving the update notification message, the service instance uses the Nacos client library to pull the latest configuration information from the Nacos configuration management center.

[0058] S2041: Update the latest configuration information pulled to the local cache.

[0059] 2.2.6 Step S205: Adjust service behavior:

[0060] Adjust service behavior based on the new configuration information.

[0061] Input: The updated local configuration cache.

[0062] S2050: The service instance adjusts its own behavior logic according to the updated configuration information; if necessary, it restarts or reinitializes related components to apply the new configuration.

[0063] S2051: Continue to process the request from the client and provide services according to the new configuration information.

[0064] 2.3 Step S3, health monitoring and fault recovery:

[0065] When the health monitoring center finds an abnormal service instance, it updates the status information in the registration center; the gateway access layer service adjusts the routing strategy based on the health status information provided by Nacos to avoid calling abnormal instances.

[0066] 2.3.1 Step S300: The health monitoring center performs inspections:

[0067] The health monitoring center monitors the running status of the service instance by sending health check requests at regular intervals. When an abnormality is found in the service instance, step S301 is entered.

[0068] Input: Response result of the health check request.

[0069] Output: Information about the abnormal service instance.

[0070] S3000: The health monitoring center sends a health check request to the service instance at a preset frequency.

[0071] S3001, receive and parse the health check response returned by the service instance.

[0072] S3002: Determine whether the service instance is abnormal (such as response timeout, returned error code, etc.) based on the response result.

[0073] S3003, record the information of the abnormal service instance, including the service name, instance ID, network address, etc.

[0074] 2.3.2 Step S301: Update registration center status information

[0075] Synchronize the discovered abnormal service instance information to the Nacos service registration center and update the health status of the instance;

[0076] Input: Information about the abnormal service instance.

[0077] Output: Updated registry status information.

[0078] S3010, using the Nacos client library, marks the health status of the abnormal service instance as "unhealthy" or "offline".

[0079] S3011: Synchronize the updated status information to the Nacos service registration center, and then proceed to step S302.

[0080] 2.3.3 Step S302: The gateway access layer adjusts the routing policy:

[0081] The gateway access layer service dynamically adjusts the routing strategy based on the health status information provided by Nacos to avoid calling abnormal service instances.

[0082] Input: Health status information provided by the Nacos service registration center.

[0083] Output: The adjusted routing policy.

[0084] S3020, the gateway access layer service regularly pulls the health status information of the service instance from the Nacos service registration center; based on the health status information, it updates the local routing table or load balancing policy.

[0085] S3021, when processing client requests, select a healthy service instance for calling based on the updated routing policy.

[0086] S3022: For service instances marked as "unhealthy" or "offline", avoid including them in the scope of routing selection or load balancing.

[0087] 2.4 Step S4, snapshot generation and recovery:

[0088] The gateway access layer service generates system status snapshot files based on preset time intervals or trigger conditions; backs up the snapshot files to local disk or remote storage; and loads the snapshot files from the backup to restore the system status when a failure occurs or a rollback is required.

[0089] 2.4.1 Step S400: Generate a system status snapshot file:

[0090] The gateway access layer service collects the current system status information and generates a snapshot file based on the preset time interval or trigger condition.

[0091] Input: system status information (such as data in memory, configuration information, connection status, etc.).

[0092] Output: System status snapshot file.

[0093] S4000, preset snapshot generation time interval (such as every hour, every day) or preset trigger conditions (such as when a major change occurs in the system status).

[0094] S4001, when the time interval or trigger condition is reached, trigger the snapshot generation process.

[0095] S4002, collect current system status information, including data in memory, configuration information, connection status, etc.

[0096] S4003: Serialize the collected status information into a snapshot file. The file format can be JSON, XML, or binary.

[0097] 2.4.2 Step S401, back up the snapshot file:

[0098] Back up the generated system status snapshot file to a local disk or remote storage to ensure data security and availability.

[0099] Input: System state snapshot file.

[0100] Output: Confirmation message of successful backup.

[0101] S4010, determine the location of the backup storage, including a local disk and / or a remote storage service (cloud storage, NAS, etc.).

[0102] S4011, copy the generated snapshot file to the backup storage location. Verify the integrity and availability of the backup file to ensure the backup was successful. Record the time and results of the backup operation for subsequent auditing and tracking.

[0103] 2.4.3 Step S402: Snapshot recovery in case of failure or rollback:

[0104] When a failure occurs or you need to roll back to a previous state, load the snapshot file from the backup to restore the system state.

[0105] Input: The snapshot file to be restored.

[0106] Output: The system status after recovery.

[0107] S4020, obtain the snapshot file from the backup storage location.

[0108] S4021: Deserialize the data in the snapshot file into the system state, and restore the data, configuration information, and connection state in the memory.

[0109] S4022: Restart the gateway access layer service to make the restored status effective.

[0110] S4023, verify whether the system has resumed normal operation. If not, return to step S4020 and select other snapshot files until normal operation is resumed.

[0111] 2.5 Step S5, additional protection mechanism execution:

[0112] When an environmental failure is detected, including network anomalies, service instance status fluctuations, or collective disconnections, the Upstream push empty protection mechanism takes effect when Nacos pushes an empty service list, so that the gateway access layer service has an available service instance list; at the same time, the secondary handshake mechanism is executed to repeat the detection when it is determined that the service instance is unavailable, reducing the false positive rate.

[0113] 2.5.1 Step S500, environmental fault detection:

[0114] Continuously monitor the operating environment, including network status and service instance status, to detect possible environmental failures.

[0115] Input: Status information of the operating environment (such as network connectivity, service instance heartbeat, etc.).

[0116] Output: Environmental fault alarm.

[0117] For S5000, use a network monitoring tool or service to periodically perform ping tests and / or traceroute.

[0118] S5001 monitors the Nacos service registration center, obtains the heartbeat information of the service instance, and determines whether the service instance is online.

[0119] S5002, set a fault detection threshold. When the abnormal environmental status reaches the threshold, an environmental fault alarm is triggered.

[0120] 2.5.2 Step S501: Upstream push empty protection mechanism takes effect

[0121] When Nacos pushes an empty service list, the Upstream push empty protection mechanism takes effect, so that the gateway access layer service has an available service instance list to avoid service interruption.

[0122] Input: The service list pushed by Nacos (may be empty).

[0123] Output: A list of service instances processed by the protection mechanism (non-empty).

[0124] S5010, the gateway access layer service subscribes to the service list update of the Nacos service registration center.

[0125] S5011: When receiving an empty service list pushed by Nacos, the Upstream push empty protection mechanism is triggered.

[0126] S5012: The protection mechanism obtains an available service instance from a local cache or a preset default service list.

[0127] S5013: Return the obtained service instance list as an available list to the gateway access layer service.

[0128] 2.5.3 Step S502: Execute the secondary waving mechanism:

[0129] When a service instance is judged to be unavailable, a secondary wave mechanism is executed to perform repeated detection to reduce the false positive rate.

[0130] Input: A preliminary determination that the service instance is unavailable.

[0131] Output: Result confirming whether the service instance is truly unavailable.

[0132] S5020: Set the number and interval of secondary handshake detections.

[0133] S5021: When the service instance is initially determined to be unavailable, a secondary wave mechanism is triggered.

[0134] S5022: Send a probe request to the service instance according to the set probe times and intervals.

[0135] S5023: Determine whether the service instance is truly unavailable based on the response result of the detection request.

[0136] S5024: If the number of detections exceeds a preset threshold, the service instance is confirmed to be unavailable, and the administrator is notified to perform corresponding processing (failure recovery or switching to a standby instance).

[0137] (3) Mechanisms for resolving technical issues:

[0138] 3.1 High data consistency mechanism:

[0139] 3.1.1 Distributed Consensus Algorithm (Raft)

[0140] In Nacos, each node is a Raft node, and they communicate and coordinate with each other through the Raft protocol. When a node joins or leaves the cluster, the Raft algorithm automatically elects a leader to ensure that there is always a valid leader node in the cluster to maintain data consistency.

[0141] 3.1.2 Eventual consistency:

[0142] The heartbeat information of service instances is allowed to be transmitted asynchronously between nodes. Even if some nodes fail, as long as the majority of nodes remain normal, the service registration information can be quickly restored through the heartbeat mechanism.

[0143] 3.2 Rapid recovery service mechanism:

[0144] 3.2.1 Snapshot and Data Recovery:

[0145] Regular snapshots are generated to save the current service list and configuration information. In the event of a node failure or data loss, the snapshots can be used to quickly restore the system state. When a node rejoins the cluster, the service list and configuration information can be quickly restored from the snapshot, avoiding the time-consuming process of resynchronizing the entire dataset.

[0146] 3.2.2 Health Monitoring and Failover:

[0147] Nacos's health monitoring center: Once an anomaly is detected, the status information in the registration center is immediately updated and the fault recovery mechanism is triggered. For example, when a service instance failure is detected, Nacos automatically removes the failed instance from the registration list and routes requests to other healthy instances. At the same time, for persistent service instances, Nacos ensures that the information of these instances is persistently stored across multiple nodes to prevent data loss caused by single point failures.

[0148] 3.2.3 Dynamic Configuration Update and Listener:

[0149] Configuration changes are pushed to subscribed service instances in real time through a listener mechanism. This ensures that service instances can immediately apply the new configuration information after the configuration changes. For example, when the configuration information changes, the Nacos Configuration Management Center pushes update notifications to all subscribed service instances. The service instances receive these notifications through listeners and pull the latest configuration information for update. This mechanism reduces problems caused by configuration inconsistencies and improves system flexibility.

[0150] 3.3 Reduce fault recovery time and prevent data loss:

[0151] Based on the system characteristics of Nacos, service registration and configuration information can be redundantly stored across multiple nodes, ensuring that even if some nodes fail, data will not be lost. In particular, when a node fails, other nodes can take over its work, ensuring service continuity and data consistency.

[0152] Secondly, the optimized registration system based on microservice architecture:

[0153] The system is used to implement the optimized registration method based on the microservice architecture described above, which includes:

[0154] (1) Gateway access layer as a unified request access point: processes all requests from the outside, and performs traffic distribution and routing management according to business needs; interacts with the Nacos cluster through service discovery or long links to obtain service instance information and configuration information.

[0155] Components include: access points for traffic, app / h5, and backend management, supporting HTTP protocol to implement standardized processing and response of requests.

[0156] (2) Provides downstream service layers for the implementation of specific business functions, such as order processing and user management. It writes its own information into Nacos through service registration and obtains information about other service instances through service discovery for invocation.

[0157] Components include: multiple microservice instances, each instance is responsible for different (specific) business logic.

[0158] (3) Nacos cluster layer that manages the registration information of all service instances: supports dynamic update and push of configurations to ensure that service instances use the latest configurations; at the same time, monitors the health status of service instances to detect and handle abnormal situations in a timely manner; uses the Raft protocol to ensure data consistency and improves fault tolerance through cluster redundancy.

[0159] Components include:

[0160] (3.1) A service registration center that stores registration information of service instances.

[0161] (3.2) Configuration management center that manages the configuration information of all service instances: supports version control and rollback.

[0162] (3.3) Health monitoring center that monitors the health status of service instances in real time: provides abnormal alarm function.

[0163] (4) Regularly generate snapshot files of the system status, including interface protocols, configuration information, and an additional layer of protection mechanism for health status. Enable the gateway access layer server to generate snapshots at specified time points and back them up to the local disk. Support the generation, storage, loading, and switching processes of snapshot files; also include:

[0164] (4.1) Secondary wave mechanism: Reduces the misjudgment rate caused by network anomalies or service instance status fluctuations through repeated detection.

[0165] (4.2) Push empty protection mechanism: prevents Nacos from pushing empty service lists when service instances are collectively disconnected, ensuring the availability of gateway access layer services.

[0166] (4.3) Unified monitoring mechanism: Real-time monitoring and logging of status changes of downstream service instances, and timely alarms for abnormal situations.

[0167] (4.4) Disaster recovery and degradation plan platform: Provides access layer service degradation function, supports degradation processing of individual services or all services, and ensures partial availability or rapid recovery capabilities of the system in extreme situations.

[0168] Compared with the prior art, the present invention has the following beneficial effects:

[0169] 1. High Data Consistency: This invention implements a double-wave mechanism in the communication between Nacos cluster nodes, gateway services, and downstream services to ensure accurate judgment of downstream service offline conditions, avoiding data inconsistencies caused by node failures or network partitions. For non-persistent services, the eventual consistency protocol ensures data consistency in its final state while maintaining system performance.

[0170] Second, rapid service recovery capabilities: This system regularly generates and saves snapshots, enabling rapid system recovery from snapshots in the event of node failure or data loss, significantly reducing recovery time. The health monitoring center's real-time monitoring and failover mechanisms enable immediate recovery upon detecting service instance anomalies, ensuring service continuity and availability.

[0171] 3. Dynamic configuration update and flexibility: The present invention supports dynamic configuration update and pushes configuration changes to subscribed service instances in real time through a listener mechanism, enabling the system to quickly adapt to changes in demand and improving the flexibility and maintainability of the system.

[0172] 4. Multi-node redundant storage and data security: This invention redundantly stores service registration and configuration information across multiple nodes, ensuring that even if some nodes fail, data will not be lost, improving the data security and reliability of the system. The introduction of the upstream push protection mechanism can also prevent the collective disconnection of service providers, realizing the centralized push service of Nacos. BRIEF DESCRIPTION OF THE DRAWINGS

[0173] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0174] Figure 1 is a schematic diagram of the present invention;

[0175] Figure 2 Schematic diagram of the system architecture of the present invention;

[0176] Figure 3 Schematic diagram of a method for generating a static snapshot of the present invention;

[0177] Figure 4 This is a schematic diagram of the overall process of snapshot generation, startup, and switching of the present invention;

[0178] Figure 5 is a schematic diagram of static snapshot detection of the present invention;

[0179] Figure 6 Schematic diagram of the secondary waving method of the present invention;

[0180] Figure 7 This is a schematic diagram of the Upstream push empty protection of the present invention;

[0181] Figure 8 Schematic diagram of the disaster recovery and degradation plan platform of the present invention. DETAILED DESCRIPTION

[0182] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. The following description sets forth many specific details to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0183] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. The devices disclosed in the embodiments are described briefly because they correspond to the methods disclosed in the embodiments. For relevant details, refer to the method description.

[0184] Explanation of relevant terms:

[0185] (1) Service registration: The service instance registers its own information with the registration center so that other services can discover and call it; that is, the address and other necessary information of the microservice are registered with the service registration center (Nacos) so that other services can discover and communicate with it;

[0186] (2) Service discovery: The process of finding available service instances through the registry to achieve dynamic service invocation; that is, the process of retrieving other microservice information from the service registry (Nacos) so that services can identify and interact with each other;

[0187] (3) (Static) Snapshot: A backup method that makes a complete copy of system data at a specific point in time; a backup of the system state at a certain point in time, used for fault recovery or data rollback;

[0188] (4) Secondary handshake: Common in the TCP protocol, used to ensure that both parties have completely sent and received data; reconfirmation is performed when a service instance is determined to be unavailable, reducing false positives and improving system stability;

[0189] (5) Nacos cluster service: a distributed service governance platform that provides services such as registration, configuration management, and health monitoring;

[0190] (6) Downstream services: relative to the gateway access layer, services that are called to process specific business logic;

[0191] (7) Microservice instance: In the microservice architecture, an independent deployment unit that specifically undertakes a certain business function;

[0192] (8) Nacos Service Registration Center: The component responsible for service registration and management in the Nacos cluster;

[0193] (9) Configuration information: parameter settings required for the operation of the system or service, which can be dynamically updated to adapt to changes in demand;

[0194] (10) Listener: A component used to listen for and respond to specific events (such as configuration updates);

[0195] (11) Nacos service discovery mechanism: a mechanism provided by Nacos for dynamically finding and calling service instances;

[0196] (12) Status information in the registry: data recording the health, availability, and other status of service instances;

[0197] (13) Adjust routing policy: Dynamically modify request forwarding rules based on system status or service instance conditions;

[0198] (14) Preset time intervals or trigger conditions: Preset conditions that trigger operations such as snapshot generation and configuration updates;

[0199] (15) Upstream empty push protection mechanism: In a distributed system, a protection mechanism is adopted to prevent upstream data interruption or empty push, which leads to downstream system processing failure; when the registration center pushes an empty service list, it ensures that the gateway still has a list of available service instances.

[0200] Example 1: Figures 2 to 8 As shown, this embodiment discloses an optimized registration system based on a microservice architecture, and the architecture of the system includes:

[0201] (1) Gateway access layer: As a unified request access point, it processes all requests from the outside and manages traffic distribution and routing according to business needs. It interacts with the Nacos cluster through service discovery or long links to obtain service instance information and configuration information. Components include access points for the traffic side, app side / h5 side, and backend management side. It supports the HTTP protocol to achieve standardized request processing and response.

[0202] (2) Downstream service layer: Provides the implementation of functions in specific business areas, such as order processing, user management, etc. It writes its own information into Nacos through service registration and obtains information about other service instances through service discovery for calling.

[0203] Components include: multiple microservice instances, each instance is responsible for different business logic.

[0204] (3) Nacos cluster layer: manages the registration information of all service instances, supports dynamic update and push of configurations, and monitors the health status of service instances. Components include:

[0205] (3.1) Service Registry: stores registration information of service instances.

[0206] (3.2) Configuration Management Center: manages the configuration information of all service instances and supports version control and rollback.

[0207] (3.3) Health Monitoring Center: monitors the health status of service instances in real time and provides abnormal alarm function.

[0208] (3) Additional protection mechanism layer:

[0209] Regularly generate snapshot files of the system status, including interface protocols, configuration information, and health status. Provides a secondary wave mechanism, push-down protection mechanism, unified monitoring mechanism, and disaster recovery and downgrade plan platform. Snapshot generation and recovery module, secondary wave mechanism module, push-down protection mechanism module, unified monitoring mechanism module, and disaster recovery and downgrade plan platform.

[0210] (4) Interaction between services:

[0211] The gateway access layer interacts with downstream services via HTTP requests.

[0212] The gateway access layer interacts with the Nacos cluster through service discovery or long links.

[0213] Downstream services interact with the Nacos cluster through service discovery or long links.

[0214] Service registration: All providers write the name of the service they provide and host details (IP, port, version, etc.) to the Nacos registration center.

[0215] Service discovery: When consumers need to call a microservice, they download the service registry from the Nacos registry to their local computer, and then select a service provider based on the locally configured load balancing policy. Multiple data transmissions are performed on a single established network connection, maintaining a continuous connection to improve communication efficiency.

[0216] (5) Technical means to deal with failures:

[0217] (5.1) Partition tolerance / service availability:

[0218] (5.1.1) Disconnection reconnection mechanism: When the network is disconnected, try to reconnect to ensure service continuity.

[0219] (5.1.2) Snapshot offline / offline mechanism detection: When a service goes offline, a snapshot is generated and the service status is detected for timely recovery.

[0220] (5.1.3) Network anomaly alarm: Real-time monitoring and alarm of network anomalies for timely processing.

[0221] (5.2) Data accuracy:

[0222] (5.2.1) Snapshot mechanism: Generate snapshots and backups regularly to facilitate recovery in case of data loss or abnormality.

[0223] (5.2.2) Empty / Sudden Drop Alarm: Alarm when Nacos pushes an empty service list or service instances suddenly drop, so that timely processing can be carried out.

[0224] It should be noted that the gateway access layer server generates a snapshot file at a specified time point, including interface protocols, configuration information, health status, etc., and writes it to the local memory and backs it up on the server's local disk.

[0225] It's important to note that the overall process of snapshot creation, activation, and switching includes generating the snapshot cache, notification of changes, flushing local files, and initiating the restore and switchover process. These steps ensure that snapshot data can be restored in the event of a system restart or failure.

[0226] It should be pointed out that static snapshots are built based on timed bypass, and snapshot detection is performed to cope with dynamic expansion and prevent snapshot pollution.

[0227] It should be pointed out that the second wave reduces the misjudgment rate caused by network anomalies or service instance status fluctuations through repeated detection, and responds to the phenomenon of gradually removing the machine "empty" due to abnormal push of Nacos.

[0228] It should be pointed out that Upstream push empty protection is mainly aimed at the situation where Nacos pushes empty service lists after the service providers are collectively disconnected, to ensure that the gateway access layer service has an available service instance list.

[0229] It should be pointed out that the unified monitoring mechanism monitors and logs the status changes of downstream service instances in real time, and issues timely alarms for abnormal situations so that abnormalities can be discovered and handled gradually as early as possible.

[0230] It's important to note that the disaster recovery and downgrade plan platform provides access layer service downgrade capabilities, supporting downgrade of individual or all services. Downgrades can be performed on downstream services at the access layer, enabling one-click downgrade of all services. Monitoring and alarming are provided for abnormal traffic removal and empty pushes, with manual assessment and execution of the plan.

[0231] Example 2: Figure 1 As shown, based on the system provided in Example 1, this embodiment further discloses an application method of the optimized registration method based on the microservice architecture in the online car-hailing microservice platform.

[0232] In the ride-hailing microservice platform, once the system receives a startup command, it executes a series of electronic data processing steps to ensure normal service registration, discovery, invocation, monitoring, and fault recovery. The following process details steps S1 to S5, focusing specifically on how the Nacos system maintains high data consistency and quickly restores service in the face of extreme failures.

[0233] In this embodiment, regarding step S1: system initialization and startup:

[0234] (1) Gateway access layer initialization: Load the configuration file, initialize the network communication module, start the HTTP server, and listen to the specified port.

[0235] (2) Nacos cluster service startup: Load existing service registration information. The configuration management center starts, loads and caches configuration information. The health monitoring center starts, and regularly sends health check requests to downstream services.

[0236] (3) Downstream service instance startup and registration: Each microservice instance receives the startup command and loads the application configuration. It registers its own information (service name, instance ID, and network address) with the Nacos service registration center, subscribes to the required configuration information, and sets the configuration update listener.

[0237] Specifically, steps S100-S102: Detailed startup and registration process:

[0238] S100: Nacos Cluster Service Startup: Start each node in the Nacos cluster and configure the network address, port, and data directory. Use the Raft algorithm to elect a leader node to ensure cluster data consistency. After the leader node is successfully elected, data synchronization is performed to ensure that all nodes have consistent information.

[0239] S101: Downstream service instance startup and registration: Load application configuration information, including service name, port, etc. Send a registration request to the Nacos registration center and wait for verification results. After successful registration, Nacos maintains the configuration information subscription list and pushes updates in real time.

[0240] S102: Health monitoring center performs scheduled health checks: It sends health check requests to service instances regularly, receives and processes health status information, and ensures that the service instance status is updated in real time.

[0241] In this embodiment, regarding step S2: service discovery and invocation:

[0242] (1) Gateway access layer receives requests: listens to the designated port, receives and parses client requests, and extracts the service name, path, and parameter information from the request.

[0243] (2) Service discovery: Use the Nacos client library to query the service registry. Obtain a list of available service instances and select the target instance based on the load balancing strategy.

[0244] (3) Request forwarding: Construct a forwarding request, encapsulate the original request information, and send it to the target instance. Wait for and receive the response from the target instance, and then return it to the client.

[0245] (4) Configuration information update notification: When the configuration information changes, the Nacos Configuration Management Center pushes the update notification. The service instance pulls the latest configuration information and updates the local cache.

[0246] (5) Adjust service behavior: Adjust service behavior according to the updated configuration information, such as restarting or reinitializing components.

[0247] In this embodiment, regarding step S3: health monitoring and fault recovery:

[0248] (1) The health monitoring center performs inspections: it sends health check requests regularly to monitor the status of service instances. When an anomaly is found, the information is recorded and synchronized to the Nacos registration center.

[0249] (2) Update the status information of the registration center: mark the abnormal service instance information as "unhealthy" or "offline". Synchronize the updated status information to the Nacos registration center.

[0250] (3) The gateway access layer adjusts routing strategies: Regularly pull service instance health status information. Update routing tables or load balancing strategies to avoid calling abnormal instances.

[0251] In this embodiment, regarding step S4: snapshot generation and restoration:

[0252] (1) Generate system status snapshot files: Collect system status information based on preset time intervals or trigger conditions. Generate snapshot files and serialize them into a specified format (such as JSON or XML).

[0253] (2) Backup snapshot files: Back up snapshot files to a local disk or remote storage. Verify the integrity and availability of the backup files.

[0254] (3) Snapshot recovery during failure or rollback: Load the snapshot file from the backup. Deserialize the data to restore the system state. Restart the service and verify whether the system has returned to normal.

[0255] In this embodiment, regarding step S5: additional protection mechanism execution:

[0256] (1) Environmental fault detection: Continuously monitor the operating environment, including network status and service instance status. Set fault detection thresholds to trigger environmental fault alerts.

[0257] (2) Upstream push empty protection mechanism takes effect: When Nacos pushes an empty service list, the protection mechanism is triggered. Available service instances are obtained from the local cache or the preset default list.

[0258] (3) Execute the secondary wave mechanism: Set the secondary wave detection times and intervals. Repeat the detection of service instances that are initially judged to be unavailable. Confirm the service instance status based on the detection results and notify the administrator to handle the situation.

[0259] It is understandable that the Nacos cluster and snapshot mechanism ensures the consistency of service registration information and configuration information, reducing service call failures caused by inconsistent information. In the event of a failure, the system state can be quickly restored from the backup, reducing the recovery time.

[0260] Snapshot files contain comprehensive information to ensure that the system state can be completely restored during recovery.

[0261] Additional protection mechanisms such as Upstream push-empty protection and secondary wave mechanisms can reduce the misjudgment rate and improve the system's ability to cope with extreme failures.

[0262] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0263] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0264] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. An optimized registration method based on a microservice architecture includes: when receiving a system activation instruction, the gateway access layer loads the configuration file, the Nacos service registration center loads the existing service registration information; the configuration management center loads and caches the configuration information, characterized in that: Perform the following steps: S1: The health monitoring center sends health check requests to downstream services at regular intervals; each microservice instance receives the startup command and loads the application configuration, and registers its own information with the Nacos service registration center; S2: The gateway access layer obtains the network address of the target service instance through the Nacos service discovery mechanism based on the service name in the request. When the configuration information changes, it pushes update notifications to all subscribed service instances, pulls the latest configuration information, and updates the local cache. S3: When the health monitoring center finds an abnormal service instance, it updates the status information in the registration center; the gateway access layer service adjusts the routing strategy based on the health status information provided by Nacos; S4, the gateway access layer service generates a system status snapshot file according to a preset time interval or trigger condition; In case of failure or rollback, load the snapshot file from the backup; S5, when an environmental failure is detected, the Upstream push empty protection mechanism takes effect when Nacos pushes an empty service list, so that the gateway access layer service has an available service instance list.

2. The optimized registration method according to claim 1, characterized in that: The execution method of S1 includes: S100: Start each node in the Nacos cluster and configure the network address, port, and data directory of each node. Use the Raft algorithm to elect the leader node to synchronize data consistency among the nodes in the cluster. S101, when the downstream service instance starts, load the application configuration information, including the service name, port, and log level; The downstream service instance sends a service registration request to the Nacos service registration center, including detailed information about the service instance (service name, instance ID, and network address); After receiving the registration request, the Nacos service registration center verifies and returns the registration result; if the registration is successful, the service instance is added to the service list; The Nacos service registration center maintains a subscription list of configuration information and pushes configuration information changes to subscribers in real time; Downstream service instances set configuration update listeners; S102, the health monitoring center sends a health check request to the downstream service instance at regular intervals. After receiving the health check request, the downstream service instance returns its own health status information.

3. The optimized registration method according to claim 1, characterized in that: The execution method of S2 includes: S200, the gateway access layer service receives a request from the client; S201, according to the service name in the request, obtain the network address of the target service instance through the Nacos service discovery mechanism; S202, forwarding the request to the target service instance for processing; S203, when the configuration information changes, the Nacos Configuration Management Center pushes update notifications to all subscribed service instances; S204, the service instance pulls the latest configuration information and updates the local cache; S205: Adjust service behavior according to the new configuration information.

4. The optimized registration method according to claim 3, characterized in that: In the S203, it includes: S2030, Nacos Configuration Management Center monitors configuration information changes; S2031, when configuration information changes, generate an update notification message; S2032: Push the update notification message to all service instances that subscribe to the configuration information.

5. The optimized registration method according to claim 1, characterized in that: The execution method of S3 includes: S300, the health monitoring center monitors the running status of the service instance by sending health check requests at regular intervals. If an abnormality is found in the service instance, the process proceeds to S301; S301: Synchronize the discovered abnormal service instance information to the Nacos service registration center and update the health status of the instance; S302: The gateway access layer service dynamically adjusts the routing strategy based on the health status information provided by Nacos to avoid calling abnormal service instances.

6. The optimized registration method according to claim 5, characterized in that: In the S300, it includes: S3000: The health monitoring center sends health check requests to the service instance at a preset frequency. S3001, receiving and parsing the health check response returned by the service instance; S3002, judging whether the service instance is abnormal based on the response result; S3003, record the information of the abnormal service instance, including the service name, instance ID and network address; The S302 includes: S3020, the gateway access layer service regularly pulls the health status information of the service instance from the Nacos service registration center; based on the health status information, it updates the local routing table or load balancing policy; S3021, when processing the client request, select a healthy service instance to call based on the updated routing policy; S3022: Avoid including service instances marked as "unhealthy" or "offline" in routing or load balancing.

7. The optimized registration method according to claim 1, 2 or 5, characterized in that: In said S4, it includes: S400, the gateway access layer service collects the current system status information according to a preset time interval or trigger condition and generates a snapshot file; S401, backing up the generated system status snapshot file to a local disk or remote storage; S402, when a failure occurs or a rollback to a previous state is required, the snapshot file is loaded from the backup to restore the system state.

8. The optimized registration method according to claim 1, 2 or 5, characterized in that: In said S5, it includes: S500, continuously monitors the operating environment, including network status and service instance status; S501, when Nacos pushes an empty service list, the Upstream push empty protection mechanism takes effect, so that the gateway access layer service has an available service instance list to avoid service interruption; S502: When the service instance is determined to be unavailable, a secondary wave mechanism is executed to perform repeated detection.

9. A system for implementing the optimized registration method according to any one of claims 1 to 8, characterized in that: The system comprises: The gateway access layer serves as a unified request access point, including access points for the traffic end, app end / h5 end, and backend management end; Provides a downstream service layer that implements functions in specific business areas, including: multiple microservice instances; The Nacos cluster layer manages the registration information of all service instances, including: a service registration center that stores the registration information of service instances, a configuration management center that manages the configuration information of all service instances, and a health monitoring center that monitors the health status of service instances in real time; Generates snapshot files of system status regularly, including interface protocols, configuration information, and an additional layer of protection mechanism for health status.

10. The system according to claim 9, characterized in that: The additional protection mechanism layer has the following mechanisms: Secondary wave mechanism: Reduces false positives caused by network anomalies or service instance status fluctuations through repeated detection; Empty push protection mechanism: prevents Nacos from pushing an empty service list when service instances are collectively disconnected; Disaster recovery and downgrade plan platform: provides access layer service degradation function and supports downgrade processing of a single service or all services.

Images