Multi-module system starting method, device, equipment, storage medium and program product

Abstract

This invention discloses a method, apparatus, device, storage medium, and program product for starting a multi-module system. The modules in the multi-module system have startup dependencies. The startup method includes: responding to a startup command and, based on a topological startup order according to the startup dependencies, sequentially controlling the startup of each module in the multi-module system; for each currently triggered module, collecting at least two state signals of the current module; determining the readiness of the current module based on the at least two state signals; and, if the current module is determined to be ready, allowing subsequent modules of the current module to start based on the topological startup order. This invention improves the accuracy, stability, and controllability of the multi-module system startup process by introducing a topology-dependent startup control mechanism, a multi-dimensional state signal acquisition mechanism, and a stability-constrained readiness determination mechanism to accurately perceive the true readiness state of modules and release them during the execution phase based on this perception.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a multi-module system startup method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the rapid development of industrial software, microservice architecture, and edge computing systems, multi-module collaborative operation has become a common pattern for building complex application systems. Multi-module systems typically consist of multiple interconnected functional modules, with clear startup dependencies between them. To ensure correct system operation, the modules need to be started sequentially according to a pre-defined startup dependency order.

[0003] In existing technologies, the startup control of multi-module systems typically employs a scripted startup method based on a fixed sequence. Maintenance personnel or automated scripts start each module sequentially according to a pre-set order, controlling the startup interval between modules by setting fixed waiting times. While this method is simple to implement, it has significant drawbacks in practical applications.

[0004] On the one hand, different hardware environments, system loads, and operating states can lead to significant differences in module startup times, making it difficult to accurately reflect the actual startup status of a module with a fixed waiting time. When the waiting time is set too long, it will cause unnecessary startup delays and reduce the overall system startup efficiency; when the waiting time is set too short, the preceding modules may not have completed initialization before entering the subsequent startup process.

[0005] On the other hand, if a module process has started but the business functions are not yet ready, the premature start of a subsequent module can easily lead to problems such as connection failure, service abnormalities, or system instability.

[0006] Therefore, improving the accuracy and stability of multi-module system startup has become a pressing technical problem that needs to be solved in this field.

[0007] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0008] In view of the problems in the prior art, the purpose of this invention is to provide a method, apparatus, device, storage medium and program product for starting a multi-module system, to overcome the difficulties of related technologies, and to solve the technical problems of poor accuracy and stability in the current multi-module system startup.

[0009] The first aspect of this disclosure provides a method for starting a multi-module system, wherein the modules in the multi-module system have startup dependencies. The method for starting a multi-module system includes: In response to the startup command, based on the topological startup order of startup dependencies, the system sequentially controls the startup of each module in the multi-module system. For each currently triggered module, at least two status signals of the current module are collected; The readiness of the current module is determined based on at least two state signals; If the current module is determined to be ready, the subsequent modules of the current module are allowed to start based on the topology startup order.

[0010] In some implementations, the multi-module system startup method further includes: If the current module is determined to be not ready, stop operations are performed on the started modules in the reverse topological order of the startup dependencies.

[0011] In some implementations, the current module is determined to be not ready, including: If the current module is not determined to be ready within the second preset time interval, or if the current module is detected to be in an abnormal state.

[0012] In some implementations, performing a stop operation on a started module includes at least one of the following: Stop the running process of the started module; Release the port resources occupied by the started modules; Clean up temporary state files generated during the operation of started modules.

[0013] In some implementations, the multi-module system startup method further includes: Before stopping the running process of a started module, send a graceful stop command to the started module, and stop the running process of the started module if the graceful stop times out.

[0014] In some implementations, the multi-module system startup method further includes: After stopping the started module, the startup command is regenerated according to the preset retry strategy, and the startup command is executed back to respond. Based on the startup dependency topology startup order, the startup control of each module in the multi-module system is performed in sequence.

[0015] In some implementations, the following consistency check is performed before regenerating the startup command according to a preset retry policy: The process corresponding to the started module has exited and the corresponding port has been released; If the consistency check passes, the startup command will be regenerated according to the preset retry strategy.

[0016] In some implementations, the method further includes: If the consistency check fails, the execution will be terminated, the startup command will be regenerated according to the preset retry strategy, and a startup exception report will be output.

[0017] In some implementations, startup dependencies are stored as a directed graph; the reverse topological order is generated by performing edge reversal or reverse traversal on the directed graph.

[0018] In some implementations, a stop operation is performed on the started modules in the reverse topological order of the startup dependencies, specifically including: Based on the directed graph, modules that are not ready and have at least one level of dependency relationship with the current module are identified and judged as candidate stopping objects; Modules that are candidates for stopping are selected from the started modules to form a set of modules to be stopped; Perform stop operations on the set of modules to be stopped in reverse topological order.

[0019] In some implementations, the readiness of the current module is determined based on at least two state signals, including: A comprehensive index is obtained by weighting at least two state signals. When the comprehensive indicators meet the preset threshold, the current module is determined to be ready.

[0020] In some implementations, satisfying a preset threshold includes: The comprehensive index shall not be lower than the preset threshold within the first preset time interval.

[0021] In some implementations, the preset threshold and the first preset time interval are determined based on the topological hierarchy of the current module in the startup dependency relationship; Among them, the module that is in the preceding position in the topology startup sequence has a preset threshold that is higher than the preset threshold of its successor module, and its first preset time interval is longer than the first preset time interval of its successor module.

[0022] In some implementations, determining the readiness of the current module based on at least two state signals further includes: Within the first preset time interval, the acquired status signals are smoothed using a sliding window method, and in each sliding window, the current module is judged to be ready based on at least two status signals. Count the number of sliding windows that meet the preset threshold within the first preset time interval; If the proportion of the number of sliding windows that meet the preset threshold to the total number of sliding windows exceeds the preset percentage, then the current module is determined to be in a ready state.

[0023] In some implementations, at least two status signals include at least two of the following: process status signals, port connectivity status signals, and service health status signals.

[0024] In some implementations, the service health status signal is obtained by executing a preset service probe, which includes at least one of the following: Database connection test; Heartbeat command executed; Metadata loading status verification; Cluster node registration status query.

[0025] In some implementations, the multi-module system startup method is applied to an orchestration service, where the modules in the multi-module system are distributed across different physical nodes. The orchestration service, through remote communication with the physical nodes, sequentially controls the startup of each module in the multi-module system and collects at least two status signals of the current module.

[0026] In some implementations, a multi-module system includes a database module and a business interface module; In the process of executing the startup control of the database module, the database module is the current module, and the business interface module is the corresponding successor module.

[0027] In some implementations, the database module includes a management node module and a data node module with startup dependencies; the startup control of the database module specifically includes: The management node module is used as a sub-startup unit to perform startup control, and when the management node module is determined to be ready, the startup control of the data node module, which is the sub-successor unit of the sub-startup unit, is triggered. If the data node module is determined to be ready, the database module is determined to be ready, triggering the release of the business interface module as the subsequent module.

[0028] In some implementations, startup dependencies are stored in the form of a directed graph; the topology startup order is determined by performing a topology sorting algorithm on the directed graph.

[0029] In some implementations, the successor module to the current module is started based on the topology startup order, including: If multiple successor modules that depend on the current module are detected, startup control will be executed sequentially according to the preset resource scheduling strategy.

[0030] In some implementations, allowing subsequent modules of the current module to run based on the topology startup order includes: If the current module is determined to be ready, and it is identified based on the topology startup order that the subsequent module depends on multiple preceding dependent modules, then the subsequent module will be allowed to proceed if all the preceding dependent modules are determined to be ready.

[0031] The second aspect of this disclosure provides a multi-module system startup device, wherein the modules in the multi-module system have startup dependencies, and the multi-module system startup device includes: The startup unit responds to startup commands and, based on the startup dependency topology startup sequence, sequentially controls the startup of each module in the multi-module system. The status acquisition unit acquires at least two status signals for each currently triggered module. The readiness determination unit determines the readiness of the current module based on at least two state signals; The release unit, when the current module is determined to be ready, releases the subsequent modules of the current module based on the topology startup order.

[0032] A third aspect of this disclosure provides an electronic device comprising: Processor; and Memory, which stores the processor's executable instructions; The processor is configured to execute the multi-module system startup method of any of the above embodiments by executing executable instructions.

[0033] The fourth aspect of this disclosure provides a computer-readable storage medium for storing a program that, when executed, implements a multi-module system startup method according to any of the above embodiments.

[0034] The fifth aspect of this disclosure provides a computer program product having a computer program stored thereon, wherein the computer program, when executed, implements the multi-module system startup method of any of the above embodiments.

[0035] The multi-module system startup method, apparatus, device, storage medium, and program product proposed in this disclosure have the following advantages: By introducing a startup control mechanism based on topology dependency, a multi-dimensional state signal acquisition mechanism, and a readiness determination mechanism based on stability constraints, the system can accurately perceive the true readiness state of modules and control the execution phase release and abnormal rollback based on this, thereby improving the accuracy, stability, and controllability of the startup process of multi-module systems.

[0036] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0037] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0038] Figure 1 This is a flowchart illustrating the multi-module system startup method provided in this embodiment. Figure 2 This is a schematic diagram of the logical structure of the startup dependency relationship between multiple modules provided in the embodiments of this disclosure; Figure 3 This is a flowchart illustrating another multi-module system startup method provided in this disclosure. Figure 4 This is an example diagram of a multi-module system architecture provided by this disclosure, illustrating the dependency relationship between the database module and the business interface module; Figure 5 This is an example diagram of another multi-module system architecture including composite modules provided by the embodiments of this disclosure, which details the node composition inside the database module; Figure 6 This disclosure provides an embodiment for... Figure 5 The flowchart of the specific startup control logic of the architecture shown is as follows; Figure 7 This is a schematic diagram of the reverse topology sequence stop operation process provided in the embodiments of this disclosure under abnormal startup conditions; Figure 8 This is a schematic diagram of the first modular structure of the multi-module system startup device provided in this embodiment; Figure 9 This is a schematic diagram of the second modular structure of the multi-module system startup device provided in this embodiment, which adds an exception handling unit; Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0039] To make the technical solution, the technical problem solved, and the technical effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the described embodiments are merely exemplary embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art can make various modifications and variations to the embodiments without departing from the spirit and scope of the present invention, and all such modifications and variations should be considered to fall within the scope of protection of the present invention.

[0040] Techniques, methods, and apparatus known to those skilled in the art are not discussed in detail where appropriate, but should be considered part of this specification. In all examples shown herein, any specific numerical values ​​or parameters should be interpreted as exemplary only and not as limiting the invention.

[0041] Existing multi-module system startup schemes typically lack an effective mechanism for determining the true readiness status of modules, and cannot distinguish between modules that have been started and those that are already usable.

[0042] This disclosure provides an improved multi-module system startup method. The key technical idea is to construct a startup control closed loop based on multi-dimensional state signal acquisition and readiness determination. This method performs topological modeling of the startup dependencies between modules, executes startup control according to the topological startup sequence, and introduces multi-dimensional state signal combination readiness determination logic. This achieves accurate perception of the true readiness state of the modules, thereby solving the technical problems of poor accuracy and stability in current multi-module system startup.

[0043] Figure 1 This diagram illustrates a flowchart of a multi-module system startup method provided in this embodiment. The execution entity of this multi-module system startup method can be a startup control device for the multi-module system, an orchestration service node, a server, or a terminal device with program execution capabilities, such as an industrial software deployment server, a cloud platform node, or an edge computing device.

[0044] When implemented as a software program, this method can be deployed on an operating system or run as a standalone service.

[0045] This multi-module system startup method is applicable to multi-module systems with startup dependencies. A multi-module system refers to a system as a whole composed of multiple interrelated modules, which form a collaborative relationship through data interaction, service calls, or functional dependencies.

[0046] In this context, a module can refer to a logical entity managed as an independent scheduling unit during the startup control process. It can be a single service component, such as a database service, a business interface service, or a computing service. A module can also be a composite module composed of multiple sub-modules. Startup dependencies refer to the pre- and post-startup constraints between modules during the startup process; that is, the startup of one module depends on the completion of startup of another module.

[0047] For example, a multi-module system can be a combination system of database module and business interface module, a microservice system, a distributed computing system, or an industrial control software system, etc.

[0048] It should be noted that each step described in the following embodiments can be executed by one or more processors and can be implemented by computer program instructions. The order of each step can be adjusted or partially executed in parallel without affecting the overall technical effect.

[0049] like Figure 1 As shown, the multi-module system startup method provided in this disclosure includes, but is not limited to, the following steps: Step 110: Respond to the startup command and, based on the startup dependency relationship and topology startup order, sequentially control the startup of each module in the multi-module system; Step 120: For each currently triggered module, collect at least two status signals of the current module; Step 130: Determine the readiness of the current module based on at least two state signals; Step 140: If the current module is determined to be ready, allow the subsequent modules of the current module to start based on the topology startup order.

[0050] The multi-module system startup method of this disclosure determines the topology startup order through preset startup dependencies, ensuring that the multi-module system can be started in a controlled manner according to a predefined logical sequence, and avoiding call failures or system crashes caused by disordered module startup.

[0051] Compared to existing technologies that only monitor process liveness, this solution can effectively distinguish between the "started" and "ready" states of a module by collecting at least two types of status signals, which helps to reduce the problem of inaccurate readiness determination caused by module internal initialization delays.

[0052] Subsequently, by introducing a readiness determination step after each current module starts, and using this as a necessary condition to trigger the release (startup) of subsequent modules, a closed-loop startup control logic is constructed, making the startup of subsequent modules dependent on the actual available state of the preceding modules, thereby reducing the probability of subsequent modules failing to start or running abnormally.

[0053] Through the above steps, the present invention can ensure that the multi-module system starts up in an orderly manner according to the startup dependency relationship, the module startup process has state-driven characteristics, and the phased release is based on the actual ready state of the module, thereby improving the accuracy and stability of the multi-module system startup process.

[0054] In some implementations, in step 110 above, the start command is used to trigger the control signal that initiates the multi-module system startup.

[0055] In one implementation scenario, operations and maintenance personnel trigger the "start cluster" operation in the management interface, and the front end sends an API request to the orchestration service, which is the start command.

[0056] In another implementation scenario, third-party automated operation and maintenance platforms (such as Ansible and KubernetesOperator) issue startup tasks through RESTful interfaces.

[0057] In some implementations, the generation of the startup command also includes an internal automatic triggering mode. Specifically, the operating status of the multi-module system is continuously monitored. When the current operating status is found to be inconsistent with the preset topology baseline status (e.g., a missing module process, abnormal port occupancy, or a change in the physical environment is detected), the strategy engine inside the execution entity automatically generates a compensatory startup command and re-executes the aforementioned startup control closed loop.

[0058] In this way, through an internal automatic triggering mechanism, the multi-module system has the ability to self-heal at runtime, and can automatically recover to a consistent state without human intervention, thereby improving the availability of the multi-module system in complex industrial environments.

[0059] In some implementations, upon receiving a startup command, the startup dependencies of the multi-module system are first obtained. These dependencies can be derived from pre-configured files, system deployment information, or runtime dynamically resolved results.

[0060] For example, startup dependencies are stored in the form of a directed dependency graph. Figure 2 As shown, the directed dependency graph consists of multiple vertices (representing modules) and directed edges (representing startup dependencies). For example, the multi-module system includes module A, module B, and module C. Module A is a vertex, and a directed edge from module A to module B indicates that module B's startup depends on module A. Similarly, module C's startup depends on module B.

[0061] After responding to the start command, the topology sorting algorithm is invoked to parse the directed dependency graph and obtain the topology start order. In specific implementations, the Kahn algorithm based on in-degree calculation or the depth-first search (DFS) algorithm can be used.

[0062] In one implementation, the Kahn algorithm based on in-degree calculation is used to parse directed dependency graphs, including: First, calculate the in-degree of each node in the directed graph. The in-degree represents the number of dependent edges pointing to the module. Select the node with an in-degree of zero as the initial startup module and add it to the startup sequence. The simulation removes the initial startup module from the directed graph and updates the in-degree of its successor modules. This process is repeated until a topological startup order that satisfies the dependency constraints is obtained.

[0063] In another implementation, a topology startup order is generated by recursively traversing the dependency paths based on a depth-first search algorithm.

[0064] It should be noted that the topology startup order obtained by performing a topology sorting algorithm on the directed graph can ensure that any module other than the initial startup module is started after all its preceding dependent modules, thus strictly satisfying the constraints of startup dependencies.

[0065] Meanwhile, assuming there are no cycles in the directed graph, the topology sorting result is a valid topology startup order. If a cycle is detected in the directed graph, the module dependency configuration is determined to be abnormal, the current startup process is terminated, and an error message or exception report is output.

[0066] This implementation method can detect invalid circular dependencies early by performing loop detection during the dependency modeling stage, thus preventing the subsequent startup process from entering an unrecoverable state and further improving the system's configuration reliability and startup security.

[0067] In some implementations, the topology sorting result can be represented as a hierarchical structure, where there are no dependencies between modules in the same level, thus allowing startup control to be executed in parallel when resources permit; in other implementations, the topology sorting result can also be converted into a linear sequence to perform serial startup.

[0068] By using the above method, the startup dependencies are structured into a directed graph and the startup order is determined by topological sorting. This gives the module startup process a clear computational basis and an executable path, providing a unified data foundation and order guarantee for subsequent readiness determination and startup control based on state signals.

[0069] After obtaining the topology startup order, startup control is performed on each module sequentially according to this order. Once the startup control of any module is completed, it is marked as started and set as the current module. The startup control includes performing startup operations one by one, starting with the initial module without any prerequisites, including creating running processes, loading module configurations, and initializing the runtime environment.

[0070] It should be noted that the "started" status only indicates that the current module process has been successfully started, and does not mean that the current module has reached a ready state that subsequent modules can depend on.

[0071] After obtaining the topology startup order, startup control is performed on each module sequentially according to this order. Once any module completes startup control, it is marked as started and set as the current module. It should be noted that the started state only indicates that the process has been launched, and does not mean that the module has reached a truly usable state. Then, the process proceeds to the status acquisition stage in step 120 and the readiness determination stage in step 130.

[0072] In some implementations, at least two status signals represent a set of data representing the current module running status, which may include at least two of process status signals, port connectivity status signals, and service health status signals.

[0073] Among them, the process status signal refers to the signal that reflects whether the current module's running process exists and its running status; the port connectivity status signal refers to the signal that reflects whether the current module's external service port can establish a communication connection; and the business health status signal refers to the deep perception signal that reflects whether the current module has basic service capabilities at the business level.

[0074] In some implementations, the status signals may also include hardware resource readiness signals, distributed consensus status signals, or configuration consistency verification signals, as optional enhancement dimensions.

[0075] In some implementations, the status signal also includes a hardware resource readiness signal, used to characterize the resource status of the physical or virtual environment in which the current module resides, including disk mount status, available memory percentage, I / O load, and specific hardware license identifier. This signal can be used to ensure that the current module is determined to be ready, provided that it has sufficient physical performance support.

[0076] In some implementations, the status signals also include distributed consensus status signals, used to collect the role status, log synchronization progress, and replica liveness number of modules with cluster consistency requirements within the distributed protocol (such as Raft, Paxos). This signal can be used to trigger the startup of subsequent modules after the cluster has completed leader election or data alignment.

[0077] In some implementations, the status signal also includes a configuration consistency verification signal, used to verify whether the current module's runtime environment parameters and local configuration files are consistent with the cluster's preset baseline, including version number verification and configuration file verification and comparison. This signal can be used to implement logical auditing during the startup phase.

[0078] In some implementations, status signals can be acquired through periodic polling, event triggering, or asynchronous callbacks.

[0079] In some implementations, process status signals can be acquired through the operating system interface, such as detecting the existence of the corresponding process identifier (PID), whether the process is running, and whether an abnormal exit has occurred. These process status signals can be used to determine whether the current module has completed the basic process initiation at the operating system level.

[0080] In some implementations, port connectivity status signals can be acquired through network probing, such as establishing a TCP connection, sending a port probe request, or detecting the port listening status, to determine whether the port providing services to the outside world is in a connectable state.

[0081] In further implementations, a sliding window mechanism (such as multiple consecutive successful connections) can be used to determine if a port is in a stable connectivity state, thereby avoiding misjudgments caused by momentary or false connectivity.

[0082] In some implementations, the business health status signal is obtained by executing a preset business probe. The preset business probe is used to detect the actual availability of the current module at the business logic level, and may specifically include at least one of the following: Database connection testing can be used to verify whether the client can establish a valid database session through the driver and execute basic SQL or query operations; Heartbeat command execution can be used to detect whether the current module can respond to basic requests of the application layer protocol (such as the Ping-Pong mechanism). Metadata loading status verification can be used to confirm whether key data structures within the current module (such as schema information, partition tables, routing tables, etc.) have been loaded into memory or aligned to disk. Cluster node registration status query can be used to detect whether the current module has completed logical registration and has been recognized as an online member by the cluster by accessing the cluster management plane (such as ConfigNode or Zookeeper).

[0083] Through the aforementioned business probes, the multi-module system can accurately determine whether the current module is not only started at the process layer and port layer, but also has real and usable capabilities at the business layer.

[0084] In some implementations, the acquisition of status signals employs a dynamic frequency mechanism. The executing entity can dynamically adjust the first preset time interval or acquisition frequency based on the current module's position in the topology startup sequence. For example, for a core module in a preceding position, a longer first preset time interval and a higher acquisition frequency can be set.

[0085] In this step, the status signals support two acquisition modes: active probing (Pull) and passive reception (Push). Probing can be initiated actively by the orchestration service, or the current module can proactively send a ready notification message to the orchestration service after initialization. The acquired status signals will be directly used as input data for the ready determination in step 130.

[0086] Through the above method, this step can obtain multi-dimensional status information reflecting the operating status of a module in real time after the module is started, enabling the system to perform subsequent control based on the actual operating status of the module rather than a single time or sequence, thereby providing data support for improving the accuracy and reliability of the startup process of a multi-module system.

[0087] In this embodiment of the disclosure, the readiness determination in step 130 is used to determine whether the current module has reached a stable and available state that can be used by subsequent modules, such as a stable and available state that can be used by subsequent modules for dependency calls, data interaction or business access.

[0088] In some implementations, readiness determination can be based on a combination of multiple state signals. By introducing a joint determination mechanism using multiple state signals, inaccuracies caused by misjudgments based on a single state signal can be avoided.

[0089] For example, in practical engineering, the mere existence of a process (PID online) does not necessarily mean that the internal business logic of the current module has been initialized. Similarly, the mere connectivity of a port (successful TCP three-way handshake) may indicate that the current module is in an abnormal initialization state and cannot respond to real business requests. Therefore, by combining multiple status signals (such as port connectivity and normal business heartbeat), we can more comprehensively and three-dimensionally reflect the actual state transition of the module from the operating system layer to the business layer.

[0090] In a further implementation, the readiness of the current module is determined based on at least two state signals, including: A comprehensive index is obtained by weighting at least two state signals. When the comprehensive indicators meet the preset threshold, the current module is determined to be ready.

[0091] In this implementation, multiple types of state signals are used to form decision inputs. The final comprehensive index refers to the quantitative result representing the overall readiness level of the current module, calculated based on multiple state signals, such as a percentage or score-based quantitative result representing the overall readiness state of the current module.

[0092] The preset threshold refers to the criterion used to determine whether the current module has reached the ready state.

[0093] For example, different weight coefficients are assigned to different types of status signals according to a preset configuration strategy. For instance, in distributed database scenarios such as IoTDB, business health status signals (such as metadata loading progress) are given relatively high weights, port connectivity status signals are given medium weights, and process status signals are given basic weights.

[0094] During the calculation, the quantized values ​​of each state signal are multiplied by their corresponding weights and summed to obtain the final comprehensive index. When the comprehensive index meets a preset threshold, the current module is determined to be ready.

[0095] It should be noted that the weight settings can be flexibly configured according to the current module's business type (such as compute-intensive or I / O-intensive), system reliability level requirements, or historical operating experience rules, and are not limited to fixed values, thus making the judgment logic highly adaptive.

[0096] In some implementations, to avoid misjudgments caused by short-term fluctuations or transient anomalies, the preset threshold can be further limited to: The comprehensive index remains no lower than the preset threshold within the first preset time interval.

[0097] In this implementation, by introducing a time-dimensional constraint, it can be ensured that the current module does not merely achieve the target instantaneously, but maintains a stable and usable state over a preset observation period. This stability verification can filter out the instantaneous spikes at the moment the current module starts up, greatly improving the reliability of the judgment results in complex distributed environments.

[0098] In some implementations, the comprehensive index may be continuously sampled within a first preset time interval, and statistical characteristic values ​​(such as mean, median, or mode) of the sampled sequence may be calculated. If the characteristic value meets a preset threshold, it is determined that the preset threshold is met.

[0099] This implementation method allows for slight fluctuations in the comprehensive index due to environmental noise in a short period of time. As long as the statistical characteristic value meets the standard, it can be judged as ready, effectively improving the judgment fault tolerance in network jitter environment.

[0100] In a further implementation, the acquired status signals are smoothed using a sliding window approach, and a readiness determination is performed based on the combined signals within each sliding window.

[0101] For example, a first preset time interval is defined as a dynamic observation interval with a fixed time step or a fixed number of sampling points, serving as a sliding window of fixed length. Here, a sampling point can refer to an instantaneous data point obtained by discretely acquiring and calculating the state signal during the sliding window's movement.

[0102] Within a first preset time interval, the sliding window is slid along the time axis to continuously monitor the acquired status signals. Within each sliding window, a readiness determination is made based on a set of status data (i.e., the aforementioned combined signals) covered by the sliding window.

[0103] The readyness determination results generated during the entire observation period of the first preset time interval are aggregated, and the specific number of sliding windows that are determined to meet the preset threshold within the first preset time interval is counted.

[0104] Calculate the proportion of sliding windows that meet the preset threshold to the total number of sliding windows (i.e., window compliance rate). If the proportion of sliding windows that meet the preset threshold to the total number of sliding windows exceeds the preset percentage (e.g., 95%, 99%, or other values ​​set according to business sensitivity), then the current module is determined to have entered a stable ready state.

[0105] In this implementation, the sliding window mechanism allows for a very small number of controlled, non-critical sampling point fluctuations within the sliding window at the local level. As long as the overall performance within the sliding window meets expectations, the sliding window is considered to have met the criteria. By statistically analyzing the percentage of windows meeting the criteria within a first preset time interval, the system further verifies whether the current module's state has achieved overall convergence within the larger framework, thus improving the robustness of the readiness determination.

[0106] In this way, even if an individual abnormal sliding window occurs within the entire first preset time interval (e.g. due to instantaneous network fluctuations), as long as the vast majority of sliding windows perform stably, an accurate readiness determination can still be given.

[0107] In some implementations, the aforementioned preset threshold and first preset time interval can be set differently and in a step-by-step manner based on the topological hierarchy of the current module in the startup dependency relationship.

[0108] For example, if the current module is a basic module (such as a management node or consensus module) that is in the preceding position in the topology startup sequence, its corresponding preset threshold can be set to be higher than the preset threshold of the subsequent module, and its corresponding first preset time interval can also be set to be significantly longer than that of the subsequent module.

[0109] The above dynamic configuration method follows the principle of "robust underlying layers and efficient upper layers". If the current module is a low-level module, it is required to have a higher stability threshold and a longer observation period to ensure that the "system foundation" is absolutely solid. For its corresponding upper-level business modules that are subsequent modules, under the premise that the dependencies of the underlying modules have been established, the judgment conditions can be appropriately relaxed (such as shortening the first preset time interval), thereby optimizing the overall startup time of the entire multi-module system while ensuring overall stability.

[0110] In some implementations, determining the readiness of the current module based on status signals can also be achieved through the following modes: The collected status signals of each dimension are treated as Boolean variables (i.e., "meets" or "does not meet"). The judgment logic is a hard match using a preset logical expression. For example, the preset judgment logic is the AND logic of the full names of "process status signals, port connectivity status signals, and service health status signals". When the status signals of all the above dimensions independently meet their preset sub-ready conditions, the "ready" judgment result is output.

[0111] This model eliminates the compensation effect between indicators (i.e., prevents one indicator from being too high and masking the lack of another indicator), and is suitable for core basic components with high requirements for startup security.

[0112] In other embodiments, determining the readiness of the current module based on at least two state signals further includes: Following the logical order from the underlying system to the high-level business, each status signal is judged in a layered manner. For example, process status is judged first. If the process status is ready, network probe for port connectivity is triggered. After the port is connected, a deep probe for business health status is finally executed.

[0113] This progressive decision-making process can reduce the resource overhead of the system during the high-concurrency startup phase, avoid blindly issuing heavy business layer probe requests before the underlying basic modules are stable, and achieve on-demand energy consumption management in the decision-making process.

[0114] Therefore, it should be noted that the readiness determination mechanism can be implemented using a pre-set rule base, or it can be extended to a machine learning-based predictive model or a dynamic adjustment based on configuration strategies, without deviating from the technical ideas of this disclosure. Regardless of the specific implementation method, its core lies in determining the "true usability" state of the current module through multi-dimensional state signals.

[0115] The readiness determination result in step 130 will directly serve as the logic switch for whether to trigger the release of subsequent modules in step 140. That is, when the current module is determined to be ready, its subsequent modules are allowed to enter the release and startup phase.

[0116] In this way, step 130 can combine multiple methods such as multi-dimensional state signals, quantization weighting, time windows, and topology level perception to improve the accuracy of readiness determination, effectively reduce the probability of misjudgment, and provide data support and judgment basis for the reliable startup of subsequent modules.

[0117] In this embodiment of the disclosure, in step 140 above, the successor module refers to the downstream node module in the startup dependency relationship, that is, the module that logically or functionally depends on the current module to run.

[0118] Among them, starting the successor module of the current module based on the topology startup order refers to the control behavior of releasing the lock on the successor module on the dependent path and issuing the startup command after the current module is determined to be ready.

[0119] In some implementations, if the current module is determined to be ready, its status flag is updated to ready, and its corresponding startup release logic is activated. For example, based on the topology startup order, all successor modules that have direct preceding dependencies on the current module are identified, and the startup release of the successor modules is triggered.

[0120] If multiple successor modules that depend on the current module are detected, these successor modules are added to the startup queue, and startup control is executed sequentially according to the preset resource scheduling strategy.

[0121] In some implementations, for multiple successor modules at the same topology level whose dependencies are all met, the preset resource scheduling strategy can be to adopt a parallel startup approach. By concurrently launching successor modules that have no mutual dependencies, the system's computing resources (such as multi-core CPUs or concurrent I / O) can be utilized to the maximum extent, thereby significantly reducing the total system startup time.

[0122] In other implementations, considering the instantaneous system load or specific hardware constraints, the preset resource scheduling strategy may also be to start sequentially according to preset weight priorities or resource quota limits.

[0123] For example, core components that have a greater impact on system stability can be started first, or the number of modules that can be started simultaneously can be limited in a memory-constrained environment. Through this step-by-step release mechanism based on state feedback and resource constraints, multi-module systems can achieve orderly, controlled, and efficient cascading startup according to a predefined dependency topology.

[0124] In some implementations, for each identified successor module, its corresponding full dependency list can be retrieved. If a successor module depends on multiple preceding dependent modules (i.e., has multiple incoming edges in the directed graph), the readiness status of these preceding dependent modules is checked. Only when all preceding dependent modules are determined to be ready is the successor module allowed to proceed. This multi-dependency verification mechanism ensures that, in complex topologies, subsequent business logic will not fail to start due to partial missing underlying infrastructure.

[0125] It should be noted that the preset resource scheduling strategy can be dynamically adjusted according to the real-time load of the system, the business priority of the module, or the hardware topology, and is not limited to the parallel or serial methods listed in this embodiment; the retrieval of the full dependency list can also be implemented by various algorithms such as recursive query, dynamic hash table matching, or Boolean logic matrix operation, all of which are within the protection scope of this disclosure.

[0126] Figure 3 A flowchart illustrating another multi-module system startup method provided by embodiments of this disclosure is shown, such as... Figure 3 As shown, this method includes, but is not limited to, the following steps: Step 310: Respond to the startup command and, based on the startup dependency relationship and topology startup order, sequentially control the startup of each module in the multi-module system; Step 320: For each currently triggered module, collect at least two status signals of the current module; Step 330: Determine the readiness of the current module based on at least two state signals; Step 340: If the current module is determined to be ready (yes), allow the subsequent modules of the current module to start based on the topology startup order; Step 350: If the current module is determined to be not ready (no), perform a stop operation on the started modules in the reverse topological order of the startup dependencies.

[0127] For specific implementation details of steps 310 to 340, please refer to the relevant descriptions of steps 110 to 140 above, which will not be repeated here.

[0128] In this embodiment of the disclosure, the multi-module system startup method focuses on constructing the exception handling branch corresponding to step 350, that is, when the current module is not determined to be ready, a reverse topology rollback operation is performed.

[0129] Specifically, when it is detected that the current module does not meet the preset readiness conditions, the triggering of subsequent module startup will be aborted, and a rollback process will begin. Here, "started modules" refers to the set of modules that have completed the startup control in step 310 and have been determined to be ready before the current time point. This includes the current module, and if the current module has a predecessor module that has already started, it also includes predecessor modules that started before the current module. Reverse topology order refers to the execution order in reverse relative to the topology startup order, used for controlled rollback of dependency chains in abnormal situations.

[0130] In this implementation, the startup release logic and the exception rollback logic form mutually exclusive branches, and the two will not be triggered simultaneously within the same decision cycle. When the current module is determined to be ready, it performs step-by-step release; when it is determined to be not ready, it triggers reverse topology rollback, thus forming a complete automated startup control closed loop.

[0131] Through the above methods, the embodiments of this disclosure not only realize the startup control of successor modules based on the ready state, but also restore system consistency through the reverse topology rollback mechanism in abnormal situations, thereby improving the reliability and controllability of the startup process of multi-module systems.

[0132] In some implementations, the specific circumstances under which the current module is determined to be not ready include: Within the second preset time interval, the comprehensive index or status signal of the current module consistently fails to reach the preset threshold. During the observation process, it can detect in real time that the current module is in an unexpected abnormal state, such as the current module process exiting unexpectedly, the bound core port being unreachable, or the business probe reporting a serious error.

[0133] It should be noted that, in this embodiment, the second preset time interval is used to limit the maximum allowed waiting time of the current module during the startup phase, which corresponds to the timeout control parameter for module startup ( This is used to determine whether the current module has completed the transition from the started to the ready state within a reasonable time.

[0134] Correspondingly, in step 130, the first preset time interval used to determine the current module's stable and ready state ( This is used to constrain the sustainability of comprehensive indicators meeting preset thresholds, in order to avoid misjudgments caused by instantaneous fluctuations or temporary compliance.

[0135] In terms of temporal semantics, the first preset time interval and the second preset time interval have the following relationship: The first preset time interval is used for stability verification during the readiness determination phase, while the second preset time interval is used for timeout boundary control during the startup phase. In terms of numerical relationships, the first preset time interval is less than or equal to the second preset time interval, that is:

[0136] In some implementations, the first preset time interval is a time window that is part of the second preset time interval, and is used to determine the stability convergence of the module state within the second preset time interval.

[0137] With the above settings, during the startup process of any module, the module status is continuously monitored within the second preset time interval, and a time segment that meets the stability condition of the first preset time interval is searched within this time range. If no time segment that meets the stability condition appears before the end of the second preset time interval, it is determined that the current module is not ready, thereby triggering the subsequent exception handling process.

[0138] By distinguishing between the first preset time interval and the second preset time interval, and establishing a two-layer time constraint mechanism for stability judgment and timeout control, the problems of instantaneous readiness misjudgment and infinite waiting can be avoided at the same time, thereby improving the judgment accuracy and overall controllability of the multi-module system startup process.

[0139] After confirming the rollback trigger, the started modules are withdrawn one by one from the end of the dependency chain to the root node, following a path that is strictly opposite to the topology startup order.

[0140] In some implementations, it can be based on Figure 2 The directed graph structure shown performs rollback processing on started modules according to reverse order logic, thereby ensuring that underlying infrastructure resources are not shut down before the corresponding upper-layer dependencies are cleared, thus guaranteeing logical consistency and data security during the rollback process.

[0141] In some implementations, to ensure the completeness of resource release, performing a stop operation on a started module includes at least one of the following: Stop the running process of the started module; Release the port resources occupied by the started modules; Clean up temporary state files generated during the operation of started modules.

[0142] Releasing port resources refers to releasing the network port or communication socket occupied by the started module, which can prevent port conflicts during subsequent retries.

[0143] Cleaning up temporary state files can refer to cleaning up intermediate data generated during block execution, such as PID files, lock files, or temporary cache data, in order to eliminate the interference of residual state on the next environment initialization.

[0144] In some implementations, a graceful stop command can be sent to the started module before executing the process of stopping the running process of the started module, so that the started module has the opportunity to perform resource release and state saving operations. In the event of a graceful stop timeout or an unresponsive started module, a forced stop operation is performed to balance system stability and exception handling efficiency.

[0145] It should be noted that by performing the above-mentioned reverse topology stop operation, the system state can be restored to the unstarted or initial state, thereby avoiding inconsistencies caused by residual operation of some modules and providing a clean operating environment for subsequent restarts.

[0146] In some implementations, the system has the ability to automatically recover after the shutdown operation of the started module is completed. Specifically, the start command is regenerated according to a preset retry strategy (e.g., exponential backoff retries or limited number of retries), and the system returns to execute the response start command in step 110.

[0147] To prevent "secondary failures" caused by blindly retrying before the environment is properly cleaned, the execution entity can perform a consistency check before regenerating the startup instructions. The consistency check includes: Verify that the process corresponding to the started module has completely exited; Verify whether the corresponding physical or logical port has been successfully released.

[0148] If the consistency check passes, it is determined that the current environment has been restored to a clean initial state. Then, the step of regenerating the startup command according to the preset retry strategy is executed, and the startup control of the multi-module system is restarted based on the topology startup sequence.

[0149] In some implementations, if the consistency check fails (e.g., the process freezes and cannot exit or the port is continuously occupied), the retry process is terminated, and a detailed startup exception report is output. The report may include the faulty module identifier, the reason for the consistency check failure, and stack information to facilitate manual intervention by operations and maintenance personnel.

[0150] In the above embodiments, through the aforementioned reverse-order stopping, resource cleanup, graceful exit, and retry mechanism with consistency verification, the embodiments of this disclosure achieve automated fault tolerance and atomic rollback of the multi-module system startup process at the algorithm level. This not only effectively avoids resource deadlock or data pollution problems caused by the residual operation of some components, but also provides a solid technical guarantee for the continuous availability of large-scale complex distributed systems.

[0151] In some implementations, startup dependencies are stored as a directed graph. During the rollback phase, an inverse topological order is generated based on this directed graph. Specifically, the inverse topological order can be obtained in any of the following ways: Transpose all directed edges in the original directed graph to construct a reverse directed graph. Then apply a topological sorting algorithm to the reverse directed graph to generate a sequence that is the natural inverse topological order.

[0152] Based on the original directed graph, a reverse traversal is performed, which means reversing the original topological starting order to obtain the reverse topological order. Specifically, the reverse output results of depth-first search (DFS) or breadth-first search (BFS) are used, or the forward topological sorting results are pushed onto and popped onto a stack (last-in, first-out), to obtain a reverse traversal sequence that satisfies the dependency unconstraint.

[0153] Both of the above methods can be used to generate inverse topological orders that satisfy dependency backoff constraints. Other equivalent methods can also be used without departing from the technical concept of this disclosure.

[0154] The reverse topological order generated in the above manner ensures that when a stop operation is performed, the successor module is stopped before its dependent modules.

[0155] In a further implementation, performing a stop operation on the started modules according to the reverse topological order of the startup dependencies may include the following process: First, based on the directed graph, modules with at least one level of dependency relationship with the current module that are deemed not ready are identified and designated as candidate modules for rollback. Specifically, starting from the current module, the system traverses the dependency path in reverse or forward direction to identify related modules that have direct or indirect dependencies on the current module, thereby determining the scope of modules that need to participate in the rollback. For example, if the current module A depends on the predecessor module Y, and the predecessor module Y depends on the root module X, when the current module A is determined to be not ready, both the already running predecessor modules Y and X are identified as candidate modules for rollback.

[0156] Secondly, modules that are candidates for stopping are selected from the already started modules, forming a set of modules to be stopped. For example, the intersection operation is performed between the aforementioned dependent candidate stopping objects and the current set of started modules. Since the preceding modules start before the current module in the topology startup sequence, these modules that are on the dependency path of the current module A and are already running constitute the set of modules to be stopped. This step ensures that the rollback operation only applies to the dependency links related to the faulty module and does not inadvertently affect other parallel and unrelated started branches in the system.

[0157] Therefore, this screening process can avoid performing redundant operations on modules that have not been started or are irrelevant, thereby improving rollback efficiency.

[0158] Subsequently, stopping operations are performed on the set of modules to be stopped in reverse topological order. Specifically, stopping is performed on each module one by one in reverse topological order, ensuring that modules that are later in the dependency chain are stopped first, while their dependent modules are stopped in subsequent stages. This reverse-order mechanism of starting later and stopping earlier ensures that when any preceding module is shut down during the rollback process, its dependent modules have already been safely shut down beforehand, thus avoiding dependency hanging or system crashes caused by the premature rollback of underlying resources, and guaranteeing the consistency of the rollback process.

[0159] In some implementations, the identification of candidate stop objects can be based on a single layer of dependencies, or it can be extended to multiple layers or the entire path dependency. The set of modules to be stopped can be a subset of all started modules, or it can be extended to all started modules under a specific strategy, thereby enabling rollback control of different granularities in different application scenarios.

[0160] By using the above method, this implementation not only clarifies the generation mechanism of the reverse topology order, but also refines the selection and execution logic of the modules to be stopped during the rollback process, so that the exception handling process has a clear execution path and scope control, thereby improving the pertinence and controllability of the rollback operation while ensuring system consistency.

[0161] Compared to traditional full system restarts, this solution can significantly reduce the computational overhead and system oscillations caused by anomaly handling, especially in the startup scenario of distributed databases with many nodes (such as IoTDB), greatly improving the robustness of the system startup process and the efficiency of anomaly self-healing.

[0162] In some implementations, such as Figure 4 As shown, the multi-module system 400 may include a database module 410 and a business interface module 420. The database module 410 is used to provide data storage and query capabilities, and the business interface module 420 is used to provide a user-facing interactive interface and business function display.

[0163] The business interface module 420 relies on the data service capabilities provided by the database module 410 during operation. Therefore, in the startup dependency relationship, the database module 410 is the preceding module and the business interface module 420 is the following module.

[0164] In this embodiment, when startup control is performed on the database module 410, the database module 410 can be processed as the current module. This includes: collecting the status signal of the database module 410 and determining its readiness; when the database module is determined to be ready, triggering the startup control of the business interface module 420, which is the successor module.

[0165] It should be noted that in this application scenario, the prerequisite for starting the business interface module 420 includes not only that the database process has started, but also that the database has service capabilities at the business level, such as being able to respond to connection requests or execute basic queries, so as to ensure that the business interface module 420 can establish a connection and provide services normally after starting.

[0166] In a further implementation, such as Figure 5 As shown, the database module 410 can be a composite module containing sub-modules with startup dependencies, thus forming a nested dependency topology.

[0167] Specifically, the database module 410 can be a distributed database system, which includes multiple sub-modules with startup dependencies, such as the management node module 411 and the data node module 412. The management node module 411 is used to provide cluster management, metadata services, or coordination functions, while the data node module 412 is used to provide specific data storage and query capabilities.

[0168] In this embodiment, the startup control of the database module 410 can be further refined into a startup control process at the sub-module level.

[0169] Specifically, the management node module 411 can be executed first as a preceding module in the sub-startup unit. Figure 1 or Figure 3 The startup method is shown.

[0170] After the data node module 412 starts, its execution status is collected and readyness is determined. When the data node module 412 is determined to be ready, the database module 410 as a whole can be considered ready. At this time, the ready result of the database module 410 as a whole module is established, thereby triggering the start control of the business interface module 420 as the successor module.

[0171] It should be further noted that, in some implementations, the data node module 412 may include multiple instance nodes, which can be started in parallel provided that dependencies are satisfied. Furthermore, the overall readiness determination of the database module 410 can be based on the readiness of all data node modules, or on the readiness of a preset number or proportion of data node modules 412, thus allowing for flexible configuration in different application scenarios.

[0172] Furthermore, in this hierarchical startup structure, the internal startup process of the database module 410 (management node module 411 → data node module 412) is nested with the overall system startup process (database module 410 → business interface module 420), meaning that the module itself still follows... Figure 1 or Figure 3 The startup control mechanism enables a unified dependency modeling and state-driven control approach.

[0173] For example, such as Figure 6 As shown, based on Figure 5 The startup method for the multi-module system architecture shown includes the following steps: Step 610: Upon receiving the startup request, confirm the startup command; Step 620: Start the control management node module 411; Step 630: Collect the multi-dimensional status signals of the management node module 411 and perform a readiness determination; Step 640: If the management node module 411 is determined to be ready, trigger the release of the data node module 412; Step 650: Repeat the above status signal acquisition and readiness determination steps for data node module 412, and after determining that it is ready, confirm that the database module 410 is ready as a whole, and then trigger the start of business interface module 420.

[0174] By using the above method, the database module 410 is split into sub-modules with hierarchical dependencies for startup control, and the business interface module 420 is triggered to start only after the database module 410 is fully ready. This not only ensures that the system startup order conforms to the actual dependencies, but also improves the success rate of the business interface module 420 startup, thereby enhancing the overall startup stability and consistency of the multi-module system.

[0175] In some implementations, the multi-module system startup method can be applied to an orchestration service architecture, where the modules in the multi-module system are distributed and run on different physical nodes. The orchestration service, as a unified execution entity, performs startup control on the modules on each physical node through remote communication and collects corresponding status signals, thereby achieving cross-node multi-module collaborative startup.

[0176] The orchestration service refers to the control module used to perform startup dependency management, status acquisition, readiness determination, and startup control logic, and can run as an independent service. A physical node refers to a computing device with deployed modules, such as a server node, virtual machine, or container instance. The remote communication method refers to the communication mechanism between the orchestration service and the physical node for command interaction and status acquisition, such as remote invocation or message communication based on network protocols.

[0177] In one specific implementation, the orchestration service can be deployed on a central node or any node with scheduling capabilities, and maintain the startup dependencies of the multi-module system (e.g., stored in the form of a directed graph).

[0178] When performing steps 110 or 310 above, the orchestration service sends startup commands to the corresponding physical nodes through the remote communication interface according to the topology startup order, so as to trigger the startup control of each module.

[0179] In step 120 or 320, the orchestration service collects the status signals of the current module from each physical node via remote communication. Specifically, it can obtain at least one of the following: process status signals, port connectivity status signals, and service health status signals by remotely calling the agent program, system interface, or probe service on the node. The collected status signals are uniformly summarized in the orchestration service for use in the readiness determination of subsequent steps 130 or 330.

[0180] In step 130 or 330, the orchestration service performs a readiness determination based on the collected status signals, and in step 140 or 340, 350, it decides whether to send a start command to the physical node where the successor module is located, or to trigger a cross-node reverse topology rollback operation in abnormal circumstances, based on the determination result.

[0181] It should be noted that during the rollback process, the orchestration service also sends stop commands to each physical node via remote communication and coordinates resource release and state cleanup to achieve consistent recovery across nodes.

[0182] In some implementations, the orchestration service can serve as a general startup control hub, supporting unified orchestration of multiple nodes and modules, so that the startup process of the entire system does not depend on the local execution logic of a single node, but achieves global consistency through centralized control.

[0183] In different application scenarios, the startup methods for multi-module systems can have different deployment forms.

[0184] For example, the multi-module system runs in a desktop stand-alone mode, where each module (e.g., the database module and the business interface module) is deployed as an independent process on the same physical node.

[0185] In this scenario, the orchestration service can be implemented as a local initiator, using local process management and state acquisition mechanisms. Figure 1 or Figure 3 The execution of each step in the startup method shown. At this point, remote communication can degenerate into local process calls or system interface calls.

[0186] For example, the multi-module system operates in a service-oriented model, where status acquisition, readiness determination, and startup control logic are abstracted into independent orchestration services. These services uniformly manage the modules distributed across different physical nodes. Each node can deploy a lightweight proxy or interface service to receive startup commands and report status information. In this model, Figure 1 or Figure 3 The startup methods shown are all executed centrally by the orchestration service, enabling collaborative startup and unified rollback control across nodes.

[0187] For example, in resource-constrained environments, a lightweight mode can be adopted, where only process status signals and port connectivity status signals are collected during status acquisition and readiness determination, with business health status signals as an optional enhancement. In this mode, status acquisition overhead and system resource consumption can be reduced, while still achieving basic startup sequence control and status determination functions.

[0188] It should be noted that the above different deployment forms are all based on the same core technology mechanism, namely dependency modeling, state signal acquisition, readiness determination and phased start-up control. The only difference lies in the deployment method and the complexity of implementation.

[0189] By adopting the above method, cross-node startup control of multi-module systems can be achieved under the orchestration service architecture, enabling the system to maintain a unified startup order and status determination logic in a distributed environment, thereby improving the startup consistency and manageability of multi-module systems in complex deployment environments.

[0190] To enable those skilled in the art to better understand the above-described startup control process, the following further elaborates on the execution details of the embodiments of this disclosure in conjunction with specific mathematical models and logical parameters.

[0191] In some implementations, to provide a quantitative description of the startup process of a multi-module system, refer to the symbols and their definitions in Table 1 below:

[0192] Table 1

[0193] Based on the parameters above, the multi-module system startup method can be executed according to the following steps: Step S10, Dependency Modeling: Read the pre-defined module dependencies, construct a directed graph G to represent the startup dependencies of each module, and perform topological sorting based on the directed graph to determine the topology startup order.

[0194] Step S20, initiate request acceptance: Receive the startup command for the multi-module system, generate the LogID identifier for this startup session, and initialize the state machine and the running log module.

[0195] Step S30, Initial module launch: Based on the topology startup order, the initial module with an in-degree of zero is started and set as the current module. Then, the status signal acquisition loop begins.

[0196] Step S40, Status signal acquisition: For the current module At any moment Periodically collect its state vector The state vector includes at least the process state signal. Port connectivity status signal and business health status signals At least two of them.

[0197] Step S50: Readiness check: Calculate the comprehensive index based on the state vector:

[0198] in .

[0199] when T_heta i And in the first preset time interval If the ready condition is continuously met, the current module will be... The condition has been determined to be ready.

[0200] Step S60, Phased Release: In the current module Once a module is deemed ready, its subsequent modules are started based on the topology startup sequence until all modules are ready.

[0201] Step S70, Failure Detection: If the current module Second preset time If the system is not ready or an abnormal state is detected, the startup is deemed to have failed, and the following rollback process will be initiated.

[0202] Step S80, automatic rollback, this includes Figure 7 The steps are as follows: Step 710: Startup failed; Step 720: In the event of startup failure, collect the set of started modules. If the current module If it is a Workbench, then the set of modules that have been started is... ; Step 730: In reverse topological order ) Perform a stop operation, including: Step 740: Stop the current module The process runs, releases its port resources, cleans up temporary states, and writes to the rollback log.

[0203] Continue to step S90 and retry control: Determine if the maximum number of retries has been reached. ; Before the maximum number of retries has been reached If this occurs, a retry is allowed, which includes regenerating the startup command and returning to step S20. In some implementations, a consistency check is performed before retrying.

[0204] Step S100, if the maximum number of retries is reached... If it still fails, a session-level startup report based on LogID will be output, which includes startup time, failed modules, rollback path and final execution result.

[0205] Figure 8A modular structure diagram of the multi-module system startup device provided in this disclosure is shown. The multi-module system startup device can be deployed in a distributed computing environment, and its execution entity can be an orchestration service cluster composed of multiple service nodes. The modules in the multi-module system communicate with each other through interface calls, remote procedure calls, or message mechanisms, thereby forming a complete startup control chain.

[0206] like Figure 8 As shown, the multi-module system startup device 800 may include: The startup unit 810 responds to the startup command and, based on the startup dependency relationship and topological startup order, sequentially controls the startup of each module in the multi-module system. The status acquisition unit 820 acquires at least two status signals for each currently triggered module. The readiness determination unit 830 performs a readiness determination on the current module based on at least two state signals; Release unit 840, when the current module is determined to be ready, releases the subsequent modules of the current module based on the topology startup order.

[0207] Each of the above units can be deployed as an independent service or integrated into the same service process.

[0208] In some implementations, the starting unit 810 is specifically used for: First, the startup dependencies stored in the form of a directed dependency graph are obtained, and the topology startup order is generated by the topology sorting algorithm. When there are multiple successor modules that depend on the current module, startup control can be executed sequentially or concurrently according to the preset resource scheduling strategy.

[0209] In some implementations, at least two status signals include at least two of process status signals, port connectivity status signals, and service health status signals.

[0210] In some implementations, business health status signals can be obtained by executing preset business probes, which include at least one of database connection tests, heartbeat command execution, metadata loading status verification, or cluster node registration status queries.

[0211] In a distributed deployment scenario, the status acquisition unit 820 acquires status signals through remote communication with each physical node.

[0212] In some implementations, the readiness determination unit 830 is specifically used to: perform weighted calculation on at least two state signals to obtain a comprehensive index, and determine that the current module is ready when the comprehensive index meets a preset threshold.

[0213] In some implementations, the preset threshold and the first preset time interval can be configured differently based on the current module's hierarchy in the topology startup sequence. Specifically, the preset threshold of a module that is in a preceding position in the topology startup sequence is higher than the preset threshold of its successor module, and its first preset time interval is longer than the first preset time interval of its successor module.

[0214] In a further embodiment, the readiness determination unit 830 is also used for: Within a first preset time interval, the status signals are smoothed using a sliding window method, and the current module is determined to be ready based on at least two status signals in each sliding window. The number of sliding windows that meet a preset threshold within the first preset time interval is counted. When the proportion of the number of sliding windows to the total number of sliding windows exceeds a preset proportion, the current module is determined to be ready.

[0215] In some implementations, the release unit 840 is specifically used for: If a subsequent module depends on multiple preceding dependent modules, the release will only be triggered after all preceding dependent modules have been determined to be ready.

[0216] Figure 9 This illustration shows a module architecture diagram of a multi-module system startup device provided in another embodiment of this disclosure, and... Figure 8 compared to, Figure 9 The multi-module system startup device shown also includes: The exception handling unit 950, when the current module is determined to be not ready, performs a stop operation on the started modules according to the reverse topological order of the startup dependencies. Determining that the module is not ready includes the current module not being determined to be ready within a second preset time interval, or the current module being detected to be in an abnormal state.

[0217] In some implementations, the stop operation includes at least one of stopping the running process, releasing port resources, and cleaning up temporary state files. Before stopping the running process, the exception handling unit 950 sends a graceful stop command to the started module, and stops the running process of the started module if the graceful stop times out.

[0218] In some implementations, the exception handling unit 950 is further configured to: After stopping the operation, a consistency check is performed. The check includes whether the process corresponding to the started module has exited and the corresponding port has been released. If the check passes, a retry is triggered according to the preset retry policy. If it fails, a startup exception report is output.

[0219] In some implementations, the reverse topological order is generated by performing edge reversal or reverse traversal on the directed dependency graph. Furthermore, based on the directed graph, modules that are not ready and have at least one layer of dependency relationship with the current module are identified as candidate stopping objects. Modules belonging to the candidate stopping objects are selected to form a set of modules to be stopped, and the stopping operation is performed in reverse topological order.

[0220] In specific application scenarios, this device can be used for the coordinated startup of the database module and the business interface module. The database module can be further divided into a management node module and a data node module. When executing the database module startup control, the management node module is used as a sub-startup unit to perform startup control. When the management node module is determined to be ready, the startup control of the data node module, which is its sub-successor unit, is triggered. When the data node module is determined to be ready, the database module is determined to be ready, and the business interface module, which is the successor module, is triggered to proceed.

[0221] In different application scenarios, this device can support desktop standalone mode, service-oriented mode or lightweight mode. In lightweight mode, readiness can be determined based solely on process status signals and port connectivity signals, while business health status signals are optional enhancements.

[0222] Through the above methods, the multi-module system startup device provided in this embodiment of the present disclosure, by introducing a startup control mechanism based on topology dependence, a multi-dimensional state signal acquisition mechanism, and a readiness determination mechanism based on stability constraints, achieves accurate perception of the true readiness state of the modules, and based on this, performs execution phase release and abnormal rollback control, thereby improving the accuracy, stability, and controllability of the multi-module system startup process.

[0223] This disclosure also provides an electronic device, including a processor and a memory, wherein the memory stores executable instructions that can be executed by the processor. When the processor executes the executable instructions, it implements the steps of the multi-module system startup method of the foregoing embodiments.

[0224] As described above, the electronic device of the present invention introduces a startup control mechanism based on topology dependence, a multi-dimensional state signal acquisition mechanism, and a readiness determination mechanism based on stability constraints to achieve accurate perception of the true readiness state of the module, and based on this, executes phase release and abnormal rollback control, thereby improving the accuracy, stability and controllability of the startup process of a multi-module system.

[0225] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0226] Figure 10 This is a schematic diagram of the electronic device of the present invention. See below for reference. Figure 10 To describe an electronic device 1000 according to this embodiment of the present invention. Figure 10 The electronic device 1000 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0227] like Figure 10 As shown, the electronic device 1000 is presented in the form of a general-purpose computing device. The components of the electronic device 1000 may include, but are not limited to: at least one processing unit 1010, at least one storage unit 1020, a bus 1030 connecting different platform components (including storage unit 1020 and processing unit 1010), a display unit 1040, etc.

[0228] The storage unit stores program code, which can be executed by the processing unit 1010, causing the processing unit 1010 to perform the steps described in the multi-module system startup method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 1010 can perform, as follows: Figure 1 or Figure 3 The steps are shown.

[0229] Storage unit 1020 may include a readable medium in the form of an active storage unit, such as random access memory (RAM) 1021 and / or cache memory 1022, and may further include read-only memory (ROM) 1023.

[0230] Storage unit 1020 may also include program / utility business tool 1024 having a set (at least one) program module 1025, such program module 1025 including but not limited to: operating system, one or more application programs, other program modules and program data, each of these examples or some combination of these may include an implementation of a network environment.

[0231] Bus 1030 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0232] Electronic device 1000 can also communicate with one or more external devices 1001 (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 1000, and / or any device that enables electronic device 1000 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1050. Furthermore, electronic device 1000 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1060. Network adapter 1060 can communicate with other modules of electronic device 1000 via bus 1030. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0233] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or electronic device, etc.) to execute the methods according to the embodiments of this disclosure.

[0234] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a computer program product capable of implementing the methods described above is stored. In some possible implementations, various aspects of this disclosure may also be implemented as a computer program product including program code that, when the computer program product is run on an electronic device, causes the electronic device to perform the steps of the various exemplary embodiments of this disclosure described in the "Exemplary Methods" section above.

[0235] The program product for implementing the above-described method according to embodiments of the present disclosure may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on an electronic device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0236] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0237] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0238] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0239] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on an IoT terminal, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0240] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0241] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0242] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or electronic device, etc.) to execute the methods according to the embodiments of this disclosure.

[0243] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A method for starting a multi-module system, characterized in that, The modules in the multi-module system have startup dependencies, and the startup method of the multi-module system includes: In response to the startup command, based on the topological startup order of the startup dependencies, the startup control is performed on each module in the multi-module system in sequence; For each currently triggered module, at least two status signals of the current module are collected; The readiness of the current module is determined based on the at least two state signals. If the current module is determined to be ready, the subsequent modules of the current module are allowed to start based on the topology startup order.

2. The multi-module system startup method according to claim 1, characterized in that, The multi-module system startup method also includes: If the current module is determined to be not ready, the started modules are stopped in reverse topological order of the startup dependencies.

3. The multi-module system startup method according to claim 2, characterized in that, The current module is determined to be not ready, including: If the current module is not determined to be ready within the second preset time interval, or if the current module is detected to be in an abnormal state.

4. The multi-module system startup method according to claim 2, characterized in that, The step of stopping a started module includes at least one of the following: Stop the running process of the started module; Release the port resources occupied by the started module; Clean up the temporary state files generated during the operation of the started module.

5. The multi-module system startup method according to claim 2, characterized in that, The multi-module system startup method also includes: Before stopping the running process of the started module, a graceful stop command is sent to the started module, and if the graceful stop times out, the running process of the started module is stopped.

6. The multi-module system startup method according to claim 2, characterized in that, The multi-module system startup method also includes: After stopping the started module, the startup command is regenerated according to the preset retry strategy, and the response startup command is executed. Based on the startup dependency topology startup order, the startup control of each module in the multi-module system is performed in sequence.

7. The multi-module system startup method according to claim 6, characterized in that, Before regenerating the startup command according to the preset retry policy, the following consistency check is performed: The process corresponding to the started module has exited and the corresponding port has been released; If the consistency check passes, the startup command is regenerated according to the preset retry strategy.

8. The multi-module system startup method according to claim 7, characterized in that, The method further includes: If the consistency check fails, the execution of the startup command is terminated and regenerated according to the preset retry strategy, and a startup exception report is output.

9. The multi-module system startup method according to claim 2, characterized in that, The startup dependencies are stored in the form of a directed graph; the reverse topological order is generated by performing edge reversal or reverse traversal on the directed graph.

10. The multi-module system startup method according to claim 9, characterized in that, The step of performing a stop operation on the started modules according to the reverse topological order of the startup dependencies specifically includes: Based on the directed graph, modules that are not ready and have at least one layer of dependency relationship with the current module are identified and determined as candidate stopping objects; The modules that belong to the candidate to be stopped are selected from the started modules to form a set of modules to be stopped; The stop operation is performed on the set of modules to be stopped in the reverse topological order.

11. The multi-module system startup method according to claim 1, characterized in that, The process of determining the readiness of the current module based on the at least two state signals includes: A comprehensive index is obtained by weighting the at least two state signals. When the comprehensive index meets the preset threshold, the current module is determined to be ready.

12. The multi-module system startup method according to claim 11, characterized in that, The condition of satisfying the preset threshold includes: The comprehensive indicator is not lower than the preset threshold within the first preset time interval.

13. The multi-module system startup method according to claim 12, characterized in that, The preset threshold and the first preset time interval are determined based on the topological hierarchy of the current module in the startup dependency relationship; In the topology startup sequence, the module that is in the preceding position has a preset threshold that is higher than the preset threshold of its successor module, and its first preset time interval is longer than the first preset time interval of its successor module.

14. The multi-module system startup method according to claim 12, characterized in that, The step of determining the readiness of the current module based on the at least two state signals further includes: Within the first preset time interval, the acquired state signals are smoothed using a sliding window method, and at least two state signals within each sliding window are judged to be ready. Count the number of sliding windows that meet the preset threshold within the first preset time interval; If the proportion of the number of sliding windows that meet the preset threshold to the total number of sliding windows exceeds a preset percentage, then the current module is determined to be in a ready state.

15. The multi-module system startup method according to claim 1, characterized in that, The at least two status signals include at least two of the following: process status signals, port connectivity status signals, and service health status signals.

16. The multi-module system startup method according to claim 15, characterized in that, The service health status signal is obtained by executing a preset service probe, which includes at least one of the following: Database connection test; Heartbeat command executed; Metadata loading status verification; Cluster node registration status query.

17. The multi-module system startup method according to claim 1, characterized in that, The multi-module system startup method is applied to an orchestration service, wherein the modules in the multi-module system are distributed across different physical nodes; the orchestration service, through remote communication with the physical nodes, sequentially controls the startup of each module in the multi-module system and collects at least two status signals of the current module.

18. The multi-module system startup method according to claim 1, characterized in that, The multi-module system includes a database module and a business interface module; When executing the startup control of the database module, the database module serves as the current module, and the business interface module serves as the corresponding successor module.

19. The multi-module system startup method according to claim 18, characterized in that, The database module includes a management node module and a data node module that have the aforementioned startup dependencies; the startup control of the database module specifically includes: The management node module is used as a sub-startup unit to perform startup control, and when the management node module is determined to be ready, the startup control of the data node module, which is the sub-successor unit of the sub-startup unit, is triggered. If the data node module is determined to be ready, the database module is determined to be ready, and the business interface module, which is the successor module, is allowed to proceed.

20. The multi-module system startup method according to claim 1, characterized in that, The startup dependencies are stored in the form of a directed graph; the topology startup order is determined by performing a topology sorting algorithm on the directed graph.

21. The multi-module system startup method according to claim 1, characterized in that, The step of starting the successor module of the current module based on the topology startup order includes: If multiple successor modules that depend on the current module are detected, startup control is executed sequentially according to a preset resource scheduling strategy.

22. The multi-module system startup method according to claim 1, characterized in that, Based on the aforementioned topology startup order, subsequent modules of the current module are allowed to proceed, including: If the current module is determined to be ready, and it is identified based on the topology startup order that the subsequent module depends on multiple preceding dependent modules, then if all of the multiple preceding dependent modules are determined to be ready, the subsequent module is allowed to proceed.

23. A multi-module system startup device, characterized in that, The modules in the multi-module system have startup dependencies, and the multi-module system startup device includes: The startup unit responds to the startup command and, based on the topological startup order of the startup dependencies, sequentially controls the startup of each module in the multi-module system. The status acquisition unit acquires at least two status signals for each currently triggered module. The readiness determination unit performs a readiness determination on the current module based on the at least two state signals; The release unit, when the current module is determined to be ready, releases the subsequent modules of the current module based on the topology startup order.

24. An electronic device, characterized in that, include: processor; as well as A memory in which executable instructions of the processor are stored; The processor is configured to execute the multi-module system startup method of any one of claims 1 to 22 by executing the executable instructions.

25. A computer-readable storage medium for storing a program, characterized in that, When the program is executed, it implements the multi-module system startup method according to any one of claims 1 to 22.

26. A computer program product having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-module system startup method according to any one of claims 1 to 22.

Images