Cluster resource self-adaptive scaling method and system based on traffic mutation perception

Abstract

The application discloses a cluster resource self-adaptive expansion and contraction method and system based on flow mutation awareness, and relates to the technical field of cloud computing. The method comprises the following steps: S1, collecting cluster expansion and contraction awareness data in real time, performing data preprocessing, and extracting flow change characteristics, response change characteristics and queuing change characteristics; S2, identifying a flow mutation state, analyzing historical flow mutation records or growth extrapolation results, evaluating a flow peak value predicted arrival time and a predicted peak value request amount, and performing boundary checking; S3, performing time limit evaluation on a newly added instance available preparation process, and generating an expansion opportunity marker; S4, judging expansion instance demand, generating an instance expansion instruction according to the expansion opportunity marker and the expansion instance demand, and adding the newly added instance to a traffic forwarding link corresponding to a target service. The method solves the problem that in a flow surge scenario, the actual available time of expanded resources does not match the flow peak value arrival time, resulting in expansion lag, service overload or resource idle waste.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, specifically to a method and system for adaptive scaling of cluster resources based on traffic mutation awareness. Background Technology

[0002] With the development of cloud computing, microservice architecture, and container orchestration technologies, internet business systems are increasingly adopting multi-instance collaborative operation to handle high-concurrency access requests. Service request volumes in business scenarios such as e-commerce transactions, online live streaming, intelligent recommendations, mobile payments, and artificial intelligence inference exhibit dynamic changes. Service instances achieve unified scheduling and resource management through load balancing and container orchestration platforms. Simultaneously, operational data such as service interface response status, request queuing status, instance health status, and instance startup process status are continuously generated, providing a data foundation for cluster operational status analysis, resource scheduling control, and service operation assurance, and driving the continuous development of other software such as basic network and information security software.

[0003] For example, Chinese patent CN115145690B discloses a cluster resource scaling method, apparatus, and container cluster management system, applied in the field of autonomous driving technology. The method includes: responding to an event detected by an interface service component updating the resource specification information of a target container group, and determining that the target container group has an in-situ update identifier; and deleting the in-situ update identifier when the target container group meets the in-situ update conditions, so that the node proxy component on the working node where the target container group resides, responding to the detected event and determining that the target container group no longer has an in-situ update identifier, applies the updated resource specification information of the target container group. This method enables vertical scaling of cluster resources through collaboration between the scheduling component, interface service component, and node proxy component, without deleting currently running container groups, avoiding service interruptions, and ensuring service quality even in scenarios with rapidly changing business loads, demonstrating high flexibility in container group management.

[0004] For example, Chinese patent CN116107687A discloses a method, apparatus, and system for automatic scaling of cluster resources. The method includes: pre-acquiring a scaling group created and configured from the cloud layer, setting corresponding scaling parameters internally, receiving request instructions from cluster resources in real time, scanning the resource utilization of cluster resources based on the request instructions, determining whether to request the cloud to create or delete a cloud server based on the current resource utilization value, and finally notifying the terminal. Through this method, this application can automatically request the cloud to create a cloud server when business traffic is high, allowing the newly created cloud server to automatically join the local service cluster for expansion; conversely, when business traffic is low, it can automatically request the cloud to delete a cloud server for reduction, thereby improving operational efficiency, saving resources, and achieving flexible cost control.

[0005] However, in scenarios such as e-commerce flash sales, online education live streaming, and centralized login for enterprise SaaS, traffic surges often occur within tens of seconds. The process of adding a new instance to a cluster, from triggering scaling to actually handling traffic, involves image pulling, container startup, service registration, health checks, and connection warm-up. Traditional scaling systems typically trigger scaling only after CPU, memory, or QPS have exceeded thresholds. This results in existing instances becoming overloaded before new instances are ready, leading to request queuing, interface timeouts, and service degradation. Conversely, excessive scaling in advance can cause resources to remain idle for extended periods. Therefore, it is necessary to address how to predict the actual availability of scaling resources and the arrival time of peak traffic in the early stages of traffic surges, thereby triggering scaling early and appropriately.

[0006] Therefore, in order to address the above problems, there is an urgent need for a cluster resource adaptive scaling method and system based on traffic mutation awareness. Summary of the Invention

[0007] Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a cluster resource adaptive scaling method and system based on traffic surge awareness, which solves the problem of mismatch between the actual available time of expanded resources and the arrival time of traffic peaks in traffic surge scenarios, resulting in delayed expansion, service overload, or wasted idle resources.

[0008] Technical solution To achieve the above objectives, the present invention provides the following technical solution: a cluster resource adaptive scaling method based on traffic mutation awareness, comprising the following steps: S1, real-time collection of cluster scaling awareness data, data preprocessing of the cluster scaling awareness data, and extraction of traffic change characteristics, response change characteristics, and queuing change characteristics; S2, identification of traffic mutation states based on traffic change characteristics, response change characteristics, and queuing change characteristics; when in a traffic mutation state, analysis of historical traffic mutation records or growth extrapolation results, assessment of the estimated arrival time of traffic peak and predicted peak request volume, and boundary verification of the predicted peak request volume; S3, combining cluster scaling awareness data and the estimated arrival time of traffic peak, performance evaluation of the availability preparation process for new instances, and generation of expansion timing markers based on the performance evaluation results; S4, determination of expansion instance requirements based on cluster scaling awareness data and predicted peak request volume, generation of instance expansion instructions based on the expansion timing markers and expansion instance requirements, and addition of new instances to the traffic forwarding link corresponding to the target service.

[0009] Furthermore, the specific process of real-time collection of cluster scaling awareness data, data preprocessing of cluster scaling awareness data, and extraction of traffic change characteristics, response change characteristics, and queuing change characteristics is as follows: Real-time collection of cluster scaling awareness data, including: service identifier, instance number, ingress request volume, service interface response time, request queue length, number of currently running instances, instance health status, image pull baseline time, container startup baseline time, service registration baseline time, health check pass baseline time, and service resource initialization baseline time; time alignment of the cluster scaling awareness data with a unified clock baseline, and resampling according to a fixed sampling period; filling in missing data using forward padding; marking data exceeding the business operation range as outliers and removing them; calculating the number of requests processed by each instance within the fixed sampling period to obtain the number of requests processed per instance per unit time; dividing the ingress request volume at the current sampling time by... The request volume ratio is obtained by summing the entry request volume at the previous sampling time with the smallest positive number. A sliding time window is constructed, and the standard deviation of the request volume ratio within the sliding time window is calculated to obtain the fluctuation value of the request volume ratio. The average response time of the service interface within the sliding time window is calculated to obtain the average request response time. The difference between the average request response time of the current window and the average request response time of the previous window is calculated and divided by the sum of the average request response time of the previous window with the smallest positive number to obtain the response time growth rate. The average request queue length within the sliding time window is calculated to obtain the average request queue length. The difference between the average request queue length of the current window and the average request queue length of the previous window is calculated and divided by the sum of the average request queue length of the previous window with the smallest positive number to obtain the queue length growth rate. The raw and preprocessed cluster scaling awareness data are associated with the corresponding service identifier, instance number, and sampling timestamp and written into the scaling monitoring database.

[0010] Furthermore, the specific process for identifying traffic mutation states based on traffic change characteristics, response change characteristics, and queuing change characteristics is as follows: Calculate the difference between the inbound request volume at the current sampling time and the inbound request volume at the previous sampling time, and divide it by the sampling period to obtain the request volume growth slope; calculate the difference between the request volume growth slope at the current sampling time and the request volume growth slope at the previous sampling time, and divide it by the sampling period to obtain the request volume growth acceleration; when K consecutive sampling times satisfy the conditions of increasing inbound request volume, request volume growth slope greater than the growth slope threshold, and response time growth rate greater than the response growth threshold or queue length growth rate greater than the queue growth threshold, the current cluster is determined to have entered the early stage of traffic mutation, and a traffic mutation marker is generated; combine the inbound request volume, request volume growth slope, request volume growth acceleration, response time growth rate, and queue length growth rate to construct a traffic state feature vector, and write the traffic state feature vector and the traffic mutation marker into the scaling monitoring database; the traffic state feature vector is used for subsequent historical mutation similarity matching to predict peak arrival time and peak request volume.

[0011] Furthermore, when in a state of traffic mutation, the specific process of analyzing historical traffic mutation records or growth extrapolation results to assess the expected arrival time of the traffic peak and predict the peak request volume is as follows: After generating a traffic mutation marker, historical traffic mutation records are read. When the number of historical traffic mutation records is greater than or equal to the minimum sample size threshold, the current traffic state feature vector and the historical traffic state feature vector corresponding to each historical traffic mutation record are obtained. The Euclidean distance between the current traffic state feature vector and the historical traffic state feature vector is calculated to obtain the state difference value. The first m historical traffic mutation records are selected from smallest to largest based on the state difference value. For each historical traffic mutation record, the traffic mutation marker generation time corresponding to the historical traffic mutation record is obtained as the mutation start time, the ingress request volume sequence, and the sampling timestamp corresponding to each ingress request volume. In the ingress request volume sequence after the mutation start time, the maximum value of the ingress request volume is selected as the historical peak. The system calculates the historical peak request volume and uses the sampling timestamp corresponding to the historical peak request volume as the historical peak arrival time. It then calculates the difference between the historical peak arrival time and the start time of the mutation to obtain the historical peak arrival duration. Based on the historical peak request volume in each historical traffic mutation record, it calculates the average to obtain the predicted peak request volume. Finally, it calculates the average of the historical peak arrival duration in each historical traffic mutation record and adds the current time to obtain the estimated arrival time of the traffic peak. When the number of historical traffic mutation records is less than the minimum sample size threshold, it constructs a second-order growth expression based on the current inbound request volume, the request volume growth slope, and the request volume growth acceleration. It substitutes the upper limit of the inbound request volume into the second-order growth expression and obtains the corresponding positive real-number time solution to obtain the estimated arrival time required for the current inbound request volume to grow to the upper limit of the inbound request volume. Finally, it adds the current time to the estimated arrival time to obtain the estimated arrival time of the traffic peak and uses the upper limit of the inbound request volume as the predicted peak request volume.

[0012] Furthermore, the specific process for boundary verification of the predicted peak request volume is as follows: when the predicted peak request volume is less than the current ingress request volume, the predicted peak request volume is corrected to the current ingress request volume; when the predicted peak request volume is greater than the upper limit of the ingress request volume, the predicted peak request volume is corrected to the upper limit of the ingress request volume.

[0013] Furthermore, combining cluster scaling awareness data and the estimated arrival time of traffic peaks, the specific process for evaluating the timeliness of the preparation process for the availability of new instances is as follows: After generating a traffic mutation marker, read the baseline time for image pull, container startup, service registration, health check pass, and service resource initialization for the current service; calculate the sum of the baseline time for image pull, container startup, service registration, health check pass, and service resource initialization, and add it to the current time to obtain the estimated availability time of the new instance; subtract the estimated availability time of the new instance from the estimated arrival time of the traffic peak to obtain the pre-peak availability time difference; divide the pre-peak availability time difference by the sum of the average request response time and the smallest positive number to obtain the time matching ratio; add one to the request volume month-on-month multiple and take the natural logarithm to obtain the request growth enhancement term; take the opposite of the request volume month-on-month multiple fluctuation value and perform natural exponential calculation to obtain the growth stabilization suppression term; multiply the time matching ratio, request growth enhancement term, and growth stabilization suppression term to obtain the scaling timing matching value.

[0014] Furthermore, the specific process of generating expansion timing markers based on the timeliness assessment results is as follows: when the expansion timing matching value is greater than the expansion early trigger threshold, it is determined that the currently added instance is expected to complete the availability preparation before the traffic peak arrives, and an early expansion marker is generated; when the expansion timing matching value is less than or equal to the expansion early trigger threshold, it is determined that the currently added instance is not expected to complete the availability preparation before the traffic peak arrives, and an emergency expansion marker is generated.

[0015] Furthermore, the specific process of determining the demand for scaling up instances by combining cluster scaling awareness data and predicted peak request volume is as follows: Calculate the median number of requests processed per unit time for each instance when its health status is normal, obtaining the stable processing capacity value for a single instance; multiply the number of running instances with normal current health status by the stable processing capacity value for a single instance to obtain the total processing capacity of the current instance; read the available time difference before the peak, compare the available time difference before the peak with zero and take the maximum value, divide the maximum value by the sum of the average request response time and the smallest positive number to obtain the discounted available time value before the peak; [The text then abruptly shifts to a different topic:] ...for the available time before the peak... The inverse of the converted value is used for natural exponentiation. The result of natural exponentiation is subtracted from one to obtain the pre-peak available conversion factor for new instances. The difference between the predicted peak request volume and the current instance's total processing capacity is calculated. The difference is compared with zero and the maximum value is taken to obtain the predicted capacity gap. The stable processing capacity of a single instance is multiplied by the pre-peak available conversion factor for new instances, and a very small positive number is added to obtain the effective capacity of a single instance. The predicted capacity gap is divided by the effective capacity of a single instance to obtain the base value of the expansion instance demand. The base value of the expansion instance demand is rounded up to obtain the expansion instance demand value.

[0016] Furthermore, the specific process of generating instance expansion instructions and adding new instances to the traffic forwarding link corresponding to the target service based on the expansion timing marker and expansion instance requirements is as follows: When an early expansion marker is generated, an early expansion instruction is generated according to the expansion instance requirement value, and expansion is executed using a gradual and smooth expansion method. The gradual and smooth expansion method involves creating new instances in stages according to a preset expansion batch ratio, and starting the next batch of new instances only after the previous batch of new instances has passed the health check; when an emergency expansion marker is generated, an emergency expansion instruction is generated according to the expansion instance requirement value, and expansion is executed using a dense batch expansion method. The intensive batch expansion method is as follows: compared to the gradual smooth expansion method, it increases the number of new instances in a single batch and shortens the waiting time between adjacent expansion batches; at the same time, it prioritizes selecting the instance template with the smallest sum of container startup time and health check pass time from the preset instance template set corresponding to the current service; expansion requests are issued to the container orchestration platform according to the advance expansion instructions and emergency expansion instructions. The expansion request includes the target service identifier, the required value of expansion instances, the expansion method, and the expansion execution timestamp; the container orchestration platform creates new instances according to the expansion requests and adds the new instances to the traffic forwarding link corresponding to the target service.

[0017] The second aspect of this invention provides a cluster resource adaptive scaling system based on traffic mutation awareness, comprising: a data acquisition and processing module for real-time acquisition of cluster scaling awareness data, preprocessing the cluster scaling awareness data, and extracting traffic change features, response change features, and queuing change features; a traffic mutation identification module for identifying traffic mutation states based on traffic change features, response change features, and queuing change features, and when in a traffic mutation state, analyzing historical traffic mutation records or growth extrapolation results, evaluating the expected arrival time of traffic peaks and the predicted peak request volume, and performing boundary verification on the predicted peak request volume; an availability time prediction module for combining cluster scaling awareness data and the expected arrival time of traffic peaks to perform a timeliness assessment of the availability preparation process for new instances, and generating expansion timing markers based on the timeliness assessment results; and a scaling decision execution module for determining the expansion instance requirements based on cluster scaling awareness data and the predicted peak request volume, generating instance expansion instructions based on the expansion timing markers and expansion instance requirements, and adding the new instances to the traffic forwarding link corresponding to the target service.

[0018] Beneficial effects The present invention has the following beneficial effects: (1) This invention, by collecting the number of inbound requests, the response time of the service interface and the length of the request queue, and extracting the traffic change characteristics, response change characteristics and queue change characteristics, can identify the early state of traffic mutation before the CPU or memory reaches the overload threshold, thereby improving the advance triggering of capacity expansion.

[0019] (2) This invention, by combining historical traffic mutation records or second-order growth extrapolation results to evaluate the expected arrival time of traffic peak and predict the peak request volume, can predict the future traffic peak development trend in advance, provide a basis for subsequent expansion timing and expansion quantity determination, and reduce expansion lag.

[0020] (3) This invention, by combining the baseline time of image retrieval, container startup, service registration, health check and service resource initialization of the new instance, evaluates the expected availability time of the new instance and matches it with the expected arrival time of the traffic peak, so as to determine whether the new instance can be put into use before the peak arrives, thereby improving the accuracy of the expansion decision.

[0021] (4) The present invention can balance expansion speed and expansion stability in traffic mutation scenarios by performing gradual smooth expansion or dense batch expansion according to the expansion timing mark and expansion instance demand value, reducing request queuing, interface timeout and service degradation, and reducing resource idleness caused by excessive expansion.

[0022] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0023] Figure 1 The flowchart shows a cluster resource adaptive scaling method based on traffic mutation awareness. Figure 2 This is a diagram of the cluster resource adaptive scaling system architecture based on traffic mutation awareness. Figure 3 A diagram showing the relationship between instance expansion requirements and carrying capacity under a traffic surge event; Figure 4 This is a schematic diagram illustrating the coordination between peak traffic arrival and advance capacity expansion. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. As those skilled in the art will understand, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figures 1-4 This invention provides a technical solution: a cluster resource adaptive scaling method based on traffic mutation awareness, such as... Figure 1As shown, the process includes the following steps: S1, real-time collection of cluster scaling awareness data, data preprocessing of the cluster scaling awareness data, and extraction of traffic change characteristics, response change characteristics, and queuing change characteristics; S2, identification of traffic mutation states based on traffic change characteristics, response change characteristics, and queuing change characteristics. When in a traffic mutation state, analysis of historical traffic mutation records or growth extrapolation results is performed to assess the estimated arrival time of the traffic peak and the predicted peak request volume, and boundary verification is performed on the predicted peak request volume; S3, combining the cluster scaling awareness data and the estimated arrival time of the traffic peak, a timeliness assessment of the preparation process for the availability of new instances is conducted, and a scaling up timing marker is generated based on the timeliness assessment results; S4, combining the cluster scaling awareness data and the predicted peak request volume to determine the demand for scaling up instances, generating instance scaling up instructions based on the scaling up timing marker and the demand for scaling up instances, and adding the new instances to the traffic forwarding link corresponding to the target service.

[0026] Specifically, the process of real-time collection of cluster scaling awareness data, data preprocessing of the cluster scaling awareness data, and extraction of traffic change characteristics, response change characteristics, and queuing change characteristics is as follows: Real-time collection of cluster scaling awareness data includes: service identifier, instance number, ingress request volume, service interface response time, request queue length, number of currently running instances, instance health status, image pull baseline time, container startup baseline time, service registration baseline time, health check pass baseline time, and service resource initialization baseline time. Among these, the service identifier is obtained from the service name recorded in the service registry and is used to distinguish the target service that needs to be detected for traffic mutations and scaled. The instance number is obtained from the Pod number assigned by the container orchestration platform and is used to distinguish the specific running instance under the target service. The ingress request volume is obtained from the gateway access log statistics. The service interface response time is calculated from the request reception time and response return time of the gateway access log. The request queue length is obtained from the gateway connection queue and is used to indicate the backlog of pending requests. The number of currently running instances and the instance health status are obtained from the instance status of the container orchestration platform, the instance registration status of the service discovery component, and the results returned by the health check interface. The baseline time for image retrieval is calculated from the image retrieval start time and image retrieval completion time in the container orchestration platform event log; the baseline time for container startup is calculated from the container creation time and instance entry into running state time recorded by the container orchestration platform; the baseline time for service registration is calculated from the service startup completion time and the registration success time recorded by the service registry center; the baseline time for passing health checks is calculated from the health check start time and the first health check pass time; the baseline time for service resource initialization is calculated from the start time and completion time of database connection pool, cache connection, message queue connection, and business dependency resource initialization in the service initialization log; the above baseline times are preferably obtained by pre-collecting data from target service test deployment, canary release, or existing instance startup event records. If multiple samples exist, it is preferable to calculate the median of the image retrieval time, container startup time, service registration time, health check pass time, and service resource initialization time to obtain the corresponding baseline time, and store it in association with the service identifier. The cluster scaling awareness data is time-aligned using a unified clock reference and resampled according to a fixed sampling period. Missing data is filled using forward padding, and data outside the scope of business operations is marked as outliers and removed. The unified clock reference is used to ensure that gateway logs, service access logs, container orchestration platform events, health check records, and service initialization logs are on the same timeline.A fixed sampling period is used to standardize the statistical metrics for ingress request volume, service interface response time, request queue length, and instance processing request volume. The fixed sampling period is determined based on the request mutation rate of the target service, the monitoring system's collection frequency, and the container orchestration platform's status refresh frequency. The preferred fixed sampling period is 1 to 5 seconds. When the target service experiences second-level traffic mutations, such as e-commerce flash sales or concentrated logins during online education live streams, a fixed sampling period of 1 second is preferred. When the traffic changes of the target service are relatively gradual, a fixed sampling period of 5 seconds is preferred. These settings ensure timely detection of traffic changes while avoiding excessive pressure on monitoring data processing due to an excessively short sampling period. For short-term missing data, data from the previous valid sampling period is used to fill in the gaps, maintaining the computability of continuous time-series data. Data exceeding the scope of business operations is marked as anomalies and removed to avoid obvious collection errors from being included in subsequent feature extraction. The scope of business operations is determined based on the value range of the corresponding monitoring indicators of the gateway monitoring component, container orchestration platform monitoring component, APM monitoring system, and message queue monitoring system. When collected data exceeds the maximum allowed value of the corresponding monitoring indicator, falls below the minimum allowed value, or exhibits abnormal values ​​exceeding the actual business operation scope, the corresponding data is marked as an anomaly and removed. For example, if the request queue length is less than zero, the service interface response time is less than zero, or the ingress request volume exceeds the maximum statistical range configured by the gateway, the corresponding data is determined to be outside the scope of business operations. The number of requests processed by each instance within a fixed sampling period is calculated to obtain the number of requests processed per instance per unit time. The number of requests processed per instance per unit time is associated with the instance number and is used to characterize the number of requests actually processed by the corresponding instance within a single fixed sampling period. The request volume ratio is obtained by dividing the current sampling time's inbound request volume by the sum of the previous sampling time's inbound request volume and the smallest positive number. A sliding time window is constructed, and the standard deviation of the request volume ratio within the sliding time window is calculated to obtain the request volume ratio fluctuation value. The average response time of the service interface within the sliding time window is calculated to obtain the average request response time. The difference between the current window's average request response time and the previous window's average request response time is calculated and divided by the sum of the previous window's average request response time and the smallest positive number to obtain the response time growth rate. The average request queue length within the sliding time window is calculated to obtain the average request queue length. The difference between the current window's average request queue length and the previous window's average request queue length is calculated and divided by the sum of the previous window's average request queue length and the smallest positive number to obtain the queue length growth rate. The sliding time window slides periodically according to a fixed sampling period. The window length is determined based on the target service's traffic change rate, request statistical stability, and traffic mutation identification sensitivity. Preferably, the sliding time window length is set to 5 to 20 fixed sampling periods. The smallest positive number is used to avoid calculation errors caused by a denominator of zero. The unit of the smallest positive number is consistent with the unit of the corresponding denominator, and the preferred value is 0.001.The request volume month-over-month ratio characterizes the ratio of the inbound request volume at the current sampling time to the inbound request volume at the previous sampling time. The request volume month-over-month ratio fluctuation value characterizes the stability of the request growth process within a continuous sampling period. The average request response time characterizes the request processing time of the target service within the current window. The response time growth rate characterizes the increase in service interface processing time. The average request queue length characterizes the backlog of pending requests within the current window. The queue length growth rate characterizes the increase in the backlog of pending requests. The raw and preprocessed cluster scaling awareness data are associated with the corresponding service identifier, instance number, and sampling timestamp and written into the scaling monitoring database. The sampling timestamp marks the collection time of the corresponding data. The scaling monitoring database stores the raw collected data, preprocessing results, and extracted traffic change characteristics, response change characteristics, and queue change characteristics, providing a data foundation for subsequent traffic mutation trend identification, resource availability time prediction for expansion, and adaptive scaling decisions.

[0027] This implementation plan clarifies the source, meaning, and collection criteria of cluster scaling awareness data, and improves data continuity and accuracy through unified clock alignment, fixed sampling period resampling, missing data filling, and anomaly removal. At the same time, it extracts traffic, response, and queuing change characteristics based on inbound request volume, service interface response time, and request queue length, providing a reliable and quantifiable data foundation for subsequent traffic mutation identification, expansion resource availability time prediction, and adaptive scaling decisions.

[0028] Specifically, the process of identifying sudden changes in traffic flow based on traffic flow change characteristics, response change characteristics, and queuing change characteristics is as follows: Calculate the difference between the inbound request volume at the current sampling moment and the inbound request volume at the previous sampling moment, and divide this difference by the sampling period to obtain the request volume growth slope. Here, both the current and previous inbound request volumes are obtained after resampling according to a fixed sampling period. The request volume growth slope is used to characterize the rate of increase of the inbound request volume between adjacent sampling moments. Calculate the difference between the current and previous inbound request volume growth slopes, and divide this difference by the sampling period to obtain the request volume growth acceleration. Here, the request volume growth acceleration is used to characterize the degree of change in the rate of increase of the inbound request volume. When the request volume growth acceleration is positive, it indicates that the rate of increase of the inbound request volume is increasing. When K consecutive sampling times satisfy the following conditions: increasing inbound request volume, request volume growth rate greater than the growth rate threshold, and response time growth rate greater than the response growth threshold or queue length growth rate greater than the queue growth threshold, the current cluster is determined to have entered the early stage of traffic mutation, and a traffic mutation marker is generated. Here, K is the number of consecutive sampling times for determination, preferably set to 3 to 5. The growth rate threshold is determined based on the historical median and fluctuation range of the target service's request volume growth rate in the non-mutation state; the response growth threshold is determined based on the historical median and fluctuation range of the target service's response time growth rate in the non-mutation state; and the queue growth threshold is determined based on the historical median and fluctuation range of the target service's queue length growth rate in the non-mutation state. Increasing inbound request volume is used to confirm a continuous increase in traffic volume; a request volume growth rate greater than the growth rate threshold is used to confirm that the traffic increase rate exceeds the normal fluctuation range; and a response time growth rate greater than the response growth threshold or a queue length growth rate greater than the queue growth threshold is used to confirm that the traffic increase has already affected the target service's processing or request backlog state. A traffic status feature vector is constructed by combining inbound request volume, request volume growth slope, request volume growth acceleration, response time growth rate, and queue length growth rate. This feature vector is arranged in a fixed order to maintain consistency in feature dimensions between the current traffic status and historical traffic mutation records. The traffic status feature vector and traffic mutation markers are written into the scaling monitoring database. The traffic status feature vector is then used for subsequent historical mutation similarity matching to predict peak arrival time and peak request volume. This setup avoids triggering mutation judgment solely based on a single request volume threshold, enabling traffic mutation identification to consider traffic scale, growth rate, growth acceleration trend, and changes in service response and queuing, thus improving the accuracy and feasibility of early traffic mutation identification.

[0029] This implementation plan can further combine the request volume growth slope, request volume growth acceleration, response time growth rate, and queue length growth rate to identify the early state of traffic mutation based on the continuous increase in inbound request volume, avoiding misjudgment caused by relying solely on a single request volume threshold; at the same time, by constructing a traffic state feature vector, it provides a unified and quantifiable feature basis for subsequent historical mutation similarity matching and traffic peak prediction, thereby improving the accuracy and feasibility of traffic mutation identification.

[0030] Specifically, when in a traffic mutation state, the process of analyzing historical traffic mutation records or growth extrapolation results to assess the estimated arrival time of the traffic peak and predict the peak request volume is as follows: After generating a traffic mutation marker, historical traffic mutation records are read. These records are records of completed traffic mutation processes under the same service identifier, including at least the historical traffic mutation marker generation time, historical ingress request volume sequence, historical traffic state feature vector, historical sampling timestamp, historical peak request volume, and historical peak arrival time. Historical traffic mutation records can be obtained by replaying historical sampling data stored in the scaling monitoring database. When the number of historical traffic mutation records is greater than or equal to the minimum sample size threshold, the current traffic state feature vector and the historical traffic state feature vectors corresponding to each historical traffic mutation record are obtained. The Euclidean distance between the current traffic state feature vector and the historical traffic state feature vectors is calculated to obtain the state difference value. Preferably, the traffic state feature vector is normalized before calculating the Euclidean distance. The first m historical traffic mutation records are selected based on the state difference value from smallest to largest; where m is the number of reference samples, and m is less than or equal to the number of historical traffic mutation records, preferably 3 to 5 records, to avoid the influence of accidental fluctuations in a single historical record on the prediction results. For each historical traffic mutation record, the generation time of the traffic mutation marker corresponding to the historical traffic mutation record is obtained as the mutation start time, the ingress request volume sequence, and the sampling timestamp corresponding to each ingress request volume. In the ingress request volume sequence after the mutation start time, the maximum ingress request volume is selected as the historical peak request volume, and the sampling timestamp corresponding to the historical peak request volume is used as the historical peak arrival time. The difference between the historical peak arrival time and the mutation start time is calculated to obtain the historical peak arrival duration. Based on the historical peak request volume in each historical traffic mutation record, the average value is calculated to obtain the predicted peak request volume. The average value of the historical peak arrival duration in each historical traffic mutation record is calculated and added to the current time to obtain the estimated arrival time of the traffic peak. When the number of historical traffic mutation records is less than the minimum sample size threshold, a second-order growth expression is constructed based on the current ingress request volume, the request volume growth slope, and the request volume growth acceleration. The second-order growth expression is: ;in, This indicates the number of entry requests at a future time. This indicates the current number of inbound requests. This indicates the slope of the request volume growth. This indicates an acceleration in the growth of request volume. This represents the future time calculated from the current time. The upper limit of inbound requests is substituted into the second-order growth expression as the inbound request volume at the future time. The upper limit of inbound requests is the maximum allowed access request volume per unit time set in the gateway rate limiting configuration corresponding to the target service. It is preferably obtained by reading the gateway configuration file, gateway rate limiting rules, or gateway dynamic rate limiting parameters, and is used to constrain the second-order growth extrapolation result to avoid the predicted peak request volume exceeding the system's allowed access capacity at the inbound side. The corresponding positive real-number time solution is obtained to get the estimated arrival time required for the current inbound request volume to grow to the upper limit of inbound requests. Specifically, the upper limit of inbound requests is used as... Substituting into the second-order growth expression, a quadratic equation is formed with respect to the future time t. A real solution greater than zero is selected as the estimated arrival time. When two positive real solutions exist, the smaller one is chosen as the estimated arrival time to characterize the earliest time when the inbound request volume reaches its upper limit. The current time is added to the estimated arrival time to obtain the estimated arrival time of the peak traffic volume. The upper limit of the inbound request volume is then used as the predicted peak request volume.

[0031] This implementation plan can predict peak request volume and peak arrival time based on similar historical traffic mutation records when there are sufficient historical samples. When there are insufficient historical samples, it can perform second-order growth extrapolation based on the current inbound request volume, request volume growth slope and request volume growth acceleration, and combine the prediction results with the upper limit constraint of inbound request volume, thereby improving the feasibility and boundary rationality of traffic peak prediction, and providing a reliable basis for subsequent assessment of the availability time of expansion resources and judgment of expansion instance requirements.

[0032] Specifically, the boundary verification process for the predicted peak request volume is as follows: When the predicted peak request volume is less than the current inbound request volume, the predicted peak request volume is corrected to the current inbound request volume. Here, the current inbound request volume is the actual number of requests entering the target service at the current sampling time. This correction is used to avoid the predicted peak request volume being lower than the currently occurring inbound request volume, thus minimizing subsequent capacity gaps. When the predicted peak request volume is greater than the upper limit of the inbound request volume, the predicted peak request volume is corrected to the upper limit of the inbound request volume. Here, the upper limit of the inbound request volume is the maximum allowed access request volume per unit time set in the gateway rate limiting configuration corresponding to the target service. This correction is used to avoid the predicted peak request volume exceeding the system's inbound side's allowed access capacity, thus excessively amplifying the demand for expansion instances. The predicted peak request volume after boundary verification serves as input data for subsequent expansion instance demand judgment.

[0033] This implementation plan can limit the predicted peak request volume to between the current actual ingress request volume and the upper limit of the ingress request volume, avoiding the underestimation of expansion demand due to an excessively low peak prediction result, and also avoiding the excessive amplification of expansion demand due to the prediction result exceeding the access capacity of the ingress side, thereby improving the accuracy and stability of subsequent expansion instance demand judgment.

[0034] Specifically, the timeliness assessment process for the preparation of new instance availability, combining cluster scaling awareness data and the estimated arrival time of traffic peaks, is as follows: After a traffic mutation marker is generated, the baseline time for image pull, container startup, service registration, health check completion, and service resource initialization for the current service are read. Here, the current service is the target service for which the traffic mutation marker was generated. The baseline times for image pull, container startup, service registration, health check completion, and service resource initialization are all stored associated with their corresponding service identifiers, representing the baseline times for each stage a new instance needs to go through from creation to having the ability to access business traffic. The sum of the baseline times for image pull, container startup, service registration, health check completion, and service resource initialization is calculated and added to the current time to obtain the estimated availability time of the new instance. The estimated availability time of the new instance represents the time point at which the new instance is expected to begin receiving business requests after the current scaling is triggered. The estimated arrival time of the peak traffic is subtracted from the estimated availability time of the new instance to obtain the pre-peak availability time difference. This pre-peak availability time difference represents the remaining time that the new instance can be deployed before the peak traffic arrives. When the pre-peak availability time difference is greater than zero, it indicates that the new instance is expected to be ready for availability before the peak traffic arrives; when the pre-peak availability time difference is less than or equal to zero, it indicates that the new instance is not expected to be ready for availability before the peak traffic arrives. The pre-peak availability time difference is divided by the sum of the average request response time and the smallest positive number to obtain the time matching ratio. The average request response time is used to normalize the pre-peak availability time difference on a time scale, so that the time matching ratio represents the degree of matching between the availability time of the new instance and the current request processing rhythm. The time matching ratio is a dimensionless ratio. The request growth enhancement term is obtained by adding one to the request volume ratio and taking its natural logarithm. This term enhances the sensitivity of scaling up in scenarios with rapid request volume growth and is a dimensionless value. The growth stabilization suppression term is obtained by taking the negative of the request growth rate fluctuation value and then performing a natural exponential operation. This term reduces the matching degree of expansion timing in scenarios with large fluctuations in request growth. The more stable the request growth process, the closer the growth stabilization suppression term is to 1; the more volatile the request growth process, the closer it is to 0. The growth stabilization suppression term is dimensionless. The expansion timing matching value is obtained by multiplying the time matching ratio, the request growth enhancement term, and the growth stabilization suppression term. This value comprehensively characterizes the matching degree between the expected availability time of the new instance and the expected arrival time of the traffic peak, while also reflecting the current traffic growth intensity and stability. Since the time matching ratio, the request growth enhancement term, and the growth stabilization suppression term are all dimensionless, the expansion timing matching value is also dimensionless.The reason the expansion timing matching value is designed by multiplying the time matching ratio, request growth enhancement term, and growth stability suppression term is that whether a new instance can effectively participate in traffic carrying depends not only on whether the new instance can complete its availability preparation before the traffic peak arrives, but also on the intensity of the current traffic growth and the stability of the traffic growth process. Specifically, the time matching ratio characterizes the time margin relationship between the expected availability time of the new instance and the expected arrival time of the traffic peak. When the new instance can complete its availability preparation earlier, the time matching ratio is larger, indicating that the new instance has more time to participate in subsequent traffic carrying. The request growth enhancement term characterizes the growth intensity of the current inbound request volume. The faster the request volume grows, the larger the request growth enhancement term, thus increasing the expansion timing matching value and making the system more inclined to trigger expansion earlier. The growth stability suppression term characterizes the stability of the request growth process. The more stable the request growth process, the closer the growth stability suppression term is to 1, indicating that the current traffic change trend is continuous and predictable, thus increasing the expansion timing matching value. When the request growth process fluctuates greatly, the growth stability suppression term decreases, reducing the expansion timing matching value and making the system more inclined to adopt a faster emergency expansion method. The above design enables the expansion timing matching value to simultaneously reflect the comprehensive matching relationship between the availability time of new instances, the intensity of traffic growth, and the stability of traffic growth.

[0035] The specific formula for the expansion timing matching value is as follows: ; In the formula, This represents the matching value for the timing of capacity expansion. It is used to comprehensively evaluate the degree of matching between the availability time of new instances and the arrival time of traffic peaks, and to determine whether the current capacity expansion operation can cope with subsequent traffic peaks in a timely and effective manner, in conjunction with the intensity and stability of traffic growth. This indicates the estimated arrival time of the traffic peak, used to characterize the predicted time point when the traffic peak will occur; This indicates the estimated availability time of the new instance, representing the point in time when the new instance completes startup and is able to connect to business traffic; This represents the average request response time, used to characterize the current processing time level of business requests; This represents the month-on-month growth rate of request volume, used to characterize the intensity of current entry request volume growth. This represents the month-on-month fluctuation rate of requests, used to characterize the stability of the request growth process; This represents a very small positive number, used to avoid calculation errors caused by a zero denominator and to improve the numerical stability of the formula. The unit of the very small positive number is consistent with the unit of the corresponding denominator, and the preferred value is 0.001.

[0036] This implementation plan can predict the expected availability time of new instances based on the baseline time of each stage of new instance addition, and match it with the expected arrival time of traffic peaks. At the same time, it combines the intensity of request growth and the stability of request growth to form a matching value for expansion timing, thereby determining whether it is appropriate to expand in advance or in an emergency, improving the accuracy of expansion timing judgment, and reducing the risk of service overload caused by new instances not yet being available.

[0037] Specifically, the process of generating expansion timing markers based on timeliness assessment results is as follows: When the expansion timing matching value is greater than the expansion early trigger threshold, it is determined that the newly added instance is expected to be ready for availability before the traffic peak arrives, and an early expansion marker is generated. The expansion early trigger threshold is used to distinguish whether the newly added instance has sufficient conditions for early expansion. This threshold can be pre-set based on the average request response time of the target service, historical expansion completion time, and the business's tolerance for request latency. The early expansion marker indicates that a gradual, smooth expansion approach will be adopted to gradually supplement instance capacity before the traffic peak arrives. When the expansion timing matching value is less than or equal to the expansion early trigger threshold, it is determined that the newly added instance is not expected to be ready for availability before the traffic peak arrives, and an emergency expansion marker is generated. The emergency expansion marker indicates that the current expansion timing is too late, and a dense, batch-based expansion approach is needed to improve the efficiency of new instance creation. The expansion timing marker is not used to determine whether to expand independently, but rather to determine the specific expansion execution method when the expansion instance demand value is greater than zero.

[0038] In this implementation plan, the system can distinguish whether a new instance is available before the peak based on the expansion timing matching value, and generate an early expansion flag or an emergency expansion flag. This allows the system to select the corresponding expansion execution method after determining that there is an expansion need, thereby improving the matching between the expansion strategy and the arrival time of traffic peaks and reducing the risk of service overload caused by expansion lag.

[0039] Specifically, the process of determining the demand for scaling up instances by combining cluster scaling awareness data and predicted peak request volume is as follows: The median number of requests processed per unit time by each instance when its health status is normal is calculated to obtain the stable processing capacity value of a single instance. Here, "normal health status" is used to exclude instances that have failed health checks, are in the startup phase, or cannot receive business traffic. Using the median can reduce the impact of short-term fluctuations in a single instance on the stable processing capacity value of that single instance. The number of currently running instances with normal health status is multiplied by the stable processing capacity value of a single instance to obtain the total processing capacity of the current instance. The available time difference before the peak is read, compared with zero, and the maximum value is taken. This maximum value is divided by the sum of the average request response time and the smallest positive number to obtain the pre-peak available time discounted value. The pre-peak available time discounted value is a dimensionless value used to convert the available time margin of new instances before the traffic peak arrives into the number of effective processing cycles relative to the average request response time. The pre-peak availability discount value is inversely calculated and then subjected to natural exponentiation. Subtracting the result from one yields the pre-peak availability discount coefficient for new instances. This coefficient maps the pre-peak availability time difference to a contribution ratio between 0 and 1. A larger pre-peak availability time difference results in a discount coefficient closer to 1, indicating that the new instance can fully utilize its stable processing capacity before the traffic peak arrives. When the pre-peak availability time difference is zero, the discount coefficient is 0, indicating that the new instance's contribution to the capacity gap before the peak arrives is limited. This discount method avoids over-scaling or under-scaling caused by simply dividing the predicted peak request volume by the stable processing capacity of a single instance, ensuring that the instance expansion requirement considers the impact of the new instance's availability time on the actual capacity contribution. Calculate the difference between the predicted peak request volume and the current instance's total processing capacity. Compare this difference with zero and take the maximum value to obtain the predicted capacity gap. The predicted capacity gap represents the portion of the predicted peak request volume that exceeds the current instance's total processing capacity. When the predicted peak request volume does not exceed the current instance's total processing capacity, the predicted capacity gap is zero. Multiply the stable processing capacity of a single instance by the pre-peak available discount factor for the new instance, and add a very small positive number to obtain the effective capacity of a single instance. The effective capacity of a single instance represents the actual request processing capacity that the new instance can contribute before the traffic peak arrives; the very small positive number is used to avoid calculation errors caused by a zero denominator. Divide the predicted capacity gap by the effective capacity of a single instance to obtain the base value for expansion instance demand. Round up the base value to obtain the expansion instance demand value. The expansion instance demand value is an integer representing the number of new instances needed. Rounding up ensures that the number of new instances is not less than the minimum instance demand corresponding to the predicted capacity gap.Since the actual traffic pressure that a newly added instance can handle depends not only on the current lack of request processing capacity but also on the effective capacity that the new instance can actually provide before the traffic peak arrives, the requirement value for expanding the instance is designed using the ratio between the predicted capacity gap and the effective capacity of a single instance. Specifically, the predicted capacity gap represents the portion of the predicted peak request volume that exceeds the current instance's total processing capacity, reflecting the request processing capacity still lacking in the system during peak traffic scenarios; the single instance stable processing capacity value represents the number of requests that a single healthy instance can continuously process under stable operating conditions; and the pre-peak availability discount factor for newly added instances represents the actual availability of the newly added instance before the traffic peak arrives. The earlier the newly added instance completes its availability preparation, the closer the pre-peak availability discount factor is to 1, indicating that the newly added instance can fully utilize its stable processing capacity. The closer the availability time of the newly added instance is to the traffic peak arrival time, the smaller the pre-peak availability discount factor is, indicating that the actual capacity that the newly added instance can contribute during the peak phase is more limited. Therefore, by combining the stable processing capacity of a single instance with the peak availability discount factor of new instances to form the effective carrying capacity of a single instance, and then using the predicted carrying capacity gap divided by the effective carrying capacity of a single instance to obtain the demand value of the expanded instances, the number of expanded instances can not only reflect the size of the traffic gap, but also reflect the actual availability of new instances, thereby avoiding the problems of over-expansion or under-expansion caused by simply expanding based on the peak gap.

[0040] The specific formula for the required value of expanded instances is as follows: ; In the formula, This represents the required number of instances to be expanded, which is used to assess the number of instances that need to be expanded based on the predicted traffic shortfall, the total processing capacity of the current instances, and the actual available contribution of the new instances. This represents the predicted peak request volume, used to characterize the request scale corresponding to the future traffic peak. This represents the total processing capacity of the current instance, representing the upper limit of the requests that a currently healthy running instance can stably handle at the current moment; This represents the stable processing capacity value for a single instance, used to characterize the request processing capacity of a single instance in a stable state. This represents the pre-peak conversion factor for newly added instances, used to characterize the effective carrying capacity that newly added instances can actually achieve before the traffic peak arrives; This represents a very small positive number, used to avoid calculation errors caused by a zero denominator and to improve the numerical stability of the formula. The unit of the very small positive number is consistent with the unit of the corresponding denominator, and the preferred value is 0.001.

[0041] In this embodiment, Table 1 is a data table of expansion instance requirements. The smallest positive number is 0.001. The table details the predicted peak request volume, current instance total processing capacity, single instance stable processing capacity, pre-peak available conversion factor for new instances, and expansion instance requirements for five traffic surge events. Specifically, event 1 corresponds to a predicted peak request volume of 8437, a current instance total processing capacity of 6726, a single instance stable processing capacity of 887, a pre-peak available conversion factor for new instances of 0.91, and an expansion instance requirement of 3; event 2 corresponds to a predicted peak request volume of 13184, a current instance total processing capacity of 7563, a single instance stable processing capacity of 913, a pre-peak available conversion factor for new instances of 0.83, and an expansion instance requirement of 8; event 3 corresponds to a predicted peak request volume of 21376, a current instance total processing capacity of 8742, a single instance stable processing capacity of 913, a pre-peak available conversion factor for new instances of 0.83, and an expansion instance requirement of 8; and event 3 corresponds to a predicted peak request volume of 21376, a current instance total processing capacity of 8742, a single instance stable processing capacity of 913, a pre-peak available conversion factor for new instances of 0.83, and an expansion instance requirement of 8. The processing capacity value is 936, the peak availability conversion factor for new instances is 0.62, and the expansion instance requirement value is 22; the predicted peak request volume for event 4 is 18229, the current total processing capacity of the instance is 10084, the stable processing capacity of a single instance is 904, the peak availability conversion factor for new instances is 0.48, and the expansion instance requirement value is 19; the predicted peak request volume for event 5 is 14318, the current total processing capacity of the instance is 12487, the stable processing capacity of a single instance is 918, the peak availability conversion factor for new instances is 0.86, and the expansion instance requirement value is 3.

[0042] Table 1. Expansion Instance Demand Data Table

[0043] like Figure 3 The figure shows the relationship between the demand for new instances and the carrying capacity under a traffic surge event. The figure uses a traffic surge event as the object and visualizes the key calculation results in the formula for the demand value of new instances. Different bars represent the predicted carrying capacity gap (the difference between the predicted peak request volume and the total processing capacity of the current instance) and the effective carrying capacity of a single instance (the actual effective carrying capacity after the combined effect of the stable processing capacity of a single instance and the pre-peak available discount factor for new instances). The line represents the demand value for new instances, used to characterize the number of new instances needed under the current event. By jointly displaying the predicted carrying capacity gap, the effective carrying capacity of a single instance, and the demand value for new instances, the figure intuitively reflects the changes in the system's expansion pressure under different traffic surge events, and the impact of the actual effective contribution capacity of new instances on the number of new instances. (See Table 1 and...) Figure 3As can be seen, Event 3 corresponds to the largest predicted capacity gap, reaching 12634, indicating the strongest request growth pressure. Simultaneously, the pre-peak availability discount factor for new instances drops to 0.62, leading to a decrease in the effective capacity of a single instance. Therefore, the demand for expanded instances is the highest, reaching 22, indicating that when instantaneous traffic surges, a large number of instances need to be added quickly to meet the capacity demand. In Event 4, although the predicted peak request volume is lower than in Event 3, the pre-peak availability discount factor for new instances further decreases to 0.48, causing a continued weakening of the effective capacity of a single instance. Therefore, the demand for expanded instances remains high, indicating that when new instances are difficult to deploy in a timely manner, even if traffic pressure decreases, a large number of expanded instances are still needed to compensate. In Events 1 and 5, the predicted capacity gap is relatively small, and the pre-peak availability discount factor for new instances is high, indicating that new instances can be deployed quickly to handle business traffic. Therefore, the demand for expanded instances is low, requiring only a small number of new instances to meet traffic demand. Overall, the demand for expanding instances is not only related to the traffic gap, but also closely related to the actual availability of new instances before the peak is reached, which can more realistically reflect the expansion demand under the scenario of sudden traffic changes.

[0044] This implementation plan can determine the required number of expansion instances by combining the predicted capacity gap, the stable processing capacity of a single instance, and the availability of new instances before peak periods. This allows the expansion quantity to reflect both future traffic pressure and the actual capacity contribution of new instances, avoiding over-expansion or under-expansion caused by simply expanding based on peak request volume, and improving the accuracy of expansion decisions and resource utilization.

[0045] Specifically, the process of generating instance expansion instructions based on the expansion timing marker and expansion instance requirements, and adding the new instances to the traffic forwarding link corresponding to the target service, is as follows: When an early expansion marker is generated, an early expansion instruction is generated based on the expansion instance requirement value, and expansion is executed using a gradual and smooth expansion method. The gradual and smooth expansion method involves creating new instances in stages according to a preset expansion batch ratio, and starting the next batch of new instances only after the previous batch of new instances has passed the health check. The preset expansion batch ratio is used to divide the expansion instance requirement value into multiple expansion batches, preferably 20% to 40% of the expansion instance requirement value created in each batch, and the number of new instances in each batch is at least 1. The waiting time between adjacent expansion batches is preferably 1 to 3 fixed sampling periods, and the confirmation that the health check of the previous batch of new instances has passed is used as the trigger condition for starting the next batch of new instances, thereby reducing the impact of creating too many instances at once on the image pulling, service registration, and health check processes. When an emergency expansion flag is generated, an emergency expansion command is generated based on the expansion instance demand value, and expansion is executed using a dense batch expansion method. The dense batch expansion method is as follows: compared to the gradual smooth expansion method, it increases the number of new instances per batch and shortens the waiting time between adjacent expansion batches. Specifically, the dense batch expansion method is preferably 50% to 80% of the expansion instance demand value created per batch, and the waiting time between adjacent expansion batches is preferably 0 to 1 fixed sampling period, which is used to improve the speed of new instance creation when the peak is approaching. Increasing the number of new instances per batch means that the number of new instances per batch under the dense batch expansion method is greater than the number of new instances per batch under the gradual smooth expansion method, and shortening the waiting time between adjacent expansion batches means that the waiting time between adjacent expansion batches under the dense batch expansion method is less than the waiting time between adjacent expansion batches under the gradual smooth expansion method. Simultaneously, from the preset instance template set corresponding to the current service, the instance template with the smallest sum of container startup time and health check pass time is selected first. The preset instance template set is a pre-configured set of deployable instance templates for the current service, and each instance template includes the container image version, resource specifications, startup parameters, and health check configuration. The sum of container startup time and health check pass time characterizes the critical preparation time from instance creation to entering a traffic-accessible state. Selecting the instance template with the smallest sum shortens the time for newly added instances to become available in emergency scaling scenarios. Based on advance scaling instructions and emergency scaling instructions, scaling requests are issued to the container orchestration platform. Scaling requests include the target service identifier, the required value of the scaling instance, the scaling method, and the scaling execution timestamp. The container orchestration platform creates new instances based on the scaling requests and adds the new instances to the traffic forwarding link corresponding to the target service.The scaling method is used to identify whether a gradual, smooth scaling method or a dense, batch scaling method is used, and the scaling execution timestamp is used to record the time when the scaling request is issued. After a new instance completes a health check and is registered as an available instance by the service discovery component, the load balancer adds the new instance to the traffic forwarding link corresponding to the target service, allowing the new instance to start sharing the inbound requests. Optionally, when the inbound request volume corresponding to the target service is lower than the total processing capacity of the current instance for 3 to 10 consecutive fixed sampling periods, and the slope of the request volume growth is less than a preset fallback threshold, the current service is determined to have entered a traffic recovery state. The total processing capacity of the current instance is the product of the number of running instances with normal health status and the stable processing capacity value of a single instance. The preset fallback threshold is preferably less than or equal to zero, used to indicate that the growth trend of the inbound request volume has stopped growing and entered a stable or declining phase. Once the current service is determined to have entered a traffic recovery state, the number of retained instances is determined based on the current inbound request volume and the stable processing capacity of a single instance. Specifically, the base value for the number of retained instances is obtained by dividing the current inbound request volume by the sum of the stable processing capacity of a single instance and a very small positive number, and then rounding up to obtain the total number of retained instances. The number of retained instances is subtracted from the number of currently healthy running instances to obtain the number of instances that can be scaled down. When the number of scalable instances is greater than zero, it is used as the scaling-down instance requirement value; when the number of scalable instances is less than or equal to zero, the scaling-down instance requirement value is set to zero. The container orchestration platform prioritizes newly added instances whose current request processing volume is below a preset idle threshold as the instances to be scaled down, based on the scaling-down instance requirement value. The preset idle threshold is determined as a certain percentage of the stable processing capacity of a single instance, preferably 5% to 20%. The instances to be scaled down are first removed from the traffic forwarding link corresponding to the target service. After confirming that there are no currently processing business requests on the instances to be scaled down, the corresponding instances are stopped to avoid interruption of business request processing. After scaling down is completed, the scaling down execution time, the number of instances scaled down, the number of instances before scaling down, the number of instances after scaling down, and the corresponding service identifiers are associated and written into the scaling monitoring database for subsequent traffic recovery analysis and scaling down strategy adjustment.

[0046] like Figure 4The diagram illustrates the collaboration between peak traffic arrival and pre-expansion capacity scaling. It explains the synergistic relationship between predicted traffic changes, instance expansion, and capacity enhancement in a cluster resource adaptive scaling system based on traffic mutation awareness. The blue curve represents the predicted inbound request volume over time, reflecting the request growth trend of the target service under traffic mutation scenarios. The orange dashed line represents the original instance's total processing capacity, characterizing the upper limit of the request capacity that a currently healthy instance can stably handle without expansion. The green stepped curve represents the total processing capacity after expansion, reflecting the capacity enhancement process formed by the gradual addition of new instances to the traffic forwarding link after completing image pulling, container startup, service registration, health checks, and service resource initialization. Specifically, "Current Expansion Trigger Time" indicates the time point when traffic mutation is identified and expansion decisions are generated; "New Instance Access" indicates the time point when the new instance completes availability preparation and begins receiving business requests; "Peak Arrival" indicates the time point when the predicted inbound request volume reaches its peak; and "Peak Availability Time Difference" indicates the time difference between the expected availability time of the new instance and the expected arrival time of the traffic peak, characterizing the time margin by which the new instance can be deployed for business operations before the traffic peak arrives. The shaded area in the diagram represents the area where the original instance is insufficient to handle the predicted inbound request volume, which exceeds the total processing capacity of the original instance. This indicates that if expansion is not performed, the original instance will not be able to continue to stably handle the subsequent increase in traffic. By adding new instances in batches, the total processing capacity after expansion gradually increases and eventually covers the request processing needs corresponding to the predicted traffic peak, thereby achieving dynamic capacity supplementation in traffic peak scenarios.

[0047] This implementation plan can select the corresponding expansion execution method based on the expansion timing marker and the expansion instance requirement value. Before the peak arrives, it adopts a gradual and smooth expansion to reduce the startup impact caused by centralized instance creation. When the peak is approaching, it adopts a dense batch expansion to improve the availability speed of new instances. At the same time, after the traffic recovers, it controls instance reclamation by retaining the number of instances and the shrinking instance requirement value to avoid new instances being idle for a long time. It also reduces the risk of service interruption during the shrinking process by removing the traffic forwarding link before stopping the instance.

[0048] Reference Figure 2As shown, the second aspect of the present invention provides a cluster resource adaptive scaling system based on traffic mutation awareness, applied to the aforementioned cluster resource adaptive scaling method based on traffic mutation awareness, comprising: a data acquisition and processing module, used to acquire cluster scaling awareness data in real time, preprocess the cluster scaling awareness data, and extract traffic change features, response change features, and queuing change features; a traffic mutation identification module, used to identify the traffic mutation state based on the traffic change features, response change features, and queuing change features, and when in a traffic mutation state, analyze historical traffic mutation records or growth extrapolation results, evaluate the expected arrival time of the traffic peak and the predicted peak request volume, and perform boundary verification on the predicted peak request volume; an availability time prediction module, used to combine the cluster scaling awareness data and the expected arrival time of the traffic peak to perform a timeliness assessment of the availability preparation process for new instances, and generate a scaling timing marker based on the timeliness assessment result; and a scaling decision execution module, used to combine the cluster scaling awareness data and the predicted peak request volume to determine the scaling instance requirement, generate an instance scaling instruction based on the scaling timing marker and the scaling instance requirement, and add the new instance to the traffic forwarding link corresponding to the target service.

[0049] In this implementation plan, each module can complete data acquisition and processing, traffic mutation identification, availability prediction and scaling decision execution, forming a complete closed loop from traffic awareness, peak assessment, expansion timing judgment to instance expansion implementation, thereby improving the timeliness, accuracy and service stability of cluster expansion in traffic mutation scenarios.

[0050] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0051] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. As those skilled in the art will understand, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A cluster resource adaptive scaling method based on traffic mutation awareness, characterized in that, Includes the following steps: S1 collects cluster scaling sensing data in real time, performs data preprocessing on the cluster scaling sensing data, and extracts traffic change characteristics, response change characteristics, and queuing change characteristics. S2 identifies traffic mutation states based on traffic change characteristics, response change characteristics, and queuing change characteristics. When in a traffic mutation state, it analyzes historical traffic mutation records or growth extrapolation results to assess the expected arrival time of the traffic peak and the predicted peak request volume, and performs boundary verification on the predicted peak request volume. S3 combines cluster scaling awareness data and the estimated arrival time of traffic peaks to conduct a timeliness assessment of the preparation process for new instance availability, and generates expansion timing markers based on the timeliness assessment results; S4 combines cluster scaling awareness data and predicted peak request volume to determine the need for expanding instances. Based on the scaling timing marker and the need for expanding instances, it generates instance scaling instructions and adds the new instances to the traffic forwarding link corresponding to the target service.

2. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 1, characterized in that, The specific process of real-time acquisition of cluster scaling sensing data, data preprocessing of the cluster scaling sensing data, and extraction of traffic change features, response change features, and queuing change features is as follows: Real-time collection of cluster scaling awareness data, including: service identifier, instance number, ingress request volume, service interface response time, request queue length, number of currently running instances, instance health status, image pull baseline time, container startup baseline time, service registration baseline time, health check pass baseline time, and service resource initialization baseline time. The cluster scaling awareness data is time-aligned using a unified clock reference and resampled according to a fixed sampling period. Missing data is filled using forward padding, and data that exceeds the business operation range is marked as outliers and removed. The number of requests processed by each instance within the fixed sampling period is calculated to obtain the number of requests processed per instance per unit time. Divide the current sampling time's inbound request volume by the sum of the previous sampling time's inbound request volume and the smallest positive number to obtain the request volume month-over-month ratio; construct a sliding time window and calculate the standard deviation of the request volume month-over-month ratio within the sliding time window to obtain the request volume month-over-month ratio fluctuation value; calculate the average service interface response time within the sliding time window to obtain the average request response time; calculate the difference between the current window's average request response time and the previous window's average request response time, and divide it by the sum of the previous window's average request response time and the smallest positive number to obtain the response time growth rate; calculate the average request queue length within the sliding time window to obtain the average request queue length; calculate the difference between the current window's average request queue length and the previous window's average request queue length, and divide it by the sum of the previous window's average request queue length and the smallest positive number to obtain the queue length growth rate; The raw and preprocessed cluster scaling awareness data are associated with the corresponding service identifier, instance number, and sampling timestamp and written into the scaling monitoring database.

3. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 2, characterized in that, The specific process for identifying abrupt changes in traffic flow based on flow change characteristics, response change characteristics, and queuing change characteristics is as follows: Calculate the difference between the current sampling time and the previous sampling time, and divide it by the sampling period to obtain the request growth slope; calculate the difference between the current sampling time and the previous sampling time's request growth slope, and divide it by the sampling period to obtain the request growth acceleration. When K consecutive sampling times satisfy the following conditions: increasing inbound request volume, request volume growth rate greater than the growth rate threshold, and response time growth rate greater than the response growth threshold or queue length growth rate greater than the queue growth threshold, the current cluster is determined to have entered the early stage of traffic mutation, and a traffic mutation marker is generated. The inbound request volume, request volume growth rate, request volume growth acceleration, response time growth rate, and queue length growth rate are combined to construct a traffic state feature vector. The traffic state feature vector and the traffic mutation marker are written into the scaling monitoring database. The traffic state feature vector is used for subsequent historical mutation similarity matching to predict peak arrival time and peak request volume.

4. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 3, characterized in that, The specific process of analyzing historical traffic mutation records or growth extrapolation results to assess the estimated arrival time of the traffic peak and predict the peak request volume when in a state of traffic mutation is as follows: After generating a traffic mutation marker, historical traffic mutation records are read. When the number of historical traffic mutation records is greater than or equal to the minimum sample size threshold, the current traffic state feature vector and the historical traffic state feature vector corresponding to each historical traffic mutation record are obtained. The Euclidean distance between the current traffic state feature vector and the historical traffic state feature vector is calculated to obtain the state difference value. The first m historical traffic mutation records are selected from smallest to largest based on the state difference value. For each historical traffic mutation record, the traffic mutation marker generation time corresponding to the historical traffic mutation record is obtained as the mutation start time, the ingress request volume sequence, and the sampling timestamp corresponding to each ingress request volume. In the ingress request volume sequence after the mutation start time, the maximum ingress request volume is selected as the historical peak request volume, and the sampling timestamp corresponding to the historical peak request volume is used as the historical peak arrival time. The difference between the historical peak arrival time and the mutation start time is calculated to obtain the historical peak arrival duration. Based on the historical peak request volume in each historical traffic mutation record, the average value is calculated to obtain the predicted peak request volume. The average value of the historical peak arrival duration in each historical traffic mutation record is calculated and then added to the current time to obtain the estimated arrival time of the traffic peak. When the number of historical traffic mutation records is less than the minimum sample size threshold, a second-order growth expression is constructed based on the current inbound request volume, the request volume growth slope, and the request volume growth acceleration. The upper limit of the inbound request volume is substituted into the second-order growth expression to obtain the corresponding positive real time solution, thus obtaining the estimated arrival time required for the current inbound request volume to grow to the upper limit of the inbound request volume. Add the current time to the estimated arrival time to get the estimated arrival time of the traffic peak, and use the upper limit of the inbound request volume as the predicted peak request volume.

5. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 4, characterized in that, The specific process for boundary verification of the predicted peak request volume is as follows: When the predicted peak request volume is less than the current ingress request volume, the predicted peak request volume will be adjusted to the current ingress request volume; when the predicted peak request volume is greater than the ingress request volume limit, the predicted peak request volume will be adjusted to the ingress request volume limit.

6. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 4, characterized in that, The specific process for evaluating the timeliness of the preparation process for new instance availability by combining cluster scaling awareness data and the estimated arrival time of traffic peaks is as follows: After generating a traffic mutation flag, read the baseline time for pulling the image, the baseline time for starting the container, the baseline time for registering the service, the baseline time for passing the health check, and the baseline time for initializing the service resources corresponding to the current service. Calculate the baseline time for image pull, container startup, service registration, and health check. Sum the baseline time for service resource initialization and add the current time to get the estimated availability time of the new instance. Subtract the estimated availability time of new instances from the estimated arrival time of peak traffic to obtain the pre-peak availability time difference; divide the pre-peak availability time difference by the sum of the average request response time and the smallest positive number to obtain the time matching ratio; add one to the request volume ratio and take the natural logarithm to obtain the request growth enhancement item. The natural exponential operation is performed on the negative of the request month-on-month fluctuation value to obtain the growth stability suppression term; the time matching ratio, the request growth enhancement term and the growth stability suppression term are multiplied to obtain the expansion timing matching value.

7. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 6, characterized in that, The specific process for generating expansion timing markers based on timeliness assessment results is as follows: When the expansion timing matching value is greater than the expansion early trigger threshold, it is determined that the newly added instance is expected to be ready for availability before the traffic peak arrives, and an early expansion flag is generated. When the expansion timing matching value is less than or equal to the expansion early trigger threshold, it is determined that the newly added instance is not expected to be ready for availability before the traffic peak arrives, and an emergency expansion flag is generated.

8. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 4, characterized in that, The specific process of determining the demand for scaling up instances by combining cluster scaling awareness data and predicted peak request volume is as follows: The median number of requests processed per unit time for each instance when the instance health status is normal is calculated to obtain the stable processing capacity value of a single instance; the total processing capacity of the current instance is obtained by multiplying the number of running instances with normal health status by the stable processing capacity value of a single instance. Read the available time difference before the peak, compare the available time difference before the peak with zero and take the maximum value, divide the maximum value by the sum of the average request response time and the smallest positive number to get the discounted value of available time before the peak; take the opposite of the discounted value of available time before the peak and perform natural exponentiation, subtract the result of natural exponentiation from one to get the discounted value of available time before the peak for new instances; Calculate the difference between the predicted peak request volume and the current instance's total processing capacity, compare the difference with zero and take the maximum value to obtain the predicted capacity gap; multiply the stable processing capacity of a single instance by the available discount factor before the peak of the new instance, and add a very small positive number to obtain the effective capacity of a single instance; divide the predicted capacity gap by the effective capacity of a single instance to obtain the base value of the expansion instance demand, and round up the base value of the expansion instance demand to obtain the expansion instance demand value.

9. The cluster resource adaptive scaling method based on traffic mutation awareness according to claim 1, characterized in that, The specific process of generating instance expansion instructions based on the expansion timing marker and expansion instance requirements, and adding the new instance to the traffic forwarding link corresponding to the target service, is as follows: When an early expansion flag is generated, an early expansion instruction is generated based on the expansion instance demand value, and the expansion is executed in a progressive and smooth expansion manner. The progressive and smooth expansion manner is as follows: new instances are created in stages according to the preset expansion batch ratio, and the next batch of new instances is started only after the previous batch of new instances has passed the health check. When an emergency expansion flag is generated, an emergency expansion command is generated based on the expansion instance requirement value, and the expansion is executed using a dense batch expansion method. The dense batch expansion method is as follows: compared with the gradual smooth expansion method, it increases the number of new instances in a single batch and shortens the waiting time between adjacent expansion batches; at the same time, it prioritizes selecting the instance template with the smallest sum of container startup time and health check pass time from the preset instance template set corresponding to the current service. Based on the advance expansion instructions and emergency expansion instructions, expansion requests are issued to the container orchestration platform. The expansion request includes the target service identifier, the required value of the expansion instance, the expansion method, and the expansion execution timestamp. The container orchestration platform creates new instances based on the scaling request and adds the new instances to the traffic forwarding link corresponding to the target service.

10. A cluster resource adaptive scaling system based on traffic mutation awareness, characterized in that, include: The data acquisition and processing module is used to collect cluster scaling sensing data in real time, preprocess the cluster scaling sensing data, and extract traffic change features, response change features, and queuing change features. The traffic mutation identification module is used to identify the traffic mutation state based on traffic change characteristics, response change characteristics, and queuing change characteristics. When the traffic mutation state is in the case, it analyzes historical traffic mutation records or growth extrapolation results to evaluate the expected arrival time of the traffic peak and the predicted peak request volume, and performs boundary verification on the predicted peak request volume. The availability prediction module is used to combine cluster scaling awareness data and the estimated arrival time of traffic peaks to assess the timeliness of the preparation process for the availability of new instances, and generate expansion timing markers based on the timeliness assessment results. The scaling decision execution module is used to combine cluster scaling awareness data and predicted peak request volume to determine the demand for scaling up instances. Based on the scaling timing marker and the demand for scaling up instances, it generates instance scaling instructions and adds the new instances to the traffic forwarding link corresponding to the target service.

Images