Version update methods, devices, equipment and media

Abstract

This application relates to the field of software release technology, and more particularly to a version update method, apparatus, device, and medium. In this application, when a user's business request is received at the edge, the request is tinted and untinted according to a preset tinting ratio; the target update version of the current system version is obtained, and a simulation database for the target update version is constructed; the tinted and untinted requests are tinted until the tinting ratio reaches a preset version release ratio value, thus obtaining the release result of the target update version and completing the version update. The new version is verified by comparing the processing results of the traffic splitting requests between the old and new versions, and the test traffic ratio is dynamically and automatically increased based on the verification results until a standard for safe full release is reached. Therefore, while ensuring zero impact on online business, the new version undergoes automated business correctness verification, thereby automating the full version release.

Description

Technical Field

[0001] This application relates to the field of software distribution technology, and in particular to a version update method, apparatus, device and medium. Background Technology

[0002] In the continuous delivery of cloud-native AMI systems, a microservice architecture is adopted, encompassing over 20 services including HES (Hardware Estimates), MDM (Management Data Management), and Vending (Vendorized Delivery). Frequent iterations and upgrades are required. To ensure the stability, correctness, and performance of new versions and avoid potential systemic risks from direct full deployment, the industry typically employs a gradual release strategy. However, existing mainstream strategies still have significant shortcomings in specific scenarios, especially in systems with extremely high requirements for data consistency and business logic correctness.

[0003] Currently, most version update methods use canary deployments. This method involves deploying the new version to a small group of actual servers or users to collect real-world traffic data (such as error rates and latency) to determine whether to expand the deployment. If the new version contains logical errors or data consistency defects, it will directly impact the business of these users, resulting in financial losses or service unavailability. Furthermore, it typically relies on operational monitoring metrics (such as CPU usage and error logs), making it difficult to perform in-depth correctness comparisons of complex business logic processing results.

[0004] Therefore, how to automate the business correctness verification of the new version while ensuring zero impact on online business, and thus automate the full release of the version, has become an urgent problem to be solved. Summary of the Invention

[0005] In view of this, embodiments of this application provide a version update method, apparatus, device, and medium to solve the problem of how to automatically verify the business correctness of a new version while ensuring zero impact on online business, thereby automatically achieving full version release.

[0006] In a first aspect, embodiments of this application provide a version update method, wherein the version update method is applied to the cloud of the system, including: When the edge receives a user's service request, it performs a coloring operation on the service request and the uncolored request according to a preset coloring ratio. Obtain the target update version of the current version of the system, construct a simulation database for the target update version, record the first processing result of the coloring request in the target update version, and use the simulation database to execute the processing operation of the business request by the target update version; Record the second processing result of the current version on the uncolored request, and verify the second processing result and the first processing result according to the preset target parameters to obtain the verification result; Based on the verification results, the staining ratio is adjusted to obtain the adjusted staining ratio; The adjusted coloring ratio is used as the preset coloring ratio. The coloring request and the uncoloring request after performing the coloring operation on the business request according to the preset coloring ratio are returned until the coloring ratio reaches the preset version release ratio value, and the release result of the target updated version is obtained, thus completing the version update.

[0007] Secondly, according to an embodiment of this application, a version update device is provided, which is applied to the cloud of the system and includes: The coloring module is used to obtain the colored request and the uncolored request after the edge receives the user's service request and performs a coloring operation on the service request according to a preset coloring ratio. The processing module is used to obtain the target update version of the current version of the system, construct a simulation database for the target update version, record the first processing result of the coloring request in the target update version, and the simulation database is used to execute the processing operation of the target update version on the business request. The verification module is used to record the second processing result of the current version on the uncolored request, and to verify the second processing result and the first processing result according to the preset target parameters to obtain the verification result; An adjustment module is used to adjust the staining ratio according to the verification results to obtain an adjusted staining ratio; The version update module is used to take the adjusted coloring ratio as the preset coloring ratio, return the colored request and the uncolored request after performing the coloring operation on the business request according to the preset coloring ratio, until the coloring ratio reaches the preset version release ratio value, obtain the release result of the target updated version, and complete the version update.

[0008] Thirdly, embodiments of this application provide a computer device, the computer device including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the version update method as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the version update method as described in the first aspect.

[0010] The beneficial effects of the embodiments in this application compared with the prior art are: This application obtains the colored and uncolored requests after the edge receives a user's business request, based on a preset coloring ratio. It then obtains the target update version of the current system version, constructs a simulation database for the target update version, and records the first processing result of the corresponding colored requests in the target update version. This simulation database is used to execute the target update version's processing operations on the business requests. It also records the second processing result of the uncolored requests in the current version, and verifies the second and first processing results according to preset target parameters to obtain the verification result. Based on the verification result, it adjusts the coloring ratio to obtain the adjusted coloring ratio. Using the adjusted coloring ratio as the preset coloring ratio, it returns to execute the colored and uncolored requests after coloring the business requests according to the preset coloring ratio, until the coloring ratio reaches the preset version release ratio value, thus obtaining the target update version's release result and completing the version update. The new version is verified by comparing the processing results of the traffic splitting requests between the old and new versions, and the test traffic ratio is dynamically and automatically increased based on the verification results until a safe full release standard is reached. This allows for automated business correctness verification of the new version while ensuring zero impact on online business, thereby automating the full version release. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment for a version update method provided in Embodiment 1 of this application; Figure 2 This is a flowchart illustrating a version update method provided in Embodiment 2 of this application; Figure 3 This is a flowchart illustrating a version update method provided in Embodiment 3 of this application; Figure 4 This is a flowchart illustrating a version update method provided in Embodiment 4 of this application; Figure 5 This is a flowchart illustrating a version update method provided in Embodiment 5 of this application; Figure 6 This is a schematic diagram of the structure of a version update device provided in Embodiment Six of this application; Figure 7This is a schematic diagram of the structure of a computer device provided in Embodiment 7 of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0015] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0017] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0018] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0019] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0020] To illustrate the technical solution of this application, specific embodiments are described below.

[0021] The version update method provided in Embodiment 1 of this application can be applied to, for example, Figure 1 In this application environment, users submit version update requests, configuration conditions, and update trigger commands through client operations. The server includes the pre-configured operating system, runtime environment, and application to be updated for the AMI. The server provides an external service entry point through a load balancer, receiving and processing version update control commands from clients. In this method, the server executes strategies such as rolling updates or coloring based on client commands, gradually replacing or overlaying old AMI instances with new ones in a controllable manner, ultimately completing the upgrade of the entire server application version.

[0022] See Figure 2 This is a flowchart illustrating a version update method provided in Embodiment 2 of this application. The above version update method can be applied to... Figure 1 The server-side component.

[0023] like Figure 2 As shown, this version update method may include the following steps: Step S201: When the edge receives a user's service request, the colored request and the uncolored request are obtained after coloring the service request according to a preset coloring ratio.

[0024] Optionally, when the acquisition edge receives a user's service request, before coloring the service request and the uncolored request according to a preset coloring ratio, the following steps may be included: Upon receiving a release request for the target update version, a canary release task is created for the target update version; Extract the coloring rules from the grayscale release task, and determine the coloring ratio of the business request based on the coloring rules.

[0025] The edge is the access layer gateway or traffic entry server. Whenever it receives a user's business request, the edge will color the request or not color it according to a preset ratio.

[0026] Colored requests refer to requests that have been marked with a specific tag. These requests will be redirected to newer versions for processing. Uncolored requests refer to requests that have not been marked. These requests will continue to be processed by the current stable version. The preset coloring ratio is a core control parameter. For example, if the preset coloring ratio is set to 5%, the system will randomly (or according to specific rules) color approximately 5% of requests as colored requests, and the remaining 95% as uncolored requests. The execution of step S201 depends on a predefined "coloring ratio" and rules. These rules are set based on the creation and configuration of the canary release task. This can be understood as preparation work before release.

[0027] When operations or development personnel initiate a request to release a new version, the system creates a controlled release plan, or canary release task, for this specific target update version. This task contains all the strategies and parameters for how to release this version. From the above task, the coloring rules are extracted.

[0028] The coloring rules consist of traffic filtering rules, which define which requests meet the criteria for being colored (e.g., only requests from a specific region, user group, or API interface will be colored). Initially, for security reasons, these rules may be very simple, such as random sampling. It also includes an initial coloring percentage, i.e., how much traffic matching the rules will be colored at the beginning. This is a very conservative initial value, such as 1% or 0.1%, intended for initial probing with minimal traffic.

[0029] Step S202: Obtain the target update version of the current version of the system, construct a simulation database for the target update version, and record the first processing result of the coloring request in the target update version. The simulation database is used to execute the processing operation of the business request by the target update version.

[0030] The system is ready to release the target update version (i.e., a new version of software code or service instance). This is the subject to be verified.

[0031] Building a mock database involves creating a database replica (i.e., a sandbox or shadow database) with the same structure as the online environment but with isolated data for the new version. All read operations (queries) in the new version can be directed to a snapshot or read-only copy of the online real database to ensure it can obtain the latest business data for logical judgment. All write operations (insert, delete, update) in the new version must be redirected to this mock database.

[0032] The coloring requests sorted out in step S201 are then directed to the new version of the program running in the simulated database environment for processing. After processing each coloring request, the new version generates a response (e.g., a calculated order amount, a returned list of query results, a JSON response from the API, etc.). This response is precisely recorded by the system and is called the "first processing result." This "first processing result" will serve as one of the benchmarks for subsequent comparison and verification. It represents the actual behavior of the new version in the current business scenario.

[0033] Step S203: Record the second processing result of the current version on the uncolored request, and verify the second processing result and the first processing result according to the preset target parameters to obtain the verification result.

[0034] Optionally, recording the second processing result of the current version for the uncolored request may include the following steps: Extract the second processing logic of the current version for the business request, and process the uncolored request according to the second processing logic to obtain the second processing result.

[0035] In this context, the "second processing result" of the current version refers to the uncolored requests sorted out in step S201 (i.e., traffic processed by the stable version). The current version processes these requests and generates responses. The system accurately records these responses, which are called the "second processing result." This represents the known and correct behavioral baseline of the system.

[0036] The preset target parameters serve as the "benchmark" for verification, defined before release. They specify what to compare, such as functional correctness, consistency of API response data (e.g., order amount, query result list), business rules, and consistency of key business logic outputs (e.g., risk control audit results, coupon redemption status), etc. The system compares the "first processing result" generated in the new version with the "second processing result" generated in the current version for the same batch of business requests (colored requests and their corresponding uncolored requests, usually associated based on the same input conditions or user sessions), according to the aforementioned "target parameters".

[0037] The comparison result is a quantitative indicator, most commonly the "difference rate". For example, if 1000 requests are compared and 5 requests have inconsistent output content between the old and new versions, the difference rate is 0.5%. This "verification result" (difference rate) is the core decision-making basis for the next step of traffic control.

[0038] The optional step provides a more accurate way to obtain the "second processing result", especially when it is technically difficult to directly record the output of the current version (e.g., the processing logic is scattered or it is difficult to intercept the complete response).

[0039] The second processing logic is extracted by the system not simply recording the output of the current version, but rather reversing the process to extract or call the complete logic code or service of the current version that handles the business request. This extracted "processing logic," representing the current version, is then used to reprocess the uncolored request (or an exact copy thereof). The result of this re-execution is used as the "second processing result" for comparison. This eliminates noise caused by factors such as recording timing, network jitter, and external state changes, ensuring that the "second processing result" used for comparison is the output of the current version's logic under ideal and clean conditions, making the comparison fairer and more accurate.

[0040] Step S204: Based on the verification results, adjust the staining ratio to obtain the adjusted staining ratio.

[0041] Optionally, adjusting the staining ratio based on the verification results to obtain the adjusted staining ratio may include the following steps: If the difference rate corresponding to the staining ratio is zero, then the staining ratio is increased by a preset increase ratio to obtain an increased staining ratio, and the increased staining ratio is used as the adjusted staining ratio; or If the difference rate corresponding to the staining ratio is not zero, the staining ratio is reduced by a preset reduction ratio to obtain the reduced staining ratio, and the reduced staining ratio is used as the adjusted staining ratio.

[0042] The verification result produced in step S203 is the difference rate (e.g., the percentage of requests whose output is inconsistent with the current version). The system compares this difference rate with an implicit "health threshold" (usually 0%) to determine whether the performance of the new version is acceptable.

[0043] Scenario 1: Verification passed (difference rate zero). All coloring requests at the current coloring ratio result in identical processing outcomes in the new version. This indicates that the new version performed stably without issues in the exposed traffic scenarios. The coloring ratio is then increased by the preset increment. The experimental scope is expanded to include more real traffic in the new version to test its stability in broader and more complex business scenarios. This is a "cautiously optimistic, gradual approach." For example, the coloring ratio is gradually increased from 1% to 5% to 20%.

[0044] Scenario two involves a failed verification (difference rate not zero), indicating an inconsistency. This suggests a bug in the new version, performance degradation, or an intentional but unconfirmed change (requiring manual intervention). Regardless of the cause, from a risk control perspective, this is considered an abnormal signal. The staining percentage is reduced according to the preset reduction plan. Traffic to the new version is immediately reduced to prevent the problem from affecting more users. Simultaneously, a minimum observation window is maintained (e.g., from 5% to 1%) so that developers can continue to collect samples of erroneous requests for localization and analysis, rather than a blanket full rollback (which might lose real-world information). For example, the staining percentage is reduced from 10% to 2% to 0.5%. If the problem persists, the percentage may eventually drop to 0% (i.e., completely shutting down traffic to the new version).

[0045] The adjusted dyeing ratio takes effect immediately and is fed back to the flow sorting stage in step S201. This process continues to cycle until the release is completed (ratio rises to 100%) or the release is stopped (ratio drops to 0%).

[0046] Step S205: Using the adjusted coloring ratio as the preset coloring ratio, return to the coloring request and uncoloring request after performing the coloring operation on the service request according to the preset coloring ratio, until the coloring ratio reaches the preset version release ratio value, obtain the release result of the target updated version, and complete the version update.

[0047] In this process, the adjusted dyeing ratio calculated in step S204 is assigned back to the preset dyeing ratio variable at the starting point of the process. This establishes a feedback loop from the end point (S204) to the starting point (S201). The entire system is no longer a one-time action, but a "control loop".

[0048] After each cycle, the preset coloring ratio, a control variable, is updated based on the actual performance (difference rate) of the previous round, thereby guiding the flow to be allocated in a new and more reasonable manner in the next round.

[0049] The system returns to the preset coloring ratio and applies it to business requests, automatically initiating a new round of gray-scale release verification. This time, however, it uses an updated coloring ratio that more closely approximates the target state. This continues until the coloring ratio reaches the preset version release ratio value. The preset version release ratio value is the ultimate goal of the release process and can have two key values: 100%, indicating a successful full release. When the coloring ratio is gradually increased to 100% through multiple security verifications, it means that all traffic has switched to the new version and no anomalies have been found. At this point, the old version can be taken offline. Or 0%, indicating a release failure and a complete rollback. If, during a certain cycle, the ratio is repeatedly lowered due to a non-zero difference rate, eventually dropping to 0%, it means that a problem has been found in the new version, and a complete rollback is necessary. The process terminates with a failure.

[0050] This application obtains the colored and uncolored requests after the edge receives a user's business request, based on a preset coloring ratio. It then obtains the target update version of the current system version, constructs a simulation database for the target update version, and records the first processing result of the corresponding colored requests in the target update version. This simulation database is used to execute the target update version's processing operations on the business requests. It also records the second processing result of the uncolored requests in the current version, and verifies the second and first processing results according to preset target parameters to obtain the verification result. Based on the verification result, it adjusts the coloring ratio to obtain the adjusted coloring ratio. Using the adjusted coloring ratio as the preset coloring ratio, it returns to execute the colored and uncolored requests after coloring the business requests according to the preset coloring ratio, until the coloring ratio reaches the preset version release ratio value, thus obtaining the target update version's release result and completing the version update. The new version is verified by comparing the processing results of the traffic splitting requests between the old and new versions, and the test traffic ratio is dynamically and automatically increased based on the verification results until a safe full release standard is reached. This allows for automated business correctness verification of the new version while ensuring zero impact on online business, thereby automating the full version release.

[0051] For example, in an AMI microservice scenario, when a user initiates an order request, the coloring gateway deployed at the traffic inlet first intercepts the request. Based on the system's preset initial coloring ratio (e.g., 5%), the gateway uses a random algorithm to decide whether to inject a coloring identifier into the request. Subsequently, the gateway makes routing decisions based on this identifier; colored requests are directed to the new version instance to be released, while uncolored requests continue to flow to the current stable online version instance. For the same colored order request, the system triggers dual-path parallel processing. After the new version instance receives the request, all business operations (such as order creation and points calculation) are executed in a pre-built simulated database (shadow environment). In this example, it calculates the points according to the new rules (e.g., 15% of the order amount, with a maximum of 100 points) and reports the full processing log containing this result (referred to as the first processing result) to the verification center. Crucially, the user's actual business response is given by this version. To compare results, the system typically sends a copy of the colored request synchronously or asynchronously to the current version instance (or in some designs, the current version instance processes all requests, but the colored request is additionally marked for comparison). The current version instance uses the production database to process according to the old rules (e.g., 10% of the order amount) and reports its processing result (referred to as the second processing result). This processing result is only used for comparison and is not returned to the user, thus achieving lossless comparative testing of the business. The verification center continuously collects paired processing results from the current version and the target updated version instance. The system performs automated comparison and analysis based on preset core verification indicators (such as the calculated points, order status, response latency, error codes, etc. in this example). Verification not only focuses on whether the results of the two versions are consistent (for scenarios where the logic remains unchanged), but also on whether the results of the new version meet the expected new business rules (for scenarios where the logic has changed). At the same time, the system will comprehensively evaluate indicators such as success rate and performance differences to form an overall confidence assessment of the stability and correctness of the new version under the current coloring ratio. Based on the verification results, if the new version consistently meets the preset correctness and stability thresholds for handling coloring requests at the current coloring ratio (e.g., success rate >99.9% for several consecutive hours, business logic error-free), the system will automatically and incrementally increase the coloring ratio (e.g., from 5% to 15%, 30%, etc.). This signifies increased confidence in the new version and expands its testing scope. If a business logic error, severe performance degradation, or a spike in the error rate is detected, the system will immediately stop increasing the ratio and may automatically roll back to the previous safe ratio, or even fully switch back to the current version. Simultaneously, an alert will be triggered, notifying developers to investigate.

[0052] See Figure 3 This is a flowchart illustrating a version update method provided in Embodiment 3 of this application. Figure 3As shown, the step S202 above, which involves obtaining the target update version of the current system version, constructing a simulation database for the target update version, and recording the first processing result corresponding to the coloring request in the target update version, may include the following steps: Step S301: Extract the first processing logic for the business instruction in the target update version, process the coloring request according to the first processing logic, and obtain the first processing result; Step S302, the step of extracting the first processing logic for the business instruction in the target updated version, processing the coloring request according to the first processing logic, and obtaining the first processing result, is executed in the simulation database.

[0053] The first processing logic refers to the code, service, or configuration of the target updated version that is about to be released. Instead of directly calling the new version of the service online (which may not yet exist or could interfere with real traffic), the system extracts its business logic. This can be achieved by loading the new version's JAR package, calling its API sandbox endpoint, or instantiating a temporary process containing the new logic.

[0054] Step S201 sorts out the coloring requests marked as requiring processing by the new version. The key point is that the data source (database, cache, etc.) driving this new logic is a "simulated database," not the actual online database. The simulated database is initialized using a snapshot or partially anonymized copy of the actual online database at a certain point in time. This simulates a real data scenario while ensuring isolation. The new version logic uses data from the simulated database to calculate and process the coloring requests, and may write intermediate or final data to the simulated database. The final output response generated by this process is the recorded first processing result.

[0055] Step S302 introduces constraints at the architectural level, requiring the canary release system to have strict environment isolation capabilities, such as through network policies, container isolation, and data source configuration overriding.

[0056] This application embodiment obtains behavioral samples (first processing results) of the new version when facing real traffic, which are closest to the real future operating state, without assuming any risk of polluting online data.

[0057] See Figure 4 This is a flowchart illustrating a version update method provided in Embodiment 4 of this application. Figure 4 As shown, step S203, which involves verifying the second processing result and the first processing result based on preset target parameters to obtain a verification result, may include the following steps: Step S401: Extract the first target value of the first processing result according to the target parameter; Step S402: Extract the second target value of the second processing result according to the target parameter; Step S403: Compare the first target value and the second target value to obtain the difference rate, and use the difference rate as the verification result.

[0058] In this context, target parameters are predefined key metrics used to measure business correctness and performance. Target parameters are not the raw response data, but rather one or more core values ​​calculated or extracted from the raw data. For example, for a request to query a user's balance, the target parameter could be the final balance value.

[0059] For a request to create an order, the target parameters can be the order status, the total order amount, etc.

[0060] The system parses and calculates the "first target value" corresponding to the preset target parameters from the first processing results recorded in the simulation database (generated by the new version). The system also parses and calculates the second target value corresponding to the same preset target parameters from the "second processing results" recorded in the real online environment (generated by the old version). This is achieved by writing comparison scripts or assertion rules, which know how to parse the response and find the key data points for comparison.

[0061] The system compares the first target value with the second target value. For example, for the balance, if the new version calculates 100 and the old version calculates 100, the difference rate is 0%; if the new version calculates 105, the difference rate is 5%.

[0062] For status parameters (such as order status), the difference rate is usually 0% (consistent) or 100% (inconsistent) (if the order status created in the new version is "paid" while the corresponding order in the old version is "pending payment", it is considered a 100% difference).

[0063] If multiple target parameters exist, the system can calculate the difference rate for each parameter and then take the weighted average or the maximum value as the overall difference rate. If any core parameter (such as order status or fund changes) is inconsistent, the overall difference rate is directly recorded as 100% (failure).

[0064] This difference rate is the verification result output in step S203.

[0065] It is a quantitative and objective metric that perfectly serves subsequent decision-making steps (S204).

[0066] A difference rate of 0% or below a certain small threshold (such as 0.1%) means that the new version performs in the same way as the old version in terms of core business logic metrics, and can be considered safe and correct.

[0067] A difference rate greater than 0% or higher than a certain small threshold means that the new version has produced different outputs in a core business dimension. The larger the difference rate, the more serious the deviation and the higher the risk.

[0068] This value directly determines whether the next step (S204) should be to increase the grayscale (increase the ratio), pause observation, or decrease the grayscale (decrease the ratio).

[0069] In this embodiment, the subjective and ambiguous question of whether the new version is correct is transformed into an objective and precise programmable judgment of whether the difference rate is within an acceptable range. It is this quantified verification result that enables the entire canary release process to be upgraded from being driven by human experience to being driven by data intelligence, achieving secure and automated rolling releases.

[0070] See Figure 5 This is a flowchart illustrating a version update method provided in Embodiment 5 of this application. Figure 5 As shown, after obtaining the verification result in step S203, the following steps may also be included: Step S501: Obtain a preset rollback threshold. If the difference rate is higher than the rollback threshold, adjust the coloring ratio to zero, use the current version to execute the business request, and obtain the processing result of the business request. Step S502: Based on the difference rate, generate an alarm signal and obtain an alarm log, which is used for maintenance analysis.

[0071] The preset rollback threshold is a predefined, inviolable safety threshold. It is typically much stricter than the acceptable threshold (used to determine whether to expand the grayscale). For example, for financial transactions, any difference in amount or status is fatal, and the rollback threshold might be set to 0% (zero tolerance). For minor adjustments to page layout, the rollback threshold might be set to 5% (allowing for minor UI rendering differences).

[0072] Setting the coloring ratio to zero is equivalent to immediately and completely halting the canary release. No new coloring requests (i.e., requests representing canary traffic) will be routed to the new version. The configuration of traffic schedulers (such as gateways and load balancers) will be dynamically updated. All subsequent requests marked as part of this canary task will be 100% redirected to the stable and reliable current version (i.e., the old version). Essentially, this is a second-level, data-loss-free automatic rollback. Because the new version only runs on a simulated database and does not affect real data, the rollback only requires switching traffic; no data recovery is needed.

[0073] After an automatic rollback, users' business requests will continue to be processed seamlessly and imperceptibly by the well-validated older version, ensuring that online business continuity is not affected.

[0074] Based on the difference rate, the generation of alarm signals, i.e., the alarm triggering conditions and severity levels, can be directly linked to the difference rate.

[0075] Obtain alarm logs for maintenance analysis. An alarm log is a complete data packet or crime scene record that can be used for in-depth analysis.

[0076] The alarm log includes the complete content of the colored request that triggered the issue. It also includes a complete processing log of the new version in the simulation environment (execution trace of the first processing logic, all read and write operations on the simulation database, and intermediate states). Additionally, it includes the processing log of the same request in the online environment. Finally, it includes the new or old version code identifier, environment configuration, and dependent service status at the time.

[0077] This application embodiment transforms a potential online failure into a controllable and fruitful release verification experiment.

[0078] Corresponding to the version update method in the above embodiments, Figure 6 A structural block diagram of the version update device provided in Embodiment Six of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0079] See Figure 6 The version update device, which is applied to the system's cloud, includes: The coloring module 61 is used to obtain the colored request and the uncolored request after the edge receives the user's service request and performs a coloring operation on the service request according to a preset coloring ratio. Processing module 62 is used to obtain the target update version of the current version of the system, construct a simulation database for the target update version, record the first processing result corresponding to the coloring request in the target update version, and the simulation database is used to execute the processing operation of the target update version on the business request. Verification module 63 is used to record the second processing result of the current version on the uncolored request, and to verify the second processing result and the first processing result according to the preset target parameters to obtain the verification result; The adjustment module 64 is used to adjust the staining ratio according to the verification result to obtain the adjusted staining ratio; Version update module 65 is used to take the adjusted coloring ratio as the preset coloring ratio, return the coloring request and the uncoloring request after performing the coloring operation on the business request according to the preset coloring ratio, until the coloring ratio reaches the preset version release ratio value, obtain the release result of the target updated version, and complete the version update.

[0080] Optionally, the version update device further includes: The task creation module is used to create a canary release task for the target update version when a release request for the target update version is received. The coloring ratio determination module is used to extract the coloring rules from the grayscale release task and determine the coloring ratio of the business request based on the coloring rules.

[0081] Optionally, the processing module 62 includes: The first processing unit is used to extract the first processing logic for the business instruction in the target updated version, process the coloring request according to the first processing logic, and obtain the first processing result. The step execution module is used to extract the first processing logic for the business instruction in the target updated version, process the coloring request according to the first processing logic, and obtain the first processing result, and execute the step in the simulation database.

[0082] Optionally, the verification module 63 includes: The request processing unit is used to extract the second processing logic of the current version for the business request, process the uncolored request according to the second processing logic, and obtain the second processing result.

[0083] Optionally, the verification module 63 includes: The first target extraction unit is used to extract the first target value of the first processing result based on the target parameters; The target value extraction unit is used to extract the second target value of the second processing result based on the target parameters; The target value comparison unit is used to compare the first target value and the second target value to obtain the difference rate, and use the difference rate as the verification result.

[0084] Optionally, the adjustment module 64 includes: A ratio increasing unit is used to increase the staining ratio by a preset ratio if the difference rate corresponding to the staining ratio is zero, to obtain an increased staining ratio, and to use the increased staining ratio as the adjusted staining ratio; or The proportion reduction unit is used to reduce the staining ratio by a preset reduction ratio if the difference rate corresponding to the staining ratio is not zero, so as to obtain the reduced staining ratio and use the reduced staining ratio as the adjusted staining ratio.

[0085] Optionally, the version update device further includes: The request processing module is used to obtain a preset rollback threshold. If the difference rate is higher than the rollback threshold, the coloring ratio is adjusted to zero, the current version is used to execute the business request, and the processing result of the business request is obtained. After obtaining the processing result of the business request, the process also includes: The analysis unit is used to generate an alarm signal based on the difference rate and to obtain an alarm log, which is used for maintenance analysis.

[0086] It should be noted that the information interaction and execution process between the above modules, units, and sub-units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0087] Figure 7 This is a schematic diagram of the structure of a computer device provided in Embodiment Seven of this application. Figure 7 As shown, the computer device of this embodiment includes: at least one processor ( Figure 7 Only one is shown in the diagram), a memory, and a computer program stored in the memory and executable on at least one processor, wherein the processor executes the computer program to implement the steps of any of the above-described version update methods or version update method embodiments.

[0088] This computer device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 7 The examples of computer devices are merely examples and do not constitute a limitation on computer devices. Computer devices may include more or fewer components than shown in the illustration, or combinations of certain components, or different components, such as network interfaces, displays, and input devices.

[0089] The processor referred to can be a CPU, but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0090] Memory includes readable storage media, internal memory, etc., wherein internal memory can be the RAM of a computer device, providing an environment for the operation of the operating system and computer-readable instructions stored in the readable storage media. The readable storage media can be the hard drive of a computer device, or in other embodiments, it can be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, memory can include both internal storage units and external storage devices of the computer device. Memory is used to store the operating system, applications, bootloader, data, and other programs, such as program code for computer programs. Memory can also be used to temporarily store data that has been output or will be output.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code, a recording medium, a computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0092] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on a computer device, it enables the computer device to execute the steps in the above method embodiments.

[0093] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0094] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0095] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0096] 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.

[0097] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A version update method, characterized in that, The version update method is applied to the system's cloud and includes: When the edge receives a user's service request, it performs a coloring operation on the service request and the uncolored request according to a preset coloring ratio. Obtain the target update version of the current version of the system, construct a simulation database for the target update version, record the first processing result of the coloring request in the target update version, and use the simulation database to execute the processing operation of the business request by the target update version; Record the second processing result of the current version on the uncolored request, and verify the second processing result and the first processing result according to the preset target parameters to obtain the verification result; Based on the verification results, the staining ratio is adjusted to obtain the adjusted staining ratio; The adjusted coloring ratio is used as the preset coloring ratio. The coloring request and the uncoloring request after performing the coloring operation on the business request according to the preset coloring ratio are returned until the coloring ratio reaches the preset version release ratio value, and the release result of the target updated version is obtained, thus completing the version update.

2. The version update method according to claim 1, characterized in that, Before the colored request and the uncolored request are colored according to a preset coloring ratio when the acquisition edge receives a user's service request, the following steps are also included: Upon receiving a release request for the target update version, a canary release task is created for the target update version; Extract the coloring rules from the grayscale release task, and determine the coloring ratio of the business request based on the coloring rules.

3. The version update method according to claim 1, characterized in that, The system obtains the target update version of the current version, constructs a simulation database for the target update version, and records the first processing result corresponding to the coloring request in the target update version, including: Extract the first processing logic for the business instruction from the target updated version, process the coloring request according to the first processing logic, and obtain the first processing result; The step of extracting the first processing logic for the business instruction in the target updated version, processing the coloring request according to the first processing logic, and obtaining the first processing result is executed in the simulation database.

4. The version update method according to claim 1, characterized in that, The second processing result of the current version on the uncolored request includes: Extract the second processing logic of the current version for the business request, and process the uncolored request according to the second processing logic to obtain the second processing result.

5. The version update method according to claim 1, characterized in that, The step of verifying the second processing result and the first processing result according to preset target parameters to obtain a verification result includes: Based on the target parameters, extract the first target value of the first processing result; Based on the target parameters, extract the second target value of the second processing result; The first target value and the second target value are compared to obtain the difference rate, and the difference rate is used as the verification result.

6. The version update method according to claim 5, characterized in that, The step of adjusting the staining ratio based on the verification results to obtain the adjusted staining ratio includes: If the difference rate corresponding to the staining ratio is zero, then the staining ratio is increased by a preset increase ratio to obtain an increased staining ratio, and the increased staining ratio is used as the adjusted staining ratio; or If the difference rate corresponding to the staining ratio is not zero, the staining ratio is reduced by a preset reduction ratio to obtain the reduced staining ratio, and the reduced staining ratio is used as the adjusted staining ratio.

7. The version update method according to claim 5, characterized in that, After obtaining the verification result, the process also includes: Obtain a preset rollback threshold. If the difference rate is higher than the rollback threshold, adjust the coloring ratio to zero, execute the business request using the current version, and obtain the processing result of the business request. After obtaining the processing result of the business request, the process also includes: Based on the difference rate, an alarm signal is generated and an alarm log is obtained, which is used for maintenance analysis.

8. A version update device, characterized in that, The version update device is applied to the system's cloud and includes: The coloring module is used to obtain the colored request and the uncolored request after the edge receives the user's service request and performs a coloring operation on the service request according to a preset coloring ratio. The processing module is used to obtain the target update version of the current version of the system, construct a simulation database for the target update version, record the first processing result of the coloring request in the target update version, and the simulation database is used to execute the processing operation of the target update version on the business request. The verification module is used to record the second processing result of the current version on the uncolored request, and to verify the second processing result and the first processing result according to the preset target parameters to obtain the verification result; An adjustment module is used to adjust the staining ratio according to the verification results to obtain an adjusted staining ratio; The version update module is used to take the adjusted coloring ratio as the preset coloring ratio, return the colored request and the uncolored request after performing the coloring operation on the business request according to the preset coloring ratio, until the coloring ratio reaches the preset version release ratio value, obtain the release result of the target updated version, and complete the version update.

9. A computer device, characterized in that, The computer device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the version update method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the version update method as described in any one of claims 1 to 7.

Images