Micro-service change method and apparatus

Abstract

Disclosed in the embodiments of the present application are a micro-service change method and apparatus, which are used for improving the change efficiency of a micro-service change. The method in the embodiments of the present application comprises: a computing device acquiring a micro-service orchestration artifact package, wherein the micro-service orchestration artifact package comprises a final-state resource orchestration code and a change process orchestration code, the final-state resource orchestration code is used for managing a final-state resource set involved in a micro-service change, the final-state resource set comprises one or more final-state resource subsets, the change process orchestration code is used for orchestrating non-final-state change operations and final-state resource change operations, and the final-state resource change operations comprise change operations corresponding to the one or more final-state resource subsets; generating a change execution plan on the basis of the micro-service orchestration artifact package, wherein the change execution plan comprises change elements involved in the micro-service change, the change elements comprise the non-final-state change operations and the final-state resource change operations; and executing a micro-service change task according to the change execution plan.

Description

A method and apparatus for modifying microservices

[0001] This application claims priority to Chinese patent application filed on March 28, 2025, with application number 202510390513.6 and entitled "A method and apparatus for changing microservices", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computers, and more particularly to a method and apparatus for modifying microservices. Background Technology

[0003] With the development of modern software architecture, microservices have become the preferred choice for enterprises to develop and deploy applications due to their flexibility and scalability. However, when managing changes to numerous microservices, current microservice change management solutions use Infrastructure as Code (IaC) technology to manage microservice changes in a code-based manner. IaC is a technology that manages and configures IT infrastructure by defining code files, which can improve the reliability and efficiency of microservice changes.

[0004] Currently, in microservice change solutions based on IaC technology, users describe the final state resource configuration corresponding to a microservice change through IaC code. The microservice change system then automatically executes the final state resource change operation based on the IaC code. Specifically, the microservice change system automatically coordinates the microservice's change from its current state to the target final state based on the final state resource configuration specified in the IaC code and the current state resource configuration, and ultimately changes the resources to the final state resource configuration specified in the IaC code.

[0005] However, during the microservice change process, some microservice change operations cannot be implemented through final state resource configuration. That is, the final state resource configuration of microservice changes cannot be completed automatically by IaC code at once and requires manual intervention, resulting in low efficiency of microservice changes. Summary of the Invention

[0006] This application provides a method for modifying microservices, which improves the efficiency of microservice modification. This application also provides a microservice modification apparatus, computing device, computing device cluster, computer-readable storage medium, and computer program product corresponding to the microservice modification method.

[0007] In a first aspect, embodiments of this application provide a method for modifying microservices. This method can be executed by a computing device, or by a component of the computing device, such as a processor, chip, or chip system, or by a logic module or software capable of implementing all or part of the functions of the computing device. The method provided in the first aspect includes: the computing device acquiring a microservice orchestration artifact package. The microservice orchestration artifact includes final-state resource orchestration code and change process orchestration code. The final-state resource orchestration code manages a set of final-state resources involved in the microservice modification, and the set of final-state resources includes one or more subsets of final-state resources. The change process orchestration code orchestrates non-final-state change operations and final-state resource change operations, and the final-state resource change operations include change operations corresponding to one or more subsets of final-state resources. The computing device generates a change execution plan based on the microservice orchestration artifact package. The change execution plan includes change elements involved in the microservice modification. The change elements include non-final-state change operations and final-state resource change operations. Non-final-state change operations are imperative change operations without a specified final state, and final-state resource change operations are automatic change operations with a specified final state. The computing device executes the microservice modification task according to the change execution plan.

[0008] In this embodiment, the computing device can define the orchestration logic for non-final state change operations and final state resource change operations during the microservice change process in the microservice orchestration artifact package. This enables the microservice change process to automatically perform microservice change operations according to the change process orchestration logic in the microservice orchestration artifact package. Compared with the prior art, where the microservice change process can only automate the final state resource change operation through IaC code, the microservice orchestration artifact package in this embodiment can achieve full-process automated execution of the microservice change process, thereby improving the efficiency of microservice change.

[0009] In one possible implementation, microservice change tasks include non-final state change tasks and final state resource change tasks. During the execution of microservice change tasks according to the change execution plan, the computing device controls the operation and maintenance service system to execute non-final state change tasks based on a process action orchestration plugin. The operation and maintenance service system includes one or more of the following: a monitoring system, an alarm system, a probing system, and a traffic switching system. The computing device controls the infrastructure, or IaC system, to execute final state resource change tasks based on a final state resource orchestration plugin. The IaC system is used to change the current resource state of the microservice to a final state resource state, where the final state resource state includes final state resource states corresponding to one or more subsets of final state resources.

[0010] In this embodiment, the computing device can perform mixed execution of non-final state change tasks and final state resource change tasks in the execution plan of microservice changes. The package controls the operation and maintenance service system to execute non-final state change tasks based on the process action orchestration plug-in, and controls the IaC system to execute final state resource change tasks based on the final state resource orchestration plug-in, thereby improving the feasibility of mixed execution of non-final state change tasks and final state resource change tasks.

[0011] In one possible implementation, the final state resource change operation includes multiple final state resource change operations, and these multiple final state resource change operations are final state resource changes corresponding to the same subset of final state resources. That is, the change process orchestration logic in the microservice orchestration artifact package can orchestrate the final state resource change operations corresponding to the same subset of final state resources multiple times. Thus, during the microservice change process, the computing device can make multiple calls to the IaC system corresponding to the same subset of final state resources to implement multiple final state resource change operations.

[0012] In the embodiments of this application, the microservice orchestration artifact package supports automatic repeated change operations on the final state resource changes corresponding to the same final state resource subset in a single microservice change process, thereby improving the change efficiency of microservice changes.

[0013] In one possible implementation, the computing device performs checkpoint control on the microservice change process based on change process orchestration code. Checkpoint control is used to set control points between change operations corresponding to one or more subsets of final-state resources. That is, the computing device can control the intermediate states of the change process based on the change process orchestration logic in the microservice orchestration artifact package, thereby supporting the customization and extension of the microservice change process.

[0014] In this embodiment, the computing device can encapsulate all the orchestration elements required for microservice changes through code, enabling businesses to customize and extend the microservice change process by writing code, thereby improving the flexibility of microservice change process orchestration.

[0015] In one possible implementation, during the execution of microservice change tasks according to the change execution plan, the computing device can generate multiple task instances based on the change execution plan and maintain a directed acyclic graph structure of the multiple task instances, thereby enabling the observability of the microservice change process.

[0016] In this embodiment of the application, the computing device can maintain a directed acyclic graph (DAG) structure of multiple task instances based on the change execution plan, thereby improving the observability of the microservice change process.

[0017] In one possible implementation, the computing device assigns state migration paths to final state resource change operations corresponding to one or more final state resource subsets based on a migration arbitrator. The state migration path is used to indicate the resource state number of the final state resource change operation. The state migration path includes one or more resource states, and each resource state corresponds to a unique resource state number.

[0018] In this embodiment of the application, the computing device can allocate state migration paths for final state resource change operations corresponding to one or more final state resource subsets based on the migration arbitrator, thereby recording multiple intermediate resource states in the final state resource change operation and improving the traceability of the final state resource change operation.

[0019] In one possible implementation, change baseline data corresponding to one or more resource states in the storage state migration path is used to perform rollback operations on one or more resource states. The change baseline data includes one or more of the following: microservice orchestration artifact packages, input parameters for final state resource changes, output data for final state resource changes, and local variable information for final state resource changes.

[0020] In this embodiment, the computing device can maintain corresponding change baseline data for each resource state in the storage state migration path, thereby enabling rollback operations on one or more resource states and improving the feasibility of rollback operations in microservice changes.

[0021] In one possible implementation, after the computing device executes the microservice change task according to the change execution plan, the computing device updates the change baseline data based on the execution result of the microservice change task. The change baseline data includes one or more of the following: microservice orchestration artifact packages, change input parameters, final-state resource change output data, and final-state resource change local variable information. Here, the change input parameters include change input parameters for final-state resource changes and change parameters for non-final-state changes. The final-state resource change output data includes the global output value of the final-state resource and the output values ​​of each subset of final-state resources. The final-state resource change local variable information includes the global local parameter values ​​of the final-state resource and the local parameter values ​​of each subset of final-state resources.

[0022] In this embodiment, the computing device can update the change baseline data based on the execution result of the microservice change task, thereby improving the correctness and timeliness of the transfer of change baseline data between different final state resource change operations.

[0023] In one possible implementation, the change operation corresponding to the microservice change task includes one or more of the following: execution operation, retry operation, and rollback operation. Execution and retry operations are forward execution operations, while rollback operations are reverse execution operations.

[0024] In the embodiments of this application, the change operation corresponding to the microservice change task can be of various types, thereby improving the feasibility of microservice change.

[0025] Secondly, embodiments of this application provide a microservice modification apparatus, comprising an acquisition unit and a processing unit. The acquisition unit acquires a microservice orchestration artifact package, which includes final-state resource orchestration code and change process orchestration code. The final-state resource orchestration code manages a set of final-state resources involved in the microservice modification, and this set includes one or more subsets of final-state resources. The change process orchestration code orchestrates non-final-state modification operations and final-state resource modification operations, each including modification operations corresponding to one or more subsets of final-state resources. The processing unit generates a modification execution plan based on the microservice orchestration artifact package. The modification execution plan includes modification elements involved in the microservice modification, including non-final-state modification operations and final-state resource modification operations. Non-final-state modification operations are imperative modification operations without a specified final state, while final-state resource modification operations are automatic modification operations with a specified final state. The processing unit also executes microservice modification tasks according to the modification execution plan.

[0026] In one possible implementation, microservice change tasks include non-final state change tasks and final state resource change tasks. The processing unit is specifically used to control the operation and maintenance service system to execute non-final state change tasks based on the process action orchestration plugin. The operation and maintenance service system includes one or more of the following: a monitoring system, an alarm system, a probing system, and a traffic switching system. Final state resource change tasks are executed based on the final state resource orchestration plugin-controlled infrastructure, i.e., the code IaC system. The IaC system is used to change the current resource state of the microservice to the final state resource state, where the final state resource state includes the final state resource states corresponding to one or more subsets of final state resources.

[0027] In one possible implementation, the final state resource change operation includes multiple final state resource change operations, and the multiple final state resource change operations are final state resource changes corresponding to the same subset of final state resources.

[0028] In one possible implementation, the processing unit is further configured to perform checkpoint control on the microservice change process based on the change process orchestration code. The checkpoint control is used to set control points between the final resource change operations corresponding to one or more final resource subsets.

[0029] In one possible implementation, the processing unit is further configured to allocate state migration paths for final state resource change operations corresponding to one or more final state resource subsets based on the migration arbitrator, wherein the state migration path is used to indicate the resource state number of the final state resource change operation.

[0030] In one possible implementation, the processing unit is further configured to store change baseline data corresponding to one or more resource states in the state migration path, and the change baseline data is used to perform rollback operations on one or more resource states.

[0031] In one possible implementation, the processing unit is further configured to update the change baseline data based on the execution result of the microservice change task. The change baseline data includes one or more of the following: microservice orchestration artifact package, change input parameters, final state resource change output data, and final state resource change local variable information.

[0032] In one possible implementation, the change operation corresponding to the microservice change task includes one or more of the following: execution operation, retry operation, and rollback operation.

[0033] Thirdly, embodiments of this application provide a computing device including a processor coupled to a memory. The processor stores instructions, which, when executed by the processor, cause the computing device to perform the method described in the first aspect or any possible implementation thereof.

[0034] Fourthly, embodiments of this application provide a computing device cluster, which includes one or more computing devices. Each computing device includes a processor coupled to a memory. The processor is used to store instructions, which, when executed by the processor, cause the computing device cluster to perform the method described in the first aspect or any possible implementation thereof.

[0035] Fifthly, embodiments of this application provide a computer-readable storage medium having instructions stored thereon, which, when executed, cause a computer to perform the method described in the first aspect or any possible implementation thereof.

[0036] Sixthly, embodiments of this application provide a computer program product including instructions that, when executed, cause a computer to implement the method described in the first aspect or any possible implementation thereof.

[0037] It is understood that the beneficial effects that any of the microservice modification devices, computing devices, computing device clusters, computer-readable media or computer program products provided above can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0038] Figure 1 is a schematic diagram of the system architecture of a microservice change system provided in an embodiment of this application;

[0039] Figure 2 is a flowchart illustrating a microservice modification method provided in an embodiment of this application;

[0040] Figure 3 is a schematic diagram of an artifact package catalog of a microservice orchestration artifact package provided in an embodiment of this application;

[0041] Figure 4 is a schematic diagram of the input parameter information of a final state resource orchestration code in an embodiment of this application;

[0042] Figure 5 is a schematic diagram of local variable information of a final state resource orchestration code in an embodiment of this application;

[0043] Figure 6 is a schematic diagram of a change process arrangement code provided in an embodiment of this application;

[0044] Figure 7 is a schematic diagram of another microservice change process provided in an embodiment of this application;

[0045] Figure 8 is a schematic diagram of another microservice change process provided in an embodiment of this application;

[0046] Figure 9 is a schematic diagram of another microservice change process provided in an embodiment of this application;

[0047] Figure 10 is a schematic diagram of a baseline change management process provided in an embodiment of this application;

[0048] Figure 11 is a schematic diagram of a state transition path provided in an embodiment of this application;

[0049] Figure 12 is a schematic diagram of a final state resource change process provided in an embodiment of this application;

[0050] Figure 13 is a schematic diagram of a microservice modification device provided in an embodiment of this application;

[0051] Figure 14 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0052] Figure 15 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0053] Figure 16 is a schematic diagram of another computing device cluster provided in an embodiment of this application. Detailed Implementation

[0054] This application provides a method and apparatus for modifying microservices, which improves the efficiency of microservice modification.

[0055] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0056] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0057] First, some of the terms used in the embodiments of this application will be introduced to help those skilled in the art understand the technical solutions.

[0058] Infrastructure as code (IaC) is a methodology for defining and managing infrastructure through code. It automates the configuration and management process of infrastructure, enabling developers to programmatically create, deploy, and manage resources such as servers, networks, and storage without relying on manual operations or graphical interfaces.

[0059] Final state resources refer to a resource management method used by an IaC system. Resources must first be encapsulated and implemented as IaC final state resources and integrated with the IaC system before they can be managed by the IaC system. Typically, IaC final state resources need to meet the following characteristics: the target state of the resource can be described through declarative attribute configuration, and changes in resource state caused by changes in attribute configuration can be completed automatically, without manual intervention during the resource state migration process.

[0060] A resource set, also known as a final state resource set, is used in IaC systems or other final state-oriented change management systems to represent a collection of resources, resource changes, and operational states managed by the IaC system. Each time a user makes a change using IaC, the operation is performed at the granularity of a resource set.

[0061] The full set of resources for microservices refers to all the resources involved in supporting the end-to-end operation of microservices, such as database resources, container workloads, dynamic configurations, and gateway configurations.

[0062] Microservice resource subsets are multiple finer-grained resource sets that are divided from the full resource set of a microservice. Each resource subset can be changed independently, and the execution order of multiple resource subsets can be specified by the user.

[0063] Pipeline data is a data structure used to describe the change process of microservices. Microservices may contain various change patterns, such as blue-green upgrades and batch rolling upgrades. Each change pattern corresponds to a separate pipeline code file to describe the corresponding change process.

[0064] A change order is a work order record for a complete change to a microservice. It corresponds to a record in the work order list of the change system. A change order identifies the overall status of the change and serves as the object of the change operation. Change order statuses include: pending execution, executing, execution failed, execution paused, and execution successful. Users can initiate multiple change operations on a single change order; for example, initiating a new change retry operation when the change order fails, or initiating a continuation operation when the change is paused.

[0065] A state transition path is a state transition process from the initial state to the target state for each change operation of the final state resource. A complete microservice change includes multiple final state resource change operations. Each change operation is associated with a state transition path to represent the original state and target state of the final state resource corresponding to this operation.

[0066] A change baseline is a collection of input data required to drive a change and output data during the change process. The change baseline includes: input parameter values, orchestration code required for the change, the result status of the change task, and output parameter values. Change orders are associated with change baselines. Change baselines typically have multiple versions, each corresponding to a different status number in the final resource migration path. These versions are snapshots of the final resource status, allowing for forward changes or rollbacks to the corresponding snapshot status.

[0067] To make the technical solution of this application clearer and easier to understand, the system architecture of this application will be described below with reference to the accompanying drawings.

[0068] Please refer to Figure 1, which is a schematic diagram of the system architecture of a microservice change system provided in this application embodiment. In the example shown in Figure 1, the microservice change system 10 includes a change parsing module 101, a change process orchestration module 102, a process action orchestration plugin 103, and a final state resource orchestration plugin 104. The change process orchestration module 102 includes a change orchestration control submodule 1021 and a final state resource management submodule 1022. The specific functions of each part of the microservice change system 10 are described in detail below.

[0069] The change parsing module 101 is used to verify and parse user-defined microservice orchestration artifact packages, and convert the microservice orchestration artifact packages into executable structured data, such as pipeline data. During the parsing process, the change parsing module 101 can verify the code format and code semantics of the microservice orchestration artifact packages, and store the verified microservice orchestration artifact packages in a structured manner in the database for use by other modules.

[0070] The change process orchestration module 102 is the core engine for coordinating microservice changes, also known as the change process orchestration engine module. It interacts with the orchestration plugins 103 and 104, which follow the orchestration logic and process of microservice artifact packages, to drive other systems to automatically complete the microservice change process. These other systems include operation and maintenance service systems and Infrastructure as Code (IaC) systems. The change process orchestration module 102 includes a change orchestration control submodule 1021 and a final resource management submodule 1022.

[0071] The change orchestration control submodule 1021 is used to orchestrate non-final state change operations with multiple final state resource change operations according to the change process orchestration logic defined in the microservice orchestration artifact package, thereby controlling the full-process automation of microservice changes. Non-final state change operations are subject to procedural control, and the operation and maintenance service system can execute specific process actions step by step to complete the change. Final state resource change operations, on the other hand, are subject to declarative control; by defining the final state of the resource, the IaC system can automatically adjust the current state to achieve the final state change.

[0072] The final state resource management submodule 1022 manages the full set of final state resources defined in the microservice orchestration artifact package. This submodule can divide the full set of final state resources into one or more subsets. Each subset allows for independent final state resource change operations via the IaC system. The change orchestration control submodule 1021 can also orchestrate multiple subsets to implement final state resource change operations at the subset level.

[0073] The process action orchestration plugin 103 is used to interface with the operation and maintenance service system, thereby controlling the operation and maintenance service system to initiate and perform non-final state change operations. The operation and maintenance service system can be of various types, such as monitoring systems, alarm systems, dial-up testing systems, traffic switching systems, etc. The process action orchestration plugin 103 also provides interfaces for forward execution and reverse rollback. The change process orchestration module 102 can call the corresponding interfaces to complete the execution and rollback of microservice changes.

[0074] The final-state resource orchestration plugin 104 is used to interface with the IaC system, thereby controlling the IaC system to perform final-state resource change operations. Final-state resource changes can be performed at the subset-level granularity of final-state resources. Specifically, the change process orchestration module 102, through the final-state resource orchestration plugin 104, calls the IaC system to migrate the resource state to the final-state resource state described by the final-state orchestration code in the microservice orchestration artifact package. The change process orchestration module 102 can also control the migration of resource states through the final-state resource orchestration plugin 104, and implement forward execution and reverse rollback of microservice changes.

[0075] It should be noted that the change parsing module 101, change process orchestration module 102, process action orchestration plugin 103, and final state resource orchestration plugin 104 in the microservice change system 10 can all be deployed on computing devices or computing device clusters. Therefore, in this embodiment, computing devices or computing device clusters can also be used to refer to the various modules in the microservice change system 10.

[0076] Based on the microservice modification system 10 shown in Figure 1, this application also provides a microservice modification method. The microservice modification method provided in this application will be described below with reference to embodiments.

[0077] Please refer to Figure 2, which is a flowchart illustrating a microservice modification method provided in an embodiment of this application. In the example shown in Figure 2, the method includes the following steps:

[0078] 201. Obtain the microservice orchestration artifact package. The microservice orchestration artifact includes final resource orchestration code and change process orchestration code. The final resource orchestration code is used to manage the set of final resources involved in microservice changes, and the change process orchestration code is used to orchestrate non-final change operations and final resource change operations.

[0079] In this embodiment, the microservice change system 10 can manage the orchestration logic of microservice changes based on microservice orchestration artifact packages. It uses a coded approach to mix final-state resource change operations and non-final-state change operations required for microservice changes, resulting in a higher degree of automation and scalability for the complete microservice change process. The details are as follows:

[0080] The microservice change system 10 obtains a microservice orchestration artifact package. This microservice orchestration artifact package contains all the change elements required for the microservice change. All change elements include final resource change operations and non-final change operations. The user packages the mixed orchestration logic of final resource change operations and non-final change operations into the microservice orchestration artifact package in the form of code files. This allows the microservice orchestration artifact package to drive the microservice change system 10 to automatically complete the microservice change process according to the mixed orchestration logic.

[0081] The following section first introduces the microservice orchestration artifact package in the embodiments of this application:

[0082] In this embodiment, the microservice orchestration artifacts mainly include final-state resource orchestration code and change process orchestration code. The final-state resource orchestration code manages the set of final-state resources involved in microservice changes. This set includes all final-state resources involved in the microservice change, and can be divided into one or more subsets of final-state resources. The final-state resource orchestration code can also control the IaC system to perform final-state resource change operations at the subset-level granularity. In other words, the final-state resource orchestration code includes orchestration code corresponding to one or more resource state subsets. The change process orchestration code is used to orchestrate non-final-state change operations and final-state resource change operations. The final-state resource change operations include change operations corresponding to one or more final-state resource subsets.

[0083] In this embodiment, the microservice orchestration artifact package includes other types of information besides orchestration code, such as metadata and auxiliary resources for changes to dependencies. These are described in detail below with reference to the accompanying drawings:

[0084] Please refer to Figure 3, which is a schematic diagram of the artifact package directory of a microservice orchestration artifact package provided in an embodiment of this application. In the example shown in Figure 3, the artifact package directory in the microservice orchestration artifact package includes package description information, an attachment resource directory for change dependencies, and an orchestration code directory. The "manifest.yaml" field contains the package description information of the microservice orchestration artifact package, which can also be called metadata configuration. The package description information includes the package name, package version, and microservice information, etc. The "resources" directory is an attachment resource directory for microservice change dependencies. Attachment resources include script files, SQL files, and Swagger API description files, etc. The orchestration code can reference the content of the attachment resource files.

[0085] In the example shown in Figure 3, the "templates" directory is the orchestration code directory, which includes final resource orchestration code and change process orchestration code. The "templates" directory includes the "iac" directory and the "pipelines" directory. The "iac" directory is the final resource orchestration code directory, and the "pipelines" directory is the change process orchestration code directory.

[0086] In the example shown in Figure 3, the "iac" directory includes multiple final resource subset directories, such as directory numbers [0.3.1.4] to [0.3.1.9]. Directory numbers [0.3.1.4] to [0.3.1.8] are the final resource subset directories for standard microservices, while directory number [0.3.1.4] is a user-defined final resource subset directory. Users can use final resource subset directories and directory combinations as needed when orchestrating change processes.

[0087] It is understandable that the internal code of a single final resource subset directory is IaC code. Depending on the IaC system that the microservice change system interfaces with, the code file format inside the corresponding final resource subset directory will also be different.

[0088] In the example shown in Figure 3, the "iac" directory also includes "inputs", "outputs", and "locals" directories, for example, directory numbers [0.3.1.1] to [0.3.1.3]. The "inputs" directory defines the input parameter information of the final-state resource orchestration code, the "outputs" directory defines the output data information of the final-state resource orchestration code, and the "locals" directory defines the local variable information of the final-state orchestration code. This information is described below with reference to the accompanying figures:

[0089] Please refer to Figure 4, which is a schematic diagram of input parameter information for a final state resource orchestration code in an embodiment of this application. In the example shown in Figure 4, the "inputs" directory defines the input parameter information for the final state resource orchestration code, including the "global" syntax block and the "rscSet" syntax block. The "global" syntax block defines global input parameters, which are shared by all final state resource subsets, while the "rscSet" syntax block defines input parameters private to a single final state resource subset.

[0090] In the example shown in Figure 4, the fields such as "k8s namespace" in the "global" syntax block represent parameter names, and the next level "type" field represents the parameter type. In the "rscSet" syntax block, the "infrastructure" field corresponds to the name of the resource subset, the next level "apec" field of the resource subset name is the parameter name of that resource subset, and the next level "type" field of the parameter name is the parameter attribute definition.

[0091] In the example shown in Figure 4, the parameters in the "global" syntax block are shared by all final state resource subsets. When a change is made, they will be passed to the IaC system corresponding to all final state resource subsets. The parameters in the "rscSet" syntax block are independent of a specific resource subset. When a change is made, the IaC system corresponding to each final state resource subset will only receive the parameters belonging to that final state resource subset.

[0092] Understandably, the output data format defined in the "outputs" directory is similar to the input parameter format in the "inputs" directory, also divided into "global" global output data and "rscSet" resource subset-specific output data. Furthermore, the output data from the IaC system performing final-state resource change operations can also serve as input data for final-state resource changes corresponding to other final-state resource subsets.

[0093] Please refer to Figure 5, which is a schematic diagram of local variable information in a final state resource orchestration code according to an embodiment of this application. In the example shown in Figure 5, the local variable information of the final state resource orchestration code defined by the "locals" directory includes the "global" syntax block and the "rscSet" syntax block. The local variable information is mainly used to control the dynamic data transfer between various final state resource subsets. Users do not need to input parameter values ​​when making changes; instead, the change system automatically parses and obtains the parameter values.

[0094] In the example shown in Figure 5, the “rscSet” syntax block represents the definition of local variables at the final state resource subset level. The “workload” field represents the definition of local variables that are unique to the “workload” final state resource subset, and the “expression” field indicates that the value of this parameter is automatically obtained according to the “expression” expression, that is, the value of the variable named “cluster_endpoint” is obtained from the output variables of the “infrastructure” final state resource subset as the input value of this parameter.

[0095] In the example shown in Figure 5, the "cluster_endpoint" parameter is required when the "workload" final state resource subset changes. The value of this parameter is automatically obtained from the output variable of the "infrastructure" final state resource subset, enabling dynamic data transfer between multiple final state resource subsets.

[0096] The above content introduced the "iac" directory corresponding to the final state resource orchestration code. The following section introduces the "pipelines" directory corresponding to the change process orchestration code:

[0097] Please refer to Figure 3. In the example shown in Figure 3, the "pipelines" directory is the change process orchestration code directory. The "pipelines" directory can contain multiple code files for change process orchestration, each corresponding to a change mode. The user specifies the code file for change process orchestration. The following example uses a code file within the "pipelines" directory for illustration:

[0098] Please refer to Figure 6, which is a schematic diagram of a change process orchestration code provided in an embodiment of this application. In the example shown in Figure 6, the code file is used to orchestrate the batch change process of a microservice. During the batch change process of a microservice, the user can specify the batch configuration based on the code file, and the configuration includes parameters such as the number of batches and the number of new and old version workload instances in each batch.

[0099] In the example shown in Figure 6, the "stage" code describes the orchestration control logic for the final state resource change operations and non-final state change operations corresponding to multiple final state resource subsets. The change process orchestration logic includes various microservice change actions, such as final state resource change operations corresponding to infrastructure final state resource subsets, multi-batch cyclic control of workloads, adjustment of the number of new and old version workload instances within a single batch, traffic switching operations between old version workload instances, and manual checkpoint verification, etc.

[0100] In the example shown in Figure 6, the change process orchestration code is divided into three levels: stage, job, and step. A "stage" represents a change phase, and all change phases are executed sequentially. Each "stage" contains multiple "jobs," which the user can configure to be executed serially or in parallel. Each "job" contains multiple "steps," each representing a basic change operation.

[0101] In the example shown in Figure 6, the "step" field mainly includes a name field, a task field, and an inputs field. The "name" field represents the step name and is used to uniquely identify the step; the "task" field represents the task type and is used to identify the task type of the step; and the "inputs" field is the input configuration for the step, with different input parameter formats corresponding to different step types.

[0102] It should be noted that the task types for the "step" in the change process orchestration code include process control tasks, system change tasks, and business customization plugin tasks.

[0103] Among them, process control tasks are used to control the execution logic of the change process. These tasks can be provided by the change system. Examples of process control tasks include loop, branch selection, manual checkpoints, and parallel sub-process concurrency.

[0104] System change tasks are used to control the IaC system to perform final state resource changes at the final state resource subset granularity by orchestrating the final state orchestration code in the artifact package. System change tasks can also be provided by the change system. For example, system change tasks are the final state resource changes corresponding to the "ApplyIaCRscSet" final state resource subset in Figure 6.

[0105] Customized plugin tasks are used by various businesses to develop and integrate them into the change system through plugins. For example, the "TrafficSwitch" task in Figure 6 is used to control the traffic between new and old working instances in a single batch.

[0106] 202. Generate a change execution plan based on the microservice orchestration artifact package. The change execution plan includes the change elements involved in the microservice change. The change elements include non-final state changes and final state resource changes. Non-final state change operations are imperative change operations without a specified final state, while final state resource change operations are automatic change operations with a specified final state.

[0107] After obtaining the microservice orchestration artifact package, the microservice change system 10 generates a change execution plan based on the microservice orchestration artifact package. This change execution plan is the pipeline orchestration data corresponding to the change process orchestration code. The change execution plan includes the change elements involved in the microservice change, including non-final state changes and final state resource changes. Non-final state change operations are imperative change operations without a specified final state; they are also called non-final state resource changes or non-final state process actions. Final state resource change operations are automatic change operations with a specified final state.

[0108] In this embodiment, a final-state resource change operation refers to a microservice change operation whose goal is to reach a definite final state. Regardless of how many times the final-state resource change operation is executed, the result is the same. Final-state resource change operations are typically declarative, meaning the user specifies the desired final state, and the change system is responsible for adjusting the resource to that state. Non-final-state change operations refer to microservice change operations that require executing a series of steps according to instructions, without a definite final state, or whose final state depends on intermediate processes. Non-final-state change operations are typically imperative, where the user specifies specific change steps, the change system executes them step by step, and the change result may vary depending on the current state.

[0109] Please refer to Figure 7, which is a schematic diagram of another microservice change process provided in an embodiment of this application. In step a of the example shown in Figure 7, the microservice change system 10 receives a microservice orchestration artifact package and input parameters corresponding to the final state resource orchestration code. The microservice orchestration artifact includes the final state resource orchestration code and the change process orchestration code. The inputs, also called change parameters, include input parameters corresponding to non-final state change operations and input parameters corresponding to final state resource change operations. The microservice change system 10 parses the microservice orchestration artifact package to obtain executable pipeline orchestration data.

[0110] In steps b to g of the example shown in Figure 7, the microservice change system 10 can perform microservice changes based on microservice orchestration artifact packages. The microservice change process includes calling the operation and maintenance service system to perform non-final state change operations based on the process action orchestration plugin, and calling the IaC system to perform final state resource change operations based on the final state resource orchestration plugin. During the microservice change process based on microservice orchestration artifact packages, the microservice change system 10 can perform change baseline management and final state migration operations, which will be described in detail in the example shown in Figure 9 later.

[0111] 203. Execute microservice change tasks according to the change execution plan.

[0112] The microservice change system 10 is based on microservice orchestration artifacts. After generating a change execution plan, it executes microservice change tasks according to the change execution plan. Microservice change tasks include non-final state change tasks and final state resource change tasks.

[0113] Specifically, the microservice change system 10, based on the process action orchestration plugin 103, controls the operation and maintenance service system to execute non-final state change tasks. The operation and maintenance service system includes one or more of the following: a monitoring system, an alarm system, a testing system, and a traffic switching system. Non-final state change tasks include monitoring tasks, alarm tasks, testing tasks, and traffic switching tasks. The microservice change system 10, based on the final state resource orchestration plugin 104, controls the infrastructure as a code (IaC) system to execute final state resource change tasks. The IaC system is used to change the current resource state of the microservice to the final state resource state, where the final state resource state is the resource state corresponding to the final state resource set.

[0114] Please refer to Figure 8, which is a schematic diagram of another microservice change process provided in this embodiment of the application. In the example shown in Figure 8, after the microservice change system 10 parses the microservice orchestration artifact package, the change process orchestration module 102 controls the operation and maintenance service system to execute non-final state change tasks through the process action orchestration plugin 103, thereby realizing the change process corresponding to the change process orchestration code in the microservice orchestration artifact package. The change process orchestration module 102 controls the IaC system to execute final state resource change tasks through the final state resource orchestration plugin 104, thereby realizing the final state resource change corresponding to the final state resource orchestration code in the microservice orchestration artifact package.

[0115] In one possible implementation, during the execution of microservice change tasks according to the change execution plan, the microservice change system 10 can generate multiple task instances and maintain a directed acyclic graph (DAG) structure of these multiple task instances, thereby achieving parallel acceleration of microservice changes and observability of the change process. A specific example is provided below:

[0116] Please refer to Figure 9, which is a schematic diagram of another microservice change process provided in an embodiment of this application. In step a of the example shown in Figure 9, the microservice change system 10 receives a change request and performs a microservice change. The change request includes a change execution plan, which is pipeline data. The change operations in the change execution plan include operations such as execution, retry, and rollback. The microservice change system 10 first verifies the legality of the change operations in the change execution plan and generates a change order corresponding to the microservice change. The change order can record the change content of the microservice change.

[0117] It should be noted that if the change request is a new request and is not associated with an existing change order, the microservice change system 10 needs to create a corresponding change order and persist it for use in subsequent steps. If the change request is associated with an existing change order, the microservice change system 10 does not need to generate a new change order and can reuse the existing one. For example, when a change request is used to request a retry or continuation of a microservice task in a failed or paused change status, the change request is associated with an existing change order.

[0118] In step b of the example shown in Figure 9, the microservice change system 10 maintains the directed acyclic graph (DAG) structure of the task based on the change request. Specifically, the microservice change system 10 transforms the pipeline data or change order of the change request in step a into a DAG structure composed of steps. Each step corresponds to a task node in the DAG, and the execution order between steps is represented by directed edges in the DAG.

[0119] Understandably, when initiating the first change execution for a specified change order, the microservice change system 10 will generate a corresponding DAG graph. However, for subsequent change operations on the specified change order, such as retry, continue execution, and rollback operations, it is not necessary to generate a DAG graph again; the existing DAG structure associated with the change order can be reused. The DAG structure can be stored in the database for subsequent scheduling and execution.

[0120] In step c and the method shown in Figure 9, the microservice change system 10 determines whether the microservice change in the change request is a forward execution operation. If it is, step d is executed; otherwise, step r is executed. For example, when the change operation in the change request is an execute or retry operation, the microservice change system 10 continues to execute the unfinished task nodes in the forward direction according to the DAG structure during the microservice change task process until all tasks are completed. When the change operation in the change request is a rollback operation, the microservice change system 10 needs to execute the rollback operation of each task node in reverse order for the currently completed task nodes, and rollback all change operations in reverse order.

[0121] Specifically, the microservice change system 10 filters out all currently running nodes in the forward execution DAG structure from step b, generates a list of tasks to be rolled back, and establishes a new rollback DAG structure for each task node in the rollback task list. The direction of the edges in the rollback DAG structure is opposite to the direction of the edges between the corresponding task nodes in the forward execution DAG structure maintained in step b. Similarly, for scenarios where rollback operations are not performed for the first time, since the corresponding rollback DAG structure has already been generated during the first rollback operation, it is not necessary to generate it again.

[0122] In steps d to f and step p of the example shown in Figure 9, the microservice change system 10 receives the DAG structure generated in step b or r, and determines the task nodes that need to be executed based on the DAG structure, generating a list of tasks to be run. The microservice change system 10 determines whether the list of tasks to be run is empty. If the list is empty, it means that all tasks have been completed, there are no task nodes to be executed, and the DAG change scheduling has been completed, ending the execution. If the list is not empty, the microservice change system 10 executes step f, selecting a batch of tasks to be run concurrently. For example, every batch consists of 20 task nodes, and the microservice change system 10 selects a batch to execute all tasks concurrently. The execution flow for a single task is described starting from step g.

[0123] In steps g to h of the example shown in Figure 9, the microservice change system 10 executes a single task instance. First, it determines whether the task instance contains subtasks. If it does, step s is executed to generate a subtask DAG graph and execute the subtasks. For example, in the example shown in Figure 6, when the microservice change task uses a Loop task type, this step includes a subtask flow containing four sub-steps: "ScaleNewWorkload", "ScaleOldWorkload", "TrafficSwitch", and "RanualCheck". If the task instance does not contain subtasks, step i is executed to handle final-state resource change tasks and non-final-state change tasks, respectively.

[0124] In steps s to t of the example shown in Figure 9, for steps containing subtasks, the microservice change system 10 can generate the sub-DAG structure corresponding to the subtask and associate the sub-DAG structure with the task instance. Then, steps d and t are executed. Step d starts scheduling the execution of the sub-DAG. In step t, the microservice change system 10 polls and waits for the sub-DAG to finish execution. Specifically, the microservice change system 10 monitors the execution status of the sub-DAG generated in step s and waits for the sub-DAG to finish execution. Then, step d is executed to refresh the baseline data.

[0125] In steps i to j and step u of the example shown in Figure 9, during the execution of the task instance by the microservice change system 10, it is further determined whether the task instance is a final resource change task. If it is a final resource change task, step j is executed; if it is not a final resource change task, step u is executed. In step u, the microservice change system 10 calls the process action orchestration plugin to execute a non-final change.

[0126] In one possible implementation, during the process of final state resource change, the microservice change system 10 generates change baseline data based on the state transition path. The change baseline data includes one or more of the following: microservice orchestration artifact package, change input parameters, output data of final state resource change, and local variable information of final state resource change.

[0127] Please refer to Figure 9. In steps j to n of the example shown in Figure 9, if the task instance is a final-state resource change task, the microservice change system 10 can call the final-state arbitrator to allocate a unique state transition path for the final-state resource change task corresponding to the final-state resource subset. This state transition path indicates the tuple corresponding to the final-state resource change task, and the tuple includes the original state number and the target state number. Afterwards, the microservice change system 10 maintains the baseline data corresponding to the original state and the target state according to the generated state transition path to ensure that both the original state and the target state have corresponding change baseline data. The change baseline data can support the migration of the final-state resource subset to the original state or the target state.

[0128] In step i of the example shown in Figure 9, if the task instance is a final-state resource change task, the microservice change system 10 calls the final-state resource orchestration plugin to pass the state transition path generated in step j to the IaC system, completing the final-state resource change corresponding to the final-state resource subset. In step j, the microservice change system 10 monitors the task status and output data in steps i and u, and persists them, waiting for the task execution to complete.

[0129] In one possible implementation, after the microservice change task is completed, the microservice change system 10 needs to maintain change baseline data. This change baseline data includes one or more of the following: microservice orchestration artifact packages, change input parameters, output data for final-state resource changes, and local variable information for final-state resource changes. At this time, the change input parameters include change input parameters for final-state resource changes and change parameters for non-final-state changes.

[0130] Please refer to Figure 9. In steps n to o of the example shown in Figure 9, the microservice change system 10 refreshes the change baseline based on the execution status of the task instance. Subsequent changes can obtain change input data based on the latest change baseline. The refreshed change baseline includes the change results and output data corresponding to the final state resource changes. After this step, the execution flow for a single task instance ends. Once all concurrently executed task instances in this batch have finished executing, the execution of the next batch of task instances can begin.

[0131] In step u of the example shown in Figure 9, all change actions corresponding to this change request have been completed. The user can continue to initiate new change requests for the microservice change task based on the change status. For example, when the change status is a failed state, the microservice change system 10 initiates a retry or rollback operation; when the change status is a stuck pause state, the microservice change system 10 initiates a continue or rollback operation.

[0132] In one possible implementation, the final resource change task in this embodiment corresponds to multiple final resource change operations, and these multiple final resource change operations are change operations corresponding to the same subset of final resources. That is, the change process orchestration logic in the microservice orchestration artifact package can orchestrate multiple final resource change operations corresponding to the same subset of final resources, thereby enabling the computing device to make multiple calls to the IaC system corresponding to the same subset of final resources during the microservice change process to implement multiple final resource change operations.

[0133] It is understandable that the microservice change system 10 orchestrates multiple final resource change operations corresponding to the same final resource subset, and the input parameters, local variable information and output data of the final resource changes may be different.

[0134] As can be seen from the embodiment shown in Figure 9, the microservice change system 10 in this application embodiment maintains the change baseline data either after each resource state change is completed in the final state resource change operation, i.e., step k in Figure 9, or after each microservice change task instance is completed, i.e., step n in Figure 9. The process of change baseline management by the microservice change system 10 in this application embodiment is described below with reference to the accompanying drawings:

[0135] Please refer to Figure 10, which is a schematic diagram of a change baseline management process provided in an embodiment of this application. In step a of the example shown in Figure 10, the microservice change system 10 receives a change baseline update request during the execution of a microservice change task. The change baseline update request includes the change order of the microservice change task and related data of the microservice change execution task.

[0136] It should be noted that there is no limitation on the timing of baseline updates. For example, the microservice change system 10 can update the baseline data in real time before, during, and after the final resource change.

[0137] In steps b to c of the example shown in Figure 10, before updating the change baseline, the microservice change system 10 determines whether the current change order has a change baseline. If the current change order already has change baseline data, the microservice change system 10 only needs to update the change baseline data based on the existing change baseline. Otherwise, the microservice change system 10 needs to create new change baseline data corresponding to the change order.

[0138] The modified baseline data in this embodiment includes one or more of the following: microservice orchestration artifact package, modified input parameters, output data for final-state resource modifications, and local variable information for final-state resource modifications. The microservice orchestration artifact package includes modified process orchestration code and final-state resource orchestration code corresponding to the final-state resource subsets. Modified input parameters include process orchestration parameters, global input parameter values ​​for final-state resources, and unique input parameter values ​​for final-state resource subsets; process orchestration parameters are the modified parameters for non-final-state modifications. Final-state resource modification output data includes global output values ​​for final-state resources and output values ​​for each final-state resource subset. Local variable information for final-state resource modifications includes the global "locals" parameter value for the final-state resource and the "locals" parameter values ​​for each final-state resource subset.

[0139] It should be noted that the aforementioned changed baseline data can be the initial version baseline corresponding to the initial state of the change, and the content of the changed baseline data can be copied from the latest version baseline data of the previous change order. Subsequent changes to the final state resource subset will trigger a new state transition, and the changed baseline data will be updated again for the target state.

[0140] In steps d to e of the example shown in Figure 10, the microservice change system 10 further determines whether a new version of the change baseline needs to be generated. If the microservice change task in step a is a change to a final-state resource corresponding to a subset of final-state resources, and the target state in its state transition path does not have corresponding version baseline data, then the microservice change system 10 generates change baseline data based on the state allocation path. Specifically, the microservice change system 10 generates corresponding new version change baseline data based on the target state. Otherwise, the microservice change system 10 obtains the existing version change baseline, that is, it searches for the baseline data corresponding to the target state from the full baseline data of this change order.

[0141] In step e of the example shown in Figure 10, during the process of generating a new version change baseline by the microservice change system 10, the microservice change system 10 establishes a change baseline corresponding to the target state based on the target state of the final state resource state migration path, thereby ensuring that the new change baseline can drive the final state resource to migrate to the target state and includes the latest data generated by the previously run change actions.

[0142] The microservice change system 10 obtains the most recent state of the target state. For example, if the current state number is "S0.2", then the most recent state is "S0.1". If the most recent state is not the initial state "S0", the microservice change system 10 copies the microservice orchestration artifact package, change input parameters, and final state resource change output data based on the baseline data of the most recent state, and then calculates the local variable information of the final state resource change according to the code logic. If the most recent state is the initial state "S0", the microservice change system 10 re-establishes a new change baseline. The new change baseline establishes the microservice orchestration artifact package and change input parameters based on the input information related to this change order. The final state resource change output data is set to empty and dynamically refreshed during subsequent changes. The local variable information of the final state resource change is calculated based on the change input parameters and the final state resource change output data.

[0143] In steps f to h of the example shown in Figure 10, the microservice change system 10 further determines whether the change baseline needs to be updated. Specifically, based on the change order and the execution result of the change task in step a, the microservice change system 10 determines whether the baseline update is triggered by the completion of the change execution corresponding to the final state resource subset. If so, the baseline data associated with the final state resource is updated; otherwise, the change baseline does not need to be refreshed, and the process ends.

[0144] In step g of the example shown in Figure 10, during the process of the microservice change system 10 updating the baseline data associated with the final state resources, after the final state resource subset is executed, the output data of the step is refreshed to the change baseline data of the corresponding state, and other baseline data that depend on this output data are refreshed synchronously. Step g ensures that when the change task corresponding to a final state resource subset is completed, the latest version of the change baseline will be refreshed in a timely manner, and subsequent final state resource change tasks can obtain the latest input parameters, ensuring the correctness and timeliness of dynamic data transfer between final state resources.

[0145] In one possible implementation, the microservice change system 10 assigns state migration paths to final state resource change operations corresponding to one or more final state resource subsets based on a migration arbitrator. The state migration path is used to indicate the resource state number of the final state resource change operation. The state migration path includes one or more resource states, and each resource state corresponds to a unique resource state number.

[0146] Please refer to Figure 11, which is a schematic diagram of a state transition path provided in an embodiment of this application. In the example shown in Figure 11, when the microservice change system 10 executes a change operation corresponding to each final state resource subset, it first calls the migration arbitrator to allocate a unique state transition path. The state transition path is a tuple consisting of the original state number of this change and the target state number. Each final state resource change corresponding to the final state resource subset is based on the latest state number of this subset, and a new auto-incrementing state number is allocated to form a tuple of the original state and the target state. For example, the tuple (S0.1, S0.2) indicates that this change is transitioning from the original state "S0.1" to the target state "S0.2".

[0147] In the example shown in Figure 11, the state transition path change example includes state transition paths corresponding to three final state resource subsets. Assuming the initial state of the overall change is S0, five final state resource subset changes are initiated in chronological order from left to right. Specifically, the state transition path assigned to final state resource subset 1 when it performs its first change is (S0, S0.1), meaning it transitions from the initial state S0 to state S0.1. Similarly, when final state resource subsets 2 and 3 perform their first changes, they also transition from their respective initial states (S0) to a globally unique auto-incrementing state number, corresponding to the second and fourth global changes, respectively. In the third global change, final state resource subset 1 transitions from its latest state number (S0.1) to a new globally unique auto-incrementing number (S0.3), forming a transition path (S0.1, S0.3). Similarly, in the fifth global change, final state resource subset 2 corresponds to a transition path (S0.2, S0.5).

[0148] In one possible implementation, the microservice change system 10 performs checkpoint control on the microservice change process based on change process orchestration code. Checkpoint control is used to set control points between change operations corresponding to one or more final-state resource subsets. The microservice change system 10 can control the intermediate states of the change process based on the change process orchestration logic in the microservice orchestration artifact package, thereby supporting the customization and extension of the microservice change process.

[0149] In one possible implementation, during the final state resource change process, the microservice change system 10 executes the final state resource change task based on the final state resource orchestration plugin 104 control infrastructure, i.e., the code IaC system. The IaC system is used to change the current resource state of the microservice to the final state resource state. The final state resource change process in this embodiment is described below with reference to the accompanying drawings:

[0150] Please refer to Figure 12, which is a schematic diagram of a final state resource change process provided in an embodiment of this application. In step b of step a in the example shown in Figure 12, the microservice change system 10 receives a final state resource change execution request, which includes a subset of final state resources, a state transition path, and a change baseline. The microservice change system 10 determines whether the final state resource change corresponding to the subset of final state resources is a forward execution operation. If yes, step c is executed; otherwise, step f is executed. The forward execution operation includes one or more of the following: execution, continued execution, retry execution, etc.

[0151] In steps c to f of the example shown in Figure 12, if the final state resource change is a forward execution operation, the microservice change system 10 obtains the change baseline corresponding to the target state, including obtaining the target state number in the state migration path corresponding to the final state resource subset, thereby driving subsequent final state resource changes corresponding to the final state resource subset to migrate to the target state. If the final state resource change is not a forward execution operation, the microservice change system 10 obtains the baseline data corresponding to the source state, including obtaining the original state in the state migration path corresponding to the final state resource subset, thereby driving subsequent final state resource changes to roll back to the original state.

[0152] In steps d to e of the example shown in Figure 12, the microservice change system 10 generates the IaC change data required for the final state resource change based on the change baseline obtained in steps c and f. The IaC change data includes the final state resource orchestration code and input values. The input values ​​are determined by global input parameters in the change baseline, input parameters private to the final state resource subset, global "locals" local variable values, and private "locals" local variable values ​​for the final state resource subset. The microservice change system 10 executes the final state resource change based on the IaC change data, invoking the final state resource orchestration plugin to initiate the final state resource change for the final state resource subset to the IaC system.

[0153] As can be seen from the above embodiments, the microservice change system 10 in this application embodiment can define the orchestration logic of non-final state change operations and final state resource change operations in the microservice orchestration artifact package, thereby enabling the microservice change process to be automatically carried out in accordance with the change process orchestration logic in the microservice orchestration artifact package, thus improving the change efficiency of microservice change.

[0154] Based on the above method embodiments, this application also provides a microservice modification device, which is described in detail below.

[0155] Please refer to Figure 13, which is a schematic diagram of the structure of a microservice modification device provided in an embodiment of this application. In the example shown in Figure 13, the microservice modification device 1300 is used to implement the various steps performed by the microservice modification system in the above embodiments. The microservice modification device 1300 includes an acquisition unit 1301 and a processing unit 1302.

[0156] The acquisition unit 1301 is used to acquire a microservice orchestration artifact package. The microservice orchestration artifact includes final-state resource orchestration code and change process orchestration code. The final-state resource orchestration code manages the set of final-state resources involved in microservice changes. The set of final-state resources includes one or more subsets of final-state resources. The change process orchestration code orchestrates non-final-state change operations and final-state resource change operations. Final-state resource change operations include change operations corresponding to one or more subsets of final-state resources. The processing unit 1302 is used to generate a change execution plan based on the microservice orchestration artifact package. The change execution plan includes change elements involved in the microservice change. Change elements include non-final-state change operations and final-state resource change operations. Non-final-state change operations are imperative change operations without a specified final state, while final-state resource change operations are automatic change operations with a specified final state. The processing unit 1302 is also used to execute microservice change tasks according to the change execution plan.

[0157] In one possible implementation, the microservice change task includes non-final state change tasks and final state resource change tasks. The processing unit 1302 is specifically used to control the operation and maintenance service system to execute non-final state change tasks based on the process action orchestration plugin. The operation and maintenance service system includes one or more of the following: a monitoring system, an alarm system, a testing system, and a traffic switching system. The final state resource change task is executed based on the final state resource orchestration plugin-controlled infrastructure, i.e., the IaC system. The IaC system is used to change the current resource state of the microservice to the final state resource state, where the final state resource state includes the final state resource states corresponding to one or more subsets of final state resources.

[0158] In one possible implementation, the final state resource change operation includes multiple final state resource change operations, and the multiple final state resource change operations are final state resource changes corresponding to the same subset of final state resources.

[0159] In one possible implementation, the processing unit 1302 is further configured to perform checkpoint control on the microservice change process based on the change process orchestration code, wherein the checkpoint control is used to set control points between the final resource change operations corresponding to one or more final resource subsets.

[0160] In one possible implementation, the processing unit 1302 is further configured to allocate state migration paths for final state resource change operations corresponding to one or more final state resource subsets based on the migration arbitrator, wherein the state migration path is used to indicate the resource state number of the final state resource change operation.

[0161] In one possible implementation, the processing unit 1302 is further configured to store change baseline data corresponding to one or more resource states in the state migration path, and the change baseline data is used to perform rollback operations on one or more resource states.

[0162] In one possible implementation, the processing unit 1302 is further configured to update the change baseline data based on the execution result of the microservice change task. The change baseline data includes one or more of the following: microservice orchestration artifact package, change input parameters, final state resource change output data, and final state resource change local variable information.

[0163] It is understandable that the acquisition unit 1301 and processing unit 1302 in the microservice change device 1300 can be mapped as functional modules to each module in the microservice change system 10 in Figure 1, thereby realizing the functions of each module in the microservice change system 10.

[0164] It should be understood that the division of units in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, all units in the device can be implemented entirely through software calls from processing elements; all units can be implemented entirely in hardware; or some units can be implemented through software calls from processing elements, and some units can be implemented in hardware. For example, each unit can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as a program in memory, called and executed by a processing element of the device. Moreover, these units can be fully or partially integrated together, or implemented independently. The processing element mentioned here can also be called a processor, which can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above units can be implemented through integrated logic circuits in the processor element or through software calls from processing elements.

[0165] It is worth noting that, for the sake of simplicity, the above method embodiments are described as a series of actions. However, those skilled in the art should know that this application is not limited to the order of the described actions. Furthermore, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by this application.

[0166] Other reasonable combinations of steps that can be conceived by those skilled in the art based on the above description also fall within the scope of protection of this application. Furthermore, those skilled in the art should also be aware that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0167] Please refer to Figure 14, which is a schematic diagram of the structure of a computing device provided in an embodiment of this application. As shown in Figure 14, the computing device 1400 includes: a processor 1401, a memory 1402, a communication interface 1403, and a bus 1404. The processor 1401, the memory 1402, and the communication interface 1403 are coupled through the bus 1404. The memory 1402 stores instructions. When the execution instructions in the memory 1402 are executed, the computing device 1400 executes the method performed by the microservice change system in the above-described method embodiment.

[0168] The computing device 1400 may be one or more integrated circuits configured to implement the methods described above, such as: one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these forms of integrated circuits. Furthermore, when the units in the device can be implemented in the form of a processing element scheduler, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Alternatively, these units may be integrated together and implemented as a system-on-a-chip (SOC).

[0169] Processor 1401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0170] The memory 1402 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0171] The memory 1402 stores executable program code, and the processor 1401 executes the executable program code to implement the functions of the aforementioned units or modules, thereby realizing the microservice modification method described above. That is, the memory 1402 stores instructions for executing the microservice modification method described above.

[0172] The communication interface 1403 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1400 and other devices or communication networks.

[0173] In addition to the data bus, the 1404 bus can also include a power bus, a control bus, and a status signal bus. The bus can be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. The bus can be divided into address bus, data bus, and control bus.

[0174] Please refer to Figure 15, which is a schematic diagram of a computing device cluster provided in an embodiment of this application. As shown in Figure 15, the computing device cluster 1500 includes at least one computing device 1400.

[0175] As shown in Figure 15, the computing device cluster 1500 includes at least one computing device 1400. The memory 1402 of one or more computing devices 1400 in the computing device cluster 1500 may store the same instructions for executing the modification method of the microservice described above.

[0176] In some possible implementations, the memory 1402 of one or more computing devices 1400 in the computing device cluster 1500 may also store partial instructions for executing the aforementioned microservice modification method. In other words, a combination of one or more computing devices 1400 can jointly execute the instructions for executing the aforementioned microservice modification method.

[0177] It should be noted that the memory 1402 of different computing devices 1400 in the computing device cluster 1500 can store different instructions, which are used to execute some of the functions of the aforementioned node load control device. That is, the instructions stored in the memory 1402 of different computing devices 1400 can realize the functions of one or more modules in the acquisition unit and processing unit.

[0178] In some possible implementations, one or more computing devices 1400 in the computing device cluster 1500 can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc.

[0179] Please refer to Figure 16, which is a schematic diagram of computer devices in a computer cluster connected via a network according to an embodiment of this application. As shown in Figure 16, two computing devices 1400A and 1400B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device.

[0180] In one possible implementation, the memory in computing device 1400A stores instructions for performing the fetch unit function. Meanwhile, the memory in computing device 1400B stores instructions for performing the processing unit function.

[0181] It should be understood that the functions of computing device 1400A shown in Figure 16 can also be performed by multiple computing devices. Similarly, the functions of computing device 1400B can also be performed by multiple computing devices.

[0182] In another embodiment of this application, a computer-readable storage medium is also provided, which stores computer-executable instructions. When the processor of the device executes the computer-executable instructions, the device executes the method performed by the microservice change system in the above method embodiment.

[0183] In another embodiment of this application, a computer program product is also provided, which includes computer-executable instructions stored in a computer-readable storage medium. When the processor of the device executes the computer-executable instructions, the device performs the method executed by the microservice change system in the above method embodiment.

[0184] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0185] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

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

[0188] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for modifying microservices, characterized in that, include: Obtain a microservice orchestration artifact package, wherein the microservice orchestration artifact includes final state resource orchestration code and change process orchestration code. The final state resource orchestration code is used to manage the set of final state resources involved in microservice changes. The set of final state resources includes one or more subsets of final state resources. The change process orchestration code is used to orchestrate non-final state change operations and final state resource change operations. The final state resource change operations include change operations corresponding to the one or more subsets of final state resources. A change execution plan is generated based on the microservice orchestration artifact package. The change execution plan includes change elements involved in the microservice change. The change elements include non-final state change operations and final state resource change operations. The non-final state change operations are imperative change operations without a specified final state, and the final state resource change operations are automatic change operations with a specified final state. Perform the microservice change tasks according to the change execution plan.

2. The method according to claim 1, characterized in that, The microservice change tasks include non-final state change tasks and final state resource change tasks. Executing the microservice change tasks according to the change execution plan includes: The operation and maintenance service system is controlled by a process action orchestration plugin to execute the non-final state change task. The operation and maintenance service system includes one or more of the following: a monitoring system, an alarm system, a dial-up testing system, and a traffic switching system. The final resource change task is executed based on the final resource orchestration plugin control infrastructure, i.e., code IaC system. The IaC system is used to change the current resource state of the microservice to the final resource state, and the final resource state includes the final resource state corresponding to the one or more final resource subsets.

3. The method according to claim 2, characterized in that, The final state resource change operation includes multiple final state resource change operations, and the multiple final state resource change operations are final state resource changes corresponding to the same subset of final state resources.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The microservice change process is controlled by the change process orchestration code, and the control point is used to set control points between the final resource change operations corresponding to one or more final resource subsets.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The migration arbitrator assigns state migration paths to the final state resource change operations corresponding to the one or more final state resource subsets, and the state migration paths are used to indicate the resource state number of the final state resource change operation.

6. The method according to claim 5, characterized in that, The method further includes: The system stores change baseline data corresponding to one or more resource states in the state transition path, and the change baseline data is used to perform rollback operations on the one or more resource states.

7. The method according to any one of claims 1 to 6, characterized in that, After executing the microservice change task according to the change execution plan, the method further includes: The change baseline data is updated based on the execution result of the microservice change task. The change baseline data includes one or more of the following: the microservice orchestration artifact package, change input parameters, output data of final state resource change, and local variable information of final state resource change.

8. The method according to any one of claims 1 to 7, characterized in that, The change operations corresponding to the microservice change task include one or more of the following: execution operation, retry operation, and rollback operation.

9. A microservice modification device, characterized in that, include: The acquisition unit is used to acquire a microservice orchestration artifact package. The microservice orchestration artifact includes final-state resource orchestration code and change process orchestration code. The final-state resource orchestration code is used to manage the set of final-state resources involved in microservice changes. The set of final-state resources includes one or more subsets of final-state resources. The change process orchestration code is used to orchestrate non-final-state change operations and final-state resource change operations. The final-state resource change operations include change operations corresponding to the one or more subsets of final-state resources. The processing unit is configured to generate a change execution plan based on the microservice orchestration artifact package. The change execution plan includes change elements involved in the microservice change. The change elements include non-final state change operations and final state resource change operations. The non-final state change operations are imperative change operations without a specified final state, and the final state resource change operations are automatic change operations with a specified final state. The processing unit is also used to execute microservice change tasks according to the change execution plan.

10. The apparatus according to claim 9, characterized in that, The microservice change tasks include non-final state change tasks and final state resource change tasks, and the processing unit is specifically used for: The operation and maintenance service system is controlled by a process action orchestration plugin to execute the non-final state change task. The operation and maintenance service system includes one or more of the following: a monitoring system, an alarm system, a dial-up testing system, and a traffic switching system. The final resource change task is executed based on the final resource orchestration plugin control infrastructure, i.e., code IaC system. The IaC system is used to change the current resource state of the microservice to the final resource state, and the final resource state includes the final resource state corresponding to the one or more final resource subsets.

11. The apparatus according to claim 10, characterized in that, The final state resource change operation includes multiple final state resource change operations, and the multiple final state resource change operations are final state resource changes corresponding to the same subset of final state resources.

12. The apparatus according to any one of claims 9 to 11, characterized in that, The processing unit is also used for: The microservice change process is controlled by the change process orchestration code, and the control point is used to set control points between the final resource change operations corresponding to one or more final resource subsets.

13. The apparatus according to any one of claims 9 to 12, characterized in that, The processing unit is also used for: The migration arbitrator assigns state migration paths to the final state resource change operations corresponding to the one or more final state resource subsets, and the state migration paths are used to indicate the resource state number of the final state resource change operation.

14. The apparatus according to claim 13, characterized in that, The processing unit is also used for: The system stores change baseline data corresponding to one or more resource states in the state transition path, and the change baseline data is used to perform rollback operations on the one or more resource states.

15. The apparatus according to any one of claims 9 to 14, characterized in that, The processing unit is also used for: The change baseline data is updated based on the execution result of the microservice change task. The change baseline data includes one or more of the following: the microservice orchestration artifact package, change input parameters, final state resource change output data, and final state resource change local variable information.

16. The apparatus according to any one of claims 9 to 15, characterized in that, The change operations corresponding to the microservice change task include one or more of the following: execution operation, retry operation, and rollback operation.

17. A computing device cluster, characterized in that, The system includes at least one computing device, the computing device including a processor coupled to a memory, the processor being used to store instructions that, when executed by the processor, cause the cluster of computing devices to perform the method of any one of claims 1 to 8.

18. A computer-readable storage medium having instructions stored thereon, characterized in that, When the instructions are executed, they cause the computer to perform the method of any one of claims 1 to 8.

19. A computer program product, the computer program product comprising instructions, characterized in that, When the instructions are executed, they cause the computer to implement the method of any one of claims 1 to 8.

Images