Cloud resource change consistency control and failure rollback method based on incremental patch update

Abstract

The application provides a cloud resource change consistency control and failure rollback method based on incremental patch update, relates to the technical field of cloud resource management, and realizes fine control of the change process through baseline reading, incremental patch and marker generation, atomic update submission, convergence determination, failure classification, accurate rollback, and standardized processes of rollback convergence confirmation by binding a unique marker identification for each change attempt through sub-item / field level incremental patch update. Meanwhile, various deformation implementation schemes are designed to adapt to different cloud resource change scenarios. The application greatly reduces the change surface and concurrent coverage risk, avoids historical state misjudgment from the mechanism, realizes accurate rollback after failure without damaging concurrent new requests, establishes observable causal correlation of change attempts, controller observation, and state write-back under the premise of not introducing heavy transactions and high-cost lock mechanisms, and improves the stability, consistency and traceability of cloud resource changes.

Description

Technical Field

[0001] This invention relates to the field of cloud resource management technology, and more specifically, to a method for consistent control and rollback of cloud resource changes based on incremental patch updates. Background Technology

[0002] With the rapid development of cloud computing technology, the resource scale and business complexity of cloud platforms continue to increase, and users have increasingly higher requirements for the stability and consistency of cloud resource purchases, configuration changes, and configuration updates. Existing cloud platforms generally adopt a chain of "receiving change requests → writing to pre-allocated objects / pre-allocated records → controller asynchronously executing creation / update → status write-back" to realize cloud resource changes. Among them, the pre-allocated object, as the key object carrying the expected configuration of cloud resources, usually contains a spec field (storing the expected configuration) and a status field (storing the actual execution result). The controller listens for changes in the spec field of the pre-allocated object, calls the resource interface to execute the actual resource operation, and writes the execution result back to the status field for querying and auditing by the business side.

[0003] However, existing cloud resource modification solutions have many shortcomings under the distributed asynchronous execution architecture, specifically:

[0004] 1. Difficulty in ensuring consistency: A single cloud resource change often involves the modification of multiple fields / sub-items. Existing solutions often use full overwrite or multiple writes to update the pre-occupied object, which can easily lead to intermediate states where some sub-items have taken effect and others have failed. This results in inconsistencies between the expected configuration (spec field) and the actual configuration (status field), and it is difficult to fix quickly.

[0005] 2. Lost updates under concurrency: In cloud platforms, it is common for multiple change requests to be initiated concurrently and for multiple controllers to process them in parallel. If the update granularity is coarse (such as writing the entire spec field) and there is a lack of effective conflict control and observation mechanisms, configuration overwriting, configuration drift, or incorrect merging can easily occur, resulting in lost updates and affecting business continuity.

[0006] 3. Inaccurate rollback upon failure: After a change fails, the spec field of the pre-occupied object may have been written with a new expected value, but the actual cloud resources have not taken effect or have only partially taken effect. Because the existing solution lacks a unique identifier bound to "this change attempt", it is impossible to accurately determine the rollback scope and rollback target, which can easily lead to problems such as rolling back subsequent new requests by mistake, missing key fields, or even causing secondary failures.

[0007] 4. Misjudgment of status: The existing solution only uses general success / failure indicators to determine the change result, without establishing a causal relationship between the change attempt and the controller's processing result. This may lead to the mistaken recognition of the success status of the previous change as the success status of the current change, resulting in erroneous approval and causing hidden configuration inconsistency issues.

[0008] The root cause of these problems lies in the lack of transactional guarantees in the asynchronous execution architecture of distributed cloud platforms. The expected configuration of pre-allocated objects and the actual configuration of cloud resources can only achieve eventual consistency, not strong consistency. Furthermore, concurrent updates and retries are common occurrences in cloud resource changes, and existing solutions lack sophisticated control mechanisms for this. While existing heavy-transaction and high-cost locking mechanisms can achieve strong consistency, they significantly reduce the cloud platform's concurrent processing capabilities and increase system overhead, contradicting the elastic and high-availability design principles of cloud platforms. Therefore, they cannot be directly applied to cloud resource change scenarios. Summary of the Invention

[0009] Therefore, the purpose of this invention is to propose a lightweight, highly compatible, and highly accurate method for consistent control and rollback of cloud resource changes based on incremental patch updates. This method uses sub-item / field-level incremental patch updates as its core, combined with a unique marker to bind change attempts and processing results. Through standardized processes and multi-dimensional variations, it solves problems such as difficulty in ensuring consistency, easy loss of concurrent updates, inaccurate rollbacks, and misjudgments of status during existing cloud resource changes, without introducing heavy transactions or high-cost locking mechanisms, while ensuring the concurrent processing capabilities of the cloud platform. This improves the operational efficiency of cloud resource changes.

[0010] This invention provides a method for consistent control and rollback of cloud resource changes based on incremental patch updates, comprising the following steps:

[0011] S1: Baseline Reading: Read the baseline spec field, status field, and version information (such as resourceVersion or equivalent version number) of the current pre-occupied object, and locate the set of resource sub-items and target sub-items involved in this change according to the business association key or preset rules;

[0012] S2: Generate Incremental Patch and Marker: Attempt to generate a unique marker for this change, construct sub-item / field-level incremental patches based on the cloud resource change type (additional purchase / configuration change), and generate the rollback basis corresponding to this change. The rollback basis is the baseline snapshot or the reverse patch rollbackPatch.

[0013] S3: Atomic update of Patch submission: Depending on the actual application scenario, choose any one of the atomic update methods, such as JSON Merge Patch, JSONPatch, or Server-Side Apply, and submit incremental patches with version control information. When version conflicts or field conflicts occur, execute the retry strategy of rereading the baseline and recalculating the patch, and limit the maximum number of retries.

[0014] S4: Waiting and Convergence Determination: After the patch is submitted, the status field of the pre-occupied object is read through polling or Watch mechanism. The change is determined to be converged successfully if and only if the dual conditions of final state determination and observation consistency determination are met at the same time. If the dual conditions are not met due to timeout, it is determined to be a failure / timeout. The consistency check of key fields is superimposed to further improve the accuracy of the determination.

[0015] S5: Failure / Timeout Classification: Based on whether the marker was observed and the specific type of failure, failures / timeouts are classified into three categories: controller unprocessed (no marker observed), controller processing failed (marker observed but execution failed), and business key field validation failed (convergence judgment passed but business fields are inconsistent). A corresponding processing strategy is matched for each type of failure.

[0016] S6: Precise Rollback: For failure scenarios that require rollback, a marker threshold check is performed before rollback to confirm that the sub-items / fields corresponding to this change still exist and belong to the result of this change. Then, a rollback patch is generated according to the rollback basis, and the rollback patch is submitted using the same atomic update method as step S3. Only the sub-items / fields involved in this change are rolled back, without affecting other sub-items or concurrent new requests.

[0017] S7: Rollback Convergence Confirmation and Recording: After the rollback patch is submitted, repeat the convergence judgment process in step S4 to confirm that the rollback operation was successfully executed; at the same time, record all information of this change, including the reason for failure, rollback result, processing time, number of retries, submission / rollback timestamps and other audit information to ensure the idempotency and traceability of the entire process.

[0018] Furthermore, the pre-occupied object described in this invention is the core object that carries the expected configuration of cloud resources and serves as the interaction medium between the cloud platform controller and the change service. It at least includes the spec field and the status field.

[0019] The spec field is used to store the expected configuration of cloud resources. It sets a set of resource sub-items (such as spec.items[]) to describe the changeable cloud resource sub-items, such as EIP, Volume, cloud server specifications, etc. The resource sub-item set supports parallel changes of multiple sub-items.

[0020] The status field stores the actual execution results and status information of cloud resource changes. It includes observation fields to prove that the controller has processed the change and to establish a causal relationship between the change attempt and the controller's processing. The observation fields include at least one of status.observedMarker, status.observedGeneration, and status.conditions, which can be flexibly combined according to the scenario.

[0021] Furthermore, the marker described in this invention is a unique identifier bound to a change attempt and is the core of achieving accurate change and rollback. Its generation method can be any one of the following: sub-order number, sub-resource idempotent key, sub-order number + resource type combination key, or UUID, which can be selected according to the uniqueness requirements of the business scenario. The core function of the marker is to accurately locate the scope of this change, so it needs to be written into all resource sub-items involved in this change as a unique identifier for this change.

[0022] Furthermore, in step S2, the generation logic for incremental patches and rollback bases differs depending on the type of cloud resource change, specifically in the following scenarios:

[0023] Add-purchase scenario: Construct a newItem object, which contains the business fields of this add-purchase (such as resource specifications, quantity, carrier, etc.) and the marker of this change. The incremental patch only expresses the operation of "appending the newItem to the resource sub-item set of the spec"; the rollback basis is to record the marker added this time, so as to accurately delete the added sub-item in case of failure.

[0024] In the scenario of configuration change: First, locate the old resource sub-item oldItem that needs to be modified by using the preset business association key or historical marker, and record the old value of the field to be modified in oldItem (such as old bandwidth, old specifications, etc.). The incremental patch only expresses the operation of "replacing the target field in oldItem with the new value". The rollback is based on the recorded old value (baseline snapshot) or generating a rollback patch (reverse patch) that is the opposite of the forward patch, which is used to restore the target field to the state before the change in case of failure.

[0025] The rollback method described in this invention includes at least one of baseline snapshot and rollbackPatch, and the two methods can be used alone or in combination.

[0026] Baseline snapshots are the old values ​​of fields / sub-items involved in this change or the complete old resource sub-items. They only record the relevant content of this change and do not record the full configuration, thus reducing storage overhead. Their advantages are that they are intuitive and interpretable, and are suitable for rollback in configuration change scenarios.

[0027] A rollback patch is an operation instruction that is completely opposite to a forward incremental patch, realizing the reverse mapping of operations. For example, if the forward operation is an add operation, the reverse operation is a remove operation, and if the forward operation is a replace_new operation, the reverse operation is a replace_old operation. Its advantages are fast rollback execution speed, clear engineering implementation, and suitability for all change scenarios.

[0028] Furthermore, step S3 provides three atomic update methods for patches to adapt to different cloud platform architectures and change scenarios. All three methods can achieve atomic commit of incremental patches, avoiding intermediate states. Specifically:

[0029] Atomic updates based on JSON Merge Patch: Suitable for scenarios involving object field replacement and stable array reconstruction on the client side. It is simple to implement and highly versatile. The specific steps are: a. Read the pre-existing object baseline to obtain the oldSpec and version number; b. On the client side, calculate the newSpec based on the oldSpec, modifying only the target child item while keeping irrelevant fields unchanged; c. Construct a MergePatch containing only the top-level field to be updated (e.g., {"spec":{"items":newItems}}); d. Submit the Patch with the resourceVersion precondition, using the CAS mechanism to achieve atomicity; e. If a conflict is returned, reread the baseline → recalculate the newSpec → resubmit, until the maximum number of retries is reached.

[0030] Atomic updates based on JSON Patch: Suitable for precise add / remove / replace operations on array items, offering the finest granularity and minimal change scope, making it the preferred method of this invention and most conducive to precise rollback; the specific steps are as follows: a. Read the baseline of the pre-reserved object and determine the array path of the resource item collection (e.g., / spec / items); b. When adding items, submit the add operation, with the path / spec / items / - and the value being newItem containing the marker; c. When changing the configuration, locate the index i of the target item in the resource item collection according to the marker, submit the replace operation, with the path / spec / items / i / field and the value being the new field value; d. If the index does not exist or returns a conflict, reread the baseline, relocate the index i, and submit again;

[0031] Atomic updates based on Server-Side Apply (SSA): Suitable for scenarios with multiple clients writing concurrently and where the server is expected to handle field merging uniformly, offering strong concurrency compatibility. The specific steps are: a. The client uses a fieldManager as a unique identifier and submits only the desired fragment containing the fields to be changed, without submitting the full configuration; b. After receiving the data, the server performs field merging and ownership determination based on the fieldManager, with each field owned by the fieldManager that last submitted; c. If a field conflict occurs (the same field is modified by multiple fieldManagers), the server returns conflict information; d. The client performs retries, enters a serial queue, or downgrades to JSON Patch submission according to a preset strategy.

[0032] All three atomic update methods adhere to the principle of minimal change, committing only the fields / sub-items involved in the current change and not modifying irrelevant content, significantly reducing the scope of change and the probability of concurrent overwrite; at the same time, they are all equipped with conflict detection and retry mechanisms, transforming "silent overwrite" into "visible conflict", improving the controllability of changes.

[0033] Furthermore, the convergence determination in step S4 is a crucial step in avoiding state misjudgment. A dual determination mechanism is employed, consisting of final state determination and observation consistency determination; neither can be omitted. This mechanism eliminates interference from historical states, preventing the misidentification of past successful states as current successful states. Specifically:

[0034] Final state determination: The status field of the pre-occupied object enters a clear success or failure final state, that is, status.phase is Success or Failed, excluding the interference of intermediate states (such as Pending, Processing);

[0035] Consistency of observation criteria: Meeting any one of the following conditions is sufficient. The implementation method is flexible and can be adapted to existing mechanisms on different cloud platforms:

[0036] The status.observedMarker is exactly the same as the marker for this change. After the controller processes this change, it writes the marker back to status.observedMarker, making the causal relationship the most direct.

[0037] status.observedGeneration is greater than or equal to the generation version number corresponding to this commit. generation is the global version number of the preserving object, which increments with each change to adapt to the native version mechanism of the cloud platform.

[0038] The status.conditions contains the processing result conditions corresponding to the marker or generation of this change. status.conditions is a multi-dimensional status record collection that can record information such as processing result, failure reason, and processing time, and has strong interpretability.

[0039] To further improve the accuracy of convergence determination, for business scenarios with extremely high consistency requirements, a key field consistency check can be added on top of the dual determination mechanism to verify whether the actual effective configuration is consistent with the expected configuration, thus avoiding the hidden problem of the status showing success but the actual configuration being inconsistent.

[0040] This invention provides two methods for verifying the consistency of key fields, which can be flexibly selected according to the scenario, including:

[0041] Key fields are verified one by one: Only the key fields of this change (such as bandwidth, specifications, quantity, carrier, etc.) are compared one by one, and all fields are not verified. While ensuring the accuracy of the verification, the verification cost is controlled and resources are not wasted.

[0042] configHash validation: The set of key fields for this change is normalized and serialized (fixed field order and data format), and a unique hash value is calculated and written to spec.expectedHash. After the controller processes the resource change, the same normalized serialization and hash calculation are performed on the key fields that actually take effect, and the result is written to status.appliedHash. When spec.expectedHash and status.appliedHash are completely identical, the key field validation is considered successful. The advantages of this method are low validation cost, clear coverage of the field set, and reduced risk of missed validations.

[0043] Furthermore, in step S5, the failure / timeout is categorized and processed according to the specific reasons, avoiding a one-size-fits-all approach and improving the rationality and accuracy of failure handling. The specific categorization and corresponding strategies are as follows:

[0044] Unprocessed by the controller: The patch was successfully submitted, but no marker was observed, indicating that the controller may not have detected the change or started processing. In this case, a safe rollback or retry strategy is executed. A safe rollback directly deletes the changed content in the pre-emptive object, while the retry strategy re-executes steps S1-S4, which is suitable for temporary network fluctuations or scenarios with high controller load.

[0045] Controller processing failure type: The marker has been observed, but the status field shows a failed final state, indicating that the controller has processed this change but the execution failed. At this time, the precise rollback strategy is executed, and the fields / sub-items of this change are restored according to the rollback basis.

[0046] Business-critical field validation failure type: If the convergence judgment passes (final state + observation consistency), but the critical field consistency validation fails, it is considered as implicit inconsistency. In this case, a precise rollback or compensation strategy is executed. The compensation strategy is to re-execute the change operation to correct the actual configuration to the expected configuration, which is suitable for scenarios where the configuration has not fully taken effect.

[0047] Furthermore, the precise rollback in step S6 is one of the main innovations of this invention. Through marker threshold verification and sub-item / field-level rollback, only the content involved in this change is rolled back, without affecting other sub-items or concurrent new requests, thus avoiding erroneous rollbacks. The specific process is as follows:

[0048] Marker threshold verification: Before rollback, the spec field of the pre-owned object is read again to confirm that the target sub-item / field of this change still exists and belongs to the result of this change, avoiding erroneous rollback due to concurrent new requests modifying or deleting the target sub-item; Specifically, when rolling back an additional purchase, it is confirmed that there is still a new sub-item in the resource sub-item set of spec with the marker consistent with the marker of this change, if not, the rollback is terminated directly; when rolling back a configuration change, it is confirmed that the resource sub-item corresponding to the marker still exists, and the field status can be identified as the result of this change (such as the field value being consistent with the new value of this change), if not, the rollback is terminated;

[0049] Generate rollback patch: Based on the rollback basis generated in step S2, generate a rollback patch in combination with the type of change this time; the rollback patch for the purchase scenario is a remove operation, which deletes the newly added sub-item corresponding to the marker; the rollback patch for the configuration change scenario is a replace operation, which restores the target field to the old value of the baseline snapshot, or directly applies the reverse patch rollbackPatch.

[0050] Perform atomic rollback: Submit the rollback patch using the same atomic update method as in step S3 to ensure the atomicity of the rollback operation and avoid intermediate states during the rollback process; the rollback patch only includes the rollback content of this change and does not modify irrelevant fields / sub-items.

[0051] Furthermore, the rollback convergence confirmation and recording in step S7 are key steps to ensure process closure and traceability:

[0052] Rollback convergence confirmation: After the rollback patch is submitted, repeat the convergence determination process in step S4 to confirm that the rollback operation has been processed by the controller and executed successfully, and ensure that the spec field of the pre-occupied object after rollback is consistent with the actual cloud resource configuration; if the rollback fails, retry according to the reason for failure until the rollback is successful or the maximum number of retries is reached.

[0053] Full information recording: Records all information related to this change and rollback, including but not limited to: change request identifier, marker identifier, change type, submission time, reason for failure, rollback time, processing time, number of retries, atomic update method, rollback result, operator / service identifier, etc. All recorded information is persistently stored to support subsequent auditing, problem localization, and data analysis.

[0054] In this invention, in order to adapt to different cloud platform architectures, business scenarios and consistency requirements, a multi-dimensional variant implementation scheme is designed, including Patch form variant, marker storage location variant, rollback basis variant, convergence judgment variant, and consistency verification variant. Each variant scheme can be used independently or in combination to improve the compatibility and flexibility of this invention.

[0055] Patch format variations: namely, the three methods provided in step S3, namely JSON Merge Patch, JSON Patch, and Server-SideApply, which are adapted to different concurrency scenarios, array processing requirements, and server capabilities respectively;

[0056] Marker storage location variations: In addition to the preferred option of "as a sub-field of spec resource", the following options are also available:

[0057] a. Write the annotation field of the pre-occupied object to record the lastMarker or marker list index, which is suitable for object-level serial changes;

[0058] b. Write the label field of the pre-reserved object for queue filtering / batch processing. Due to character length limitations, it is not recommended to use it as the sole basis for rollback.

[0059] The c.spec field is set to marker and the status field is set to observedMarker, which achieves two-way binding between changes and observations and can best solve the problem of misjudgment of old states.

[0060] d. Create an independent ChangeRecord object to record the marker, pre-occupied object identifier, rollback basis, and change stage. The rollback basis is more complete and the audit capability is stronger, making it suitable for scenarios with high traceability requirements.

[0061] Rollback can be based on two methods: baseline snapshot and rollbackPatch. The choice can be made based on the type of change and the difficulty of project implementation.

[0062] Convergence determination variations include three methods: observedMarker determination, observedGeneration determination, and conditions determination, which can be selected based on the cloud platform's native mechanism and causal relationship requirements.

[0063] Consistency verification variations include two methods: item-by-item verification of key fields and configHash verification. The choice can be made based on consistency requirements and verification costs.

[0064] This invention implements various modified schemes by designing patch format, marker storage location, rollback basis, convergence judgment, and consistency verification. Each scheme can be used independently or in combination, adapting to different cloud platform architectures, business scenarios, consistency requirements, and concurrency scenarios. It supports changes such as purchasing, modifying, and updating configurations of various cloud resources, including computing, storage, network, and security, and has a wide range of applications.

[0065] Furthermore, this invention also provides a quantitative statistical method for the effect of changes. Through implementable indicators and calculation methods, the technical effects of this invention are quantified, facilitating technology implementation and effect verification. The main quantitative indicators include:

[0066] Change surface ratio: This metric is defined as the number of field paths (or JSON Patch operations) involved in this change / the total number of field paths of the spec field in the pre-reserved object. When updating with full coverage, this ratio is approximately 1. The incremental Patch update of this invention can reduce this ratio to an extremely low level. For example, in the example calculation, the total number of normalized field paths of the spec field is N=200. If only 4 paths are modified in this change, then the change surface ratio is 4 / 200=0.02, which means the change surface is reduced by approximately 98%.

[0067] Conflict visibility rate: The metric is defined as version conflict / field conflict / retry count ÷ total commit count, which is used to prove that the present invention transforms "silent overwrite" into "visible conflict and triggering retry / serialization", thereby improving the controllability of changes;

[0068] False Coverage Rate: The metric is defined as the number of rollbacks or manual interventions caused by concurrent coverage divided by the total number of changes, and is used to reflect the actual effect of the present invention in reducing the risk of concurrent coverage.

[0069] False positive rate: The metric is defined as the number of times "Success was read but the controller did not process the change" ÷ the total number of judgments, which is used to prove that the dual convergence judgment mechanism of the present invention can significantly reduce the probability of false state judgment.

[0070] The statistical data of the above-mentioned quantitative indicators can be obtained through the logs and monitoring system of the cloud platform. The change surface ratio can be obtained from the schema normalization statistics of the pre-occupied object and the statistics of the number of patch operations. The conflict visibility rate, false coverage rate, and false judgment rate can be obtained from the commit logs, rollback logs, and judgment logs of the change service. The quantitative results can be directly used for the technical effect verification and optimization of this invention.

[0071] This invention also provides a cloud resource management system for implementing the incremental patch update-based cloud resource change consistency control and failure rollback method, including a request client, a change service module, a pre-allocated object storage module, a controller module, a resource interface module, a consistency verification module, and a rollback module. These modules work collaboratively to achieve consistent control and precise rollback of cloud resource changes. The functions of each module are as follows:

[0072] The request end serves as the entry point for users / business systems to initiate cloud resource change requests, supporting various change types such as additional purchases and configuration changes, and submitting the changed business parameters;

[0073] The change service module is the core processing module of this system. It executes steps S1-S5 and S7 of the above method, including baseline reading, incremental patch and marker generation, patch atomic submission, convergence determination, failure classification, rollback result confirmation and information recording.

[0074] The pre-owned object storage module is used to persistently store all information of pre-owned objects (spec field, status field, version information, annotation, label, etc.), as well as audit records of all changes and rollbacks, and supports high-concurrency read / write / listening operations;

[0075] The controller module is used to listen for changes to pre-owned objects in the pre-owned object storage module, call the resource interface module to perform actual cloud resource change operations, and write back the processing results (success / failure, marker, generation, etc.) to the status field of the pre-owned object.

[0076] The resource interface module is the unified access interface for the cloud resource pool. It connects to various cloud resources such as computing, storage, network, and security, executes resource purchase, configuration, and deletion operations issued by the controller module, and returns the actual execution results.

[0077] The consistency verification module is used to perform consistency verification of key fields (item-by-item verification / configHash verification) and convergence determination in step S4, and returns the verification / determination results to the change service module;

[0078] The rollback module is used to execute step S6 of the above method, including marker threshold verification, rollback patch generation, and atomic commit of the rollback patch, to achieve precise rollback after failure.

[0079] The aforementioned cloud resource management system features a distributed architecture, with modules interacting through standardized interfaces. It supports horizontal scaling, adapts to cloud resource pools of different sizes, and is not dependent on a specific cloud platform architecture, exhibiting strong compatibility.

[0080] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0081] The cloud resource change consistency control and failure rollback method based on incremental patch updates provided by this invention adopts incremental patch updates at the sub-item / field level, modifying only the content involved in the current change and avoiding irrelevant fields / sub-items, significantly reducing the change surface (by more than 90%). This reduces intermediate states of partial effectiveness and partial failure from the source, improving the consistency between expected and actual configurations. Simultaneously, all patches are submitted atomically, avoiding intermediate states during the update process and further ensuring consistency. By adhering to the principle of minimum change, the probability of concurrent field intersections is reduced. Furthermore, concurrency control mechanisms such as conflict detection, retries, and serialization are incorporated, transforming the "silent overwriting" in existing technologies into "visible conflicts," improving the controllability of changes. Server-Side The Apply method also supports server-side field merging and ownership determination, significantly improving compatibility with concurrent updates from multiple clients, reducing the risk of concurrent overwrite, and resolving update loss issues under concurrency. It binds a unique marker to each change attempt, using marker threshold validation to accurately locate the rollback scope, rolling back only the sub-items / fields involved in the current change, without affecting other sub-items or concurrent new requests. This solves the problems of full-order rollback, erroneous rollback of subsequent requests, and missed rollback of critical fields in existing technologies. Simultaneously, the rollback operation uses an atomic update method to ensure consistency during the rollback process, avoiding erroneous rollbacks and secondary failures. A dual convergence determination mechanism of final state determination and observation consistency determination establishes an observable causal relationship between the current change attempt, controller observation, and state writeback, eliminating interference from historical states and fundamentally preventing... This invention addresses the issue of mistaking historical success states for current success states; optional key field consistency checks can also uncover implicit configuration inconsistencies, further improving judgment accuracy; this invention achieves the above technical effects without introducing heavy transactions and high-cost locking mechanisms. All mechanisms are lightweight designs, implemented only through incremental patches, marker identification, and standardized processes, without reducing the cloud platform's concurrent processing capabilities or significantly increasing system overhead, aligning with the cloud platform's elastic and highly available design philosophy; this invention designs a standardized closed-loop process from change submission to convergence judgment, failure classification, precise rollback, and rollback confirmation, while simultaneously recording full audit information for changes and rollbacks, ensuring the process's idempotency and traceability; operations and maintenance personnel can quickly locate problems through audit information, significantly improving the operational efficiency of cloud resource changes. Attached Figure Description

[0082] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0083] In the attached diagram:

[0084] Figure 1 This is a schematic diagram of the architecture of the cloud resource management system according to an embodiment of the present invention;

[0085] Figure 2 The flowchart below shows the cloud resource change consistency control and failure rollback method based on incremental patch updates according to an embodiment of the present invention:

[0086] Figure 3 This is a detailed flowchart illustrating the precise rollback process in an embodiment of the present invention.

[0087] Figure 4 This is a timing diagram illustrating cloud resource changes and rollbacks according to an embodiment of the present invention. Detailed Implementation

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

[0089] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0090] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0091] The embodiments of the present invention will be described in further detail below.

[0092] Example

[0093] This invention provides a method for consistent control and rollback of cloud resource changes based on incremental patch updates, including the following steps:

[0094] S1. Baseline Reading: Read the baseline spec field, status field, and version information of the current pre-occupied object to locate the set of resource sub-items and target sub-items involved in this change;

[0095] The pre-occupied object is the core object that carries the expected configuration of cloud resources, and includes at least the spec field and the status field. The spec field sets a set of resource sub-items to describe the changeable cloud resource sub-items. The status field sets observation fields to prove that the controller has processed the change. The observation fields include status.observedMarker, status.observedGeneration, and status.conditions.

[0096] S2. Generate Incremental Patch and Marker: Attempt to generate a unique marker for this change, construct an incremental patch based on the cloud resource change type, and simultaneously generate the rollback basis for this change;

[0097] The marker is a unique identifier bound to a change attempt. It can be a sub-order number, a sub-resource idempotent key, a combination key of sub-order number and resource type, or a UUID. The marker is written into the resource sub-items involved in this change to accurately locate the scope of this change.

[0098] Specifically, the location where the marker is stored includes any one or a combination of the following:

[0099] As an independent field within the resource sub-item of the spec field;

[0100] Write the annotation field of the pre-occupied object to record the lastMarker or marker list index;

[0101] Write the label field of the reserved object for queue filtering / batch processing;

[0102] The spec field is written to the marker and the status field is written to the corresponding observedMarker;

[0103] Create a separate ChangeRecord object to record the marker, pre-reserved object identifier, rollback basis, and change stage.

[0104] Cloud resource change types include purchase and configuration change. When purchasing, the incremental patch is used to express the addition of a new resource sub-item, and the marker of this change is embedded in the new resource sub-item. When configuring, the old resource sub-item is located by the marker, and the incremental patch is used to express the target field of the old resource sub-item to be replaced, while recording the old value of the target field of the old resource sub-item.

[0105] The rollback is based on at least one of a baseline snapshot and a rollback patch; the baseline snapshot is the old value of the field / sub-item involved in this change or the old resource sub-item; the rollback patch is the operation instruction opposite to the forward incremental patch, realizing the reverse mapping of add and remove, replace _new and replace _old.

[0106] S3. Atomic update of Patch submission: Use any of the atomic update methods of JSON Merge Patch, JSON Patch or Server-SideApply to submit incremental Patch with version control information. When a conflict occurs, execute a retry strategy of rereading and recalculating.

[0107] The atomic update method of JSON Merge Patch includes: reading the baseline of the pre-occupied object to obtain oldSpec and version number, calculating newSpec on the client side based on oldSpec to modify only the target sub-item, constructing MergePatch containing only the top-level field that needs to be updated, submitting with resourceVersion as a precondition, and rereading the baseline and recalculating newSpec before retrying in case of conflict.

[0108] The atomic update methods of JSON Patch include: reading the baseline of the pre-occupied object and specifying the array path of the resource sub-item collection; when purchasing additional items, submitting an add operation to append new resource sub-items containing markers; when changing configurations, locating the index of the resource sub-item by marker and submitting a replace operation to replace the target field; and when the index does not exist or conflicts, rereading the baseline and relocating the index before retrying.

[0109] The atomic update method of Server-Side Apply includes: the client uses fieldManager as the identifier, submits the expected fragment containing only the fields to be changed, the server performs field merging and ownership determination, returns conflict information when field conflicts occur, and the client performs retry, enters the serial queue, or degrades to JSON Patch submission according to the preset strategy.

[0110] S4. Waiting and convergence determination: After the patch is submitted, poll or watch to read the status field of the pre-occupied object. If and only if the dual conditions of final state determination and observation consistency determination are met, the change is determined to be converged; otherwise, it is determined to be a failure / timeout.

[0111] The final state determination is when the status field of the pre-occupied object enters the final state of success or failure; the observation consistency determination is when any of the following conditions are met: status.observedMarker is completely consistent with the marker of this change; status.observedGeneration is greater than or equal to the generation version number corresponding to this commit; status.conditions contains processing result conditions corresponding to the marker or generation of this change; on the basis of the final state determination and the observation consistency determination, the consistency check of key fields is superimposed.

[0112] Key field consistency verification includes either key field item-by-item verification or configHash verification. Key field item-by-item verification compares only the key fields of this change, without performing a full field verification. configHash verification normalizes and serializes the set of key fields of this change and calculates their hash values, which are then written to spec.expectedHash. After processing by the controller, the actual effective key field hash values ​​are written to status.appliedHash. When spec.expectedHash and status.appliedHash are consistent, the key field verification is considered successful.

[0113] S5. Failure / Timeout Classification: Based on whether a marker was observed and the failure type, failures / timeouts are classified into controller unprocessed type, controller processing failure type, and business key field validation failure type, and different processing strategies are matched for each.

[0114] For controller-unprocessed failures / timeouts where no marker was observed, a safe rollback or retry strategy is executed. For controller-processed failures where the marker was observed but the change execution failed, a precise rollback strategy is executed. For business key field validation failures where convergence judgment passed but key fields on the business side are inconsistent, this is considered an implicit inconsistency, and a precise rollback or compensation strategy is executed.

[0115] S6. Precise Rollback: Before rollback, perform marker threshold validation to confirm that the sub-items / fields corresponding to this change still exist and belong to this change. Then, generate a rollback patch based on the rollback criteria and perform an atomic update, only rolling back the sub-items / fields involved in this change.

[0116] Marker threshold verification includes: When rolling back an additional purchase, confirming that there is still a new sub-item in the resource sub-item set of the spec field that is consistent with the marker of this change; if not, the rollback will not be performed. When rolling back a configuration change, confirming that the resource sub-item corresponding to the marker still exists and that the field status can be identified as the result of this change; if these conditions are not met, the rollback will not be performed.

[0117] S7. Rollback Convergence Confirmation and Recording: After the rollback patch is submitted, repeat the convergence determination in step S4, record the reason for the failure of this change, the rollback result, the time taken, the number of retries and audit information, to ensure that the idempotent process is traceable.

[0118] Preferably, the cloud resource change consistency control and failure rollback method based on incremental patch updates also includes quantitative statistics of change effects. The quantitative statistics indicators include change surface ratio, conflict visibility rate, false coverage rate, and false judgment rate.

[0119] The change ratio is calculated as: (Number of field paths involved in this change) / (Total number of field paths in the spec field of the pre-reserved object).

[0120] Conflict visibility rate = Version conflict / Field conflict / Number of retries ÷ Total number of commits;

[0121] False coverage rate = Number of rollbacks or manual interventions caused by concurrent coverage ÷ Total number of changes;

[0122] False positive rate = Number of times a successful status was read but the controller failed to process the change ÷ Total number of judgments.

[0123] This invention also provides a cloud resource management system, including a request client, a change service module, a pre-allocated object storage module, a controller module, a resource interface module, a consistency verification module, and a rollback module. The request client initiates cloud resource change requests. The change service module executes steps S1-S5 and S7 of the incremental patch-based cloud resource change consistency control and failure rollback method. The pre-allocated object storage module stores pre-allocated objects and all change and rollback records. The controller module monitors changes to pre-allocated objects, calls the resource interface module to execute actual cloud resource changes, and writes the processing result back to the status field of the pre-allocated object. The resource interface module connects to the actual cloud resource pool and performs operations such as resource purchase and allocation changes. The consistency verification module performs key field consistency verification and convergence determination. The rollback module executes step S6 of the incremental patch-based cloud resource change consistency control and failure rollback method.

[0124] Figure 1 The diagram illustrates the architectural relationships of the cloud resource management system of this invention, including the request end, change service, pre-allocated object, controller, resource interface / actual resource, consistency check and rollback module. Figure 1In the process, the requesting end initiates a cloud resource change request. The change service module performs baseline reading, patch and marker generation, atomic commit, convergence determination, failure classification, rollback confirmation and logging. The pre-occupied object storage module stores pre-occupied objects and audit records. The controller module listens for changes to pre-occupied objects, calls the resource interface module to perform actual resource operations, and writes back the processing results. The resource interface module connects to the actual cloud resource pool. The consistency verification module performs convergence determination and key field verification. The rollback module performs marker threshold verification, rollback patch generation, and atomic rollback. The modules interact with each other through standardized interfaces to achieve closed-loop control.

[0125] Figure 2 The overall flow of the method in this embodiment is shown, which is as follows: S1 Baseline reading, S2 Generation of incremental patch and marker, S3 Atomic update of patch submission, S4 Waiting and convergence determination. If convergence is successful, the success information is recorded. If convergence fails, proceed to S5 Failure / Timeout classification. Based on the classification result, perform safe rollback / retry or precise rollback. After precise rollback, proceed to S7 Rollback convergence confirmation and recording to complete the entire process.

[0126] Figure 3 The detailed process of accurate rollback in case of failure is shown. First, failure classification is performed to determine whether rollback is needed. If not, the result is recorded directly. If it is needed, marker threshold validation is performed. If the validation fails, the rollback is terminated and recorded. If the validation passes, a rollback patch is generated according to the rollback criteria, and the atomic update of the rollback patch is submitted. Then, rollback convergence is performed. If the validation is successful, the rollback success information is recorded. If the validation fails, the rollback is retried until it succeeds or the maximum number of retries is reached.

[0127] Figure 4 The sequence diagram for changes and rollbacks is as follows, with the timeline from left to right: Change service submits incremental patch and marker → Pre-empted object update → Controller listens and executes resource operation → If operation fails, the controller writes back the failure status and marker → Change service determines failure and initiates rollback → Change service performs marker threshold verification → Submits rollback patch → Pre-empted object rollback update → Controller listens and executes rollback operation → Controller writes back the rollback success status → Change service records full information.

[0128] The above figures are only used to illustrate the technical architecture and process of the present invention, and are not intended to limit the specific implementation of the present invention. Those skilled in the art can make reasonable adjustments and extensions to the architecture and process in the figures according to actual needs.

[0129] Application examples

[0130] In practical applications, this invention has been implemented in the following two examples based on two different scenario requirements:

[0131] Application Example 1

[0132] The cloud resource change consistency control and failure rollback method based on incremental patch updates of the present invention is applied in the EIP resource purchase scenario. It initiates an EIP resource purchase request for cloud platform users, adding two public network EIPs from telecom operators with a bandwidth of 5M. JSON Patch is used as the atomic update method, the marker is the sub-order number, convergence is determined by observedMarker, rollback is based on the marker record, and consistency verification is performed using configHash.

[0133] The method used in Example 1 includes the following specific steps:

[0134] S1: Baseline reading, the change service module receives the user's EIP purchase request, the request identifier is REQ2026001, the sub-order number is SUB2026001, reads the spec field, status field and resourceVersion=10 of the current EIP pre-occupied object from the pre-occupied object storage module, the pre-occupied object's spec.items[] already has 3 EIP sub-items, there is no relevant content for this change;

[0135] S2: Generate an incremental patch and marker, using sub-order number SUB2026001 as the marker for this change. Construct two new EIP sub-items, newItem1 and newItem2, both containing business fields (isp=telecom, bandwidth=5M, type=public network) and marker=SUB2026001. Construct an incremental patch for the JSON patch, consisting of two add operations, both with the path / spec / items / -, and values ​​newItem1 and newItem2 respectively. Rollback is based on the record marker=SUB2026001. At the same time, normalize and serialize the key fields of this change (isp, bandwidth, type, count) and calculate the hash value = Hash2026001, writing it to spec.expectedHash.

[0136] S3: Submit the atomic update of the Patch, change the service module to carry the precondition of resourceVersion=10, submit the above JSON Patch to the pre-occupied object storage module to achieve atomic update, the resourceVersion of the pre-occupied object is incremented to 11, and two new EIP sub-items with markers are added to spec.items[] without any conflict.

[0137] S4: Waiting and Convergence Determination. The change service module monitors the status field of the pre-occupied object through the Watch mechanism. After the controller module detects the change of the pre-occupied object, it calls the resource interface module to perform the EIP purchase operation, adding two 5M Telecom public network EIPs. After the operation is successful, status.phase is updated to Success, status.observedMarker is updated to SUB2026001, and the hash value of the key field that actually takes effect is calculated as Hash2026001 and written to status.appliedHash. When the change service module detects that the final state determination (status.phase=Success) and the observation consistency determination (status.observedMarker=SUB2026001) are satisfied, and the configHash verification passes (spec.expectedHash=status.appliedHash), it determines that the change has converged successfully.

[0138] S5: Failure / Timeout Classification. This change has converged successfully, and no failure handling is required.

[0139] S6: Precise rollback. This change was successful and no rollback is required.

[0140] S7: Rollback convergence confirmation and recording. The change service module records all information about this change, including REQ2026001, SUB2026001, additional purchase, JSON Patch, resourceVersion=10→11, success, configHash=Hash2026001, processing time 0.5s, etc., and persists it to the audit log.

[0141] Application Example 2

[0142] The cloud resource change consistency control and failure rollback method based on incremental patch updates of this invention is applied to EIP resource configuration scenarios (change failure and precise rollback). It initiates an EIP resource configuration request for cloud platform users, upgrading the bandwidth of the newly added EIP sub-item newItem1 in Application Example 1 from 5M to 10M. Server-Side Apply is used as the atomic update method, the marker is the combination key SUB2026002-EIP of sub-order number and resource type, convergence is determined by conditions, rollback is based on baseline snapshot + reverse patch rollbackPatch, and consistency verification is performed item by item by key fields.

[0143] The method used in Example 2 includes the following specific steps:

[0144] S1: Baseline reading. The change service module receives the user's EIP configuration change request. The request identifier is REQ2026002 and the sub-order number is SUB2026002. It reads the spec field, status field, and resourceVersion=11 of the current EIP pre-occupied object from the pre-occupied object storage module. Based on marker=SUB2026001 in Example 1, it locates the target sub-item newItem1 and records its old bandwidth value oldBandwidth=5M (baseline snapshot) and resourceVersion=11.

[0145] S2: Generate an incremental patch and marker, using the key combination SUB2026002-EIP as the marker for this change, construct the expected fragment for Server-Side Apply, which only contains newItem1's bandwidth=10M and marker=SUB2026002-EIP; generate a reverse patch rollbackPatch, which is a replace operation, restoring newItem1's bandwidth to 5M; the rollback is based on the baseline snapshot (oldBandwidth=5M) + rollbackPatch;

[0146] S3: Submit the atomic update of the Patch. The change service module is identified by fieldManager=EIP-Change-Service. Submit the above expected fragment to the pre-occupied object storage module. The server performs field merging and ownership determination. No conflict occurs. The resourceVersion of the pre-occupied object is incremented to 12. The bandwidth of newItem1 is updated to 10M. The marker is updated to SUB2026002-EIP.

[0147] S4: Waiting and Convergence Determination. The change service module reads the status field of the pre-allocated object through a polling mechanism, with a polling timeout of 30 seconds. After the controller module detects a change in the pre-allocated object, it calls the resource interface module to perform an EIP bandwidth upgrade operation. Due to insufficient resources on the operator side, the operation fails. The controller module updates status.phase to Failed and adds a record to status.conditions: {type:Processed,reason:ISPResourceInsufficient,processedMarker:SUB2026002-EIP,time:2026-02-0210:00:00}. The change service module detects that the final state determination (status.phase=Failed) and the observation consistency determination (processedMarker=SUB2026002-EIP exists in status.conditions) are met, and determines that this change has failed.

[0148] S5: Failure / Timeout Classification. This change has observed marker=SUB2026002-EIP, which indicates a controller execution failure. This falls under the controller processing failure category, and a precise rollback strategy will be executed.

[0149] S6: Precise rollback, ①marker threshold verification: The change service module reads the spec field of the pre-occupied object again, confirming that the sub-item newItem1 with marker=SUB2026002-EIP still exists in spec.items[], and its bandwidth=10M is the result of this change, and the verification passes; ②Generate rollback Patch: Based on the baseline snapshot and rollbackPatch, construct the rollback expectation fragment of Server-Side Apply, which only contains the bandwidth=5M of newItem1 and fieldManager=EIP-Rollback-Service; ③Atomic rollback: Submit the rollback expectation fragment, the server performs field merging, no conflict occurs, the resourceVersion of the pre-occupied object is incremented to 13, and the bandwidth of newItem1 is restored to 5M;

[0150] S7: Rollback Convergence Confirmation and Recording, ① Rollback Convergence Confirmation: After the rollback patch is submitted, the change service module polls and reads the status field. After the controller module detects the change, it confirms that the EIP bandwidth has been restored to 5M, updates status.phase to Success, and adds a rollback record to status.conditions: {type:Rollbacked,processedMarker:SUB2026002-EIP,time:2026-02-0210:01:00}. The change service module determines that the rollback convergence is successful. ② Full Information Recording: The change service module records the full information of this change and rollback, including REQ2026002, SUB2026002-EIP, configuration change, Server-Side Apply, resourceVersion=11→12→13, failure reason=insufficient operator resources, rollback successful, processing time 60s, retries 0, etc., and persists it to the audit log.

[0151] In Application Example 2, the rollback operation only modified the bandwidth field of newItem1, without affecting other EIP sub-items. Furthermore, a marker threshold check was performed before the rollback, which prevented erroneous rollbacks caused by concurrent new requests and achieved accurate rollback after failure.

[0152] The application example of this invention achieves an observable causal relationship between the current change attempt, controller observation, and state write-back without introducing heavy transactions and high-cost locking mechanisms; when concurrent new requests occur, it can still safely determine the change convergence status and perform accurate rollback, avoiding erroneous rollback and state misjudgment.

[0153] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0154] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cloud resource change consistency control and failure rollback method based on incremental patch updates, characterized in that, Includes the following steps: S1. Read the baseline spec field, status field, and version information of the current pre-occupied object to locate the set of resource sub-items and the target sub-item involved in this change; S2. Attempt to generate a unique marker for this change, construct an incremental patch based on the cloud resource change type, and simultaneously generate the basis for rolling back this change; S3. Use any one of the atomic update methods, such as JSON Merge Patch, JSON Patch, or Server-Side Apply, to submit incremental patches with version control information. When a conflict occurs, execute a retry strategy of rereading and recalculating. S4. After the patch is submitted, poll or watch to read the status field of the pre-occupied object. If and only if the dual conditions of final state determination and observation consistency determination are met, the change is determined to have converged; otherwise, it is determined to have failed / timed out. S5. Based on whether the marker was observed and the failure type, the failures / timeouts are divided into controller unprocessed type, controller processing failure type, and business key field validation failure type, and different processing strategies are matched for each. S6. Before rollback, perform marker threshold verification to confirm that the sub-items / fields corresponding to this change still exist and belong to this change. Then, generate a rollback patch based on the rollback criteria and perform an atomic update, only rolling back the sub-items / fields involved in this change. S7. After rolling back the patch submission, repeat the convergence determination in step S4, record the reason for the failure of this change, the rollback result, the time taken, the number of retries and the audit information to ensure that the idempotent process is traceable.

2. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 1, characterized in that, The pre-occupied object is an object that carries the expected configuration of cloud resources, and includes at least a spec field and a status field; the spec field sets a set of resource sub-items to describe the changeable cloud resource sub-items; the status field sets an observation field to prove that the controller has processed the change, and the observation field includes at least one of status.observedMarker, status.observedGeneration, and status.conditions.

3. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 1, characterized in that, The marker is a unique identifier bound to a change attempt. It can be any one of the following: sub-order number, sub-resource idempotent key, sub-order number + resource type combination key, or UUID. The marker is written into the resource sub-item involved in this change to accurately locate the scope of this change.

4. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 1, characterized in that, The cloud resource change types mentioned in step S2 include additional purchases and reconfigurations. When making an additional purchase, the incremental patch is constructed to express the addition of a new resource sub-item, and the marker of this change is embedded in the new resource sub-item. When reconfiguring, the old resource sub-item is located by the marker, and the incremental patch is used to express the target field of the old resource sub-item to be replaced, while recording the old value of the target field of the old resource sub-item.

5. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 2, characterized in that, The rollback basis in step S2 includes at least one of baseline snapshot and rollbackPatch; the baseline snapshot is the old value or old resource sub-item of the field / sub-item involved in this change; the rollbackPatch is the operation instruction opposite to the forward incremental patch, realizing the reverse mapping of add and remove, replace_new and replace_old.

6. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 5, characterized in that, The final state determination in step S4 is that the status field of the pre-occupied object enters the final state of success or failure; the observation consistency determination is that any of the following conditions are met: status.observedMarker is completely consistent with the marker of this change; status.observedGeneration is greater than or equal to the generation version number corresponding to this commit; status.conditions contains processing result conditions corresponding to the marker or generation of this change; on the basis of the final state determination and the observation consistency determination, the key field consistency check is superimposed.

7. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 2, characterized in that, In step S5, the unprocessed type of the controller is the failure / timeout where no marker is observed, and a safe rollback or retry strategy is executed; the failed type of the controller is the case where the marker has been observed but the change execution has failed, and a precise rollback strategy is executed; the failed type of the business key field validation is the case where the convergence judgment is passed but the key fields on the business side are inconsistent, which is regarded as implicit inconsistency, and a precise rollback or compensation strategy is executed.

8. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 1, characterized in that, The marker threshold verification in step S6 includes: when rolling back an additional purchase, confirming that there is still a new sub-item in the resource sub-item set of the spec field that is consistent with the marker of this change; if it does not exist, the rollback will not be performed. When rolling back a configuration change, confirming that the resource sub-item corresponding to the marker still exists and that the field status can be identified as the result of this change; if these conditions are not met, the rollback will not be performed.

9. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 1, characterized in that, The atomic update method of JSON Merge Patch described in step S3 includes: reading the baseline of the pre-occupied object to obtain oldSpec and version number, calculating newSpec on the client based on oldSpec to modify only the target sub-item, constructing MergePatch containing only the top-level field that needs to be updated, submitting with resourceVersion as a precondition, and rereading the baseline and recalculating newSpec before retrying in case of conflict.

10. The cloud resource change consistency control and failure rollback method based on incremental patch updates according to claim 2, characterized in that, The atomic update method of JSON Patch described in step S3 includes: reading the baseline of the pre-occupied object and specifying the array path of the resource sub-item set; when purchasing additional items, submitting an add operation to append new resource sub-items containing markers; when changing configurations, locating the index of the resource sub-item by marker and submitting a replace operation to replace the target field; and when the index does not exist or conflicts, rereading the baseline and relocating the index before retrying.

Images