Service scheduling method, system and equipment based on container starting sequence and medium

Abstract

The invention provides a service scheduling method, system and device based on a container starting sequence and a medium, and belongs to the technical field of distributed system operation and maintaining.The method comprises the steps that a container arrangement file is analyzed, and a directed acyclic graph representing the dependency relationship between services is constructed; generating a starting sequence according to the directed acyclic graph based on a topological sorting algorithm; starting the corresponding containers in sequence according to the starting sequence, and monitoring the health state of each container in real time; and when determining that the container fails to be started due to the dependency service based on the health state monitoring result, triggering a retry operation according to a pre-configured retry strategy. The startup success rate and deployment efficiency of the containerized application are improved, and the manual intervention cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of distributed system operation and maintenance technology, specifically to a service scheduling method, system, device, and medium based on container startup order. Background Technology

[0002] With the widespread adoption of microservice architecture and containerization technology, modern distributed applications typically consist of dozens or even hundreds of loosely coupled services, deployed and managed through container orchestration platforms such as Kubernetes and Docker Swarm. In this architecture, complex startup sequence dependencies exist between services. For example, the database service must start and complete initialization before the application business service, and the business service must start before the web gateway service. Ensuring the proper management of these dependencies is a crucial prerequisite for the successful startup and stable operation of the entire distributed system.

[0003] To address the challenges of service startup dependencies, several mainstream technical solutions exist in this field. One is to manually configure a fixed wait time, i.e., embed a fixed delay (such as `sleep 30`) instruction into the container startup command of subsequent services, artificially forcing a delayed startup. Another is to utilize the health check probes (Readiness Probes) provided by the container platform to periodically check whether the target ports or interfaces of dependent services are ready. A third is the Init Container mode, which performs availability checks on dependent services by running one or more init containers before the main application container starts.

[0004] The first dependency management method has the following problems: a fixed wait time cannot adapt to the differences in service startup time under different environments; setting it too short will cause dependencies to start before they are ready, while setting it too long will lead to idle resources, wasting resources and prolonging deployment time. The second dependency management method has the following problems: it can only passively detect and cannot actively trigger retry startups; manual intervention is often required after a detection failure. The third dependency management method has the following problems: it usually only performs a single check, lacking fault tolerance and retry capabilities for transient failures, i.e., it lacks a dynamic retry mechanism; if the dependent service times out, the entire deployment process will fail. Summary of the Invention

[0005] In view of this, it is necessary to provide a service scheduling method, system, device and medium based on container startup order to solve the technical problems of poor fault tolerance and low efficiency in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a service scheduling method based on container startup order, comprising: Parse the container orchestration file and construct a directed acyclic graph representing the dependencies between services; Based on the topological sorting algorithm, a starting sequence is generated according to the directed acyclic graph; The corresponding containers are started sequentially according to the startup sequence, and the health status of each container is monitored in real time. When it is determined from the health status monitoring results that the container fails to start due to the dependent service, a retry operation is triggered according to the pre-configured retry policy.

[0007] In one possible implementation, when it is determined from health status monitoring results that the container has failed to start due to the dependent service, triggering a retry operation according to a pre-configured retry policy includes: Based on the health status monitoring results and the directed acyclic graph, the target dependency service that caused the startup failure is determined; the target dependency service is the first dependency service in the dependency chain where the abnormal container is located whose health status is abnormal; When the timer reaches the initial retry duration, a restart command is sent to the target dependent service to perform a start retry operation on the target dependent service.

[0008] One possible implementation also includes: Based on the dependency relationships of the directed acyclic graph, the set of downstream containers of the target dependent service is identified; During the retry period, the retry count of each container in the downstream container set remains unchanged.

[0009] In one possible implementation, after the timer reaches the initial retry duration, sending a restart command to the target dependent service to perform a start retry operation on the target dependent service includes: Obtain the retry startup result of the target dependent service; The latest retry duration is calculated based on the initial retry duration and the retry start result; wherein, if the retry start result is a start failure, the latest retry duration increases exponentially. After the timer reaches the latest retry duration, a restart command is sent to the target dependent service to perform a start retry operation on the target dependent service; The number of retries for the failed startup of the target dependent service is counted, and when the number of retries reaches the maximum threshold, the startup retry operation is stopped and an alarm is triggered.

[0010] In one possible implementation, the step of generating the startup sequence based on the directed acyclic graph, followed by: Identify container groups in the directed acyclic graph that do not have dependencies, and perform parallel startup on the containers in the container groups.

[0011] In one possible implementation, monitoring the health status of each of the containers includes: The process status of the container is checked using a process liveness detection probe; The reachability of the service port corresponding to the container is detected by a socket probe. The response status of the service port corresponding to the container is detected by a health check probe; The health status of the container is determined based on the detection results. The health status includes container ready status, container startup failure status, and dependency unmet status.

[0012] In one possible implementation, classifying the detection results into health status events such as container ready, container startup failure, and unmet dependencies includes: When the container's process is running normally, the service port is reachable, the response status is successful, and all the dependent services are ready, the health status is determined to be the container's ready state. When the container's process is running normally, the service port is reachable, and the response status is successful, but there are dependent services that are not ready, the health status is determined to be a dependent unmet status. When the container's process runs abnormally, the service port is unreachable, or the response status is failure, the health status is determined to be the container startup failure status.

[0013] Secondly, the present invention also provides a service scheduling system based on container startup order, comprising: The dependency analysis module is used to parse container orchestration files, construct a directed acyclic graph representing the dependencies between services, and generate a startup sequence based on the directed acyclic graph using a topology sorting algorithm. A health monitoring module is used to sequentially start the corresponding containers according to the startup sequence and monitor the health status of each container in real time. A retry scheduler is used to trigger a retry operation according to a pre-configured retry policy when it is determined from the health status monitoring results that the container has failed to start due to the dependent service.

[0014] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the service scheduling method based on container startup order as described in any of the above implementations.

[0015] Fourthly, the present invention also provides a computer-readable storage medium for storing a computer-readable program or instruction, which, when executed by a processor, can implement the steps of the service scheduling method based on container startup order described in any of the above implementations.

[0016] The beneficial effects of this invention are as follows: The service scheduling method based on container startup order provided by this invention first constructs a directed acyclic graph by parsing the container orchestration file, and generates a startup sequence based on a topology sorting algorithm. This ensures that container services start in the correct dependency order, effectively avoiding problems caused by incorrect startup order and improving the deployment success rate and reliability of containerized applications. Furthermore, during container operation, various reasons may lead to abnormal container health states, such as dependent service failures, network problems, and insufficient resources. Real-time monitoring of container health status and handling it according to dependencies and retry strategies helps improve system availability and stability. Moreover, real-time monitoring allows for timely detection of container health problems and identification of the root cause based on dependencies. When a dependent service startup failure causes a container abnormality, retrying according to a pre-configured retry strategy increases the chance of successful container startup and reduces container downtime caused by dependent service failures, thereby improving the overall system availability. In addition, it can automatically handle some temporary faults to a certain extent, enhancing the system's self-healing capabilities and making the system more stable and reliable. Furthermore, based on container orchestration files and container startup and health monitoring mechanisms, operations personnel only need to correctly configure container orchestration files and retry policies. The system can then automatically complete a series of operations such as container startup, health monitoring, and fault retries, reducing manual intervention, lowering the workload and error probability of operations personnel, and significantly improving operational efficiency and reducing costs. Simultaneously, the improved system availability and stability reduce business downtime due to faults, indirectly lowering operational costs and improving overall system operational efficiency. Moreover, during the development and deployment of containerized applications, the scale and complexity of applications may constantly change, new services may be added, and the dependencies between services may change. The container startup and health monitoring mechanism based on directed acyclic graphs and topology sorting in this invention offers excellent scalability and flexibility. When new services need to be added or service dependencies need to be modified, the system can automatically rebuild the directed acyclic graph and generate a new startup sequence simply by updating the container orchestration file, without having to make large-scale manual adjustments to the entire startup and monitoring process. This allows the system to better adapt to the dynamic changes of applications, making it easier for developers and operations personnel to extend and maintain containerized applications, and enhancing the scalability and flexibility of the system. Attached Figure Description

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

[0018] Figure 1 This is a schematic flowchart of an embodiment of the service scheduling method based on container startup order provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of the S400; Figure 3 For the present invention Figure 2 A schematic diagram of an embodiment of S420; Figure 4 For the present invention Figure 1 A flowchart illustrating another embodiment of the S400; Figure 5 For the present invention Figure 1 A schematic diagram of an embodiment of S300; Figure 6 This is a system architecture diagram of an automatic retry system for dependent services based on container startup order provided by an embodiment of the present invention; Figure 7 This is a timing diagram of the workflow of an automatic retry system for dependent services based on container startup order provided by an embodiment of the present invention; Figure 8 A schematic diagram of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0020] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] Before demonstrating the embodiments, the following terms will be explained.

[0024] A DAG (Directed Acyclic Graph) is a graph where every edge has a direction, indicating a path from one vertex to another. There are no cycles in the graph; that is, no path can start from a vertex, traverse several edges, and return to that vertex. A key property of DAGs is their topological sortability. A topological sort is a linear ordering such that for every directed edge u→v, vertex u always precedes vertex v. Because there are no cycles, paths in a DAG will not form closed loops, allowing many algorithms to run efficiently on DAGs without getting stuck in infinite loops. DAGs are often used to represent dependencies between tasks, where vertices represent tasks and edges represent the order of dependencies between tasks.

[0025] Kahn's algorithm is a topological sorting algorithm for directed acyclic graphs (DAGs). Topological sorting arranges all vertices in a DAG into a linear sequence such that for every directed edge u→v, vertex u precedes vertex v. The core idea of ​​Kahn's algorithm is to calculate the in-degree of each vertex (i.e., the number of edges pointing to that vertex), progressively finding vertices with an in-degree of 0 and removing them from the graph until all vertices are sorted.

[0026] This invention provides a service scheduling method, system, device, and medium based on container startup order, which are described below.

[0027] Figure 1 This is a schematic flowchart of an embodiment of the service scheduling method based on container startup order provided by the present invention, as shown below. Figure 1 As shown, the service scheduling method based on container startup order includes: S100. Parse the container orchestration file and construct a directed acyclic graph representing the dependencies between services.

[0028] It's important to note that the system is deployed in a containerized manner, injected into the target service container via the Sidecar pattern, or run as an independent DaemonSet on Kubernetes cluster nodes. Container orchestration files typically describe the configuration information of each container service in a specific format (such as Docker Compose files or Kubernetes YAML files), including service names, images, ports, environment variables, and dependencies. First, a parser program is written to parse the file content line by line, segment by segment, according to the syntax rules of this file format, extracting key information for each container service, paying particular attention to the dependency declaration tags between services. For example, by parsing the `depends_on` and `initContainers` tags in the Docker Compose or Kubernetes YAML files, a directed acyclic graph is constructed.

[0029] A Directed Acyclic Graph (DAG) is constructed using container services as nodes and dependencies between services as directed edges. A graph data structure is created where each node stores information about the container service (such as service name, configuration parameters, etc.). For dependencies explicitly specified in the configuration file, such as service A depending on service B, a directed edge is added from service B to service A. During the construction process, it is crucial to ensure that the graph is free of cycles, as the startup order of container services cannot have circular dependencies; otherwise, a reasonable startup order cannot be determined. Algorithms such as Depth-First Search (DFS) can be used to detect cycles during the construction process. If a cycle is found, the user is prompted to modify the orchestration file to eliminate the circular dependency, thus ensuring that the final constructed graph is a Directed Acyclic Graph (DAG).

[0030] S200. Based on the topological sorting algorithm, a starting sequence is generated according to the directed acyclic graph.

[0031] It's important to note that topological sorting is a sorting algorithm for directed acyclic graphs (DAGs). It arranges all nodes (i.e., container services) in the graph into a linear sequence, where for every edge (u, v), node u appears before node v. Common topological sorting algorithms include Kahn's algorithm and depth-first search (DFS). Kahn's algorithm is preferred here because it's better suited for large-scale graph structures and allows for easy recording of the in-degree information of each node during processing, facilitating subsequent operations. The steps of Kahn's algorithm are as follows: First, calculate the in-degree (i.e., the number of edges pointing to that node) of each node in the DAG. Then, add all nodes with an in-degree of 0 to a queue; these nodes are container services that do not depend on other services and can be started first. Next, remove a node from the queue and add it to the startup sequence. Iterate through all the adjacent nodes (i.e., the nodes it depends on), decrementing the in-degree of these adjacent nodes by 1. If the in-degree of an adjacent node becomes 0, add it to the queue. Repeat this process until the queue is empty. If the number of nodes in the startup sequence equals the total number of nodes in the graph, the topological sorting is successful, and a reasonable startup sequence for container services is obtained. Otherwise, it indicates that there is a cycle in the graph, which contradicts the acyclic assumption made when constructing the directed acyclic graph. The graph structure needs to be re-examined and corrected.

[0032] S300. Start the corresponding containers sequentially according to the startup sequence, and monitor the health status of each container in real time.

[0033] It's important to note that the startup sequence, generated according to the topology, executes startup operations for each container service sequentially. When starting a container, the API interface of the container runtime (such as Docker, Kubernetes, etc.) is invoked based on the container configuration information (e.g., image name, port mapping, environment variables) parsed from the orchestration file to create and start the container. For example, when using Docker, the container can be started using the `docker run` command with appropriate parameters; in a Kubernetes environment, a Pod can be created and started via API calls. After a container starts, its health status needs to be monitored in real time to ensure it functions correctly. The startup controller sends container startup commands to the container orchestration platform (such as the Kubernetes API Server) sequentially according to the startup sequence generated by the topology. The next container is only started after the current container passes its health check.

[0034] S400. When it is determined from the health status monitoring results that the container fails to start due to the dependent service, a retry operation is triggered according to the pre-configured retry policy.

[0035] It's important to note that when an abnormal health status is detected in a container, further analysis is needed to determine if the anomaly is due to the failure of dependent services to start. This can be done by checking the container's dependencies and the health status of those dependent services. For example, if container A depends on container B, and container A fails to start, and container B's health status is also abnormal, then it can be preliminarily determined that container A's startup failure is due to container B not starting properly. Furthermore, checking the container's log information can further confirm whether there are any error messages related to dependent services.

[0036] Retry policies for different scenarios should be predefined in the container orchestration file or through other configuration methods. Retry policies can include parameters such as the number of retries, the retry interval (the same interval for each retry), and retry conditions. For example, you can configure a maximum of 3 retries, with a 10-second interval between each retry, when a dependent service fails to start, causing the container to fail to start. Once it is determined that the container failed to start due to a dependent service, a retry operation is triggered according to the pre-configured retry policy. During the retry process, the dependent service is first attempted to be restarted. If the dependent service starts successfully and returns to a normal healthy state, the original container is restarted. If the dependent service still fails to start, the retry policy continues until the maximum number of retries is reached. If the dependent service eventually starts successfully during the retry process, and the original container also starts normally and remains healthy, the entire system returns to normal operation. If the number of retries is exhausted and the container still cannot start normally, further investigation is needed, such as notifying the administrator for manual intervention.

[0037] In summary, the service scheduling method based on container startup order provided in this invention first constructs a directed acyclic graph by parsing the container orchestration file and generates a startup sequence based on a topology sorting algorithm. This ensures that container services start in the correct dependency order, effectively avoiding problems caused by incorrect startup order and improving the deployment success rate and reliability of containerized applications. Furthermore, during container operation, various reasons may lead to abnormal container health states, such as dependent service failures, network problems, and insufficient resources. Real-time monitoring of container health status and handling it according to dependencies and retry policies helps improve system availability and stability. Real-time monitoring allows for timely detection of container health issues and identification of the root cause based on dependencies. When a dependent service startup failure causes a container abnormality, retrying according to a pre-configured retry policy increases the chance of successful container startup and reduces container downtime due to dependent service failures, thereby improving overall system availability. In addition, it can automatically handle some temporary faults to a certain extent, enhancing the system's self-healing capabilities and making the system more stable and reliable. Furthermore, based on container orchestration files and container startup and health monitoring mechanisms, operations personnel only need to correctly configure container orchestration files and retry policies. The system can then automatically complete a series of operations such as container startup, health monitoring, and fault retries, reducing manual intervention, lowering the workload and error probability of operations personnel, and significantly improving operational efficiency and reducing costs. Simultaneously, the improved system availability and stability reduce business downtime due to faults, indirectly lowering operational costs and improving overall system operational efficiency. Moreover, during the development and deployment of containerized applications, the scale and complexity of applications may constantly change, new services may be added, and the dependencies between services may change. The container startup and health monitoring mechanism based on directed acyclic graphs and topology sorting in this invention offers excellent scalability and flexibility. When new services need to be added or service dependencies need to be modified, the system can automatically rebuild the directed acyclic graph and generate a new startup sequence simply by updating the container orchestration file, without having to make large-scale manual adjustments to the entire startup and monitoring process. This allows the system to better adapt to the dynamic changes of applications, making it easier for developers and operations personnel to extend and maintain containerized applications, and enhancing the scalability and flexibility of the system.

[0038] In some embodiments of the present invention, such as Figure 2 As shown, step S400 includes: S410. Based on the health status monitoring results and the directed acyclic graph, determine the target dependency service that caused the startup failure; the target dependency service is the first dependency service in the dependency chain where the abnormal container is located whose health status is abnormal.

[0039] It should be noted that: A Directed Acyclic Graph (DAG) can be used to determine the dependency chain of each container, that is, the path from the current container to all its dependent services (i.e., the dependency chain). Based on health status monitoring results, abnormal containers that fail to start can be identified. In response to detecting container startup failure or unmet dependencies, dependency chain tracing analysis is performed using the DAG dependency model, tracing upstream along the dependency chain to locate the root cause node leading to the abnormal state. That is, starting from the abnormal container node, tracing upstream along the DAG dependency edges, checking the real-time health status of each upstream dependent node, and determining the first unhealthy root cause node as the target dependent service.

[0040] S420. When the timer reaches the initial retry duration, a restart command is sent to the target dependent service to perform a start retry operation on the target dependent service.

[0041] It should be noted that the initial retry duration is preset in the policy configuration center, for example, 2 seconds. A timer is started, beginning when an anomaly is detected in the target dependency service. When the timer reaches the initial retry duration, a restart operation is triggered. A restart command is sent to the target dependency service via a container orchestration tool (such as the Kubernetes API or the Docker Compose command). Upon receiving the restart command, the target dependency service executes the restart operation. The status of the target dependency service is updated to "Retrying". The number of retries is recorded for later determination of whether the maximum number of retries has been reached.

[0042] In this embodiment, by backtracking the dependency chain of a Directed Acyclic Graph (DAG), the first unhealthy dependent service causing the startup failure can be accurately located, instead of blindly retrying all dependent services. This avoids unnecessary retries on normally functioning dependent services, improving system efficiency and stability. Furthermore, when an anomaly is detected in a dependent service, the system can automatically trigger a retry operation instead of directly reporting an error or failure, improving the system's fault tolerance. Through precise fault location and retry mechanisms, cascading failures of the entire service chain due to the failure of a single dependent service are avoided. Furthermore, the retry interval is dynamically adjusted according to a preset retry strategy (such as an exponential backoff algorithm, where the retry interval increases exponentially), avoiding system resource contention and avalanche effects caused by high-frequency retries. The initial retry duration can be flexibly configured according to actual needs to adapt to differences in service startup time under different environments. Furthermore, the automatic retry mechanism can quickly restore the normal operation of dependent services, reducing service unavailability time and user waiting time caused by dependent service startup failures, thus improving user experience.

[0043] In some embodiments of the present invention, such as Figure 3 As shown, step S400 further includes: S421. Based on the dependency relationships of the directed acyclic graph, identify the set of downstream containers of the target dependent service.

[0044] It's important to note that: starting with the target dependent service, Depth-First Search (DFS) is used to traverse the Directed Acyclic Graph (DAG) to find all downstream containers that depend on that service. Alternatively, Browsing-First Search (BFS) can be used to find all downstream containers that depend on the target dependent service, layer by layer. The found downstream containers are then stored in a collection, such as `downstreamContainers`.

[0045] S422. During the retry period, the retry count of each container in the downstream container set remains unchanged.

[0046] It should be noted that during the retries of the target dependent service, the retry counts of each container in the downstream container set are frozen to prevent the retry counts of downstream containers from increasing due to retries of the target dependent service. During the retries, the state of the downstream containers is recorded to ensure they can recover to the correct state after the retry. Once the target dependent service successfully retryes, the retry counts of the downstream containers are unfrozen, allowing them to continue operating normally.

[0047] In this embodiment, by identifying the downstream container set and freezing the retry count, unnecessary retries by downstream containers due to retries of the target dependent service are avoided. This reduces the waste of system resources caused by frequent retries and improves the overall efficiency of the system. Furthermore, by freezing the retry count of downstream containers, cascading failures in the entire service chain caused by retries of a single dependent service are avoided, reducing the possibility of abnormal downstream container states due to retries of the target dependent service and improving system stability. Moreover, the retry count of downstream containers remains unchanged during retries of the target dependent service, allowing the system to dynamically adjust the retry strategy according to actual conditions. The retry strategy can be flexibly configured according to actual needs to adapt to differences in service startup time under different environments.

[0048] In some embodiments of the present invention, such as Figure 4 As shown, after step S420, the following steps are included: S430. Obtain the retry startup result of the target dependent service.

[0049] It should be noted that the status of the target dependent services is periodically polled using a predefined health check mechanism (such as HTTP health checks, TCP port checks, custom probes, etc.). The result of each retry is recorded, typically showing either "startup successful" or "startup failed". The retry result is then reported to the retry scheduler for further processing.

[0050] S440. Calculate the latest retry duration based on the initial retry duration and the retry start result; wherein, if the retry start result is a start failure, the latest retry duration increases exponentially.

[0051] It should be noted that the initial retry duration (initial retry interval) is set through the policy configuration center, for example, 2 seconds. If the retry attempt fails, the latest retry duration (i.e., the latest retry interval) is calculated based on the exponential backoff algorithm. The formula for calculating the latest retry duration is: Latest retry duration = Initial retry duration n Where n is the current number of retries. A maximum retry duration limit is set to prevent the retry duration from growing indefinitely. For example, the maximum retry duration is 60 seconds. To prevent resource contention and avalanche effects caused by multiple services retrying simultaneously, random latency jitter can be added to the latest retry duration. For example, the random jitter range is 10% of the latest retry duration, adding random latency to the fixed retry interval to avoid avalanche effects.

[0052] S450. After the timer reaches the latest retry duration, a restart command is sent to the target dependent service to perform a start retry operation on the target dependent service.

[0053] It's important to note that: A timer is started, beginning from the last failed retry attempt of the target dependency service. When the timer reaches the latest retry duration, a restart operation is triggered. A restart command is sent to the target dependency service via a container orchestration tool (such as the Kubernetes API or the DockerCompose command). The status of the target dependency service is updated to "Retrying" and the number of retries is recorded.

[0054] S460. Count the number of retries for the failed startup of the target dependent service, and stop the startup retry operation and trigger an alarm when the number of retries reaches the maximum threshold.

[0055] It should be noted that the following steps are required: Record the number of retries for each failed startup of the target dependent service. A preset maximum number of retries (i.e., the maximum threshold) is set, for example, 5 times. When the maximum threshold is reached, the retries are stopped. An alarm is triggered to notify operations personnel for manual intervention. Alarm methods can include email, SMS, and log recording. The target dependent service is marked as "failed," and the reason for the failure and context information are recorded.

[0056] In this embodiment, a health check mechanism precisely monitors the startup status of the target dependent services, ensuring the system can respond promptly to service startup failures. Retry startup results are reported to the retry scheduler in real time, providing a basis for subsequent retry strategy adjustments. Furthermore, an exponential backoff algorithm intelligently adjusts the retry interval to avoid system resource contention and avalanche effects caused by high-frequency retries. Dynamically adjusting the retry strategy based on retry startup results improves the system's adaptability and fault tolerance. Furthermore, automated processing of timers and restart commands reduces the need for manual intervention, increasing the system's automation level.

[0057] Furthermore, by setting a maximum retry threshold, infinite retries due to continuous failures of the target dependent service are avoided, reducing the waste of system resources. When the maximum retry count is reached, an alarm is triggered to promptly notify the operation and maintenance personnel for manual intervention, thereby improving the reliability of the system.

[0058] In some embodiments of the present invention, the step of generating the startup sequence based on the directed acyclic graph includes: Identify container groups in the directed acyclic graph that do not have dependencies, and perform parallel startup on the containers in the container groups.

[0059] It's important to note that for each node (container) in the DAG, its in-degree (the number of edges pointing to that node) is calculated. A node with an in-degree of 0 indicates that the container has no dependencies on other containers. All nodes with an in-degree of 0 are collected into a set; this set represents the group of containers without dependencies. The identified dependency-free container groups are stored in a list or set. Parallel processing techniques (such as multithreading, multiprocessing, or asynchronous programming) are used to start all containers in the dependency-free container group simultaneously. Container startup is controlled using container orchestration tools (such as the Kubernetes API or the Docker Compose command). During parallel startup, the startup status of each container is monitored in real time to ensure all containers start successfully. If a container in the group fails to start, the failure information is recorded, and a retry or alert is issued according to a pre-defined retry strategy.

[0060] In this embodiment, by identifying dependency-free container groups, the startup order of containers can be optimized, reducing unnecessary waiting time. Dependency-free containers can be started in parallel, significantly improving system startup efficiency and shortening overall deployment time. Furthermore, by starting dependency-free containers in parallel, the waiting time caused by serial startup is reduced, improving system response speed. Moreover, parallel startup makes full use of system resources, improving resource utilization and reducing resource idle time.

[0061] In some embodiments of the present invention, such as Figure 5As shown, monitoring the health status of each of the containers includes: S310. Check the process status of the container using a process liveness detection probe.

[0062] It's important to note that you should use system-level process management tools or custom scripts to periodically check the liveness status of critical processes within the container. Determine process liveness by checking if the process ID exists. Send signals (such as SIGUSR1) to the process and assess its liveness based on its response. Check the process's log files to confirm its proper functioning. Record the results, which typically fall into two categories: "process is alive" or "process does not exist." Update the container's health status based on the results.

[0063] S320. Detect the reachability of the service port corresponding to the container using a socket probe.

[0064] It's important to note that you should use network tools (such as telnet or nc) or a programming language's socket library (such as Python's socket module) to verify the reachability of the container's service port. Attempt to connect to the container's service port and check if a connection can be successfully established. Set a reasonable connection timeout to avoid long wait times. Record the test results, which are typically either "port reachable" or "port unreachable." Update the container's health status based on the test results.

[0065] S330. Detect the response status of the service port corresponding to the container using a health check probe.

[0066] It's important to note that the response status of the container's corresponding service port is checked using HTTP requests, TCP connections, or other custom protocols. An HTTP request is sent to the container's service port, and the returned status code is checked (e.g., 200 for success, 500 for internal error). Depending on the service's specific protocol, a specific request is sent and the response is checked. The results are recorded, typically including the response status code and response time. The container's health status is then updated based on the results.

[0067] S340. Determine the health status of the container based on the detection results. The health status includes container ready status, container startup failure status, and dependency unmet status.

[0068] It should be noted that the health status of a container is comprehensively determined by combining the results of process liveness detection, port reachability, and response status checks. Health status categories include container ready, container startup failed, and dependency unmet needs. The final health status is updated in the container's status record, and subsequent operations (such as retries and alerts) are triggered as needed.

[0069] In this embodiment, process liveness detection probes are used to check the process status of the container, enabling precise monitoring of the liveness of critical processes within the container, timely detection of process anomalies, and rapid response in case of anomalies. This reduces service downtime, avoids resource waste caused by process anomalies, and improves system resource utilization. Furthermore, socket probes are used to check the reachability of the service ports corresponding to the container, ensuring normal network connectivity, quickly identifying network problems, facilitating troubleshooting and repair, and ensuring service port reachability, thus improving system reliability. Furthermore, health check probes are used to check the response status of the service ports corresponding to the container, ensuring normal service operation. Service performance is monitored through metrics such as response time, enabling timely detection of performance issues, ensuring normal service response, and improving user experience. Furthermore, combining multiple detection results comprehensively assesses the health status of the container, improving the accuracy of judgments. Subsequent operations (such as retries and alarms) are automatically triggered based on the health status, reducing manual intervention and improving operational efficiency.

[0070] In some embodiments of the present invention, step S340 includes: When the container's process is running normally, the service port is reachable, the response status is successful, and all the dependent services are ready, the health status is determined to be the container's ready state. When the container's process is running normally, the service port is reachable, and the response status is successful, but there are dependent services that are not ready, the health status is determined to be a dependent unmet status. When the container's process runs abnormally, the service port is unreachable, or the response status is failure, the health status is determined to be the container startup failure status.

[0071] It should be noted that: process liveness detection probes (such as checking the existence of process IDs, sending signals, etc.) are used to confirm that the processes within the container are running normally. Socket probes (such as socket connections) are used to confirm that the container's service ports are reachable. Health check probes (such as sending HTTP requests) are used to confirm that the service's response status is successful (such as HTTP status code 200). A directed acyclic graph (DAG) is used to identify all dependent services of the container and to check the health status of these dependent services.

[0072] First, confirm that the processes within the container are running normally, that the container's service ports are reachable, and that the service response status is successful. Then, use the Directed Acyclic Graph (DAG) to identify all dependent services of the container and check their health status. If any dependent service is not ready, the container's health status is set to "Dependency Unmet". Next, confirm that the processes within the container are running abnormally (e.g., process ID not existing, abnormal process response), that the container's service ports are unreachable (e.g., connection failure, timeout), and that the service response status is failed (e.g., HTTP status code 500, timeout). If any of these conditions are not met, the container's health status is set to "Container Startup Failed".

[0073] In this embodiment, the container health check mechanism that integrates multiple detection methods has significant advantages in terms of accurate monitoring, rapid response and automated processing, which can significantly improve the reliability and operational efficiency of containerized applications.

[0074] To better implement the service scheduling method based on container startup order in this invention embodiment, based on the service scheduling method based on container startup order, the corresponding method is as follows: Figure 6 As shown, this embodiment of the invention also provides a service scheduling system 600 based on container startup order, the service scheduling system 600 based on container startup order includes: The dependency analysis module 601 is used to parse the container orchestration file, construct a directed acyclic graph representing the dependencies between services, and generate a startup sequence based on the directed acyclic graph using a topology sorting algorithm. The health monitoring module 602 is used to sequentially start the corresponding containers according to the startup sequence and monitor the health status of each container in real time. The retry scheduler 603 is used to trigger a retry operation according to a pre-configured retry policy when it is determined from the health status monitoring results that the container fails to start due to the dependent service.

[0075] The service scheduling system 600 based on container startup order provided in the above embodiments can implement the technical solutions described in the above service scheduling method embodiments based on container startup order. The specific implementation principles of each module or unit can be found in the corresponding content in the above service scheduling method embodiments based on container startup order, and will not be repeated here.

[0076] For example, Figure 7 A sequence diagram of the workflow for an automated retry system for dependent services. (Example:) Figure 6 and Figure 7As shown, the detailed service scheduling process based on container startup order is as follows: The dependency analysis module scans service declarations (such as Docker Compose files) within the container cluster and identifies service dependency chains (such as database container → API service container → front-end web container). Finally, a structured DAG is generated and passed to the retry scheduler to determine the startup order, startup priority, and retry path of each container. The dependency analysis module is only responsible for identifying and modeling dependencies, while the retry scheduler is the main entity responsible for executing priority control and retry strategies. The health monitoring module polls the container status in real time (HTTP health check / PID liveness detection) and reports the following events: container ready (Container_Ready), container startup failed (Container_Failed), and dependency unmet (Dependency_Unmet).

[0077] The strategy configuration center configures retry parameters, such as the maximum number of retries (e.g., 5 times), retry interval (exponential backoff strategy), and timeout threshold (e.g., database container startup timeout of 120 seconds).

[0078] The retry scheduler performs tiered processing based on the DAG and health status (i.e., container status). Upon initial startup, containers are started in the order of the DAG topology (database container first → API service container → frontend web container). If the API service container fails to start, the database connection pool is reset according to a policy (i.e., the retry scheduler identifies the corresponding database container that needs to be reset by parsing the dependencies in the DAG and then restarts it); the API service container is restarted after a 10-second delay; when the cumulative number of failures exceeds a threshold, the DAG is marked as "unrecoverable" and an alarm is triggered.

[0079] The retry scheduler has fault tolerance and recovery mechanisms. On one hand, it relies on cascading processing: when the front-end web container fails to start due to the API service container's failure, the scheduler automatically freezes the API service container's retry count until the API service container recovers (i.e., the API service container itself has a container state; a startup failure will result in a retry count. If the front-end web container fails to start due to the API service container's failure, it will trigger another retry, increasing the API service container's retry count; therefore, freezing the API service container's retry count is necessary). On the other hand, it performs atomic rollback: if consecutive retries fail, it releases the resources of already started dependent containers (such as closing useless database connections). Specifically, the database container needs to be initialized and started first. The API service container needs to wait for the database container to fully start before starting. The front-end web container waits for the S106 API service container to fully start before starting.

[0080] When the database container returns an HTTP 500 error (internal server error) upon startup, it indicates that the database container startup has failed (initial error). A failure notification, including the error code and timestamp, is proactively sent to the retry scheduler. Standardized error codes enable rapid fault identification. After a database container startup failure, an initial retry is performed (delayed by 2 seconds), the failure event is recorded, and a 2-second delay timer (exponential backoff initial value) is started. After the timer expires, a restart command is sent to the database container. The fault tolerance logic uses short delays to avoid frequent retries caused by momentary failures (such as resource contention). The retry delay time increases exponentially (e.g., 2s→4s→8s→16s) until the maximum number of retries or a threshold time is reached. This design effectively avoids system resource contention or avalanche effects caused by high-frequency retries by gradually increasing the retry interval. If the database container fails to start again, a second retry is performed (delayed by 4 seconds). If the first retry also returns a 500 error, the delay time is doubled to 4 seconds. Before the second retry, system resource utilization (e.g., CPU / memory) is checked to avoid resource exhaustion scenarios. The design adheres to the backoff algorithm principles of the TCP / IP protocol and is compatible with containerized environments. Upon successful startup of the database container, an HTTP 200 status code is returned, the service status is updated to "healthy," and the retry counter is cleared. Then, a startup authorization signal is sent to the API service container. Upon detecting the authorization signal, the API service container begins its startup process and removes dependencies. If the authorization signal times out, a circuit breaker mechanism is triggered to terminate the startup and issue an alert.

[0081] The maximum number of retries is typically configured with a threshold (e.g., 5 times). Exceeding this limit triggers an alarm and switches to a standby instance. For example, if an API service is deployed in a cluster, with the primary instance API01 (currently actively processing requests) and the standby instance API02 (in a standby state, configured the same as the primary instance), and API01 is marked as unavailable, API02 becomes the new primary instance. Retry events are collected uniformly across container logs for easier root cause analysis later.

[0082] During the initialization phase, the system transitions from the container's initial state to the initialization state. After initialization, the container configuration is loaded, and the readiness status of all dependent services (such as databases and message queues) is scanned. If all dependent services are ready, the system directly transitions to the running state. If any dependent services are not ready, the system switches to the waiting dependency state and triggers an automatic retry operation, i.e., it starts a timed polling mechanism (e.g., every 10 seconds) to continuously monitor the health status of the not-ready dependent services. When the polling detects that a dependent service is still unavailable, the system automatically triggers the retry state. Note that the system does not immediately retry upon first entering the waiting dependency state; a delay threshold must be configured. The retry strategy adopted in this application uses an exponential backoff algorithm (e.g., a 2-second wait initially, doubling the time for each subsequent retry). A maximum number of retries (e.g., 5 times) is pre-configured, and a counter is updated after each retry to count the number of retries. If the dependent service recovers to the ready state after a retry, it enters the running state, and the container executes its business logic normally until the task is completed or the system actively terminates (e.g., the old version of the container is actively recycled during a container rolling update). After completing the task, the container returns to its initial state, awaiting the next scheduling. If the system fails to return to a ready state after a retry and still fails after reaching the maximum number of retries, it will transition to a failed state, triggering system-level alerts (such as email or SMS notifications) and recording error logs (such as dependent service types and failure timestamps). Subsequent manual intervention can be initiated; after investigation, the system can be manually reset to the container's initial state. This invention uses a service registry (such as Consul) to collect dependencies between containers in real time, generating a directed acyclic graph (DAG) and dynamically updating service startup priorities. An exponential backoff algorithm combined with service health status detection is used to dynamically adjust the retry interval. A circuit breaker mechanism is introduced to automatically trigger a degradation strategy when dependent services remain unavailable. A topology sorting algorithm is used to dynamically orchestrate the container startup sequence, supporting the parallel startup of container groups without dependencies and shortening the overall deployment time.

[0083] like Figure 8 As shown, the present invention also provides an electronic device 800. The electronic device 800 includes a processor 801, a memory 802, and a display 803. Figure 8 Only some components of the electronic device 800 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0084] In some embodiments, processor 801 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 802 or process data, such as the service scheduling method based on container startup order in this invention.

[0085] In some embodiments, processor 801 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 801 may be local or remote. In some embodiments, processor 801 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, intranet, multi-cloud, etc., or any combination thereof.

[0086] In some embodiments, memory 802 may be an internal storage unit of electronic device 800, such as a hard disk or memory of electronic device 800. In other embodiments, memory 802 may also be an external storage device of electronic device 800, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 800.

[0087] Furthermore, the memory 802 may include both internal storage units of the electronic device 800 and external storage devices. The memory 802 is used to store application software and various types of data installed on the electronic device 800.

[0088] In some embodiments, display 803 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 803 is used to display information from electronic device 800 and to display a visual user interface. Components 801-803 of electronic device 800 communicate with each other via a system bus.

[0089] In one embodiment, when processor 801 executes a service scheduler based on container startup order in memory 802, the following steps may be implemented: Parse the container orchestration file and construct a directed acyclic graph representing the dependencies between services; Based on the topological sorting algorithm, a starting sequence is generated according to the directed acyclic graph; The corresponding containers are started sequentially according to the startup sequence, and the health status of each container is monitored in real time. When it is determined from the health status monitoring results that the container fails to start due to the dependent service, a retry operation is triggered according to the pre-configured retry policy.

[0090] It should be understood that when the processor 801 executes the service scheduler based on container startup order in the memory 802, in addition to the functions mentioned above, it can also perform other functions, as detailed in the description of the corresponding method embodiments above.

[0091] Furthermore, this embodiment of the invention does not specifically limit the type of electronic device 800 mentioned. Electronic device 800 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the invention, electronic device 800 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0092] Accordingly, this application also provides a computer-readable storage medium for storing computer-readable programs or instructions. When the programs or instructions are executed by a processor, they can implement the steps or functions of the service scheduling method based on container startup order provided in the above-described method embodiments.

[0093] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0094] The above provides a detailed description of the service scheduling method, system, device, and medium based on container startup order provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A service scheduling method based on container startup order, characterized in that, include: Parse the container orchestration file and construct a directed acyclic graph representing the dependencies between services; Based on the topological sorting algorithm, a starting sequence is generated according to the directed acyclic graph; The corresponding containers are started sequentially according to the startup sequence, and the health status of each container is monitored in real time. When it is determined from the health status monitoring results that the container fails to start due to the dependent service, a retry operation is triggered according to the pre-configured retry policy.

2. The service scheduling method based on container startup order according to claim 1, characterized in that, When it is determined from the health status monitoring results that the container fails to start due to the dependent service, a retry operation is triggered according to the pre-configured retry policy, including: Based on the health status monitoring results and the directed acyclic graph, the target dependency service that caused the startup failure is determined; the target dependency service is the first dependency service in the dependency chain where the abnormal container is located whose health status is abnormal; When the timer reaches the initial retry duration, a restart command is sent to the target dependent service to perform a start retry operation on the target dependent service.

3. The service scheduling method based on container startup order according to claim 2, characterized in that, Also includes: Based on the dependency relationships of the directed acyclic graph, the set of downstream containers of the target dependent service is identified; The retry count for each container in the downstream container set remains unchanged during the retry period.

4. The service scheduling method based on container startup order according to claim 2, characterized in that, When the timer reaches the initial retry duration, after sending a restart command to the target dependent service to perform a start retry operation on the target dependent service, the process includes: Obtain the retry startup result of the target dependent service; The latest retry duration is calculated based on the initial retry duration and the retry start result; wherein, if the retry start result is a start failure, the latest retry duration increases exponentially. After the timer reaches the latest retry duration, a restart command is sent to the target dependent service to perform a start retry operation on the target dependent service; The number of retries for the failed startup of the target dependent service is counted, and when the number of retries reaches the maximum threshold, the startup retry operation is stopped and an alarm is triggered.

5. The service scheduling method based on container startup order according to claim 4, characterized in that, The step of generating a startup sequence based on the directed acyclic graph, followed by: Identify container groups in the directed acyclic graph that do not have dependencies, and perform parallel startup on the containers in the container groups.

6. The service scheduling method based on container startup order according to claim 1, characterized in that, The monitoring of the health status of each of the containers includes: The process status of the container is checked using a process liveness detection probe; The reachability of the service port corresponding to the container is detected by a socket probe. The response status of the service port corresponding to the container is detected by a health check probe; The health status of the container is determined based on the detection results. The health status includes container ready status, container startup failure status, and dependency unmet status.

7. The service scheduling method based on container startup order according to claim 6, characterized in that, The classification of detection results into health status events such as container ready, container startup failure, and unmet dependencies includes: When the container's process is running normally, the service port is reachable, the response status is successful, and all the dependent services are ready, the health status is determined to be the container's ready state. When the container's process is running normally, the service port is reachable, and the response status is successful, but there are dependent services that are not ready, the health status is determined to be a dependent unmet status. When the container's process runs abnormally, the service port is unreachable, or the response status is failure, the health status is determined to be the container startup failure status.

8. A service scheduling system based on container startup order, characterized in that, include: The dependency analysis module is used to parse container orchestration files, construct a directed acyclic graph representing the dependencies between services, and generate a startup sequence based on the directed acyclic graph using a topology sorting algorithm. A health monitoring module is used to sequentially start the corresponding containers according to the startup sequence and monitor the health status of each container in real time. A retry scheduler is used to trigger a retry operation according to a pre-configured retry policy when it is determined from the health status monitoring results that the container has failed to start due to the dependent service.

9. An electronic device, characterized in that, Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the service scheduling method based on container startup order as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer-readable programs or instructions, which, when executed by a processor, can implement the steps in the service scheduling method based on container startup order as described in any one of claims 1 to 7.

Images