Method and system for stopping and restoring microservice applications

Abstract

The present invention discloses a method and system for stopping and resuming a microservice application, which belongs to the field of microservice management technology. The technical problem to be solved is how to stop and resume a microservice application without terminating an application example in a pod. The microservice application is terminated by the following steps: S100, detecting the microservice through a set microservice stop detection rule; S200, terminating the microservice application through a unique string generation algorithm; S300, detecting the microservice application based on the microservice stop detection rule, if the microservice application is not terminated, executing steps S100-S300 until the microservice has been terminated; detecting the terminated microservice through a preconfigured microservice recovery detection rule; and restoring the microservice application through a microservice recovery rule.

Description

Technical Field

[0001] The present invention relates to the field of microservice management technology, and in particular to a method and system for stopping and restoring a microservice application. Background Art

[0002] After entering the era of cloud computing, many enterprise-level applications have shifted from monolithic architecture to microservice architecture, and are deployed and delivered with cloud-native microservice architecture. Kubernetes is an open source container orchestration engine that supports automated deployment, large-scale scalability, and application container management. With the development of containerization technology and Kubernetes technology, more and more Internet companies choose to use Kubernetes to manage and orchestrate microservice applications. Microservice applications generally run in pods in Kubernetes, and microservices provide external applications through Kubernetes Services. Endpoints are usually used to record the access address of a pod corresponding to a service. Endpoint is a resource object in Kubernetes and is stored in etcd.

[0003] For microservice developers, using Kubernetes to manage and debug microservice applications and stop and resume requires learning the technical knowledge and principles of Kubernetes Service, pod, etc. This increases the cost of developers in the process of debugging microservice applications, and Kubernetes itself does not provide instructions for stopping and resuming microservice applications similar to using kubectl commands. If you need to stop a microservice application, you generally need to stop the corresponding pod, and then restart the pod when you want to resume it. This operation through instructions is prone to errors and exceptions, and the restart and scheduling of pods will also increase the pressure on the server.

[0004] How to stop and resume microservice applications without terminating the application examples in the pod, avoiding the rescheduling and restarting of the pod, and thus avoiding abnormal problems during the operation is a technical problem that needs to be solved. Summary of the invention

[0005] The technical task of the present invention is to address the above shortcomings and provide a method and system for stopping and recovering a microservice application to solve the technical problem of how to stop and recover a microservice application without terminating the application example in the pod.

[0006] In a first aspect, a method for stopping and restoring a microservice application of the present invention, for a microservice application in Kubernetes, stops the microservice application by the following steps:

[0007] S100, based on the microservice name specified in the microservice stop instruction, the microservice is detected by a preconfigured microservice stop detection rule, where the microservice stop detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod;

[0008] S200, for a microservice application that meets the microservice stop detection rule, terminating the microservice application by using a unique string generation algorithm;

[0009] S300, for the microservice application terminated in step S200, detect the microservice through the pre-configured microservice stop detection rule to determine whether the microservice application has been terminated. If the microservice application has not been terminated, execute steps S100-S300 until the microservice has been terminated;

[0010] For microservice applications that have been terminated in Kubernetes, execute the recovery instructions and perform the following recovery operations:

[0011] Based on the microservice name specified in the microservice stop instruction, the terminated microservice is detected by a preconfigured microservice recovery detection rule, wherein the microservice recovery detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod;

[0012] For microservice applications that meet the microservice recovery detection rules, the microservice applications are restored using the microservice recovery rules, which are used to find the corresponding service resources in Kubernetes and restore the association between the Service and the pod.

[0013] Preferably, the microservice name corresponds to the name of the service in Kubernetes;

[0014] Step S100 detects the microservice application based on the preconfigured microservice stop detection rule, including the following steps:

[0015] Determine whether the corresponding service resources can be found in Kubernetes;

[0016] If it does not exist, return an error directly;

[0017] If it exists, further query whether the content of the endpoint field in the Service is the none field. If it is, it means that the current Service is not associated with a pod application, and the microservice application can no longer provide work to the outside world, that is, it does not meet the microservice stop detection rules. Otherwise, it meets the microservice stop detection rules.

[0018] Preferably, step S200 terminates the microservice application by using a unique string generation algorithm, comprising the following steps:

[0019] Generate the current system timestamp currentTimeMillis through the system function;

[0020] Encrypt app-name+currentTimeMillis through the string encryption function to generate an encrypted string greater than 12 digits;

[0021] Take out the first 6 digits and the last 6 digits of the encrypted string respectively and combine them into a new string cipher;

[0022] Find the corresponding service in Kubernetes and replace the value of the app field under the selector in the service with app-name-cipher.

[0023] Preferably, step S300 detects the microservice by using a preconfigured microservice stop detection rule, comprising the following steps:

[0024] According to the name of the microservice to be detected, check whether the endpoint field content in the corresponding Kubernetes service is the none field. If it is, it means that the current Service is not associated with a pod application and the microservice application has been successfully terminated. If not, it means that the microservice application has not been successfully terminated.

[0025] As a preferred method, for microservice applications that have been terminated in Kubernetes, there are two ways to execute recovery instructions, namely, manually enter the execution instructions and automatically execute the instructions based on the restart time;

[0026] If the microservice stop instruction specifies a restart time for the microservice application to be restored, the stopped microservice application is automatically restored based on the restart time;

[0027] If the restart time for restoring the microservice application is not specified in the microservice stop instruction, the stopped microservice application is restored by manually inputting instructions.

[0028] Preferably, detecting the suspended microservice application based on a preconfigured microservice recovery detection rule comprises the following steps:

[0029] Find the corresponding service resources in Kubernetes;

[0030] If it does not exist, return an error directly;

[0031] If it exists, check whether the content of the endpoint field in the Service is the none field;

[0032] If so, find the corresponding service from Kubernetes and determine whether the value length of the app field under the selector in the service is greater than 14, and whether the 13th last character string in the app field is "-". If so, it means that the current microservice meets the microservice recovery detection rules and can be restored. Otherwise, it means that the current microservice does not meet the microservice recovery detection rules and cannot be restored.

[0033] Preferably, the microservice application is restored by using a preconfigured microservice recovery rule, comprising the following steps:

[0034] According to the microservice name specified in the microservice stop instruction, find the corresponding service in Kubernetes, find out that the value of the app field under the selector in the Service is app-name, remove the last 13 digits of the app-name value, generate a new app-new-name string, and use app-new-name instead of app-name.

[0035] In a second aspect, a microservice application stopping and recovering system of the present invention is used to stop and recover a microservice application by using a microservice application stopping and recovering method as described in any one of the first aspects, and the system includes:

[0036] Kubernetes console, where the Kubernetes console is used to input a microservice stop instruction, where the microservice stop instruction at least includes a microservice name;

[0037] A stop detection module, which is used to detect the microservice based on the microservice name specified in the microservice stop instruction through a preconfigured microservice stop detection rule, and the microservice stop detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod;

[0038] A stop execution module, for a microservice application that meets the microservice stop detection rule, the stop execution module is used to stop the microservice application through a unique string generation algorithm;

[0039] A stop confirmation module, for a microservice application stopped by the stop execution module, the stop confirmation module is used to detect the microservice through a pre-configured microservice stop detection rule, and if the microservice application is not stopped, the stop detection module and the stop execution module are called to stop the microservice application again, and the microservice is detected again through the pre-configured microservice stop detection rule until the microservice is stopped;

[0040] A recovery detection module, which is used to detect the terminated microservice based on the microservice name specified in the microservice stop instruction through a preconfigured microservice recovery detection rule, wherein the microservice recovery detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod;

[0041] A recovery execution module, for a microservice application that meets the microservice recovery detection rule, the recovery execution module is used to recover the microservice application through the microservice recovery rule, and the microservice recovery rule is used to find the corresponding service resource from Kubernetes and restore the association relationship between the Service and the pod;

[0042] A recovery mode confirmation module, for microservice applications that have been terminated in Kubernetes, is configured with two modes of executing recovery instructions, namely, manually inputting execution instructions and automatically executing instructions based on restart time;

[0043] The recovery mode confirmation module is used to select a mode for executing the recovery instruction in the following manner: if the microservice stop instruction specifies a restart time for the recovery of the microservice application, the recovery operation is automatically performed on the suspended microservice application based on the restart time; if the microservice stop instruction does not specify a restart time for the recovery of the microservice application, the recovery operation is performed on the suspended microservice application by manually inputting instructions.

[0044] Preferably, the microservice name corresponds to the name of the service in Kubernetes;

[0045] The stop detection module is used to detect the microservice application based on the preconfigured microservice stop detection rule through the following steps:

[0046] Determine whether the corresponding service resources can be found in Kubernetes;

[0047] If it does not exist, return an error directly;

[0048] If it exists, further query whether the content of the endpoint field in the Service is the none field. If it is, it means that the current Service is not associated with a pod application, and the microservice application can no longer provide work to the outside world, that is, it does not meet the microservice stop detection rule. Otherwise, it meets the microservice stop detection rule;

[0049] The stop execution module is used to terminate the microservice application through a unique string generation algorithm through the following steps:

[0050] Generate the current system timestamp currentTimeMillis through the system function;

[0051] Encrypt app-name+currentTimeMillis through the string encryption function to generate an encrypted string greater than 12 digits;

[0052] Take out the first 6 digits and the last 6 digits of the encrypted string respectively and combine them into a new string cipher;

[0053] Find the corresponding service in Kubernetes and replace the value of the app field under the selector in the service with app-name-cipher;

[0054] The stop confirmation module is used to determine whether the microservice application has been terminated through the following steps:

[0055] According to the name of the microservice to be detected, check whether the content of the endpoint field in the corresponding Kubernetes service is the none field. If it is, it means that the current Service is not associated with a pod application and the microservice application has been successfully terminated. If not, it means that the microservice application has not been successfully terminated.

[0056] Preferably, the recovery detection module is used to detect the suspended microservice application based on a preconfigured microservice recovery detection rule through the following steps:

[0057] Find the corresponding service resources in Kubernetes;

[0058] If it does not exist, return an error directly;

[0059] If it exists, check whether the content of the endpoint field in the Service is the none field;

[0060] If yes, find the corresponding service in Kubernetes and determine whether the value length of the app field under the selector in the service is greater than 14, and whether the 13th last character string in the app field is "-". If yes, it means that the current microservice meets the microservice recovery detection rules and can be restored. Otherwise, it means that the current microservice does not meet the microservice recovery detection rules and cannot be restored.

[0061] The recovery execution module is used to recover the microservice application based on the preconfigured microservice recovery rules through the following steps:

[0062] According to the microservice name specified in the microservice stop instruction, find the corresponding service in Kubernetes, find out that the value of the app field under the selector in the Service is app-name, remove the last 13 digits of the app-name value, generate a new app-new-name string, and use app-new-name instead of app-name.

[0063] The method and system for stopping and restoring microservice applications of the present invention have the following advantages:

[0064] 1. By interrupting and restoring the relationship between Service and pod in Kubernetes, the microservice application in Kubernetes can be stopped and restored, which simplifies the process of stopping and restoring microservice applications in Kubernetes. In addition, during the process of stopping and restoring microservice applications in Kubernetes, no new pod restart and scheduling will occur, which greatly saves the cost of resource scheduling in Kubernetes.

[0065] 2. It provides the function of delayed recovery of microservice applications in Kubernetes, solving the problem of complex stop and recovery operations for microservice developers when debugging and developing microservice applications in Kubernetes. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 creative work.

[0067] The present invention is further described below in conjunction with the accompanying drawings.

[0068] Figure 1 This is a flowchart of stopping in the microservice application stopping and restoring method in Example 1;

[0069] Figure 2 This is a flowchart of recovery in the microservice application stop and recovery method in Example 1. DETAILED DESCRIPTION

[0070] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments may be combined with each other.

[0071] The embodiments of the present invention provide a method and system for stopping and restoring a microservice application, which are used to solve the technical problem of how to stop and restore a microservice application without terminating an application instance in a pod.

[0072] Embodiment 1:

[0073] The present invention discloses a method for stopping and restoring a microservice application, which realizes stopping and restoring the service of the microservice application in Kubernetes by interrupting and restoring the association relationship between Service and pod in Kubernetes.

[0074] For microservice applications in Kubernetes, terminate the microservice applications by following the steps below:

[0075] S100, based on the microservice name specified in the microservice stop instruction, the microservice is detected by a preconfigured microservice stop detection rule, where the microservice stop detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod;

[0076] S200, for a microservice application that meets the microservice stop detection rule, terminating the microservice application by using a unique string generation algorithm;

[0077] S300 detects the microservice application terminated by step S200 through a preconfigured microservice stop detection rule to determine whether the microservice application has been terminated. If the microservice application has not been terminated, steps S100-S300 are executed until the microservice has been terminated.

[0078] In the specific implementation, the development and operation personnel input the microservice stop command through the Kubernetes console to stop the microservice application running in Kubernetes. The microservice stop command includes at least one parameter, namely the microservice name, and may also include two parameters, one is the microservice name, and the other is the restart time of the microservice recovery.

[0079] The microservice name corresponds to the name of the service in Kubernetes. The restart time is the delay time for the microservice to start again, in seconds, which is used to regularly restore the microservice application in Kubernetes.

[0080] Step S100 detects the microservice application based on the preconfigured microservice stop detection rule, including the following steps:

[0081] (1) Determine whether the corresponding service resources can be found in Kubernetes;

[0082] (2) If it does not exist, it will return an error.

[0083] (3) If it exists, further query whether the content of the endpoint field in the Service is the none field. If it is, it means that the current Service is not associated with a pod application, and the microservice application can no longer provide work to the outside world, that is, it does not meet the microservice stop detection rules. Otherwise, it meets the microservice stop detection rules.

[0084] Step S200 uses a unique string generation algorithm to terminate the above-mentioned microservices that meet the microservice stop detection rules. Find the corresponding service in Kubernetes, query the value of the app field under the selector in the Service as the application name app-name, and use the unique string generation algorithm to terminate the microservice. The specific steps are as follows: First, generate the current system timestamp currentTimeMillis through the system function, and then encrypt app-name+currentTimeMilli-s through the string encryption function to generate an encrypted string greater than 12 digits. Take out the first 6 digits and the last 6 digits of the encrypted string respectively and combine them into a new string cipher. Finally, replace the value of the app field under the selector in the Kubernetes service corresponding to the microservice application that needs to be terminated with app-name-cipher.

[0085] Step S300 further detects the microservice application that has been terminated to determine whether the microservice application has been successfully terminated. The specific implementation is: according to the name of the microservice that needs to be detected, query whether the content of the endpoint field in the corresponding Kubernetes service is the none field. If it is, it means that the current Service is not associated with a pod application and the microservice application has been successfully terminated. If not, execute the above steps S100 and S200 again, and then use the microservice status detection rule to perform microservice status detection until the query microservice application terminates the service.

[0086] For microservice applications that have been terminated in Kubernetes, execute the recovery instructions and perform the following recovery operations:

[0087] S100, based on the microservice name specified in the microservice stop instruction, the suspended microservice is detected by a preconfigured microservice recovery detection rule, wherein the microservice recovery detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod;

[0088] S200. For a microservice application that meets the microservice recovery detection rule, the microservice application is recovered by using the microservice recovery rule. The microservice recovery rule is used to find the corresponding service resources from Kubernetes and restore the association relationship between the Service and the pod.

[0089] Given that the microservice stop instruction may have another parameter, i.e., the restart time of restoring the microservice application, the execution method of the recovery instruction can be determined based on the restart time. There are two execution methods, namely, manually inputting the instruction to execute the recovery operation and automatically executing the recovery operation based on the restart time. If the microservice stop instruction specifies the restart time for restoring the microservice application, the recovery method of the microservice is selected based on the restart time; if the microservice stop instruction does not specify the restart time for restoring the microservice application, the recovery operation of the terminated microservice application is performed by manually inputting the instruction.

[0090] The specific operation is: check whether there is a restart time parameter for microservice recovery in the microservice stop instruction field. If so, determine whether the value of the restart time parameter is 0. If not, start the timer in the background, and automatically execute the microservice recovery instruction after the delay of the parameter value of the restart time parameter. If there is no restart time parameter for microservice recovery or the parameter value is 0, you need to enter the microservice recovery instruction to recover the microservice application in Kubernetes. The microservice recovery instruction contains a microservice name parameter.

[0091] When restoring a microservice application, use the microservice recovery detection rules to detect whether the microservice that needs to be restored complies with the rules. The specific microservice recovery detection rules are as follows: First, according to the microservice name parameter in the microservice recovery instruction, search for the corresponding service resource in Kubernetes. If it does not exist, return an error directly. If it does exist, further query whether the content of the endpoint field in the Service is the none field. If so, perform the second step of microservice recovery rule detection. Further query whether the length of the value of the app field under the selector under the corresponding service found in Kubernetes is greater than 14 and whether the 13th-to-last string is "-". If so, it means that the current microservice complies with the microservice recovery detection rules and microservice recovery can be performed. Otherwise, it means that the current microservice does not comply with the microservice recovery detection rules and the microservice cannot be restored.

[0092] For the terminated microservice applications that meet the microservice recovery rules, use the microservice recovery rules to restore the specified microservices. The specific implementation steps are as follows: First, according to the microservice name entered in the microservice instruction, find the corresponding service in Kubernetes, find out that the value of the app field under the selector in the Service is app-name, cut off the last 13 digits of the app-name value, generate a new app-new-name string, and use app-new-name instead of app-name. The microservice can be restored.

[0093] The method of this embodiment realizes the stopping and recovery of microservice applications in Kubernetes by interrupting and restoring the association between Service and pod in Kubernetes, which simplifies the stopping and recovery process of microservice applications in Kubernetes, and in the process of stopping and recovering microservice applications in Kubernetes, there will be no restart and scheduling of new pods, which greatly saves the overhead of resource scheduling in Kubernetes; specifically, the value of the app field under the selector in the service is replaced by a string generated by a unique string generation algorithm, interrupting the microservice application in kubernets from providing external services, thereby realizing the function of stopping the microservice in Kubernetes from providing services, and the application examples in the pod will not be terminated in this process, so it will not cause the rescheduling and restart of the pod, and can avoid abnormal problems generated during the operation process. In addition, the method provides a delayed recovery function after the service is suspended through the restart time, which is more convenient for developers to manage microservice applications during the debugging process of microservice applications, and is used to meet the needs of developers who need to suspend services during the debugging process of enterprise applications.

[0094] Embodiment 2:

[0095] The present invention discloses a microservice application stopping and recovering system, comprising a Kubernetes console, a stop detection module, a stop execution module, a stop confirmation module, a recovery detection module, a recovery execution module and a recovery mode confirmation module. The system can realize the stopping and recovering of the microservice application by executing the method disclosed in Example 1.

[0096] The Kubernetes console is used to input a microservice stop instruction, where the microservice stop instruction at least includes the microservice name.

[0097] The development and operation personnel input the microservice stop command through the Kubernetes console to stop the microservice application running in Kubernetes. The microservice stop command includes at least one parameter, namely the microservice name, and may also include two parameters, one is the microservice name, and the other is the restart time of the microservice recovery.

[0098] The microservice name corresponds to the name of the service in Kubernetes. The restart time is the delay time for the microservice to start again, in seconds, which is used to regularly restore the microservice application in Kubernetes.

[0099] The stop detection module is used to detect the microservice based on the microservice name specified in the microservice stop instruction through the preconfigured microservice stop detection rule. The microservice stop detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod.

[0100] The detection process of the microservice stop detection rule in the stop detection module is:

[0101] (1) Determine whether the corresponding service resources can be found in Kubernetes;

[0102] (2) If it does not exist, it will return an error.

[0103] (3) If it exists, further query whether the content of the endpoint field in the Service is the none field. If it is, it means that the current Service is not associated with a pod application, and the microservice application can no longer provide work to the outside world, that is, it does not meet the microservice stop detection rules. Otherwise, it meets the microservice stop detection rules.

[0104] For microservice applications that meet the microservice stop detection rules, the stop execution module is used to terminate the microservice application through a unique string generation algorithm. The module searches for the corresponding service in Kubernetes, queries the value of the app field under the selector in the Service as the application name app-name, and uses a unique string generation algorithm to terminate the microservice. The specific steps are as follows: First, the current system timestamp currentTimeMillis is generated through a system function, and then app-name+currentTimeMillis is encrypted through a string encryption function to generate an encrypted string greater than 12 digits. The first 6 digits and the last 6 digits of the encrypted string are taken out respectively to form a new string cipher. Finally, replace the value of the app field under the selector in the Kubernetes service corresponding to the microservice application that needs to be terminated with app-name-cipher.

[0105] For a microservice application terminated by the stop execution module, the stop confirmation module is used to detect the microservice through a preconfigured microservice stop detection rule. If the microservice application is not terminated, the stop detection module and the stop execution module are called to terminate the microservice application again, and the microservice is detected again through the preconfigured microservice stop detection rule until the microservice has been terminated.

[0106] The specific implementation of the stop execution module is as follows: according to the name of the microservice to be detected, query whether the content of the endpoint field in the corresponding Kubernetes service is the none field. If so, it means that the current Service is not associated with a pod application and the microservice application has been successfully terminated. If not, call the stop detection module and the stop execution module again to terminate the microservice application, and confirm the terminated microservice through the module itself until the query microservice application terminates the service.

[0107] The recovery detection module is used to detect the terminated microservice based on the microservice name specified in the microservice stop instruction through the preconfigured microservice recovery detection rule. The microservice recovery detection rule is used to find the corresponding service resource from Kubernetes and detect the association relationship between the Service and the pod.

[0108] When restoring a microservice application, the recovery detection module uses the microservice recovery detection rules to detect whether the microservice that needs to be restored complies with the rules. The specific microservice recovery detection rules are as follows: First, according to the microservice name parameter in the microservice recovery instruction, search for the corresponding service resource in Kubernetes. If it does not exist, an error is directly returned. If it does exist, further query whether the content of the endpoint field in the Service is the none field. If so, the second step of microservice recovery rule detection is performed. Further query whether the length of the value of the app field under the selector under the corresponding service found in Kubernetes is greater than 14 and whether the 13th-to-last string is "-". If so, it means that the current microservice complies with the microservice recovery detection rules and microservice recovery can be performed. Otherwise, it means that the current microservice does not comply with the microservice recovery detection rules and the microservice cannot be restored.

[0109] For microservice applications that meet the microservice recovery detection rules, the recovery execution module is used to recover the microservice applications through microservice recovery rules. The microservice recovery rules are used to find the corresponding service resources from Kubernetes and restore the association between the Service and the pod.

[0110] The recovery execution module is used to perform the following steps to recover the terminated microservice application: first, according to the microservice name entered in the microservice instruction, find the corresponding service in Kubernetes, query the value of the app field under the selector in the Service as app-name, truncate the last 13 digits of the app-name value, generate a new app-new-name string, and use app-new-name instead of app-name to achieve microservice recovery.

[0111] For a microservice application that has been terminated, the recovery mode confirmation module is used to confirm the recovery mode based on the restart time and call the recovery detection module and the recovery execution module to perform the recovery execution operation; the recovery mode includes manually inputting instructions to execute the recovery operation and automatically executing the recovery operation based on the restart time. If the microservice stop instruction specifies the restart time for the recovery of the microservice application, the recovery mode of the microservice is selected based on the restart time. If the microservice stop instruction does not specify the restart time for the recovery of the microservice application, the recovery operation of the terminated microservice application is performed by manually inputting instructions.

[0112] The specific operation in the recovery method confirmation module is as follows: Check whether there is a restart time parameter for microservice recovery in the microservice stop instruction field. If so, determine whether the value of the restart time parameter is 0. If not, start the timer in the background, and automatically execute the microservice recovery instruction after the delay of the parameter value of the restart time parameter. If there is no restart time parameter for microservice recovery or the parameter value is 0, you need to enter the microservice recovery instruction to recover the microservice application in Kubernetes. The microservice recovery instruction contains a microservice name parameter.

[0113] The present invention has been shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the means in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the protection scope of the present invention.

Claims

1. A method for stopping and restoring a microservice application, characterized in that For microservice applications in Kubernetes, terminate the microservice applications by following the steps below: S100, based on the microservice name specified in the microservice stop instruction, the microservice is detected by a preconfigured microservice stop detection rule, wherein the microservice stop detection rule is used to find the corresponding Service resource from Kubernetes and detect the association relationship between the Service and the pod; S200, for a microservice application that meets the microservice stop detection rule, after combining the string generated by the unique string generation algorithm with the value of the app field under the selector in Service, the microservice application is terminated; S300, for the microservice application terminated in step S200, detect the microservice through the pre-configured microservice stop detection rule to determine whether the microservice application has been terminated. If the microservice application has not been terminated, execute steps S100-S300 until the microservice has been terminated; For microservice applications that have been terminated in Kubernetes, execute the recovery instructions and perform the following recovery operations: Based on the microservice name specified in the recovery instruction, the suspended microservice is detected by a preconfigured microservice recovery detection rule, where the microservice recovery detection rule is used to find the corresponding Service resource from Kubernetes and detect the association relationship between the Service and the pod; For microservice applications that meet the microservice recovery detection rules, the microservice applications are restored using the microservice recovery rules, which are used to find the corresponding Service resources in Kubernetes and restore the association between the Service and the pod.

2. A method for stopping and restoring a microservice application according to claim 1, characterized in that The microservice name corresponds to the name of the Service in Kubernetes; Step S100 detects the microservice application based on the preconfigured microservice stop detection rule, including the following steps: Determine whether the corresponding Service resources can be found in Kubernetes; If it does not exist, return an error directly; If it exists, further query whether the content of the endpoint field in the Service is the none field. If it is, it means that the current Service is not associated with a pod application, and the microservice application can no longer provide work to the outside world, that is, it does not meet the microservice stop detection rules. Otherwise, it meets the microservice stop detection rules.

3. A method for stopping and restoring a microservice application according to claim 2, characterized in that Step S200 terminates the microservice application by using a unique string generation algorithm, including the following steps: Generate the current system timestamp currentTimeMillis through the system function; Encrypt app-name+currentTimeMillis through the string encryption function to generate an encrypted string greater than 12 digits; Take out the first 6 digits and the last 6 digits of the encrypted string respectively and combine them into a new string cipher; Find the corresponding Service in Kubernetes and replace the value of the app field under the selector in the Service with app-name-cipher.

4. A method for stopping and restoring a microservice application according to claim 3, characterized in that Step S300 detects the microservice using a preconfigured microservice stop detection rule, including the following steps: According to the name of the microservice to be detected, check whether the endpoint field content in the corresponding Kubernetes Service is the none field. If it is, it means that the current Service is not associated with a pod application and the microservice application has been successfully terminated. If not, it means that the microservice application has not been successfully terminated.

5. A method for stopping and restoring a microservice application according to claim 1, characterized in that For microservice applications that have been terminated in Kubernetes, there are two ways to execute recovery instructions: manually enter the execution instructions and automatically execute the instructions based on the restart time; If the microservice stop instruction specifies a restart time for the microservice application to be restored, the stopped microservice application is automatically restored based on the restart time; If the restart time for restoring the microservice application is not specified in the microservice stop instruction, the stopped microservice application is restored by manually inputting instructions.

6. A method for stopping and restoring a microservice application according to any one of claims 1 to 5, characterized in that Detecting the suspended microservice application based on a preconfigured microservice recovery detection rule includes the following steps: Find the corresponding Service resources in Kubernetes; If it does not exist, return an error directly; If it exists, check whether the content of the endpoint field in the Service is the none field; If yes, find the corresponding Service in Kubernetes and determine whether the value length of the app field under the selector in the Service is greater than 14, and whether the 13th last character string in the app field is "-". If yes, it means that the current microservice meets the microservice recovery detection rules and can be restored. Otherwise, it means that the current microservice does not meet the microservice recovery detection rules and cannot be restored.

7. A method for stopping and restoring a microservice application according to claim 6, characterized in that Recovering the microservice application using a preconfigured microservice recovery rule includes the following steps: According to the microservice name specified in the microservice stop instruction, find the corresponding Service in Kubernetes, find out that the value of the app field under the selector in the Service is app-name, remove the last 13 digits of the app-name value, generate a new app-new-name string, and use app-new-name instead of app-name.

8. A microservice application stop and recovery system, characterized in that The system is used to stop and resume a microservice application by using a method for stopping and resuming a microservice application according to any one of claims 1 to 7, the system comprising: A Kubernetes console, wherein the Kubernetes console is used to input a microservice stop instruction, wherein the microservice stop instruction includes at least a microservice name; A stop detection module, which is used to detect the microservice based on the microservice name specified in the microservice stop instruction through a preconfigured microservice stop detection rule, and the microservice stop detection rule is used to find the corresponding Service resource from Kubernetes and detect the association relationship between the Service and the pod; A stop execution module, for a microservice application that meets the microservice stop detection rule, the stop execution module is used to combine the string generated by the unique string generation algorithm with the value of the app field under the selector in the Service, and then terminate the microservice application; A stop confirmation module, for a microservice application stopped by the stop execution module, the stop confirmation module is used to detect the microservice through a preconfigured microservice stop detection rule, and if the microservice application is not stopped, the stop detection module and the stop execution module are called to stop the microservice application again, and the microservice is detected again through the preconfigured microservice stop detection rule until the microservice has been stopped; A recovery detection module, which is used to detect the suspended microservice based on the microservice name specified in the recovery instruction through a preconfigured microservice recovery detection rule, wherein the microservice recovery detection rule is used to find the corresponding Service resource from Kubernetes and detect the association relationship between the Service and the pod; A recovery execution module, for a microservice application that meets the microservice recovery detection rule, the recovery execution module is used to recover the microservice application through the microservice recovery rule, and the microservice recovery rule is used to find the corresponding Service resource from Kubernetes and restore the association relationship between the Service and the pod; A recovery mode confirmation module, for microservice applications that have been terminated in Kubernetes, is configured with two modes of executing recovery instructions, namely, manually inputting execution instructions and automatically executing instructions based on restart time; The recovery mode confirmation module is used to select the mode of executing the recovery instruction in the following manner: if the microservice stop instruction specifies the restart time of the microservice application recovery, the microservice application that has been stopped is automatically restarted based on the restart time. If the microservice stop instruction does not specify a restart time for the microservice application to be restored, a recovery operation is performed on the suspended microservice application by manually inputting an instruction.

9. The microservice application stop and recovery system according to claim 8, characterized in that The microservice name corresponds to the name of the Service in Kubernetes; The stop detection module is used to detect the microservice application based on the preconfigured microservice stop detection rule through the following steps: Determine whether the corresponding Service resources can be found in Kubernetes; If it does not exist, return an error directly; If it exists, further query whether the content of the endpoint field in the Service is the none field. If it is, it means that the current Service is not associated with a pod application, and the microservice application can no longer provide work to the outside world, that is, it does not meet the microservice stop detection rule. Otherwise, it meets the microservice stop detection rule; The stop execution module is used to terminate the microservice application through a unique string generation algorithm through the following steps: Generate the current system timestamp currentTimeMillis through the system function; Encrypt app-name+currentTimeMillis through the string encryption function to generate an encrypted string greater than 12 digits; Take out the first 6 digits and the last 6 digits of the encrypted string respectively and combine them into a new string cipher; Find the corresponding Service in Kubernetes and replace the value of the app field under the selector in the Service with app-name-cipher; The stop confirmation module is used to determine whether the microservice application has been terminated through the following steps: According to the name of the microservice to be detected, check whether the endpoint field content in the corresponding Kubernetes Service is the none field. If it is, it means that the current Service is not associated with a pod application and the microservice application has been successfully terminated. If not, it means that the microservice application has not been successfully terminated.

10. The microservice application stop and recovery system according to claim 9, characterized in that The recovery detection module is used to detect the suspended microservice application based on the preconfigured microservice recovery detection rules through the following steps: Find the corresponding Service resources in Kubernetes; If it does not exist, return an error directly; If it exists, check whether the content of the endpoint field in the Service is the none field; If yes, find the corresponding Service in Kubernetes and determine whether the value length of the app field under the selector in the Service is greater than 14, and whether the 13th last character string in the app field is "-". If yes, it means that the current microservice meets the microservice recovery detection rules and can be restored. Otherwise, it means that the current microservice does not meet the microservice recovery detection rules and cannot be restored. The recovery execution module is used to recover the microservice application based on the preconfigured microservice recovery rules through the following steps: According to the microservice name specified in the microservice stop instruction, find the corresponding Service in Kubernetes, find out that the value of the app field under the selector in the Service is app-name, remove the last 13 digits of the app-name value, generate a new app-new-name string, and use app-new-name instead of app-name.

Images