Software system maintenance method, device, computer equipment and readable storage medium

Abstract

The present invention relates to the field of automatic programming. An embodiment of the present invention provides a maintenance method, device, computer equipment and readable storage medium for a software system, wherein the method comprises: calling a self-detection script, executing the self-detection script to determine whether the process of the application to be detected is in a survival state according to the process keyword in the configuration file; if not, and it is determined that the application to be detected is abnormally shut down, then calling the application shutdown script according to the full path of the application shutdown script in the configuration file, executing the application shutdown script to shut down the application to be detected, and calling the application startup script according to the full path of the application startup script in the configuration file, executing the application startup script to start the application to be detected. This scheme realizes the automatic recovery of the application, which is conducive to ensuring the high availability of the information system. At the same time, this maintenance method is easy to operate, does not require the addition of additional high-availability servers, and is conducive to reducing costs.

Description

Technical Field

[0001] The present invention relates to the field of automatic programming, and in particular to a maintenance method, device, computer equipment and readable storage medium for a software system. Background Art

[0002] Information systems are widely used in various sectors, from aviation and aerospace to finance and telecommunications, and even in general management systems. If an information system is unable to provide external services due to application downtime, it can have a significant impact on businesses and customers, and even lead to significant economic losses. Therefore, information systems must ensure continuous availability, and high-availability solutions must be considered in software design to ensure the system continues to provide services.

[0003] High availability (HA) is a key consideration in distributed system architecture design. It generally involves minimizing downtime due to both routine maintenance (planned) and unexpected system crashes (unplanned) to improve system and application availability. HA is the most effective way for enterprises to prevent downtime of core computer systems due to failures.

[0004] The commonly used high availability method in the industry is based on distributed clusters. Applications need to be deployed in cluster mode and rely on additional load balancing servers to provide a heartbeat detection mechanism to ensure the high availability of the system through the load balancing server and its high availability. For some small and medium-sized enterprises or small and medium-sized applications, this method will undoubtedly increase costs and maintenance difficulties. Summary of the Invention

[0005] The present invention provides a software system maintenance method to solve the technical problems in the prior art of software system maintenance, which are high cost and difficult to operate due to the need for additional load balancing servers. The method includes:

[0006] Calling a self-test script, executing the self-test script to determine whether the process of the application to be tested is alive according to the process keyword in the configuration file;

[0007] If not, and it is determined that the application to be detected is shut down abnormally, the application shutdown script is called according to the full path of the application shutdown script in the configuration file, and the application shutdown script is executed to shut down the application to be detected, and the application startup script is called according to the full path of the application startup script in the configuration file, and the application startup script is executed to start the application to be detected.

[0008] In one embodiment, determining whether the process of the application to be detected is alive includes:

[0009] Determine the application to be detected according to the process keyword in the configuration file;

[0010] The application to be detected is accessed through an access command. When a correct response status is received, it is determined that the process of the application to be detected is in a live state; otherwise, it is determined that the process of the application to be detected is in a dead state.

[0011] In one embodiment, it further includes:

[0012] When executing the application shutdown script and determining that the application shutdown script is called manually, storing a specific file in a specified path;

[0013] Executing the application startup script to delete the specific file stored in the specified path;

[0014] Determining that the application to be detected is shut down abnormally includes:

[0015] During the execution of the self-detection script, if it is determined that the specified path does not store the specific file and the process of the application to be detected is in a non-surviving state, it is determined that the application to be detected is shut down abnormally; if it is determined that the specified path stores the specific file, it is determined that the application to be detected is shut down normally.

[0016] In one embodiment, it further includes:

[0017] When it is determined that the process of the application to be detected is in a live state, the self-detection script is executed to determine whether the application to be detected exists in the registration center; if not, the service registration script is called according to the full path of the service registration script in the configuration file, and the service registration script is executed to register the application to be detected in the registration center;

[0018] When it is determined that the application to be detected is shut down normally or abnormally, the self-detection script is executed to determine whether the application to be detected exists in the registration center. If so, the service removal script is called according to the full path of the service removal script in the configuration file, and the service removal script is executed to remove the application to be detected from the registration center.

[0019] In one embodiment,

[0020] Executing the service registration script to register the application to be detected in the registration center includes:

[0021] Executing the service registration script to write relevant information of the application to be detected into the registration center;

[0022] Executing the service removal script to remove the application to be detected from the registration center includes:

[0023] The service removal script is executed to delete the relevant information of the application to be detected in the registration center.

[0024] In one embodiment, the registration center is Zookeeper.

[0025] In one embodiment, calling a self-test script includes:

[0026] Set up scheduled tasks through crontab and call the self-test script according to the scheduled tasks.

[0027] The present invention also provides a software system maintenance device to solve the technical problems of high cost and high operational difficulty in software system maintenance due to the need for additional load balancing servers in the prior art. The device includes:

[0028] A detection module is used to call a self-detection script, execute the self-detection script and determine whether the process of the application to be detected is alive according to the process keyword in the configuration file;

[0029] A maintenance module is used to determine that the process of the application to be detected is in a non-surviving state and that the application to be detected is abnormally shut down, and then call the application shutdown script according to the full path of the application shutdown script in the configuration file, execute the application shutdown script to shut down the application to be detected, and call the application startup script according to the full path of the application startup script in the configuration file, and execute the application startup script to start the application to be detected.

[0030] In one embodiment, the detection module includes:

[0031] A survival status detection unit is used to determine the application to be detected based on the process keyword in the configuration file; access the application to be detected through an access command, and when a correct response status is received, it is determined that the process of the application to be detected is in a survival state; otherwise, it is determined that the process of the application to be detected is in a non-survival state.

[0032] In one embodiment, the maintenance module includes:

[0033] A shutdown unit, configured to store a specific file in a specified path when executing the application shutdown script and determining that the application shutdown script is called manually;

[0034] A startup unit, configured to execute the application startup script to delete the specific file stored in the specified path;

[0035] Determining that the application to be detected is shut down abnormally includes:

[0036] The shutdown status detection unit is used to determine that when the specific file is not stored in the designated path and the process of the application to be detected is in a non-survival state, the application to be detected is determined to be abnormally shut down; when it is determined that the specific file is stored in the designated path, the application to be detected is determined to be normally shut down.

[0037] In one embodiment, the maintenance module further includes:

[0038] A service registration unit is configured to, when determining that the process of the application to be detected is alive, execute the self-detection script to determine whether the application to be detected exists in the registration center; if not, call the service registration script according to the full path of the service registration script in the configuration file, and execute the service registration script to register the application to be detected in the registration center;

[0039] The service removal unit is used to execute the self-detection script to determine whether the application to be detected exists in the registration center when it is determined that the application to be detected is shut down normally or abnormally. If so, the service removal script is called according to the full path of the service removal script in the configuration file, and the service removal script is executed to remove the application to be detected from the registration center.

[0040] In one embodiment, the service registration unit includes:

[0041] A service registration subunit, configured to execute the service registration script to write relevant information of the application to be detected into the registration center;

[0042] Service removal unit, including:

[0043] The service removal subunit is configured to execute the service removal script to delete the relevant information of the application to be detected in the registration center.

[0044] In one embodiment, the registration center is Zookeeper.

[0045] In one embodiment, the detection module includes:

[0046] The calling unit is used to set a scheduled task through crontab and call the self-test script according to the scheduled task.

[0047] An embodiment of the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the maintenance method of any of the above-mentioned software systems to solve the technical problems in the prior art of high cost and high operational difficulty of software system maintenance due to the need for additional load balancing servers.

[0048] An embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program for executing any of the above-mentioned software system maintenance methods to solve the technical problems in the prior art of high cost and high operational difficulty caused by the need for additional load balancing servers for software system maintenance.

[0049] In an embodiment of the present invention, a method is proposed to detect the survival status of the process of the application to be detected based on a self-detection script. When it is determined that the process of the application to be detected is in a non-survival state and that the application to be detected is abnormally shut down, the application shutdown script is called according to the full path of the application shutdown script in the configuration file, and the application shutdown script is executed to shut down the application to be detected, thereby achieving normal shutdown of the application to be detected. The application startup script is called according to the full path of the application startup script in the configuration file, and the application startup script is executed to start the application to be detected, thereby achieving normal startup of the application to be detected. Compared with the technical solution in the prior art that relies on a load balancing server to provide a heartbeat detection mechanism to maintain a software system, a detection mechanism for automatically detecting the survival status and shutdown status of an application through a self-detection script is realized, and the normal startup of the application is automatically achieved based on the application shutdown script and the application startup script, that is, the self-recovery of the application is achieved, which is conducive to ensuring the high availability of the information system. At the same time, this maintenance method is easy to operate and does not require the addition of additional high-availability servers, which is conducive to reducing costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention. In the drawings:

[0051] Figure 1 This is a flowchart of a software system maintenance method provided by an embodiment of the present invention;

[0052] Figure 2 Schematic diagram of a scenario for implementing the maintenance method of the above-mentioned software system provided by an embodiment of the present invention;

[0053] Figure 3 is a flowchart of a maintenance method for implementing the above software system provided by an embodiment of the present invention;

[0054] Figure 4 This is a structural block diagram of a computer device provided by an embodiment of the present invention;

[0055] Figure 5 This is a structural block diagram of a maintenance device for a software system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the exemplary embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0057] In an embodiment of the present invention, a method for maintaining a software system is provided, such as Figure 1 As shown, the method includes:

[0058] Step 102: calling a self-test script, executing the self-test script to determine whether the process of the application to be tested is alive according to the process keyword in the configuration file;

[0059] Step 104: If not, and it is determined that the application to be detected is shut down abnormally, the application shutdown script is called according to the full path of the application shutdown script in the configuration file, and the application shutdown script is executed to shut down the application to be detected, and the application startup script is called according to the full path of the application startup script in the configuration file, and the application startup script is executed to start the application to be detected.

[0060] Depend on Figure 1 As can be seen from the process shown, in an embodiment of the present invention, it is proposed to detect the survival status of the process of the application to be detected based on the self-detection script. When it is determined that the process of the application to be detected is in a non-survival state and it is determined that the application to be detected is abnormally shut down, the application shutdown script is called according to the full path of the application shutdown script in the configuration file, and the application shutdown script is executed to shut down the application to be detected, thereby achieving normal shutdown of the application to be detected. The application startup script is called according to the full path of the application startup script in the configuration file, and the application startup script is executed to start the application to be detected, thereby achieving normal startup of the application to be detected. Compared with the technical solution in the prior art that relies on the load balancing server to provide a heartbeat detection mechanism to maintain the software system, this method realizes a detection mechanism that automatically detects the survival status and shutdown status of the application through the self-detection script, and automatically realizes the normal startup of the application based on the application shutdown script and the application startup script, that is, realizes self-recovery of the application, which is conducive to ensuring the high availability of the information system. At the same time, this maintenance method is easy to operate and does not require the addition of additional high-availability servers, which is conducive to reducing costs.

[0061] During specific implementation, the above-mentioned application to be tested can be an application deployed in a Web container. The container is a commonly used middleware. The so-called middleware is software that provides a connection between system software and application software to facilitate communication between various software components. The middleware is between the operating system and the higher-level application. Its function is to isolate the application running environment from the operating system, so that application developers do not have to worry about more system problems, but can directly focus on the application's ability to solve problems. The container can provide an environment for the application components therein, allowing the application to interact directly with the environment variables in the container without having to worry about other system problems. For example: tomcat (servlet container), Jboss (EJB container), the interfaces provided by these containers strictly comply with the web application standards in the J2EE specification.

[0062] In specific implementation, the scenario of implementing the maintenance method of the above software system is as follows Figure 2 As shown, the application is deployed in a Web container, and users can access the application through http requests. The maintenance method of the above software system can be run in the server background. The server background calls and executes the self-detection script to determine whether the application process is alive. If it is alive, it will continue to perform the next round of scanning after sleeping for a specified interval. If the application process is not alive, it is determined whether it is an abnormal shutdown. If it is an abnormal shutdown, the application shutdown script is called to shut down the application to achieve normal shutdown of the application, and then the application startup script is called to start the application to achieve restart of the application.

[0063] In specific implementation, the calling of the self-test script can be flexibly set to a timer based on the characteristics of the application to be tested, for example, Figure 2 As shown, you can set up a scheduled task through crontab, and then call the self-test script according to the scheduled task. Specifically, the scheduled task can be executed by either the root user or the application user. Using the application user can better ensure system security.

[0064] The crontab command, commonly found in Unix and Unix-like operating systems, is used to schedule periodic commands. It reads commands from standard input and stores them in a file called "crontab" for later reading and execution. Typically, commands stored in crontab are activated by a daemon process, which often runs in the background, checking for scheduled jobs, often called cron jobs.

[0065] In practice, the software system maintenance method, based on self-detection scripts, can implement a self-detection mechanism compatible with multiple web containers. Simply by adjusting the corresponding process keyword for the container and the startup and shutdown scripts for the corresponding container application in the configuration file, flexible calls can be made to automatically detect and recover from exceptions in different web containers. Specifically, the configuration file settings can include information such as the process keyword, the full path of the application shutdown script, the full path of the application startup script, and the log file path, as shown in the example below.

[0066]

[0067] Specifically, the process keyword can be determined based on the web container type, and the full file paths of the startup and shutdown scripts can be adjusted simultaneously. This supports a variety of mainstream web containers, including Tomcat, WebLogic, and JBoss. The FileFlag identifier is used to record whether the application was shut down normally or abnormally (accidentally).

[0068] During specific implementation, in the process of executing the self-detection script, it is possible to determine whether the application process is in a survival state in the following ways. For example, the application to be detected is determined based on the process keyword in the configuration file, that is, the process containing the process keyword exists, and then the application to be detected is accessed through an access command. When the correct response status is received, it is determined that the process of the application to be detected is in a survival state. Otherwise, it is determined that the process of the application to be detected is in a non-survival state.

[0069] Specifically, the web application can be accessed through the curl command. If the web application can return a correct http response status code, it indicates that the process of the web application is alive. Otherwise, it indicates that the process of the web application is dead.

[0070] In specific implementation, the so-called normal shutdown of an application refers to shutting down the application by manually calling the application shutdown script; and the abnormal shutdown of an application refers to the cessation of the application service due to unexpected reasons. In order to conveniently and accurately determine whether the application is shut down abnormally, in this embodiment, the application shutdown script is improved. On the basis of being able to shut down the application, the application shutdown script can also determine whether the call to the application shutdown script is a manual call. When it is determined that the call to the application shutdown script is a manual call, a specific file appisshutdown is stored in the specified path. In this way, based on whether the specific file appisshutdown exists, it can be determined whether the application is shut down normally or abnormally. For example, the way to improve the application shutdown script may be to add the following content on the basis of the logic of the original application shutdown script:

[0071]

[0072] Specifically, improvements have been made to the application startup script. During the execution of the application startup script, in addition to starting the application, the specific file appisshutdown stored in the specified path can also be deleted to indicate that the application is in a normal restart state and no longer in an abnormal shutdown state. For example, the application startup script can be improved by adding the following content to the original application startup script logic:

[0073]

[0074]

[0075] In specific implementation, after improving the application shutdown script and the application startup script, it is possible to determine whether the application to be detected is abnormally shut down through the following steps based on the specific file. For example, when executing the self-detection script, it is determined that the specified path does not store the specific file, and the process of the application to be detected is in a dead state, that is, the process of the application to be detected is dead and does not belong to manually calling the application shutdown script to shut down the application, indicating that the application service is stopped due to an unexpected reason, and the application to be detected is determined to be abnormally shut down; when it is determined that the specified path stores the specific file, it means that the application is shut down by manually calling the application shutdown script, and the application to be detected is determined to be normally shut down. When it is determined that the specified path does not store the specific file and the process of the application to be detected is alive, it means that the application is serving normally.

[0076] During specific implementation, for scenarios of distributed applications or microservice applications, since applications often need to be registered in a registration center, in order for the maintenance method of the above-mentioned software system to be applicable to scenarios of distributed applications or microservice applications, in this embodiment, the above-mentioned self-detection script can also automatically remove and register the application in the registration center according to the different states of the application to be detected. For example, when it is determined that the process of the application to be detected is in a live state, the self-detection script is executed to determine whether the application to be detected exists in the registration center. If not, it means that the application to be detected is not registered in the registration center. Then, the service registration script is called according to the full path of the service registration script in the configuration file, and the service registration script is executed to register the application to be detected in the registration center. If so, it means that the application to be detected has been registered in the registration center, and this detection is skipped.

[0077] When it is determined that the application to be detected is shut down normally or abnormally, the self-detection script is executed to determine whether the application to be detected exists in the registration center. If so, it means that the application to be detected has been registered in the registration center. The service removal script is called according to the full path of the service removal script in the configuration file, and the service removal script is executed to remove the application to be detected from the registration center. Then, the application restart process is performed. After the application is restarted, the application is registered in the registration center. If not, it means that the application to be detected is not registered in the registration center, and this detection is skipped.

[0078] In a microservices architecture, each microservice registers its network address and other information with the registry upon startup. The registry stores this data. Service consumers query the registry for the address of service providers and use this address to call the service provider's API. Each microservice communicates with the registry using a mechanism (such as a heartbeat). If the registry loses communication with a microservice for an extended period, the instance is deregistered.

[0079] During specific implementation, the registration center may be Zookeeper.

[0080] Specifically, ZooKeeper is a commonly used registry implementation technology. Specifically, ZooKeeper is a distributed, open-source coordination service for distributed applications. It is an open-source implementation of Google's Chubby and a key component of Hadoop and HBase. It provides consistency services for distributed applications, including configuration maintenance, domain name services, distributed synchronization, and group services.

[0081] In a specific implementation, the process of executing the service registration script to register the application to be detected in the registration center may be: executing the service registration script to write the relevant information of the application to be detected in the registration center;

[0082] The process of executing the service removal script to remove the application to be detected from the registration center may be: executing the service removal script to delete the relevant information of the application to be detected in the registration center.

[0083] In specific implementation, the maintenance method of the above software system is based on a mechanism in which an automatic detection script can perform service status detection, service registration and removal of applications. Service registration and removal can be adjusted and expanded according to the specific implementation technology of the registration center.

[0084] In specific implementation, the following Figure 3 The process of implementing the maintenance method of the above software system is described in detail, and the process includes the following steps:

[0085] 301. Write a configuration file for the self-test script, set the application process keyword, the full path of the application startup script file, the full path of the application shutdown script file, the log file path, and other information;

[0086] 302. Adjust the application shutdown script and add content based on the original logic so that when the application shutdown script is called manually, a specific file is stored in the specified path:

[0087] 303. Adjust the application startup script and add content based on the original logic so that the specific file stored in the specified path is deleted when the application startup script is executed:

[0088] 304. Write an automatic detection script to implement the logic of automatic detection of application status, automatic startup of application, automatic shutdown of application, automatic registration and removal, etc. The details are as follows:

[0089] Check whether the specific file appisshutdown exists in the specified path. If so, it means that the application was shut down normally by manually calling the application shutdown script. At this time, check whether the application exists in the registration center. If the application exists in the registration center, call the service removal script to remove the application node from the registration center; otherwise, directly exit this round of detection.

[0090] If the specific file appisshutdown does not exist in the specified path, the application process is checked for alive status based on the process keyword in the configuration file and the response status of the curl command accessing the application URL. If it is alive, the application is normal. Then, the application is checked for alive status in the registration center. If it exists, the application is registered, and this check is skipped. If it does not exist, the application is not registered, and the service registration script is called to register the application node in the registration center.

[0091] If the process is in a dead state, it means that the program has unexpectedly crashed, which is an abnormal shutdown. In this case, we will first determine whether the application exists in the registration center. If it exists, that is, the application has been registered, and we need to call the service removal script to remove the application node from the registration center.

[0092] Then call the application shutdown script in the configuration file to shut down the application normally, and then call the application startup script in the configuration file to start the application normally. After the application starts normally, it is necessary to call the service registration script to register the application in the registration center.

[0093] 305. Set up a scheduled task through crontab and call the automatic detection script in step 304 regularly.

[0094] You can flexibly configure the automatic detection execution cycle and log output directory by adjusting the crantab expression according to the actual needs of the business scenario.

[0095] In specific implementation, the maintenance method of the above software system can be used not only for automatic detection and high availability of stand-alone applications, but also supports automatic detection and high availability of cluster environments. By adjusting the process keyword to a process related to the load balancer, automatic detection and recovery of the load balancer can be achieved, providing high availability guarantees. Whether it is a general application, microservice, load balancing middleware or other scenarios that require self-recovery, the maintenance method of the above software system can be used to achieve automatic detection and recovery of application status. The high availability solution implemented by the maintenance method of the above software system is decoupled from the business and is imperceptible to developers and customers. It can also support the automatic removal and registration of service nodes in distributed or microservice scenarios.

[0096] In this embodiment, a computer device is provided, such as Figure 4 As shown, it includes a memory 402, a processor 404 and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, any of the above-mentioned software system maintenance methods is implemented.

[0097] Specifically, the computer device may be a computer terminal, a server or a similar computing device.

[0098] In this embodiment, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program for executing any of the above-mentioned software system maintenance methods.

[0099] Specifically, computer-readable storage media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer-readable storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable storage media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0100] Based on the same inventive concept, an embodiment of the present invention further provides a maintenance device for a software system, as described in the following embodiments. Since the principle of solving the problem by the maintenance device for a software system is similar to that of the maintenance method for a software system, the implementation of the maintenance device for a software system can refer to the implementation of the maintenance method for a software system, and the repeated parts will not be repeated. As used below, the term "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and conceivable.

[0101] Figure 5 This is a structural block diagram of a maintenance device for a software system according to an embodiment of the present invention. Figure 5 As shown, the device includes:

[0102] A detection module 502 is configured to call a self-detection script, execute the self-detection script, and determine whether the process of the application to be detected is alive based on the process keyword in the configuration file;

[0103] The maintenance module 504 is used to determine that the process of the application to be detected is in a non-surviving state and that the application to be detected is abnormally shut down, and then call the application shutdown script according to the full path of the application shutdown script in the configuration file, execute the application shutdown script to shut down the application to be detected, and call the application startup script according to the full path of the application startup script in the configuration file, and execute the application startup script to start the application to be detected.

[0104] In one embodiment, the detection module includes:

[0105] A survival status detection unit is used to determine the application to be detected based on the process keyword in the configuration file; access the application to be detected through an access command, and when a correct response status is received, it is determined that the process of the application to be detected is in a survival state; otherwise, it is determined that the process of the application to be detected is in a non-survival state.

[0106] In one embodiment, the maintenance module includes:

[0107] A shutdown unit, configured to store a specific file in a specified path when executing the application shutdown script and determining that the application shutdown script is called manually;

[0108] A startup unit, configured to execute the application startup script to delete the specific file stored in the specified path;

[0109] Determining that the application to be detected is shut down abnormally includes:

[0110] The shutdown status detection unit is used to determine that when the specific file is not stored in the designated path and the process of the application to be detected is in a non-survival state, the application to be detected is determined to be abnormally shut down; when it is determined that the specific file is stored in the designated path, the application to be detected is determined to be normally shut down.

[0111] In one embodiment, the maintenance module further includes:

[0112] A service registration unit is configured to, when determining that the process of the application to be detected is alive, execute the self-detection script to determine whether the application to be detected exists in the registration center; if not, call the service registration script according to the full path of the service registration script in the configuration file, and execute the service registration script to register the application to be detected in the registration center;

[0113] The service removal unit is used to execute the self-detection script to determine whether the application to be detected exists in the registration center when it is determined that the application to be detected is shut down normally or abnormally. If so, the service removal script is called according to the full path of the service removal script in the configuration file, and the service removal script is executed to remove the application to be detected from the registration center.

[0114] In one embodiment, the service registration unit includes:

[0115] A service registration subunit, configured to execute the service registration script to write relevant information of the application to be detected into the registration center;

[0116] Service removal unit, including:

[0117] The service removal subunit is configured to execute the service removal script to delete the relevant information of the application to be detected in the registration center.

[0118] In one embodiment, the registration center is Zookeeper.

[0119] In one embodiment, the detection module includes:

[0120] The calling unit is used to set a scheduled task through crontab and call the self-test script according to the scheduled task.

[0121] The embodiment of the present invention achieves the following technical effects: it proposes a method for detecting the survival status of the process of the application to be detected based on a self-detection script, and when it is determined that the process of the application to be detected is in a non-survival state and that the application to be detected is abnormally shut down, the application shutdown script is called according to the full path of the application shutdown script in the configuration file, and the application shutdown script is executed to shut down the application to be detected, thereby achieving normal shutdown of the application to be detected, and the application startup script is called according to the full path of the application startup script in the configuration file, and the application startup script is executed to start the application to be detected, thereby achieving normal startup of the application to be detected. Compared with the technical solution in the prior art that relies on a load balancing server to provide a heartbeat detection mechanism to maintain a software system, a detection mechanism for automatically detecting the survival status and shutdown status of an application through a self-detection script is realized, and normal startup of the application is automatically achieved based on the application shutdown script and the application startup script, that is, self-recovery of the application is achieved, which is conducive to ensuring the high availability of the information system. At the same time, this maintenance method is easy to operate and does not require the addition of additional high-availability servers, which is conducive to reducing costs.

[0122] Although the present invention provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative work. The order of steps listed in the embodiments is only one way of executing the steps among many steps and does not represent the only execution order. When an actual device or client product is executed, the method can be executed sequentially or in parallel according to the embodiments or the accompanying drawings (for example, in a parallel processor or multi-threaded processing environment).

[0123] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, devices (systems), or computer program products. Thus, the embodiments of this specification may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

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

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

[0127] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments may be referred to in conjunction with each other. Each embodiment focuses on the differences from the other embodiments. In particular, the system embodiments, since they are generally similar to the method embodiments, are described more simply. For relevant details, refer to the description of the method embodiments. In this document, relational terms such as first and second, etc., are used solely to distinguish one entity or operation from another and do not necessarily require or imply any actual relationship or order between these entities or operations. Furthermore, the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. Terms such as "upper" and "lower" to indicate orientations or positional relationships are based on those shown in the accompanying drawings and are intended solely to facilitate the description of the present invention and simplify the description. They are not intended to indicate or imply that the devices or elements referred to must have, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limitations on the present invention. Unless otherwise expressly specified and limited, the terms "installed", "connected" and "connected" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or an indirect connection through an intermediate medium, or it can be a communication between the two components. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances. It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other. The present invention is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or permutation of these aspects and / or embodiments. Moreover, each aspect and / or embodiment of the present invention can be used alone or in combination with one or more other aspects and / or embodiments thereof.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention, and they should all be included in the scope of the claims and description of the present invention.

Claims

1. A software system maintenance method, characterized in that: include: Determine whether a specific file exists in the specified path: If a specific file exists under the specified path, determine whether the application to be detected exists in the registration center. If the application to be detected exists in the registration center, call the service removal script to remove the application node to be detected from the registration center; otherwise, directly exit this round of detection; when the application shutdown script is called manually, a specific file is stored in the specified path. The normal shutdown of the application is to shut down the application by manually calling the application shutdown script; If the specific file does not exist under the specified path, call the self-detection script, execute the self-detection script to determine whether the process of the application to be detected is alive according to the process keyword in the configuration file; the application to be detected is an application deployed in a Web container; the configuration file includes the process keyword, the full path of the application shutdown script, the full path of the application startup script, and the log file path information; If it is in the survival state, determine whether the application to be detected exists in the registration center. If it exists, skip this detection; if it does not exist, call the service registration script to register the application node to be detected in the registration center; If it is in a non-survival state, first determine whether the application to be detected exists in the registration center. If it exists, call the service removal script to remove the application node to be detected in the registration center, and then call the application shutdown script in the configuration file to first shut down the application to be detected normally, and then call the application startup script in the configuration file to start the application to be detected normally. After the application to be detected starts normally, call the service registration script to register the application to be detected in the registration center; wherein the application startup script is executed to delete the specific file stored in the specified path to indicate that the application is in a normal restart state and is no longer in an abnormal shutdown state.

2. The software system maintenance method according to claim 1, characterized in that: Determine whether the process of the application to be detected is alive, including: Determine the application to be detected according to the process keyword in the configuration file; The application to be detected is accessed through an access command. When a correct response status is received, it is determined that the process of the application to be detected is in a live state; otherwise, it is determined that the process of the application to be detected is in a dead state.

3. The software system maintenance method according to claim 1, characterized in that: Also includes: When it is determined that the process of the application to be detected is in a live state, the self-detection script is executed to determine whether the application to be detected exists in the registration center. If not, the service registration script is called according to the full path of the service registration script in the configuration file, and the service registration script is executed to register the application to be detected in the registration center; When it is determined that the application to be detected is shut down normally or abnormally, the self-detection script is executed to determine whether the application to be detected exists in the registration center. If so, the service removal script is called according to the full path of the service removal script in the configuration file, and the service removal script is executed to remove the application to be detected from the registration center.

4. The software system maintenance method according to claim 3, characterized in that: Executing the service registration script to register the application to be detected in the registration center includes: Execute the service registration script to write relevant information of the application to be detected in the registration center; Executing the service removal script to remove the application to be detected from the registration center includes: The service removal script is executed to delete the relevant information of the application to be detected in the registration center.

5. The software system maintenance method according to claim 3, characterized in that: The registration center is zookeeper.

6. The software system maintenance method according to any one of claims 1 to 5, characterized in that: Call the self-test script, including: Set up scheduled tasks through crontab and call the self-detection script according to the scheduled tasks.

7. A software system maintenance device, characterized in that: include: The detection module is used to determine whether a specific file exists under the specified path: if a specific file exists under the specified path, determine whether the application to be detected exists in the registration center. If the application to be detected exists in the registration center, it is necessary to call the service removal script to remove the application node to be detected in the registration center; otherwise, directly jump out of this round of detection; wherein, when the application shutdown script is called manually, a specific file is stored in the specified path, and the normal shutdown of the application is to close the application by manually calling the application shutdown script; if the specific file does not exist under the specified path, call the self-detection script, execute the self-detection script to determine whether the process of the application to be detected is alive according to the process keyword in the configuration file; the application to be detected is an application deployed in a Web container; the configuration file settings include process keywords, the full path of the application shutdown script, the full path of the application startup script, and log file path information; The maintenance module is used to determine whether the application to be detected exists in the registration center if it is in the survival state, and if so, skip this detection; if not, call the service registration script to register the application node to be detected in the registration center; if it is in the non-survival state, first determine whether the application to be detected exists in the registration center, if so, call the service removal script to remove the application node to be detected in the registration center, and then call the application shutdown script in the configuration file to first shut down the application to be detected normally, and then call the application startup script in the configuration file to start the application to be detected normally. After the application to be detected starts normally, call the service registration script to register the application to be detected in the registration center; wherein the application startup script is executed to delete the specific file stored in the specified path to indicate that the application is in a normal restart state and is no longer in an abnormal shutdown state.

8. The software system maintenance device according to claim 7, characterized in that: Detection module, including: The survival status detection unit is used to determine the application to be detected according to the process keyword in the configuration file; access the application to be detected through an access command, and when a correct response status is received, it is judged that the process of the application to be detected is in a survival state; otherwise, it is judged that the process of the application to be detected is in a non-survival state.

9. The software system maintenance device according to claim 8, characterized in that: The maintenance module also includes: A service registration unit, configured to, when it is determined that the process of the application to be detected is in a live state, execute the self-detection script to determine whether the application to be detected exists in a registration center, and if not, call the service registration script according to the full path of the service registration script in the configuration file, and execute the service registration script to register the application to be detected in the registration center; The service removal unit is used to execute the self-detection script to determine whether the application to be detected exists in the registration center when it is determined that the application to be detected is shut down normally or abnormally. If so, the service removal script is called according to the full path of the service removal script in the configuration file, and the service removal script is executed to remove the application to be detected from the registration center.

10. The software system maintenance device according to claim 8, characterized in that: Service registration unit, including: A service registration subunit, configured to execute the service registration script to write relevant information of the application to be detected in the registration center; Service removal unit, including: The service removal subunit is used to execute the service removal script to delete the relevant information of the application to be detected in the registration center.

11. The software system maintenance device according to claim 8, characterized in that: The registration center is zookeeper.

12. The software system maintenance device according to any one of claims 7 to 11, characterized in that: Detection module, including: The calling unit is used to set a scheduled task through crontab and call the self-detection script according to the scheduled task.

13. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the software system maintenance method according to any one of claims 1 to 6 is implemented.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program for executing the software system maintenance method according to any one of claims 1 to 6.

Images