A method and apparatus for elastic quota allocation for PaaS platforms

Abstract

This invention provides a method and apparatus for elastic quota allocation in a PaaS platform, relating to the field of distributed system traffic control. It includes: determining whether to trigger elastic quota allocation through a dual-condition triggering mechanism; allocating elastic quotas only when resources of each type are sufficient for each resource type; identifying long-term over-provisioned tenants through historical data analysis, and restricting their allocation eligibility when the historical over-provisioning rate exceeds the long-term over-provisioning threshold; calculating a priority weighting factor based on the tenant's SLA level, payment tier, and historical behavior score; calculating an elastic coefficient for each resource type based on its idle rate, priority weighting factor, and time decay factor; distributing the calculated elastic coefficients for each resource type to a local rate-limiting proxy to update the actual available quota for each tenant on each resource type; and monitoring the elastic quota utilization rate. This improves business success rate and resource utilization, and prevents long-term over-provisioned tenants from occupying elastic resources.

Description

Technical Field

[0001] This invention belongs to the field of distributed system traffic control technology, and in particular relates to a method and apparatus for elastic quota allocation for PaaS platforms. Background Technology

[0002] With the rapid development of cloud computing technology, microservice architecture and PaaS (Platform as a Service) multi-tenant environments have become the mainstream deployment models. In PaaS platforms, business applications from different tenants share the same underlying infrastructure and service cluster. This resource-sharing model unique to PaaS platforms brings new technical challenges. Based on practical project experience, traditional distributed rate limiting solutions have the following significant shortcomings in PaaS platform environments:

[0003] Lack of fairness among PaaS platform tenants: Current rate limiting solutions mostly set global thresholds based on services or APIs, failing to distinguish the tenant identity behind a request. In a PaaS platform, this can lead to abnormal or sudden traffic from a single tenant potentially congesting shared resources and affecting the normal processing of other tenants' requests, resulting in erroneous rate limiting of compliant requests and violating the PaaS platform's Service Level Agreement (SLA).

[0004] Low resource utilization of PaaS platforms: Existing static quota schemes cannot detect the real-time utilization of underlying resources of the PaaS platform. When resources such as CPU and memory are very idle, tenants are still strictly limited to their basic quotas, resulting in a huge waste of PaaS platform resources and failing to achieve "making the best use of resources".

[0005] PaaS platform lacks elastic quota mechanism: Existing solutions lack intelligent elastic quota calculation capabilities, cannot provide temporary resource support when tenants experience sudden traffic surges and overall resources are sufficient, and cannot identify long-term over-provisioned tenants and restrict their elasticity eligibility.

[0006] The complexity of multi-level calls in PaaS platforms is compounded: In PaaS platforms, a single external request often triggers a call chain across multiple services. Existing solutions struggle to continuously track tenant identities within complex call paths and use them for rate limiting decisions, failing to achieve end-to-end tenant-level resource guarantees for PaaS platforms. Summary of the Invention

[0007] Therefore, the technical problem to be solved by the present invention is to provide a method and apparatus for elastic quota allocation for PaaS platforms, which realizes intelligent elastic allocation, improves business success rate and resource utilization in both sudden traffic scenarios and resource idle scenarios, and avoids long-term over-allocation of elastic resources by tenants.

[0008] In a first aspect, the present invention provides a method for elastic quota allocation for a PaaS platform, comprising:

[0009] S1 determines whether to trigger the flexible quota allocation through a two-condition triggering mechanism; the two-condition triggering mechanism includes:

[0010] By detecting sudden surges in tenant traffic, it can be determined whether elastic quota allocation is triggered.

[0011] By detecting whether system resources are idle and the tenant's quota utilization, it can be determined whether to trigger elastic quota allocation;

[0012] S2, For each resource type, determine whether the resource type is sufficient, and only perform elastic quota allocation when the resource type is sufficient;

[0013] S3 identifies long-term over-allocation tenants through historical data analysis. When a tenant's historical over-allocation rate exceeds the long-term over-allocation threshold, its allocation eligibility is restricted.

[0014] S4 calculates a priority weighting factor based on the tenant’s Service Level Agreement (SLA) level, payment tier, and historical behavior score.

[0015] S5. For each resource type, calculate the elasticity coefficient based on the idle rate, priority weighting factor, and time decay factor of that resource type.

[0016] S6 sends the elasticity coefficients calculated for each resource type to the local rate limiting agent and updates the actual available quotas for each resource type for the tenant.

[0017] S7. Monitor the elastic quota utilization rate. When the elastic quota utilization rate is lower than the recycling threshold, trigger quota recycling. Restore the elastic coefficient to the basic elastic coefficient and end the current elastic quota allocation for resources.

[0018] Furthermore, in S1, the step of determining whether to trigger elastic quota allocation by detecting sudden bursts of tenant traffic includes:

[0019] When the tenant utilization rate exceeds a preset burst threshold, elastic quota allocation is triggered; the tenant utilization rate is the ratio of the tenant's current actual utilization to the tenant's basic quota.

[0020] Furthermore, in S1, determining whether to trigger elastic quota allocation by detecting whether system resources are idle and the tenant quota utilization includes:

[0021] When the system resource idle rate exceeds the preset system resource idle threshold, if the tenant utilization rate is less than the preset active trigger utilization rate limit, then elastic quota allocation is triggered.

[0022] Furthermore, in S2, determining whether each resource type is sufficient, and only allocating flexible quotas when the resource type is sufficient, includes:

[0023] Determine whether the utilization rate of the resource type is lower than a preset resource safety threshold, and obtain the resource type utilization rate determination result;

[0024] When the resource type utilization rate determination result is yes, flexible quota allocation is performed;

[0025] When the resource type utilization rate judgment result is negative, no flexible allocation is performed;

[0026] The resource types include CPU utilization, memory utilization, database connection pool utilization, Redis connection utilization, or network bandwidth utilization.

[0027] Furthermore, in S3, the historical over-provision rate is the ratio of the number of over-provision days to the preset number of days within the past preset number of days; the number of over-provision days is the number of days when the tenant's utilization rate exceeds the basic quota.

[0028] Furthermore, in S4, the formula for calculating the priority weighting factor is:

[0029] P=base_priority+payment_bonus+behavior_bonus

[0030] in:

[0031] P is the priority weighting factor;

[0032] base_priority is the tenant SLA level; the tenant SLA levels include Basic, Standard, Professional, Enterprise, and Flagship editions.

[0033] payment_bonus refers to the tenant's payment tier; the tenant payment tiers include Free, Basic, Standard, Premium, Enterprise, and Customized.

[0034] behavior_bonus is a score for the tenant's historical behavior.

[0035] Furthermore, the tenant's historical behavior score includes:

[0036] Historical behavior score = base score + compliance reward - violation penalty + resource efficiency reward

[0037] in,

[0038] Base score = 0.0;

[0039] Compliance reward = min(number of days of compliant use / total number of days × 0.5, 0.5);

[0040] Penalty for violation = min(number of violations × 0.1, 0.8);

[0041] Resource efficiency bonus = (actual utilization rate - 0.5) × 0.2, with a range of [-0.1, 0.1].

[0042] Furthermore, the formula for calculating the elastic coefficient is as follows:

[0043] E_base_r = 1 + α × (1 - U_r);

[0044] E_priority_r = E_base_r × P;

[0045] E_decay_r=E_priority_r×e^(-β×t);

[0046] E_safe_r=min(E_decay_r,E_max);

[0047] E_r = max(E_safe_r, 1.0);

[0048] in,

[0049] α is an adjustment sensitivity parameter used to control the sensitivity of the elasticity coefficient to the resource idle rate;

[0050] U_r represents the utilization rate of the resource type, which is the real-time monitoring data for that resource type.

[0051] E_base_r is the base elasticity coefficient for the resource type, reflecting the idle level of that resource type;

[0052] P is the priority weighting factor;

[0053] E_priority_r is the elasticity coefficient weighted by resource type priority;

[0054] β is the time decay coefficient, used to control the rate at which the elastic quota decays over time;

[0055] t is the duration of the elastic state;

[0056] E_decay_r is the elasticity coefficient of the resource type after time decay;

[0057] E_max is the maximum elasticity coefficient limit;

[0058] E_safe_r is the resilience coefficient after resource type security boundary control;

[0059] E_r is the elasticity coefficient of the resource type.

[0060] Furthermore, S7 specifically includes:

[0061] Monitor the elastic quota utilization rate of each resource type at fixed time intervals;

[0062] If the utilization rate of the elastic quota is lower than the recycling threshold, recycling is triggered immediately, and the elasticity coefficient is reset.

[0063] Update quota allocation.

[0064] On the other hand, the present invention provides an elastic quota allocation device for a PaaS platform, the device including a trigger condition judgment module, a resource sufficiency judgment module, a long-term over-allocation identification module, a priority weighting module, an elastic coefficient calculation module, a quota update module, and a continuous monitoring and recycling module.

[0065] The triggering condition judgment module is used to determine whether to trigger elastic quota allocation through a dual-condition triggering mechanism; the dual-condition triggering mechanism includes:

[0066] By detecting sudden surges in tenant traffic, it can be determined whether elastic quota allocation is triggered.

[0067] By detecting whether system resources are idle and the tenant's quota utilization, it can be determined whether to trigger elastic quota allocation;

[0068] The resource sufficiency judgment module is used to determine whether the resource type is sufficient for each resource type, and to perform elastic quota allocation only when the resource type is sufficient.

[0069] The long-term over-allocation identification module is used to identify long-term over-allocation tenants through historical data analysis. When a tenant's historical over-allocation rate exceeds the long-term over-allocation threshold, its allocation eligibility is restricted.

[0070] The priority weighting module is used to calculate the priority weighting factor based on the tenant's Service Level Agreement (SLA) level, payment tier, and historical behavior score.

[0071] The elasticity coefficient calculation module is used to calculate the elasticity coefficient for each resource type based on the idle rate, priority weighting factor and time decay factor of that resource type.

[0072] The quota update module is used to send the elasticity coefficients calculated for each resource type to the local rate limiting agent and update the actual available quotas of the tenant for each resource type.

[0073] The continuous monitoring and recycling module is used to trigger quota recycling when the utilization rate of the elastic quota is lower than the recycling threshold; restore the elastic coefficient to the basic elastic coefficient; and end the current elastic quota allocation of resources.

[0074] Beneficial effects:

[0075] Intelligent Elastic Quota Allocation: Intelligent elastic allocation utilizes a dual-trigger mechanism through the Elastic Quota Calculator (ECA). When a sudden surge in tenant traffic (utilization exceeding a threshold) is detected and system resources are sufficient, passive burst elastic quota support is provided. When system resources are idle and tenants are not fully utilizing their quotas, proactive resource utilization elastic allocation is triggered, allowing tenants to fully utilize idle resources. It supports multiple factors such as tenant priority, time decay control, resource sufficiency assessment, and long-term over-provisioning identification, calculating elastic coefficients for each resource type to achieve intelligent elastic allocation. This improves business success rates and resource utilization in both burst traffic and idle resource scenarios, while preventing long-term over-provisioning tenants from occupying elastic resources.

[0076] Global stability: The multi-layered token bucket model and dynamic degradation mechanism prevent abuse by individual tenants and overload of individual services, improving the overall resilience of the system from multiple dimensions. The resource-level overload protection mechanism can perform precise rate limiting control for specific resource types (such as database connection pool exhaustion), avoiding the unavailability of the entire service due to a single resource bottleneck, effectively improving system availability and shortening fault recovery time.

[0077] Business-friendly: Supports tenant-level monitoring and autonomy, enhancing product operability and user experience. Provides multi-dimensional resource usage monitoring, allowing tenants to view the usage of various resources such as CPU, memory, database, and Redis, effectively improving operational efficiency and user experience.

[0078] Priority-driven progressive degradation and rate limiting: When service-level or resource-level capacity is insufficient, the system performs progressive degradation based on tenant priority (such as SLA level, payment tier) and request priority (such as read / write, synchronous / asynchronous, business urgency). This includes one or more of the following: soft rejection, queuing, proportional reduction of available tokens, and final forced rejection. This strategy is linked with quota adjustment to form an adaptive closed loop of "dynamic adjustment + priority degradation", which not only ensures the SLA of high-priority services, but also reduces overload jitter and resource fluctuations. Attached Figure Description

[0079] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0080] Figure 1 This is a system architecture diagram for Example 1;

[0081] Figure 2 This is a sequence diagram of dynamic quota adjustment in Example 2;

[0082] Figure 3 This is a flowchart of the quota allocation process in Example 2. Detailed Implementation

[0083] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. The principles and features of the present invention are described below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other. The embodiments given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0084] The mainstream current rate limiting solutions have the following limitations:

[0085] 1. Traditional token bucket algorithm: Traditional solutions, represented by Guava RateLimiter, are simple to implement, but only support single-dimensional rate limiting control and cannot distinguish tenant identities. In real multi-tenant environments, sudden traffic from a single tenant can easily crowd out public resources and affect other tenants.

[0086] 2. Distributed rate limiting solution: The distributed rate limiting solution based on Redis + Lua scripts solves the problem of single-point rate limiting, but it still has shortcomings in terms of tenant-level isolation and elastic resource allocation.

[0087] 3. Cloud-native rate limiting solutions: The rate limiting functions of cloud-native solutions such as Istio are mainly aimed at service-level rate limiting, and there are gaps in the resource management and elastic burst mechanism at the tenant level.

[0088] 4. Multi-tenant resource management in PaaS platforms: Although solutions such as Kubernetes ResourceQuota provide multi-tenant support, they only support static resource quotas in PaaS platform environments and cannot be dynamically adjusted according to real-time load, thus failing to meet the resource utilization optimization needs of PaaS platforms.

[0089] Example 1

[0090] like Figure 1 As shown in the figure, this embodiment discloses an elastic quota allocation device for a PaaS platform, the architecture of which is as follows:

[0091] 1. PaaS Platform Global Quota Manager (GQM): The core centralized component of the PaaS platform (can be deployed in a cluster). Its core responsibilities include:

[0092] Maintain the PaaS platform tenant quota policy library, defining the basic quota, maximum burst quota, etc. for each tenant on different services.

[0093] Maintain the PaaS platform system service resource capacity library and define the total processing capacity of each service.

[0094] Real-time monitoring of system resource utilization (such as CPU idle rate and memory usage) of all service nodes on the PaaS platform.

[0095] Based on the above strategies and real-time load, calculate and generate a multi-dimensional quota allocation table (tenant × service × resource type) for the PaaS platform and an elasticity coefficient E_r for each resource type.

[0096] Receive heartbeats and statistics from the local agent of the PaaS platform and dynamically adjust the quota allocation strategy.

[0097] Implement a quota leasing pool on the PaaS platform to manage the dynamic redistribution of idle quotas.

[0098] It integrates a pluggable fairness engine for the PaaS platform, supporting fairness assessment and quota allocation for various resource types.

[0099] Integrate the PaaS platform's elastic quota calculator to enable intelligent elastic quota allocation decisions.

[0100] 2. Tenant-Aware Local Limiter Agent (TLLA) for PaaS Platforms: Deployed on each service instance of the PaaS platform, its core responsibilities include:

[0101] Intercept all requests flowing into the PaaS platform and extract the tenant ID from the request context (such as HTTP headers and authentication information).

[0102] Maintain a multi-tiered token bucket structure for a PaaS platform:

[0103] Layer 1: PaaS platform service-level token bucket. Used to protect the total capacity of current service instances from being exhausted.

[0104] Layer 2: PaaS platform tenant-level token buckets. Each active tenant maintains an independent sub-token bucket, the capacity and filling rate of which are jointly determined by the tenant-specific quota issued by GQM and the elasticity coefficient E_r for each resource type.

[0105] The third layer: PaaS platform resource-level token buckets. Independent token buckets are maintained for each tenant, targeting different resource types (CPU, memory, database connections, Redis connections, network bandwidth, etc.).

[0106] Perform multi-level serial rate limiting checks on the PaaS platform: For each request, check the service-level capacity, tenant-level quota, and resource-level quota in sequence (depending on the specific resource type involved in the request). The request is only allowed if all levels of checks pass.

[0107] Implement end-to-end tenant identity transfer: When making calls between services on the PaaS platform, it is responsible for injecting the tenant identifier into the call request header. Through various methods such as HTTP request header injection, RPC call context transfer, and message queue message attribute transfer, it ensures the lossless transfer of tenant context in complex microservice call chains.

[0108] Regularly report to GQM the local token consumption rate, request latency, error rate, local system resource metrics, and external resource usage metrics such as databases / Redis on the PaaS platform.

[0109] When service-level or resource-level capacity is insufficient, it supports degradation and rate limiting based on tenant priority (such as SLA level, payment tier) and request priority (such as read / write, synchronous / asynchronous, business urgency).

[0110] High-priority tenants and high-priority requests are processed first, while low-priority requests are processed with tokens reduced proportionally or queued with delays.

[0111] Supports a progressive degradation strategy of "soft rejection → queuing → forced rejection" to avoid instantaneous fluctuations.

[0112] Degradation decisions can be dynamically adjusted by GQM using policy parameters, and take effect quickly locally on TLLA.

[0113] 3. PaaS Platform Pluggable Fairness Engine (PFE): As a core sub-component of the PaaS platform's GQM, it is responsible for implementing flexible resource fairness judgment logic. Its core features include:

[0114] PaaS platform resource type abstraction layer: Defines a unified resource interface to support fair management of various resource types such as CPU, memory, database connection pool, Redis connection, network bandwidth, and file handles.

[0115] PaaS platform with plug-in fairness algorithms: Supports plug-in access to various fairness algorithms (such as weighted round-robin, minimum fair sharing, proportional fairness, etc.), allowing users to select the most suitable fairness strategy based on different resource characteristics.

[0116] PaaS platform dynamic resource monitoring: Real-time monitoring of key indicators such as utilization rate of various resources, waiting queue length, and response time, providing data support for fairness decisions.

[0117] PaaS platform cross-resource coordination: When a single request involves multiple resources, it coordinates the allocation of quotas for different resource types to ensure overall fairness.

[0118] 4. PaaS Platform Elastic Quota Calculator (ECA): As a core sub-component of the PaaS platform's GQM, it is responsible for implementing intelligent elastic quota calculation. Its core features include:

[0119] PaaS platform burst traffic detection: Real-time monitoring of traffic patterns for each tenant to identify burst traffic scenarios.

[0120] PaaS platform tenant priority assessment: assess tenant priority based on tenant SLA level, payment tier, historical behavior, etc.

[0121] PaaS platform resource sufficiency assessment: comprehensively evaluate the overall resource status of the system to ensure that elastic allocation will not affect system stability.

[0122] PaaS platform long-term overprovisioning identification: Through historical data analysis, identify tenants who have been overprovisioning for a long time and restrict their elasticity eligibility.

[0123] PaaS platform elasticity coefficient calculation: The elasticity coefficient E_r of each resource type is calculated based on multi-dimensional factors.

[0124] The calculation of the elasticity coefficient includes:

[0125] i. Data structure design: A hierarchical hash table structure is adopted. The first layer uses the service ID as the key, the second layer uses the tenant ID as the key, and the third layer uses the resource type as the key to realize token bucket lookup with O(1) time complexity.

[0126] ii. Concurrency control: A read-write lock mechanism is used. Read operations (token checks) use read locks, and write operations (token updates) use write locks to ensure performance in high-concurrency scenarios.

[0127] iii. Memory optimization: A lazy loading mechanism is adopted, and token buckets are only created for active tenants to reduce memory usage.

[0128] i. HTTP Request Header Injection: Inject the tenant identifier into the HTTP request header at the API gateway layer to ensure that each request carries tenant information.

[0129] ii. RPC call context passing: When making RPC calls between services, the tenant identifier is passed as a context parameter, supporting mainstream RPC frameworks such as gRPC and Dubbo.

[0130] iii. Message queue message attribute passing: In asynchronous message processing scenarios, the tenant identifier is passed as a message attribute to ensure that the tenant identity can be correctly identified even in asynchronous processing.

[0131] iv. Distributed Linked Tracing Integration: Integrate with a distributed linked tracing system, using TraceID and SpanID to associate tenant identities, to achieve full-link tenant tracing.

[0132] i. Real-time monitoring: Resource utilization data is collected every 30 seconds using a timer, and the average value is calculated using a sliding window algorithm to avoid the impact of instantaneous fluctuations.

[0133] ii. Distributed computing: GQM uses the MapReduce model to calculate global resource utilization and supports real-time monitoring of large-scale clusters.

[0134] iii. Parameter tuning: Provides a parameter tuning interface to support dynamic adjustment of algorithm parameters according to actual business scenarios.

[0135] The workflow of this embodiment is as follows:

[0136] 1. Tenant Quota Initialization: The platform administrator configures a global quota package for each tenant, including service-level quotas and resource-level quotas (CPU, memory, database connections, Redis connections, network bandwidth, etc.). GQM decomposes this configuration into a three-dimensional matrix of "tenant-service-resource type" and distributes it to the TLLA of each service. Initially, the elasticity coefficient E_r of each resource type is set to 1.0.

[0137] 2. Request processing and multi-level rate limiting:

[0138] When the request arrives at the API gateway, the gateway authenticates the user and injects the Tenant-ID into the request header.

[0139] The request arrives at the TLLA of service S_j. The TLLA extracts the Tenant-ID (e.g., T123) and analyzes the specific resource type involved in the request.

[0140] TLLA first checks if the total token bucket of service S_j has enough tokens. If not, it first attempts to perform rate limiting based on tenant / request priority; if the rate limiting fails, it returns "Service busy".

[0141] If the service bucket is available or the downgrade is successful, then check if tenant T123's local sub-bucket (whose capacity is base quota × E_r, where E_r is the tenant's elasticity coefficient for the resource type involved in the request) has enough tokens. If not, reject immediately and return "Tenant quota insufficient".

[0142] If the tenant bucket has a token, then check the tenant's quota for the resource type involved in the request (such as database connection, Redis connection, etc.). If not, first attempt to perform degradation and rate limiting based on tenant / request priority; if degradation fails, return "Insufficient resource quota".

[0143] If all levels pass, the corresponding token is deducted, the request is processed, and the Tenant-ID is passed on to downstream service B.

[0144] 3. Dynamic feedback and fair adjustment:

[0145] TLLA regularly reports monitoring data to GQM (including tenant-level metrics, local CPU / memory load, database connection pool utilization, Redis connection count, network bandwidth utilization, etc.).

[0146] GQM analyzes data through a pluggable fairness engine (PFE) and implements dynamic adjustments to ensure fairness and resilience.

[0147] Service overload protection: When a service S_j is found to be overloaded, GQM can instruct all TLLAs to downgrade the quotas of all tenants of S_j by the same proportion (e.g., all downgraded to 80%), prioritizing the protection of the service from crashing.

[0148] Resource-level overload protection: When high usage of a specific resource type (such as database connection pool or Redis connection) is detected, GQM can downgrade the quota for all tenants for that resource type to prevent resource exhaustion.

[0149] Fair scheduling among tenants: When it is detected that the quota of tenant T_a has been idle for a long time, while tenant T_b continues to make over-quota requests, GQM can allocate a portion of T_a's quota to the "tenancy pool" and temporarily allocate it to T_b for use.

[0150] 4. Flexible quota calculation and allocation:

[0151] ECA analyzes the quota usage and system resource status of each tenant in real time and executes the elastic quota calculation algorithm.

[0152] Burst detection: Detects whether the current usage rate of a tenant exceeds the threshold of the basic quota (e.g., 80%).

[0153] Resource sufficiency assessment: For each resource type, assess the utilization rate of that resource type to ensure that there are enough idle resources to support elastic allocation.

[0154] Tenant eligibility assessment: Check whether the tenant is a long-term over-provisioned tenant and restrict their flexibility eligibility.

[0155] Priority weighting: The weighting factor is calculated based on the tenant priority (SLA level, payment tier).

[0156] Elasticity coefficient calculation: For each resource type, the elasticity coefficient E_r is calculated by taking into account multiple factors.

[0157] Time decay control: Ensure that elastic quotas have time limits to avoid long-term occupation.

[0158] Example 2

[0159] like Figure 2 As shown in the figure, this embodiment discloses an elastic quota allocation method for PaaS platforms.

[0160] The core objective of the Elastic Quota Calculator (ECA) is to intelligently identify sudden traffic demands from tenants while ensuring system stability. Based on multi-dimensional factors such as system resource status, tenant priority, and historical behavior, it dynamically calculates the elasticity coefficient E_r for each resource type to achieve intelligent elastic allocation of resources.

[0161] The core formula of this embodiment:

[0162] The elasticity coefficient E_r is calculated using a multi-factor weighted model for each resource type:

[0163] For resource type r:

[0164] E_safe_r=min(E_base_r×P×e^(-β×t),E_max);

[0165] E_r = max(E_safe_r, 1.0);

[0166] Or equivalently expressed as:

[0167] For resource type r: E_r=max(min([1+α×(1-U_r)]×P×e^(-β×t),E_max),1.0);

[0168] in:

[0169] E_base_r = 1 + α × (1 - U_r), the base elasticity coefficient for resource type r, reflecting the idle level of that resource type. α = sensitivity parameter, floating-point number 0.1-1.0, default 0.8. Used to control the responsiveness of the elasticity coefficient to resource idle rate. The larger α is, the faster the elastic quota increases when the resource is idle; the smaller α is, the smoother the elasticity change. It is recommended to adjust flexibly according to actual business needs. U_r = utilization rate of resource type r (between 0 and 1);

[0170] P=f(sla_level,payment_tier,behavior_score), a priority weighting factor that combines tenant level, payment status, and historical behavior;

[0171] β = Time decay coefficient, which controls the timeliness of the flexible quota;

[0172] t = duration of the elastic state (hours);

[0173] E_max = Maximum elasticity coefficient limit, to prevent excessive amplification;

[0174] like Figure 3 As shown, the algorithm execution flow in this embodiment is as follows:

[0175] The algorithm execution is divided into three stages: trigger condition check, elasticity coefficient calculation, and quota update and monitoring.

[0176] Phase 1: Trigger Condition Check

[0177] 1. Elastic trigger condition judgment (dual condition judgment):

[0178] usage_ratio=current_usage / base_quota;

[0179] system_idle_ratio = 1 - U_r (system resource idle rate);

[0180] / / Condition 1: Passive burst trigger (burst traffic from tenants);

[0181] burst_trigger=usage_ratio>burst_threshold;

[0182] / / Condition 2: Active resource utilization is triggered (system resources are idle and tenants are not fully configured);

[0183] proactive_trigger=(system_idle_ratio>idle_threshold)AND(usage_ratio <proactive_usage_threshold);

[0184] IF burst_trigger OR proactive_trigger THEN;

[0185] Enter the resilience assessment;

[0186] ELSE;

[0187] Keep E_r=1.0 for all resource types and end the calculation;

[0188] END IF.

[0189] Parameter description:

[0190] Design Description:

[0191] current_usage: The tenant's current actual usage (QPS / connections / GB, etc.), integer ≥ 0, real-time statistics, average value over a 30-second sliding window;

[0192] base_quota: Tenant's basic quota, integer > 0, the basic resource amount (QPS / connections / GB, etc.) agreed upon in the contract, maintained by GQM;

[0193] usage_ratio: Tenant utilization rate, floating-point number from 0 to ∞, current_usage / base_quota, calculated in real time;

[0194] U_r: System resource utilization rate, floating-point number 0-1, real-time monitoring data for this resource type;

[0195] system_idle_ratio: System resource idle rate, a floating-point number from 0 to 1, or 1 to U_r;

[0196] burst_threshold: Passive burst detection threshold, floating-point number 0.7-0.9, default 0.8. Exceeding this value is considered a burst.

[0197] idle_threshold: Actively triggers the idle threshold, a floating-point number of 0.3-0.6, with a default of 0.5. When the system idle rate exceeds this value, it can actively provide elastic quotas.

[0198] proactive_usage_threshold: Actively triggers the upper limit of usage rate, a floating-point number of 0.4-0.7, with a default of 0.6. Tenants can only enjoy proactive elasticity when their usage rate is below this value;

[0199] Passive burst trigger: Triggered when tenant utilization exceeds burst_threshold, used to handle sudden traffic surges;

[0200] Active resource utilization trigger: Triggered when system resources are idle and tenants are not fully utilizing their quotas, it is used to improve resource utilization and solve the problem of "system idle but tenants being rate-limited";

[0201] Dual protection: Through two triggering mechanisms, it ensures timely response in emergency scenarios and proactively improves resource utilization when the system is idle;

[0202] 2. System resource sufficiency assessment:

[0203] For each resource type r (CPU / Memory / DB / Redis / Network, etc.):

[0204] IF U_r <safety_threshold THEN;

[0205] Resources are sufficient; continue to conduct flexible assessments.

[0206] ELSE;

[0207] If resource r is scarce, set E_r=1.0 for this resource type and end elastic allocation for this resource type;

[0208] END IF.

[0209] Parameter description:

[0210] U_CPU: CPU utilization, floating-point number 0-1, system monitoring data, 1-minute average;

[0211] U_Memory: Memory usage, floating-point number 0-1, system monitoring data, 1-minute average;

[0212] U_DB: Database connection pool utilization, a floating-point number between 0 and 1, representing the number of active connections / the maximum number of connections;

[0213] U_Redis: Redis connection utilization, a floating-point number from 0 to 1, representing the number of active connections / the maximum number of connections;

[0214] U_Network: Network bandwidth utilization, a floating-point number from 0 to 1, representing current traffic / maximum bandwidth;

[0215] safety_threshold: Resource safety threshold, floating-point number 0.6-0.8, default 0.7. Elastic allocation of this resource type will stop if this value is exceeded.

[0216] 3. Identification of long-term over-provisioned tenants:

[0217] overshoot_ratio=historical_overshoot_days / total_days;

[0218] IF overshoot_ratio>long_term_threshold THEN;

[0219] If identified as a long-term over-provisioned tenant, set E_r=1.0 for all resource types and end the calculation;

[0220] ELSE;

[0221] Continue with flexible calculations;

[0222] END IF.

[0223] Parameter description:

[0224] historical_overshoot_days: Historical overshoot days, integer ≥ 0, statistics of overshoot days used in the past 90 days;

[0225] total_days: Counts the total number of days. Integer > 0, fixed at 90 days.

[0226] overshoot_ratio: Historical overshoot ratio, a floating-point number between 0 and 1, historical_overshoot_days / total_days;

[0227] long_term_threshold: Long-term overprovision threshold, floating-point number 0.3-0.6, default 0.5. Tenants exceeding this value are identified as long-term overprovisioned tenants.

[0228] Phase Two: Calculation of Elasticity Coefficient.

[0229] 4. Priority weighting factor calculation:

[0230] base_priority=1.0+(sla_level-1)×0.2 / / 1.0-2.0;

[0231] payment_bonus=payment_tier×0.1 / / 0-0.5;

[0232] behavior_bonus=behavior_score×0.3 / / -0.3 to 0.3;

[0233] P=base_priority+payment_bonus+behavior_bonus;

[0234] Parameter description:

[0235] sla_level: SLA level, integer 1-5, tenant configuration, 1=Basic, 2=Standard, 3=Professional, 4=Enterprise, 5=Ultimate;

[0236] payment_tier: Payment tier, integer 0-5, tenant configuration, 0=free version, 1=basic payment, 2=standard payment, 3=premium payment, 4=enterprise payment, 5=custom payment;

[0237] behavior_score: Historical behavior score, a floating-point number ranging from -1.0 to 1.0, calculated based on compliance, number of violations, and resource efficiency (see Section 5.4.2 for details).

[0238] base_priority: Basic priority, floating-point number 1.0-2.0, calculated based on SLA level;

[0239] payment_bonus: Paid reward, floating-point number 0-0.5, calculated based on the payment tier;

[0240] behavior_bonus: Behavior reward / penalty, a floating-point number from -0.3 to 0.3, calculated based on historical behavior scores;

[0241] P: Comprehensive priority factor, floating-point number, ultimately used for elasticity coefficient calculation.

[0242] 5. Step-by-step calculation of elasticity coefficient (calculated separately for each resource type):

[0243] For each resource type r (CPU / Memory / DB / Redis / Network, etc.):

[0244] E_base_r = 1 + α × (1 - U_r);

[0245] E_priority_r = E_base_r × P;

[0246] E_decay_r=E_priority_r×e^(-β×t);

[0247] E_safe_r=min(E_decay_r,E_max);

[0248] E_r = max(E_safe_r, 1.0).

[0249] Parameter description:

[0250] α: Adjust the sensitivity parameter, floating-point number 0.1-1.0, default 0.8, controls the sensitivity of the elasticity coefficient to the resource idle rate;

[0251] U_r: Utilization rate of resource type r, a floating-point number (0-1), representing real-time monitoring data for this resource type;

[0252] E_base_r: The base elasticity coefficient for resource type r, a floating-point number ≥ 1.0, reflecting the idle level of this resource type;

[0253] P: Priority weighting factor, a floating-point number, taking into account tenant level, payment status, and historical behavior;

[0254] E_priority_r: Elasticity coefficient weighted by the priority of resource type r, floating-point number ≥ 1.0;

[0255] β: Time decay coefficient, floating-point number 0.05-0.3, default 0.1, controls the rate at which the elastic quota decays over time;

[0256] t: Duration of the elastic state, floating-point number ≥ 0, in hours, starting from the beginning of the elastic state;

[0257] E_decay_r: The elasticity coefficient of resource type r after time decay, floating-point number ≥ 0;

[0258] E_max: Maximum elasticity coefficient limit, floating-point number 1.5-3.0, default 2.0, to prevent excessive amplification;

[0259] E_safe_r: The resilience coefficient after safety boundary control for resource type r, a floating-point number 1.0 - E_max;

[0260] E_r: The final elasticity coefficient of resource type r, a floating-point number 1.0-E_max, used for quota calculation of this resource type;

[0261] Phase 3: Quota updates and monitoring.

[0262] 6. Quota Update (issued separately for each resource type):

[0263] For each resource type r:

[0264] Actual quota_r = basic quota_r × E_r;

[0265] Distribute the flexible quotas for each resource type to TLLA;

[0266] Record the start time of the elastic state.

[0267] Parameter description:

[0268] Basic quota_r: Tenant basic quota for resource type r, integer > 0, the basic resource amount (QPS / connection count / GB, etc.) agreed upon in the contract.

[0269] E_r: The final elasticity coefficient of resource type r, a floating-point number 1.0-E_max, used for quota calculation of this resource type;

[0270] Actual quota_r: The actual available quota after calculation for resource type r, integer > 0, base quota × elasticity coefficient;

[0271] TLLA: Tenant-aware local rate limiting proxy, a local component responsible for performing rate limiting checks;

[0272] Elastic state start time: timestamp, used to calculate the elastic state duration t.

[0273] 7. Continuous monitoring and recycling (monitoring separately for each resource type):

[0274] The elastic state remains in DO;

[0275] For each resource type r:

[0276] Monitor the elastic quota utilization rate of resource r;

[0277] IF resource utilization rate <return_threshold THEN;

[0278] Trigger resource quota reclamation by setting E_r=1.0;

[0279] End the elastic state of resource r;

[0280] END IF.

[0281] Check every 30 seconds;

[0282] END WHILE.

[0283] Parameter description:

[0284] Elastic quota utilization rate: a floating-point number from 0 to 1, representing the actual utilization rate of the current elastic quota, calculated separately for each resource type;

[0285] return_threshold: Quota reclamation threshold, a floating-point number of 0.3-0.5, with a default of 0.4. Reclamation is triggered when the value falls below this.

[0286] E_r=1.0: Restores the basic elasticity coefficient of resource type r, indicating that the elasticity quota of this resource type is cancelled;

[0287] 30 seconds: Monitoring and inspection interval, fixed time interval, configurable range 10-60 seconds (monitor_interval parameter);

[0288] The mapping between SLA levels and basic priorities is shown in Table 1:

[0289] Table 1

[0290]

[0291] The mapping between payment tiers and reward coefficients is shown in Table 2:

[0292] Table 2

[0293]

[0294] Historical behavior scoring calculation rules:

[0295] behavior_score = base score + compliance reward - violation penalty + resource efficiency reward

[0296] in:

[0297] Base score = 0.0 (neutral starting point);

[0298] Compliance reward = min(number of days of compliant use / total number of days × 0.5, 0.5);

[0299] Penalty for violation = min(number of violations × 0.1, 0.8);

[0300] Resource efficiency bonus = (actual utilization rate - 0.5) × 0.2, range [-0.1, 0.1];

[0301] Violations include:

[0302] Long-term over-provisioning use (over-provisioning for 7 consecutive days);

[0303] Malicious traffic manipulation;

[0304] Violation of the user agreement;

[0305] Wasteful use of resources (utilization rate consistently below 30%).

[0306] The configuration parameters required for this embodiment are shown in Table 3, and can be adjusted according to the actual business scenario:

[0307] Table 3

[0308]

[0309] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A method for elastic quota allocation in a PaaS platform, characterized in that, include: S1 determines whether to trigger the flexible quota allocation through a dual-condition triggering mechanism; The dual-condition triggering mechanisms include: By detecting sudden surges in tenant traffic, it can be determined whether elastic quota allocation is triggered. By detecting whether system resources are idle and the tenant's quota utilization, it can be determined whether to trigger elastic quota allocation; S2, For each resource type, determine whether the resource type is sufficient, and only perform elastic quota allocation when the resource type is sufficient; S3 identifies long-term over-allocation tenants through historical data analysis. When a tenant's historical over-allocation rate exceeds the long-term over-allocation threshold, its allocation eligibility is restricted. S4 calculates a priority weighting factor based on the tenant’s Service Level Agreement (SLA) level, payment tier, and historical behavior score. S5. For each resource type, calculate the elasticity coefficient based on the idle rate, priority weighting factor, and time decay factor of that resource type. S6 sends the elasticity coefficients calculated for each resource type to the local rate limiting agent and updates the actual available quotas for each resource type for the tenant. S7. Monitor the elastic quota utilization rate. When the elastic quota utilization rate is lower than the recycling threshold, trigger quota recycling. Restore the elastic coefficient to the basic elastic coefficient and end the current elastic quota allocation for resources.

2. The method according to claim 1, characterized in that, In S1, the step of determining whether to trigger elastic quota allocation by detecting sudden bursts of tenant traffic includes: When the tenant utilization rate exceeds a preset burst threshold, elastic quota allocation is triggered; the tenant utilization rate is the ratio of the tenant's current actual utilization to the tenant's basic quota.

3. The method according to claim 2, characterized in that, In S1, determining whether to trigger elastic quota allocation by detecting whether system resources are idle and the tenant quota utilization includes: When the system resource idle rate exceeds the preset system resource idle threshold, if the tenant utilization rate is less than the preset active trigger utilization rate limit, then elastic quota allocation is triggered.

4. The method according to claim 1, characterized in that, In S2, determining whether each resource type is sufficient for each resource type, and only performing elastic quota allocation when the resource type is sufficient, includes: Determine whether the utilization rate of the resource type is lower than a preset resource safety threshold, and obtain the resource type utilization rate determination result; When the resource type utilization rate determination result is yes, flexible quota allocation is performed; When the resource type utilization rate judgment result is negative, no flexible allocation is performed; The resource types include CPU utilization, memory utilization, database connection pool utilization, Redis connection utilization, or network bandwidth utilization.

5. The method according to claim 1, characterized in that, In S3, the historical over-provision rate is the ratio of the number of over-provision days to the preset number of days within the past preset number of days; the number of over-provision days is the number of days when the tenant's utilization rate exceeds the basic quota.

6. The method according to claim 1, characterized in that, In S4, the formula for calculating the priority weighting factor is: P=base_priority+payment_bonus+behavior_bonus in: P is the priority weighting factor; base_priority is the tenant SLA level; the tenant SLA levels include Basic, Standard, Professional, Enterprise, and Flagship editions. payment_bonus refers to the tenant's payment tier; the tenant payment tiers include Free, Basic, Standard, Premium, Enterprise, and Customized. behavior_bonus is a score for the tenant's historical behavior.

7. The method according to claim 6, characterized in that, The tenant's historical behavior score includes: Historical behavior score = base score + compliance reward - violation penalty + resource efficiency reward, where, Base score = 0.0; Compliance reward = min(number of days of compliant use / total number of days × 0.5, 0.5); Penalty for violation = min(number of violations × 0.1, 0.8); Resource efficiency bonus = (actual utilization rate - 0.5) × 0.2, with a range of [-0.1, 0.1].

8. The method according to claim 1, characterized in that, In S5, the formula for calculating the elastic coefficient is as follows: E_base_r = 1 + α × (1 - U_r); E_priority_r = E_base_r × P; E_decay_r=E_priority_r×e^(-β×t); E_safe_r=min(E_decay_r,E_max); E_r = max(E_safe_r, 1.0); in, α is an adjustment sensitivity parameter used to control the sensitivity of the elasticity coefficient to the resource idle rate; U_r represents the utilization rate of the resource type, which is the real-time monitoring data for that resource type. E_base_r is the base elasticity coefficient for the resource type, reflecting the idle level of that resource type; P is the priority weighting factor; E_priority_r is the elasticity coefficient weighted by resource type priority; β is the time decay coefficient, used to control the rate at which the elastic quota decays over time; t is the duration of the elastic state; E_decay_r is the elasticity coefficient of the resource type after time decay; E_max is the maximum elasticity coefficient limit; E_safe_r is the resilience coefficient after resource type security boundary control; E_r is the elasticity coefficient of the resource type.

9. The method according to claim 1, characterized in that, Specifically, S7 includes: Monitor the elastic quota utilization rate of each resource type at fixed time intervals; If the utilization rate of the elastic quota is lower than the recycling threshold, recycling is triggered immediately, and the elasticity coefficient is reset. Update quota allocation.

10. A flexible quota allocation device for a PaaS platform, characterized in that, The device includes a trigger condition judgment module, a resource sufficiency judgment module, a long-term over-allocation identification module, a priority weighting module, an elasticity coefficient calculation module, a quota update module, and a continuous monitoring and recycling module. The triggering condition judgment module is used to determine whether to trigger elastic quota allocation through a dual-condition triggering mechanism. The dual-condition triggering mechanisms include: By detecting sudden surges in tenant traffic, it can be determined whether elastic quota allocation is triggered. By detecting whether system resources are idle and the tenant's quota utilization, it can be determined whether to trigger elastic quota allocation; The resource sufficiency judgment module is used to determine whether the resource type is sufficient for each resource type, and to perform elastic quota allocation only when the resource type is sufficient. The long-term over-allocation identification module is used to identify long-term over-allocation tenants through historical data analysis. When a tenant's historical over-allocation rate exceeds the long-term over-allocation threshold, its allocation eligibility is restricted. The priority weighting module is used to calculate the priority weighting factor based on the tenant's Service Level Agreement (SLA) level, payment tier, and historical behavior score. The elasticity coefficient calculation module is used to calculate the elasticity coefficient for each resource type based on the idle rate, priority weighting factor and time decay factor of that resource type. The quota update module is used to send the elasticity coefficients calculated for each resource type to the local rate limiting agent and update the actual available quotas of the tenant for each resource type. The continuous monitoring and recycling module is used to trigger quota recycling when the utilization rate of the elastic quota is lower than the recycling threshold; restore the elastic coefficient to the basic elastic coefficient; and end the current elastic quota allocation of resources.

Images