Method and system for micro-service lossless on and off line

Abstract

The application provides a method for lossless on-off of microservices, which comprises the following steps: S1, the microservice off-line takes the initiative to inform all clients that the current microservice is preparing to off-line, and the clients remove the service instance from the local routing table; S2, the microservice off-line waits for all current traffics to be processed before closing the service; S3, the microservice on-line takes the delay registration, the microservice waits for the required resource to be loaded when initializing, detects the resource availability, and registers the microservice to the registration center after everything is ready; S4, the client reads the available service instance information from the registration center, updates to the local routing table, and sets the newly added service instance information as the detection state; and S5, the client selects one service instance from the local routing table for calling each time, so as to solve the problem that the on-off of high-concurrency and large-flow service may cause the loss of traffic.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer communication, in particular to a method and system for lossless on and off of microservices. BACKGROUND

[0002] A microservice system reads available service instances through a service registry center for calling. Before a service is updated and put online, although a series of perfect function tests are conducted, in a high concurrency and large traffic scenario, if the service is directly killed and a new service is put online, the problem of loss of traffic request in a short time may occur. This situation may occur when the service is offline, but due to the delay problem of the registry center, the client does not perceive it, and continues to call the offline service in a short time; it may also occur when the service is online and the related resources are not completely loaded, that is, it is in an unusable state, and it has been registered to the registry center, causing the client to prematurely request traffic, thereby causing an error.

[0003] The microservice wiki defines it as: a software development technique - a variant of the service-oriented architecture (SOA) architectural style, which advocates dividing a single application into a group of small services, which coordinate and cooperate with each other to provide the final value for users. Each service runs in its own process, and services communicate with each other using a lightweight communication mechanism. Each service is built around a specific business and can be independently deployed to a production environment, a production-like environment, etc. In addition, a unified and centralized service management mechanism should be avoided, and for a specific service, a suitable language and tool should be selected according to the context to build it. SUMMARY

[0004] To overcome the above problems, the purpose of the present application is to provide a method for lossless on and off of microservices, which can solve the problem that high concurrency and large traffic may cause loss of service on and off.

[0005] The present application adopts the following scheme: a method for lossless on and off of microservices, the method comprising the following steps:

[0006] Step S1, the microservice takes the initiative to notify when it is offline, notifies all clients that the current microservice is preparing to be offline, and the client removes the service instance from the local routing table;

[0007] Step S2, the microservice takes the initiative to notify when it is offline, notifies all clients that the current microservice is preparing to be offline, and the client removes the service instance from the local routing table;

[0008] Step S3, the microservice takes the initiative to notify when it is offline, notifies all clients that the current microservice is preparing to be offline, and the client removes the service instance from the local routing table;

[0009] Step S4, the client reads the available service instance information from the registration center, updates to the local routing table, and sets the newly added service instance information to the detection state;

[0010] Step S5, the client selects a service instance from the local routing table for each request, and if the service in the detection state is called, it is judged whether the service in the detection state is available. If available, the detection state mark is deleted. If not available, the service instance in the local routing table without the detection state mark is called.

[0011] Further, the step S1 is further specific: the micro services in the system all need to implement a service offline notification interface. When the service is offline, the client is actively notified to obtain other online clients from the registration center for notification. The client removes the service instance in the local routing table after receiving the service offline notification, and will not call the offline micro service in the future. The local routing table is a service instance storage set in the memory.

[0012] Further, the step S2 is further specific: after the service notifies the client to be offline, it is judged whether all the pending requests in the current service have been completed. If not, it waits. If all the requests are completed, it is offline.

[0013] Further, the step S3 is further specific: the associated resources need to be loaded in the process of initializing the micro service, including the connection of mysql, redis, middleware or downstream service. When the micro service is successfully offline, the update of the new service, that is, the process of the micro service online, adopts a delay registration mechanism. In the initialization process, only when all the resources are successfully loaded, the resource availability is detected, and after everything is ready, the micro service is registered to the registration center.

[0014] Further, the step S4 is further specific: the client will pull the available service instance information from the registration center every minute, and update to the local routing table. Before updating the local routing table, it will be compared first. If there is a new service instance, the newly added service instance is marked as a detection state, that is, the status of the service instance is 0.

[0015] Further, the step S5 is further specific: before the client requests the service, a service instance needs to be selected from the routing table for calling. However, there is a new service in the detection state, so 5% of the traffic needs to be released to detect whether the service is available. Releasing 5% of the traffic to detect the service is to take a random number of 1-100. If the random number is greater than 5, the service instance in the local routing table without the detection state mark is called. If the random number is less than or equal to 5, the service in the detection state is called.

[0016] The application also provides a system for lossless on and off of microservices, which comprises an offline notification module, an offline service closing module, a service registration module, a reading and updating module, and a calling module.

[0017] The offline notification module initiatively notifies all clients that the current microservice is preparing to be offline when the microservice is offline, and the clients remove the service instance from the local routing table.

[0018] The offline service closing module closes the service after waiting for all current traffics to be processed when the microservice is offline.

[0019] The service registration module adopts a delayed registration when the microservice is online, and the microservice is registered to the registration center after waiting for all resources to be loaded, detecting the availability of the resources, and waiting for everything to be ready during the initialization of the microservice.

[0020] The reading and updating module reads the available service instance information from the registration center, updates to the local routing table, and sets the newly added service instance information as a detection state.

[0021] The calling module selects a service instance from the local routing table for calling each time the client requests, and if the service in the detection state is called, it is judged whether the service in the detection state is available, and if yes, the detection state mark is deleted, and if not, the service instance in the local routing table without the detection state mark is called.

[0022] Further, the offline notification module is further specific to the following: all microservices in the system need to implement a service offline notification interface, and the service offline initiatively notifies the clients to get other online clients from the registration center for notification, and the clients remove the service instance in the local routing table after receiving the service offline notification, and the offline microservice will not be called in the future, and the local routing table is a service instance storage set in the memory.

[0023] Further, the offline service closing module is further specific to the following: after the service notifies the clients that it is going to be offline, it is judged whether all the requests in the current service are completed, and if not, it is waited, and if yes, it is offline.

[0024] Further, the service registration module is further specific to the following: the associated resources need to be loaded during the initialization of the microservice, the associated resources include the connection of mysql, redis, the connection of middleware or the connection of downstream services, and after the microservice is successfully offline, the update of the new service, that is, the process of the microservice being online, adopts a delayed registration mechanism, and only after all the resources are successfully loaded, the availability of the resources is detected, and everything is ready, the microservice is registered to the registration center.

[0025] Further, the reading updating module is further specific to that the client pulls the instance information of the available service from the registration center every minute, and updates to the local routing table, and before updating the local routing table, comparison is performed first, and if there is a newly added service instance, the newly added service instance is marked as a detection state, that is, the status of the service instance = 0.

[0026] Further, the calling module is further specific to that before the client requests the service, a service instance needs to be selected from the routing table for calling, but due to the existence of the new service in the detection state, 5% of the traffic needs to be released to detect whether the service is available, and the release of 5% of the traffic to detect the service is specific to taking a random number of 1-100, if the random number is greater than 5, the service instance in the local routing table which is not marked as the detection state is called, and if the random number is less than or equal to 5, the service in the detection state is called.

[0027] The application has the beneficial effects that the application processes the online and offline of the micro service, realizes lossless updating of the service, and can solve the problem that the online and offline of the high-concurrency and high-traffic service may cause loss of traffic. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 is a method flowchart of the application.

[0029] Figure 2 is a system principle block diagram of the application. DETAILED DESCRIPTION

[0030] The application will be further described below in combination with the drawings.

[0031] Please refer to Figure 1 The application provides a method for lossless online and offline of micro service, and the method comprises the following steps:

[0032] Step S1, the micro service offline adopts active notification, notifies all clients that the current micro service is ready to be offline, and the client removes the service instance from the local routing table;

[0033] Step S2, the micro service offline adopts waiting for all current traffic to be processed before closing the service;

[0034] Step S3, the micro service online adopts delayed registration, the micro service waits for the required resources to be loaded when initializing, detects the availability of the resources, and after everything is ready, the micro service is registered to the registration center;

[0035] Step S4, the client reads the available service instance information from the registration center, updates to the local routing table, and sets the newly added service instance information as the detection state;

[0036] Step S5, the client selects a service instance from the local routing table each time to make a call, if the service in the detection state is called, it is judged whether the service in the detection state is available, if available, the detection state mark is deleted, and if unavailable, the service instance in the local routing table without the detection state mark is called.

[0037] The application will be further described in combination with a specific embodiment:

[0038] The application provides a method for lossless on and off of microservices.

[0039] Step one, the service off-line takes the initiative to inform, informs other clients that the current service is preparing to off-line, and the client removes the instance from the local routing table.

[0040] The client perceives the service list existing delay from the registration center, which may cause the client to still call the off-line service in a short period of time after the service instance off-line, thereby causing the call to fail.

[0041] The microservices in the system all need to implement the service off-line notification interface, and the service off-line takes the initiative to inform the client, obtains other online clients from the registration center to inform, and the client removes the service instance in the local routing table after receiving the service off-line notification, and will not call the off-line service in the future. The local routing table is a service instance storage set in the memory, and stores the following information [{‘name’:‘user.server’,‘ip’:‘192.168.1.1’,‘status’:1},{‘name’:‘user.server’,‘ip’:‘192.168.1.2’,‘status’:1}]

[0042] Step two, the service off-line takes adaptive waiting, waits until the current traffic is processed, and then closes the service.

[0043] Although the client has been actively informed that the service has off-line in step one, in the case of large traffic, even if the client removes the service instance in the local routing table, there may still be some requests waiting for the off-line service to process and return data. If the service directly off-line at this time, these requests cannot be normally responded.

[0044] After the service informs the client that it will off-line, it is judged whether all the pending requests in the current service have been completed, if not, it is waited, and if all the requests are completed, it is off-line, that is, adaptive waiting.

[0045] Step three, the service on-line takes delay registration, the service initializes to wait for the required resources to be loaded, detects the availability of the resources, and registers to the registration center after waiting for everything to be ready.

[0046] The process of service initialization needs to load associated resources, such as the connection of mysql, redis, the connection of other middleware or downstream services and the like, so that the initialization process may be relatively slow compared with a normal request, and the service is registered to the registration center before the initialization of the resources is completed, which may cause the client to request traffic too early, thereby causing errors.

[0047] Therefore, when the service is successfully offline, the updating of the new service, that is, the process of service online, adopts a delay registration mechanism, and only when the resources are successfully loaded in the initialization process, the service is registered to the registration center.

[0048] Step four, the client reads the available service instance information from the registration center, updates to the local routing table, and sets the newly added service instance information to the detection state.

[0049] The client pulls the available service instance information from the registration center every minute, and updates to the local routing table, that is, exists in the memory. Before updating the local routing table, comparison is performed first, and if there is a newly added service instance, the newly added service instance is set to the detection state, that is, status = 0. For the online of the new service, although multiple rounds of tests are performed, in order to avoid unknown problems of the new service during the online period, a small part of traffic detection is adopted in the calling of the new service.

[0050] Step five, the client releases 5% of the traffic to the service in the detection state before each request for service, and if the service in the detection state is available, the detection state is deleted.

[0051] Before the client requests the service, a service instance needs to be selected from the routing table for calling, but since there may be a new service in the detection state, 5% of the traffic needs to be released to detect whether the service is available, and the specific method is that a random number of 1-100 is generated, if the random result is greater than 5, other normal services are called, and if the number is less than or equal to 5, the detection service is called. And record the service request result, if the success is accumulated for 5 times continuously, the detection state of the new service is deleted, and the service instance not marked with the detection state is requested normally. If the new service fails to be called during the detection stage, manual intervention is needed to troubleshoot the new service. That is, 5% and 95% of the probability of calling services in different states, 5% of the traffic to call the service in the detection state, and 95% of the traffic to call the service not marked with the detection state.

[0052] Please refer to Figure 2 The application also provides a micro-service lossless online and offline system, which comprises an offline notification module, an offline service closing module, a service registration module, a reading and updating module, and a calling module.

[0053] The offline notification module initiatively notifies all clients that the current microservice is preparing to go offline when the microservice goes offline, and the clients remove the service instance from the local routing table.

[0054] The offline notification module is further specifically that the microservices in the system all need to implement a service offline notification interface, and the service goes offline initiatively notifies the clients, obtains other online clients from the registration center to perform notification, and the clients remove the service instance in the local routing table after receiving the service offline notification, and will not call the offline microservice in the future. The local routing table is a service instance storage set in the memory.

[0055] The offline service closing module waits for all the current traffic to be processed before closing the service when the microservice goes offline.

[0056] The offline service closing module is further specifically that after the service notifies the clients that it is going offline, it is determined whether all the pending requests in the current service have been completed, and if not, it waits, and if all the requests have been completed, it goes offline.

[0057] The service registration module initiatively registers with a delay when the microservice goes online, waits for the required resources to be loaded, detects resource availability, and registers the microservice to the registration center after everything is ready.

[0058] The service registration module is further specifically that the associated resources need to be loaded during the initialization of the microservice, the associated resources include the connections of mysql, redis, middleware or downstream services, and when the microservice successfully goes offline, the update of the new service, that is, the process of the microservice going online, initiatively adopts a delay registration mechanism. Only when all the resources are successfully loaded during the initialization process, the resource availability is detected, and everything is ready, the microservice is registered to the registration center.

[0059] The reading and updating module reads the available service instance information from the registration center, updates to the local routing table, and sets the newly added service instance information to the detection state.

[0060] The reading and updating module is further specifically that the client pulls the available service instance information from the registration center every minute, and updates to the local routing table. Before updating the local routing table, it is compared first. If there is a new service instance, the newly added service instance is set to the detection state mark, that is, the status of the service instance = 0.

[0061] The calling module selects one service instance from the local routing table for calling each time the client requests, and if the service in the probe state is called, it is judged whether the service in the probe state is available, if available, the probe state mark is deleted, and if unavailable, the service instance in the local routing table which is not marked with the probe state is called.

[0062] The calling module is further specifically that before the client requests the service, one service instance needs to be selected from the routing table for calling, but since there is a new service in the probe state, 5% of the traffic needs to be released to probe whether the service is available, and the 5% of the traffic to probe the service is specifically that a random number of 1-100 is taken, if the random number is greater than 5, the service instance in the local routing table which is not marked with the probe state is called, and if the random number is less than or equal to 5, the service in the probe state is called.

[0063] In summary, the microservice online and offline are processed, so that the service realizes lossless update, and the problem that the online and offline of the high-concurrency and high-traffic service may cause loss of traffic can be solved.

[0064] The above only describes the preferred embodiments of the present application, and any changes and modifications made within the scope of the present application should be included in the scope of the present application.

Claims

1. A method for seamless online / offline deployment of microservices, characterized in that: The method includes the following steps: Step S1: When a microservice goes offline, an active notification is made to all clients that the current microservice is about to go offline, and the client removes the service instance from its local routing table. Step S2: When taking a microservice offline, wait until all current traffic has been processed before shutting down the service. Step S3: Microservices are launched with delayed registration. When a microservice is initialized, it waits for the required resources to be loaded, checks the availability of resources, and registers the microservice to the registry center after everything is ready. Step S4: The client reads the available service instance information from the registry center, updates the local routing table, and sets the newly added service instance information to the probe state. Step S4 is further specified as follows: The client will periodically pull the instance information of available services from the registration center every minute and update the local routing table. Before updating the local routing table, a comparison will be performed. If there are newly added service instances, the newly added service instances will be set as probe status flags, that is, the service instance status=0. Step S5: Each time the client makes a request, it selects a service instance from the local routing table for invocation. If a service in the probe state is invoked, it is determined whether the service in the probe state is available. If it is available, the probe state mark is removed. If it is unavailable, the service instance in the local routing table that is not marked in the probe state is invoked. Step S5 is further specified as follows: Before the client requests a service, it needs to select a service instance from the routing table for invocation. However, since there is a new service in the probe state, 5% of the traffic needs to be released to probe whether the service is available. Specifically, releasing 5% of the traffic to probe the service involves taking a random number between 1 and 100. If the random number is greater than 5, the service instance in the local routing table that is not marked as being in the probe state is invoked. If the random number is less than or equal to 5, the service in the probe state is invoked. The service request result is recorded. If the invocation is successful for 5 consecutive times, the probe state of the new service is deleted. Subsequently, the client will request the service instance that is not marked as being in the probe state.

2. The method for seamless online / offline registration and deactivation of microservices according to claim 1, characterized in that: Step S1 is further specified as follows: all microservices in the system need to implement the service offline notification interface. When a service goes offline, it actively notifies the client by obtaining other online clients from the registry center. After receiving the service offline notification, the client removes the service instance from the local routing table and will no longer call the offline microservice. The local routing table is a set of service instances stored in memory.

3. The method for seamless online / offline registration and deactivation of microservices according to claim 1, characterized in that: Step S2 is further specified as follows: after the service notifies the client that it is going offline, it counts whether all pending requests in the current service have been completed. If not, it waits; if all requests have been completed, it goes offline.

4. The method for seamless online / offline registration and deactivation of microservices according to claim 1, characterized in that: Step S3 is further specified as follows: During the microservice initialization process, it is necessary to load associated resources, including: MySQL and Redis connections, middleware connections, or downstream service connections. When the microservice is successfully taken offline, the update of the new service, that is, the microservice going online, adopts a delayed registration mechanism. During the initialization process, only after all resources have been successfully loaded, resource availability is checked, and everything is ready, will the microservice be registered to the registry center.

5. A system for seamless online / offline operation of microservices, characterized in that: The system includes: an offline notification module, an offline service shutdown module, a service registration module, a read update module, and a call module; The offline notification module actively notifies all clients that the current microservice is about to be offline when a microservice is offline, and the client removes the service instance from its local routing table. The offline service shutdown module, when a microservice is taken offline, waits until all current traffic is processed before shutting down the service; The service registration module implements delayed registration for microservices. During microservice initialization, it waits for the required resources to be loaded, checks resource availability, and registers the microservice to the registration center after everything is ready. The read update module reads available service instance information from the registry center on the client side, updates the local routing table, and sets the information of newly added service instances to the probe state. The read update module is further specified as follows: the client will periodically pull the instance information of available services from the registry center every minute and update the local routing table. Before updating the local routing table, a comparison will be performed. If there are any newly added service instances, the newly added service instances will be set as probe status flags, that is, the service instance status=0. The calling module selects a service instance from the local routing table for each client request. If a service in the probe state is called, it determines whether the service in the probe state is available. If it is available, the probe state mark is removed. If it is unavailable, the service instance in the local routing table that is not marked in the probe state is called. The calling module is further specified as follows: Before the client requests a service, it needs to select a service instance from the routing table for invocation. However, since there is a new service in the probe state, it needs to release 5% of the traffic to probe whether the service is available. Specifically, releasing 5% of the traffic to probe the service involves taking a random number between 1 and 100. If the random number is greater than 5, the service instance in the local routing table that is not marked as being in the probe state is called. If the random number is less than or equal to 5, the service in the probe state is called. The service request result is recorded. If the new service is successfully invoked 5 times in a row, the probe state of the new service is deleted. Subsequently, the client will request the service instance that is not marked as being in the probe state.

6. A system for seamless microservice online / offline operation according to claim 5, characterized in that: The offline notification module is further specified as follows: all microservices in the system need to implement the service offline notification interface. When a service goes offline, it actively notifies the client by obtaining other online clients from the registry center. After receiving the service offline notification, the client removes the service instance from its local routing table and will no longer call the offline microservice. The local routing table is a set of service instances stored in memory.

7. A system for seamless microservice online / offline operation according to claim 5, characterized in that: The offline service shutdown module is further specified as follows: after the service notifies the client that it is going offline, it counts whether all pending requests in the current service have been completed. If not, it waits; if all requests have been completed, it goes offline.

8. A system for seamless microservice online / offline operation according to claim 5, characterized in that: The service registration module is further specified as follows: During the microservice initialization process, it is necessary to load associated resources, including: MySQL and Redis connections, middleware connections, or downstream service connections. When the microservice is successfully taken offline, the update of the new service, that is, the microservice going online, adopts a delayed registration mechanism. During the initialization process, only after all resources have been successfully loaded, resource availability is checked, and everything is ready, will the microservice be registered to the registry center.

Images