A mature timing and action condition supply micro-service scaling method and system

Abstract

The application discloses a micro-service scaling method and system with mature timing and action condition supply. The method obtains the current serviceable replica state and the mature event record containing the replica quantity and the predicted serviceable time, forms the time step by time step reference supply in the prediction window, and compares the reference capacity gap with the load demand prediction value at the same time step. The hard constraint action set is formed according to the replica quantity, the resource quota and the scaling constraint, the action condition supply track is formed according to the capacity effective time of the candidate action, the action after capacity gap is recalculated, and the final action is determined by comprehensively considering the capacity risk, the resource occupation and the action switching cost. The next period mature event record is updated according to the replica maturity, delay, failure, cancellation and stop service feedback. Therefore, the service capacity of the replica to be started and the candidate action is involved in the evaluation according to the actual effective timing, and the risk of repeated scaling and wrong scaling is reduced.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing, container orchestration, and microservice resource management, and specifically to a microservice scaling control method and system that maps the maturity time of replicas to be started, the effective time of candidate action capabilities, and future load requirements to the same time axis for evaluation. Background Technology

[0002] Microservices typically run as container replicas. Reactive scaling suffers from provisioning lag; while predictive scaling can act in advance, replicas require resource allocation, startup, and health checks before they can provide services, and the time it takes for capacity to be available may differ. Summary of the Invention

[0003] I. Technical problems to be solved

[0004] The technical problem this invention aims to solve is to prevent future service capabilities from being prematurely included or deducted later when the replica to be launched and the candidate action have different capability activation times, thereby reducing the risks of repeated expansion, erroneous scaling down, and persistent capacity gaps.

[0005] II. Technical Solution

[0006] Step S101: Obtain load, replica maturity events, and constraint status; S102: Obtain multi-step demand forecast values; S103: Form a baseline supply trajectory; S104: Calculate the baseline gap at the same time step; S105: Form a set of hard constraint actions; S106: Form action condition supply based on the effective time of candidate actions and recalculate the gap; S107: Determine the final action through comprehensive evaluation; S108: Send the action and update the maturity events based on actual feedback.

[0007] III. Beneficial Effects

[0008] This invention records the supply in transit according to the expected service time, compares the predicted demand, baseline supply and operational condition supply on the same time axis, and corrects the subsequent supply trajectory based on the actual life cycle feedback. Attached Figure Description

[0009] Figure 1 This is the overall flowchart of the microservice scaling control method of the present invention;

[0010] Figure 2 This is a schematic diagram of the microservice scaling control system structure of the present invention;

[0011] Figure 3 This is a schematic diagram illustrating the baseline supply trajectory for the formation of the prototype maturation event of the present invention.

[0012] Figure 4 This is a schematic diagram showing the simultaneous axis comparison of predicted demand, baseline supply, and candidate action condition supply in this invention.

[0013] Figure 5 This is a closed-loop diagram illustrating the feedback update of mature event records in this invention. Detailed Implementation

[0014] The invention is described below with reference to the accompanying drawings. Unless otherwise stated, scheduling proceeds in discrete time steps, and load demand and supply are normalized to the total nominal service capacity corresponding to the maximum number of replicas.

[0015] Example 1: Complete Expansion / Shrinkage Control Process

[0016] (a) Mature events and benchmark supply trajectory

[0017] The execution environment establishes mature events for replicas or batches to be launched, recording the event identifier, number of replicas, estimated serviceability time, and event status. Replicas with the same estimated time can be merged and recorded together; those with different estimated times are recorded separately. The set is empty when there are no replicas to be launched.

[0018]

[0019] The third field is the event status. The i-th future time step will only accumulate events whose estimated serviceability time is no later than that time step:

[0020]

[0021] Where I(·) is the indicator function, which takes the value 1 when the condition is true, and 0 otherwise.

[0022] Let the current number of serviceable replicas and the maximum number of replicas be denoted as follows: The load forecasting module outputs future demand forecasts using the same normalized scale as the supply. The baseline supply and baseline time-by-time capacity gap are:

[0023]

[0024]

[0025] Unused copies are not included in the supply until they are expected to mature; events whose expected maturity time exceeds the forecast window are also not included in the supply within the current window.

[0026] (ii) Hard-constrained action set and action condition supply trajectory

[0027] The control device generates a set of hard-constraint actions based on replica upper and lower bounds, resource quotas, and scaling-down cooling status. Resource quotas can be provided by ResourceQuota, node resources, Pod resource requests, or execution environment interfaces.

[0028] For each candidate action 'a', an action activation event is established: Expansion increases supply when a new replica is Ready; Cancellation of a replica awaiting activation deducts future supply from the later of the cancellation time and the originally expected serviceable time; Termination of a serviceable replica reduces supply when traffic is removed and service is stopped; The action's corresponding empty set is maintained. Each non-empty event records the change in signed replicas and the activation time.

[0029] When scaling down, prioritize canceling replicas with later expected service times; if the number is insufficient, then remove traffic from available replicas and stop service after connections are exhausted. In a fixed cold start simulation, this order corresponds to prioritizing the cancellation of later created tasks.

[0030]

[0031]

[0032] The hard-constraint action set guarantees that the planned replica count meets the upper and lower bounds, and the action condition supply is no longer truncated upwards by the minimum replica count. The post-action capacity gap uses the same time index and comparison relationship as the baseline gap.

[0033]

[0034]

[0035] Time weights are non-negative and sum to 1; equal weighting or increased weighting of recent gaps can be used. After normalizing capacity risk, resource consumption, and action switching costs, the comprehensive evaluation value is calculated:

[0036]

[0037]

[0038] All reference values ​​are positive. Resource usage is calculated based on the resource request or equivalent number of replicas after the action. Action switching cost is calculated based on the difference between the candidate action and the actual action in the previous cycle. If there is no feasible non-holding action, a holding action is output.

[0039] When using a learning-based strategy, PPO can output action preferences or probabilities; the final action is still determined within the set of hard-constrained actions based on the action condition supply and the post-action gap, and PPO is not a necessary algorithm.

[0040] Optionally, an action mask is generated based on the set of hard-constraint actions. The policy-sampled actions and the actual executed actions are recorded separately; if they are inconsistent, the mature events, supply, and next-cycle state are updated with the actual actions.

[0041] (III) Execution feedback update of mature events

[0042] Feedback is processed based on event identifiers: When a replica is Ready, the number of mature events is reduced and the number of serviceable replicas is increased according to the actual number; when Ready is delayed, the estimated serviceability time is updated; when startup fails or is canceled, the corresponding event is reduced or deleted; and a new event is retried to create a replica.

[0043] When a serviceable replica completes traffic removal and stops service, the number of serviceable replicas is reduced according to the actual number and time; replicas are still included in the supply before cessation. When performing environment pruning or rejection actions, the supply is updated with the actual actions and actual effective events, and actions that have not yet been performed are not used.

[0044] Example 2: Numerical Calculation Example of a Complete Control Method

[0045] Assume the maximum number of replicas is 10 and the current number of serviceable replicas is 4. Two maturity events contain 2 and 1 replicas respectively, maturing in the 1st and 3rd time steps, with a cumulative number of matured replicas of {2, 2, 3}; the demand forecast is {55, 70, 80}.

[0046]

[0047]

[0048] When expansion +2 takes effect in the third time step, the supply is {60, 60, 90}, the gap is {0, 10, 0}, and the equal-weighted risk is approximately 3.33; when reduction -1 takes effect in the first time step, the supply is {50, 50, 60}, the gap is {5, 20, 20}, and the risk is 15.

[0049] Let the action set be {−1, 0, +2}, the actual action in the previous cycle be 0, the three weights be 0.8, 0.1, and 0.1, and the reference values ​​be 20, 10, and 2. Then the comprehensive evaluation value is:

[0050]

[0051]

[0052]

[0053] Therefore, the +2 action with the lowest overall evaluation value is selected.

[0054] If all pending replicas are included in advance, the baseline supply is {70, 70, 70} with an equal-weighted risk of approximately 3.33; when calculated based on the actual maturity timeline, the supply is {60, 60, 70} with a risk of approximately 6.67, indicating that aggregated calculations will include capacity in advance.

[0055] Example 3: Basic Implementation of Existing Simulations

[0056] This implementation corresponds to a completed fixed three-cycle cold start simulation, with the total number of replicas to be started and the fastest remaining maturity time representing the status in transit; the results are not used to prove the performance of the event-level enhancement scheme.

[0057] The simulation uses upper and lower bound clipping and scaling down cooling of the copy after the action output, but does not use a mask before the action selection.

[0058] Let the scheduling period be ΔT, the fixed cold start delay be τ, and the multi-step prediction window length K and the number of prediction steps H satisfy:

[0059]

[0060] The short-term forecast risks, planned number of replicas, planned supply ratio, and basic capacity gap are as follows:

[0061]

[0062]

[0063]

[0064]

[0065] The input to the PPO policy network consists of the load, active replicas, aggregated replicas to be started, prediction results, and cooling state in the basic simulation environment. Its state vector can be represented as:

[0066]

[0067] in, , , and These are the single-instance load pressure, the fastest maturity time remaining, the remaining cooldown time, and the cooldown window length, respectively. The actual actions based on the execution environment feedback are used for status updates and statistics.

[0068] The simulation employs N-HiTS prediction and PPO discrete actions, with the execution environment adjusted for upper and lower bounds and cooling. Both models are interchangeable and are not essential features of claim 1.

[0069] Existing simulation data and results

[0070] The simulation used six container processor utilization sequences from Alibaba cluster-trace-v2018, with a resampling time of 1 minute; data from 8 consecutive days were used sequentially for prediction training and validation, PPO training, checkpoint selection, and testing on day 8.

[0071] Compared with HPA-70, predictive HPA-70, non-predictive PPO and this embodiment, all methods use the same test sequence, upper and lower bounds and cold start settings.

[0072] Day 8 has a total of 1440 time steps; SLO default, severe overload, and service failure risks are statistically analyzed separately. >70、 >80 and ≥110 time steps, time steps where the actual number of actions is not 0 according to the action count.

[0073] Table 1. Test results of the existing basic simulation on day 8.

[0074] HPA-70 4.477 122.500 13.500 0.833 34.500 Predictive HPA-70 4.796 41.833 7.500 0.500 31.167 Unpredictable PPO 4.577 76.667 11.833 0.500 54.833 This implementation method 5.118 32.556 3.556 0.000 23.056

[0075] This implementation reduces SLO defaults, severe overload, and number of actions, without any risk of service failure; the results only correspond to the basic simulation implementation.

[0076] Example 4: Systems, electronic devices, and computer program products

[0077] Figure 2 The system shown can be deployed on a container orchestration control plane, a standalone controller, or a simulation platform. Modules can be deployed centrally or distributed, and the system updates its status based on execution feedback, without being limited to any particular execution environment.

[0078] When an electronic device executes a computer program, it completes status acquisition, load prediction, supply construction, action evaluation, output and feedback updates; the program may be stored on a non-transitory computer-readable storage medium or provided as a computer program product.

Claims

1. A method for scaling up and down microservices based on maturity timing and action condition provisioning, characterized in that, The scaling control device executes the process according to a preset scheduling cycle, including: acquiring the historical load demand sequence, current load demand, current serviceable replica status, set of maturity event records for replicas to be started, replica quantity constraints, resource quotas, and scaling-down constraint status of the microservice; wherein each maturity event record for a replica to be started includes at least an event identifier, replica quantity, and estimated time to enter the serviceable state; based on the historical load demand sequence and current load demand, obtaining the predicted load demand value for each future time step within the prediction window; based on the set of maturity event records for replicas to be started, calculating the cumulative number of replicas to be started that have entered the serviceable state up to each future time step, and forming a time-step baseline supply trajectory together with the currently serviceable replicas; comparing the predicted load demand value for each future time step with the baseline supply at the same time step to obtain the baseline time-step capacity gap; and forming hard constraints based on the replica quantity constraints, resource quotas, and scaling-down constraint status. Action set; for each candidate replica change action in the hard constraint action set, an action activation event set is formed based on the action type, replica change amount, and capability activation time of the candidate replica change action. The baseline supply trajectory is corrected using the action activation event set to obtain the action condition supply trajectory. The load demand forecast value of each future time step is compared with the action condition supply at the same time step to obtain the time-by-time capacity gap after the action. Based on the time-by-time capacity gap after the action, resource consumption, and action switching cost, the final replica change action is determined from the hard constraint action set. The final replica change action is sent to the scaling execution environment and the actual execution action is received. When replica lifecycle events exist, the corresponding replica lifecycle event feedback is received. Based on the actual execution action and the received replica lifecycle event feedback, the set of mature event records for replicas to be started and the baseline supply trajectory for the next scheduling cycle are updated.

2. The method according to claim 1, characterized in that, Let the scheduling period, the maximum effective duration of the prediction window coverage, the prediction window length, and the number of prediction steps be ΔT, respectively. K and H; Not less than the maximum value among the remaining maturity time of the replica to be started, the maturity time of candidate expansion actions, and the service stoppage time of candidate shrinkage actions, satisfying: The prediction window includes the first to the Kth future time steps.

3. The method according to claim 2, characterized in that, To calculate the baseline supply trajectory, the set of mature event records for replicas to be launched at time t is represented by the number of replicas and the expected time to enter a serviceable state, while retaining the correspondence between event identifiers. in, The number of mature event records, when the set is empty. ; and Let be the number of replicas for the j-th event and the estimated time to reach a serviceable state, respectively; let the current number of serviceable replicas and the maximum number of replicas be respectively... and Then, the cumulative number of mature replicas, the baseline supply, and the baseline time-by-time capacity gap at the i-th time step are: Where I(·) is the indicator function, and the future load demand forecast and the baseline supply use the same normalization scale.

4. The method according to claim 3, characterized in that, The set of hard constraint actions includes at least hold actions, and filters out actions from the preset action set that exceed the upper and lower bounds of the planned replica count, exceed the available quota for resource requests, or do not meet the scaling-down cooling constraints; the resource quota is provided by at least one of ResourceQuota, node schedulable resources, Pod resource requests, or scaling-down execution environment interfaces.

5. The method according to claim 4, characterized in that, For each candidate replica change action 'a', a set of action activation events is established, where each action activation event includes the signed replica change amount and the action activation time; the cumulative action capability formation amount at the i-th time step is: in, The total number of events in which the action of candidate action a takes effect. and The first The signed replica change and action activation time are for each action's effective event. For expansion actions, the signed replica change is positive, and the action activation time is the estimated time when the newly added replica will enter a serviceable state. When canceling a replica to be started, the signed replica change is a negative value representing the number of canceled replicas, and the action activation time is the later of the cancellation activation time and the originally estimated time to enter a serviceable state. When stopping a currently serviceable replica, the signed replica change is negative, and the action activation time is the estimated time of service stoppage. Maintaining an empty action's effective event set results in a cumulative action capacity formation of 0. The action condition supply is: The set of hard-constraint actions ensures that the planned number of replicas after the action is implemented is between the minimum and maximum number of replicas, and the action condition supply is calculated only based on the currently serviceable replicas, the replicas to be started in sequence, and the amount of action capability formed.

6. The method according to claim 5, characterized in that, The time-by-time capacity gap and time-weighted capacity risk following the action 'a' corresponding to the candidate replica change are: By normalizing the time-weighted capacity risk, resource consumption, and action switching cost, a comprehensive evaluation value is obtained: Among these, time weights are non-negative and sum to 1, evaluation weights are non-negative, and reference values ​​are positive. The action executed in the previous cycle is used; if the actual action executed in the previous cycle cannot be obtained, the final action of the previous cycle is used. The action with the lowest overall evaluation value is selected; if the evaluation values ​​are the same, the action with the smaller magnitude is selected.

7. The method according to claim 1, characterized in that, Update mature event logs based on event identifiers: When a replica enters a serviceable state, reduce the corresponding event and increase the number of serviceable replicas according to the actual number; when startup is delayed, update the estimated serviceable time according to the actual effective time; when startup fails or is canceled, reduce or delete the corresponding event according to the actual number. When a serviceable replica stops serving, the number of serviceable replicas is reduced; when the actual action is inconsistent with the final action, the mature event, the status of serviceable replicas, and the baseline supply trajectory for the next cycle are updated with the actual action, the number affected, and the actual effective time.

8. A microservice scaling system that provides mature timing and action conditions, characterized in that, include: The status and maturity event receiving module is used to obtain load demand, serviceable replica status, set of maturity event records for replicas to be started, and scaling constraints; the multi-step load forecasting module is used to obtain the load demand forecast value for each future time step within the forecast window; the maturity supply and capacity gap module is used to form a time-step benchmark supply trajectory and calculate the benchmark time-step capacity gap. The hard constraint action formation module is used to form a set of hard constraint actions based on replica quantity constraints, resource quotas, and scaling-down constraints. The action condition supply and comprehensive evaluation module is used to form the action condition supply trajectory for each candidate replica change action, calculate the capacity gap at each time step after the action, and determine the final replica change action based on capacity risk, resource consumption, and action switching cost. The execution interface and feedback update module is used to send the final replica change action and receive the actual executed action. When a replica lifecycle event exists, it receives feedback containing the event identifier, the number of affected replicas, the actual effective time, and the event result. It also updates the mature event record set and baseline supply trajectory for the next scheduling cycle based on the actual executed action and the received feedback.

9. An electronic device, characterized in that, The device includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform 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 performs the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it performs the method according to any one of claims 1 to 7.

Images