Service updating method and device and micro-service system

Abstract

The invention provides a service updating method and device and a micro-service system, and relates to the technical field of cloud native. The method is applied to a Nacos system in a micro-service system, and redis cache middleware is integrated in the Nacos system. The method comprises the steps of generating an updating instruction for updating a service list cached in redis cache middleware when detecting that the state of any service instance provided by a server side is a fault, and initiating an expiration event for the service instance in the fault state after updating is completed, so that a consumption side updates the service list after monitoring the expiration event. Therefore, the Nacos system is combined with the redis cache middleware, and monitoring is configured at the consumption end, so that the original timing polling logic of the consumption end is converted into active monitoring, the consumption end can sense the state change of the service instance in time, and then the locally cached service list is updated in real time.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a service update method, device, and microservice system. Background Art

[0002] Nacos (Naming and Configuration Service), an open-source registration center, is widely used in the distributed service space. The Nacos system consists of the Nacos-server and the Nacos-client, which work closely together to provide comprehensive service discovery capabilities, including service registration, where service providers register their service information with the Nacos-server through the Nacos-client, and service discovery, where service consumers query the Nacos-server through the Nacos-client to obtain a list of available service providers.

[0003] Among them, the service consumer uses Nacos-client to periodically poll Nacos-server to obtain the latest service list and cache this information for fast call. However, in actual applications, there are problems where the service consumer calls a service instance that has been offline, resulting in temporary service unavailability, which affects the service consumer's user experience. Summary of the Invention

[0004] The present application provides a service update method, device and microservice system, which enable the consumer end to promptly perceive the status changes of service instances and promptly update the locally cached service list to avoid calling unavailable service instances and affecting the user experience of service consumers.

[0005] In a first aspect, an embodiment of the present application provides a service update method, which is applied to a Nacos system in a microservice system using Nacos as a registration center. The microservice system includes a consumer end, a server end, and a Nacos system, and the Nacos system is integrated with a Redis cache middleware. The method includes: Detecting the status of multiple service instances provided by the server; When it is detected that the status of any service instance is faulty, an update instruction for updating the service list cached in the redis cache middleware is generated; the service list is composed of the multiple service instances; After the update is complete, an expiration event is initiated for the service instance with a fault status; The expiration event is used to enable the consumer to update the locally cached service list when the consumer monitors the expiration event.

[0006] Optionally, the method further includes: Sending heartbeat requests to the multiple service instances at preset time intervals; Determine the status of a service instance that receives a heartbeat request response within a preset time as normal; The status of a service instance that has not received a response to a heartbeat request within a preset time is determined to be faulty.

[0007] Optionally, the method further includes: Regularly read the service list from the redis cache middleware for permanent storage to form a basic service list; The basic service list is used to enable the consumer end to update the locally cached service list according to the basic service list when the redis cache middleware fails.

[0008] Optionally, the method further includes: When it is detected that any of the multiple service instances are online or offline, the service update instruction is generated.

[0009] Optionally, when it is detected that the status of any service instance is faulty, after generating an update instruction for updating the service list cached in the redis cache middleware, the method further includes: Based on the update instruction, detecting whether an expiration event has been initiated for the service instance in the fault state; If no expiration event has been initiated, the cached service list is updated according to the service update instruction.

[0010] Optionally, the method further includes: In response to the registration request initiated by the server, the service instance is stored in the redis cache middleware; The registration request is initiated by the server when it performs a performance self-test on the service instance and the server passes the test.

[0011] Based on the same inventive concept, a second aspect of an embodiment of the present application provides a service update method, which is applied to a consumer end in a microservice system with Nacos as a registration center. The microservice system includes a consumer end, a service end, and a Nacos system. The Nacos system is integrated with a redis cache middleware. The above method includes: When an expiration event is detected, the locally cached service list is updated; Among them, the expiration event is generated when the Nacos system detects that there is a service instance in a faulty state among the multiple service instances provided by the server, generates an update instruction for updating the service list cached in the redis cache middleware, and updates the service list; the service list is composed of the multiple service instances.

[0012] Optionally, when the expiration event is monitored, the locally cached service list is updated, including: When the expiration event is monitored, the service instance in the fault state is deleted from the service list in the local cache.

[0013] Based on the same inventive concept, the third aspect of the embodiment of the present application provides a microservice system for service update, which uses Nacos as a registration center. The microservice system includes a consumer end, a server end, and a Nacos system. The Nacos system is integrated with a redis cache middleware; wherein, The Nacos system is configured to detect the status of multiple service instances provided by the server, and when detecting that the status of any service instance is faulty, generate an update instruction for updating the service list cached in the redis cache middleware, and initiate an expiration event for the service instance in the faulty status after the update is completed; the service list is composed of the multiple service instances; The consumer end is used to update the locally cached service list when monitoring the expiration event.

[0014] Based on the same inventive concept, a fourth aspect of an embodiment of the present application provides a service update device, which is applied to a Nacos system in a microservice system with Nacos as a registration center. The microservice system includes a consumer end, a server end, and a Nacos system. The Nacos system is integrated with a Redis cache middleware. The device includes: A status detection module, used to detect the status of multiple service instances provided by the server; A service update module is configured to generate an update instruction for updating a service list cached in the Redis cache middleware when detecting that any service instance is in a faulty state, and initiate an expiration event for the service instance in a faulty state after the update is completed; the service list is composed of the multiple service instances; The expiration event is used to enable the consumer to update the locally cached service list when the consumer monitors the expiration event.

[0015] Based on the same inventive concept, a fifth aspect of an embodiment of the present application provides a service update device, which is applied to a consumer end in a microservice system with Nacos as a registration center. The microservice system includes a consumer end, a service end, and a Nacos system. The Nacos system is integrated with a Redis cache middleware. The device includes: The monitoring update module is used to update the locally cached service list when an expiration event is detected; Among them, the expiration event is generated when the Nacos system detects that there is a service instance in a faulty state among the multiple service instances provided by the server, generates an update instruction for updating the service list cached in the redis cache middleware, and updates the service list; the service list is composed of the multiple service instances.

[0016] Compared with the prior art, this application has the following advantages: A service update method provided in an embodiment of the present application is applied to the Nacos system in a microservice system with Nacos as the registration center, wherein the microservice system includes a consumer end, a server end and a Nacos system, and the Nacos system is integrated with a redis cache middleware. The service update method detects the status of multiple service instances provided by the server end; when it is detected that the status of any service instance is faulty, an update instruction is generated for updating the service list cached in the redis cache middleware, and after the update is completed, an expiration event is initiated for the service instance with a faulty status; wherein the expiration event is used to enable the consumer end to update the locally cached service list when the expiration event is detected. Thus, by combining the Nacos system with the redis cache middleware and utilizing the expiration event capability of redis, a monitor is configured on the consumer end to convert the original timed polling logic of the consumer end into an active monitor, so that the consumer end can promptly perceive the status change of the service instance, and then promptly update the locally cached service list, thereby ensuring the timeliness of the service data, and ultimately improving the availability of the Nacos service itself, providing a better service experience for service consumers. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 It is the service flow chart of the microservice system in related technologies; Figure 2 This is a service flow chart of the microservice system in one embodiment of the present application; Figure 3 This is a flowchart of a service update method applied to the Nacos system in one embodiment of the present application; Figure 4 This is a flowchart of a service update method applied to a consumer end in another embodiment of the present application; Figure 5 This is a schematic diagram of the structure of a microservice system for service update in one embodiment of the present application; Figure 6 This is a functional module diagram of a service update device applied to the Nacos system in one embodiment of the present application; Figure 7 This is a functional module diagram of a service update device applied to a consumer end in one embodiment of the present application. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0020] Nacos is a dynamic service discovery, configuration management and service management platform that is easy to build cloud native applications. For details, please refer to Figure 1 , Figure 1 It is a service flow chart of the microservice system in related technologies. Figure 1 As shown in the figure, the microservice system uses Nacos as the registration center. The microservice system includes the consumer side, the server side, and the Nacos system. The Nacos system includes Nacos-server (server) and Nacos-client (client), and through the close cooperation of the two, it provides a complete service discovery function, including but not limited to: 1. Service Registration: The service provider on the server side sends a registration request to the Nacos-server through the Nacos-client to register its own service and provide its own metadata, such as IP address, port, etc. After receiving the registration request, the Nacos-server will store this metadata information in a two-layer memory map table.

[0021] 2. Service Discovery: When a service consumer on the consumer side calls a service provided by a service provider, it sends a call request to Nacos-server through Nacos-client to obtain the service list registered above and cache it locally in Nacos-client. At the same time, a scheduled task is started locally in Nacos-client to periodically poll Nacos-server, pull the latest registry information from Nacos-server and update it to the local cache. Then, the service consumer can select a service instance from the service list to call according to its own strategy (such as polling, random selection, etc.).

[0022] Since Nacos-client uses a periodic polling method to pull the latest service list from Nacos-server for caching, when a service suddenly fails and goes offline, Nacos-client needs to wait for the next polling cycle to obtain the latest service list from Nacos-server. In other words, there is a lag in updating the local service list of Nacos-client, which may cause service consumers to call offline service instances, resulting in temporary service unavailability.

[0023] To avoid this problem, this application first improves the existing microservice system architecture and integrates Redis cache middleware into the Nacos system. Redis cache middleware is a high-performance storage middleware that mainly uses data structures such as memory, fixed characters, hashes, sets, and arrays to provide efficient data reading capabilities.

[0024] For details, please refer to Figure 2 , Figure 2 This is a service flow chart of the microservice system in one embodiment of the present application. Figure 2 As shown in the figure, after receiving the registration request, Nacos-server caches the service instance information in the Redis cache middleware. When Nacos-server detects that a service has suddenly failed and gone offline, it updates the Redis cache middleware in real time. After the update, Redis will trigger an expiration event. By configuring a listener in Nacos-client, you can monitor this expiration event in real time. Therefore, once the service list in the Redis cache middleware is updated, all consumers on the consumer side can immediately monitor the change through Nacos-client, thereby updating the service list cached locally in Nacos-client in real time, ensuring the timeliness of service data.

[0025] Further, in Figure 2In the microservice system shown in FIG, this application proposes a service update method, which is applied to the Nacos system in the microservice system. Specifically, Figure 3 As shown, the method includes the following steps: S301: Detect the status of multiple service instances provided by the server.

[0026] like Figure 2 As shown in Figure 1, the service side includes one or more service providers, and the consumer side includes one or more service consumers. Service consumers can call service instances provided by service providers to perform corresponding tasks.

[0027] First, when the service provider (i.e., microservice application) starts, it will initiate a service registration request to the Nacos-server (server) through the Nacos-client (client) to register the metadata of the service instance it provides with the Nacos-server for service consumers to call. The metadata of the service instance includes information such as the service name, instance address (IP and port), and health check path.

[0028] After receiving the service registration request, Nacos-server verifies the relevant information of the service instance and, after confirming that the service information is correct, stores the relevant information of each service instance in the Redis cache middleware in hash format to form a service list. At the same time, it also stores them in an internal data structure, that is, it will simultaneously save them to persistent storage (such as a database) to ensure high availability of the service instance. At this point, the service registration is completed.

[0029] After that, Nacos-server will continue to detect the status of each service instance to understand the health of the service instance and determine whether the service instance is available, so as to update and maintain the service list and keep the registration information real-time.

[0030] For example, Nacos-server can start a scheduled task to check the health status of registered service instances. For example, after the service is registered, Nacos-client is required to report a heartbeat every 5 seconds to indicate that the service is always available. If Nacos-server does not receive a heartbeat from Nacos-client for more than 15 seconds, it will mark its health attribute as unhealthy and continue to count. If it still does not receive a heartbeat from the service instance for more than 30 seconds, it will determine that the status of the service instance is faulty.

[0031] S302: When it is detected that the status of any service instance is faulty, an update instruction for updating the service list cached in the redis cache middleware is generated; the service list is composed of multiple service instances.

[0032] In this embodiment, the service update instruction is used to instruct the redis cache middleware to update the cached service list according to the current status of each service instance.

[0033] After completing service registration, Nacos-server will continue to detect the latest status of each service instance. If it detects that a service instance is in a faulty state, it means that the service instance is no longer available. In this case, a service update instruction is generated to instruct the Redis cache middleware to change the status of the faulty service instance in the cached service list, thereby updating the service list.

[0034] Specifically, after receiving the service update instruction sent by Nacos-server, the redis cache middleware will update the cached service list. For example, it will change the status of the faulty service instance to unavailable, or directly delete the faulty service instance from the service list to keep the service list real-time.

[0035] S303: After the update is completed, an expiration event is initiated for the service instance in the fault state; wherein the expiration event is used to enable the consumer end to update the locally cached service list when the expiration event is monitored.

[0036] In this embodiment, after the redis cache middleware in Nacos-server updates the cached service list according to the service update instruction, it will initiate an expiration event for the service instance with a fault status to the consumer end.

[0037] At this point, multiple service consumers on the consumer side can synchronously monitor the expiration event through Nacos-client, learn the latest status of the current service instance, and make corresponding updates in the locally cached service list based on the faulty service instance indicated by the expiration event. For example, they can delete the faulty service instance from the service list to prevent the service consumer from calling an unavailable service instance.

[0038] When implementing this, you first need to configure event notifications in Redis to control what types of event notifications Redis sends. For example, you can enable the notify-keyspace-events "*" configuration item to set the events you want to monitor. When Redis publishes events via Pub / Sub (publish and subscribe mode), you can use __keyevent@ <db> __: <event>The format is published to the channel, and the service consumers on the consumer side can subscribe to these channels through Nacos-client to listen for specific operations.

[0039] Specifically, after the redis cache middleware receives the service update instruction sent by Nacos-server, it will update the cached service list and then publish the event __keyevent@ <db>__:<Service Instance 1 Expired>. This is the expiration event for the failed service instance 1. In this regard, all service consumers on the consumer side can simultaneously monitor the expiration event of service instance 1 through Nacos-client, and then update the local cached service list accordingly. Afterwards, the service consumer can select a service instance from the service list to call according to its own strategy.

[0040] Specifically, Nacos-server has a built-in agent (an intelligent agent, a software or service running in a computer system, whose main function is to communicate and coordinate between the server and the client). The agent prefabricates the service interface call script for the basic scenario. The consumer side calls the predefined service scenario interface through the Nacos-client client to provide external services to the service consumer as expected.

[0041] On this basis, the consumer can select the appropriate service instance to call through the service load balancing component Ribbon. In the Ribbon module, common load balancing strategies can be implemented, including polling strategy, weighted polling strategy, shortest response time strategy, etc. As for the specific access strategy, you can set it in the Nacos service configuration. It should be noted that different polling strategies may have different requirements for the Nacos service configuration. For example, if the weighted polling strategy is used, it is necessary to obtain the service instance when setting the Nacos service configuration, and then set the weight of different service instances. Of course, the simplest load balancing strategy is the polling strategy, so this strategy can be set as the default load balancing strategy.

[0042] Furthermore, the update process of the service list is as follows: Based on the update instruction, check whether an expiration event has been initiated for the service instance in the fault status; if no expiration event has been initiated, update the cached service list according to the service update instruction, and initiate an expiration event for the service instance in the fault status after the update is completed.

[0043] In this implementation, after receiving the service update command, the Redis cache middleware first checks whether an expiration event has already been initiated for the faulty service instance. If an expiration event has already been initiated for the faulty service instance, this indicates that the service update command sent by Nacos-server is a duplicate. The Redis cache middleware has already updated the service list and initiated an expiration event for the faulty service instance. Therefore, there is no need to repeat the update this time.

[0044] If no expiration event has been initiated for the faulty service instance, it means that this is the first time that the service instance has been detected to be faulty. Therefore, the cached service list is updated according to the service update instruction, and after the update is completed, an expiration event is initiated for the service instance with a faulty status. This notifies Nacos-client to update the locally cached service list in a timely manner, so that service consumers can always call available service instances.

[0045] Specifically, Redis updates the service list by adjusting the status of the failed service instance to 0, immediately removing the failed service instance from the cached service list. If the service instance subsequently recovers to a usable state, it can be added to the Redis cached service list by re-registering it.

[0046] It is easy to understand that Nacos-client also updates the service list by deleting the faulty service instance from the local cached service list.

[0047] This embodiment combines the Nacos system with the Redis cache middleware and utilizes the expiration event capability of Redis to configure monitoring on the consumer side. This converts the original scheduled polling logic of the consumer side into active monitoring, allowing the consumer side to promptly perceive the status changes of the service instance and then promptly update the locally cached service list, ensuring the timeliness of service data. Ultimately, this improves the availability of the Nacos service itself and provides a better service experience for service consumers.

[0048] Optionally, the above method further includes: At preset time intervals, heartbeat requests are sent to multiple service instances respectively; the status of the service instance that receives a response to the heartbeat request within the preset time is determined to be normal; the status of the service instance that does not receive a response to the heartbeat request within the preset time is determined to be faulty.

[0049] In this implementation, Nacos-server uses a heartbeat mechanism to detect the status of service instances. For example, Nacos-server sends heartbeat requests to each service instance at a certain time interval (for example, once every 5 seconds) and determines whether the service instance is alive based on the response of the service instance.

[0050] After receiving the heartbeat request, the service instance on the server side will return the corresponding heartbeat data packet to Nacos-server within the preset time to prove that it is still alive and available.

[0051] For Nacos-server, if the service instance responds to the heartbeat request in time and returns the corresponding heartbeat data packet within the preset time, Nacos-server considers that the service instance status is normal and the service instance is available.

[0052] If the service instance does not respond to the heartbeat request in time and return the corresponding heartbeat data packet, or the returned status code is not 100 (indicating that the service instance is online), Nacos-server will consider the service instance unhealthy or even unavailable (status failure), and will delete the service instance from its service list to maintain the real-time nature of the service instance.

[0053] In addition to the heartbeat mechanism, the Nacos system also supports custom health checkers. Users can configure health check rules in custom health checkers, including parameters such as health check type, check interval, check timeout, and number of checks. Health check logic can also be customized in custom health checkers, allowing service providers to verify their own health status through specified health check paths. For example, by calling a certain interface or sending a certain request, the health of the service instance can be checked.

[0054] Optionally, the above method further includes: The service list is read from the redis cache middleware regularly for permanent storage to form a basic service list; wherein, the basic service list is used to enable the consumer end to update the locally cached service list according to the basic service list in the event of a redis cache middleware failure.

[0055] In this implementation, after Nacos-server caches registered service instances in the Redis cache middleware, it continuously monitors the status of each service instance and updates the service list in Redis. Furthermore, Nacos-server periodically pulls the service list from the Redis cache middleware for permanent storage and stores the service information in a database (such as MySQL, an open-source relational database management system that uses SQL to store, retrieve, and manage data). This forms the basic service list, ensuring that data is ultimately stored on disk and preventing data loss due to Redis downtime.

[0056] Therefore, even if Redis crashes, Nacos-server can recover service information from persistent storage and re-update the service list through the heartbeat mechanism. Or, even if Redis is temporarily disconnected from Nacos-server, persistent storage still retains the last consistent state to prevent complete data loss.

[0057] Furthermore, when Redis fails, the Nacos-client is triggered to start a scheduled polling task, periodically pulling the latest service list from the Nacos-server to update the locally cached service list. Thus, by triggering scheduled polling to update the service list as a backup, we ensure that when the Redis service is unavailable, we will degrade to the original service capabilities of Nacos, without worrying about the consumer-side Nacos-client not being able to update service data. This ensures both the real-time and reliability of service updates.

[0058] It should be noted that in this application, the Nacos-client's scheduled polling function can be triggered only by detecting a Redis failure, or it can be always present. When the Nacos-client's scheduled polling function and the function of updating by listening to Redis expiration events coexist, if a service instance suddenly fails, the Nacos-client will first implement real-time updates to the service list by listening to Redis expiration events. When the Nacos-client then obtains the latest service list through scheduled polling, since this service list is the same as its locally updated service list, it does not need to be updated again. However, the scheduled polling function must still be retained to ensure that when the Redis service is unavailable, it degenerates to Nacos's original service capabilities.

[0059] This embodiment periodically synchronizes the service list in Redis to persistent storage (such as MySQL) to avoid data loss due to Redis downtime. Furthermore, compared to real-time persistent storage (which writes data to MySQL for each registration), periodic batch synchronization reduces disk I / O (write and read) pressure and is more suitable for large-scale instance registration scenarios.

[0060] Optionally, the above method further includes: When it is detected that multiple service instances are online or offline, a service update instruction is generated.

[0061] In this implementation, since some service instances have fixed online or offline times (for example, service instance 1 always goes offline at 8 p.m.), Nacos-server can directly generate service update instructions at a fixed time, allowing the Redis cache middleware to directly update the service list without having to wait for the service instance's status to be detected through heartbeat detection before generating service update instructions to update the service list. This allows the service list to be updated in real time based on the online or offline status of the service instance.

[0062] Specifically, you can deploy online and offline detection services on Nacos-server and run the corresponding detection scripts to detect the online or offline status of the service in real time.

[0063] Optionally, the above method further includes: In response to a registration request initiated by the server, the service instance is stored in the redis cache middleware; wherein, the registration request is initiated by the server when it performs a performance self-test on the service instance and passes the test.

[0064] like Figure 2 As shown, it is easy to understand that if the service instance to be registered itself has a fault (such as the dependent database is not started, the thread pool is exhausted, etc.), direct registration will result in: the service consumer fails to call the service instance, triggering an avalanche effect. At the same time, the Nacos-server registration center needs to maintain a large number of "zombie" instances, wasting resources.

[0065] Therefore, in this implementation, before the service provider on the server side initiates a service registration request to the Nacos-server through the Nacos-client, it will first perform a self-check on the relevant performance of the service instance, including whether the CPU or memory is overloaded, whether the database and cache are connected, whether the service instance has been properly bound to the port, etc.

[0066] If the self-test passes, the service provider on the server side initiates a service registration request to Nacos-server through Nacos-client.

[0067] After receiving the registration instance request, Nacos-server will encapsulate the IP, port number, service name, group name, cluster name and other data carried in the request into an Instance object, and then create a service for this service instance (there may be multiple service instances under a Service). After confirming that the service information is correct, it is stored in the redis cache middleware in hash format.

[0068] In this implementation, Nacos-client performs a self-check on the service instance before initiating service registration to ensure that all service instances registered with Nacos-server are available, thereby reducing the risk of cascading failures and preventing invalid or problematic instances from contaminating the service registration center, thereby ensuring the healthy operation of the entire microservice system.

[0069] Please refer to Figure 4 Based on the same inventive concept, a second aspect of an embodiment of the present application provides a service update method, which is applied to a consumer end in a microservice system with Nacos as a registration center. The microservice system includes a consumer end, a service end, and a Nacos system. The Nacos system is integrated with a redis cache middleware. The above method includes: S401: When an expiration event is detected, the locally cached service list is updated. The expiration event is generated when the Nacos system detects that a service instance in the multiple service instances provided by the server is in a faulty state. The system generates an update instruction for updating the service list cached in the redis cache middleware and updates the service list. The service list is composed of multiple service instances.

[0070] Optionally, when an expiration event is monitored, the locally cached service list is updated, including: when an expiration event is monitored, deleting a service instance with a fault status from the locally cached service list.

[0071] like Figure 2 As shown, in this embodiment, the Nacos system includes Nacos-server (server) and Nacos-client (client).

[0072] After the service provider on the server side requests service registration from Nacos-server via Nacos-client, Nacos-server caches the relevant information of each service instance in the Redis cache middleware to form a service list. Subsequently, Nacos-server will continuously monitor the status of each service instance to understand its health. If a service instance is detected as faulty, it indicates that the service instance is no longer available. A service update instruction is then generated to instruct the Redis cache middleware to remove the faulty service instance from the cached service list, thereby updating the service list. After the update is complete, Redis will initiate an expiration event for the faulty service instance.

[0073] The service consumer on the consumer side can monitor the expiration event of the faulty service instance through the Nacos-client and delete the faulty service instance from the locally cached service list to update the locally cached service list. The service consumer can then select a service instance from the service list to call based on its own strategy. For example, a polling strategy, a weighted polling strategy, or a shortest response time strategy can be used.

[0074] Therefore, by configuring monitoring on the consumer side, the original periodic polling logic of the consumer side is converted to active monitoring, so that the consumer side can promptly perceive the status changes of the service instance, and then promptly update the local cached service list to ensure the timeliness of service data, ultimately improving the availability of the Nacos service itself and providing service consumers with a better service experience.

[0075] Please refer to Figure 5 Based on the same inventive concept, the third aspect of the embodiment of the present application provides a microservice system for service update, which uses Nacos as the registration center. The microservice system includes a consumer end, a server end, and a Nacos system. The Nacos system is integrated with a redis cache middleware; wherein, The Nacos system is used to detect the status of multiple service instances provided by the server. When it detects that the status of any service instance is faulty, it generates an update instruction for updating the service list cached in the redis cache middleware and initiates an expiration event for the service instance in the faulty status after the update is completed. The service list consists of multiple service instances. The consumer side is used to update the locally cached service list when an expiration event is detected.

[0076] like Figure 2 As shown, in this embodiment, the Nacos system includes Nacos-server (server) and Nacos-client (client).

[0077] The service provider on the server side first performs a self-test on the performance of the service instance. If the self-test passes, it initiates a service registration request to Nacos-server through Nacos-client to register the metadata of the service instance it provides with Nacos-server for service consumers to call. The metadata of the service instance includes information such as the service name, instance address (IP and port), and health check path.

[0078] After receiving the service registration request, Nacos-server verifies the relevant information of the service instance and, after confirming that the service information is correct, stores the relevant information of each service instance in the Redis cache middleware in hash format to form a service list. At the same time, it also stores them in an internal data structure, that is, it will simultaneously save them to persistent storage (such as a database) to ensure high availability of the service instance. At this point, the service registration is completed.

[0079] After that, Nacos-server will continue to detect the status of each service instance to understand the health of the service instance. If it detects that the status of a service instance is faulty, it means that the service instance is no longer available. Then, a service update instruction is generated to instruct the redis cache middleware to remove the faulty service instance from the cached service list, thereby updating the service list.

[0080] After receiving the service update instruction sent by Nacos-server, the redis cache middleware will update the cached service list and initiate an expiration event for the service instance with a fault status to the consumer end after the update is completed.

[0081] The service consumer on the consumer side can monitor the expiration event of the faulty service instance through Nacos-client, delete the faulty service instance from the local cached service list to update the local cached service list. Then, the service consumer can select a service instance from the service list to call according to its own strategy.

[0082] Therefore, by combining the Nacos system with the Redis cache middleware and leveraging the expiration event capability of Redis, we configure monitoring on the consumer side to convert the original scheduled polling logic of the consumer side into active monitoring, so that the consumer side can promptly perceive the status changes of the service instance and then promptly update the local cached service list to ensure the timeliness of service data, ultimately improving the availability of the Nacos service itself and providing a better service experience for service consumers.

[0083] Please refer to Figure 6 Based on the same inventive concept, a fourth aspect of an embodiment of the present application provides a service update device, which is applied to a Nacos system in a microservice system with Nacos as a registration center. The microservice system includes a consumer end, a server end, and the Nacos system. The Nacos system is integrated with a Redis cache middleware. The service update device 600 includes: Status detection module 601, used to detect the status of multiple service instances provided by the server; The service update module 602 is used to generate an update instruction for updating the service list cached in the Redis cache middleware when it is detected that the status of any service instance is faulty, and initiate an expiration event for the service instance in the faulty status after the update is completed; the service list is composed of multiple service instances; The expiration event is used to enable the consumer to update the locally cached service list when it detects the expiration event.

[0084] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment in the first aspect.

[0085] Please refer to Figure 7 Based on the same inventive concept, a fifth aspect of an embodiment of the present application provides a service update device, which is applied to a consumer end in a microservice system with Nacos as a registration center. The microservice system includes a consumer end, a service end, and a Nacos system. The Nacos system is integrated with a redis cache middleware. The service update device 700 includes: The monitoring and updating module 701 is used to update the service list of the local cache when an expiration event initiated by the redis cache middleware is monitored; Among them, the expiration event is generated when the Nacos system detects that there is a service instance in the fault state among the multiple service instances provided by the server. It generates an update instruction for updating the service list cached in the redis cache middleware and updates the service list; the service list is composed of multiple service instances.

[0086] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment in the second aspect.

[0087] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0088] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0090] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0091] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0092] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic inventive concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0093] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0094] The above is a detailed introduction to a service update method, device and microservice system provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.< / db> < / event> < / db>

Claims

1. A service update method, characterized in that: The method is applied to a Nacos system in a microservice system using Nacos as a registration center, wherein the microservice system includes a consumer end, a server end, and a Nacos system, and the Nacos system is integrated with a redis cache middleware; the method includes: Detecting the status of multiple service instances provided by the server; When it is detected that the status of any service instance is faulty, an update instruction for updating the service list cached in the redis cache middleware is generated; the service list is composed of the multiple service instances; After the update is complete, an expiration event is initiated for the service instance with a fault status; The expiration event is used to enable the consumer to update the locally cached service list when the consumer monitors the expiration event.

2. The method according to claim 1, characterized in that The method further comprises: Sending heartbeat requests to the multiple service instances at preset time intervals; Determine the status of a service instance that receives a heartbeat request response within a preset time as normal; The status of a service instance that has not received a response to a heartbeat request within a preset time is determined to be faulty.

3. The method according to claim 1, characterized in that The method further comprises: Regularly read the service list from the redis cache middleware for permanent storage to form a basic service list; The basic service list is used to enable the consumer end to update the locally cached service list according to the basic service list when the redis cache middleware fails.

4. The method according to claim 1, wherein The method further comprises: When it is detected that any of the multiple service instances are online or offline, the service update instruction is generated.

5. The method according to claim 1, characterized in that When it is detected that the status of any service instance is faulty, after generating an update instruction for updating the service list cached in the redis cache middleware, the method further includes: Based on the update instruction, detecting whether an expiration event has been initiated for the service instance in the fault state; If no expiration event has been initiated, the cached service list is updated according to the service update instruction.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: In response to the registration request initiated by the server, the service instance is stored in the redis cache middleware; The registration request is initiated by the server when it performs a performance self-test on the service instance and the server passes the test.

7. A service update method, characterized in that: The method is applied to a consumer end in a microservice system using Nacos as a registration center. The microservice system includes a consumer end, a service end, and a Nacos system. The Nacos system is integrated with a redis cache middleware. The method includes: When an expiration event is detected, the locally cached service list is updated; Among them, the expiration event is generated when the Nacos system detects that there is a service instance in a faulty state among the multiple service instances provided by the server, generates an update instruction for updating the service list cached in the redis cache middleware, and updates the service list; the service list is composed of the multiple service instances.

8. The method according to claim 7, characterized in that When the expiration event is detected, the locally cached service list is updated, including: When the expiration event is monitored, the service instance in the fault state is deleted from the service list in the local cache.

9. A microservice system for service update, characterized in that: The microservice system uses Nacos as the registration center. The microservice system includes a consumer end, a server end, and a Nacos system. The Nacos system is integrated with a redis cache middleware. The Nacos system is configured to detect the status of multiple service instances provided by the server, and when detecting that the status of any service instance is faulty, generate an update instruction for updating the service list cached in the redis cache middleware, and initiate an expiration event for the service instance in the faulty status after the update is completed; the service list is composed of the multiple service instances; The consumer end is used to update the locally cached service list when monitoring the expiration event.

10. A service updating device, characterized in that: The device is applied to a Nacos system in a microservice system using Nacos as a registration center. The microservice system includes a consumer end, a server end, and a Nacos system. The Nacos system is integrated with a redis cache middleware. The device includes: A status detection module, used to detect the status of multiple service instances provided by the server; A service update module is configured to generate an update instruction for updating a service list cached in the Redis cache middleware when detecting that any service instance is in a faulty state, and initiate an expiration event for the service instance in a faulty state after the update is completed; the service list is composed of the multiple service instances; The expiration event is used to enable the consumer to update the locally cached service list when the consumer monitors the expiration event.

Images