Program service self-recovery method and device, storage medium and terminal

Abstract

The application discloses a program service self-recovery method and device, a storage medium and a terminal, wherein the method comprises the following steps: obtaining a health state query request of a target program service, and judging whether the target program service is in a normal running state through a program service health judgment mode based on the health state query request; if yes, the next step is determined; otherwise, a restart instruction is sent to the target program service, and an alarm signal is sent to a monitoring center station; judging whether the middleware in the target program service needs to be restarted through a program service middleware judgment mode based on the health state query request; if yes, a restart instruction is sent to the target program service, and an alarm signal is sent to the monitoring center station; otherwise, the middleware in the target program service is updated through a program service middleware updating mode. The application realizes automatic recovery of the program service, avoids that the program is in an abnormal and unstable state for a long time, and causes great loss for daily business operation.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method and apparatus for self-recovery of program services, a storage medium, and a terminal. Background Technology

[0002] During the operation of existing program services, various reasons may cause the service to fail to provide services to the outside world. For example, the program service may appear to be dead, that is, the program service is running, but the service protocol it provides is in a stagnant state. Most of the existing keep-alive probes used for health checks can only check whether the program service process exists, but cannot monitor the status of the service protocol provided by the program service. Therefore, the reliability of the check results is not high.

[0003] For example, if the middleware parameter settings in a program service are no longer sufficient for the current operation, a restart is needed to release the data cache pressure or to update the parameters. However, the systems that currently support program services often lack self-recovery capabilities. The current program services will only attempt to restart when the program service process exits, or will only resume normal operation after the parameters are modified and restarted. This leaves the program services in an abnormal and unstable state for a long time, causing huge losses to daily business operations. Summary of the Invention

[0004] The technical problem that this invention aims to solve is that when a program service fails to provide services due to reasons such as freezing or the need to update middleware, it cannot automatically recover. This results in the program service being in an abnormal and unstable state for a long time, causing huge losses to daily business operations.

[0005] To address the aforementioned technical problems, this invention provides a method for self-recovery of program services, comprising:

[0006] Obtain a health status query request for the target program service, and based on the health status query request, determine whether the target program service is in normal operation through the program service health judgment method. If it is, proceed to the next step of judgment; otherwise, send a restart command to the target program service and send an alarm signal to the monitoring center.

[0007] Based on the health status query request, the middleware in the target program service is determined by the program service middleware determination method. If it needs to be restarted, a restart command is sent to the target program service and an alarm signal is sent to the monitoring platform. Otherwise, the middleware in the target program service is updated by the program service middleware update method.

[0008] Preferably, determining whether the target program service is in normal operating condition based on the health status query request and through a program service health judgment method includes:

[0009] Based on the health status query request, determine whether the target program service process exists in the operating system. If it does, it means that the target program service is running. Otherwise, send an alarm message to the monitoring platform.

[0010] Obtain all currently connected TCP ports of the target program service, and compile the obtained TCP port set into a target TCP port set;

[0011] Obtain the application service protocols provided by the target program service under normal operating conditions, and combine all the obtained application service protocols into a target application service protocol set;

[0012] Based on the preset invocation method, it is determined whether any application service protocol in the target application service protocol set has a TCP port in the target TCP port set that has made a request. If so, it indicates that the target program service is in normal operation. Otherwise, it indicates that the target program service is running abnormally, and an alarm message is sent to the monitoring platform.

[0013] Preferably, obtaining the application service protocol provided by the target program service under normal operating conditions includes:

[0014] Based on the program deployment path of the target program service, obtain the executable file and dependent libraries of the target program service;

[0015] The executable files and dependent libraries of the target program service are analyzed to obtain the original language code corresponding to each executable file and the original language code corresponding to each dependent library.

[0016] The original language code corresponding to all executable files and the original language code corresponding to all dependent libraries are compared with the application service protocol code in the application service protocol code library to obtain all application service protocols provided by the target program service.

[0017] The application service protocol code library includes all application service protocol codes.

[0018] Preferably, determining whether the middleware in the target program service needs to be restarted through a program service middleware determination method includes:

[0019] Obtain the middleware identifier of the middleware that has been started in the current target program service, and obtain the corresponding indicator data of the middleware based on the middleware identifier;

[0020] The dynamic modification rule file of the target program service is obtained from the configuration center based on the configuration file address, and the dynamic modification rule of the corresponding middleware is obtained from the dynamic modification rule file based on each middleware identifier.

[0021] Based on the metric data and dynamic modification rules of each middleware, it is determined whether the corresponding middleware needs to be restarted. If a middleware needs to be restarted, it is determined that the middleware in the target program service needs to be restarted; otherwise, it is determined that the middleware in the target program service does not need to be restarted.

[0022] Preferably, updating the middleware in the target program service via a process service middleware update method includes:

[0023] Obtain the middleware identifier of the middleware that has been started in the current target program service, and obtain the corresponding indicator data of the middleware based on the middleware identifier;

[0024] The dynamic modification rule file of the target program service is obtained from the configuration center based on the configuration file address, and the dynamic modification rule of the corresponding middleware is obtained from the dynamic modification rule file based on each middleware identifier.

[0025] Based on the index data and dynamic modification rules of each middleware, it is determined whether the parameters of the corresponding middleware need to be modified. If so, the parameters of the corresponding middleware are modified according to the corresponding dynamic modification rules; otherwise, the parameters of the corresponding middleware remain unchanged.

[0026] The program service middleware update method is implemented based on middleware indicator probes.

[0027] Preferably, before the step of obtaining the middleware identifier of the middleware that has been started in the current target program service, and obtaining the corresponding indicator data of the middleware based on the middleware identifier, the method further includes:

[0028] Obtain startup-related parameters, including status instructions and configuration file addresses;

[0029] If the status instruction is to start the middleware indicator probe service, then determine whether the middleware indicator probe is started. If it is started, the middleware indicator probe maintains its current state; otherwise, the middleware indicator probe is started.

[0030] If the status instruction is to stop the middleware indicator probe service, then release the middleware indicator probe resources and stop the middleware indicator probe service.

[0031] If the status instruction is to upgrade the middleware indicator probe service, then release the middleware indicator probe resources, stop the middleware indicator probe service, and then restart the middleware indicator probe service.

[0032] Preferably, the middleware types in the target program service include network connection pools, thread pools, and local cache pools.

[0033] To address the aforementioned technical problems, the present invention also provides a program service self-recovery device, including a program service health assessment module and a middleware update module;

[0034] The program service health assessment module is used to obtain the health status query request of the target program service, and based on the health status query request, determine whether the target program service is in normal operation through the program service health assessment method. If it is, proceed to the next step of the assessment; otherwise, send a restart command to the target program service and send an alarm signal to the monitoring platform.

[0035] The middleware update module is used to determine whether the middleware in the target program service needs to be restarted based on the health status query request and through the program service middleware determination method. If so, it sends a restart command to the target program service and sends an alarm signal to the monitoring platform; otherwise, it updates the middleware in the target program service through the program service middleware update method.

[0036] To address the aforementioned technical problems, the present invention also provides a storage medium storing a computer program, characterized in that the program service self-recovery method is provided when the program is executed by a processor.

[0037] To address the aforementioned technical problems, the present invention also provides a terminal, comprising: a processor and a memory, wherein the memory and the processor are communicatively connected;

[0038] The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to enable the terminal to perform a program service self-recovery method.

[0039] Compared with the prior art, one or more embodiments of the above solutions may have the following advantages or beneficial effects:

[0040] The program service self-recovery method provided in this invention first determines the running status of the program service through a program service health assessment. If the program service is in an abnormal state, it can be directly restarted to achieve self-recovery. If the program service is in a normal running state, the middleware status within the program service needs to be further assessed to determine if any middleware parameters are no longer sufficient for the program service's operation and can only be restored to normal operation by restarting the program to relieve pressure. If so, the program service is directly restarted to achieve self-recovery, reducing losses in daily business operations. Furthermore, if the middleware parameters can be updated through modification, self-recovery is achieved by updating the middleware parameters. This invention enables automatic recovery of program services, preventing programs from being in an abnormal and unstable state for extended periods, thus avoiding significant losses to daily business operations.

[0041] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the description, claims, and drawings. Attached Figure Description

[0042] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0043] Figure 1 A flowchart illustrating the program service self-recovery method according to Embodiment 1 of the present invention is shown;

[0044] Figure 2 A schematic diagram of the structure of the program service self-recovery device according to Embodiment 2 of the present invention is shown;

[0045] Figure 3 A schematic diagram of the terminal structure of Embodiment 4 of the present invention is shown. Detailed Implementation

[0046] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples, so that the process of how the present invention uses technical means to solve technical problems and achieve technical effects can be fully understood and implemented accordingly. It should be noted that, as long as there is no conflict, the various embodiments and features in the various embodiments of the present invention can be combined with each other, and the resulting technical solutions are all within the protection scope of the present invention.

[0047] TCP (Transmission Control Protocol) represents the Transmission Control Protocol. Monitoring middleware services to determine whether the middleware is running normally or to obtain corresponding metric data is usually achieved through middleware metric probes. A middleware metric probe is a program (such as the Skywalking probe or the Zabbix probe) used to obtain or modify the runtime metrics of third-party software used by the service, that is, to measure one or a set of dimensions of the middleware's operational status. Middleware metric probes are usually hosted in the program service and start together with the program service. That is, there is a one-to-one relationship between the middleware metric probe and the program service in the operating system, and each middleware metric probe has a corresponding program service.

[0048] To accurately identify program service freezes and issues where middleware parameters fail to meet operational requirements, necessitating updates or restarts to restore normal operation, and to prevent programs from remaining in abnormal and unstable states for extended periods, thus causing significant losses to daily business operations, this invention provides a program service self-recovery method, apparatus, storage medium, and terminal.

[0049] Example 1

[0050] To address the problems existing in the prior art, this invention provides a method for self-recovery of program services.

[0051] Figure 1 A flowchart illustrating the self-recovery method for program services according to Embodiment 1 of the present invention is shown; see reference. Figure 1 As shown, the self-recovery method for program services in this embodiment of the invention includes the following steps.

[0052] Step S101: Obtain the health status query request of the target program service, and based on the health status query request, determine whether the target program service is in normal operation through the program service health judgment method. If so, proceed to the next step of judgment; otherwise, send a restart command to the target program service and send an alarm signal to the monitoring platform.

[0053] Specifically, monitoring program services to determine their normal operation or health is typically achieved through keep-alive probes or monitoring probes. These probes are housed in the same container as the monitored program service and are started together with the container. In this embodiment, the container is the operating system. The following program service health determination methods are implemented using keep-alive probes. To facilitate the explanation of the program service self-recovery method, this embodiment uses the target program service as an example. The target program service is any program service within the operating system.

[0054] After the keep-alive probe obtains the health status query request of the target program service, it needs to determine whether the target program service is in a normal operating state based on the health status query request and the program service health judgment method. If so, the next step needs to be judged. Otherwise, it can be directly determined that the target program service needs to be restarted to achieve self-recovery. Then, a restart command is sent to the target program service to achieve the restart of the target program service. At the same time, the monitoring center needs to send an alarm signal to inform the monitoring center that the target program service is currently in an abnormal state.

[0055] Furthermore, based on the health status query request, the process of determining whether the target program service is in normal operating condition through the program service health determination method specifically includes the following sub-steps.

[0056] Sub-step S1011: Based on the health status query request, determine whether the target program service process exists in the operating system. If it does, it means that the target program service is running; otherwise, send an alarm message to the monitoring platform.

[0057] Specifically, since the operating system sends corresponding process startup instructions when a program service process is running, when the keep-alive probe receives a health status query request for the target program service, it needs to send a startup instruction retrieval request to the operating system. Upon receiving the request, the operating system packages the process startup instructions of all currently running program services and sends it to the keep-alive probe. The keep-alive probe then further determines, based on the name or identifier of the target program service, whether the process startup instructions of all currently running program services include the target program service's process startup instruction. If so, it indicates that the target program service process exists in the operating system, meaning the target program service is running, and further evaluation can be performed. However, if the process startup instructions of all currently running program services do not include the target program service's process startup instruction, it indicates that the target program service is in a stagnant state. In this case, the keep-alive probe needs to send an alarm message to the monitoring platform to inform it that the target program service is in an abnormal state.

[0058] Sub-step S1012: Obtain all currently connected TCP ports of the target program service, and set the obtained TCP port set as the target TCP port set.

[0059] Specifically, the keep-alive probe sends network commands to the operating system. The operating system then uses these commands to obtain all current TCP connection information, including TCP ports and connection status. The keep-alive probe filters out the TCP connection information of the target program service from this information. Based on the connection status of this information, it identifies all TCP ports successfully connected to the target program service. Finally, it sets all successfully connected TCP ports into a target TCP port set. The keep-alive probe filters out the target program service's TCP connection information by using the socketinode corresponding to the target program service's TCP connection information.

[0060] Sub-step S1013: Obtain the application service protocols provided by the target program service under normal operating conditions, and combine all the obtained application service protocols into a target application service protocol set.

[0061] Specifically, the keep-alive probe obtains the executable files and dependent libraries of the target program service based on the program deployment path. The dependent libraries are functional modules that the program service can directly call, avoiding redundant development. Then, the executable files and dependent libraries of the target program service are analyzed using a preset method to obtain the original language code corresponding to all executable files and all dependent libraries. It should be noted that since executable files or dependent libraries may be implemented in different programming languages, they need to be analyzed in a way that corresponds to the programming language code of the executable file or dependent library. For example, if the executable file or dependent library is a Java program, ASM (Java Byte Manipulation Framework) can be used to read and analyze it to obtain the corresponding original language code. Decompilation techniques can also be used to decompile the executable file or dependent library to obtain the corresponding original language code. Preferably, the original language code is easily readable high-level programming language code.

[0062] After the keep-alive probe obtains the original language code corresponding to each executable file and each dependent library of the target program service, it needs to compare the original language code of all executable files and dependent libraries with the application service protocol code in the application service protocol code library to determine which application service protocol the executable file or dependent library belongs to. This method allows the acquisition of all application service protocols provided by the target program code under normal operating conditions. It should be noted that the application service protocol code library contains multiple application service protocol codes; to avoid missing any application service protocols during the comparison process, the application service protocol code should include as many of the currently obtainable application service protocol codes as possible.

[0063] The keep-alive probe then acquires all the application service protocol sets as the target application service protocol set, which will be used in subsequent steps.

[0064] Sub-step S1014: Based on the preset calling method, determine whether any application service protocol in the target application service protocol set has a TCP port in the target TCP port set that has made a request. If so, it means that the target program service is running normally; otherwise, it means that the target program service is running abnormally, and an alarm message is sent to the monitoring platform.

[0065] Specifically, for convenience, the operating system's local TCP call method can be used to call the application service protocols in the target application service protocol set, and to determine if any TCP port in the target TCP port set can accept the corresponding request. If it does, it indicates that the application service protocol in the target program service is running normally, and so on. When all application service protocols in the target application service protocol set have TCP ports in the target TCP port set accepting requests after being called, it indicates that all application service protocols in the target program service are running normally. Therefore, it can be determined that the target program service is running normally. However, if at least one application service protocol in the target application service protocol set fails to accept requests from all TCP ports in the target TCP port set, it indicates that the corresponding application service protocol is in an abnormal state, and it can be further determined that the target program service is running abnormally. In this case, an alarm message should be sent to the monitoring platform. It should be noted that other reasonable calling methods can also be used as the default calling method, which will not be elaborated on here.

[0066] Step S102: Based on the health status query request, determine whether the middleware in the target program service needs to be restarted through the program service middleware determination method. If so, send a restart command to the target program service and send an alarm signal to the monitoring platform. Otherwise, update the middleware in the target program service through the program service middleware update method.

[0067] Specifically, after confirming that the target program service is running normally, the running status of all middleware within it needs further evaluation. Specifically, based on the program service middleware determination method, it is necessary to first determine whether any middleware in the target program service needs to be restarted. If so, the target program service needs to be restarted to restart all middleware, thus achieving the goal of restarting middleware that requires a restart to function properly. Simultaneously, an alarm signal needs to be sent to the monitoring platform to inform it that the target program service is currently in an abnormal state. If no middleware in the target program needs to be restarted, the middleware in the target program service can be updated based on the program service middleware update method.

[0068] Furthermore, based on the health status query request, the method of determining whether the middleware in the target program service needs to be restarted includes the following sub-steps.

[0069] Sub-step S1021: Obtain startup-related parameters.

[0070] Specifically, under normal circumstances, after receiving a health status query request from the target program service, the keep-alive probe will obtain the startup-related parameters of the middleware indicator probe in the target program service based on the program service health status query request, and send them to the middleware indicator probe of the target program service. The startup-related parameters include a status command and a configuration file address. If the status command in the startup-related parameters is to start the middleware indicator probe service, it is necessary to determine whether the middleware indicator probe is started. If it is started, the middleware indicator probe maintains its current state; otherwise, it starts. If the status command in the startup-related parameters is to stop the middleware indicator probe service, the middleware indicator probe releases its resources and stops the middleware indicator probe service. If the status command in the startup-related parameters is to upgrade the middleware indicator probe service, the middleware indicator probe needs to release its resources, stop the middleware indicator probe service, and then restart the middleware indicator probe service to complete the middleware indicator probe upgrade.

[0071] Sub-step S1022: Obtain the middleware identifier of the middleware that has been started in the current target program service, and obtain the corresponding middleware's indicator data based on the middleware identifier.

[0072] Specifically, when a middleware metric probe is running, it can monitor and dynamically adjust the middleware within its associated program service. The program service to which the middleware metric probe belongs is set as the target program service. The middleware metric probe needs to determine which middleware in the current target program service is running and obtain the middleware identifiers of all running middleware in the current target program service. Then, based on the middleware identifiers of the running middleware, it starts the corresponding scheduled metric task for that middleware, so that the corresponding scheduled task obtains the metric data for that middleware. In other words, it achieves the acquisition of metric data for each running middleware based on its middleware identifier in the target program service. Middleware types can include local cache pools, network connection pools, thread pools, message queues, scheduled tasks, databases, and RPC calls, etc.; the data types of the acquired metrics also differ depending on the middleware type.

[0073] Sub-step S1023: Obtain the dynamic modification rule file of the target program service from the configuration center based on the configuration file address, and obtain the dynamic modification rule of the corresponding middleware from the dynamic modification rule file based on each middleware identifier.

[0074] Specifically, while obtaining the indicator data of each started middleware in the target program service, it is also necessary to download the dynamic modification rule file corresponding to the target program service from the configuration center based on the configuration file address in the startup-related parameters. This dynamic modification rule file stores the dynamic modification rules for all middleware in the target program service. The dynamic modification rules of the middleware are used as the criteria for middleware status judgment, middleware restart criteria, and parameter modification criteria. Then, based on the middleware identifier of each started middleware, the corresponding dynamic modification rule is obtained from the dynamic modification rule file, that is, the dynamic modification rule corresponding to each started middleware is obtained based on the middleware identifier of each started middleware.

[0075] Sub-step S1024: Based on the metric data and dynamic modification rules of each middleware, determine whether the parameters of the corresponding middleware need to be restarted. If there is a middleware that needs to be restarted, then determine that the middleware in the target program service needs to be restarted; otherwise, determine that the middleware in the target program service does not need to be restarted.

[0076] Specifically, after obtaining the metric data and dynamic modification rules for all started middleware in the target program service, the metric data and corresponding dynamic modification rules for each started middleware need to be compared to determine its state. For example, if a metric exceeds the threshold specified in the dynamic modification rules and the middleware cannot be updated by modifying its parameters, it indicates that the middleware is in an abnormal state. In this case, the middleware needs to be restarted by restarting the target program service, allowing it to recover to normal operation by releasing pressure. Conversely, if all metric data does not exceed the corresponding threshold in the dynamic modification rules, the middleware is in a normal state and does not require restarting or parameter updates.

[0077] If some or all middleware in the target program service needs to be restarted, then the target program service needs to be restarted. If none of the middleware in the target program service needs to be restarted, then the target program service does not need to be restarted.

[0078] The specific processes of sub-steps S1031, S1032, and S1033 in the process of updating the middleware in the target program service through the process service middleware update method are exactly the same as the sub-steps S1021, S1022, and S1023 in the process of determining whether the middleware in the target program service needs to be restarted based on the health status query request and the process service middleware determination method. The difference is that the specific process of sub-step S1034 in the process of updating the middleware in the target program service through the process service middleware update method is as follows.

[0079] Step S1034: Based on the indicator data and dynamic modification rules of each middleware, determine whether the parameters of the corresponding middleware need to be modified. If so, modify the parameters of the corresponding middleware according to the corresponding dynamic modification rules; otherwise, keep the parameters of the corresponding middleware unchanged.

[0080] Specifically, after obtaining the metric data and dynamic modification rules for all started middleware in the target program service, the metric data for each started middleware needs to be compared with its corresponding dynamic modification rule to determine the state of the corresponding started middleware. For example, if a certain data in the metric data exceeds the threshold specified in the dynamic modification rule, it indicates that the middleware is in an abnormal state; conversely, if all data in the metric data does not exceed the corresponding threshold in the dynamic modification rule, it indicates that the middleware is in a normal state.

[0081] If a middleware is in an abnormal state, it indicates that its parameters need to be adjusted to suit the current running state of the target program service; conversely, if a middleware is in a normal state, its parameters do not need adjustment. Furthermore, after determining the status of each started middleware, the determination result must be sent to the monitoring platform. Specifically, if it is determined that the parameters of the corresponding middleware need modification, an alarm signal must be sent to the monitoring platform; if it is determined that the parameters of the corresponding middleware do not need modification, a normal signal must be sent to the monitoring platform. Preferably, the middleware indicator probe communicates with the monitoring platform based on URL requests.

[0082] When it is determined that a parameter of a middleware needs to be modified, the middleware parameter must be modified according to the corresponding dynamic modification rules to make it suitable for the current running state of the target program service. After modification, an alarm service must be invoked to send a parameter modification completion message to the terminal where the operating system is located. Conversely, if it is determined that a parameter of a middleware does not need to be modified, the current middleware parameter remains unchanged.

[0083] To provide a more detailed explanation of the middleware update method for the program service, the following sections will use local cache pool, network connection pool, and thread pool as examples to illustrate the middleware update process.

[0084] When the middleware is a local cache pool, it is confirmed that the metric probe is running and the local cache pool is also running. The identifier of the local cache pool is obtained, and its corresponding metric data is retrieved based on this identifier. The metric data includes the cache pool type (e.g., ehcache, memcache, caffine) and its parameters (e.g., cache data storage size). The corresponding dynamic modification rule is then searched in the dynamic modification rule file based on the local cache pool identifier. The metric data and the corresponding dynamic modification rule are compared to determine if the local cache pool parameters need modification. If the cache data storage size in the metric data exceeds the threshold in the corresponding dynamic modification rule, it indicates that the local cache pool is currently oversupplied and its storage capacity needs to be increased. Finally, the parameters of the local cache pool are modified according to the corresponding dynamic modification rule to achieve local cache pool expansion. It should be noted that the parameters of the local cache pool include at least one of the following: maximum number of caches, memory clearing policy, cache validity period, and whether to persist to disk. The dynamic modification rules can be designed based on the actual situation to modify the local cache pool parameters.

[0085] When the middleware is a network connection pool, it is confirmed that the metric probe is running and the current network connection pool is also running. The network connection pool identifier is obtained, and its corresponding metric data is retrieved based on this identifier. The network connection pool metric data includes the network connection pool type and its parameter data. Then, based on the network connection pool identifier, the corresponding dynamic modification rule is searched in the dynamic modification rule file. The network connection pool metric data and the corresponding dynamic modification rule are compared to determine if the network connection pool parameters need modification. If so, the network connection pool parameters are modified according to the corresponding dynamic modification rule to update the network connection pool. It should be noted that the network connection pool parameters include at least one of the maximum number of POSTGRESQL database connections and the maximum number of HTTPCLIENT connections. The dynamic modification rules can be designed based on actual conditions to modify the network connection pool parameters.

[0086] Similarly, when the middleware is a thread pool, it is determined that the metric probe is running and the current thread pool is also running. The thread pool identifier is obtained, and its corresponding metric data is retrieved based on this identifier. The thread pool metric data includes the thread pool type and its parameter data. Then, based on the thread pool identifier, the corresponding dynamic modification rule is searched in the dynamic modification rule file. The thread pool metric data and the corresponding dynamic modification rule are compared to determine if the thread pool parameters need modification. If so, the thread pool parameters must be modified according to the corresponding dynamic modification rule to update the thread pool. It should be noted that the thread pool parameters include at least one of the following: the number of cores, maximum number of threads, queue type, queue capacity, and rejection policy. The dynamic modification rules can be designed based on the actual situation to modify the thread pool parameters.

[0087] The program service health determination method adopted in this invention improves the reliability of program service status monitoring and avoids the phenomenon of program service freezing, which affects the monitoring effect. The program service middleware determination method and program service middleware update method adopted in this invention have the function of dynamically adjusting various middleware, which not only enhances the stability of program service operation, but is also more economical than the existing method of expanding services through resource orchestration system.

[0088] The program service self-recovery method provided in this invention first determines the running status of the program service through a program service health assessment. If the program service is in an abnormal state, it can be directly restarted to achieve self-recovery. If the program service is in a normal running state, the middleware status within the program service needs to be further assessed to determine if any middleware parameters are currently insufficient to meet the operational needs of the program service and can only be restored to normal operation by restarting the program to relieve pressure. If so, the program service is directly restarted to achieve self-recovery, reducing losses in daily business operations. Furthermore, if the middleware parameters can be updated through modification, self-recovery is achieved by updating the middleware parameters. This invention enables automatic recovery of program services, preventing programs from being in an abnormal and unstable state for extended periods, thus avoiding significant losses to daily business operations.

[0089] Example 2

[0090] To address the technical problems existing in the prior art, embodiments of the present invention also provide a program service self-recovery device.

[0091] Figure 2 A schematic diagram of the self-recovery device for program services according to Embodiment 2 of the present invention is shown; see reference. Figure 2 As shown, the program service self-recovery device of this embodiment includes a program service health judgment module and a middleware update module.

[0092] The program service health assessment module is used to obtain the health status query request of the target program service, and based on the health status query request, to determine whether the target program service is in normal operation through the program service health assessment method. If it is, the next step of assessment is performed; otherwise, a restart command is sent to the target program service and an alarm signal is sent to the monitoring platform.

[0093] The middleware update module is used to determine whether the middleware in the target program service needs to be restarted based on the health status query request and the program service middleware judgment method. If so, it sends a restart command to the target program service and sends an alarm signal to the monitoring platform. Otherwise, it updates the middleware in the target program service through the program service middleware update method.

[0094] The program service health early warning device provided in this embodiment of the invention compares the currently connected TCP port of the program service with all application service protocols provided when the program service is running normally, using existing calling methods, to determine whether all application services of the program service are in a normal running state, and thus determine whether the program service is in a dead state; at the same time, before detecting the running status of each application of the program service, it first determines whether there is a program service process in the operating system to ensure that the program service is in a normal running state, improve the reliability of program service status monitoring, and avoid the phenomenon of program service deadness affecting the monitoring effect.

[0095] Example 3

[0096] To address the aforementioned technical problems in the prior art, this embodiment of the invention also provides a storage medium storing a computer program that, when executed by a processor, can implement all the steps in the program service self-recovery method of Embodiment 1.

[0097] The specific steps of the program service self-recovery method and the beneficial effects obtained by applying the readable storage medium provided in this embodiment of the invention are the same as in Embodiment 1, and will not be repeated here.

[0098] It should be noted that storage media include various media that can store program code, such as ROM, RAM, magnetic disks, or optical disks.

[0099] Example 4

[0100] To address the aforementioned technical problems in the prior art, embodiments of the present invention also provide a terminal.

[0101] Figure 3 A schematic diagram of the terminal structure of Embodiment 4 of the present invention is shown, with reference to... Figure 3 In this embodiment, the terminal includes a processor and a memory connected to each other; the memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory, so that the terminal can implement all the steps of the program service self-recovery method in Embodiment 1 when it is executed.

[0102] The specific steps of the program service self-recovery method and the beneficial effects obtained by the terminal provided by the application of the present invention are the same as those in Embodiment 1, and will not be repeated here.

[0103] It should be noted that the memory may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Similarly, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0104] While the embodiments disclosed in this invention are as described above, the content is merely for the purpose of facilitating understanding of the invention and is not intended to limit the invention. Any person skilled in the art to which this invention pertains may make any modifications and changes in form and detail of the implementation without departing from the spirit and scope disclosed herein; however, the scope of protection of this invention shall still be determined by the scope defined in the appended claims.

Claims

1. A method for self-recovery of a program service, comprising: Obtain a health status query request for the target program service, and based on the health status query request, determine whether the target program service is in normal operation through the program service health judgment method. If it is, proceed to the next step of judgment; otherwise, send a restart command to the target program service and send an alarm signal to the monitoring center. Based on the health status query request, the middleware in the target program service is determined by the program service middleware determination method. If it needs to be restarted, a restart command is sent to the target program service and an alarm signal is sent to the monitoring platform. Otherwise, the middleware in the target program service is updated by the program service middleware update method. Specifically, determining whether the target program service is in normal operating condition based on the health status query request and through a program service health assessment method includes: Based on the health status query request, determine whether the target program service process exists in the operating system. If it does, it means that the target program service is running. Otherwise, send an alarm message to the monitoring platform. Obtain all currently connected TCP ports of the target program service, and compile the obtained TCP port set into a target TCP port set; Obtain the application service protocols provided by the target program service under normal operating conditions, and combine all the obtained application service protocols into a target application service protocol set; Based on the preset invocation method, it is determined whether any application service protocol in the target application service protocol set has a TCP port in the target TCP port set that has made a request. If so, it indicates that the target program service is in normal operation. Otherwise, it indicates that the target program service is running abnormally, and an alarm message is sent to the monitoring platform.

2. The method according to claim 1, characterized in that, Obtaining the application service protocol provided by the target program service under normal operating conditions includes: Based on the program deployment path of the target program service, obtain the executable file and dependent libraries of the target program service; The executable files and dependent libraries of the target program service are analyzed to obtain the original language code corresponding to each executable file and the original language code corresponding to each dependent library. The original language code corresponding to all executable files and the original language code corresponding to all dependent libraries are compared with the application service protocol code in the application service protocol code library to obtain all application service protocols provided by the target program service. The application service protocol code library includes multiple application service protocol codes.

3. The method according to claim 1, characterized in that, Determining whether the middleware in the target program service needs to be restarted through a middleware-based approach includes: Obtain the middleware identifier of the middleware that has been started in the current target program service, and obtain the corresponding indicator data of the middleware based on the middleware identifier; The dynamic modification rule file of the target program service is obtained from the configuration center based on the configuration file address, and the dynamic modification rule of the corresponding middleware is obtained from the dynamic modification rule file based on each middleware identifier. Based on the metric data and dynamic modification rules of each middleware, it is determined whether the corresponding middleware needs to be restarted. If a middleware needs to be restarted, it is determined that the middleware in the target program service needs to be restarted; otherwise, it is determined that the middleware in the target program service does not need to be restarted.

4. The method according to claim 1, characterized in that, Updating the middleware in the target program service through the level service middleware update method includes: Obtain the middleware identifier of the middleware that has been started in the current target program service, and obtain the corresponding indicator data of the middleware based on the middleware identifier; The dynamic modification rule file of the target program service is obtained from the configuration center based on the configuration file address, and the dynamic modification rule of the corresponding middleware is obtained from the dynamic modification rule file based on each middleware identifier. Based on the index data and dynamic modification rules of each middleware, it is determined whether the parameters of the corresponding middleware need to be modified. If so, the parameters of the corresponding middleware are modified according to the corresponding dynamic modification rules; otherwise, the parameters of the corresponding middleware remain unchanged. The program service middleware update method is implemented based on middleware indicator probes.

5. The method according to claim 4, characterized in that, Before the steps of obtaining the middleware identifier of the middleware that has been started in the current target program service, and obtaining the corresponding indicator data of the middleware based on the middleware identifier, the method further includes: Obtain startup-related parameters, including status instructions and configuration file addresses; If the status instruction is to start the middleware indicator probe service, then determine whether the middleware indicator probe is started. If it is started, the middleware indicator probe maintains its current state; otherwise, the middleware indicator probe is started. If the status instruction is to stop the middleware indicator probe service, then release the middleware indicator probe resources and stop the middleware indicator probe service. If the status instruction is to upgrade the middleware indicator probe service, then release the middleware indicator probe resources, stop the middleware indicator probe service, and then restart the middleware indicator probe service.

6. The method according to claim 1, characterized in that, The middleware types in the target program service include network connection pools, thread pools, and local cache pools.

7. A program service self-recovery device, characterized in that, This includes a program service health assessment module and a middleware update module; The program service health assessment module is used to obtain the health status query request of the target program service, and based on the health status query request, determine whether the target program service is in normal operation through the program service health assessment method. If it is, proceed to the next step of the assessment; otherwise, send a restart command to the target program service and send an alarm signal to the monitoring platform. The middleware update module is used to determine whether the middleware in the target program service needs to be restarted based on the health status query request and through the program service middleware determination method. If so, a restart command is sent to the target program service and an alarm signal is sent to the monitoring platform. Otherwise, the middleware in the target program service is updated through the program service middleware update method. Specifically, determining whether the target program service is in normal operating condition based on the health status query request and through a program service health assessment method includes: Based on the health status query request, determine whether the target program service process exists in the operating system. If it does, it means that the target program service is running. Otherwise, send an alarm message to the monitoring platform. Obtain all currently connected TCP ports of the target program service, and compile the obtained TCP port set into a target TCP port set; Obtain the application service protocols provided by the target program service under normal operating conditions, and combine all the obtained application service protocols into a target application service protocol set; Based on the preset invocation method, it is determined whether any application service protocol in the target application service protocol set has a TCP port in the target TCP port set that has made a request. If so, it indicates that the target program service is in normal operation. Otherwise, it indicates that the target program service is running abnormally, and an alarm message is sent to the monitoring platform.

8. A storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the program service self-recovery method of any one of claims 1 to 6.

9. A terminal, characterized in that, include: A processor and a memory, wherein the memory and the processor are communicatively connected; The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to cause the terminal to perform the program service self-recovery method as claimed in any one of claims 1 to 6.

Images