Service stability guarantee method and device, and electronic equipment

Abstract

The application provides a service stability guarantee method and device and electronic equipment, wherein the method mainly adopts a system-level daemon mechanism or an application-level daemon mechanism according to service types (middleware service / business application service) and performs multiple health checks on business application services, including processes, health interfaces and business logic states, so that the "dead" state of the business application service can be effectively found and recovered, and the availability and stability of the business service are significantly improved.

Description

Technical Field

[0001] This application belongs to the field of server technology, and in particular relates to a method, apparatus and electronic device for ensuring service stability. Background Technology

[0002] Server systems typically deploy and run various types of services, which need to operate continuously and stably to ensure business continuity. When services experience anomalies for various reasons, they need to be detected promptly and automatically recovered.

[0003] In related technologies, a unified service detection and recovery mechanism is typically used to maintain service availability. These solutions generally determine service liveness by periodically checking the service's process status or network port status, and perform a restart operation when a service is deemed abnormal.

[0004] However, the above solution has a major drawback: its unified detection strategy is ineffective in detecting the "dead" state of business application services. Due to the lack of ability to check the internal health status and critical business logic status of the service, the existing detection mechanism cannot detect when the business application service process exists but is unable to process business requests normally (e.g., unable to respond to health check interfaces or has been disconnected from critical dependent components), thus making the service practically unavailable and failing to meet the requirements of high availability. Summary of the Invention

[0005] This application provides a service stability assurance method, apparatus, and electronic device that can effectively detect and restore the "frozen" state of business application services, significantly improving the availability and stability of business services.

[0006] The first aspect of this application provides a service stability assurance method, comprising: identifying the service type of a target service running on a server, wherein the service type includes middleware services and business application services; when the target service is identified as a middleware service, employing a system-level guardian mechanism to detect and restore the target service, wherein the system-level guardian mechanism includes: checking whether the process of the target service exists through a system service manager, and triggering a restart of the target service if the process does not exist; when the target service is identified as a business application service, employing an application-level guardian mechanism to detect and restore the target service, wherein the application-level guardian mechanism includes: performing multiple health checks on the target service by executing a custom guardian script, and triggering a restart of the target service if the checks fail, wherein the multiple health checks include at least checking whether the process exists, checking whether a preset health interface returns to a normal state, and checking whether a preset business logic state is normal.

[0007] In the technical solution of this application, the system-level protection mechanism or the application-level protection mechanism is adopted differently according to the service type (middleware service / business application service), and multiple health checks including process, health interface and business logic status are performed on the business application service. In this way, the "frozen" state of the business application service can be effectively detected and restored, which significantly improves the availability and stability of the business service.

[0008] Optionally, in one possible implementation of the first aspect, identifying the service type of the target service running on the server includes: determining whether the target service is a middleware service based on the matching relationship between the target service's installation directory and a preset system standard directory, and based on whether the target service is configured with a system service manager unit file; determining whether the target service is a business application service based on the matching relationship between the target service's installation directory and at least one preset application deployment directory, and based on whether a custom daemon script with a preset name exists in the target service's directory. Thus, by identifying the service type based on the service's installation directory (system standard directory / application deployment directory) and the existence of a specific configuration file (system unit file / custom daemon script), the automatic and accurate differentiation between middleware services and business application services is achieved, providing a reliable basis for implementing differentiated daemonization and reducing manual configuration.

[0009] Optionally, in another possible implementation of the first aspect, the above-mentioned method performs multiple health checks on the target service by executing a custom daemon script. These checks include: checking if the target service process exists; if the target service process exists, accessing a preset health interface to obtain health status data; if the health interface returns a Hypertext Transfer Protocol (HTTP) status code indicating normal operation, extracting at least one business logic status field from the health status data; and determining whether the business logic status of the target service is normal based on the value of the business logic status field. Thus, by specifying a progressively advancing multi-step health check process for the business application service (checking the process → accessing the health interface → resolving the business status), a logically rigorous and progressively in-depth check process is constructed, ensuring accurate identification of the specific aspect of service anomalies (whether it is a process crash, an interface anomaly, or a business logic failure), improving the timeliness and accuracy of problem detection.

[0010] Optionally, in another possible implementation of the first aspect, the aforementioned preset business logic state includes at least one of the following: the registration status of the target service in the service registry, and the connection status of the target service with the message middleware. Thus, by specifying the business logic state as the service registration status and the message middleware connection status, health checks can directly verify the collaboration capabilities between the business application service and key distributed components, ensuring the true availability of the service at the business level and avoiding service function paralysis due to registration or connection failures.

[0011] Optionally, in another possible implementation of the first aspect, the aforementioned application-level daemon mechanism further includes: before triggering the restart of the target service, checking whether a pre-set lock file for the target service exists; if the lock file exists, reading the timestamp recorded in the lock file and calculating the difference between the timestamp and the current time; if the difference between the timestamp and the current time is less than a pre-set timeout threshold, determining that the target service is in the startup process and aborting the current restart operation. Thus, by checking the timestamp-based lock file and determining whether the startup has timed out before triggering the restart, the problem of repeated startups caused by the detection period being shorter than the startup duration can be effectively prevented during service startup, avoiding port conflicts and resource contention, and ensuring the orderly nature of the service restart process.

[0012] Optionally, in another possible implementation of the first aspect, the method further includes: if the difference between the timestamp and the current time is greater than or equal to a timeout threshold, checking if the process of the target service exists; if the process of the target service exists, stopping the process of the target service; after confirming that the process of the target service has stopped, deleting the lock file; and after deleting the lock file, executing the restart process of the target service in the application-level daemon mechanism. Thus, by executing the process of stopping the existing process, cleaning up the lock file, and restarting after the lock file times out, it is possible to automatically perform on-site cleanup and attempt recovery when the service startup is stuck or abnormal, thereby enhancing the self-recovery capability and robustness of the application-level daemon mechanism in abnormal scenarios.

[0013] Optionally, in another possible implementation of the first aspect, before identifying the service type of the target service running on the server, the method further includes: periodically scanning at least one preset application deployment directory, and during the scanning process, obtaining the first-level directory under each application deployment directory as a service unit directory; for each service unit directory, checking whether a custom daemon script with a preset name exists in the service unit directory; if a custom daemon script exists in the service unit directory, determining the service corresponding to the service unit directory as the target service with a service type of business application service. Thus, by periodically scanning the application deployment directory and automatically discovering business application services based on custom daemon scripts, automatic management of newly added or deployed business services is achieved without manually updating the service list, greatly improving the management efficiency and automation level of the daemon system.

[0014] Optionally, in another possible implementation of the first aspect, the method further includes: detecting the mount status of external network storage resources through the system service manager, wherein the external network storage resources are used to provide storage space for the server, and the normal operation of middleware services or business application services depends on access to the external network storage resources; if the mount status of the external network storage resources is detected to be invalid, the re-mounting operation is automatically executed to restore resource availability. Thus, by utilizing the system service manager to detect the mount status of external storage resources and automatically re-attaching when invalid, the availability of the basic storage resources on which the server depends is ensured, providing reliable resource support for the stable operation of various upper-layer services, and demonstrating the completeness of the protection mechanism.

[0015] A second aspect of this application provides a service stability assurance device, including:

[0016] The type identification module is used to identify the service type of the target service running on the server. The service type includes middleware services and business application services.

[0017] The system-level guardian module is used to detect and restore the target service when the target service is identified as a middleware service. The system-level guardian mechanism includes: checking whether the process of the target service exists through the system service manager, and triggering the restart of the target service if the process does not exist.

[0018] The application-level guardian module is used to detect and restore the target service when the target service is identified as a business application service. The application-level guardian mechanism includes: performing multiple health checks on the target service by executing a custom guardian script, and triggering the restart of the target service if the check fails. The multiple health checks include at least checking whether the process exists, whether the preset health interface returns a normal status, and whether the preset business logic status is normal.

[0019] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the service stability assurance method of the first aspect described above.

[0020] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the service stability assurance method of the first aspect described above.

[0021] The fifth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the service stability guarantee method described in the first aspect.

[0022] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a service stability assurance method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a service stability assurance device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0026] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0027] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0029] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0031] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0032] In related technologies, a unified service detection and recovery mechanism is typically used to maintain service availability. These solutions generally determine service liveness by periodically checking the service's process status or network port status, and perform a restart operation when the service is deemed abnormal. However, the above solutions have a major drawback: their unified detection strategy is ineffective at detecting the "dead" state of business application services. Due to the lack of ability to check the internal health status and critical business logic status of the service, when the business application service process exists but is unable to process business requests normally (e.g., unable to respond to health check interfaces or disconnected from critical dependent components), the existing detection mechanism cannot detect it, resulting in the service being practically unavailable and failing to meet high availability requirements.

[0033] In view of this, embodiments of this application provide a service stability assurance method, apparatus, and electronic device. The method mainly adopts a system-level protection mechanism or an application-level protection mechanism differently according to the service type (middleware service / business application service), and performs multiple health checks on the business application service, including process, health interface, and business logic status. This effectively detects and restores the "frozen" state of the business application service, significantly improving the availability and stability of the business service.

[0034] The following example illustrates the application scenario of the service stability assurance method provided in this application. In an enterprise server system that deploys databases, message queues, and multiple web application services, traditional service detection schemes can only detect the existence of processes. When a web application service "freezes" due to an internal error (the process is still running but unable to process requests), traditional schemes cannot detect it, leading to continuous user access failures. Using this application, the system identifies the web application as a "business application service" and initiates an application-level daemon mechanism, performing multiple health checks, including process checks, invoking its health management interface, and verifying its registry status. This mechanism can quickly detect the service's freeze anomaly and automatically trigger a restart, thereby restoring the service without manual intervention and significantly reducing the business interruption time and impact caused by service freezes.

[0035] To illustrate the technical solution of this application, specific embodiments are described below.

[0036] Reference Figure 1The diagram illustrates a flowchart of a service stability assurance method provided in an embodiment of this application. This method can be executed by a server system, or by a service stability assurance device or electronic device as described in the following embodiments.

[0037] like Figure 1 As shown, the method for ensuring service stability may include the following steps: Step 101: Identify the service type of the target service running on the server.

[0038] The service types include middleware services and business application services.

[0039] In the embodiments of this application, the server system typically runs multiple types of services simultaneously, such as middleware services that provide basic functions for business (e.g., databases, message queues, configuration centers, etc.) and application services that directly provide business functions to users (e.g., web services, application programming interface (API) services, etc.). These two types of services have fundamental differences in their protection requirements.

[0040] Middleware services, as system infrastructure, primarily require absolute process stability and standardized lifecycle management, typically only needing to ensure process existence. Business application services, however, directly carry business logic, and their protection needs are more complex, requiring the ability to detect whether a service is in a "dead" state (i.e., the process exists but the service is unresponsive) and whether the business logic is functioning correctly (e.g., whether it has successfully registered with the service registry). Using a single, uniform protection mechanism (e.g., using systemd or simple custom scripts) to manage all services will fail to simultaneously meet the differentiated needs of these two types of services. This one-size-fits-all approach leads to two fundamental problems: for middleware services, the standardized, highly reliable system-level service management capabilities provided by the operating system cannot be fully utilized; for business application services, necessary deep health checks cannot be implemented, resulting in critical issues such as "service dead" not being detected and resolved in a timely manner.

[0041] Therefore, this application proposes a preliminary, intelligent service type identification step as a prerequisite for implementing layered protection. This step can automatically scan the service deployment environment on the server through a dynamic service discovery and classification module. Based on preset dual judgment rules based on service deployment characteristics and protection configuration, it intelligently classifies all target services running on the server into two types: middleware services and business application services, thereby providing accurate input for the subsequent implementation of precise differentiated protection strategies.

[0042] It should be noted that the aforementioned service type identification mechanism is the logical foundation and innovative starting point of the layered guardian architecture in this application. It does not simply use two existing guardian tools side-by-side, but rather introduces an automated classification decision layer. The core value of this layer lies in its ability to automatically discover and utilize the objective differences between the two types of services in deployment specifications (whether they follow operating system standards or application project specifications) and guardian configurations (whether they use standard system configurations or custom scripts) as classification criteria, thereby achieving intelligent routing of guardian policies. This design breaks through the traditional mindset of manually specifying or uniformly processing service management, laying a solid foundation for achieving automated and refined service stability assurance.

[0043] In one embodiment, the service type of a target service running on the server can be identified as follows: Based on the matching relationship between the target service's installation directory and a preset system standard directory, and based on whether the target service has a system service manager unit file configured, it can be determined whether the target service is a middleware service; based on the matching relationship between the target service's installation directory and at least one preset application deployment directory, and based on whether a custom daemon script with a preset name exists in the target service's directory, it can be determined whether the target service is a business application service. Therefore, by identifying the service type based on the service's installation directory (system standard directory / application deployment directory) and the existence of a specific configuration file (system unit file / custom daemon script), the automatic and accurate differentiation between middleware services and business application services is achieved, providing a reliable basis for implementing differentiated daemonization and reducing manual configuration.

[0044] It's important to note that because middleware services and business application services have different roles in the operations and maintenance system, their installation and deployment specifications also differ significantly. Middleware services (such as MySQL databases, Kafka message queues, and Nacos configuration centers) are typically considered infrastructure components of the server. Their installation, configuration, and management must strictly adhere to the operating system's standard specifications to achieve optimal compatibility, security, and maintainability. Therefore, they are usually deployed in the operating system's default system standard directories, such as / usr / local / and / opt / . Furthermore, to integrate with the operating system's service management system, they are configured with unit files (e.g., nacos.service, mysql.service) from the system service manager (such as systemd, widely used in Linux systems). These files are standard configuration files used by the system service manager to define and manage service lifecycles, dependencies, resource limits, and restart policies. Conversely, business application services (such as police-server and police-evidence) are the carriers of specific business functions. Their deployment is usually closely related to the project structure and environment configuration, offering greater flexibility and customizability. Therefore, they are often deployed in agreed-upon application deployment directories, such as the environment service directory / iotp / env, the basic service directory / iotp / base, the standard service directory / iotp / standard, and the custom service directory / iotp / custom. Furthermore, to meet their complex health check requirements (checking the health of interfaces and the status of business logic), each business application service is equipped with a dedicated custom daemon script (such as guard.sh). This script encapsulates the specific check logic and start / stop procedures for that service.

[0045] In one possible implementation, the service type automatic identification mechanism of this application employs a dual-judgment rule based on the aforementioned differences. For any target service that needs to be identified, the system executes two sets of judgment logic in parallel: The first set of logic is used to identify middleware services. The judgment is based on the simultaneous fulfillment of two conditions: 1) Deployment location verification: Whether the service's executable file or main working directory is located under a preset system standard directory (such as / usr / local / or / opt / ). 2) System management configuration verification: Whether the service has a corresponding unit configuration file in the system service manager (such as systemd) (i.e., whether a file such as / etc / systemd / system / nacos.service exists). If a service simultaneously meets both conditions of "deployed in a system standard directory" and "exists a systemd unit file," the system identifies it as a "middleware service" and automatically plans to have it taken over by a system-level daemon mechanism. For example, the Nacos service is usually installed at / usr / local / nacos and has a configuration file at / etc / systemd / system / nacos.service, therefore it will be correctly identified as a middleware service.

[0046] It's important to note that using systemd unit files as the core criterion for judgment has profound technical rationale. As the standard service management tool for Linux systems, the existence of a unit file for a service signifies that the service has been integrated according to best practices for system-level services. Its protection requirements (typically process keep-alive and dependency management) can be fully met by systemd's built-in, highly reliable mechanisms, extensively validated in production environments. By checking the existence of unit files, this mechanism can accurately filter out services that have been standardized and systematically managed, avoiding unnecessary and complex application-level health check logic, thereby optimizing system resource utilization while ensuring effective protection.

[0047] The second set of logic is used to identify business application services. The judgment is also based on the simultaneous fulfillment of two conditions: 1) Deployment location verification: Whether the service's installation directory is located under one or more preset application deployment root directories (such as / iotp / standard). 2) Custom daemon configuration verification: Whether a custom daemon script file with a preset name (e.g., guard.sh) exists in the service's corresponding installation subdirectory, and this script is usually located in a fixed subpath (such as the script / directory). Specifically, the system can check if the path / iotp / standard / {service name} / script / guard.sh exists. If the target service meets both conditions—"deployed in a preset application deployment directory" and "the script / guard.sh script exists in a pre-defined location within its directory structure"—the system identifies it as a "business application service" and plans to manage it using an application-level daemon mechanism. For example, the police-server service is deployed in the / iotp / standard / police-server directory, and the script / guard.sh file exists in this directory; therefore, it will be identified as a business application service.

[0048] It should be noted that the aforementioned identification mechanism based on the agreed directory structure and script naming provides great flexibility and standardization for the deployment and maintenance of business services. It allows operations and maintenance personnel to package and deploy business services in a standardized "folder + script" format, and the maintenance system can automatically understand and accept these new services, thus decoupling service deployment from maintenance access.

[0049] In one embodiment, before identifying the service type of the target service running on the server, at least one preset application deployment directory can be scanned periodically. During the scan, the top-level directories under each application deployment directory are obtained as service unit directories. Then, for each service unit directory, it is checked whether a custom daemon script with a preset name exists. Finally, if a custom daemon script exists in the service unit directory, the service corresponding to the service unit directory is identified as the target service with the service type of business application service. Thus, by periodically scanning the application deployment directory and automatically discovering business application services based on custom daemon scripts, automatic management of newly added or deployed business services is achieved without the need for manual updates to the service list, greatly improving the management efficiency and automation level of the daemon system.

[0050] It should be noted that the number, names, and versions of business application services may dynamically change with software iterations, requirement changes, or horizontal scaling. If a static configuration file is used to list all business services that need to be protected, the administrator must manually update the configuration list of the protection system every time a service is added, removed, or renamed. This process is cumbersome, error-prone, and cannot take effect in real time, making it difficult to meet the needs of modern agile operations and maintenance. Therefore, this application designs a dynamic service discovery mechanism. The core of this mechanism is a main daemon process, which actively performs a panoramic scan of all preset application deployment directories at fixed time intervals (e.g., every 15 seconds). The scanning process follows a precise algorithm: First, the main daemon process sequentially traverses each preset application deployment directory (e.g., / iotp / env, / iotp / base, / iotp / standard, / iotp / custom). For each such root directory, it obtains the names of all direct first-level subdirectories under that directory, and each such subdirectory is considered a potential business service unit directory. For example, scanning the / iotp / standard directory may yield subdirectory names such as police-server, police-evidence, and police-web.

[0051] Furthermore, after obtaining the list of service unit directories, the dynamic service discovery mechanism enters the crucial verification phase. For each directory name in the list, the main daemon process can construct a specific file path, that is, check whether a custom daemon script file conforming to a strict convention exists in that directory. The typical path pattern is {application deployment directory} / {service unit directory name} / script / guard.sh. For example, for the service unit directory police-server, the system will check whether the file / iotp / standard / police-server / script / guard.sh exists. The file system's "existence check" is the decisive step in determining whether the directory represents a valid business application service that needs to be protected. If the check passes, the main daemon process officially registers the service corresponding to the service unit directory name (such as police-server) as the currently protected business application service target and includes it in the subsequent application-level daemon cycle task list. The entire discovery, verification, and registration process is fully automated, requiring no manual intervention or modification of configuration files.

[0052] It's important to note that the dynamic service discovery mechanism described above is designed with the complexity of real-world operational scenarios in mind, and incorporates intelligent filtering strategies to improve accuracy. A typical filtering strategy is to ignore backup directories. During the scan, the system automatically filters out subdirectories whose names contain specific identifiers (such as "bak," case-insensitive). For example, directories like / iotp / standard / police-server-bak or / iotp / standard / backup_police will be automatically excluded from service discovery. This strategy effectively prevents misjudgments by the daemon system due to the presence of temporary backups, old version remnants, etc., ensuring that only currently active service instances are included in the daemon system. Furthermore, the periodic scanning feature of this mechanism ensures that service changes are detected promptly. For instance, when an operations engineer deploys a new business service, `police-gateway`, to the ` / iotp / standard / ` directory and creates the `script / guard.sh` script, the service will be automatically discovered, identified, and immediately begin receiving application-level daemon protection in the next scan cycle (maximum 15 seconds later), truly achieving "deployment equals protection," greatly improving operational efficiency and the system's self-management capabilities.

[0053] In this embodiment, the effective operation of the dynamic service discovery mechanism relies on a pre-defined service deployment directory structure. A standard business application service needs to be deployed under a preset root directory (e.g., / iotp / standard) and use an independent folder as a service unit (e.g., police-server). Within this service unit folder, there must be agreed-upon subdirectories and scripts: the script / directory must contain the main guardian script guard.sh, and start.sh and health.sh responsible for specific health checks and startup lock logic; the bin / directory contains the actual service startup script; and the dist_lib / directory contains the service's application package (e.g., JAR files). The main guardian process discovers all potential service units conforming to this directory structure by executing specific file system scanning commands (e.g., using the find command to traverse multiple preset application deployment root directories, setting a maximum depth of 1 to only obtain first-level subdirectories). During the scanning process, the system automatically ignores backup directories through filtering rules (e.g., excluding folders whose directory names contain "bak"), ensuring that only active service instances are protected. This "convention over configuration" directory structure combined with automatic scanning is key to achieving "deployment as protection" for services.

[0054] Step 102: If the target service is identified as a middleware service, a system-level protection mechanism is used to detect and restore the target service.

[0055] In this embodiment of the application, the system-level protection mechanism includes: checking whether the process of the target service exists through the system service manager, and triggering the restart of the target service if the process does not exist.

[0056] It's important to note that the target services identified as middleware services (such as MySQL, Kafka, Nacos, Redis, and Nginx) form the cornerstone and common capability platform of the entire server software stack. Their core characteristics are standardized functionality, mature architecture, and provision of basic, non-business-related support capabilities. The stability of these services directly determines the availability boundary of all upper-layer business applications. Their protection requirements have distinct features: First, their objectives are clear and singular, with the core requirement being to ensure the continuous operation of service processes and prevent process exits for any reason; second, their dependencies are clear, with explicit startup order dependencies between services (e.g., the Nacos configuration center depends on the MySQL database); third, they need to be integrated into the operating system management system, requiring standard start, stop, and status query interfaces, as well as system-level features such as automatic startup, resource quotas, and log integration.

[0057] Traditional solutions that attempt to cover such daemonization requirements using generic custom scripts inevitably face a series of fundamental drawbacks: they require re-implementing the process detection, dependency ordering, and crash recovery logic already natively provided and thoroughly validated by the operating system. This not only incurs high development and maintenance costs but also fails to achieve the industry-standard robustness and integration with other system components (such as logging and resource control systems) that are native to the operating system's service management components. Therefore, this application designs and adopts a system-level daemonization mechanism for middleware services. Essentially, this mechanism completely delegates the lifecycle management of middleware services to the standardized service management framework of the operating system kernel, namely the system service manager (using the current de facto standard systemd in Linux as an example). This mechanism carefully defines and configures a system service manager unit file (usually a file with the .service extension) for each middleware service, declaratively configuring the service's start and stop commands, running user, environment variables, dependencies, resource limits, and crucial restart strategies for the system service manager to understand and execute.

[0058] In this embodiment, the core of the system-level daemon mechanism is the parsing and execution of the `Restart=` configuration item in the unit file by the system service manager. When this configuration item is set to `always`, a clear instruction is given to the system service manager: regardless of the reason for the exit of the protected service process (normal exit, abnormal crash, being killed by a signal, etc.), the service must be automatically restarted. Combined with the `RestartSec=` configuration item, the waiting interval before the restart action is triggered can be precisely controlled to avoid excessively frequent restart attempts when the process crashes instantly. The system service manager has a built-in efficient process status tracker that continuously monitors the lifecycle of the main process (specified by `ExecStart=`) associated with the managed service. Once the process identifier (PID) of the process disappears (i.e., the process exits), the system service manager immediately enters the restart decision logic according to the `Restart=` policy. If the policy is `always`, it will automatically and unconditionally re-execute the `ExecStart=` startup command defined in the unit file after waiting for `RestartSec=` seconds, thereby restarting the service process into a running state. The entire "detection-decision-restart" cycle is completed at the operating system kernel level, without relying on any upper-level polling scripts in user space. Its response speed, reliability, and resource consumption efficiency are all at a high level.

[0059] For example, for the Nacos configuration center service, `Restart=always` and `RestartSec=5` are configured in its unit file ` / etc / systemd / system / nacos.service`. When the Nacos process is terminated by the system due to out-of-memory (OOM) or crashes due to an unhandled internal exception, systemd will immediately detect the process termination event and, after a 5-second delay, automatically execute the ` / usr / local / nacos / bin / start.sh` script to resume the Nacos service, without requiring any intervention from the system administrator.

[0060] Specifically, system-level daemons are implemented by configuring a systemd unit file for each middleware service. Taking the Nacos Configuration Center service as an example, its complete unit file ` / etc / systemd / system / nacos.service` embodies various aspects of standardized daemons. In this file, the `[Unit]` section defines the service description, startup order dependencies (e.g., `After=network-online.target mysql.service` ensures startup after network readiness and MySQL startup), weak dependencies (`Wants`), and file system dependencies (`RequiresMountsFor`). The `[Service]` section configures in detail the process type (`Type=forking`), start and stop commands (`ExecStart`, `ExecStop`), core restart policies (`Restart=always`, `RestartSec=5`), the service's running identity and group (`User`, `Group`), working directory, and necessary environment variables (such as `JAVA_HOME`). The `[Install]` section ensures the service starts automatically when the system enters multi-user mode via `WantedBy=multi-user.target`. This configuration file comprehensively demonstrates systemd's capabilities in service lifecycle management, dependency control, resource isolation, and integrated auto-start, serving as the technological cornerstone for achieving standardized and highly reliable protection of middleware services.

[0061] It should be further explained that using systemd as the unified daemon platform for middleware services does not merely provide the "automatic restart" function, but rather brings a complete set of standardized operation and maintenance capabilities that conform to "infrastructure as code" and "production environment best practices." This is precisely the advantage of this application over traditional solutions. These advantages are specifically reflected in the following seven key aspects: First, it achieves deep system integration and unparalleled operational stability. As the initialization system and service manager for Linux systems, systemd's code works closely with the operating system kernel, running at a privileged level. Its stability has been rigorously tested in massive global production environments. Having it manage middleware services means that the daemon logic itself is almost never affected by application-layer issues in user space (such as script errors or resource contention), providing the highest level of reliability.

[0062] Secondly, it provides a standardized and unified service lifecycle management interface. All managed middleware services, whether they are Java applications, Go applications, or native binary programs, are controlled through a unified set of commands: `systemctl start / stop / restart / status [service name]`. This greatly simplifies the operational and cognitive burden on operations and maintenance personnel, reduces the learning cost, and makes the writing of automated operations and maintenance scripts simple and consistent.

[0063] Third, it possesses robust dependency and startup order management capabilities. This is a core function that is difficult to implement correctly and concisely using custom scripts. In the [Unit] section of the unit file, dependencies between services can be precisely declared using directives such as After=, Requires=, and Wants=. For example, if the Nacos service depends on MySQL and network readiness, then After=network-online.target mysql.service would be configured. When starting the Nacos unit, the system service manager will first ensure that the network-online.target and mysql.service units are in an "active" state. If a dependency fails to start, systemd will make the correct decision based on the configuration (Requires indicates a strong dependency, which will abort upon failure; Wants indicates a weak dependency, which can continue upon failure), thereby preventing a chain reaction of startup failures caused by unready dependent services.

[0064] Fourth, the configuration for services to start automatically at boot has been simplified and standardized. The `WantedBy=multi-user.target` directive in the `[Install]` section of the unit file allows services to be set to start automatically when the system enters multi-user mode (normal runlevel). System administrators no longer need to manually edit `rc.local` or other initialization scripts, reducing the risk of configuration errors and ensuring seamless integration of service startup behavior with the system startup process.

[0065] Fifth, it supports fine-grained system resource management. In the [Service] section of the unit file, directives such as MemoryLimit=, CPUQuota=, and LimitNOFILE= can be used to easily set resource limits for services, including memory usage limits, CPU time quotas, and the maximum number of open files. This effectively achieves resource isolation between middleware services, preventing abnormal behavior of a single service (such as memory leaks) from exhausting the resources of the entire server, thereby ensuring the normal operation of other co-habiting services.

[0066] Sixth, it achieves seamless integration with the system logging infrastructure. systemd has a built-in journald logging service. All standard output (stdout) and standard error output (stderr) of managed services are automatically captured, indexed, and persisted by journald. Operations personnel can use the unified command journalctl -u [service name] to view the complete logs of a specific service, supporting filtering by time and priority, which greatly facilitates troubleshooting and log auditing.

[0067] Seventh, it perfectly aligns with the "simple safeguarding requirements" of middleware services. In most production scenarios, the health status of a middleware service is equivalent to the liveness of its main process. Its internal state complexity is far lower than that of business applications, typically requiring no additional HTTP health checks or business logic interfaces for liveness detection. Therefore, systemd's process-state-based "existence checks" and "exit and restart" strategies precisely meet the core availability assurance requirements of middleware services in the simplest and most efficient way. Introducing more complex health checks would not only be redundant for middleware services but could also introduce new instabilities.

[0068] In summary, delegating the protection responsibilities of middleware services to the system service manager is a rational choice and a technical necessity in the system-level protection layer of the layered protection architecture of this application embodiment. It fully utilizes the production-grade service management capabilities natively provided by the operating system, and in a standardized, highly reliable, and low-overhead manner, it achieves a solid guarantee for the fundamental goal of "continuous process operation" of middleware services, and lays a solid foundation for the stable operation of upper-layer business application services.

[0069] In one embodiment, the system service manager can also detect the mount status of external network storage resources. These external network storage resources provide storage space for the server, and the normal operation of middleware services or business application services depends on access to them. If the mount status of an external network storage resource is detected to be invalid, a retry mount operation is automatically performed to restore resource availability. Therefore, by utilizing the system service manager to detect the mount status of external storage resources and automatically retry mounts when invalid, the availability of the basic storage resources upon which the server depends is ensured, providing reliable resource support for the stable operation of various upper-layer services and demonstrating the completeness of the protection mechanism.

[0070] It should be noted that in current server architectures, the functionality of many middleware services (such as database data directories and message queue log storage) and business application services (such as file upload storage, shared configuration files, and centralized storage of business logs) heavily relies on external network storage resources, such as Network Attached Storage (NAS) or Network File System (NFS). These resources provide scalability, sharing, and persistence guarantees. However, the introduction of network storage also brings new vulnerabilities: network link interruptions, restarts or maintenance of peer storage servers, can all cause mounted storage directories to become unavailable while the server is running. Traditional methods, such as configuring static mounting in the ` / etc / fstab` file, can achieve automatic mounting at boot, but often lack an automatic reconnection mechanism after a connection is lost during runtime, requiring manual intervention to remount, leading to prolonged malfunctions of services dependent on this path. Therefore, this application's system-level protection mechanism extends its protection scope from "service processes" to "critical system resources on which services depend," particularly the availability of external network storage resources. This extended protection capability is also implemented through the system service manager (systemd), demonstrating the completeness of system-level protection.

[0071] Specifically, for each critical external network storage resource, a dedicated mount unit file (.mount file) or automount unit file (.automount file) for the System Service Manager is created and configured. These unit files describe the resource's mount point, source address, file system type, mount options, and crucial dependencies and recovery strategies using a declarative syntax. For example, a unit file named iotp-data.mount can be created for a NAS share on a server used to store business data. In this file, the After=network-online.target configuration explicitly indicates that the mount operation must be performed only after the network service is ready. This resolves the "boot order" problem that can occur due to differences in boot speed between the server and the NAS device—that is, when the server starts, the network is not yet ready or the NAS device is not yet online, leading to mount failure.

[0072] Furthermore, automated fault recovery can be achieved by configuring the built-in retry parameters of the network file system client in the mount options (Options=). For example, configuring retry=10, timeo=60. retry=10 indicates that the system will automatically attempt up to 10 retries after a mount failure; timeo=60 sets the timeout for each network request to 60 seconds. The System Service Manager is not only responsible for performing mounts based on the unit file at startup, but also continuously monitors the activity status of the mount points it manages. When a temporary network interruption occurs between the running server and the NAS (such as a brief switch port failure), the mount point becomes inactive. After detecting this status change, the System Service Manager will continuously and automatically attempt to re-establish the connection and restore the mount in the background according to the retry policy preset in the unit file. Once the network is restored, the mount operation can automatically succeed without administrator intervention, making the / iotp / data directory available again.

[0073] It's important to note that the aforementioned resource availability protection mechanism seamlessly integrates with upper-layer service protection through the dependency chain feature of the system service manager, forming a comprehensive, bottom-up recovery system. For example, the business application service `police-server` needs to write files to the ` / iotp / data / evidence / ` directory. This dependency on `iotp-data.mount` can be established in the `police-server`'s systemd unit file (if it's also managed by systemd) or within the logic of its application-level daemon scripts. In the systemd architecture, this can be achieved by adding `After=iotp-data.mount` and `Requires=iotp-data.mount` to `police-server.service`. In other words, the `police-server` service will only start after the `iotp-data.mount` unit is successfully activated (i.e., the NAS is successfully mounted). If the NAS mounting fails, the `police-server` service will not start, thus avoiding an immediate "directory not found" error after service startup. During runtime, if the NAS connection is lost and `iotp-data.mount` enters a failed state, the dependent `police-server` service may be marked as failed by systemd or automatically stopped. Once systemd successfully restores the mount according to the retry policy, it can be further configured to automatically restart the policy-server service that depends on it, thus achieving full automation from resource failure to service recovery. This mechanism effectively shields the unreliability of external resources and provides automatic fault tolerance, greatly enhancing the resilience and self-healing ability of the entire server system in the face of infrastructure layer fluctuations.

[0074] Therefore, the aforementioned system-level resource protection method is an important supplement and improvement to the system-level protection mechanism. It demonstrates that the layered protection architecture of this application not only focuses on the lifecycle of the service process itself, but also proactively covers the key external environmental factors upon which the service operation depends. Through the native capabilities of the operating system, it achieves resource layer detection and automatic recovery, thereby ensuring the overall stability of the server at a more fundamental level.

[0075] Step 103: If the target service is identified as a business application service, an application-level protection mechanism is used to detect and restore the target service.

[0076] In this embodiment of the application, the application-level guardian mechanism includes: performing multiple health checks on the target service by executing a custom guardian script, and triggering the restart of the target service if the check fails. The multiple health checks include at least checking whether the process exists, checking whether the preset health interface returns to a normal state, and checking whether the preset business logic state is normal.

[0077] It's important to note that because business application services (such as police-server, police-evidence, and police-web) directly carry and execute core business logic, their internal states are complex and tightly coupled with external dependencies (such as databases, message queues, and configuration centers). The potential failure modes they can experience extend far beyond process crashes. A more common and damaging scenario is the "service deadlock" state, where the service process still exists in the operating system's process table, but has completely lost its ability to handle business requests due to internal thread pool exhaustion, memory leaks, deadlocks, lost connections to dependent services, or internal state machine errors.

[0078] Traditional solutions, whether using systemd process monitoring or simple scripts that only check port listening, are unable to detect such deep-seated faults. This results in the system monitoring layer displaying services as "normal," while actual business operations are unavailable, creating a significant blind spot in operations and maintenance. Therefore, this application designs an application-level monitoring mechanism for business application services. The core of this mechanism is a customizable and scalable automated monitoring framework, executed by a custom monitoring script (which can be named guard.sh) specific to each business application service. This mechanism does not rely on the operating system's service manager. Instead, a main daemon process periodically (e.g., every 15 seconds) calls the guard.sh script for each business service. This script is responsible for executing a deeply customized health diagnostic process, namely, multiple health checks. This check system includes three progressively more stringent check dimensions, aiming to penetrate the process appearance and reach the service's internal working state. Only when a service passes all dimensions of the check is it considered truly healthy; if any dimension fails, a smart restart process with anti-conflict protection is triggered to restore service availability.

[0079] It should be noted that the overall process of the application-level daemon mechanism begins with the dynamic service discovery of the main daemon process (see the description in the aforementioned embodiments regarding periodically scanning the application deployment directory and automatically discovering business application services based on custom daemon scripts). The main daemon process periodically scans the application deployment directory, discovers all services configured with the script / guard.sh script, and then sequentially calls the guard.sh script for each service. Taking the police-server service as an example, its typical path for the custom daemon script is / iotp / standard / police-server / script / guard.sh. After this script is called, it does not directly restart the service, but first calls the service startup script (such as start.sh) in the same directory. The start.sh script encapsulates complete health check and secure startup logic: it first calls a dedicated health check script (such as health.sh) to comprehensively evaluate the current state of the police-server service. The health.sh script is a key component for implementing "multiple health checks," and its check logic is sequential and strict. If the result returned by health.sh indicates that the service is normal, the start.sh script does nothing and exits directly. If health.sh returns a failure (indicating the service is not running, is frozen, or its business status is abnormal), the start.sh script will then proceed with the startup process. Before starting, it performs a critical startup lock check to prevent other concurrently running daemons from repeatedly restarting the service during the startup process (which can take tens of seconds), causing serious problems such as port conflicts. Only after confirming there are no conflicts will it call the actual service startup command (usually located in bin / start.sh) and wait until the service is ready. This series of actions constitutes a complete "detection-decision-safe restart" closed loop.

[0080] It's important to note that application-level and system-level protection mechanisms form a clear division of responsibilities and complement each other's strengths. System-level protection, leveraging systemd's deep system integration, provides standardized and highly reliable "process-level monitoring" for middleware services. Application-level protection, on the other hand, with its flexibility and deep inspection capabilities, provides "business-level monitoring" for business application services. This layered design ensures that each service receives the most suitable protection strategy for its characteristics, fundamentally resolving the various drawbacks of the "one-size-fits-all" approach of existing technologies, and achieving refined and optimized overall server stability assurance.

[0081] In one embodiment, the existence of the target service process can be checked first. Then, if the target service process exists, a preset health interface is accessed to obtain health status data. Next, if the health interface returns a Hypertext Transfer Protocol status code indicating normal operation, at least one business logic status field is extracted from the health status data. Finally, based on the value of the business logic status field, the normality of the target service's business logic status is determined. Thus, by specifying a progressively advancing multi-step health check process for the business application service (checking the process → accessing the health interface → resolving the business status), a logically rigorous and progressively in-depth check process is constructed, ensuring accurate identification of the specific aspect of service anomalies (whether it's a process crash, an interface anomaly, or a business logic failure), improving the timeliness and accuracy of problem detection.

[0082] The implementation of the multi-factor health check mechanism can be accomplished by a separate health check script (e.g., health.sh). This script accepts parameters such as the service process name and the health interface port, and performs three checks according to a rigorous, sequential execution process. Failure of any one check will result in an abnormal overall health check result.

[0083] First check: Process existence check. This is the most basic layer of checks, designed to confirm whether an executable instance of the service is running on the operating system. The check script performs this by executing process lookup commands, such as `ps -ef|grep {target service process name}|grep -vgrep`. This command searches the system process list for entries matching the given process name. If no output is found after execution, it indicates that no process matches the name, meaning the process does not exist. The check script immediately determines the service status as "abnormal" and returns a failure code; subsequent checks are not performed. For example, for the `police-server` service, this command will look for processes containing the keyword "police-server". If the process exists, the second check is then performed.

[0084] The second check: Health Interface Availability Check. This check aims to detect a "process exists but service is unresponsive" dead state. It assumes a healthy business application service should provide a health endpoint for external probing, which is a specific HTTP API endpoint, such as http: / / 127.0.0.1:{port number} / actuator / healthCheck. The check script sends an HTTP GET request to this endpoint address via a command-line tool (such as curl). The criterion is the HTTP response status code. If the service process is in a dead state, the request may time out, be rejected, or return a 5xx series server error status code. This check is considered passed only if the curl command returns an HTTP status code of 200 (indicating a successful request). If the status code is not 200, or the request fails, the service status is immediately determined to be abnormal. For example, for a police-server running on port 8080, the script executes curl -so / dev / null -w "%{http_code}"http: / / 127.0.0.1:8080 / actuator / healthCheck to obtain the status code. This check effectively distinguishes between "live processes" and "healthy processes".

[0085] The third check: Business logic status check. This is the highest-level and most critical check, designed to verify that not only is the service process alive and able to respond to HTTP requests, but its internal key business function components are also functioning normally. When returning an HTTP 200 status code, the business application service typically returns a structured data block (such as JSON format) in the response body, containing several fields representing the status of its internal submodules. After passing the second check, the check script parses the complete response body (i.e., health status data) obtained by the curl command. The script is pre-programmed to identify and extract specific business logic status fields. The values ​​of these fields are typically boolean (true / false) or strings (such as "UP" / "DOWN"). The script checks the value of each predefined business logic status field in turn. Only when all checked field values ​​indicate "normal" or "ready" (e.g., all field values ​​are true) is the entire multi-layered health check ultimately deemed "successful." If any critical business logic status field has a value of "abnormal" (such as false), then even if the first two checks pass, the service status is ultimately determined to be "abnormal." For example, a typical health check JSON response might look like this: {"status":"UP","nacos_regist_status":true,"kafka_connect_status":false}. The script will extract the `nacos_regist_status` and `kafka_connect_status` fields. If `kafka_connect_status` is false, it indicates that although the service is running, it cannot communicate with the Kafka message queue, and some of its business functions have failed; therefore, the health check has failed.

[0086] It's important to note that this three-tiered, progressive inspection system—"process → interface → business"—constitutes a defense-in-depth system. It verifies service availability layer by layer, from the outside in, from the surface to the essence. Process checks filter out complete crashes; healthy interface checks filter out network stack or infrastructure freezes; and business logic checks filter out situations where the service framework exists but core business dependencies or internal states are abnormal. This design ensures that only instances truly possessing complete business service capabilities are considered healthy by the system, thus enabling near 100% detection of "service freezes" that traditional methods cannot detect.

[0087] In one embodiment, the preset business logic state includes at least one of the following: the registration status of the target service in the service registry, and the connection status of the target service with the message middleware. Thus, by concretizing the business logic state into service registration status and message middleware connection status, health checks can directly verify the collaboration capabilities between business application services and key distributed components, ensuring the true availability of services at the business level and preventing service function paralysis due to registration or connection failures.

[0088] It's important to note that in business logic status checks, the status fields of interest directly reflect whether the critical runtime dependencies of the business application service are functioning correctly within the distributed architecture. This is a crucial basis for determining whether it can truly provide business services. Among these, the two most common and representative business logic states include: Service Registry Registration Status: In microservices or distributed architectures, after a business application service (service provider) starts, it needs to register with a centralized service registry (such as Nacos, Eureka, Consul), reporting its network address, metadata, and other information so that other services (service consumers) can discover and invoke it. Therefore, "successful registration" is a prerequisite for a service to be invoked. The health check script parses fields similar to nacos_regist_status, eureka_registration_status, or service_registration in the data returned by the health interface. If the value of this field is false or "DOWN", it indicates that the service is "out of contact" with the registry. Even if its process and HTTP interface are normal, it cannot be discovered and accessed by other components in the system, which is equivalent to the service being unavailable.

[0089] Message queue connection status: Many business applications rely on message queues (such as Kafka, RabbitMQ, and RocketMQ) for asynchronous communication, event-driven processes, or traffic shaping. Services need to establish and maintain stable connections with one or more servers (brokers) of the message queue to consume or produce messages. A broken connection will lead to message backlog, event loss, and business process interruption. Health check scripts parse fields like `kafka_connect_status`, `rabbitmq_connected`, or `mq_connection`. If this field is false, it indicates that the communication link between the service and the message queue has been broken, and its business functions that rely on asynchronous messaging have failed.

[0090] It's important to note that while the above two items are core checks, the framework for business logic status checks is open and extensible. Depending on the characteristics of specific business services, other key check fields can be added, such as: database connection pool status (checking if all database connections are valid), cache service connection status (checking connections to Redis, etc.), external application programming interface (API) dependency status (checking if critical third-party services are reachable), and internal worker thread pool status (checking if there are enough threads to handle requests). The health check script `health.sh` is designed to allow for easy addition and deletion of check items; simply adjust its logic for parsing the response JSON data. This enables the application-level daemon mechanism to flexibly adapt to the specific health metrics of various complex business services, achieving true deep monitoring.

[0091] In one embodiment, the application-level daemon mechanism further includes: before triggering a restart of the target service, checking whether a pre-set lock file exists for the target service; if the lock file exists, reading the timestamp recorded in the lock file and calculating the difference between the timestamp and the current time; if the difference between the timestamp and the current time is less than a pre-set timeout threshold, determining that the target service is in the startup process and aborting the current restart operation. Therefore, by checking the timestamp-based lock file and determining whether the startup has timed out before triggering a restart, the mechanism effectively prevents duplicate startups caused by a detection period shorter than the startup duration during service startup, avoids port conflicts and resource contention, and ensures the orderly nature of the service restart process.

[0092] It's important to note that starting a business application service is often a time-consuming process, potentially involving loading extensive configurations, connecting multiple external dependencies, and initializing complex data structures, typically taking anywhere from 10 seconds to several minutes. However, the main daemon process of the application-level daemon mechanism may have a shorter detection cycle (e.g., 15 seconds) than the service startup time. This leads to a serious problem: when the daemon process detects a service anomaly and triggers startup for the first time, the service is already starting but not yet ready; a second detection 15 seconds later, since the service still hasn't passed the health check, will trigger startup again, resulting in the same service being started concurrently multiple times. Multiple instances competing for the same network port, the same file lock, or the same memory resource will inevitably cause conflicts, ultimately preventing all instances from starting successfully.

[0093] To address the aforementioned issues, this application introduces a startup lock mechanism into the application-level daemon mechanism. The core idea of ​​this mechanism is: before starting the service, a lock file is used to mark "this service is starting," and other concurrent startup attempts must wait or abort upon detecting this mark. The specific implementation steps are as follows: Before a service's startup script (such as start.sh) decides to perform a restart operation, it first checks a lock file pre-defined for that service in a specific path (for example, creating a file named .start_lock in the service directory). If the lock file does not exist, it means that no other process is currently starting the service, and it is safe to proceed with the startup process.

[0094] If the lock file exists, it indicates that another boot process may already be running. In this case, the boot script cannot simply abandon or forcibly overwrite it, because the previous boot process may have failed without clearing the lock, or it may still be in progress. Therefore, the script reads the contents of the lock file, which is a pre-written Unix timestamp recording the start time of this boot attempt (e.g., in seconds since January 1, 1970, such as 1735689600). The boot script obtains the current system's Unix timestamp and calculates the difference (the time elapsed).

[0095] The system presets a timeout threshold (e.g., 300 seconds, or 5 minutes). This threshold represents the maximum reasonable time allowed for a service to start. The startup script compares the calculated time difference with the timeout threshold. If the difference is less than the timeout threshold (e.g., only 30 seconds have passed), it is logically determined that the last startup attempt occurred recently and has not yet timed out, meaning the service is likely still in the normal startup process. In this case, the startup script should abort the current restart operation and exit immediately, thus avoiding interference with the service that is starting. This mechanism ensures that within the service startup window, regardless of how many periodic checks the main daemon performs, only the first process that detects an anomaly will trigger startup; subsequent checks will silently exit upon finding a "not-timed-out lock," effectively preventing duplicate startups.

[0096] Furthermore, to build more robust protection, the startup lock mechanism sets up a second line of defense in the health check script (health.sh), forming a double protection. When the health.sh script is called to perform a health check, before performing regular process, interface, and business status checks, it first checks whether the startup lock file (.start_lock) corresponding to the service exists. If the lock file exists, the script reads the timestamp and calculates the lock's duration. If this duration is less than the preset startup timeout threshold (e.g., 300 seconds), and the process check confirms that the service's main process already exists, the health.sh script immediately returns a "healthy" or "starting" status, and does not execute subsequent HTTP interface checks or business logic checks that might fail due to the service not being fully ready. This design ensures that the main daemon process, during periodic checks, considers the service healthy once it finds it in a "starting" state, thus fundamentally avoiding repeated triggering of the startup process within the startup window. This logic complements the lock check in start.sh, jointly ensuring the uniqueness and stability of the service startup process.

[0097] In one embodiment, if the difference between the timestamp and the current time is greater than or equal to a timeout threshold, the system can first check if the target service process exists; if the target service process exists, stop the target service process; after confirming that the target service process has stopped, delete the lock file; and after deleting the lock file, execute the target service restart process in the application-level daemon mechanism. Thus, by executing the process of stopping the existing process, cleaning up the lock file, and restarting after the lock file times out, the system can automatically perform on-site cleanup and attempt recovery when the service startup is stuck or abnormal, enhancing the self-recovery capability and robustness of the application-level daemon mechanism in abnormal scenarios.

[0098] It's important to note that the startup lock mechanism not only needs to prevent duplicate operations during normal startup, but also must be able to handle abnormal situations such as startup timeouts or process remnants after startup failures; otherwise, the service will never be able to be restarted. This is the timeout handling logic of the startup lock.

[0099] Specifically, when the startup script checks the lock file and calculates a time difference greater than or equal to a preset timeout threshold (e.g., 310 seconds have elapsed), it determines that the previous startup attempt has timed out. A timeout can indicate two scenarios: 1) the service startup failed, the process exited, but the lock file was not cleaned up; 2) a serious error occurred during the service startup process, and the process is stuck somewhere, unable to continue or exit on its own. In this case, the startup script cannot directly delete the lock and restart, because the remaining process will occupy resources such as ports, causing new startup attempts to fail immediately.

[0100] Therefore, the startup script can enter a rigorous cleanup and recovery process: First, check if the process exists. The script uses the same process lookup command as the health check to confirm whether there are still processes running corresponding to the service. Second, stop any remaining processes. If the process does exist, it indicates a residual process scenario. The startup script will first attempt to gracefully stop the process, for example, by calling the service's built-in stop script (such as stop.sh). If graceful stopping fails or there is no stop script, a termination signal (such as kill-15) is sent, and finally, if necessary, a forced termination signal (such as kill-9) is sent to ensure the process is completely removed. This step is crucial to avoid resource conflicts between old and new processes. Third, delete the old lock file. After confirming that the residual process has been terminated, or if the initial check found that the process does not exist, the startup script safely deletes the expired .start_lock file. This signifies that the previous failed startup attempt has been officially cleaned up. Fourth, execute the restart process. After cleaning up the old lock and residual processes, the process currently running on the startup script now has unique startup rights. It then begins executing the standard startup process: First, it creates a new lock file and writes the current Unix timestamp to mark the start of a new startup cycle. Then, it calls the actual service startup command (e.g., bin / start.sh). Finally, it enters a waiting loop, periodically (e.g., every 2 seconds) calling health.sh to check the service status and wait for the service to be ready. If the service health check passes within the timeout threshold (e.g., 300 seconds), the newly created lock file is deleted, indicating successful startup. If the wait times out again, the lock file is retained, and the process exits, waiting for the next daemon check cycle to handle the new timeout lock, thus forming a closed-loop recovery attempt.

[0101] It's important to note that the aforementioned timeout handling mechanism, together with the logic in the health check script, forms a double layer of protection. The health.sh script can also include checks for the startup lock. If health.sh finds that the lock file exists and hasn't timed out, and the process also exists, then even if the health interface check hasn't passed, it can temporarily return to a "healthy" or "starting" state to proactively inform the main daemon process that "no restart is needed," thus preventing the possibility of repeated startups from another path. This design ensures the robustness of the startup lock mechanism, enabling business application services to be automatically and safely guided to a normal operating state by the system in any abnormal startup state, which is one of the core guarantees for achieving high service availability.

[0102] The service stability assurance method disclosed in the above embodiments of this application adopts a system-level protection mechanism or an application-level protection mechanism differently according to the service type (middleware service / business application service), and performs multiple health checks on the business application service, including process, health interface and business logic status, so as to effectively detect and restore the "frozen" state of the business application service, and significantly improve the availability and stability of the business service.

[0103] The effectiveness of the aforementioned service stability assurance methods will be introduced below in specific scenarios.

[0104] Scenario 1: Middleware Service Guardian (Nacos). Corresponding Protection Point: System-level Guardian Module - Service Process Guardian Submodule. Scenario Description: The Nacos configuration center service exits abnormally due to memory overflow. Guardian Process: 1) systemd detects the disappearance of the Nacos process; 2) Based on the configuration of Restart=always and RestartSec=5 in nacos.service, the ExecStart command is automatically executed after a 5-second delay; 3) The Nacos service is restarted and service is restored. Effectiveness Verification: This embodiment verifies the effectiveness of the system-level guardian module. After the middleware service exits abnormally, it can automatically restart within seconds (e.g., 5 seconds) without manual intervention, increasing service availability from approximately 95% with traditional manual recovery to over 99.9%.

[0105] Scenario 2: Business Service False Dead Protection (police-server). Corresponding Protection Point: Application-level Guardian Module - Multi-level Health Check Submodule. Scenario Description: The police-server service is in a false dead state; the process exists but cannot respond to requests and is not registered with Nacos. Guardian Process: 1) The main guardian process calls guard.sh; 2) health.sh performs checks: process check passes, health interface check fails (or returns an abnormal business status); 3) If the service is found to be abnormal, start.sh checks the start lock, executes the stop and restart process; 4) After the service recovers, it is re-registered with Nacos. Effect Verification: This embodiment verifies that the multi-level health check mechanism can detect "false dead" problems that traditional process checks cannot detect. The service false dead detection rate is increased from 0% in the existing technology to 100%, and the availability of business services is significantly improved.

[0106] Scenario 3: Startup Lock to Prevent Duplicate Startups (police-evidence). Corresponding Protection Point: Startup lock module. Scenario Description: The police-evidence service requires 30 seconds to start, with a 15-second protection period. Protection Process (Without Lock): Startup is triggered at time T0. At T0+15 seconds, the service is not ready and startup is triggered again, causing port conflicts and startup failure. Protection Process (With Lock): A lock is created and startup is initiated at time T0. At T0+15 seconds, the lock is found to have not timed out, the second startup is abandoned, and the lock is deleted after the service is ready at T0+30 seconds. Effect Verification: This embodiment verifies that the startup lock mechanism can completely prevent duplicate startups. The service duplicate startup rate is reduced from approximately 35% without protection to 0%, and the startup success rate is increased from approximately 82% to 99.9%, eliminating the risk of port conflicts.

[0107] Scenario 4: NAS Storage Resource Protection. Corresponding Protection Point: System-level Protection Module - Resource Availability Protection Submodule. Scenario Description: A NAS storage server restart causes the mount point on the main server that services depend on to fail. Protection Process: 1) systemd detects the failure of the iotp-data.mount unit; 2) Based on the configured retry=10, timeo=60 policy, it automatically attempts to reconnect and remount; 3) After the NAS recovers, the mount is automatically restored, and services that depend on this storage can continue to run or automatically restart. Performance Verification: This embodiment verifies the resource-layer protection capability. It solves the startup sequence and runtime disconnection issues, ensures the continuous availability of critical storage resources, and reduces the service failure rate caused by storage disconnection by more than 90%.

[0108] Scenario 5: Automatic Adaptation of New Services (police-gateway). Corresponding Protection Point: Dynamic Service Discovery Module. Scenario Description: Deploying a new `police-gateway` service to the server. Guardian Process: 1) Deploying the service to ` / iotp / standard` according to the standard directory structure (including `script / guard.sh`); 2) The main daemon process automatically discovers the new directory in the next scan cycle (within 15 seconds); 3) After verifying the existence of `guard.sh`, it immediately adds it to the daemon list and begins detection. Performance Verification: This example verifies the automation capabilities of dynamic service discovery. The time for adding a new service to the daemon system is reduced from approximately 30 minutes required for manual configuration to 0 minutes, improving management efficiency by 100% and eliminating omissions.

[0109] The service stability assurance method based on a layered daemon architecture provided in this application brings the following significant benefits: The comprehensiveness of health checks has been fundamentally improved: through a triple check mechanism of "process → health interface → business logic", it can detect deep-seated faults such as service freezes with 100% accuracy, overcoming the limitation of existing technologies that only check processes.

[0110] Innovative and flexible protection mechanism: It pioneers a layered protection architecture that intelligently identifies service types and automatically matches the optimal protection strategy (using systemd for middleware and custom scripts for business services), achieving differentiated and precise protection.

[0111] Service stability and availability are significantly enhanced: Whether it is a process crash, a freeze, or a failure of dependent resources, the system can automatically and quickly recover, increasing the overall service availability from about 95% in traditional solutions to over 99.9%.

[0112] The convenience of operation and maintenance management has been greatly improved: the dynamic service discovery mechanism realizes "deployment is protection", eliminating the need to manually maintain the service list; standardized scripts and configurations reduce the complexity of operation and maintenance and the learning cost.

[0113] Completely eliminates duplicate startup issues: The innovative startup lock mechanism and its dual protection logic completely solve the port conflict and resource contention problems during service startup, ensuring a high startup success rate.

[0114] Achieve in-depth business logic inspection: For the first time, key business states such as service registration and message queue connections are included in health standards to ensure that services are not only "alive" but also "working healthily".

[0115] Extended resource availability assurance: The system-level protection scope is extended from processes to critical resources such as external storage. Through dependency management and automatic retries, a complete elastic recovery system from infrastructure to upper-layer applications is built.

[0116] See Figure 2 The diagram shows a service stability assurance device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0117] The service stability assurance device may specifically include the following modules: The type identification module 201 is used to identify the service type of the target service running on the server, where the service type includes middleware services and business application services.

[0118] The system-level guardian module 202 is used to detect and restore the target service when the target service is identified as a middleware service. The system-level guardian mechanism includes: checking whether the process of the target service exists through the system service manager, and triggering the restart of the target service if the process does not exist.

[0119] The application-level guardian module 203 is used to detect and restore the target service when the target service is identified as a business application service. The application-level guardian mechanism includes: performing multiple health checks on the target service by executing a custom guardian script, and triggering the restart of the target service if the check fails. The multiple health checks include at least checking whether the process exists, checking whether the preset health interface returns to a normal state, and checking whether the preset business logic state is normal.

[0120] The service stability assurance device disclosed in the above embodiments of this application can effectively detect and restore the "frozen" state of business application services by adopting system-level protection mechanisms or application-level protection mechanisms differently according to the service type (middleware service / business application service) and performing multiple health checks on business application services, including process, health interface and business logic status, thereby significantly improving the availability and stability of business services.

[0121] Furthermore, in one possible implementation of this application embodiment, the type identification module 201 may specifically include the following units: The first determining unit is used to determine whether the target service is a middleware service based on the matching relationship between the installation directory of the target service and the preset system standard directory, and based on whether the target service is configured with a unit file of the system service manager.

[0122] The second determining unit is used to determine whether the target service is a business application service based on the matching relationship between the installation directory of the target service and at least one preset application deployment directory, and based on whether there is a custom daemon script with a preset name in the directory of the target service.

[0123] Therefore, by identifying the service type based on the service installation directory (system standard directory / application deployment directory) and the existence of specific configuration files (system unit files / custom daemon scripts), the middleware service and business application service can be automatically and accurately distinguished, providing a reliable basis for implementing differentiated daemonization and reducing manual configuration.

[0124] Furthermore, in another possible implementation of this application embodiment, the application-level guardian module 203 may specifically include the following units: The first processing unit is used to check whether the process of the target service exists.

[0125] The first acquisition unit is used to access a preset health interface to obtain health status data when the process of the target service exists.

[0126] The second acquisition unit is used to extract at least one business logic status field from the health status data when the health interface returns a Hypertext Transfer Protocol status code indicating normal operation.

[0127] The third determining unit is used to determine whether the business logic status of the target service is normal based on the value of the business logic status field.

[0128] Therefore, by stipulating a series of progressive health check steps for business application services (checking the process → accessing the health interface → resolving the business status), a logically rigorous and progressively in-depth check process is constructed, ensuring that the specific link of service anomaly (whether it is a process crash, an interface anomaly, or a business logic failure) can be accurately located, improving the timeliness and accuracy of problem discovery.

[0129] Furthermore, in another possible implementation of this application embodiment, the aforementioned preset business logic state includes at least one of the following: the registration status of the target service in the service registry center, and the connection status of the target service with the message middleware.

[0130] Therefore, the business logic state is concretized into service registration state and message middleware connection state. Health checks can directly verify the collaboration capabilities between business application services and key distributed components, ensuring the true availability of services at the business level and avoiding service function paralysis due to registration or connection failures.

[0131] Furthermore, in another possible implementation of this application embodiment, the application-level guardian module 203 is specifically used to: check whether a lock file preset for the target service exists before triggering the restart of the target service; if the lock file exists, read the timestamp recorded in the lock file and calculate the difference between the timestamp and the current time; if the difference between the timestamp and the current time is less than a preset timeout threshold, determine that the target service is in the startup process and stop the current restart operation.

[0132] Therefore, by checking the timestamp-based lock file and determining whether the startup has timed out before triggering a restart, the problem of repeated startup caused by the detection period being shorter than the startup duration can be effectively prevented during the service startup process, avoiding port conflicts and resource contention, and ensuring the orderly nature of the service restart process.

[0133] Furthermore, in another possible implementation of this application embodiment, the above-mentioned service stability assurance device may further include the following modules: The timeout detection module checks whether the process of the target service exists if the difference between the timestamp and the current time is greater than or equal to the timeout threshold; if the process of the target service exists, it stops the process of the target service; after confirming that the process of the target service has stopped, it deletes the lock file; after deleting the lock file, it executes the restart process of the target service in the application-level daemon mechanism.

[0134] Therefore, by executing the process of stopping the existing process, cleaning up the lock file, and then restarting after the lock file times out, it is possible to automatically perform on-site cleanup and attempt recovery when the service startup is stuck or abnormal, thereby enhancing the self-recovery capability and robustness of the application-level daemon mechanism in abnormal scenarios.

[0135] Furthermore, in another possible implementation of this application embodiment, the above-mentioned service stability assurance device may further include the following modules: The service type determination module is used to periodically scan at least one preset application deployment directory, and during the scanning process, obtain the first-level directory under each application deployment directory as the service unit directory; for each service unit directory, check whether there is a custom daemon script with a preset name in the service unit directory; if there is a custom daemon script in the service unit directory, determine the service corresponding to the service unit directory as the target service with the service type of business application service.

[0136] Therefore, by periodically scanning the application deployment directory and automatically discovering business application services based on custom daemon scripts, the system achieves automatic management of newly added or deployed business services without the need for manual updates to the service list, greatly improving the management efficiency and automation level of the daemon system.

[0137] Furthermore, in another possible implementation of this application embodiment, the above-mentioned service stability assurance device may further include the following modules: The mount status detection module is used to detect the mount status of external network storage resources through the system service manager. These external network storage resources provide storage space for the server, and the normal operation of middleware services or business application services depends on access to them. If the mount status of an external network storage resource is detected to be invalid, the module will automatically perform a retry mount operation to restore resource availability.

[0138] Therefore, by using the system service manager to detect the mounting status of external storage resources and automatically retry mounting when failure occurs, the availability of the basic storage resources on which the server depends is ensured, providing reliable resource support for the stable operation of various upper-layer services and demonstrating the integrity of the protection mechanism.

[0139] The service stability assurance device provided in this application embodiment can be applied in the foregoing method embodiments. For details, please refer to the description of the above method embodiments, which will not be repeated here.

[0140] Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 300 of this embodiment includes: at least one processor 310 ( Figure 3 The diagram shows only one processor, a memory 320, and a computer program 321 stored in the memory 320 and executable on the at least one processor 310. When the processor 310 executes the computer program 321, it implements the steps in the above-described service stability assurance method embodiment.

[0141] The electronic device 300 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 310 and a memory 320. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 300 and does not constitute a limitation on electronic device 300. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0142] The processor 310 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0143] In some embodiments, the memory 320 may be an internal storage unit of the electronic device 300, such as a hard disk or memory of the electronic device 300. In other embodiments, the memory 320 may be an external storage device of the electronic device 300, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 300. Furthermore, the memory 320 may include both internal and external storage units of the electronic device 300. The memory 320 is used to store operating systems, applications, boot loaders, data, and other programs, such as the program code of computer programs. The memory 320 can also be used to temporarily store data that has been output or will be output.

[0144] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0145] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0146] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0148] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0150] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0151] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the various method embodiments described above.

[0152] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for ensuring service stability, characterized in that, include: Identify the service type of the target service running on the server, wherein the service type includes middleware services and business application services; If the target service is identified as the middleware service, a system-level protection mechanism is used to detect and restore the target service. The system-level protection mechanism includes: checking whether the process of the target service exists through the system service manager, and triggering the restart of the target service if the process does not exist. When the target service is identified as the business application service, an application-level protection mechanism is used to detect and restore the target service. The application-level protection mechanism includes: performing multiple health checks on the target service by executing a custom protection script, and triggering the restart of the target service if the check fails. The multiple health checks include at least checking whether the process exists, checking whether the preset health interface returns to a normal state, and checking whether the preset business logic state is normal.

2. The method according to claim 1, characterized in that, The service type of the target service running on the identification server includes: Based on the matching relationship between the installation directory of the target service and the preset system standard directory, and based on whether the target service is configured with a unit file of the system service manager, it is determined whether the target service is a middleware service; Based on the matching relationship between the installation directory of the target service and at least one preset application deployment directory, and based on whether there is a custom daemon script with a preset name in the directory of the target service, it is determined whether the target service is a business application service.

3. The method according to claim 1, characterized in that, The process of performing multiple health checks on the target service by executing a custom daemon script includes: Check if the process of the target service exists; If the process of the target service exists, access the preset health interface to obtain health status data; If the health interface returns a Hypertext Transfer Protocol status code indicating normal operation, at least one business logic status field is extracted from the health status data. Based on the value of the business logic status field, determine whether the business logic status of the target service is normal.

4. The method according to claim 1 or 3, characterized in that, The preset business logic state includes at least one of the following: the registration status of the target service in the service registry center, and the connection status of the target service with the message middleware.

5. The method according to claim 1, characterized in that, The application-level protection mechanism also includes: Before triggering the restart of the target service, check if the lock file preset for the target service exists; If the lock file exists, read the timestamp recorded in the lock file and calculate the difference between the timestamp and the current time; If the difference between the timestamp and the current time is less than a preset timeout threshold, the target service is determined to be in the startup process, and the current restart operation is aborted.

6. The method according to claim 5, characterized in that, The method further includes: If the difference between the timestamp and the current time is greater than or equal to the timeout threshold, check whether the process of the target service exists. If the process of the target service exists, stop the process of the target service; After confirming that the process of the target service has stopped, delete the lock file; After deleting the lock file, the restart process of the target service in the application-level daemon mechanism is executed.

7. The method according to claim 1, characterized in that, Before identifying the service type of the target service running on the server, the method further includes: Periodically scan at least one preset application deployment directory, and during the scanning process, obtain the first-level directory under each application deployment directory as the service unit directory; For each of the service unit directories, check whether a custom daemon script with a preset name exists in the service unit directory; If the custom daemon script exists in the service unit directory, the service corresponding to the service unit directory is identified as the target service with the service type of the business application service.

8. The method according to claim 1, characterized in that, The method further includes: The system service manager detects the mounting status of external network storage resources, which are used to provide storage space for the server. The normal operation of the middleware service or the business application service depends on access to the external network storage resources. If the mounting status of the external network storage resource is detected to be invalid, the mounting operation will be automatically retried to restore resource availability.

9. A service stability assurance device, characterized in that, include: The type identification module is used to identify the service type of the target service running on the server, wherein the service type includes middleware services and business application services; A system-level guardian module is used to detect and restore the target service when the target service is identified as the middleware service using a system-level guardian mechanism. The system-level guardian mechanism includes: checking whether the process of the target service exists through the system service manager, and triggering the restart of the target service if the process does not exist. An application-level guardian module is used to detect and restore the target service when the target service is identified as the business application service using an application-level guardian mechanism. The application-level guardian mechanism includes: performing multiple health checks on the target service by executing a custom guardian script, and triggering the restart of the target service if the checks fail. The multiple health checks include at least checking whether the process exists, checking whether the preset health interface returns to a normal state, and checking whether the preset business logic state is normal.

10. An electronic 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, it implements the method as described in any one of claims 1 to 8.

Images