CN114625478A - Application program management method and device, electronic equipment and computer readable storage medium - Google Patents

Abstract

The application discloses an application program management method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: acquiring an operation state detection result for each application program in at least one group of application programs; acquiring container states of a set of containers in which the set of applications are respectively run; determining the application programs with preset running states in each group of application programs according to the running state detection result of each application program and the container state of the container in which the application program runs; predetermined operations are performed on the application program having the predetermined running state. The method and the device for managing the application programs can comprehensively consider the whole application programs with the same application program identification to carry out comprehensive decision of management, and avoid the problem that the service provided by the group of application programs is poor in stability due to lack of global control caused by the fact that the management of the application programs is executed only based on the running state detection result of a single application program.

Description

Application management method and apparatus, electronic device and computer-readable storage medium

technical field

The present application relates to the field of cloud computing technologies, and in particular, to an application management method and apparatus, an electronic device, and a computer-readable storage medium.

Background technique

With the development of cloud computing technology, more and more applications can provide services to users with the help of extensive cloud computing resources. In recent years, cloud-native technologies based on cloud computing have emerged. With the help of the cloud computing environment, the native design is based on the cloud computing system, so that it can run in a better state on cloud computing resources, and can make full use and play The advantages of distributed and elastic cloud platform. In the cloud-native system, containers are one of the basic elements of the cloud-native system. Containerization can provide basic guarantees for cloud-native microservices, and containers can be managed through a container orchestration system such as K8S.

In a cloud-native system, applications or services can be containerized to generate microservices provided to users. Therefore, an application can be made multiple copies and run in multiple containers to improve the operation efficiency of the application, reduce the load of a single container, and even disaster recovery performance in the event of failure. For example, when an application running in a container is in an unhealthy state, such as when the process is suspended or the service is abnormal, the container can no longer provide services as an independent microservice unit. Such an unhealthy container issues an alarm, and the maintainer manually restarts the container to restore the normal running state of the application. However, such repetitive manual maintenance operations rely on manual review and timely operation, which is not only very inefficient, but also causes one or some containers to fail to restart in time due to lack of manpower, which affects the normal use of users.

SUMMARY OF THE INVENTION

Embodiments of the present application provide an application program management method and apparatus, an electronic device, and a computer-readable storage medium, so as to solve the defects of complex configuration and low efficiency based on single-machine detection in the prior art.

To achieve the above purpose, an embodiment of the present application provides an application management method, the method comprising:

obtain a running state detection result for each application in the at least one set of applications;

Get the container state of a set of containers in which the set of applications are running;

Determine an application program with a predetermined operating state in each group of application programs according to the running state detection result of each application program and the container state of the container in which the application program runs;

Perform a predetermined operation on an application with a predetermined running state.

The embodiment of the present application also provides an application management device, including:

a first state acquisition module, configured to acquire a running state detection result for each application program in the at least one group of application programs;

The second state acquisition module is used to acquire the container state of a group of containers in which the group of application programs are respectively running;

A determination module, configured to determine the applications with predetermined running states in each group of applications according to the running state detection results of each application and the container state of the container in which the application runs;

The execution module is used to execute a predetermined operation on an application program with a predetermined running state.

The embodiment of the present application also provides an electronic device, including:

memory for storing programs;

The processor is configured to run the program stored in the memory, and when the program runs, the application program management method provided by the embodiment of the present application is executed.

Embodiments of the present application further provide a computer-readable storage medium on which a computer program executable by a processor is stored, wherein when the program is executed by the processor, the application program management method provided by the embodiments of the present application is implemented.

The application program management method and apparatus, electronic device, and computer-readable storage medium provided by the embodiments of the present application acquire the running state detection results of a group of application programs with the same application program identifier, and acquire the container corresponding to the group of application programs the container status, so as to make a comprehensive judgment based on the detection result of the running status of the application and the container status of the container in which the application runs, to determine the application with a predetermined running status in the group of applications, and to determine the application with a predetermined running status in this way. An application in a predetermined running state performs an action. Therefore, it is possible to comprehensively consider the entire application program with the same application program identifier to perform management comprehensive decision-making, and avoid performing application program management based only on the running state detection result of a single application program, resulting in lack of global control and making the group The problem of poor stability of the service provided by the application.

The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the description, and in order to make the above-mentioned and other purposes, features and advantages of the present application more obvious and easy to understand , and the specific embodiments of the present application are listed below.

Description of drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are for purposes of illustrating preferred embodiments only and are not to be considered limiting of the application. Also, the same components are denoted by the same reference numerals throughout the drawings. In the attached image:

1 is a schematic diagram of an application scenario of an application program management solution provided by an embodiment of the present application;

2 is a flowchart of an embodiment of an application management method provided by the present application;

3 is a flowchart of another embodiment of an application management method provided by the present application;

FIG. 4 is a schematic structural diagram of an embodiment of an application management apparatus provided by the present application;

FIG. 5 is a schematic structural diagram of an embodiment of an electronic device provided by the present application.

Detailed ways

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be more thoroughly understood, and will fully convey the scope of the present disclosure to those skilled in the art.

Example 1

The solutions provided in the embodiments of the present application can be applied to any system with cloud application management capability, such as a cloud service system including a cloud application management module, and so on. FIG. 1 is a schematic diagram of an application scenario of an application management solution provided by an embodiment of the present application. The scenario shown in FIG. 1 is only one example of the principle of the technical solution of the present application.

With the development of cloud computing technology, more and more applications can provide services to users with the help of extensive cloud computing resources. In recent years, cloud-native technologies based on cloud computing have emerged. With the help of the cloud computing environment, the native design is based on the cloud computing system, so that it can run in a better state on cloud computing resources, and can make full use and play The advantages of distributed and elastic cloud platform. In the cloud-native system, containers are one of the basic elements of the cloud-native system. Containerization can provide basic guarantees for cloud-native microservices, and containers can be managed through a container orchestration system such as K8S.

In a cloud-native system, applications or services can be containerized to generate microservices provided to users. Therefore, an application can be made multiple copies and run in multiple containers to improve the operation efficiency of the application, reduce the load of a single container, and even disaster recovery performance in the event of failure. For example, when an application running in a container is in an unhealthy state, such as when the process is suspended or the service is abnormal, the container can no longer provide services as an independent microservice unit. Such an unhealthy container issues an alarm, and the maintainer manually restarts the container to restore the normal running state of the application. However, such repetitive manual maintenance operations rely on manual review and timely operation, which is not only very inefficient, but also causes one or some containers to fail to restart in time due to lack of manpower, which affects the normal use of users.

In the prior art, it has been proposed to set a container probe in a container management system, so that the probe can periodically enter a specified container according to a user's configuration to detect whether the container service is normal. For example, the probe may be a command script program, and by executing the command script program in a specified container, and according to the execution result of the command script program, it is determined whether the application in the container is in a normal running state. For example, a user can configure a command script according to a group of applications that have been containerized, so that the execution of the command script can reflect the running state of the applications in the container. After configuration, the configured probe command script can be implanted into the set of applications, that is, the containers of all application copies that provide services to the outside world, and for example, when the execution successfully generates a predetermined exit code, it can be determined. The detection is successful, that is, the running status of the application in the container is normal.

On the contrary, if the exit code generated by the execution of the command script program is not zero, it can indicate that the script execution fails. Therefore, in the prior art, it can be judged that the application program in the container is running abnormally based on the result, so that it can be directly Triggers a restart of the container to resume normal operation of the application in the container.

However, in the prior art solution, the execution result of the implanted detection command script program is actually used to indirectly reflect the running state of the application in the container. Therefore, if the configuration of the command script is unreasonable, the Affect the accuracy of application running status detection, and may even lead to wrong judgment. Therefore, in the prior art, maintenance personnel of the application program are usually required to have rich experience and professional knowledge to perform such a configuration.

In addition, especially in the cloud-native system, multiple application copies are formed based on an application and run in a single container to jointly provide services to the outside world. That is, in effect, the set of application copies constitutes a whole to provide each part of the service to the outside world. Therefore, in such a case, if a single container is restarted unreasonably or even erroneously due to the unreasonable configuration of the probe command script, it will directly affect a part of the service, even if the application running in a single container is more important in the whole, Then the direct restart of such a container may have a great impact on the normal operation of the entire service, and even lead to user losses.

In the solution of the prior art, the solution of managing a group of application programs based on the detection result of a single container may have potential security risks in practical application. Because in the cloud native system, it is necessary to measure the impact of the running status of application copies in multiple containers that provide microservices on the overall service. For this reason, the configuration of stand-alone probe detection for each container requires maintenance personnel to have a deep understanding of the application, as well as professional knowledge. In addition, due to the complex relationship between the various containers that provide microservices in the cloud native system, such a single-machine configuration is often prone to incorrect configuration by maintenance personnel due to cumbersome configuration or complex content. Once such a misconfiguration is determined to be effective by the maintainer, it is easy to cause the container that provides the microservice to be restarted incorrectly, or restarted at the wrong time, which will affect the externally provided services or even fail to provide external services.

In particular, the probe detection currently used in the prior art for a single container, because each application in a group of applications is uniformly and uniformly configured during configuration, so once the configuration takes effect, it will be applied in the group of applications. Take effect in all containers of the program. In other words, if the probe detection method is incorrectly configured due to the mistakes of the maintainers, all applications running in all containers may be restarted, resulting in all applications being unable to provide services to the outside world, seriously affecting service stability and high availability.

For example, as shown in FIG. 1 , FIG. 1 shows an application scenario to which the application management method of the present application can be applied. In the scenario shown in Figure 1, three containers 1-3 can be generated for three copies of an application on the cloud server to run the three copy programs respectively, so that the three copies can be divided into containers 1-3 by dividing The three application replicas 1-3 running in the microservices provide services to the outside as a whole. Therefore, in order to ensure the stability of the service, a probe command script program can be configured for the application programs 1-3, the script program can be executed in the containers 1-3 respectively, and therefore, in the prior art, according to the above-mentioned command script The execution result of the program in the container 1-3 is used to judge the running state of the application program 1-3. In particular, in the embodiment of the present application, the maintainer usually configures the script program only according to experience, and after the script program is configured, it can take effect for all three application programs 1-3. Therefore, for example, when the execution result of the script program in the container 1 is that an exit code of zero is generated, or a successful execution result identifier is generated, it can be considered that the running state of the application program in the container is normal. On the contrary, when the execution result of the script program in a certain container is non-zero, or a failed execution result is returned, then in the prior art, it is judged that the running state of the application program in the container is abnormal, so that the The container issues a restart instruction to resume the application. However, as mentioned above, in the prior art, if the script program fails to run in the container 1 due to the wrong configuration of the script program, in fact, the application program 1 always runs normally in the container 1, but the script program But it will return e.g. a non-zero exit code due to failure, then this will cause the container to be restarted. In particular, the script will continue to be used to perform health checks of the application after a restart. Therefore, it is inevitable that these script programs will return a failed execution result every time they are run in the container, so that the container 1-3 of the application 1-3 is restarted repeatedly, and finally the services provided by the application 1-3 to the outside are made. abnormal.

In this regard, in the embodiment of the present application, after the execution result of the script program is obtained, the application program is not directly managed based on the execution result, but the current container state of the container is further obtained, and based on the container state and the script The execution result of the program is used to comprehensively judge the running state of the application program in the container. Especially in this embodiment of the present application, when judging the running state of the application program, the script programs of all the application programs in the application group are obtained. According to the execution result, applications with a predetermined state can also be managed based on the predetermined policy of the group of applications while ensuring that the service is normal as much as possible.

Specifically, the technical solutions of the embodiments of the present application may use the Kubernetes framework system as the container management solution. In this solution, the embodiments of the present application can implement non-invasive configuration, and make in-depth functional expansion and technical evolution by drawing on the livenessProbe probe capabilities in the field, thereby proposing an enhanced livenessProbe probe controller. In this solution, the controller can adopt the standard Kubernetes detection module and can be based on the ControllerRuntime architecture. Therefore, in the embodiment of the present application, the overall implementation of the cloud service system is based on centralized deployment, and the scope of influence of the entire deployment domain is a Kubernetes cluster. As described above, the container status is periodically reported for a single container on each server in the cluster, and the enhanced livenessProbe probe control module can be used to further combine the container status for comprehensive judgment.

Under the microservice architecture, applications are deployed in a containerized form, and in a broad sense, applications run in containers. Therefore, the detection script component can be arranged to perform detection on a single machine, and report the status to the container level, and then a management module such as a cloud service system to which the application management method of the embodiment of the present application is applied makes a comprehensive decision. After sensing the state change of the container, the enhanced livenessProbe controller according to the embodiment of the present application performs internal logic calculation and decides whether to restart the container. Finally, when it is judged that the application is running abnormally, the enhanced livenessProbe controller can issue instructions and trigger a restart for the corresponding container. In other words, in this embodiment of the present application, after the user edits and configures the detection script, only the detection is performed on the single-machine container side, and the detection result is reported by the container, for example, and the management module such as the detection controller checks the script's detection results. The execution results and container status are comprehensively judged, especially the judgment results of this group of application copies can be further integrated to further determine the containers that need to be restarted, so that the application can be managed from the perspective of ensuring service stability and reliability. and control.

For example, in this embodiment of the present application, the following three methods, ie, ExecAction, HTTPGetAction, and TCPSocketAction, may be used to obtain the running state detection result of the application. For example, the test result Success may indicate that the test passed, Failure indicates that the test failed, and Unknown indicates that the test was not performed normally. Specifically, for the ExecAction detection method, the specified script command can be executed in the container. If the execution is successful and the exit code is 0, the detection is successful; for the HTTPGetAction method, the HTTP Get method can be called through the IP address, port number and path of the container. If the response status code is greater than or equal to 200 and less than 400, the container is considered healthy; for TCPSocketAction, a TCP check can be performed through the container's IP address and port number, and if a TCP connection can be established, the container is healthy.

Therefore, in the solution of the embodiment of the present application, after the configuration of the probe by the user is completed, it can take effect at all container levels immediately, which is a potential risk to the reliability of the application in the solution of the prior art. For example, as mentioned above, if the probe is configured incorrectly, the adoption of community logic will cause the application to be restarted in full, which is a fatal point in terms of stability and high service availability. However, in the solution of this embodiment of the present application, the detection execution result is reported to the container control module through the container side, so that the container control module can use a centralized concept to stand in the global perspective of all applications, especially from a group of applications. The overall perspective of the program to consider the high reliability of the services provided by the application as a whole.

In addition, in this embodiment of the present application, since the overall reliability of the services provided by all application copies can be considered, a threshold for the number of containers restarted each time can be further introduced to prevent restarts of all containers caused by configuration errors. In the embodiment of the present application, the maximum unavailability ratio maxUnAvailable value can be used, so that bottom protection can be performed in combination with the actual number of containers in the current application.

In addition, in this embodiment of the present application, since the number of application program replicas that provide different services is different, when setting the maximum unavailability ratio, the current application replica number can also be considered to dynamically adjust the proportion state. For example, the current number of container replicas is 10. If maxUnAvailable=20% is set, only 2 containers are allowed to be triggered to restart at the same time. In practical applications, the threshold can be flexibly set by maintenance personnel according to the requirements of practical applications. For example, if the number of replicas<10, then maxUnAvailable=1; if the number of replicas>=10, then maxUnAvailable=20%. Of course, in the embodiment of the present application, the pdbproducer controller in the open source OpenKruise also performs real-time dynamic maintenance on the maxUnAvailable value according to the capacity of the service and the rule policy.

Also, as mentioned above, if the probe scheme configuration fails, for example, the command script is misconfigured, the script will return a failed result every time it executes in the container, but in fact both the container and the application are running fine. Therefore, in this embodiment of the present application, the number of times the application program detection result is a failure within a predetermined period of time may be further counted, and if the number of failures within a period of time reaches a predetermined threshold, the above configuration error may occur. Therefore, The user may be alerted in this case.

In addition, in the embodiment of the present application, since the detection result and the container state are comprehensively considered when judging the actual running state of the application, different priorities may be further assigned to the combination of the detection result and the container state, so as to achieve more Accurate judgment. For example, the detection results may include execution success and execution failure, and the container status may include container available and container unavailable. Therefore, in this embodiment of the present application, the priority of the first combination in which the execution fails and the container is unavailable may be set to be higher than the priority of the second combination in which the execution fails and the container is available.

The application management solution provided by the embodiments of the present application obtains the running state detection results of a group of applications with the same application identifier, and obtains the container state of the container corresponding to the group of applications, so as to obtain the running state of the application based on the running state of the application. The detection result and the container state of the container in which the application program runs are used for comprehensive judgment to determine an application program with a predetermined running state in the group of application programs, and perform an operation on the thus determined application program with a predetermined running state. Therefore, it is possible to comprehensively consider the entire application program with the same application program identifier to perform management comprehensive decision-making, and avoid performing application program management based only on the running state detection result of a single application program, resulting in lack of global control and making the group The problem of poor stability of the service provided by the application.

The foregoing embodiments are descriptions of the technical principles and exemplary application frameworks of the embodiments of the present application, and the specific technical solutions of the embodiments of the present application will be further described in detail below through multiple embodiments.

Embodiment 2

FIG. 2 is a flowchart of an embodiment of an application management method provided by this application. The execution body of the method may be various terminals or server devices with cloud application management capabilities, or may be devices or chips integrated on these devices. . As shown in Figure 2, the application management method includes the following steps:

S201: Acquire a running state detection result for each application program in at least one group of application programs.

In step S201, the running state detection result of each application program in the at least one group of application programs may be acquired. In this embodiment of the present application, the obtained detection result may be used as the running state detection result in step S201 by executing a pre-configured detection scheme in the container running each application. In particular, in this embodiment of the present application, the detection result may be acquired for a group of application programs identified by the same application program. Therefore, in the microservice system, the detection status of a set of microservice application replicas that provide services as a whole can be obtained.

S202: Acquire container states of a group of containers in which the group of application programs are respectively run.

In step S202, the container state of the container in which the application program for which the detection result acquired in step S201 is run may be acquired. For example, in a cloud-native system, each application can run in a container to provide different service content. Therefore, in this embodiment of the present application, in addition to acquiring, for example, the execution result of the probe as the detection result, the state of the container in which the application is running is further acquired in step S202 to facilitate comprehensive judgment.

S203 , according to the detection result of the running state of each application and the container state of the container in which the application runs, determine an application with a predetermined running state in each group of applications.

In step S203, the actual running state of the application can be comprehensively judged according to the detection result obtained in step S201 and the container state obtained in step S202. For example, in practical applications, the user configures the probe so that it can run in the container of the application to detect the running state of the application. Therefore, the detection result of the probe can only indirectly reflect the application. and, as mentioned above, the accuracy of the probe detection results will also depend on the specific configuration of the probe by the maintenance personnel. Therefore, if the configuration is unreasonable or even wrong, the execution of the probe in the container will fail. In the prior art, if only the execution result is used as the only basis for judging the running state of the application, it will cause Performed wrong handling of the application, for example, restarted when the application was actually running normally. In step S203 of the present application, a comprehensive judgment can be made based on the detection result and further considering the actual state of the container, so as to eliminate the problem of wrong detection results caused by the configuration problem of the detection scheme on the single machine side.

S204, perform a predetermined operation on an application program with a predetermined running state.

Therefore, in step S204, a predetermined operation may be performed on the application program determined to have a predetermined running state based on the result determined in step S203. For example, if it is determined in step S203 that the running state of the application program is abnormal or fails, the application program may be restarted in step S204 to restore the normal operation of the application program.

The application program management method provided by the embodiment of the present application obtains the running state detection results of a group of application programs with the same application program identifier, and obtains the container state of the container corresponding to the group of application programs. The detection result and the container state of the container in which the application program runs are used for comprehensive judgment to determine an application program with a predetermined running state in the group of application programs, and perform an operation on the thus determined application program with a predetermined running state. Therefore, it is possible to comprehensively consider the entire application program with the same application program identifier to perform management comprehensive decision-making, and avoid performing application program management based only on the running state detection result of a single application program, resulting in lack of global control and making the group The problem of poor stability of the service provided by the application.

Embodiment 3

FIG. 3 is a flowchart of another embodiment of an application management method provided by the present application. The execution body of the method may be various terminal or server devices with cloud native application management capabilities, or may be devices integrated on these devices. or chip. As shown in Figure 3, the application management method includes the following steps:

S301, a predetermined command script is executed in the container of each application.

In step S301, a predetermined command script may be executed in the container running each application to detect the running state of the application. For example, in the prior art, a maintenance person can configure a command script program and execute the configured script program in a container, as a detection means for detecting an application program running in the container.

S302: Determine the running state detection result of each application program according to the execution result of the command script.

In step S302, the running state detection result of the application program in the container may be determined according to the execution result of the command script executed in step S301. For example, as shown in FIG. 1 , the user may pre-configure a detection script program for the application programs running in the containers 1-3, and in step S301, the script programs are executed in the containers 1-3 respectively. Thus, in step S302, it can be obtained that the execution result in the container 1 is that an exit code of zero is generated, or a successful execution result identifier is generated. Therefore, in step S302, it can be considered that the running state of the application in the container is normal. . When it is obtained in step S302 that the execution result of the script program in a certain container is non-zero, or a failed execution result is returned, then in step S302, the execution failure result can be used as the running state detection result of the application program.

S303: Obtain container states of a group of containers in which the group of application programs are respectively run.

In step S303, the container state of the container of the application program for which the detection result obtained in step S302 is executed may be obtained. For example, in a cloud-native system, each application can run in a container to provide different service content.

For example, when the execution result of the command script executed in step S301 obtained in step S302 is non-zero, or a failed execution result is returned, then in the prior art, the running state of the application in the container will be judged exception, so that a restart instruction can be directly issued to the container to resume the running of the application. However, as mentioned above, in the prior art, if the script program fails to run in the container 1 due to the wrong configuration of the script program, in fact, the application program 1 always runs normally in the container 1, but the script program But it will return e.g. a non-zero exit code due to failure, then this will cause the container to be restarted. In particular, the script will continue to be used to perform health checks of the application after a restart. Therefore, it is inevitable that these script programs will return a failed execution result every time they are run in the container, so that the container 1-3 of the application 1-3 is restarted repeatedly, and finally the services provided by the application 1-3 to the outside are made. abnormal.

Therefore, in this embodiment of the present application, in addition to acquiring, for example, the execution result of the probe as the detection result, the state of the container in which the application is running is further acquired in step S303 to facilitate comprehensive judgment.

S304: Determine an application with a predetermined running state according to the combination priority of the running state detection result of the application and the container state.

In step S304, the running state of the application may be judged based on the combination of the detection result determined in step S302 and the container state obtained in step S303. In particular, in the embodiment of the present application, in order to comprehensively consider the detection result and the container state when judging the actual running state of the application, different priorities may be further assigned to the combination of the detection result and the container state, so as to achieve a more accurate judge. For example, the detection results may include execution success and execution failure, and the container status may include container available and container unavailable. Therefore, in this embodiment of the present application, the priority of the first combination in which the execution fails and the container is unavailable may be set to be higher than the priority of the second combination in which the execution fails and the container is available. Therefore, in the scenario shown in FIG. 1, for example, when it is determined in step S302 that the execution result of the command script in container 1 is failure and the execution result of the command script in container 2 is failure, and in step S303, the The status of container 1 is available, and the status of container 2 is unavailable, so in step S304, the priority based on the combination of the script execution result in container 2 and the container status can be higher than the script execution result in container 1 and the container status. combination, and it is determined that the container 2 is restarted first, so as to restore the running of the application 2 in the container 2.

S305: Determine an operation threshold according to the total number of application programs in a group of application programs.

S306: Manage the application programs in each group according to the proportion of the application programs in each group of application programs having a predetermined running state.

In step S305, the operation threshold may be determined according to the total number of application programs with the same identification detected in step S301. In particular, in the solution of the embodiment of the present application, after the configuration of the probe by the user is completed, it can take effect immediately at all container levels, which is a potential risk to the reliability of the application in the solution of the prior art . For example, as mentioned above, if the probe is configured incorrectly, the adoption of community logic will cause the application to be restarted in full, which is a fatal point in terms of stability and high service availability. For this reason, in this embodiment of the present application, in step S302, the container side reports the detection execution result to the container control module, and in step S303, the container status is further obtained, so that the container control module can use a centralized idea to Based on the detection results and container status of a group of applications, consider the high reliability of the services provided by the application as a whole from the global perspective of the entire application, especially from the overall perspective of a group of applications.

Therefore, in step S305, the overall reliability of the services provided by all the application copies can be considered to determine the number threshold of each operation in a group of applications, so as to prevent restarting of all containers caused by configuration errors.

For example, in step S305, the maximum unavailability ratio value may be set in combination with the actual number of containers of the current application, which is used as a bottom protection for the entire application program. Specifically, since the number of applications providing different services is different, when setting the maximum unavailability ratio in step S305, the current total number of applications can be considered to dynamically adjust the ratio status. For example, when the current number of container replicas is 10, the maximum unavailability ratio value can be set to 20% in step S305, and only two containers are allowed to be triggered to restart at the same time in step S306. In practical applications, the threshold can be flexibly set by maintenance personnel according to the requirements of practical applications. For example, when the total number of applications in a group is less than 10, the maximum unavailable number value can be fixed as 1, that is, only one container is allowed to be triggered to restart at the same time in step S306. When the total number of applications in a group is greater than or equal to 10, the maximum unavailability ratio value may be set to 20%, that is, only 20% of all applications are allowed to restart at the same time in step S306. Of course, in this embodiment of the present application, the threshold is also dynamically maintained in real time by the pdbproducer controller in the open source OpenKruise according to the capacity of the service and the rules and policies.

In addition, if the user has an error in configuring the detection scheme, when the script is executed in the container in step S301, a failure result will inevitably be returned in step S302, but in fact the container and the application are running normally. Therefore, in step S306, the number of times that the application program detection result is a failure within a predetermined period of time may be further counted, and if the number of failures within a period of time reaches a predetermined threshold, the above-mentioned configuration error may occur. Therefore, in this case The next step is to alert the user without restarting the container.

The application program management method provided by the embodiment of the present application obtains the running state detection results of a group of application programs with the same application program identifier, and obtains the container state of the container corresponding to the group of application programs. The detection result and the container state of the container in which the application program runs are used for comprehensive judgment to determine an application program with a predetermined running state in the group of application programs, and perform an operation on the thus determined application program with a predetermined running state. Therefore, it is possible to comprehensively consider the entire application program with the same application program identifier to perform management comprehensive decision-making, and avoid performing application program management based only on the running state detection result of a single application program, resulting in lack of global control and making the group The problem of poor stability of the service provided by the application.

Embodiment 4

FIG. 4 is a schematic structural diagram of an embodiment of an application management apparatus provided by the present application, which can be used to execute the method steps shown in FIG. 2 and FIG. 3 . As shown in FIG. 4 , the application program management apparatus may include: a first state acquisition module 41 , a second state acquisition module 42 , a determination module 43 and an execution module 44 .

The first state obtaining module 41 may be configured to obtain a running state detection result for each application program in the at least one group of application programs.

The first state obtaining module 41 may obtain the running state detection result of each application program in the at least one group of application programs. In this embodiment of the present application, the first state obtaining module 41 may use the obtained detection result as the running state detection result by executing a pre-configured detection scheme in the container running each application. In particular, in this embodiment of the present application, the detection result may be acquired for a group of application programs identified by the same application program. Therefore, in the microservice system, the detection status of a set of microservice application replicas that provide services as a whole can be obtained.

Specifically, the first state acquisition module 41 may execute a predetermined command script in the container running each application program to detect the running state of the application program and determine the running state detection result of each application program according to the execution result of the command script. For example, in the prior art, a maintenance person can configure a command script program and execute the configured script program in a container, as a detection means for detecting an application program running in the container. Therefore, the first state acquisition module 41 can determine the running state detection result of the application in the container according to the execution result of the executed command script. For example, as shown in FIG. 1 , a user may pre-configure a probe script program for the applications running in the containers 1-3, and execute the script program in the containers 1-3 respectively. Thus, it can be obtained that the execution result in the container 1 is an exit code of zero, or a successful execution result identifier is generated. Therefore, the first state acquisition module 41 can consider that the running state of the application in the container is normal. When the first state acquisition module 41 acquires that the execution result of the script program in a certain container is non-zero, or returns a failed execution result, then the first state acquisition module 41 can use the execution failure result as the application program's execution result. Running status detection results.

The second state acquisition module 42 may be used to acquire container states of a group of containers in which the group of application programs are respectively run.

The second state obtaining module 42 may obtain the container state of the container in which the application program for which the detection result obtained in the first state obtaining module 41 is running is executed. For example, in a cloud-native system, each application can run in a container to provide different service content. Therefore, in this embodiment of the present application, in addition to obtaining, for example, the execution result of the probe as the detection result, the second state obtaining module 42 further obtains the state of the container in which the application is running, so as to facilitate comprehensive judgment.

The determining module 43 may be configured to determine, according to the running state detection result of each application and the container state of the container in which the application runs, an application program with a predetermined running state in each group of application programs.

The determination module 43 can comprehensively determine the actual running state of the application program according to the detection result obtained by the first state obtaining module 41 and the container state obtained by the second state obtaining module 42 . For example, in practical applications, the user configures the probe so that it can run in the container of the application to detect the running state of the application. Therefore, the detection result of the probe can only indirectly reflect the application. and, as mentioned above, the accuracy of the probe detection results will also depend on the specific configuration of the probe by the maintenance personnel. Therefore, if the configuration is unreasonable or even wrong, the execution of the probe in the container will fail. In the prior art, if only the execution result is used as the only basis for judging the running state of the application, it will cause Performed wrong handling of the application, for example, restarted when the application was actually running normally. The determination module 43 can make a comprehensive judgment based on the detection result and further consider the actual state of the container, so as to eliminate the problem that the detection result is wrong due to the configuration problem of the detection scheme on the single machine side.

Specifically, the determination module 43 may determine the operation threshold according to the total number of application programs with the same identification that are the acquisition objects of the first state acquisition module 41 . In particular, in the solution of the embodiment of the present application, after the configuration of the probe by the user is completed, it can take effect immediately at all container levels, which is a potential risk to the reliability of the application in the solution of the prior art . For example, as mentioned above, if the probe is configured incorrectly, the adoption of community logic will cause the application to be restarted in full, which is a fatal point in terms of stability and high service availability. To this end, in this embodiment of the present application, the first state acquisition module 41 can report the detection execution result on the container side to the determination module 43, and the second state acquisition module 42 further acquires the container state, so that the determination module 43 can use The idea of centralization is based on the detection results and container status of a group of applications, from the global perspective of all applications, especially from the overall perspective of a group of applications, to consider the high reliability of the services provided by the application as a whole.

Therefore, the determination module 43 may consider the overall reliability of the services provided by all the application replicas to determine the number threshold of each operation in a group of applications, so as to prevent the restart of all containers caused by configuration errors.

For example, the determination module 43 may set the maximum unavailability ratio value in combination with the actual number of containers of the current application, which is used as a bottom protection for the entire application. Specifically, since the number of applications that provide different services is different, when the determination module 43 sets the maximum unavailability ratio, the current total number of applications can be considered to dynamically adjust the ratio status. For example, when the current number of container replicas is 10, the maximum unavailability ratio value can be set to 20%, and the execution module 44 allows only 2 containers to be triggered to restart at the same time. In practical applications, the threshold can be flexibly set by maintenance personnel according to the requirements of practical applications. For example, when the total number of applications in a group is less than 10, the maximum unavailable value can be fixed to 1, that is, only one container is allowed to be triggered to restart at the same time. When the total number of applications in a group is greater than or equal to 10, the maximum unavailability ratio value can be set to 20%, that is, only 20% of all applications are allowed to restart at the same time. Of course, in this embodiment of the present application, the threshold is also dynamically maintained in real time by the pdbproducer controller in the open source OpenKruise according to the capacity of the service and the rules and policies.

The execution module 44 may be used to execute a predetermined operation on an application program with a predetermined running state.

Therefore, the execution module 44 may perform a predetermined operation on the application program determined to have the predetermined running state based on the result determined by the determination module 43 . For example, when the determination module 43 determines that the running state of the application program is abnormal or fails, the execution module 44 may restart the application program to restore the normal operation of the application program.

If the user has an error in configuring the detection scheme, when the script is executed in the container, the first state obtaining module 41 will inevitably obtain the result of failure, but in fact, the container and the application are running normally. Therefore, the execution module 44 may further count the number of times that the application program detection results are failures within a predetermined period of time, and if the number of failures within a period of time reaches a predetermined threshold, the above configuration error may occur. Therefore, in this case The next step is to alert the user without restarting the container.

The application program management apparatus provided by the embodiment of the present application acquires the running state detection results of a group of application programs with the same application program identifier, and acquires the container state of the container corresponding to the group of application programs. The detection result and the container state of the container in which the application program runs are used for comprehensive judgment to determine an application program with a predetermined running state in the group of application programs, and perform an operation on the thus determined application program with a predetermined running state. Therefore, it is possible to comprehensively consider the entire application program with the same application program identifier for comprehensive decision-making for management, and avoid performing application program management only based on the running state detection result of a single application program, resulting in lack of global control and making the group The problem of poor stability of the service provided by the application.

Embodiment 5

The internal function and structure of the application management apparatus are described above, and the apparatus can be implemented as an electronic device. FIG. 5 is a schematic structural diagram of an embodiment of an electronic device provided by the present application. As shown in FIG. 5 , the electronic device includes a memory 51 and a processor 52 .

The memory 51 is used to store programs. In addition to the above-described programs, the memory 51 may also be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, contact data, phonebook data, messages, pictures, videos, etc.

Memory 51 may be implemented by any type of volatile or non-volatile storage device or combination thereof, such as static random access memory (SRAM), electrically erasable programmable read only memory (EEPROM), erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), Magnetic Memory, Flash Memory, Magnetic or Optical Disk.

The processor 52 is not limited to a processor (CPU), but may also be a graphics processing unit (GPU), a field programmable gate array (FPGA), an embedded neural network processor (NPU), or an artificial intelligence (AI) chip, etc. processing chip. The processor 52, coupled with the memory 51, executes the program stored in the memory 51, and when the program runs, the application program management method of the second or third embodiment above is executed.

Further, as shown in FIG. 5 , the electronic device may further include: a communication component 53 , a power supply component 54 , an audio component 55 , a display 56 and other components. Only some components are schematically shown in FIG. 5 , which does not mean that the electronic device only includes the components shown in FIG. 5 .

The communication component 53 is configured to facilitate wired or wireless communication between the electronic device and other devices. Electronic devices can access wireless networks based on communication standards, such as WiFi, 3G, 4G or 5G, or a combination thereof. In one exemplary embodiment, the communication component 53 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 53 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

The power supply assembly 54 provides power to various components of the electronic device. Power supply components 54 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic devices.

Audio component 55 is configured to output and/or input audio signals. For example, audio component 55 includes a microphone (MIC) that is configured to receive external audio signals when the electronic device is in operating modes, such as calling mode, recording mode, and voice recognition mode. The received audio signal may be further stored in the memory 51 or transmitted via the communication component 53 . In some embodiments, audio assembly 55 also includes a speaker for outputting audio signals.

Display 56 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, swipe, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or swipe action, but also detect the duration and pressure associated with the touch or swipe action.

Those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments may be completed by program instructions related to hardware. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps including the above method embodiments are executed; and the foregoing storage medium includes: ROM, RAM, magnetic disk or optical disk and other media that can store program codes.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions described in the foregoing embodiments can still be modified, or some or all of the technical features thereof can be equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present invention. scope.

Claims (11)

1. An application management method, wherein each application runs in a container, and the method comprises: obtain a running state detection result for each application in the at least one set of applications; Get the container state of a set of containers in which the set of applications are running; Determine an application program with a predetermined operating state in each group of application programs according to the running state detection result of each application program and the container state of the container in which the application program runs; Perform a predetermined operation on an application with a predetermined running state. 2 . The application management method according to claim 1 , wherein the acquiring a running state detection result for each application in the at least one group of applications comprises: 2 . Execute a predetermined command script in the container of each application; The running state detection result of each application program is determined according to the execution result of the command script. 3. The application program management method according to claim 1, wherein each group of the application programs has the same application program identifier, and the performing a predetermined operation on the application program with a predetermined running state comprises: An operation threshold is determined according to the total number of applications in the group of applications, wherein the operation threshold is the maximum number of containers corresponding to the group of applications that are allowed to be restarted at the same time, and The application programs of each group are managed according to the proportion of the application programs with a predetermined running state in the group of application programs. 4. The application program management method according to claim 3, wherein, according to the proportion of the application programs in each group of application programs with a predetermined running state, the management of the group of application programs comprises: When the ratio is smaller than the operation threshold, a restart operation is performed on the application program with the predetermined running state. 5. The application program management method according to claim 3, wherein the determining an operation threshold according to the total number of application programs in the group of application programs comprises: When the total number of application programs in the group of application programs is less than a preset threshold, determining a first preset value as the operation threshold; When the total number of application programs in the group of application programs is less than a preset threshold, the product of the second preset value and the total number of application programs is determined as the operation threshold. 6. The application management method according to claim 2, wherein, The determining, according to the running state detection result of each application and the container state of the container in which the application runs, determines that the applications having the predetermined running state in each group of applications include: An application having a predetermined running state is determined according to the priority of the combination of the running state detection result of the application and the container state. 7 . The application management method according to claim 6 , wherein the detection result of the running state of the application comprises: the command script is successfully executed and the command script fails to be executed, and the container state comprises: the container is ready. 8 . and the container is unavailable, and The combination includes: a first combination of command script execution failure and the container unavailable; and a second combination of command script execution failure and the container available, and The first combination has a higher priority than the second combination. 8. The application management method according to claim 1, wherein the performing a predetermined operation on an application having a predetermined running state comprises: Count the number of applications that are determined to have a predetermined operating state within a predetermined period of time; A predetermined operation is performed on the application having a predetermined running state according to the number of times. 9. An application program management apparatus, wherein each application program runs in a container, and the apparatus comprises: a first state acquisition module, configured to acquire a running state detection result for each application program in the at least one group of application programs; a second state acquisition module, configured to acquire the container states of a group of containers in which the group of application programs are respectively running; a determination module, configured to determine the applications with predetermined running states in each group of applications according to the running state detection results of each application and the container state of the container in which the application runs; The execution module is used for executing a predetermined operation on an application program with a predetermined running state. 10. An electronic device comprising: memory for storing programs; The processor is configured to run the program stored in the memory to execute the application program management method according to any one of claims 1 to 8. 11. A computer-readable storage medium on which a computer program executable by a processor is stored, wherein when the program is executed by the processor, the application program management method according to any one of claims 1 to 8 is implemented .

Images