Constraint-based multi-component installation planning method and its application

Abstract

The application provides a multi-component installation planning method based on constraint solving and application thereof, and belongs to the technical field of computer automation operation and maintenance. In view of the problem that the prior art lacks global conflict prediction, resulting in that deployment is prone to failure, a global dependency graph containing nodes and relationship edges is constructed by acquiring a list of components to be installed and multi-source metadata; multi-dimensional constraints are extracted and formalized as logical statements; a constraint solver is called to solve, and a combination of component versions satisfying the constraints is output; if the solution is not available, a closed-loop feedback process is triggered, a strategy constraint set containing an isolation domain is generated based on conflict characteristics, and secondary solving is performed until it is feasible; finally, a loop-free installation plan is generated by topological sorting based on the feasible combination. The application can predict and eliminate cross-source and version conflicts in advance, and greatly improves the first success rate of complex application stack deployment.

Description

Technical Field

[0001] This invention relates to the field of computer automated operation and maintenance and software deployment technology, and more specifically, to a multi-component installation planning method based on constraint solving and its application. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, the automated deployment of complex application stacks, including system packages, container images, and source code, on Linux servers has become commonplace. Existing technologies typically employ system package managers such as APT / YUM or configuration management tools such as Ansible and Terraform for deployment.

[0003] These tools are mostly based on local and static dependency resolution logic. For example, APT can only handle dependencies within its own software repository and cannot establish a global view for cross-source and cross-format third-party component dependencies. At the same time, existing solutions rely on fixed rules or greedy algorithms for version selection, and the installation process follows a passive execution mode of "try-error-manual intervention and adjustment". They cannot make overall predictions and plans based on the existing environmental resources of the target host and the user's multi-dimensional configuration needs before execution.

[0004] Therefore, there is an urgent need for a multi-component installation planning method based on constraint solving and its application to solve the problems existing in the current technology. Summary of the Invention

[0005] This invention provides a multi-component installation planning method based on constraint solving and its application. It addresses the technical defects of existing technologies, such as the locality of dependency resolution and the lack of a global conflict prediction mechanism, which makes it easy for cross-source or version conflicts to occur during the deployment of complex application stacks with multiple forms, resulting in passive fault tolerance, difficulty in rollback, and easy damage to the stability of the target system.

[0006] The core technology of this invention is to construct a global dependency graph across multiple components, formalize the dependency relationships and environmental states into multi-dimensional logical constraints, use constraint solvers (SAT / ASP) to perform global conflict prediction and multi-objective optimization before installation, and combine a closed-loop feedback decoupling strategy to automatically derive the conflict-free optimal installation plan.

[0007] In a first aspect, the present invention provides a multi-component installation planning method based on constraint solving, the method comprising the following steps:

[0008] Obtain the list of components to be installed as input by the user, and detect the target host environment information;

[0009] Metadata of multi-form components is collected from multiple heterogeneous sources through a preset source adapter, and the metadata is uniformly modeled to construct a global dependency graph containing component nodes and directed edges with attributes.

[0010] Multi-dimensional constraints are extracted based on the global dependency graph, the list of components to be installed, and the target host environment information, and these multi-dimensional constraints are formalized into logical statements that can be recognized by the constraint solver.

[0011] The constraint solver is invoked to solve the logical statement. If the solution is successful, the component version combination that satisfies all constraints is output. If the solution is determined to be unsolvable, a conflict resolution closed-loop feedback process is triggered to generate a new set of constraints for a second solution until a feasible component version combination is obtained.

[0012] Based on component version combinations and global dependency graphs, a directed graph topology sort is performed to generate an acyclic installation sequence plan.

[0013] Furthermore, multi-form components include system software packages, container images, binary compressed packages, and source code compilation artifacts;

[0014] Metadata of multi-form components is collected from multiple heterogeneous sources through a pre-defined source adapter, and the metadata is uniformly modeled to construct a global dependency graph containing component nodes and directed edges with attributes, including:

[0015] A multi-threaded parallel strategy with flow control is used to pull metadata from the system software repository, container repository, and general file repository.

[0016] Extract component identifiers, versions, and dependency information from metadata, convert components of different forms into standardized data structures as component nodes, and convert the dependency, conflict, provision, and replacement relationships between components into directed edges with attributes.

[0017] Furthermore, the global dependency graph is stored using an adjacency list structure;

[0018] The component node contains a component ID, version quantization value, form type, and resource attribute fields. The version quantization value is the result of converting the semantic version number into a numerical value.

[0019] Attributed directed edges include relation type, version constraint rules, and mandatory attribute fields.

[0020] Furthermore, the step of calling the constraint solver to solve the logical statement also includes:

[0021] Define the quantitative optimization objective function;

[0022] Based on the number of components to be installed and the number of constraints, adaptively select the SAT solver or the ASP solver;

[0023] If the ASP solver is selected, extreme value normalization is performed on multiple single-objective optimization functions, based on the formula... Construct a comprehensive optimization objective function, where, To comprehensively optimize the objective function, S represents the feasible solution, and m represents the number of optimization objectives. These are the weighting coefficients. This is the normalized quantized value of the single objective function. During the search tree traversal process, a pruning strategy is used to prioritize the optimization objectives with high weights, and the optimal combination of component versions is output.

[0024] Furthermore, the conflict resolution closed-loop feedback process is triggered to generate a new set of constraints for secondary solution, including:

[0025] Based on the unsolvable results output by the constraint solver, reverse the logical statements to locate the conflict type and the core conflict component pair;

[0026] Match the target resolution strategy from the strategy library based on the conflict type and preset scenario priority;

[0027] Based on the target solution strategy, the global dependency graph is extended to generate an isolation domain subgraph, and a new constraint set is formed by dynamically adding a strategy constraint layer to the original logic statement. The new constraint set is then input into the constraint solver for secondary solution.

[0028] Furthermore, the strategy library stores containerization isolation strategies and source code compilation adaptation strategies;

[0029] When the target solution strategy is a containerized isolation strategy, an isolation domain subgraph is generated, and a strategy constraint layer is dynamically added to the original logic statement, including:

[0030] Create a separate container isolation domain node for one of the core conflicting component pairs in the global dependency graph;

[0031] The dependency constraints of the original conflicting components are converted into logical statements that take effect independently only within the container isolation domain node, and the global main environment is constrained to be unrelated to the container isolation domain node, so as to achieve decoupling of conflicting constraints.

[0032] Furthermore, after generating the acyclic installation sequence plan, it also includes:

[0033] The installation sequence plan is simulated and verified in all dimensions, including resource verification, network verification, and compatibility verification.

[0034] Once verified, the installation sequence plan will be converted into an installation instruction sequence that supports multiple execution vehicles, including Shell scripts, Ansible Playbooks, SaltStack configuration files, or Puppet configuration files.

[0035] Secondly, the present invention provides a multi-component installation planning system based on constraint solving, comprising:

[0036] The data acquisition module is used to obtain the list of components to be installed input by the user and to detect the target host environment information;

[0037] The dependency modeling module is used to collect metadata of multi-form components from multiple heterogeneous sources through a preset source adapter, and to perform unified modeling of the metadata to build a global dependency graph containing component nodes and directed edges with attributes.

[0038] The constraint transformation module is used to extract multi-dimensional constraints based on the global dependency graph, the list of components to be installed, and the target host environment information, and to formalize the multi-dimensional constraints into logical statements that the constraint solver can recognize.

[0039] The core solver module is used to call the constraint solver to solve the logical statement. If the solution is successful, it outputs the component version combination that satisfies all constraints.

[0040] The closed-loop feedback module is triggered when the constraint solver determines that there is no solution. It locates the conflict type and generates a new constraint set based on the target solution strategy. The new constraint set is then input into the core solver module for secondary solution.

[0041] The planning generation module is used to perform directed graph topology sorting based on feasible component version combinations and global dependency graphs to generate acyclic installation sequence plans.

[0042] Furthermore, the closed-loop feedback module is specifically used for:

[0043] Based on the unsolvable result output by the constraint solver, the core conflict component pair is located in reverse and an isolation domain subgraph is created for the core conflict component pair in the global dependency graph. The original conflict constraint is restricted to be effective only independently within the isolation domain subgraph, so as to resolve the logical contradiction.

[0044] Thirdly, the present invention provides a readable storage medium storing a computer program, the computer program including program code for controlling a process to execute the process, the process including the multi-component installation planning method based on constraint solving described above.

[0045] The main contributions and innovations of this invention are as follows:

[0046] 1. Significantly Improved Installation Success Rate and Deployment Efficiency: This invention constructs a global dependency graph before actual installation execution and utilizes constraint solving technology to predict global conflicts and automatically plan, thus resolving potential dependency issues in advance. This technique represents a fundamental shift from "passive fault tolerance" to "proactive planning." Testing has verified that the first-time success rate of complex application stack deployments can be increased from below 60% in traditional solutions to over 98%. Simultaneously, it effectively avoids repeated trial and error and system rollback during installation, reducing overall deployment time by over 70% and greatly improving the deployment efficiency of large-scale clusters.

[0047] 2. Enhanced System Security and Stability: This invention proactively avoids incompatible component versions and conflicting configurations, preventing the target host from entering an unstable or inconsistent intermediate state due to installation operations. Furthermore, this invention supports custom optimization goals (such as "maximizing system repository utilization"), which helps to strictly adhere to system security baselines, reduces security risks arising from the introduction of unreliable third-party components, and significantly lowers the system failure rate after deployment in the production environment.

[0048] 3. Provides flexible multi-scenario deployment strategies: This invention introduces a single / multi-objective optimization solution mechanism, and the system supports user-defined constraints. This allows users to flexibly adapt to the differentiated strategy requirements of production environments ("stability and high security"), testing environments ("innovation and rapid deployment"), and edge environments ("lightweight and low resource consumption") without developing customized deployment scripts for different business scenarios, significantly improving the system's versatility and adaptability.

[0049] 4. Significantly reduces operational complexity and skill threshold: Operations personnel only need to input installation requirements through a declarative manifest, eliminating the need for manual sorting and troubleshooting of complex underlying cross-source dependency chains. The system can automatically generate the optimal end-to-end installation solution, greatly reducing the operational complexity and skill threshold of automated operations and significantly alleviating the burden of operations and maintenance.

[0050] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0051] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0052] Figure 1 This is a block diagram of the overall architecture of a multi-component installation planning system based on constraint solving according to an embodiment of the present invention;

[0053] Figure 2This is a schematic diagram illustrating the construction of a unified dependency graph according to an embodiment of the present invention;

[0054] Figure 3 This is a flowchart of a multi-component installation planning method based on constraint solving according to an embodiment of the present invention;

[0055] Figure 4 This is an example diagram illustrating the end-to-end conversion process from a user list to an installation instruction according to an embodiment of the present invention. Detailed Implementation

[0056] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0057] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0058] This invention addresses the technical problems in existing Linux and other systems, such as the unpredictable global conflicts before installation due to complex dependencies and diverse component forms, and the lack of a globally optimal installation plan that satisfies multi-dimensional constraints. It proposes a multi-component installation planning method and system based on constraint solving.

[0059] I. System Architecture

[0060] like Figure 1 The diagram shown is a general architecture block diagram of the system of this invention. The system adopts a modular five-layer architecture design, comprising, from top to bottom: user interface layer, source adapter layer, core engine layer, planning and execution layer, and executor driver layer. Each layer is decoupled from the others through standardized interfaces.

[0061] Specifically, the source adapter layer includes system package adapters, container repository adapters, general file repository adapters, and local environment adapters. These adapters work together to form the foundation for data acquisition and modeling.

[0062] The core engine layer is the control center of the system, which includes a dependency graph builder, constraint manager, solver interface, and conflict closure module.

[0063] The planning execution layer includes a planning validator and an execution instruction generator, which together constitute the planning generation module, responsible for transforming abstract plans into executable instructions.

[0064] II. Method and Flow

[0065] like Figure 3 The diagram shown is the main flowchart of the multi-component installation planning method based on constraint solving according to the present invention. Combined with... Figures 1 to 4 The method specifically includes the following steps:

[0066] Step S1: Obtain the list of components to be installed input by the user and detect the target host environment information.

[0067] The system receives a component list written by the user in YAML format through the user interface layer. The list includes information such as component identifiers, expected version ranges, and configuration preferences. At the same time, the system probes the target host's existing components, kernel version, disk space, and memory environment information through the local environment adapter in the source adapter layer. The target host's local environment is treated as a special "data source" for unified access, serving as the basis for environmental constraints.

[0068] Step S2: Collect metadata of multi-form components from multiple heterogeneous sources through a preset source adapter, and perform unified modeling on the metadata to construct a global dependency graph containing component nodes and directed edges with attributes.

[0069] like Figure 2 As shown, this invention breaks through the limitations of the single form of traditional package managers. For system packages, relationships are extracted from the Depends and Conflicts fields of the package manager; for container images, application-layer dependencies are extracted from image metadata tags and dependency files; for binary compressed packages, dependencies are detected through dynamic linking detection tools; and for source code compilation artifacts, compilation dependencies are extracted from the build script.

[0070] The system employs a multi-threaded parallel strategy with flow control to pull metadata from multiple sources and uniformly converts it into an internal representation based on Protobuf, JSON, or XML to construct a global dependency graph. This graph is stored using an adjacency list structure. Each component version is abstracted as a unique component node. Component nodes contain a component ID, form type, resource attributes (such as disk usage and memory requirements), and a version quantization value field. The version quantization value is the result of converting semantic version numbers (such as major.minor.revision) into numerical values ​​(e.g., converting version 2.3.1 to 20301), allowing subsequent solvers to perform efficient numerical comparison calculations. Relationships between components are abstracted as directed edges with attributes. Directed edges contain relationship types (such as DEPEND, CONFLICT, PROVIDE, REPLACE), version constraint rules (such as GREATER_EQUAL), and mandatory attribute fields.

[0071] Preferably, the system also supports a timestamp-based incremental synchronization mechanism, which only fetches metadata that is newer than the local cache, in order to reduce network overhead.

[0072] Step S3: Extract multi-dimensional constraints based on the global dependency graph, the list of components to be installed, and the target host environment information, and formalize the multi-dimensional constraints into logical statements that can be recognized by the constraint solver.

[0073] The constraint manager extracts three types of constraints: basic constraints extracted from the relationship graph, user constraints extracted from the inventory, and environmental constraints extracted from the environment detection results. Subsequently, propositional logic is used to convert these constraints into logical statements that the solver can process. For simple scenarios (few components), constraints are converted into Conjunctive Normal Form (CNF) inputs to the SAT solver; for complex scenarios, they are converted into logical facts and rules inputs to the ASP solver.

[0074] Specifically, when using the SAT solver, the system needs to encode the discrete version range requirements into conjunctive normal form (CNF). The system first extracts the actual set of discrete versions of the component in the source, mapping each "component-version" pair to a unique Boolean variable. The encoding process includes uniqueness constraints and range constraints:

[0075] For example, suppose component C has a version set {2.0, 2.1, 2.2, 2.3} with incrementing quantized values, and the corresponding Boolean variable is... , , and If a user or dependency proposes a range constraint of "version >= 2.1", the system first filters out the valid version set {2.1, 2.2, 2.3} that meets the condition, and generates an existence clause. If the range constraint is "version < 2.2", then generate a clause. If it is a fixed version "==2.2", then a single variable clause will be generated directly. At the same time, it retains all mutual exclusion clauses between versions, thus accurately transforming complex version range matching into pure Boolean algebra operations that the SAT solver can efficiently process.

[0076] Step S4: Call the constraint solver to solve the logic statement. If the solution is successful, output the component version combination that satisfies all constraints.

[0077] To achieve multi-objective optimization (such as "maximizing system repository usage" and "minimizing total download size"), the system pre-defines various quantization and normalization rules for single-objective optimization functions. These include:

[0078] For the objective of "maximizing system repository usage", the quantization function is defined as the ratio of the number of system repository components to the total number of components, and maximum normalization is applied; for the objective of "minimizing total download size", the quantization function is defined as the sum of the download sizes of each component, and minimum normalization is applied; for the objective of "maximizing component version number", the quantization function is defined as the sum of the ratios of the selected version quantization value to the highest version quantization value in the source, and maximum normalization is applied; for the objective of "minimizing the number of containers used", the quantization function is defined as the number of components deployed using containerization, and minimum normalization is applied.

[0079] When the ASP solver is selected, the system performs extremum normalization on multiple single-objective optimization functions, based on the formula:

[0080]

[0081] Construct a comprehensive optimization objective function. Among them, To comprehensively optimize the objective function, S represents the feasible solution, and m represents the number of optimization objectives. These are the weighting coefficients. This is the quantized value of the normalized single-objective function.

[0082] During the search tree traversal of the solver, the system pre-calculates the pruning threshold corresponding to the high-weight objective and directly prunes the search branches that do not meet the pruning threshold, thereby selecting the optimal component version combination that maximizes the comprehensive optimization objective function from all feasible solutions.

[0083] Step S5: If the solution is determined to be unsolvable, a conflict resolution closed-loop feedback process is triggered to generate a new set of constraints for secondary solution, until a feasible combination of component versions is obtained.

[0084] When the constraint solver outputs a UNSAT result, the conflict closure-loop handling module is triggered, executing the following closed-loop feedback process:

[0085] Conflict localization: Traverse the logical statements in reverse order, match the predefined conflict feature library (such as VER_MUTEX indicating version mutual exclusion), and locate the core conflict component pairs.

[0086] Strategy matching: Based on the conflict type and preset scenario priority, match the target resolution strategy (such as containerization isolation strategy or source code compilation adaptation strategy) from the strategy library.

[0087] Constraint Refactoring: Taking containerization isolation strategy as an example, the system creates an independent container isolation domain node for one of the core conflicting component pairs in the global dependency graph. Then, a strategy constraint layer is dynamically added to the original logical statement, converting the dependency constraints of the original conflicting components into logical statements that only take effect within this container isolation domain node, and constraining the global main environment to be unrelated to this container isolation domain node.

[0088] Secondary solution: After generating a new set of constraints, it is input into the constraint solver for secondary solution, thereby achieving fully automatic decoupling of logical contradictions until a feasible solution is obtained.

[0089] Preferably, the strategy library also has preset strategy execution priorities, and the system tries matching strategies in descending order of priority until a feasible solution is found.

[0090] Step S6: Based on the component version combination and the global dependency graph, perform directed graph topology sorting to generate an acyclic installation sequence plan.

[0091] After obtaining a solvable combination of component versions, the planning validator performs a directed graph topology sort based on the Kahn algorithm. It first installs the dependent base component, then installs the upper-level components that depend on it. If a deadlock loop caused by a circular dependency is detected during the topology sorting phase, it is fed back as an anomaly signal to the conflict loop handling module, which decouples the components within the loop by dividing them into independent isolation units.

[0092] Subsequently, the system performs comprehensive simulation verification, including resource verification, network verification, and compatibility verification. This simulates the execution process at the logical level to proactively identify runtime risks. Once verification is successful, the execution instruction generator converts the installation sequence plan into installation instructions that support multiple execution platforms (such as Ansible Playbooks or Shell scripts), and sends them to the executor driver layer for execution.

[0093] To demonstrate the feasibility and superiority of the multi-dimensional constraint solution and closed-loop feedback decoupling technology of this invention, two specific embodiments are provided below:

[0094] Example 1: Deployment Scenario for Multi-Objective Optimization Solution

[0095] This embodiment relates to the automated deployment of a data analysis platform on a target host. Components include a web server, Python applications (dependent on specific versions of pandas and numpy), and a cache. User constraints are: maximize system package usage (with a weighting factor w1=0.6) and minimize the total download size (with a weighting factor w2=0.4).

[0096] The data acquisition module obtained different versions of the aforementioned components from the source repository. Among them, the highest version of pandas in the source repository (1.4.2, quantization value 10402) does not meet the user-defined numerical range constraint of ">=1.5.0" (quantization threshold 10500).

[0097] The constraint formalization process is shown below (using the Prolog rule code of the ASP solver as an example):

[0098] % Component version declaration and quantitative value mapping

[0099] version("c_pandas", "1.4.2", 10402).

[0100] version("c_pandas", "1.5.3", 10503).

[0101] % Rule: select pandas version>= 1.5.0 (quantify threshold: 10500)

[0102] select("c_pandas", V_id) :- version("c_pandas", V_id, Q_val), Q_val>=10500.

[0103] During the solution process, the system automatically performs extreme value normalization and weighted calculation. Assume there are two feasible solution branches in the search tree: feasible solution S1 uses 3 system packages and 1 third-party compatibility package, with a total download size of 200MB; feasible solution S2 uses 2 system packages and 2 third-party packages, with a total download size of 100MB.

[0104] For the objective O1 (maximizing system repository usage), its maximum value of 0.75 and minimum value of 0.5 are pre-calculated, and the normalization function is as follows: For the objective O2 (minimizing the total download size), its maximum value of 200 and minimum value of 100 are pre-calculated, and the normalization function is: .

[0105] Substitute into the formula Calculations are performed for S1, and its... and The overall score was 0.6; for S2, its... and The overall score was 0.4. Therefore, the solver, through rigorous numerical comparison, outputs S1, which has the higher overall score, as the optimal hybrid version combination.

[0106] Based on the multi-objective optimization formula, the solver identified a path that fully utilizes system packages, where the pandas version could not meet the constraints. The solver adaptively adjusted its branches, ultimately outputting the mixed version combination with the highest overall score: nginx, redis, and numpy used the system package repository versions, while pandas used a third-party repository compatible version (1.5.3). Subsequently, topology sorting was performed to generate an installation plan, avoiding dependency breakage caused by forced installation.

[0107] Example 2: Unresolved Conflict Closed-Loop Handling Scenario Based on Containerized Isolation Strategy

[0108] This example involves complex version conflicts. The list of applications to be installed includes application App-A (which depends on the libfoo library and its version must be greater than or equal to 20000) and application App-B (which depends on the libfoo library and its version must be less than 20000).

[0109] In step S4, the constraint solver determines that irreconcilable mutual exclusion logic exists during processing and outputs an UNSAT signal. The conflict closure module is then triggered and performs the following actions:

[0110] 1. Feature matching determines version mutual exclusion (VER_MUTEX), and the core conflicting component pair is:<App-A, libfoo> =2.0> and <App-B, libfoo<2.0> .

[0111] 2. Based on the host environment (the presence of the Docker engine was detected), the optimal solution is "containerization isolation strategy".

[0112] 3. In the adjacency list in memory, generate independent isolation domain nodes for App-B and its dependent libfoo (with the ID prefixed with container_).

[0113] 4. Dynamically generate logical statements for the policy constraint layer, thereby localizing the constraints of the isolation domain:

[0114] % Isolation domain scope rule: App-B in container must selectcontainer_libfoo

[0115] :- select("container_app_b", V1), not select("container_libfoo", V2).

[0116] % Decoupling global main environment from isolation domain

[0117] :- select("main_app_a", V1), select("container_app_b", V2), conflict_detected("main", "container").

[0118] The new constraint set, with the added policy constraint layer, is input into the solver for a second solution. At this point, the logical mutual exclusion is broken, and the system successfully outputs a version combination containing both the main environment component and the isolation domain component. Subsequently, topology sorting plans the installation action of App-B as an independent image building and container startup task, which is executed in parallel with the host machine installation task of App-A.

[0119] As can be seen from the above specific implementation methods, this invention transforms complex automated operation and maintenance experience into rigorous mathematical models and logical calculations through unified modeling and constraint solving technology, realizing a paradigm shift from "passive fault tolerance" to "active planning", and possessing high technological innovation and industrial application value.

[0120] Example 3

[0121] This embodiment also provides a readable storage medium storing a computer program, the computer program including program code for controlling a process to execute the process, the process including the multi-component installation planning method based on constraint solving described above.

[0122] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0123] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0124] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted in this respect that, as Figure 3 Any box in the logical flow can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0125] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0126] The above embodiments are merely illustrative of several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the appended claims.

Claims

1. A multi-component installation planning method based on constraint solving, characterized in that, Includes the following steps: Obtain the list of components to be installed as input by the user, and detect the target host environment information; Metadata of multi-form components is collected from multiple heterogeneous sources through a preset source adapter, and the metadata is uniformly modeled to construct a global dependency graph containing component nodes and directed edges with attributes. Based on the global dependency graph, the list of components to be installed, and the target host environment information, multi-dimensional constraints are extracted, and the multi-dimensional constraints are formalized into logical statements that can be recognized by the constraint solver. The constraint solver is invoked to solve the logical statement. If the solution is successful, the component version combination that satisfies all constraints is output. If the solution is determined to be unsolvable, a conflict resolution closed-loop feedback process is triggered to generate a new set of constraints for a second solution until a feasible component version combination is obtained. Based on the component version combination and the global dependency graph, a directed graph topology sort is performed to generate an acyclic installation sequence plan. The installation sequence plan is then subjected to full-dimensional simulation verification, including resource verification, network verification, and compatibility verification. After successful verification, the installation sequence plan is converted into an installation instruction sequence that supports multiple execution carriers, including Shell scripts, Ansible Playbooks, SaltStack configuration files, or Puppet configuration files. The step of calling the constraint solver to solve the logical statement further includes: Define the quantitative optimization objective function; Based on the number of components to be installed and the number of constraints, adaptively select the SAT solver or the ASP solver; If the ASP solver is selected, extreme value normalization is performed on multiple single-objective optimization functions, and based on the formula... Construct a comprehensive optimization objective function, where, To comprehensively optimize the objective function, S represents the feasible solution, and m represents the number of optimization objectives. These are the weighting coefficients. The normalized single-objective function quantization value is used, and during the search tree traversal process, the optimization objective with high weight is prioritized through pruning strategy, and the optimal combination of component versions is output. If the SAT solver is selected, the discrete version range requirement is encoded as conjunctive normal form; The process of triggering a conflict resolution closed-loop feedback flow to generate a new set of constraints for secondary solution includes: Based on the unsolvable results output by the constraint solver, the logic statements are traversed in reverse to locate the conflict type and the core conflict component pair; Based on the conflict type and preset scenario priority, a target resolution strategy is matched from the strategy library; Based on the target solution strategy, the global dependency graph is expanded to generate an isolation domain subgraph, and a strategy constraint layer is dynamically added to the original logical statement to form the new constraint set. The new constraint set is then input into the constraint solver for secondary solution. The strategy library stores containerization isolation strategies and source code compilation adaptation strategies. When the target solution strategy is the containerized isolation strategy, the step of generating the isolation domain subgraph and dynamically adding a strategy constraint layer to the original logic statement includes: In the global dependency graph, create an independent container isolation domain node for one of the core conflicting component pairs; The dependency constraints of the original conflicting components are converted into logical statements that take effect independently only within the container isolation domain node, and the global main environment is constrained to be unrelated to the container isolation domain node, so as to achieve decoupling of conflicting constraints.

2. The multi-component installation planning method as described in claim 1, characterized in that, The multi-form components include system software packages, container images, binary compressed packages, and source code compilation artifacts; Metadata of multi-form components is collected from multiple heterogeneous sources through a preset source adapter, and the metadata is uniformly modeled to construct a global dependency graph containing component nodes and directed edges with attributes, including: A multi-threaded parallel strategy with flow control is used to pull the metadata from the system software repository, container repository, and general file repository. Extract the component identifier, version and dependency information from the metadata, convert the components of different forms into a standardized data structure as the component nodes, and convert the dependency, conflict, provision and replacement relationships between components into the attributed directed edges.

3. The multi-component installation planning method as described in claim 2, characterized in that, The global dependency graph is stored using an adjacency list structure; The component node includes a component ID, version quantization value, form type and resource attribute fields, and the version quantization value is the result of converting the semantic version number into a numerical value. The attributed directed edges include relation type, version constraint rules, and mandatory attribute fields.

4. A multi-component installation planning system based on constraint solving, characterized in that, include: The data acquisition module is used to obtain the list of components to be installed input by the user and to detect the target host environment information; The dependency modeling module is used to collect metadata of multi-form components from multiple heterogeneous sources through a preset source adapter, and to perform unified modeling of the metadata to construct a global dependency graph containing component nodes and directed edges with attributes. The constraint transformation module is used to extract multi-dimensional constraints based on the global dependency graph, the list of components to be installed, and the target host environment information, and to formalize the multi-dimensional constraints into logical statements that can be recognized by the constraint solver. The core solving module is used to call the constraint solver to solve the logic statement. If the solution is successful, it outputs the component version combination that satisfies all constraints. The closed-loop feedback module is triggered when the constraint solver determines that there is no solution, locates the conflict type, generates a new constraint set based on the target resolution strategy, and inputs the new constraint set into the core solver module for secondary solution. The planning generation module is used to perform directed graph topology sorting based on feasible component version combinations and the global dependency graph, generate acyclic installation sequence planning, and perform full-dimensional simulation verification of the installation sequence planning, including resource verification, network verification, and compatibility verification. After successful verification, the installation sequence plan is converted into an installation instruction sequence that supports multiple execution carriers, including Shell scripts, Ansible Playbooks, SaltStack configuration files, or Puppet configuration files. The step of calling the constraint solver to solve the logical statement further includes: Define the quantitative optimization objective function; Based on the number of components to be installed and the number of constraints, adaptively select the SAT solver or the ASP solver; If the ASP solver is selected, extreme value normalization is performed on multiple single-objective optimization functions, and based on the formula... Construct a comprehensive optimization objective function, where, To comprehensively optimize the objective function, S represents the feasible solution, and m represents the number of optimization objectives. These are the weighting coefficients. The normalized single-objective function quantization value is used, and during the search tree traversal process, the optimization objective with high weight is prioritized through pruning strategy, and the optimal combination of component versions is output. If the SAT solver is selected, the discrete version range requirement is encoded as conjunctive normal form; The process of triggering a conflict resolution closed-loop feedback flow to generate a new set of constraints for secondary solution includes: Based on the unsolvable results output by the constraint solver, the logic statements are traversed in reverse to locate the conflict type and the core conflict component pair; Based on the conflict type and preset scenario priority, a target resolution strategy is matched from the strategy library; Based on the target solution strategy, the global dependency graph is expanded to generate an isolation domain subgraph, and a strategy constraint layer is dynamically added to the original logical statement to form the new constraint set. The new constraint set is then input into the constraint solver for secondary solution. The strategy library stores containerization isolation strategies and source code compilation adaptation strategies. When the target solution strategy is the containerized isolation strategy, the step of generating the isolation domain subgraph and dynamically adding a strategy constraint layer to the original logic statement includes: In the global dependency graph, create an independent container isolation domain node for one of the core conflicting component pairs; The dependency constraints of the original conflicting components are converted into logical statements that take effect independently only within the container isolation domain node, and the global main environment is constrained to be unrelated to the container isolation domain node, so as to achieve decoupling of conflicting constraints.

5. The multi-component installation planning system according to claim 4, characterized in that, The closed-loop feedback module is specifically used for: Based on the unsolvable result output by the constraint solver, the core conflict component pair is located in reverse, and an isolation domain subgraph is created for the core conflict component pair in the global dependency graph. The original conflict constraint is restricted to be effective independently only within the isolation domain subgraph to resolve the logical contradiction.

6. A readable storage medium, characterized in that, The readable storage medium stores a computer program, the computer program including program code for controlling a process to execute the process, the process including the multi-component installation planning method according to any one of claims 1 to 3.

Images