Component tuning method and device

Abstract

The invention discloses a component tuning method and device. The method comprises the following steps: determining an application model corresponding to a target component, and extracting an expected state and a current state of the target component from the application model; under the condition that the expected state is inconsistent with the current state, generating a tuning operation according to the expected state and the current state, and mapping the tuning operation into at least one tuning step; and constructing a tuning workflow based on the tuning step, and executing the tuning workflow by utilizing a runtime engine. According to the scheme, accurate calibration and dynamic optimization of the component state are realized through real-time analysis and automatic tuning of the component state, so that the application stability and the operation efficiency are improved, the manual intervention and debugging cost are reduced, and flexible expansion and parallel tuning of multiple components and multiple environments are supported.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a component tuning method and apparatus. Background Technology

[0002] In enterprise application management platforms, with the advancement of public-private network merging and service unitization, secondary application deployment platforms based on private networks face complex requirements such as cross-operation and maintenance platform deployment, multi-cluster management, and service self-healing.

[0003] Existing technologies typically employ traditional application management platform implementations, highly coupling application deployment logic with code projects. They lack a unified application model and runtime state abstraction, relying on different configuration methods for different runtime environments, resulting in limited tuning and adaptive capabilities for application runtime states. When application scales up or runtime environments change, the system falls short in scalability, maintainability, and cross-environment adaptability, failing to meet the demands for flexible deployment and efficient operation and maintenance in enterprise-level scenarios. Summary of the Invention

[0004] This application provides a component tuning method and apparatus, solving the problems of low efficiency and difficulty in adapting to cross-operation and maintenance environments in existing technologies. The method obtains the application model of the target component, extracts its desired state and current state; when the two are inconsistent, a tuning operation is generated and a tuning workflow is constructed, which is executed by the runtime engine. This method can achieve efficient tuning and automatic recovery across operation and maintenance platforms and multi-cluster environments while ensuring component state consistency and system stability. It is suitable for enterprise-level application deployment management, multi-component collaborative optimization, and dynamic runtime tuning scenarios.

[0005] In a first aspect, this application provides a component tuning method, including: Determine the application model corresponding to the target component, and extract the desired state and current state of the target component from the application model; In the case where the desired state and the current state are inconsistent, a tuning operation is generated based on the desired state and the current state, and the tuning operation is mapped to at least one tuning step. A tuning workflow is constructed based on the tuning steps, and the tuning workflow is executed using a runtime engine.

[0006] Secondly, this application provides a component tuning device, comprising: The state extraction module is used to determine the application model corresponding to the target component and extract the expected state and current state of the target component from the application model. A tuning operation module is configured to generate a tuning operation based on the desired state and the current state when the desired state and the current state are inconsistent, and to map the tuning operation to at least one tuning step. The tuning execution module is used to construct a tuning workflow based on the tuning steps and execute the tuning workflow using a runtime engine.

[0007] Thirdly, this application provides a component tuning device, comprising: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the component tuning method as described in the first aspect.

[0008] Fourthly, this application provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the component tuning method as described in the first aspect.

[0009] In this application, a component operation tuning mechanism based on state difference recognition and operation link-driven mechanism is constructed, achieving accurate state perception of the target component, automatic derivation of tuning logic, and integrated execution of the tuning process. In the component tuning process, the application model corresponding to the target component is used as input. First, the application model is parsed to extract the desired state and current state of the target component. Based on the state comparison results, it is identified whether there is a tuning requirement, thereby achieving unified modeling and difference-driven operation of the component's operating state. After detecting a deviation between the desired state and the current state, the tuning operation is further automatically deduced based on the state difference, and the tuning operation is decomposed and mapped into at least one tuning step with atomic execution to construct a clear and executable tuning instruction set. Subsequently, a tuning workflow is generated based on the relationships between each tuning step to characterize the execution order and concurrency of the tuning behavior. Finally, the runtime engine schedules and executes the tuning workflow to complete the dynamic tuning of the target component. This solution significantly improves the automation and controllability of the component tuning process through the collaborative design of state-driven and workflow orchestration, and is suitable for enterprise-level application deployment management, multi-component collaborative optimization, and dynamic runtime tuning scenarios. Attached Figure Description

[0010] Figure 1 This is a flowchart of a component tuning method provided in an embodiment of this application; Figure 2 This is a flowchart of a component deployment method provided in an embodiment of this application; Figure 3 This is a flowchart of an application model mapping method provided in an embodiment of this application; Figure 4This is a flowchart of a method for obtaining the state of a multi-center component provided in an embodiment of this application; Figure 5 This is a flowchart of a multi-center component state matching method provided in an embodiment of this application; Figure 6 This is a flowchart of a component state correction method provided in an embodiment of this application; Figure 7 This is a flowchart of a component exponential backoff and retry method provided in an embodiment of this application; Figure 8 This is a structural block diagram of a component tuning device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a component tuning device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as being processed sequentially, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. A process can be terminated when its operation is completed, but it may also have additional steps not included in the drawings. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0012] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0013] Currently, as enterprise application architectures evolve from monolithic deployments to multi-cluster collaboration and public-private network convergence, improving deployment flexibility and service self-healing capabilities while ensuring stability has become a core technical issue for application management platforms. Existing platforms primarily develop along two technical paths: one is to highly couple deployment logic with the application management platform, driving application lifecycle management through a unified codebase; the other relies on an underlying operations and maintenance platform to control container deployment, completely decentralizing runtime maintenance. The former incurs high transformation costs and maintenance risks in multi-cluster and uninterrupted expansion; the latter lacks runtime tuning and self-healing capabilities, making it difficult to handle abnormal scenarios and resulting in insufficient service autonomy.

[0014] In addition, existing platforms generally adopt a synchronous blocking deployment strategy and rely on periodic polling to obtain task status. This mechanism cannot provide timely feedback on abnormal states, causing services to remain in the "deploying" state for extended periods when errors occur. This not only increases the cost of operation and maintenance troubleshooting but also severely impacts user experience. Furthermore, due to the lack of a unified application description model, different configuration formats are still required in different operation and maintenance environments, further exacerbating debugging difficulties and scalability deficiencies.

[0015] To address the shortcomings of existing enterprise application management platforms in multi-cluster deployment, cross-operation and maintenance platform management, and service self-healing capabilities, this embodiment provides a component tuning method. By introducing a state difference identification and tuning workflow-driven mechanism, an intelligent runtime management system with the ability to automatically perceive component states and efficiently generate tuning operations is constructed, realizing accurate state analysis of target components, automatic generation of tuning operations, and sequential execution of tuning steps.

[0016] This method takes the application model corresponding to the target component as input. First, it parses the application model to extract the desired and current states of the target component. Based on the state comparison results, it identifies whether there are tuning requirements, thus ensuring unified modeling of the component's running state and the desired state. After detecting a deviation between the desired and current states, it automatically generates tuning operations based on the state differences and decomposes and maps these operations into at least one tuning step with atomic execution, thus fully characterizing the tuning execution unit. Subsequently, a tuning workflow is constructed based on the relationships between each tuning step to characterize the execution order and concurrency of tuning behaviors. Finally, the runtime engine schedules and executes this tuning workflow to achieve dynamic adaptive tuning of the target component. This solution, through a collaborative mechanism of state difference-driven parsing, operation decomposition and mapping, and workflow execution, effectively reduces manual intervention by operations personnel during multi-cluster deployments and container recovery, significantly improving the automation and reliability of component tuning. Furthermore, this method has good scalability, can be integrated with multiple operations platforms, and supports adaptive tuning strategies for different environments, providing key technical support for achieving efficient, low-risk, and maintainable enterprise-level application operation and management.

[0017] This application provides an architecture diagram of a layered decoupling system. The layered decoupling system includes a data access layer, a data parsing layer, a domain layer, a deployment strategy layer, and a deployment capability layer.

[0018] In one embodiment, the data access layer achieves comprehensive adaptation to data integration needs at different stages and in different scenarios by constructing a multi-layered, multi-mode data access mechanism. The data access layer can provide data retrieval methods based on periodic triggers, such as scheduled task triggers, triggers at specified times, event-driven triggers, and priority scheduling triggers, to address the rapid integration needs of application engines. The data access layer supports publish / subscribe asynchronous listening mechanisms and synchronous push modes to adapt to the data access scenarios of open platforms, achieving a balance between real-time performance and reliability. The data access layer provides standardized data access interfaces and command-line tools to meet the standardized integration needs of enterprise-level systems and third-party applications. Through multi-mode access strategies, the data access layer can balance rapid deployment, real-time interaction, and standardized expansion, providing solid support for the efficient operation of subsequent data processing, business analysis, and platform services. The data parsing layer achieves standardization and high controllability of internal system data processing by constructing an isolation mechanism between the access layer and the domain layer. The data parsing layer includes two core components: a data parser and a task queue. The data parser is responsible for converting external data provided by the access layer into a unified model format within the system, effectively shielding the core domain logic from the impact of external system changes and ensuring the consistency and stability of domain layer processing. The task queue buffers and manages the parsed data, ensuring the system's robustness and processing capacity under high concurrency or sudden traffic surges. Through the collaborative work of the data parser and task queue, the data parsing layer decouples external data access from core domain logic processing, providing key technical support for the system's high reliability, scalability, and continuous operation. The domain layer is built based on domain-driven design principles, achieving a high degree of abstraction and unified management of application logic and deployment operations. The domain layer abstracts enterprise-level applications into data models to uniformly describe application objects and their attributes, achieving a structured expression of application states, dependencies, and operational goals. Simultaneously, it abstracts deployment operations into directed acyclic graph workflows to depict the relationships and execution order between operation steps, achieving standardized modeling of complex deployment processes. Through the collaborative application of data models and workflows, the domain layer provides a unified object description language, effectively supporting application state management and scheduling execution, and providing core technical support for the system's scalability, maintainability, and general adaptability across different operational platforms. The deployment strategy layer, by constructing a state-driven tuning mechanism, achieves dynamic consistency management between the expected and actual states during application deployment. The deployment strategy layer provides core tuning capabilities, responsible for perceiving the expected and operational states of target components and generating tuning operations to achieve automatic repair when discrepancies exist. Simultaneously, the deployment strategy layer intelligently selects the most suitable deployment strategy based on the characteristics and constraints of the current deployment environment, thereby ensuring that deployment operations in multi-cluster and multi-operational platform environments are both efficient and reliable.Through a collaborative mechanism of state awareness, strategy selection, and automatic tuning, the deployment strategy layer not only enhances the system's self-healing capabilities and operational stability but also provides core technical support for the elastic scaling and continuous availability of enterprise applications. The deployment capability layer achieves compatibility and unified management of multiple operation and maintenance platforms by constructing a unified deployment interface across the operation and maintenance infrastructure. The deployment capability layer provides standardized interfaces for scheduling and managing various underlying operation and maintenance platforms, including ksops, Docker, and Kubernetes, thereby achieving consistent deployment and control capabilities across platforms. By abstracting underlying differences through a unified interface, the deployment capability layer not only simplifies deployment operations across multiple environments and platforms but also provides a stable and reliable execution foundation for the upper deployment strategy layer and domain layer, ensuring that enterprise applications can efficiently and controllably complete deployment and management tasks in complex operation and maintenance environments.

[0019] The component tuning method presented in this application operates at the domain layer and the deployment strategy layer. Figure 1 A flowchart of a component tuning method provided in an embodiment of this application is given. (Reference) Figure 1 The tuning method for this component specifically includes: S110. Determine the application model corresponding to the target component, and extract the desired state and current state of the target component from the application model.

[0020] In some embodiments, the target component may be an independent software module in the system that needs to be tuned or managed, the application model may be a structured description of the target component's metadata, specifications and state management, the expected state may be the expected operating state of the target component under the current environment configuration, and the current state may be the actual operating state of the component under the current environment configuration.

[0021] In one embodiment, the application model can be determined by querying the metadata and specifications of the target component through the system registry or configuration management center, and then determining the application model corresponding to the target component from the metadata and rule descriptions of the target component.

[0022] In one embodiment, the expected state can be extracted by reading the expected state of the component from the expected state field in the application model and determining the read expected state as the expected state of the target component.

[0023] In one embodiment, the current state can be extracted by obtaining the actual state information of the component through a runtime state acquisition interface, and then determining the obtained actual state information as the current state of the target component. The current state may include health check results, replica count, and other dimensional data that can be used for state determination.

[0024] In one embodiment, the desired state and the current state may include four core states: Up, Down, HalfUp, and Unknown. Up indicates that the component is in a running state, Down indicates that the component is offline, HalfUp indicates that the component is partially running, and Unknown indicates that the component is in an unknown state.

[0025] In one embodiment, this step lays the data foundation for subsequent automatic tuning, strategy adjustment, or anomaly handling when the expected state is inconsistent with the current state. This enables the system to perform targeted processing based on clear state deviations, thereby reducing the need for manual intervention and improving the automation level and overall stability of component operation management.

[0026] Figure 2 A flowchart of a component deployment method provided in an embodiment of this application is given. Before the runtime engine performs component tuning, it needs to deploy the component first. (Reference) Figure 2 The specific deployment method for this component includes: S101. Obtain the external application data of the target component and map the external application data into an application model.

[0027] For example, external application data can be component description information provided by external systems or configuration sources, and the application model can be a structured data model used to standardize the representation of component information, specifications, and status attributes.

[0028] In one embodiment, external application data can be obtained by querying the original configuration data of the target component through an API interface, configuration file, or registry center, and then identifying the obtained original configuration data as external application data.

[0029] In one embodiment, mapping external application data to an application model can be achieved by filling the key-value items in the original configuration data into the metadata field, expected state field, and dependency field of the application model according to predefined model field rules, thereby realizing the mapping of the application model.

[0030] In one embodiment, this step provides a reliable data source for subsequently extracting the desired state and current state of the target component from the application model, enabling the desired state to truly reflect the actual needs of the external application for the component, and the current state to accurately reflect the component's performance under the drive of the external application, thereby improving the accuracy and adaptability of component state analysis, automatic tuning, and anomaly handling as a whole.

[0031] Figure 3A flowchart of an application model mapping method provided in an embodiment of this application is given. To achieve unified processing of heterogeneous external application data, it is necessary to map external application data into application models. (Reference) Figure 3 The application model mapping method specifically includes: S1011. Construct application metadata, application specification data, and application status data based on the external application data.

[0032] For example, external application data can be structured or semi-structured data from third-party systems, app store interfaces, or operation and maintenance platforms; application metadata can be the application's basic identifiers and static attributes; application specification data can characterize the application's capability boundaries and resource requirements; and application status data can be used to characterize the application's real-time or near-real-time status information during operation.

[0033] In one embodiment, the application metadata can be constructed by parsing application identifiers, version information, developer information, dependencies, and deployment environment tags from external application data, and performing field mapping and normalization processing according to a preset metadata model to form a standardized set of application metadata, which is then used as the application metadata.

[0034] In one embodiment, the application specification data can be constructed by extracting the functional modules, interface capabilities, resource quotas, performance metrics, and compatibility constraints supported by the application from external application data, and then combining this data with a specification template to generate the corresponding application specification data. The application specification data can be used to describe the application's functional scope and operational requirements.

[0035] In one embodiment, the application status data can be constructed by: aggregating and analyzing the running logs, monitoring metrics, or status callback information in external application data to determine the current running status, health status, and anomaly identifier of the application, and generating application status data in the form of a status model.

[0036] In one embodiment, the application metadata, application specification data, and application status data can be constructed by: extracting the application identifier, deployment environment, startup parameters, running strategy, expected state, current state, and runtime state from external application data; constructing application metadata based on the application identifier and deployment environment; constructing application specification data based on startup parameters and running strategy; and constructing application status data based on expected state, current state, and runtime state.

[0037] The application identifier can be the unique identification information of the target component, which may include the application name and application version. The deployment environment can be the target cluster or node range where the component runs, which may include tenant identifier, cluster identifier, tag system, and hash fingerprint. The startup parameters can be the configuration items required when the component starts, which may include the number of replicas, container image, startup parameters, port exposure, environment variables, and data volume mounting. The operation policy can be the processing rules of the component during scaling, restart, or abnormal recovery, which may include scheduling policy, release policy, health probe, and dependency declaration. The expected state can be the expected running state of the target component under the current environment configuration. The current state can be the actual state of the component in the current environment. The runtime state can be the real-time health information or monitoring indicators generated by the component during operation, which may include the runtime state snapshots of each Pod / Task, error codes, task IDs, timestamps of the most recent operation, first failure flags, retry counts, and circuit breaker status. The application metadata can be the basic attribute information used to identify the component's identity and its operating scope. The application specification data can be the configuration set that defines the component's startup method and running constraints. The application state data can be the state description information used to reflect the difference between the component's target state and its actual state.

[0038] In one embodiment, the method for extracting external application data may be: performing structured parsing on the external application data, mapping the key-value pairs in the original data to a preset field model, marking missing fields as items to be completed, and using the mapped and completed data as the extracted external application data.

[0039] In one embodiment, the application metadata can be constructed by combining the application identifier and the deployment environment into a key-value structure and writing it into the metadata field, and then using the generated metadata field as the application metadata.

[0040] In one embodiment, the application specification data can be constructed by mapping startup parameters to runtime configuration, mapping runtime policies to scheduling policy fields, and using runtime configuration and scheduling policy fields to construct application specification data.

[0041] In one embodiment, the application state data can be constructed by using the desired state as the target state field, the current state as the observed state field, and the runtime state as the health indicator field, and constructing the application state data using the target state field, the observed state field, and the health indicator field.

[0042] In one embodiment, this step lays a clear data foundation for the unified expression of the application model, enabling the application model to carry external application-related information in a modular and scalable manner. This facilitates the addition of new data dimensions or adaptation to different types of external applications, thereby improving the overall solution's versatility, maintainability, and long-term evolution capabilities.

[0043] S1012. Construct an application model based on the application metadata, the application specification data, and the application status data.

[0044] For example, the application model can be a standardized structure used to uniformly describe component identity attributes, runtime configuration, and state information.

[0045] In one embodiment, the application model can be constructed by writing application metadata into the metadata field of the model, writing application specification data into the specification field of the model, writing application status data into the status field of the model, and encapsulating the data using a preset data structure format to obtain the application model.

[0046] In one embodiment, by structuring external application data into application metadata, specification data, and status data, and further constructing an application model, the application information is standardized and uniformly described, providing a standardized data foundation for subsequent deployment and tuning, and enhancing the platform's scalability and cross-environment adaptability.

[0047] S102. Extract the desired state of the target component from the application model, and generate a deployment operation based on the desired state.

[0048] For example, the desired state can be the expected running state of the target component under the current environment configuration, and the deployment operation can be the execution instructions or control flow used to drive the component from the non-running state to the target running state.

[0049] In one embodiment, the desired state can be extracted by reading the target state identifier from the state field of the application model and using the target state identifier as the desired state of the target component.

[0050] In one embodiment, the deployment operation can be generated by: determining whether to execute a creation, startup, or expansion command based on the desired state value, writing the command into a list of tasks to be executed, and identifying the actions to be executed in the list of tasks to be executed as deployment operations.

[0051] In one embodiment, this step makes the deployment operation "verifiable". Subsequently, the generated deployment operation can be compared with the current state of the target component in a closed loop to determine whether the deployment has reached the expected state. If it has not, retry, rollback or compensation operations can be triggered, thereby improving the overall system reliability and maintainability.

[0052] S103. Construct a deployment workflow based on the deployment operation, and execute the deployment workflow using the runtime engine.

[0053] For example, a deployment workflow can be a sequence of deployment steps organized in a dependency order to guide the target component from an initial state to a desired state, and a runtime engine can be an underlying execution component used to schedule and control the execution of deployment steps.

[0054] In one embodiment, the deployment workflow can be constructed by breaking down the deployment operation into several atomic steps, such as component deployment, upgrade, delisting, and reset, and organizing each step into a directed acyclic graph structure according to the dependencies, and using the organized directed acyclic graph structure as the deployment workflow.

[0055] In one embodiment, the deployment workflow can be executed by having the runtime engine trigger each step sequentially or in parallel, and monitor the execution results and record state changes in real time.

[0056] In one embodiment, before determining the application model, external application data is mapped to the application model, and deployment operations and deployment workflows are generated based on the desired state. This unifies the deployment process with the runtime tuning process, enabling end-to-end automated management from initial deployment to runtime tuning, and improving deployment flexibility and controllability.

[0057] Figure 4 A flowchart of a method for obtaining the state of a multi-center component according to an embodiment of this application is provided. To achieve tuning of the state of the multi-center component, differentiated settings are needed for obtaining the state of the component at each center. (Reference) Figure 4 The method for obtaining the state of a multi-center component specifically includes: S1101. Obtain the target deployment mode of the target component and the environment center identifier of the current environment of the target component.

[0058] For example, the target deployment mode can be the deployment strategy of the component in a multi-center environment, such as active-active mode, primary-backup mode or multi-center mode, and the environment center identifier can be the code of the central environment in which the component is currently running.

[0059] In one embodiment, the target deployment mode can be obtained by reading the deployment strategy configuration from the specification field of the application model and using the read deployment strategy configuration as the target deployment mode.

[0060] In one embodiment, the method for obtaining the environment center identifier may be: identifying the identifier information of the current running center through system startup parameters or running environment variables, and using the identified identifier information as the environment center identifier.

[0061] In one embodiment, this step provides basic information for the subsequent construction of an auditable deployment path, enabling the system to clearly indicate in the deployment record "which deployment mode is used and which environment center it falls in", thereby improving the traceability of the deployment process and the efficiency of operation and maintenance troubleshooting, and reducing the probability of deployment failure due to environment identification errors or improper mode selection.

[0062] S1102. Match the desired state of the target component from the application model based on the target deployment mode and the environment center identifier.

[0063] For example, the target deployment mode can be the deployment strategy of the component in a multi-center environment, the environment center identifier can be the center code where the component is currently running, and the expected state can be the target running state that the component should achieve in the corresponding center environment under the current environment configuration.

[0064] In one embodiment, the method for matching the desired state may be: selecting the corresponding center priority rule according to the target deployment mode, retrieving the target state configuration that is consistent with the environment center identifier in the state field of the application model, and determining the matched target state configuration as the desired state of the target component.

[0065] In one embodiment, by obtaining the target deployment mode and current environment information of the target component and matching the desired state in the application model, the tuning operation can be precisely executed for the environment in which the component is located, ensuring the accuracy and consistency of component state management in multi-environment and multi-cluster scenarios.

[0066] Figure 5 A flowchart of a multi-center component state matching method provided in an embodiment of this application is given. Since similar components in multiple centers may have different expected states, it is necessary to match the state of the component at each center. (Reference) Figure 5 The multi-center component state matching method specifically includes: S11021. Extract the deployment center identifier and deployment status of at least one deployment center from the target deployment mode.

[0067] For example, the deployment center identifier can be the code of each center environment that can participate in the deployment, and the deployment status can be the running status configuration that the target component should achieve in the corresponding center environment.

[0068] In one embodiment, the method for extracting the deployment center identifier and deployment status can be as follows: perform structured parsing on the target deployment mode, take the list of centers in it as the deployment center identifier set, and take the running strategy or target status corresponding to each deployment center as the deployment status field corresponding to each deployment center identifier in the deployment center identifier set, thereby obtaining the deployment center identifier and deployment status.

[0069] In one embodiment, this step provides a structured benchmark for the closed-loop verification of subsequent deployment results. The system can record, compare, and audit the deployment execution status at the deployment center level, and drive subsequent processes such as graying, full deployment, rollback, and termination based on changes in deployment status, thereby enhancing the traceability, automation, and rapid handling capabilities of the deployment process in abnormal scenarios.

[0070] S11022. Based on the correspondence between the deployment center identifier and the deployment status, associate the target deployment status of the deployment center where the environment center identifier is located.

[0071] For example, the deployment center identifier can be the environment code of each deployable center, the deployment status can be the operating status that the target component should achieve in each center environment, and the target deployment status can be the specific status that the component of the center corresponding to the environment center identifier should achieve.

[0072] In one embodiment, the method for matching the target deployment status can be: traversing the deployment center identifier and deployment status mapping table, and taking the entry that matches the current environment center identifier as the target deployment status.

[0073] In one embodiment, by associating the environment center identifier with the target deployment state, the system can quickly restore the deployment context during deployment records, audit trails, and anomaly investigations, clarifying the expected deployment state of a certain environment center under the current deployment mode, thereby improving the traceability of the deployment process and the efficiency of operation and maintenance, and reducing the costs of rollback, compensation, and duplicate release caused by incorrect state association.

[0074] S11023. Extract the desired state of the target component from the target deployment state.

[0075] For example, the desired state can be the target operating state that a component should achieve in the current central environment under the current environment configuration.

[0076] In one embodiment, the desired state can be extracted by reading the corresponding running state value from the target deployment state field and using the read running state value as the desired state of the target component.

[0077] In one embodiment, the desired state is accurately extracted by establishing a mapping relationship between the deployment center identifier and the deployment state, and matching the target deployment state corresponding to the environment center. This mechanism can support state tuning in complex environments with multiple clusters and multiple deployment centers, improving the reliability and predictability of tuning operations.

[0078] S1103. Extract the current state of the target component from the application model.

[0079] For example, the current state can be the state of a component in its actual operating environment.

[0080] In one embodiment, the current state can be extracted by reading the current value of the state field in the application model and performing standardized parsing to obtain the current state of the target component. The current state of the target component can be used for subsequent tuning or deployment operations.

[0081] In one embodiment, this step enables the system to continuously observe the operational state of components, which can be used to build post-deployment verification and regression mechanisms. After performing the deployment operation, the current state is extracted again and compared with the expected state, thus forming a verifiable and traceable closed-loop governance process. This improves the reliability and operational efficiency of the deployment process and reduces the release risk caused by invisible state.

[0082] Figure 6 A flowchart of a component state correction method provided in an embodiment of this application is given. When the desired state and the environment configuration do not match, the desired state needs to be corrected. (Reference) Figure 6 The specific methods for correcting the state of this component include: S111. Determine the first policy snapshot corresponding to the target component, and extract the environmental feature identifier from the first policy snapshot.

[0083] For example, the first policy snapshot can be a static record of the scheduling policy and operation rules of the target component at a specific point in time, and the environment feature identifier can be environment feature information related to the deployment of the component, such as the operation center identifier, node configuration or other environment attributes.

[0084] In some embodiments, a policy snapshot may include a deployment policy number, and the component is deployed by matching the corresponding deployment policy according to the deployment policy number.

[0085] In one embodiment, the first policy snapshot can be determined by reading the policy record corresponding to the target component from the policy management module or configuration storage, and determining the read policy record as the first policy snapshot.

[0086] In one embodiment, the method for extracting environment feature identifiers may be: parsing the fields related to the deployment environment in the policy snapshot, and using the parsed center identifier, node information, and environment version number as environment feature identifiers.

[0087] In one embodiment, the combination of policy snapshots and environment feature identifiers provides a traceable basis for policy auditing and backtracking analysis. When deployment anomalies or state deviations occur, the system can quickly locate the policy version and its applicable environment at that time based on the policy snapshots and environment feature identifiers output in this step, thereby improving the efficiency of problem localization and reducing regression risks and operational costs during policy iteration.

[0088] S112. Obtain the environment configuration where the target component is located. If the environment configuration does not match the environment feature identifier, obtain the second policy snapshot corresponding to the environment configuration.

[0089] For example, the environment configuration can be the actual deployment information of the component's current running environment, including the central identifier, node specifications, and running version, etc., and the second policy snapshot can be a static record of the component scheduling policy and running rules for the current environment configuration.

[0090] In one embodiment, the environment configuration can be obtained by reading real-time information about the environment in which the component resides, such as the K8s cluster, K8s version, runtime engine, network capabilities, and storage capabilities, through a runtime monitoring interface or configuration management system, and using the obtained real-time information about the environment as the environment configuration.

[0091] In one embodiment, the method to determine whether the environment configuration matches the environment feature identifier can be: comparing whether the key fields in the environment configuration corresponding to the environment feature identifier match, such as comparing whether the key fields such as node specifications and environment version number match, and determining whether the environment configuration and environment feature identifier are consistent based on the matching results.

[0092] In one embodiment, the second policy snapshot can be obtained by querying the policy management module or configuration storage according to the current environment configuration, obtaining the policy record corresponding to the environment, and using the obtained policy record as the second policy snapshot.

[0093] In one embodiment, after determining that the environment configuration and environment feature identifier do not match, the corresponding optimal deployment strategy number can be selected based on the target environment information, and the deployment, upgrade or rollback process corresponding to the desired state of the optimal deployment strategy number can be executed.

[0094] S113. Extract the desired state from the second strategy snapshot as the desired state of the target component.

[0095] For example, the desired state can be the operational target state that the target component should achieve under the current environment configuration.

[0096] In one embodiment, the desired state can be extracted by reading the state fields from the second strategy snapshot and using these read state fields as the desired state of the target component. The field values ​​of the desired state can be mapped to the desired state fields of the application model for subsequent tuning or deployment operations.

[0097] In one embodiment, by comparing the policy snapshot with the environment configuration, a suitable policy snapshot can be dynamically selected as the desired state of the target component, thereby achieving adaptive tuning to environmental changes, enhancing the system's adaptability to changing operating environments, and improving service availability and self-healing capabilities.

[0098] S120. If the desired state and the current state are inconsistent, generate a tuning operation based on the desired state and the current state, and map the tuning operation to at least one tuning step.

[0099] In some embodiments, a tuning operation may be an operation that needs to be performed to bring a component state from its current state to a desired state, and a tuning step may be a specific sub-operation or execution unit in the process of a tuning operation.

[0100] In one embodiment, generating tuning operations can be achieved by comparing the desired state with the current state and determining operations such as creating, deleting, or restarting components based on the type of difference. For example, the Down→Up state is achieved by recreating the component; the HalfUp→Up state is achieved by restarting the component. A state detail recording mechanism is established during tuning operations, including detailed information such as task ID, error messages, and number of failures.

[0101] In one embodiment, mapping a tuning operation to tuning steps can be achieved by breaking down a single tuning operation into a sequence of executable steps, and using the resulting sequence of steps as tuning steps. Each tuning step corresponds to a specific runtime interface call or underlying platform operation.

[0102] In one embodiment, this step provides a structured foundation for process control and result verification of the tuning process. The system can perform execution monitoring, failure rollback and retry control at the granularity of the tuning steps, and re-collect the current state for verification after the step is completed, thereby forming a closed-loop tuning mechanism of "difference identification - step execution - state verification", which significantly improves the automation level, reliability and maintainability of component state governance.

[0103] S130. Construct a tuning workflow based on the tuning steps, and execute the tuning workflow using a runtime engine.

[0104] In some embodiments, the tuning workflow may be a sequence of tuning steps organized in a dependency order to guide the transition of component states from the current state to the desired state, and the runtime engine may be a system component for scheduling, controlling, and monitoring the execution of the tuning steps.

[0105] In one embodiment, the tuning workflow can be constructed by analyzing the prerequisite dependencies and execution order between each tuning step, organizing them into a directed acyclic graph (DAG), and the resulting DAG is the tuning workflow.

[0106] In one embodiment, the tuning workflow can be executed by having the runtime engine trigger each tuning step sequentially or in parallel, and track the execution results and status updates in real time.

[0107] In one embodiment, a tuning engine can be used to perform tuning steps. The tuning engine continuously monitors and tunes components whose desired state is "UP" and whose current state is not empty. By periodically checking the difference between the actual state and the desired state, the engine automatically performs necessary repair operations.

[0108] In one embodiment, by extracting the desired state and current state of the target component and generating tuning operations and tuning workflows based on the state differences, automated tuning and state consistency maintenance during component runtime can be achieved, improving the stability and reliability of the system in dynamic environments while reducing the cost of manual intervention.

[0109] Figure 7 A flowchart of a component exponential backoff retry method provided in an embodiment of this application is given. When a component fails to start or shut down, the retry time interval needs to be determined based on the number of shutdown failures. (Reference) Figure 7 The component's exponential backoff and retry method specifically includes: S131. If any of the tuning steps fails, obtain the failure count value of the failed step.

[0110] For example, a failed step can be a specific operation unit that failed to complete successfully in the tuning workflow, and the failure count can be the cumulative number of times that step failed.

[0111] In one embodiment, the failure count can be obtained by reading the failure count field of the corresponding step in the tuning workflow execution log or runtime status record, and using the value in the failure count field as the failure count. The failure count can be used for subsequent retries or exception handling.

[0112] In one embodiment, this step enables the tuning process to have stronger fault tolerance and adaptability. Through continuous updates of the failure count, the system can dynamically adjust the tuning rhythm and execution strategy, such as reducing concurrency, extending the retry interval, switching execution nodes, or changing the execution sequence, thereby improving the success rate and overall reliability of the tuning process in complex environments and reducing the operation and maintenance costs caused by rudimentary failure handling.

[0113] S132. Use the failure count as an exponent to calculate the retry time interval for the next retry of the failed step. If the retry time interval is reached, re-execute the failed step.

[0114] For example, the failure count value can be the cumulative number of failures of the failed steps, the retry interval can be the length of time to wait before retrying, and the failed step can be a specific operation unit that was not successfully completed in the tuning workflow.

[0115] In one embodiment, the retry interval can be calculated by using the failure count as an exponential base, calculating the retry interval according to an exponential backoff algorithm, and setting a maximum upper limit for the interval to prevent system overload. For example, a sequence of 1, 2, 4, 8, 16, and 32 minutes can be set. If this sequence is exceeded, the upper limit for the retry interval is limited to 4 hours to prevent excessive delays from affecting service availability. Before each retry, the current interval is calculated based on the historical number of failures and applied to the next scheduling attempt, thereby achieving a balance between quickly responding to short-term failures and suppressing the avalanche effect caused by persistent failures.

[0116] In one embodiment, the failed step can be re-executed by having the runtime engine re-trigger the execution of the step, while recording the new execution result and failure count.

[0117] In one embodiment, a failure step counting and exponential backoff mechanism is introduced to enable automatic retries for failed tuning steps, reducing system instability caused by occasional errors and improving the robustness and reliability of the tuning workflow execution.

[0118] Optionally, if the initial deployment of a component fails, it indicates that there may be a problem with the component's deployment parameters or environment, and re-deploying it may lead to a decrease in the overall efficiency of the system. The re-execution of the failed steps includes: Obtain the target deployment component to be deployed in the failed step. If the target deployment component carries an initial deployment failure flag, suspend the execution of the failed step. The initial deployment failure flag is used to indicate that the target deployment component failed to reach the expected state in the initial deployment.

[0119] For example, the target deployment component can be a specific component that needs to perform deployment operations in the tuning step, and the first deployment failure flag can be an identifier that the component failed to reach the expected state during the initial deployment process.

[0120] In one embodiment, the method for determining whether a first deployment failure flag is carried can be: checking whether a first failure flag identifier exists in the status field or metadata of the target deployment component; if a first failure flag identifier exists, it is determined that the first deployment failure flag is carried; if a first failure flag identifier does not exist, it is determined that the first deployment failure flag is not carried.

[0121] In one embodiment, pausing the execution of a failed step can be achieved by temporarily removing the step from the run queue or marking it as to be skipped to avoid repeated invalid execution, while recording relevant log information.

[0122] In one embodiment, components that fail to meet expectations during initial deployment are identified by initial deployment failure flags, and failed steps are paused if necessary to avoid repeated errors affecting the execution of other components or steps, thereby improving the safety and controllability of the system tuning process and reducing the risk of cascading failures.

[0123] Optionally, when a user interacts with a component, an immediate response is required. However, the periodic adjustments of the tuning engine cannot meet this requirement. Therefore, a tuning method for immediate response is needed. The component tuning method further includes: In response to receiving a component change operation for a target component, the target change state is extracted from the component change operation, and the target component is tuned to the target change state using a component state tuning engine.

[0124] For example, a component change operation can be a user- or system-initiated request to modify the state or configuration of a target component. The target changed state can be the new running state that the component should reach after the operation is completed. The component state tuning engine can be a runtime execution module used to quickly respond to component state changes and directly execute tuning operations. The component state tuning engine can be a Flash engine, a rule-based state scheduling engine, a programmable state execution engine, or any execution engine that implements component state switching, parameter updating, and runtime control functions.

[0125] In one embodiment, the method for extracting the target change state may be: parsing the state field or instruction information in the component change operation, mapping it to the target state value in the application model, and determining the mapped target state value as the target change state.

[0126] In one embodiment, the target component can be tuned by directly triggering the creation, deletion, or restart operation of the component without relying on the underlying state query interface, so as to quickly bring the component to the target changed state.

[0127] In one embodiment, the component state tuning engine can quickly process components whose expected state is "UP" or "DOWN" and whose current state is empty, without relying on the underlying state query interface, and directly perform creation or deletion operations to ensure immediate response to user operations.

[0128] In one embodiment, when responding to a component change operation, the changed state is automatically extracted and tuning is performed, enabling the component to quickly adapt to state changes at runtime, achieving dynamic adjustment and state self-management, and improving the platform's flexibility and service continuity.

[0129] Based on the above embodiments, Figure 8 This is a structural block diagram of a component tuning device provided in an embodiment of this application. (Reference) Figure 8 The component tuning device provided in this embodiment specifically includes: a state extraction module 11, a tuning operation module 12, and a tuning execution module 13.

[0130] The state extraction module 11 is configured to determine the application model corresponding to the target component and extract the expected state and current state of the target component from the application model; the tuning operation module 12 is configured to generate a tuning operation based on the expected state and the current state when the expected state and the current state are inconsistent, and map the tuning operation to at least one tuning step; the tuning execution module 13 is configured to construct a tuning workflow based on the tuning steps and execute the tuning workflow using a runtime engine.

[0131] Based on the above embodiments, the component tuning device further includes: a model mapping module configured to acquire external application data of the target component and map the external application data to an application model; a deployment operation module configured to extract the desired state of the target component from the application model and generate a deployment operation based on the desired state; and a component deployment module configured to build a deployment workflow based on the deployment operation and execute the deployment workflow using the runtime engine.

[0132] Based on the above embodiments, the model mapping module includes: a data construction unit configured to construct application metadata, application specification data, and application status data based on the external application data; and a model mapping unit configured to construct an application model based on the application metadata, the application specification data, and the application status data.

[0133] Based on the above embodiments, the state extraction module 11 includes: an environment identification unit configured to acquire the target deployment mode of the target component and the environment center identifier of the environment where the target component is currently located; a state matching unit configured to match the expected state of the target component from the application model based on the target deployment mode and the environment center identifier; and a state acquisition unit configured to extract the current state of the target component from the application model.

[0134] Based on the above embodiments, the state matching unit includes: a deployment mode subunit, configured to extract at least one deployment center identifier and deployment status from the target deployment mode; a deployment status subunit, configured to associate the target deployment status of the deployment center where the environment center identifier is located with the deployment status according to the correspondence between the deployment center identifier and the deployment status; and a desired state subunit, configured to extract the desired state of the target component from the target deployment status.

[0135] Based on the above embodiments, the component tuning device further includes: an environment feature identification module, configured to determine a first policy snapshot corresponding to the target component and extract an environment feature identifier from the first policy snapshot; a snapshot update module, configured to obtain the environment configuration where the target component is located, and if the environment configuration does not match the environment feature identifier, obtain a second policy snapshot corresponding to the environment configuration; and a state update module, configured to extract the desired state from the second policy snapshot as the desired state of the target component.

[0136] Based on the above embodiments, the component tuning device further includes: a failure counting module, configured to obtain a failure count value corresponding to the failed step when any of the tuning steps fails; and an exponent avoidance module, configured to use the failure count value as an exponent to calculate the retry time interval for the next retry of the failed step, and to re-execute the failed step when the retry time interval is reached.

[0137] Based on the above embodiments, the index avoidance module includes: a failure management unit, configured to obtain the target deployment component to be deployed in the failure step, and suspend the execution of the failure step when the target deployment component carries an initial deployment failure flag, wherein the initial deployment failure flag is used to indicate that the target deployment component failed to achieve the expected state in the initial deployment.

[0138] Based on the above embodiments, the component tuning device further includes: a fast tuning module configured to, in response to receiving a component change operation of a target component, extract a target change state from the component change operation and tune the target component to the target change state using a component state tuning engine.

[0139] The component tuning device provided in this application embodiment, by constructing a hierarchical task processing architecture consisting of a state extraction module 11, a tuning operation module 12, and a tuning execution module 13, achieves an end-to-end automated processing chain from target component state acquisition, difference detection, tuning operation generation to tuning workflow execution. This device can adapt to various application model inputs, dynamically extract component state information, and generate tuning operations based on the difference between the desired state and the current state, achieving efficient automation and precise controllability of the component tuning process. Specifically, the state extraction module 11 has the capability to acquire the target component state, used to determine the application model corresponding to the target component, and extract the desired state and current state of the target component from the application model, providing basic information for subsequent tuning operations; the tuning operation module 12 is used to generate corresponding tuning operations when the desired state and the current state are inconsistent, and maps the tuning operations to at least one executable tuning step, ensuring accurate and traceable operations; the tuning execution module 13 constructs a complete tuning workflow based on the tuning steps, and executes the workflow using a runtime engine to achieve state alignment and dynamic tuning of the target component. Through the collaborative processing of the above modules, the device constructs a complete closed-loop process from component state extraction, difference analysis, tuning operation generation to workflow execution, breaking through the limitations of traditional manual intervention or single-stage tuning mode in terms of efficiency, accuracy and traceability, and realizing efficient, reliable and automated component tuning capabilities.

[0140] The component tuning device provided in this application embodiment can be used to execute the component tuning method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0141] Figure 9 This is a schematic diagram of the structure of a component tuning device provided in an embodiment of this application, with reference to... Figure 9 The component tuning device includes a processor 21, a memory 22, a communication device 23, an input device 24, and an output device 25. The number of processors 21 and the number of memories 22 in the component tuning device can be one or more. The processor 21, memory 22, communication device 23, input device 24, and output device 25 of the component tuning device can be connected via a bus or other means.

[0142] The memory 22, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the component tuning method in any embodiment of this application (e.g., the state extraction module 11, tuning operation module 12, and tuning execution module 13 in the component tuning device). The memory 22 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory 22 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0143] The communication device 23 is used for data transmission.

[0144] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, thereby realizing the above-mentioned component tuning method.

[0145] Input device 24 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the device. Output device 25 may include display devices such as a display screen.

[0146] The component tuning device provided above can be used to execute the component tuning method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0147] This application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a component tuning method. The component tuning method includes: determining an application model corresponding to a target component; extracting a desired state and a current state of the target component from the application model; generating a tuning operation based on the desired state and the current state when the desired state and the current state are inconsistent; mapping the tuning operation to at least one tuning step; constructing a tuning workflow based on the tuning steps; and executing the tuning workflow using a runtime engine.

[0148] Storage medium—any type of memory device or storage device. The term "storage medium" is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which a program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term "storage medium" may include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0149] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the component tuning method described above, but can also perform related operations in the component tuning method provided in any embodiment of this application.

[0150] The component tuning apparatus, storage medium, and component tuning device provided in the above embodiments can execute the component tuning method provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the component tuning method provided in any embodiment of this application.

[0151] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application. The scope of this application is determined by the scope of the claims.

Claims

1. A component tuning method, characterized in that, include: Determine the application model corresponding to the target component, and extract the desired state and current state of the target component from the application model; In the case where the desired state and the current state are inconsistent, a tuning operation is generated based on the desired state and the current state, and the tuning operation is mapped to at least one tuning step. A tuning workflow is constructed based on the tuning steps, and the tuning workflow is executed using a runtime engine.

2. The component tuning method according to claim 1, characterized in that, Before determining the application model corresponding to the target component, the following steps are included: Obtain external application data of the target component and map the external application data into an application model; Extract the desired state of the target component from the application model, and generate deployment operations based on the desired state; A deployment workflow is built based on the deployment operations, and the deployment workflow is executed using the runtime engine.

3. The component tuning method according to claim 2, characterized in that, The step of mapping the external application data to an application model includes: Based on the external application data, construct application metadata, application specification data, and application status data; An application model is constructed based on the application metadata, the application specification data, and the application status data.

4. The component tuning method according to claim 1, characterized in that, The step of extracting the desired state and current state of the target component from the application model includes: Obtain the target deployment mode of the target component and the environment center identifier of the current environment of the target component; Based on the target deployment mode and the environment center identifier, match the desired state of the target component from the application model; Extract the current state of the target component from the application model.

5. The component tuning method according to claim 4, characterized in that, The step of matching the desired state of the target component from the application model based on the target deployment mode and the environment center identifier includes: Extract the deployment center identifier and deployment status of at least one deployment center from the target deployment pattern; Based on the correspondence between the deployment center identifier and the deployment status, the target deployment status of the deployment center where the environment center identifier is located is associated; Extract the desired state of the target component from the target deployment state.

6. The component tuning method according to claim 1, characterized in that, After extracting the desired state of the target component from the application model, the process includes: Determine the first policy snapshot corresponding to the target component, and extract the environmental feature identifier from the first policy snapshot; Obtain the environment configuration where the target component is located; if the environment configuration does not match the environment feature identifier, obtain the second policy snapshot corresponding to the environment configuration. Extract the desired state from the second strategy snapshot as the desired state of the target component.

7. The component tuning method according to claim 1, characterized in that, After the tuning workflow is executed using the runtime engine, the following is included: If any of the tuning steps fails, obtain the failure count value of the failed step; The failure count is used as an exponent to calculate the retry time interval for the next retry of the failed step. If the retry time interval is reached, the failed step is re-executed.

8. The component tuning method according to claim 7, characterized in that, The re-execution of the failed step includes: Obtain the target deployment component to be deployed in the failed step. If the target deployment component carries an initial deployment failure flag, suspend the execution of the failed step. The initial deployment failure flag is used to indicate that the target deployment component failed to reach the expected state in the initial deployment.

9. The component tuning method according to claim 1, characterized in that, The component tuning method further includes: In response to receiving a component change operation for a target component, the target change state is extracted from the component change operation, and the target component is tuned to the target change state using a component state tuning engine.

10. A component tuning device, characterized in that, include: The state extraction module is used to determine the application model corresponding to the target component and extract the expected state and current state of the target component from the application model. A tuning operation module is configured to generate a tuning operation based on the desired state and the current state when the desired state and the current state are inconsistent, and to map the tuning operation to at least one tuning step. The tuning execution module is used to construct a tuning workflow based on the tuning steps and execute the tuning workflow using a runtime engine.

Images