Method and system for unloading service blocking request in multi-cloud environment

Abstract

The invention relates to the technical field of cloud computing, in particular to a method and a system for unloading a service blocking request in a multi-cloud environment. The method comprises the steps of obtaining cloud platform operation data and a service request; calculating the maximum tolerable blocking rate upper limit of the service request routing to the target cloud platform based on the acquired cloud platform operation data; judging the maximum bearable cost based on the maximum tolerable blocking rate upper limit; evaluating the income based on the maximum bearable cost to determine a routing policy; and performing intelligent routing unloading early warning according to the routing strategy parameters. According to the method, through an intelligent routing retry mechanism and judgment on the upper limit of the maximum tolerable blocking rate of the standby cloud, invalid retry and unloading of the request to the unhealthy standby cloud are effectively avoided, and the overall stability of the multi-cloud system is guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud platform task scheduling, and in particular to a method and system for offloading service blocking requests in a multi-cloud environment. Background Art

[0002] Enterprises are now widely adopting a multi-cloud strategy, deploying applications across multiple cloud service providers. This offers advantages such as business resilience and avoiding vendor lock-in. However, when a service on a particular cloud platform (such as an API or database) experiences request congestion due to a sudden increase in traffic, resource exhaustion, or localized failure, traditional approaches (such as manual switching and simple retries) are often inefficient and can exacerbate the congestion, leading to service interruptions, poor user experience, and even high cross-cloud data transfer costs. Existing technologies lack a cross-cloud request offloading solution that can detect congestion in real time, intelligently assess cost and latency, and automatically make decisions.

[0003] Furthermore, existing solutions have the following limitations: Response lag and inefficiency: Manual intervention is slow and cannot handle traffic bursts or failures that occur within seconds or even milliseconds. DNS-based solutions are not instantaneous and are unaware of the congestion status within specific services, allowing only coarse-grained regional or cloud-level switching.

[0004] Lack of intelligent decision-making and blind retries: Simple retries at the client or application layer may further increase the pressure on already blocked services, creating an "avalanche effect."

[0005] Lack of cost and latency awareness: Existing load balancing or failover mechanisms generally lack the ability to intelligently perceive and optimize cross-cloud data transmission costs (egress costs) and real-time network latency, which may result in high operating expenses or suboptimal user experience.

[0006] Heterogeneity: The APIs, quality of service (QoS) metrics, and billing models of different cloud platforms vary greatly, making unified management and decision-making difficult. Summary of the Invention

[0007] To address the aforementioned issues, the present invention provides a method and system for offloading blocked service requests in a multi-cloud environment. This method, which is real-time, intelligent, and cost-effective, effectively avoids "retry storms" and improves the resilience, availability, and performance of multi-cloud applications while effectively controlling operating costs.

[0008] In a first aspect, the present invention provides a method for offloading service blocking requests in a multi-cloud environment, which adopts the following technical solutions: A method for offloading service blocking requests in a multi-cloud environment, comprising: Obtain cloud platform operation data and service requests; Based on the obtained cloud platform operation data, the maximum tolerable blocking rate limit of the service request is calculated and routed to the target cloud platform; Determine the maximum tolerable cost based on the upper limit of the maximum tolerable blocking rate; Determine routing strategies based on the maximum tolerable cost and assess benefits; Provide intelligent routing offload warning based on routing policy parameters.

[0009] Furthermore, the maximum tolerable blocking rate upper limit of the service request routing to the target cloud platform based on the obtained cloud platform operation data calculation includes the platform setting a maximum tolerable blocking rate upper limit B max,j , where j represents the jth cloud platform, B max,j It is defined as the maximum blocking rate that can be allowed when service S runs on cloud platform j without violating the preset QoS indicators. s,j The model of service nodes, blocking rate P block,j Expressed as: , Where λ is the total task arrival rate, μ j is the average service processing rate of a single service instance, N s,j is the number of service instances, λ max,j is the maximum allowed total task arrival rate, B max,j =P block,j (λ max,j ,μ j ,N s,j ).

[0010] Furthermore, the maximum tolerable cost is determined based on the upper limit of the maximum tolerable blocking rate, including real-time monitoring of the blocking status of the current service request, and comparing the blocking status with the upper limit of the maximum tolerable blocking rate, calculating the comprehensive offloading costs corresponding to different cross-cloud routing strategies under the corresponding circumstances, thereby obtaining the maximum tolerable cost of offloading the current request to the optimal backup cloud platform, wherein the real-time blocking rate is calculated by monitoring the request queue length, the number of rejected connections and the response delay anomaly indicators of the source cloud platform to determine whether the current service request needs to be offloaded.

[0011] Furthermore, the real-time blocking rate ρ current (t), expressed as: .

[0012] Furthermore, the method of determining the maximum tolerable cost based on the maximum tolerable blocking rate upper limit also includes setting a multi-objective function to calculate the comprehensive cost of offloading requests to a backup cloud platform based on the expected cross-cloud transmission delay, cross-cloud data transmission cost, and failure rate, which is expressed as: , Among them, w latency ,w data ,w proc ,w fail : It is the weight coefficient preset by the user or system, which indicates the importance attached to latency, data transmission cost, processing latency and failure rate, and is normalized ∑w k =1,D cross,j : Expected cross-cloud transmission delay, C data,j The expected cross-cloud data transfer costs.

[0013] Furthermore, the expected cross-cloud data transmission cost C data,j The calculation is expressed as: , Among them, DataSize is the amount of data requested / responsed, Price egress is the unit price of export costs in the corresponding direction, T proc,j : Expected backup cloud processing delay, P fail,j : Expected uninstall failure rate.

[0014] Furthermore, the maximum tolerable cost is determined based on the upper limit of the maximum tolerable blocking rate, and the optimal backup cloud platform is selected according to the determined comprehensive cost, and the maximum tolerable cost under the optimal backup cloud platform is determined based on the maximum tolerable cost under the optimal backup cloud platform. block,j (λ j ,μ j ,N s,j )≤B max,j Under the premise of total,j The smallest backup cloud platform j*: , where λ j is the expected total load of backup cloud j after receiving the offloading request, and the maximum tolerable cost is expressed by Cost max_bearable It is defined as the comprehensive offloading cost of offloading requests to the optimal backup cloud platform j* in the current scenario, expressed as: Cost max_bearable =Cost total,j * 。

[0015] Furthermore, the benefit evaluation based on the maximum tolerable cost is used to determine the routing strategy, including evaluating the actual cost of offloading a specific blocked request to the selected optimal backup cloud platform j* in real time when the request is actually blocked and ready to be offloaded. real If the real cost is real Maximum Affordable Cost max_bearable , indicating that the current request can be offloaded to j*, through the optimal routing strategy parameters Will indicate: Target cloud platform: j*; uninstall probability P offload :100%; Load Type: Immediate Retry / Switch Type = Immediate: Directly forward the request to j*; Flow Retry Type = Weighted_Split: Leave part of the traffic in the original cloud until recovery, and offload part to the backup cloud; Delayed Retry Type = Delayed_Retry(t delay ): Wait for t delay Try the original cloud again after a certain time. If it is still blocked, uninstall it.

[0016] Furthermore, the method of determining the routing strategy based on the maximum tolerable cost evaluation benefit also includes the following steps: real >= Maximum tolerable cost max_bearable , indicating that the current cost of offloading to j* is too high and the offloading is not performed. Indicate the target cloud platform: Maintain the original cloud platform i; uninstall probability P offload :0%; Uninstall type: Wait and alert Type = Wait_or_Alert.

[0017] In a second aspect, a system for offloading service blocking requests in a multi-cloud environment includes: The data acquisition module is configured to obtain cloud platform operation data and service requests; The request module is configured to calculate the maximum tolerable blocking rate upper limit of the service request routed to the target cloud platform based on the obtained cloud platform operation data; The determination module is configured to determine the maximum tolerable cost based on the upper limit of the maximum tolerable blocking rate; The policy module is configured to determine a routing policy by evaluating benefits based on a maximum tolerable cost; The early warning module is configured to perform intelligent routing unloading early warning according to routing policy parameters.

[0018] In a third aspect, the present invention provides a computer-readable storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded and executed by a processor of a terminal device, and a method for unloading service blocking requests in a multi-cloud environment is provided.

[0019] In a fourth aspect, the present invention provides a terminal device comprising a processor and a computer-readable storage medium, wherein the processor is used to implement various instructions; the computer-readable storage medium is used to store multiple instructions, and the instructions are suitable for being loaded and executed by the processor. A method for unloading service blocking requests in a multi-cloud environment.

[0020] In summary, the present invention has the following beneficial technical effects: The present invention effectively avoids invalid retries and offloading requests to unhealthy backup clouds through an intelligent routing retry mechanism and the judgment of the upper limit of the maximum tolerable blocking rate of the backup cloud, thereby ensuring the overall stability of the multi-cloud system.

[0021] The present invention quantifies cross-cloud data transmission costs and latency and other factors into comprehensive offloading costs, and uses this as the basis for decision-making, ensuring that cloud expenditures are optimized to the greatest extent while restoring services, avoiding potential huge operating expenses.

[0022] By optimizing algorithmic decision-making and automated execution, the present invention makes complex cross-cloud routing and offloading processes intelligent and automated, significantly reducing operational complexity and human errors.

[0023] Through dynamic and intelligent request distribution and retry, even when a local cloud platform fails or is overloaded, traffic can be quickly transferred to other healthy cloud platforms, greatly improving the overall availability and resilience of multi-cloud applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a schematic diagram of a method for offloading service blocking requests in a multi-cloud environment according to embodiment 1 of the present invention. DETAILED DESCRIPTION

[0025] The present invention will be further described in detail below with reference to the accompanying drawings.

[0026] Example 1 Reference Figure 1 , a method for offloading service blocking requests in a multi-cloud environment according to this embodiment includes: Obtain cloud platform operation data and service requests; Based on the obtained cloud platform operation data, the maximum tolerable blocking rate limit of the service request is calculated and routed to the target cloud platform; Determine the maximum tolerable cost based on the upper limit of the maximum tolerable blocking rate; Determine routing strategies based on the maximum tolerable cost and assess benefits; Provide intelligent routing offload warning based on routing policy parameters.

[0027] Specifically: Step 1: Get cloud platform service data, These include, λ: Total Task Arrival Rate: the total number of tasks arriving at cloud platform j per unit time.

[0028] Count the number of tasks received by cloud platform j over a period of time (e.g., hourly or daily), and then calculate the average. This can be obtained by monitoring logs, task queue systems, or API call records.

[0029] The task flow entering cloud platform j is continuously tracked through a real-time monitoring system, and its average arrival rate within a short time window is calculated.

[0030] μ j : Average Processing Rate per Service Instance: The number of tasks that a single service instance (or server) on cloud platform j can process and complete in unit time.

[0031] In a controlled environment, a single service instance is performance tested, and the average time it takes to process a known type of task is measured. The inverse of the average time is then used to obtain the processing rate.

[0032] Monitor the actual task completion rate of a single service instance in production. Record task start and end times. If the service instance exposes metrics related to processing power (e.g., "transactions per second" or "requests per second"), retrieve them directly through the API.

[0033] N s,j Number of Service Instances: The total number of parallel service instances used to process tasks on cloud platform j. Obtained directly from the deployment configuration of cloud platform j.

[0034] Step 2: Based on the target cloud platform's service capacity, calculate the maximum tolerable blocking rate when routing the service request to the target cloud platform.

[0035] Among them, a maximum tolerable blocking rate limit B is set on the platform max,j , in order to meet the backup cloud's own P block,j (λ j ,μ j ,N s,j )≤B max,jUnder the premise of total,j The smallest backup cloud platform j*. Where j represents the jth cloud platform. B max,j It is defined as the maximum blocking rate that can be allowed when service S runs on cloud platform j without violating the preset QoS indicators. s,j The model of service nodes, blocking rate P block,j It can be expressed as: , Where λ is the total task arrival rate, μ j is the average service processing rate of a single service instance, N s,j is the number of service instances. max,j is the maximum allowed total task arrival rate, B max,j =P block,j (λ max,j ,μ j ,N s,j ).

[0036] Among them, the blocking rate calculation formula is used to calculate the probability that all servers in the M / M / c queuing system are busy and customers need to wait in line.

[0037] , This part of the numerator represents the system in all N s,j The relative probability weight of the state that all service instances are occupied, that is, all service instances are processing tasks and new requests are waiting in line for service. The term reflects the fact that in the Poisson arrival and exponential service time model, there are N s,j The relative probability that a task is being served.

[0038] is a correction factor used to handle the situation when the system load reaches N when calculating the Erlang C blocking rate. s,j The special case of a queue with multiple service instances shows the trend of queues forming when all service desks are occupied.

[0039] , The denominator represents the sum of the relative probability weights of all possible states of the system. This is necessary to normalize the probabilities and ensure that the final calculated probability value is between 0 and 1.

[0040] The summation term indicates that there are 0 to N s,j−1The sum of the relative probability weights of all situations in which a task is being served. This means that at least one service station is idle, or the service station is not fully occupied, and new tasks can be served directly without queuing.

[0041] Step 3: Monitor the blocking status of the current service request in real time. Compare the monitoring results with the maximum tolerable blocking rate obtained in Step 1, and calculate the comprehensive offloading cost corresponding to different cross-cloud routing strategies in the corresponding situation. This will determine the maximum tolerable cost of offloading the current request to the optimal backup cloud platform.

[0042] (1) Current cloud real-time blocking rate monitoring: Among them, real-time blocking rate monitoring requires real-time indicator collection, and performance data is continuously collected by deploying monitoring agents in cloud service instances, load balancers, message queues, etc.

[0043] At the same time, key indicators are defined and collected, including: Request Queue Length: Monitors the number of pending requests in the task queue.

[0044] Rejected connections: Statistics on new connection requests that were rejected due to overload.

[0045] Abnormal response delay: Monitor whether the average / P99 response time exceeds the threshold or whether the error rate increases.

[0046] Real-time calculation and judgment: Substitute the collected indicator data into the blocking rate calculation model to calculate the current blocking rate in real time.

[0047] Real-time blocking rate Real-time blocking rate ρ current (t) Calculated by monitoring the source cloud platform's request queue length, number of rejected connections, response latency anomalies, and other indicators.

[0048] , (2) Determine whether uninstallation is required: If ρ current (t)>B threshold (The preset offloading trigger threshold is usually much lower than the maximum tolerable blocking rate B of the source cloud. max,i ), the uninstall decision process is triggered.

[0049] (3) Calculate the comprehensive offloading cost of different backup cloud platforms total,j : For each potential backup cloud platform j (which can be in a different region or from a different cloud provider), the comprehensive cost of offloading requests to that platform is calculated. This cost is a multi-objective function that includes the expected cross-cloud transmission delay and cross-cloud data transmission cost, as well as the failure rate.

[0050] Among them, by adopting the weighted summation method, each sub-cost item is normalized and multiplied by the corresponding weight to obtain a comprehensive score. latency ,w data ,w proc, w fail ) reflects the user or system's preference for different optimization objectives (delay, data transmission cost, processing delay, failure rate). By adjusting these weights, , w latency ,w data ,w proc ,w fail : It is the weight coefficient preset by the user or system, which indicates the importance attached to latency, data transmission cost, processing latency and failure rate, and is normalized ∑w k =1.

[0051] D cross,j : Expected cross-cloud transmission delay, i.e., the network delay of request transmission from source cloud platform to backup cloud platform j.

[0052] C data,j Expected cross-cloud data transfer cost. This is calculated by multiplying the request and response data volume by the cross-cloud egress traffic price in the corresponding direction.

[0053] T proc,j : Expected backup cloud processing latency, i.e., the average time it takes for a request to be processed by a service instance on backup cloud j.

[0054] P fail,j : Expected offload failure rate, i.e., the probability that a request will fail after being offloaded to backup cloud j due to internal issues in the backup cloud, network outages, or other reasons. This parameter can be predicted based on historical data or real-time health check results.

[0055] (4) Cloud service providers typically charge for egress traffic, which is the amount of data transferred from one region or cloud platform to another or to the internet. The following formula accurately calculates the inbound and outbound traffic required to offload a request (if the response is also large) and multiplies it by the corresponding egress fee unit price, thereby quantifying the direct financial cost of the offloading operation.

[0056] The calculation method is: , Among them, DataSize request and DataSize responseRefers to the size of the request and response data (for example, in GB). gress,i→j and Price egress,j→i They represent the unit price of the egress cost from the source cloud platform i to the backup cloud platform j, and the unit price of the egress cost from the backup cloud platform j back to the source cloud platform i.

[0057] (5) Select the optimal backup cloud platform: In order to meet the backup cloud's own P block,j (λ j ,μ j ,N s,j )≤B max,j Under the premise of total,j The smallest backup cloud platform j*: , where λ j is the expected total load of backup cloud j after receiving the offload request (6) Maximum tolerable cost: Cost max_bearable It is defined as the comprehensive offloading cost of offloading requests to the optimal backup cloud platform j* in the current scenario: Cost max_bearable =Cost total,j * Step 4: Based on real-time dynamic cost-benefit evaluation, the final decision is whether to perform offloading and what specific routing strategy to adopt.

[0058] Among them, the real-time unloading cost Cost real Evaluation: When a request is blocked and ready to be offloaded, the real cost of offloading the specific blocked request to the optimal backup cloud platform j* selected in step 2 is evaluated in real time.

[0059] 1) If Cost real <Cost max_bearable : It indicates that it is economical and efficient to offload the request to j* at present, and the offloading can be performed. Cost real The evaluation results will directly guide the optimal routing strategy parameters The generation of tells the system how to handle blocked requests, expressed as: Target cloud platform: j*.

[0060] Uninstallation probability P offload :100%.

[0061] Offload type: Immediate retry / switch (Type = Immediate): Directly forward the request to j*. Weighted_Split retry (Type = Weighted_Split): Leave part of the traffic on the original cloud until it is restored, and offload part to the backup cloud. Delayed retry (Type = Delayed_Retry(t delay )):Wait for t delay Try the original cloud again after a certain time. If it is still blocked, uninstall it.

[0062] 2) If Cost real >=Cost max_bearable : Indicates that the cost of offloading to j* is too high or the performance has no significant improvement. Optimal routing policy parameters Will instruct: Target cloud platform: Maintain the original cloud platform i.

[0063] Uninstallation probability P offload :0%.

[0064] Uninstallation type: Wait or Alert (Type = Wait_or_Alert). In this case, the system triggers an alarm, notifies the operation and maintenance personnel, and enters degraded mode or throttling.

[0065] Step 5: According to the strategy parameters in step 3 For service requests blocked by the current cloud platform, intelligent routing offload or front-end alarm is performed between backup cloud platforms.

[0066] Among them, when the service request of the source cloud platform is confirmed to be blocked, the system will use the previously calculated optimal routing strategy parameters , automatically perform the corresponding processing.

[0067] (1) Request interception and blocking confirmation, Interception point: The system intercepts the request at the entry point of the service request (API gateway).

[0068] Confirm blocking: Combined with real-time monitoring data, the system will reconfirm whether the blocked request is indeed affected by the source cloud platform blocking.

[0069] (2) Execute intelligent routing strategies, System based For the uninstallation type and target cloud platform j* indicated in , take the following actions: Retry / Switch Immediately (Type = Immediate): Immediately forward or redirect the blocked request to the optimal backup cloud platform j*.

[0070] Applicable scenarios: The source cloud platform experiences a serious failure or instant saturation, and traffic needs to be quickly transferred.

[0071] Split retry (Type = Weighted_Split): Execution: Based on the preset offloading probability, some new traffic is distributed directly to j*, and blocked requests that are allowed to be retried are also routed there.

[0072] Applicable scenarios: The source cloud platform is continuously under high load but has not completely failed, and its pressure needs to be smoothly reduced.

[0073] Delayed Retry(Type = Delayed_Retry(t delay )): Execution: Temporarily cache the blocked request and retry the original cloud after waiting for tdelay time. If the original cloud is still blocked or the attempt fails, route to j*.

[0074] Applicable scenarios: The source cloud platform experiences intermittent failures or brief network jitter.

[0075] (3) Front-end alarm and system protection, Wait and alert (Type = Wait_or_Alert): Execute: If the assessment shows that offloading is not cost-effective or impossible (for example, all alternative clouds are also overloaded, or cross-cloud charges are too high), the system will not perform the offloading.

[0076] Alert: Immediately trigger a high-level alert to the operation and maintenance personnel, and may return a friendly error prompt to the user.

[0077] Protection: At the same time, the system may initiate the source cloud platform's degradation mode or throttling strategy to prevent it from completely crashing.

[0078] (4) Feedback on execution results, The execution results of each uninstallation operation (success / failure, actual path, time consumption, etc.) will be recorded and sent to the "Performance and Cost Continuous Audit Module" as a basis for subsequent optimization and calibration.

[0079] Step 6: Continuous audit of performance and cost to achieve continuous learning and adaptive optimization of the system in, (1) Continuous fine-grained monitoring and data collection, Continuously track every offloaded or routed request, collecting actual performance data (such as actual completion latency and offload success rate) and actual cost data (such as actual cross-cloud data transfer volume and fees) throughout its entire lifecycle. This data is typically obtained through distributed tracing systems, cloud vendor traffic logs, and billing APIs.

[0080] (2) Audit and deviation analysis, The actual data collected is compared with the predictions or expectations made by the system before making decisions, and the deviations in performance and cost are calculated.

[0081] If the actual cross-cloud transmission latency or data transmission cost is consistently higher than the predicted value, it indicates that there is a bias in the prediction model.

[0082] (3) Feedback and model optimization, These deviations are used as feedback signals and transmitted to key modules of the system to achieve continuous learning and model optimization: Optimize the multi-cloud service status monitoring module: calibrate its congestion identification threshold or model parameters to make its perception of service congestion more accurate.

[0083] Optimize the cross-cloud cost and latency prediction module: Use actual data to retrain or fine-tune its prediction model to improve the accuracy of future latency and cost predictions.

[0084] Optimize the intelligent routing decision engine: Adjust the weight coefficients in the decision model based on actual cost-effectiveness to achieve a better balance between performance and cost in future decisions.

[0085] (4) Alarms and reports, When the audit results show that actual performance is far below expectations (such as SLA violations and cost overruns), the system will trigger an alarm to notify the operation and maintenance personnel.

[0086] Generate performance and cost reports regularly to provide data support for system optimization, capacity planning, and business decisions.

[0087] Through this continuous audit, feedback and optimization mechanism, the present invention can continuously learn and adapt to the dynamic changes of the multi-cloud environment, ensuring the efficiency, stability and cost-effectiveness of the long-term operation of the system. Continuously and finely monitor the actual completion latency (T actual_completion ), success rate (P actual_success ), the actual amount of cross-cloud data transmission and the actual costs incurred (C actual_data The audit results (deviation information) are used as feedback signals and transmitted to the key modules of the system. This can be used to optimize the weight coefficient w of IRDE. k This allows them to better balance performance and cost in future decisions. Regularly generate performance and cost reports to provide a basis for system optimization and capacity planning.

[0088] Example 2 This embodiment provides a system for offloading service blocking requests in a multi-cloud environment, including: The data acquisition module is configured to obtain cloud platform operation data and service requests; The request module is configured to calculate the maximum tolerable blocking rate upper limit of the service request routed to the target cloud platform based on the obtained cloud platform operation data; The determination module is configured to determine the maximum tolerable cost based on the upper limit of the maximum tolerable blocking rate; The policy module is configured to determine a routing policy by evaluating benefits based on a maximum tolerable cost; The early warning module is configured to perform intelligent routing unloading early warning according to routing policy parameters.

[0089] A computer-readable storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded and executed by a processor of a terminal device, a method for offloading service blocking requests in a multi-cloud environment.

[0090] A terminal device includes a processor and a computer-readable storage medium, wherein the processor is used to implement various instructions; the computer-readable storage medium is used to store multiple instructions, wherein the instructions are suitable for being loaded and executed by the processor. A method for offloading service blocking requests in a multi-cloud environment is described.

[0091] The above are all preferred embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. Therefore, any equivalent changes made based on the structure, shape, and principle of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for offloading service blocking requests in a multi-cloud environment, characterized in that: include: Obtain cloud platform operation data and service requests; Based on the obtained cloud platform operation data, the maximum tolerable blocking rate limit of the service request is calculated and routed to the target cloud platform; Determine the maximum tolerable cost based on the upper limit of the maximum tolerable blocking rate; Determine routing strategies based on the maximum tolerable cost and assess benefits; Provide intelligent routing offload warning based on routing policy parameters.

2. The method for offloading service blocking requests in a multi-cloud environment according to claim 1, characterized in that: The maximum tolerable blocking rate limit of the computing service request routed to the target cloud platform based on the acquired cloud platform operation data includes the platform setting a maximum tolerable blocking rate limit B max,j Where j represents the jth cloud platform, B max,j It is defined as the maximum blocking rate that can be allowed when service S runs on cloud platform j without violating the preset QoS indicators. s,j The model of service nodes, blocking rate P block,j Expressed as: ， Where λ is the total task arrival rate, μ j is the average service processing rate of a single service instance, N s,j is the number of service instances, λ max,j is the maximum allowed total task arrival rate, B max,j =P block,j (λ max,j ,μ j ,N s,j ).

3. The method for offloading service blocking requests in a multi-cloud environment according to claim 2, characterized in that: The method of determining the maximum tolerable cost based on the maximum tolerable blocking rate upper limit includes real-time monitoring of the blocking status of the current service request, comparing the blocking status with the maximum tolerable blocking rate upper limit, and calculating the comprehensive offloading costs corresponding to different cross-cloud routing strategies under the corresponding circumstances, thereby obtaining the maximum tolerable cost of offloading the current request to the optimal backup cloud platform. The method calculates the real-time blocking rate and determines whether offloading is required by monitoring the request queue length, the number of rejected connections, and the response delay anomaly indicators of the source cloud platform.

4. The method for offloading service blocking requests in a multi-cloud environment according to claim 3, characterized in that: The real-time blocking rate ρ current (t), expressed as: 。 5. The method for offloading service blocking requests in a multi-cloud environment according to claim 4, characterized in that: The method of determining the maximum tolerable cost based on the maximum tolerable blocking rate upper limit also includes setting a multi-objective function to calculate the comprehensive cost of offloading requests to a backup cloud platform based on the expected cross-cloud transmission delay, cross-cloud data transmission cost, and failure rate, which is expressed as: ， Among them, w latency ,w data ,w proc ,w fail : It is the weight coefficient preset by the user or system, which indicates the importance attached to latency, data transmission cost, processing latency and failure rate, and is normalized ∑w k =1,D cross,j : Expected cross-cloud transmission delay, C data,j The expected cross-cloud data transfer costs.

6. The method for offloading service blocking requests in a multi-cloud environment according to claim 5, characterized in that: The expected cross-cloud data transfer cost C data,j The calculation is expressed as: ， Among them, DataSize is the amount of data requested / responsed, Price egress is the unit price of export costs in the corresponding direction, T proc,j : Expected backup cloud processing delay, P fail,j : Expected uninstall failure rate.

7. The method for offloading service blocking requests in a multi-cloud environment according to claim 6, characterized in that: The maximum tolerable cost is determined based on the upper limit of the maximum tolerable blocking rate, and the optimal backup cloud platform is selected according to the determined comprehensive cost, and the maximum tolerable cost under the optimal backup cloud platform is determined based on the maximum tolerable cost under the optimal backup cloud platform. block,j (λ j ,μ j ,N s,j )≤B max,j Under the premise of total,j The smallest backup cloud platform j*: ， where λ j is the expected total load of backup cloud j after receiving the offloading request, and the maximum tolerable cost is expressed by Cost max_bearable It is defined as the comprehensive offloading cost of offloading requests to the optimal backup cloud platform j* in the current scenario, expressed as: Cost max_bearable =Cost total,j * 。 8. The method for offloading service blocking requests in a multi-cloud environment according to claim 7, characterized in that: The benefit evaluation based on the maximum tolerable cost is used to determine the routing strategy, including the real cost of offloading the specific blocked request to the selected optimal backup cloud platform j* in real time when the request is blocked and ready to be offloaded. real If the real cost is real Maximum Affordable Cost max_bearable , indicating that the current request can be offloaded to j*, through the optimal routing strategy parameters Will indicate: Target cloud platform: j*; Uninstallation probability P offload :100%; Load Type: Immediate Retry / Switch Type = Immediate: Directly forward the request to j*; Flow Retry Type = Weighted_Split: Leave part of the traffic in the original cloud until recovery, and offload part to the backup cloud; Delayed Retry Type = Delayed_Retry(t delay ): Wait for t delay Try the original cloud again after a certain time. If it is still blocked, uninstall it.

9. The method for offloading service blocking requests in a multi-cloud environment according to claim 8, characterized in that: The benefit is evaluated based on the maximum tolerable cost to determine the routing strategy, and the actual cost is also included. real >= Maximum tolerable cost max_bearable , indicating that the current cost of offloading to j* is too high and the offloading is not performed. Indicate the target cloud platform: Maintain the original cloud platform i; uninstall probability P offload :0%; Uninstall type: Wait and alert Type = Wait_or_Alert.

10. A system for offloading service blocking requests in a multi-cloud environment, characterized in that: include: The data acquisition module is configured to obtain cloud platform operation data and service requests; The request module is configured to calculate the maximum tolerable blocking rate upper limit of the service request routed to the target cloud platform based on the obtained cloud platform operation data; The determination module is configured to determine the maximum tolerable cost based on the upper limit of the maximum tolerable blocking rate; The policy module is configured to determine a routing policy by evaluating benefits based on a maximum tolerable cost; The early warning module is configured to perform intelligent routing unloading early warning according to routing policy parameters.

Images