Rolling updates on water level fluctuation assessment methods, devices, computer equipment, and media

Abstract

This application discloses a method, apparatus, computer equipment, and medium for assessing water level fluctuations in rolling deployments, relating to the field of cloud technology. The method includes acquiring deployment configurations and basic data for each cloud cluster; calibrating the performance coefficients of each cloud cluster based on its basic data; calculating the number of deployments per batch for each cloud cluster and dividing the deployment into batches based on the performance coefficients, basic data, and deployment configurations, forming a fixed deployment plan; performing rolling deployments based on the fixed deployment plan and deployment configurations; collecting real-time water level data for each cloud cluster; and automatically pausing deployments and pushing intervention suggestions when the real-time water level data exceeds a preset safe water level threshold, thereby achieving water level fluctuation risk assessment. This application calculates a reasonable number of deployments per batch for each cloud cluster, enabling real-time water level monitoring and threshold warning for each cloud cluster, effectively avoiding problems such as water level overload in some cloud clusters, resource idleness in some cloud clusters, and deployment stagnation.

Description

Technical Field

[0001] This application relates to the field of cloud technology, and in particular to a rolling release method, apparatus, computer equipment and medium for assessing water level fluctuations. Background Technology

[0002] Rolling deployments have become the mainstream method for server updates because they reduce the risk of failure associated with full deployments. Meanwhile, to mitigate the risk of business interruption due to single-cloud vendor failures, multi-cloud deployments have become a core architectural choice for ensuring high system availability.

[0003] However, clusters from different cloud vendors have significant differences in hardware configuration, network environment, and resource scheduling strategies, which makes the issue of water level fluctuations during the rolling deployment process more complex: if the number of deployments in each batch is too large and the interval between batches is too short, machines that have not completed the preheating may carry excessive traffic, causing slow service response or even downtime; if cross-cloud performance differences are not considered and a unified deployment strategy is adopted, it may lead to some clusters being overloaded and some clusters having idle resources. Summary of the Invention

[0004] This application provides a rolling release method, apparatus, computer equipment, and medium for assessing water level fluctuations, to at least address the water level fluctuation problem in the rolling release process in related technologies.

[0005] Firstly, this application provides a rolling release method for assessing water level fluctuations, comprising the following steps: Obtain the release configuration and basic data for each cloud cluster; The performance coefficients of each cloud cluster are calibrated based on the basic data of each cloud cluster. Based on performance coefficients, basic data, and release configurations, the number of deployments per batch for each cloud cluster is calculated and release batches are divided to form a fixed release plan; Rolling releases are based on a fixed release schedule and release configuration. Real-time water level data is collected from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to achieve water level fluctuation risk assessment.

[0006] As a preferred option of the above scheme, the basic data includes historical water levels, and the performance coefficients are calibrated based on the basic data of each cloud cluster, including: The cloud cluster with the lowest historical water level under the same flow rate is used as the benchmark cloud cluster, and the performance coefficient of the benchmark cloud cluster is set as the benchmark performance coefficient. The performance coefficients of other cloud clusters are calculated based on the baseline performance coefficient and the historical water level ratio of other cloud clusters relative to the baseline cloud cluster.

[0007] As a preferred option of the above scheme, the basic data includes the number of deployments per batch in history, historical water level and total number of machines, and the release configuration includes a preset safety water level threshold. The number of deployments per batch is related to the estimated number of unwarmed machines in each cloud cluster based on the release configuration. The formula for calculating the number of deployments per batch is as follows: X = [C - (A × B × K) / D] / N Where X is the number of deployments per batch, A is the historical number of deployments per batch, B is the historical water level, C is the total number of machines, D is the preset safety water level threshold, K is the performance coefficient, and N is the multiple of the estimated number of unwarmed machines E and the number of deployments per batch X, and N is a positive integer. Based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: A×B×K=(CE)×D; The calculated number of deployments per batch is verified by a preset fallback rule and then used as the final number of deployments per batch, X. The preset fallback rule is that the number of deployments per batch shall not exceed C / 4, and the calculation formula for the release batch is C / X.

[0008] As a preferred embodiment of the above scheme, the deployment configuration also includes batch interval time and service type warm-up time. Based on the batch interval time and service type warm-up time, the number of batches that have not completed warm-up in the two most recent batches of machines is determined, so as to correlate the estimated number of unwarmed machines with the number of deployments per batch: When it is determined that neither of the two adjacent batches of machines has completed preheating, N=2; When it is determined that only the previous batch of machines has not completed preheating, N=1.

[0009] As a preferred option of the above scheme, after calculating the number of deployments per batch for each cloud cluster and dividing the release batches, the following is also included: The estimated water level for each cloud cluster is calculated using the following formula: F=[(A×B×K) / (CX)]×100% Where F is the estimated water level, A is the number of deployments per batch in history, B is the historical water level, C is the total number of machines, K is the performance coefficient, and X is the number of deployments per batch. The principle that the total system load of each cloud cluster remains unchanged satisfies: A×B×K=(CX)×F; When the estimated water level exceeds the preset safe water level threshold, adjust the number of deployments and release batches.

[0010] As a preferred embodiment of the above scheme, rolling releases based on a fixed release plan and release configuration also include: Get the real-time number of unwarmed machines in the previous batch of deployed machines in each cloud cluster; The estimated original number of deployments per batch for each cloud cluster is calculated using the following formula: X1 = [CG - (A × B) / D] / N Where X1 is the estimated number of deployments per batch, A is the historical number of deployments per batch, B is the historical water level, C is the total number of machines, D is the preset safety water level threshold, G is the real-time number of unwarmed machines, and N is the multiple of the estimated number of unwarmed machines E and the number of deployments per batch X, and N is a positive integer. Based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: A×B = (CGN×X1)×D; The original number of deployments per batch is estimated based on a performance factor correction, calculated as follows: X2 = X1 × K Where X2 is the estimated number of deployments per batch, and K is the performance coefficient; the calculated estimated number of deployments per batch is verified by the preset fallback rule and then used as the final estimated number of deployments per batch X2. The preset fallback rule is: the estimated number of deployments per batch shall not exceed C / 4. The corrected estimated water level for each cloud cluster is calculated using the following formula: H=[(A×B×K) / (C-X2)]×100% Where H is the corrected estimated water level, and based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: (A×B×K) = (C-X2)×H; When the revised estimated water level exceeds the preset safe water level threshold, the system will automatically pause the release and push intervention suggestions to achieve risk prevention and control of water level fluctuations.

[0011] As a preferred embodiment of the above scheme, rolling releases based on a fixed release plan and release configuration also include: Obtain the status of the previous batch of deployed machines in each cloud cluster to confirm whether preheating has been completed; If the previous batch of deployed machines has not completed its warm-up, a suggestion to extend the release interval for the next batch will be pushed out.

[0012] Secondly, this application provides a rolling release water level fluctuation assessment device, comprising: Acquisition module: Used to acquire release configurations and basic data for each cloud cluster; Calibration module: Used to calibrate the performance coefficients of each cloud cluster based on the basic data of each cloud cluster; Release plan generation module: Used to calculate the number of deployments per batch for each cloud cluster and divide the release batches based on performance coefficients, basic data and release configurations, to form a fixed release plan; Rolling release module: Used for rolling releases based on a fixed release schedule and release configuration; Water level fluctuation assessment module: used to collect real-time water level data from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to realize water level fluctuation risk assessment.

[0013] Thirdly, this application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: Obtain the release configuration and basic data for each cloud cluster; The performance coefficients of each cloud cluster are calibrated based on the basic data of each cloud cluster. Based on performance coefficients, basic data, and release configurations, the number of deployments per batch for each cloud cluster is calculated and release batches are divided to form a fixed release plan; Rolling releases are based on a fixed release schedule and release configuration. Real-time water level data is collected from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to achieve water level fluctuation risk assessment.

[0014] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, performs the following steps: Obtain the release configuration and basic data for each cloud cluster; The performance coefficients of each cloud cluster are calibrated based on the basic data of each cloud cluster. Based on performance coefficients, basic data, and release configurations, the number of deployments per batch for each cloud cluster is calculated and release batches are divided to form a fixed release plan; Rolling releases are based on a fixed release schedule and release configuration. Real-time water level data is collected from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to achieve water level fluctuation risk assessment.

[0015] The rolling deployment water level fluctuation assessment method of this application introduces the performance coefficient of each cloud cluster. Before deployment, the number of deployments per batch for each cloud cluster is pre-quantified and calculated based on the performance coefficient, and the deployment batches are divided. Then, rolling deployment is carried out according to the calculated number of deployments per batch, the deployment batches, and the deployment configuration. During the rolling deployment, real-time water level data of each cloud cluster is collected. When the real-time water level exceeds the preset safe water level threshold, the deployment is automatically paused and intervention suggestions such as reducing the number of deployments in the next batch or extending the interval between deployment batches are pushed to achieve water level fluctuation risk control. In this way, the reasonable number of deployments per batch for each cloud cluster is automatically calculated, replacing manual experience judgment, realizing real-time water level monitoring and threshold early warning for each cloud cluster, effectively avoiding the problems of water level overload in some cloud clusters, idle resources in some cloud clusters, and deployment stagnation, and improving the stability of rolling deployment. Attached Figure Description

[0016] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0017] Figure 1 A flowchart illustrating the rolling release method for assessing water level fluctuations provided in this application embodiment; Figure 2 A flowchart illustrating the rolling release method for assessing water level fluctuations provided in this application embodiment; Figure 3 A structural block diagram of the water level fluctuation assessment device provided in the embodiments of this application; Figure 4 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0019] As described in the background section, with the continuous expansion of ride-hailing SaaS system business scale, the frequency of service updates is constantly increasing. Rolling releases have become the mainstream method for server-side updates because they can reduce the failure risk of full releases. At the same time, to avoid the risk of business interruption caused by single cloud vendor failures, multi-cloud deployment has become the core architectural choice to ensure high system availability.

[0020] However, clusters from different cloud vendors have significant differences in hardware configuration, network environment, and resource scheduling strategies, which makes the issue of water level fluctuations during the rolling deployment process more complex: if the number of deployments in each batch is too large and the interval between batches is too short, machines that have not completed the preheating may carry excessive traffic, causing slow service response or even downtime; if cross-cloud performance differences are not considered and a unified deployment strategy is adopted, it may lead to some clusters being overloaded and some clusters having idle resources.

[0021] Existing rolling deployment level assessment solutions mainly fall into two categories: 1. Fixed batch deployment scheme: Operations personnel set the number of machines deployed per batch and the batch interval based on manual experience, failing to consider performance differences across multi-cloud clusters and relying entirely on subjective judgment, resulting in low accuracy; 2. Single-environment level monitoring scheme: This scheme can only monitor the level of a single cloud cluster, lacks cross-cloud adaptation mechanisms, and does not link with traffic preheating progress, making it impossible to predict the risk of level fluctuations during multi-cluster collaborative deployments. Neither of these solutions addresses core issues such as cross-cloud difference adaptation, scientific batch planning, and preheating / deployment coordination in multi-cloud environments.

[0022] The existing rolling deployment water level assessment scheme has the following problems: 1. Lack of multi-cloud adaptation: It does not consider the performance differences of different cloud clusters and adopts a unified deployment strategy, resulting in overload of some weaker clusters and waste of resources in some stronger clusters; 2. Unscientific batch planning: There is no quantitative prediction model. The number of deployments in each batch and the batch interval are all set manually based on experience, which easily leads to problems such as "too many batches leading to excessively long deployment cycles" or "too few batches leading to a sudden rise in water level"; 3. Insufficient preheating coordination: The service preheating progress is not linked with the deployment process. The next batch of deployment is started before the preheating is completed, resulting in excessive traffic on unpreheated machines and causing the water level to remain high; 4. Lack of cross-cloud monitoring: There is no unified real-time monitoring mechanism for multi-cloud clusters, making it impossible to detect water level anomalies in individual clusters in a timely manner, resulting in a lag in risk response.

[0023] The rolling deployment water level fluctuation assessment method provided in this application introduces performance coefficients for each cloud cluster and designs a quantitative formula for batch deployment quantity. Based on parameters such as the total number of machines, historical water level data, and the estimated number of machines not yet warmed up, it automatically calculates a reasonable deployment quantity for each batch, replacing manual experience-based judgment. It constructs a water level prediction model for each cloud cluster by combining historical deployment data and calibrates the performance differences between different cloud clusters through performance coefficients to achieve accurate water level prediction for each cloud cluster. It establishes a warming-up linkage verification mechanism to obtain the warming progress of the previous batch of machines in real time and, combined with the preset warming time for the service type, judges the feasibility of the next batch of deployments to avoid water level risks caused by lack of warming up. It realizes real-time water level monitoring and threshold early warning for each cloud cluster, collects real-time water level data for each cloud cluster, and automatically suspends deployment and pushes adjustment suggestions when the real-time water level exceeds the preset safe water level threshold, achieving proactive risk prevention and control.

[0024] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] Example 1 This application provides a rolling release method for assessing water level fluctuations, such as... Figure 1 , Figure 2 As shown, it includes the following steps: S1: Obtain the release configuration and basic data for each cloud cluster.

[0026] Specifically, the release configuration can be obtained in the following release scenarios: For ride-hailing core dispatch service (Dubbo type, 3-minute warm-up time), rolling release needs to be performed on Alibaba Cloud publish cluster (100 nodes) and Tencent Cloud tx-gz-1 cluster (80 nodes). The release method is automatic release, the batch interval is 2 minutes, the water level data is selected as CPU utilization, and the preset safe water level threshold (CPU utilization) is 50%.

[0027] Obtain the core parameters for rolling deployment in the above deployment scenarios to clarify the deployment scope and rules. Specifically, obtain the deployment configuration for the above deployment scenarios: pull the core configuration parameters for rolling deployment through the system interface, including the total number of deployed machines, the target cloud cluster list (e.g., Alibaba Cloud publish cluster, Tencent Cloud tx-gz-1 cluster), service type (dubbo / http / gateway), deployment method (automatic deployment / manual deployment), batch interval time for automatic deployment, etc. Specifically, the system automatically pulls standardized configuration parameters through the deployment platform interface, eliminating the need for manual input and ensuring parameter consistency. Core configuration items: total number of deployed machines (100 Alibaba Cloud machines, 80 Tencent Cloud machines), target cloud clusters (Alibaba Cloud publish, Tencent Cloud tx-gz-1), service type (dubbo, associated preheating rules), preheating time for service type, deployment method (automatic deployment), batch interval time (2 minutes), preset safety water level threshold (50%).

[0028] Specifically, basic data for each cloud cluster can be obtained through a unified monitoring interface. This basic data includes the number of deployments per batch, historical deployment levels, and the total number of machines. It can be historical deployment level data (CPU utilization) for similar deployments within the last 30 days. The data collection frequency is once per minute to ensure data timeliness. Specifically, the data collection rule can be to call the monitoring platform's batch interface to continuously collect data for 5 minutes at a frequency of once per minute, and then take the average value to avoid the impact of instantaneous data fluctuations on the assessment.

[0029] The basic data collected can be as follows: Alibaba Cloud publish cluster: total number of machines 100, historical average load of similar releases in the past 30 days (historical load, i.e., average load per machine) 40%, historical best release batch number (historical deployment number per batch) 40; Tencent Cloud tx-gz-1 cluster: total number of machines 80, historical average load of similar releases in the past 30 days 55%, historical best release batch number 30. After data collection, the data can be temporarily written to the multi_cloud_release_metrics data table and retained for 14 days for post-release review and coefficient optimization.

[0030] S2: Based on the basic data of each cloud cluster, calibrate the performance coefficients of each cloud cluster.

[0031] Specifically, S2 includes: S21: Take the cloud cluster with the lowest historical water level under the same flow rate as the benchmark cloud cluster, and set the performance coefficient of the benchmark cloud cluster as the benchmark performance coefficient.

[0032] Specifically, the performance coefficient can be set to K. Data on the actual CPU utilization of each cloud cluster under the same business and traffic pressure over the past 30 days can be collected. The cloud cluster with the lowest historical utilization, i.e., the best performance, is used as the benchmark cloud cluster (such as Alibaba Cloud Publish). The performance coefficient of the benchmark cloud cluster is set as the benchmark performance coefficient. The benchmark performance coefficient K is set to 0.9 (or 1, which can be finely adjusted; in this embodiment, it is set to 0.9). The stronger the performance of the cloud cluster, the smaller the K value. For example, the K value for the Alibaba Cloud Publish cluster is set to 0.9.

[0033] S22: Calculate the performance coefficients of other cloud clusters based on the baseline performance coefficients and the historical water level ratios of other cloud clusters relative to the baseline cloud cluster.

[0034] For example, to calculate the performance coefficient of a target cloud cluster among other cloud clusters, the performance coefficient K of the target cloud cluster is calculated as: (Historical performance level of the target cloud cluster / Historical performance level of the benchmark cloud cluster) × Benchmark performance coefficient. That is, the performance difference between clusters is first determined by the historical performance level ratio, and then adjusted based on the benchmark K to ensure a strong correlation between K and cluster performance. For example, if the K of the Tencent Cloud TX-GZ-1 cluster is 55% / 40% × 0.9 = 1.375 × 0.9 ≈ 1.2, then the K of the Tencent Cloud TX-GZ-1 cluster is set to 1.2.

[0035] Different cloud vendors' clusters have varying hardware configurations (such as CPU model and memory specifications), network environments, and resource scheduling strategies. Even with the same CPU utilization, their actual carrying capacity can differ. High-performance clusters (such as Alibaba Cloud Publish) still have sufficient redundancy at 50% CPU utilization; while low-performance clusters (such as Tencent Cloud TX-GZ-1) are approaching overload thresholds at 50% CPU utilization. Therefore, a performance coefficient K is needed to adjust the number of deployments per batch. The rule for setting the K value is: the higher the performance of the cluster, the smaller the K value (≤1); the lower the performance of the cluster, the larger the K value (≥1).

[0036] The process of obtaining and publishing configurations in S1 can also be performed between S2 and S3.

[0037] S3: Based on performance coefficients, basic data, and release configurations, calculate the number of deployments per batch for each cloud cluster and divide the release batches to form a fixed release plan.

[0038] Specifically, the number of deployments in each batch is based on the release configuration and the estimated number of unwarmed machines in each cloud cluster. The calculation formula for the number of deployments in each batch is as follows, denoted as Equation 1: X = [C - (A × B × K) / D] / N Where X is the number of deployments per batch, A is the historical number of deployments per batch, B is the historical water level, C is the total number of machines, D is the preset safety water level threshold, K is the performance coefficient, and N is the multiple of the estimated number of unwarmed machines E and the number of deployments per batch X, where N is a positive integer. The overall system load remains constant across all cloud clusters, satisfying the principle: A × B × K = (CE) × D, denoted as Equation 2. Equation 2 is the fundamental and core formula, and Equation 1 is derived from it. The essence of Equation 2 is that during the deployment process, the overall system load remains constant across all cloud clusters, only being redistributed among the "machines that can provide normal service." A × B × K represents the total system load in historical deployment scenarios, corrected by K. (CE) × D represents the total system load in the current deployment scenario. Because the total load is conserved, the total system load in historical deployment scenarios and the current deployment scenario are equal, forming the core formula. The preset safety water level threshold is the maximum safe load allowed during the release process (e.g., 50% CPU utilization). The preset safety water level threshold is directly used as the "acceptable estimated upper limit of the water level". The reasonable number of batch deployments is calculated by back-calculating Equation 2 to ensure that the water level does not exceed the safety line during release.

[0039] The deployment configuration also includes batch interval and service type warm-up time. Based on the batch interval and service type warm-up time, the number of batches that have not completed warm-up in the two most recent batches of machines is determined, and then correlated with the estimated number of unwarmed machines and the number of deployments per batch: When it is determined that neither of the two adjacent batches of machines has completed preheating, N=2; When it is determined that only the previous batch of machines has not completed preheating, N=1.

[0040] The relationship between the estimated number of unwarmed machines and the number of deployments per batch is as follows: if the next batch is released without prewarming the previous batch, the number of unwarmed machines = the number of deployments per batch × 2 (neither batch is available); if only the previous batch was not prewarmed, the number of unwarmed machines = the number of deployments per batch × 1 (only one batch is unavailable). Therefore, the unified rule is: number of unwarmed machines = the number of deployments per batch * N (N = 1 or 2).

[0041] For example, there are two deployment scenarios: Scenario 1 (deployment configuration includes automatic deployment, service type is Dubbo, warm-up time is 3 minutes, batch interval is 2 minutes), and Scenario 2 (deployment configuration includes automatic / manual deployment, service type is Dubbo, warm-up time is 3 minutes, batch interval is ≥3 minutes). In Scenario 1, since the deployment method is automatic deployment and the batch interval is 2 minutes (< the service type warm-up time of 3 minutes), it is determined that neither of the two adjacent batches of machines has completed warm-up, so N=2, X=[C-(A×B×K) / D] / 2. Substituting into the basic data of the Alibaba Cloud publish cluster above, we calculate: X=[100-(40×40%×0.9) / 50%] / 2=35.6 machines, rounded to 36 machines; substituting into the basic data of the Tencent Cloud tx-gz-1 cluster above, we calculate: X=[80-(30×55%×1.2) / 50%] / 2=20.2 machines, rounded to 20 machines.

[0042] The calculated number of deployments per batch, after passing a preset fallback rule, is used as the final number of deployments per batch, X, to avoid deploying too many machines in a single batch. The preset fallback rule states that the number of deployments per batch cannot exceed C / 4, and the calculation formula for the number of release batches is C / X, rounded up. After the preset fallback rule corrects for X ≤ C / 4, the final numbers are: Alibaba Cloud publish cluster X = C / 4 = 100 / 4 = 25 machines, with 100 / 25 = 4 release batches; Tencent Cloud tx-gz-1 cluster X = C / 4 = 80 / 4 = 20 machines, with 80 / 20 = 4 release batches.

[0043] Therefore, the number of deployments and release batches were determined before the release, thus forming a fixed release plan.

[0044] After calculating the number of deployments per batch for each cloud cluster and dividing the release batches, the following steps are also included: S31: Calculate the estimated water level for each cloud cluster, using the following formula: F=[(A×B×K) / (CX)]×100% Where F is the estimated water level, A is the number of deployments per batch in history, B is the historical water level, C is the total number of machines, K is the performance coefficient, and X is the number of deployments per batch calculated in S3. The above calculation formula satisfies the principle that the total system load of each cloud cluster remains unchanged: A×B×K=(CX)×F. In the above formula, the left side of the equation represents the historical total load after K correction, the right side of the equation represents the current number of serviceable machines, and the estimated water level F represents the proportion of the current load distributed to each serviceable machine.

[0045] S32: When the estimated water level exceeds the preset safe water level threshold, adjust the number of deployments per batch and the number of release batches; when the estimated water level does not exceed the preset safe water level threshold, maintain the number of deployments per batch and the number of batches calculated in S3 to form the final fixed release plan.

[0046] Specifically, when the estimated water level exceeds the preset safe water level threshold, it means that if the current release plan is followed, there may be a risk of water level overload during the release process. The original release plan can be adjusted by reducing the number of deployments per batch, splitting batches, or increasing the number of release batches, while complying with the preset fallback rules. This will help to avoid the risk of water level overload caused by unreasonable batch planning in subsequent releases from the source.

[0047] When the estimated water level does not exceed the preset safe water level threshold, the number of deployments and batches calculated in S3 are maintained to form the final fixed release plan. Taking scenario 1 in S3 as an example, the estimated water level F is calculated as follows: Alibaba Cloud publish cluster: F=[(A×B×K) / (CX)]×100%=[(40×40%×0.9) / (100-25)]×100%=19.2%≤ 50%; Tencent Cloud tx-gz-1 cluster: F=[(A×B×K) / (CX)]×100%=[(30×55%×1.2) / (80-20)]×100%=33%≤ 50%. Therefore, under the release plans of 25 deployments per batch and 4 release batches, and 20 deployments per batch and 4 release batches respectively, the estimated water level of Alibaba Cloud publish cluster and Tencent Cloud tx-gz-1 cluster did not exceed the preset safe water level threshold. The original fixed release plan can be maintained, and no cluster water level will be overloaded during subsequent releases. At the same time, through performance coefficient K correction, no cluster resource redundancy will occur.

[0048] The above process unifies the water level assessment standards for each cloud cluster, all of which are adapted to a preset security threshold of 50%, thus solving the problems of water level overload and resource redundancy in some clusters caused by the unified release strategy.

[0049] S4: Rolling releases are based on a fixed release schedule and release configuration.

[0050] Specifically, the deployment of each cloud cluster (Alibaba Cloud publish cluster and Tencent Cloud tx-gz-1 cluster) can be carried out serially or in parallel, with parallel deployment being preferred to improve deployment efficiency. Furthermore, the rolling deployment of each cloud cluster is executed independently and does not interfere with each other.

[0051] Rolling deployments will be carried out based on the fixed deployment plan (number of deployments per batch, number of deployments per batch) determined above. During the rolling deployment process, only the water level will be monitored to ensure safety. The number of deployments per batch and the number of deployments per batch will not be automatically adjusted unless the operation and maintenance personnel intervene to avoid system chaos caused by frequent automatic parameter changes during the deployment.

[0052] S5: Collects real-time water level data from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, it automatically pauses the release and pushes intervention suggestions to achieve water level fluctuation risk assessment.

[0053] Specifically, the monitoring agent collects real-time water level data for each cloud cluster every 10 seconds, monitoring only machines in deployed batches to exclude interference from undeployed machines. The real-time water level data is compared to a preset safe water level threshold. If the real-time water level data does not exceed the preset safe water level threshold, the system automatically proceeds to the next batch deployment without manual intervention. If the real-time water level data exceeds the preset safe water level threshold, the system automatically pauses the current deployment process and pushes intervention (adjustment) suggestions to the operations and maintenance personnel, such as "reduce the number of deployments per batch to XX machines" or "extend the batch interval to XX minutes," to achieve water level fluctuation risk assessment and control. After the operations and maintenance personnel confirm the adjustment, steps S3 and S4 are re-executed.

[0054] For example, if the real-time water level data collected after the second batch of deployments for the Alibaba Cloud publish cluster is below 50%, while the real-time water level data collected after the second batch of deployments for the Tencent Cloud TX-GZ-1 cluster reaches 58%, the deployment process for the Tencent Cloud TX-GZ-1 cluster will be immediately suspended, while the Alibaba Cloud publish cluster will proceed normally. An alert will be automatically pushed to the operations and maintenance personnel of the Tencent Cloud TX-GZ-1 cluster, including specific adjustment suggestions such as: "Tencent Cloud TX-GZ-1 cluster real-time water level 58%, suggestions: ① Reduce the number of deployments in the next batch to 10; ② Extend the batch interval to more than 3 minutes." After the operations and maintenance personnel confirm the adjustments, the system will re-execute the process of "determining the number of deployments and release batches → rolling release → real-time water level monitoring" until the real-time water level returns to a safe range.

[0055] In addition, real-time water level data can be compared with the estimated water level calculated in S31 to analyze fluctuation deviations. For example, after the first batch of 25 Alibaba Cloud publish clusters were deployed, the real-time CPU utilization rate was 20%, compared with the estimated water level of 19.2%, with a deviation of ≤5%, which is considered normal. After the first batch of 20 Tencent Cloud tx-gz-1 clusters were deployed, the real-time CPU utilization rate was 35%, compared with the estimated water level of 33%, with a deviation of ≤5%, which is also considered normal. Finally, the real-time water level data can be written to the monitoring log in real time to form a real-time water level change trend curve.

[0056] S6: Calculate and correct the estimated water level. When the corrected estimated water level exceeds the preset safe water level threshold, the release will be automatically paused and intervention suggestions will be pushed to achieve water level fluctuation risk prevention and control.

[0057] The estimated water level correction is performed during the release process using a performance factor K to calibrate the estimated water level results for different cloud clusters. Its core purpose is to offset performance differences between cloud clusters, ensuring a unified and accurate cross-cloud water level assessment standard. Different cloud clusters have varying hardware configurations (such as CPU model and memory specifications), network environments, and resource scheduling strategies. Even with the same CPU utilization, their actual carrying capacity can differ: High-performance clusters (such as Alibaba Cloud Publish) still have sufficient redundancy at 50% CPU utilization; low-performance clusters (such as Tencent Cloud TX-GZ-1) are approaching the overload threshold at 50% CPU utilization. Therefore, the estimated water level needs to be corrected using the performance factor K.

[0058] Specifically, S6 includes: S61: Get the real-time number of unheated machines in the previous batch of deployed machines in each cloud cluster.

[0059] During the deployment process, various factors may cause the real-time number of unwarmed machines to differ from the estimated number of unwarmed machines before deployment. For example, there may be machine failures that prevent the provision of services. Therefore, it is necessary to query the real-time number of unwarmed machines of the previous batch of deployed machines in real time to obtain the number of machines that can provide services (total number of machines - real-time number of unwarmed machines).

[0060] The preheating progress of the previously deployed machines can be obtained through the service registry. If the machine deployment completion time does not exceed the preset preheating time for the corresponding service type (3 minutes for Dubbo), it is determined to be an "unpreheated machine" and counted in the real-time unpreheated machine count.

[0061] S62: Calculate the estimated original number of deployments per batch for each cloud cluster, using the following formula: X1 = [CG - (A × B) / D] / N Where X1 is the estimated original number of deployments per batch, A is the historical number of deployments per batch, B is the historical water level, C is the total number of machines, D is the preset safety water level threshold, G is the real-time number of unwarmed machines, and N is the multiple of the estimated number of unwarmed machines E and the number of deployments per batch X, and N is a positive integer, N is 1 or 2, and based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: A×B=(CGN×X1)×D, the left side of the above equation represents the historical total load, and the right side of the equation represents the total load of the current number of serviceable machines (total number of machines - real-time number of unwarmed machines - number of unavailable batches of machines).

[0062] Because the estimated number of unwarmed machines before deployment differs from the real-time number, the planned deployment count for each batch needs to be calibrated during the deployment process to obtain the original estimated deployment count for each batch. The more unwarmed machines in the previous batch, the fewer deployments in the next batch, in order to obtain the corrected estimated deployment level later. Once the original estimated deployment count for each batch is calculated, the system will not automatically change the planned deployment count for each batch.

[0063] S63: The original number of deployments per batch is revised based on the performance coefficient, calculated as follows: X2 = X1 × K Where X2 is the estimated number of deployments per batch, and K is the performance coefficient; the calculated estimated number of deployments per batch is verified by the preset fallback rule and then used as the final estimated number of deployments per batch X2. The preset fallback rule is: the estimated number of deployments per batch shall not exceed C / 4.

[0064] Specifically, after estimating the original number of deployments per batch, it needs to be corrected using a performance coefficient K, and the corrected number of deployments per batch also needs to be verified by preset fallback rules. For example... S64: Calculate the corrected estimated water level for each cloud cluster, using the following formula: H=[(A×B×K) / (C-X2)]×100% Where H is the corrected estimated water level, and based on the principle that the total system load of each cloud cluster remains unchanged, the formula (A×B×K) = (C-X2)×H is satisfied. The above formula is also based on the principle of load conservation.

[0065] S65: When the revised estimated water level exceeds the preset safe water level threshold, the release will be automatically paused and intervention suggestions will be pushed to achieve water level fluctuation risk prevention and control; when the revised estimated water level does not exceed the preset safe water level threshold, the system will automatically advance the next batch of releases without manual intervention.

[0066] For example, in the rolling release scenario 1 above, the Alibaba Cloud publish cluster obtains 25 real-time unwarmed machines, and N=2. Then X1=[CG-(A×B) / D] / N=[100-25-(40×40%) / 50%] / 2=21.5. X1 is rounded up to 22 machines. X2=X1×K=22×0.9=19.8. X2 is rounded up to 20. X2=20≤(80 / 4), so X2 is 20 machines. H=[(A×B×K) / (C-X2)]×100%= [(40×40%×0.9) / (100-20)]×100%=18%<50%. Therefore, the system automatically advances the next batch of releases without manual intervention.

[0067] S7: Preheating linkage verification.

[0068] Specifically, S7 includes: S71: Obtain the status of the previous batch of deployed machines in each cloud cluster and confirm whether preheating has been completed.

[0069] Before deploying the next batch, check whether the previous batch of machines has completed warm-up. Taking the Dubbo service as an example, you can check whether 3 minutes have passed since the previous batch of machines was deployed. If only 1 minute has passed since the previous batch of machines was deployed, then it is determined that the previous batch of machines has not completed warm-up.

[0070] S72: If the previous batch of deployed machines has not completed its warm-up, a suggestion to extend the release interval for the next batch will be pushed.

[0071] Specifically, if the machines deployed in the previous batch were not preheated, the number of unpreheated machines will accumulate in the next batch (the number of unpreheated machines from the previous batch plus the number of newly deployed machines from the next batch), reducing the number of machines available for service. Therefore, it is necessary to issue alerts to operations and maintenance personnel to prevent the service level from exceeding the limit.

[0072] It should be noted that steps S5, S6, and S7 are all performed after the rolling release begins. They are independent steps that can be performed in parallel or sequentially. When performed sequentially, the order of each step can be adjusted.

[0073] The rolling deployment water level fluctuation assessment method of this application introduces the performance coefficient of each cloud cluster. Before deployment, the number of deployments per batch for each cloud cluster is pre-quantified and calculated based on the performance coefficient, and the deployment batches are divided. Then, rolling deployment is carried out according to the calculated number of deployments per batch, the deployment batches, and the deployment configuration. During the rolling deployment, real-time water level data of each cloud cluster is collected. When the real-time water level exceeds the preset safe water level threshold, the deployment is automatically paused and intervention suggestions such as reducing the number of deployments in the next batch or extending the interval between deployment batches are pushed to achieve water level fluctuation risk control. In this way, the reasonable number of deployments per batch for each cloud cluster is automatically calculated, replacing manual experience judgment, realizing real-time water level monitoring and threshold early warning for each cloud cluster, effectively avoiding the problems of water level overload in some cloud clusters, idle resources in some cloud clusters, and deployment stagnation, and improving the stability of rolling deployment.

[0074] Example 2 This application provides a rolling release water level fluctuation assessment device, such as... Figure 3 As shown, it includes: Module 1: Used to obtain the release configuration and basic data of each cloud cluster; Calibration Module 2: Used to calibrate the performance coefficients of each cloud cluster based on the basic data of each cloud cluster; Release plan generation module 3: It is used to calculate the number of deployments per batch for each cloud cluster and divide the release batches based on performance coefficients, basic data and release configurations, and form a fixed release plan; Predicted water level calculation module 4: Used to calculate the predicted water level of each cloud cluster. When the predicted water level exceeds the preset safe water level threshold, the number of deployments and release batches are adjusted to form the final fixed release plan.

[0075] Rolling Release Module 5: Used for rolling releases based on a fixed release plan and release configuration; Water level fluctuation assessment module 6: Used to collect real-time water level data from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, it automatically pauses the release and pushes intervention suggestions to realize water level fluctuation risk assessment.

[0076] Module 7 for calculating corrected estimated water level: When the corrected estimated water level exceeds the preset safe water level threshold, the release will be automatically paused and intervention suggestions will be pushed to achieve risk prevention and control of water level fluctuations.

[0077] Preheating linkage verification module 8: Used for preheating linkage verification.

[0078] Thirdly, this application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: Obtain the release configuration and basic data for each cloud cluster; The performance coefficients of each cloud cluster are calibrated based on the basic data of each cloud cluster. Based on performance coefficients, basic data, and release configurations, the number of deployments per batch for each cloud cluster is calculated and release batches are divided to form a fixed release plan; Calculate the estimated water level of each cloud cluster. When the estimated water level exceeds the preset safe water level threshold, adjust the number of deployments and release batches to form the final fixed release plan. Rolling releases are based on a fixed release schedule and release configuration. Collect real-time water level data from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, automatically pause the release and push intervention suggestions to achieve water level fluctuation risk assessment. The system calculates and corrects the estimated water level. When the corrected estimated water level exceeds the preset safe water level threshold, the system automatically pauses the release of data and pushes intervention suggestions to achieve risk prevention and control of water level fluctuations.

[0079] Preheating linkage verification.

[0080] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores data in the distributed storage. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a capacity balancing optimization method for distributed storage.

[0081] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0082] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, performs the following steps: Obtain the release configuration and basic data for each cloud cluster; The performance coefficients of each cloud cluster are calibrated based on the basic data of each cloud cluster. Based on performance coefficients, basic data, and release configurations, the number of deployments per batch for each cloud cluster is calculated and release batches are divided to form a fixed release plan; Calculate the estimated water level of each cloud cluster. When the estimated water level exceeds the preset safe water level threshold, adjust the number of deployments and release batches to form the final fixed release plan. Rolling releases are based on a fixed release schedule and release configuration. Collect real-time water level data from each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, automatically pause the release and push intervention suggestions to achieve water level fluctuation risk assessment. The system calculates and corrects the estimated water level. When the corrected estimated water level exceeds the preset safe water level threshold, the system automatically pauses the release of data and pushes intervention suggestions to achieve risk prevention and control of water level fluctuations.

[0083] Preheating linkage verification.

[0084] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0085] The foregoing has provided a detailed description of the rolling release method, apparatus, computer equipment, and medium for assessing water level fluctuations provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for assessing water level fluctuations through rolling updates, characterized in that, Includes the following steps: Obtain the release configuration and basic data for each cloud cluster; The performance coefficients of each cloud cluster are determined based on the basic data of each cloud cluster. Based on the performance coefficients, the basic data, and the release configuration, the number of deployments per batch for each cloud cluster is calculated and the release batches are divided to form a fixed release plan; Rolling releases will be performed based on the fixed release plan and the release configuration. Real-time water level data of each cloud cluster is collected. When the real-time water level data exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to achieve water level fluctuation risk assessment.

2. The rolling water level fluctuation assessment method according to claim 1, characterized in that, The basic data includes historical water levels, and the performance coefficients calibrated based on the basic data of each cloud cluster include: The cloud cluster with the lowest historical water level under the same flow rate is taken as the benchmark cloud cluster, and the performance coefficient of the benchmark cloud cluster is set as the benchmark performance coefficient. The performance coefficients of the other cloud clusters are calculated based on the baseline performance coefficients and the historical water level ratios of the other cloud clusters relative to the baseline cloud cluster.

3. The rolling water level fluctuation assessment method according to claim 1, characterized in that, The basic data includes the number of deployments per batch in history, historical water level, and total number of machines. The release configuration includes a preset safety water level threshold. The number of deployments per batch is associated with the estimated number of unwarmed machines in each cloud cluster based on the release configuration. The formula for calculating the number of deployments in each batch is as follows: X = [C - (A × B × K) / D] / N Where X is the number of deployments per batch, A is the historical number of deployments per batch, B is the historical water level, C is the total number of machines, D is the preset safety water level threshold, K is the performance coefficient, and N is the multiple of the estimated number of unwarmed machines E and the number of deployments per batch X, and N is a positive integer. Based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: A×B×K=(CE)×D; The calculated number of deployments per batch, after being verified by a preset fallback rule, is taken as the final number of deployments per batch, X. The preset fallback rule is that the number of deployments per batch does not exceed C / 4, and the formula for calculating the release batch is C / X.

4. The rolling water level fluctuation assessment method according to claim 3, characterized in that, The deployment configuration also includes batch interval time and service type warm-up time. Based on the batch interval time and service type warm-up time, the number of batches that have not completed warm-up in the two most recent batches of machines is determined, so as to correlate the estimated number of machines that have not been warmed up with the number of deployments per batch: When it is determined that neither of the two adjacent batches of machines has completed preheating, N=2; When it is determined that only the previous batch of machines has not completed preheating, N=1.

5. The rolling water level fluctuation assessment method according to claim 3, characterized in that, The process of calculating the number of deployments per batch for each cloud cluster and dividing the release batches also includes: The estimated water level for each cloud cluster is calculated using the following formula: F=[(A×B×K) / (CX)]×100% Where F is the estimated water level, A is the number of deployments per batch in history, B is the historical water level, C is the total number of machines, K is the performance coefficient, X is the number of deployments per batch, and based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: A×B×K=(CX)×F; When the estimated water level exceeds the preset safe water level threshold, adjust the number of deployments per batch and the release batch.

6. The rolling water level fluctuation assessment method according to claim 5, characterized in that, The rolling release based on the fixed release plan and the release configuration also includes: Obtain the real-time number of unheated machines in the previous batch of deployed machines for each cloud cluster; The estimated original number of deployments per batch for each cloud cluster is calculated using the following formula: X1 = [CG - (A × B) / D] / N Where X1 is the estimated original number of deployments per batch, A is the historical number of deployments per batch, B is the historical water level, C is the total number of machines, D is the preset safety water level threshold, G is the real-time number of unwarmed machines, and N is a multiple of the estimated number of unwarmed machines E and the number of deployments per batch X, and N is a positive integer. Based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: A×B = (CGN×X1)×D; The estimated number of deployments per batch is corrected based on the performance coefficient, calculated as follows: X2 = X1 × K Where X2 is the estimated number of deployments per batch, and K is the performance coefficient; the estimated number of deployments per batch calculated and verified by the preset fallback rule is taken as the final estimated number of deployments per batch X2, wherein the preset fallback rule is: the estimated number of deployments per batch does not exceed C / 4. The corrected estimated water level for each cloud cluster is calculated using the following formula: H=[(A×B×K) / (C-X2)]×100% Where H is the corrected estimated water level, and based on the principle that the total system load of each cloud cluster remains unchanged, the following condition is met: (A×B×K) = (C-X2)×H; When the revised estimated water level exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to achieve water level fluctuation risk prevention and control.

7. The rolling water level fluctuation assessment method according to claim 1, characterized in that, The rolling release based on the fixed release plan and the release configuration also includes: Obtain the status of the previous batch of deployed machines in each cloud cluster to confirm whether preheating has been completed; If the previous batch of deployed machines has not completed its warm-up, a suggestion to extend the release interval for the next batch will be pushed.

8. A rolling water level fluctuation assessment device, characterized in that, include: Acquisition module: Used to acquire release configurations and basic data for each cloud cluster; Calibration module: used to calibrate the performance coefficients of each cloud cluster based on the basic data of each cloud cluster; Release plan generation module: used to calculate the number of deployments per batch for each cloud cluster and divide the release batches based on the performance coefficient, the basic data and the release configuration, and form a fixed release plan; Rolling release module: used to perform rolling releases based on the fixed release plan and the release configuration; Water level fluctuation assessment module: used to collect real-time water level data of each cloud cluster. When the real-time water level data exceeds the preset safe water level threshold, the release is automatically paused and intervention suggestions are pushed to realize water level fluctuation risk assessment.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images