XR rendering micro-service cluster capacity maximization planning method oriented to service quality jitter constraint

Abstract

The invention discloses a service quality jitter constraint-oriented XR rendering micro-service cluster capacity maximization planning method, and belongs to the technical field of computer services. The method comprises the following steps: collecting MTP delay data of an XR micro-service in a normal state and a collapse state, and performing fitting by using a one-dimensional Gaussian distribution model; cPU, GPU and memory consumption data of the XR micro-service are collected, and a resource consumption prediction model is established by using a Gaussian mixture model; establishing a service quality jitter model; calculating the maximum user capacity of a single micro-service instance under given resource constraints; establishing an integer linear integer programming model, and introducing Boolean variables to represent the number of micro-service instances on nodes; a greedy algorithm is combined with local search to quickly solve a linear integer programming problem. According to the method, quantitative constraint on experience fluctuation caused by service collapse is realized, and the technical adaptation defect of a traditional micro-service cluster capacity planning method in an XR rendering scene is overcome.

Description

Technical Field

[0001] This invention relates to a capacity maximization planning method for XR rendering microservice clusters under service quality jitter constraints, belonging to the field of computer service technology. Background Technology

[0002] In recent years, with the rapid development of the metaverse technology system, Extended Reality (XR) technology, as one of its core supporting technologies, has shown a significant technological evolution trend in virtual scene interaction and 3D content rendering. Because XR applications have extremely high computing power requirements for real-time rendering, motion tracking, and photon response processing of the 3D virtual world, the computing power of edge devices alone is insufficient to meet their high-performance requirements. Therefore, building XR rendering microservice clusters based on a cloud-edge collaborative computing architecture has become the mainstream solution in the industry.

[0003] In the architecture of an XR rendering microservice cluster, edge XR devices need to establish and maintain long-term, stable rendering data stream connections with specific real-time rendering instances in the cluster. Simultaneously, complex service call chains form between rendering instances based on microservice dependencies, and business collaboration is achieved by continuously maintaining long-lived connections. When a real-time rendering instance crashes, causing a connection interruption with the user, although the edge device can temporarily switch to independent rendering mode to maintain basic services, the service quality will significantly degrade in this mode. If such crashes occur frequently, it will directly cause drastic fluctuations in service quality, i.e., service quality jitter, severely impacting the user experience. In contrast, brief service interruptions of non-real-time rendering instances, provided they have rapid recovery capabilities, typically do not have a substantial impact on the user experience.

[0004] As a typical high-performance computing service, the XR rendering microservice differs fundamentally from traditional web services in its operational characteristics, specifically in the following ways:

[0005] 1. It has significant long-term connection characteristics, and the service resource load is strongly correlated with the number of concurrent users, rather than depending on the number of instantaneous requests;

[0006] 2. Service instances are typically in a high-load running state for a long time, and the probability of service crashes and restarts is relatively high;

[0007] 3. A proprietary performance evaluation index system should be adopted. In addition to traditional service indicators, special attention should be paid to performance parameters unique to the XR field, such as service quality jitter and motion-to-photon latency (MTP).

[0008] Existing microservice cluster capacity planning techniques primarily target stateless web service design, with the core objective of optimizing system throughput (QPS, Queries Per Second) through request queuing strategies, load balancing algorithms, and dynamic scaling mechanisms. However, these traditional methods have significant limitations when dealing with XR rendering microservice scenarios:

[0009] 1. The traditional indicator system that uses the number of requests as the benchmark for capacity assessment is incompatible with the characteristic that the number of XR service users determines resource load;

[0010] 2. No quantitative constraint model has been established for the service quality jitter problem, which cannot effectively suppress the experience fluctuations caused by service crashes;

[0011] 3. The lack of a dedicated optimization mechanism for MTP latency makes it difficult to meet the stringent end-to-end latency requirements of XR services;

[0012] 4. Failure to consider the resource coupling effect of microservice dependencies in long-lived connection states led to a discrepancy between the capacity planning results and the actual service carrying capacity.

[0013] Based on the current state of technology, there is an urgent need to propose a capacity maximization planning method specifically for XR rendering microservice clusters, in order to address the technical shortcomings of traditional technologies in areas such as service quality assurance, optimization of specific indicators, and service dependency modeling. Summary of the Invention

[0014] To address the problems existing in the background technology, this invention provides a method for maximizing the capacity planning of an XR rendering microservice cluster oriented towards service quality jitter constraints.

[0015] To achieve the above objectives, the present invention adopts the following technical solution: a method for maximizing the capacity planning of an XR rendering microservice cluster oriented towards service quality jitter constraints, the method comprising the following steps:

[0016] S1: Service performance modeling;

[0017] S101: Collect MTP latency data of XR microservices under normal conditions and construct a normal state dataset;

[0018] S102: Collect MTP latency data of XR microservices in a crash state and construct a crash state dataset;

[0019] S103: Fit the normal state dataset using a one-dimensional Gaussian distribution model to obtain the probability distribution function of MTP delay under normal conditions:

[0020] (1)

[0021] In formula (1):

[0022] Indicates a Gaussian distribution;

[0023] This represents the average MTP latency under normal conditions.

[0024] This represents the variance of the MTP delay under normal conditions;

[0025] S104: Fit the crash state dataset using a one-dimensional Gaussian distribution model to obtain the probability distribution function of MTP delay under the crash state:

[0026] (2)

[0027] In formula (2):

[0028] This represents the average MTP latency under crash conditions;

[0029] This represents the variance of MTP latency under crash conditions.

[0030] S2: Resource consumption modeling;

[0031] S201: Collect CPU consumption data of XR microservices under different numbers of users;

[0032] S202: Collect GPU consumption data of XR microservices under different numbers of users;

[0033] S203: Collect memory consumption data of XR microservices under different numbers of users;

[0034] S204: Collect GPU memory consumption data of XR microservices under different numbers of users;

[0035] S205: Preprocess the CPU consumption data, GPU consumption data, memory consumption data, and GPU memory consumption data, remove outliers, and classify them according to the number of users;

[0036] S206: Constructs separate GMMs for basic resource consumption for CPU, GPU, memory, and GPU memory, denoted as... Among them, the consumption of basic resources satisfy ;

[0037] S207: Construct a per-user incremental resource consumption GMM for CPU, GPU, memory, and GPU memory separately, denoted as... The incremental resource consumption of the i-th user satisfy ;

[0038] S208: Establish a resource consumption prediction model based on a Gaussian mixture model of basic resource consumption and incremental resource consumption per user.

[0039] (3)

[0040] In formula (3):

[0041] u represents the number of users.

[0042] S3: Service Quality Fluctuation Assessment;

[0043] S301: Based on CVaR theory, a delay risk assessment model is constructed to calculate the risk value at different confidence levels, as shown in the following formula:

[0044] (4)

[0045] In equation (4):

[0046] Indicates the confidence level;

[0047] Represents a delayed sequence;

[0048] Indicates the confidence level as Risk value at that time;

[0049] Represents the mathematical expectation;

[0050] S302: Design a sliding window mechanism to monitor service quality in real time, with the window size dynamically adjusted according to the characteristics of XR services;

[0051] S303: Adjust the sliding window according to the probability distribution function that follows the MTP delay under normal conditions. The number of samples is used to classify the samples, denoted as . Calculate the variance of this interval over an infinite time period. and probability ;

[0052] S304: Establish a service quality jitter model:

[0053] (5)

[0054] In equation (5):

[0055] Indicates a size of 0 for an infinite time period The variance of the quality sampling;

[0056] S305: Solving for service quality jitter based on the calculation results of interval variance and probability, combined with the characteristics of chi-square distribution. The variance and variance Follows a chi-square distribution and satisfies , ,and .

[0057] S4: Maximize the capacity of a single service instance;

[0058] S401: Identify the bottleneck resource on the server and determine the total amount of the bottleneck resource. ;

[0059] S402: After deployment Server of one instance Above, create an instance Collapse probability model:

[0060] (6)

[0061] In equation (5):

[0062] Indicates the probability of a crash;

[0063] S403: Calculate the effective capacity of a single instance based on the crash probability model:

[0064] (7)

[0065] S404: Calculate the crash probability using the Monte Carlo method and reuse the calculation results under different expected loads;

[0066] S405: Solve the maximum user capacity of a single microservice instance under given resource constraints using a dynamic programming algorithm.

[0067] S5: Cluster capacity linearization modeling;

[0068] S501: Define the representation server Deployment Boolean variable representing the state of each instance ;

[0069] S502: Based on Boolean variables, the problem of maximizing the capacity of an XR rendering microservice cluster is transformed into a constrained linear integer programming problem;

[0070] S503: Solve the linear integer programming problem using a general solver to obtain an optimized solution.

[0071] S6: Solution algorithm.

[0072] S601: Construct an optimized initial solution;

[0073] S60101: Calculate the number of distinct instances using dynamic programming. The maximum effective capacity of a single instance is taken as the value. ;

[0074] S60102: Assuming the number of instances per instance All values ​​are set to 1, utilizing the maximum effective capacity of a single instance. An initial allocation scheme is obtained.

[0075] S602: Based on the concept of remaining effective capacity, find another feasible solution from one feasible solution through two strategies;

[0076] The two strategies described in S602 include:

[0077] S60201: Deploy an instance that has not yet been deployed on a server, satisfying the following two conditions:

[0078] Scenario 1: The deployment reduces the remaining effective capacity of all existing services on the server, but will not cause the remaining effective capacity of any instance to become negative;

[0079] Scenario 2: In the updated remaining available capacity, the remaining available capacity of services since the new service is not less than 1.

[0080] S60202: Abandon deployment of a deployed instance on a server if either of the following two conditions is met:

[0081] Scenario 1: Deleting this instance will not cause the remaining effective capacity of this type of instance to become negative;

[0082] Scenario 2: After deleting the instance, if the server is not idle or the remaining effective capacity of the system allows for the deployment of an instance that directly contacts the user, in order to increase the remaining effective capacity of the system.

[0083] S603: Solve the linear integer programming problem by combining a greedy algorithm with local search to obtain an approximately optimal deployment scheme.

[0084] Compared with the prior art, the beneficial effects of the present invention are:

[0085] This invention uses the number of users as the core capacity assessment indicator, breaking through the limitations of traditional methods that use the number of requests as a benchmark, and more accurately matching the resource load correlation mechanism under the long-connection characteristics of XR services; it establishes a service quality jitter assessment model based on CVaR theory to achieve quantitative constraints on experience fluctuations caused by service crashes, filling the gap in the optimization of XR-specific performance indicators in existing technologies; it proposes a Gaussian mixture modeling and linearization transformation method for resource consumption, transforming the nonlinear capacity planning problem into a solvable integer linear programming model, providing a theoretical basis for maximizing cluster capacity under complex dependencies; and it designs an efficient solution algorithm combining dynamic programming and greedy strategies, significantly improving the computational efficiency of large-scale cluster capacity planning while ensuring service quality constraints, achieving optimal allocation of computing resources, and effectively solving the technical adaptation defects of traditional microservice cluster capacity planning methods in XR rendering scenarios. Attached Figure Description

[0086] Figure 1 This is a cluster diagram of the XR rendering microservice of the present invention;

[0087] Figure 2 This is a flowchart of service jitter modeling for XR rendering microservices;

[0088] Figure 3 This is a flowchart of the rapid calculation process for service jitter in XR rendering microservices;

[0089] Figure 4 This is a flowchart for quickly solving the cluster capacity maximization planning of XR rendering microservices. Detailed Implementation

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

[0091] A method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints, the method comprising the following steps:

[0092] S1: Service performance modeling;

[0093] S101: Collect MTP latency data of XR microservices under normal conditions and construct a normal state dataset;

[0094] S102: Collect MTP latency data of XR microservices in a crash state and construct a crash state dataset;

[0095] S103: Fit the normal state dataset using a one-dimensional Gaussian distribution model to obtain the probability distribution function of MTP delay under normal conditions:

[0096] (1)

[0097] In formula (1):

[0098] This represents a Gaussian distribution (normal distribution).

[0099] This represents the average MTP latency under normal conditions.

[0100] This represents the variance of the MTP delay under normal conditions;

[0101] S104: Fit the crash state dataset using a one-dimensional Gaussian distribution model to obtain the probability distribution function of MTP delay under the crash state:

[0102] (2)

[0103] In formula (2):

[0104] This represents the average MTP latency under crash conditions;

[0105] This represents the variance of MTP latency under crash conditions.

[0106] S2: Resource consumption modeling;

[0107] S201: Collect CPU consumption data of XR microservices under different numbers of users;

[0108] S202: Collect GPU consumption data of XR microservices under different numbers of users;

[0109] S203: Collect memory consumption data of XR microservices under different numbers of users;

[0110] S204: Collect GPU memory consumption data of XR microservices under different numbers of users;

[0111] S205: Preprocess the CPU consumption data, GPU consumption data, memory consumption data, and GPU memory consumption data, remove outliers, and classify them according to the number of users;

[0112] S206: Constructs separate GMMs for basic resource consumption for CPU, GPU, memory, and GPU memory, denoted as... Among them, the consumption of basic resources satisfy ;

[0113] S207: Construct a per-user incremental resource consumption GMM for CPU, GPU, memory, and GPU memory separately, denoted as... The incremental resource consumption of the i-th user satisfy ;

[0114] S208: Establish a resource consumption prediction model based on a Gaussian mixture model of basic resource consumption and incremental resource consumption per user.

[0115] (3)

[0116] In formula (3):

[0117] u represents the number of users.

[0118] S3: Service Quality Fluctuation Assessment;

[0119] S301: Based on CVaR (Conditional Risk Expectation) theory, a delay risk assessment model is constructed to calculate the risk value at different confidence levels, as shown in the following formula:

[0120] (4)

[0121] In equation (4):

[0122] Indicates the confidence level;

[0123] Represents a delayed sequence, a random variable;

[0124] Indicates the confidence level as Risk value at that time;

[0125] Represents the mathematical expectation;

[0126] S302: Design a sliding window mechanism to monitor service quality in real time, with the window size dynamically adjusted according to the characteristics of XR services;

[0127] S303: Adjust the sliding window according to the probability distribution function that follows the MTP delay under normal conditions. The number of samples is used to classify the samples, denoted as . Calculate the variance of this interval over an infinite time period. and probability ;

[0128] S304: Establish a service quality jitter model:

[0129] (5)

[0130] In equation (5):

[0131] Indicates a size of 0 for an infinite time period The variance of the quality sampling;

[0132] S305: Solving for service quality jitter based on the calculation results of interval variance and probability, combined with the characteristics of chi-square distribution. The variance and variance Follows a chi-square distribution and satisfies , ,and .

[0133] S4: Maximize the capacity of a single service instance;

[0134] S401: Analyze the server hardware resource composition to determine the bottleneck criteria for resources such as CPU, GPU, and memory; identify the bottleneck resources on the server and determine the total amount of bottleneck resources. ;

[0135] S402: Experiments show that the resource constraints of an instance are generally only related to a specific bottleneck resource, after deployment. Server of one instance Above, create an instance Collapse probability model:

[0136] (6)

[0137] In equation (5):

[0138] Indicates the probability of a crash;

[0139] S403: Calculate the effective capacity of a single instance based on the crash probability model:

[0140] (7)

[0141] S404: Calculate the crash probability using the Monte Carlo method and reuse the calculation results under different expected loads;

[0142] S405: Solve the maximum user capacity of a single microservice instance under given resource constraints using a dynamic programming algorithm.

[0143] In the optimal solution to the problem of maximizing the capacity planning of an XR rendering microservice cluster, each server Examples on Either it is not deployed, or the effective capacity of the instance has been maximized by adjusting the expected load. During this maximization process, the probability of crash can be calculated using the Monte Carlo method, and the calculation results of different expected loads can reuse part of the expected load results, so as to maximize the capacity of a single service instance in linear time.

[0144] S5: Cluster capacity linearization modeling;

[0145] S501: In the optimal solution to the problem of maximizing the capacity planning of an XR rendering microservice cluster, each server Number of instances It has an upper bound, which is defined to represent the server. Deployment Boolean variable representing the state of each instance ;

[0146] S502: Based on Boolean variables, the problem of maximizing the capacity of an XR rendering microservice cluster is transformed into a constrained linear integer programming problem;

[0147] S503: Solve the linear integer programming problem using a general solver to obtain an optimized solution.

[0148] S6: Solution algorithm.

[0149] S601: Construct an optimized initial solution;

[0150] S60101: Calculate the number of distinct instances using dynamic programming. The maximum effective capacity of a single instance is taken as the value. ;

[0151] S60102: Assuming the number of instances per instance All values ​​are set to 1, utilizing the maximum effective capacity of a single instance. An initial allocation scheme is obtained.

[0152] S602: Based on the concept of remaining effective capacity, find another feasible solution from one feasible solution through two strategies;

[0153] The remaining effective capacity is the remaining value obtained by subtracting the number of instances of the ith service from the effective capacity of the (i+1)th service. This value is non-negative in the valid solution to ensure the correctness of service dependencies.

[0154] The two strategies described in S602 include:

[0155] S60201: Deploy an instance that has not yet been deployed on a server, satisfying the following two conditions:

[0156] Scenario 1: The deployment reduces the remaining effective capacity of all existing services on the server, but will not cause the remaining effective capacity of any instance to become negative;

[0157] Scenario 2: In the updated remaining available capacity, the remaining available capacity of services since the new service is not less than 1.

[0158] S60202: Abandon deployment of a deployed instance on a server if either of the following two conditions is met:

[0159] Scenario 1: Deleting this instance will not cause the remaining effective capacity of this type of instance to become negative;

[0160] Scenario 2: After deleting the instance, if the server is not idle or the remaining effective capacity of the system allows for the deployment of an instance that directly contacts the user, in order to increase the remaining effective capacity of the system.

[0161] S603: Solve the linear integer programming problem by combining a greedy algorithm with local search to obtain an approximately optimal deployment scheme.

[0162] This invention is applicable to XR rendering microservice cluster environments. By establishing a service quality jitter model and MTP latency constraints, and using the number of users as a capacity assessment metric, it maximizes cluster capacity by adjusting the deployment of various instances on each cluster node and the expected load of each instance. Expected instance load refers to the number of long-lived connections expected to be established by a specific type of instance on a given node. For real-time rendering services, this is equivalent to the number of users; for other services, it is the number of downstream services that can be connected.

[0163] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0164] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A capacity maximization planning method for XR rendering microservice clusters under service quality jitter constraints, characterized in that: The method includes the following steps: S1: Service performance modeling; S2: Resource consumption modeling; S3: Service Quality Fluctuation Assessment; S4: Maximize the capacity of a single service instance; S5: Cluster capacity linearization modeling; S6: Solution algorithm.

2. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints as described in claim 1, characterized in that: S1 includes the following steps: S101: Collect MTP latency data of XR microservices under normal conditions and construct a normal state dataset; S102: Collect MTP latency data of XR microservices in a crash state and construct a crash state dataset; S103: Fit the normal state dataset using a one-dimensional Gaussian distribution model to obtain the probability distribution function of MTP delay under normal conditions: (1) In formula (1): Indicates a Gaussian distribution; This represents the average MTP latency under normal conditions. This represents the variance of the MTP delay under normal conditions; S104: Fit the crash state dataset using a one-dimensional Gaussian distribution model to obtain the probability distribution function of MTP delay under the crash state: (2) In formula (2): This represents the average MTP latency under crash conditions; This represents the variance of MTP latency under crash conditions.

3. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints according to claim 2, characterized in that: S2 includes the following steps: S201: Collect CPU consumption data of XR microservices under different numbers of users; S202: Collect GPU consumption data of XR microservices under different numbers of users; S203: Collect memory consumption data of XR microservices under different numbers of users; S204: Collect GPU memory consumption data of XR microservices under different numbers of users; S205: Preprocess the CPU consumption data, GPU consumption data, memory consumption data, and GPU memory consumption data, remove outliers, and classify them according to the number of users; S206: Constructs separate GMMs for basic resource consumption for CPU, GPU, memory, and GPU memory, denoted as... Among them, the consumption of basic resources satisfy ; S207: Construct a per-user incremental resource consumption GMM for CPU, GPU, memory, and GPU memory separately, denoted as... The incremental resource consumption of the i-th user satisfy ; S208: Establish a resource consumption prediction model based on a Gaussian mixture model of basic resource consumption and incremental resource consumption per user. (3) In formula (3): u represents the number of users.

4. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints according to claim 3, characterized in that: S3 includes the following steps: S301: Based on CVaR theory, a delay risk assessment model is constructed to calculate the risk value at different confidence levels, as shown in the following formula: (4) In equation (4): Indicates the confidence level; Represents a delayed sequence; Indicates the confidence level as Risk value at that time; Represents the mathematical expectation; S302: Design a sliding window mechanism to monitor service quality in real time, with the window size dynamically adjusted according to the characteristics of XR services; S303: Adjust the sliding window according to the probability distribution function that follows the MTP delay under normal conditions. The number of samples is used to classify the samples, denoted as . Calculate the variance of this interval over an infinite time period. and probability ; S304: Establish a service quality jitter model: (5) In equation (5): Indicates a size of 0 for an infinite time period The variance of the quality sampling; S305: Solving for service quality jitter based on the calculation results of interval variance and probability, combined with the characteristics of chi-square distribution. The variance and variance Follows a chi-square distribution and satisfies , ,and .

5. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints according to claim 4, characterized in that: S4 includes the following steps: S401: Identify the bottleneck resource on the server and determine the total amount of the bottleneck resource. ; S402: After deployment Server of one instance Above, create an instance Collapse probability model: (6) In equation (5): Indicates the probability of a crash; S403: Calculate the effective capacity of a single instance based on the crash probability model: (7) S404: Calculate the crash probability using the Monte Carlo method and reuse the calculation results under different expected loads; S405: Solve the maximum user capacity of a single microservice instance under given resource constraints using a dynamic programming algorithm.

6. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints according to claim 5, characterized in that: S5 includes the following steps: S501: Define the representation server Deployment Boolean variable representing the state of each instance ; S502: Based on Boolean variables, the problem of maximizing the capacity of an XR rendering microservice cluster is transformed into a constrained linear integer programming problem; S503: Solve the linear integer programming problem using a general solver to obtain an optimized solution.

7. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints as described in claim 6, characterized in that: S6 includes the following steps: S601: Construct an optimized initial solution; S602: Based on the remaining effective capacity, find another feasible solution from one feasible solution using two strategies; S603: Solve the linear integer programming problem by combining a greedy algorithm with local search to obtain an approximately optimal deployment scheme.

8. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints according to claim 7, characterized in that: S601 includes the following steps: S60101: Calculate the number of distinct instances using dynamic programming. The maximum effective capacity of a single instance is taken as the value. ; S60102: Assuming the number of instances per instance All values ​​are set to 1, utilizing the maximum effective capacity of a single instance. An initial allocation scheme is obtained.

9. The method for maximizing the capacity planning of an XR rendering microservice cluster under service quality jitter constraints as described in claim 8, characterized in that: The two strategies described in S602 include: S60201: Deploy an instance that has not yet been deployed on a server, satisfying the following two conditions: Scenario 1: The deployment reduces the remaining effective capacity of all existing services on the server, but will not cause the remaining effective capacity of any instance to become negative; Scenario 2: In the updated remaining available capacity, the remaining available capacity of services since the new service is not less than 1; S60202: Abandon deployment of a deployed instance on a server if either of the following two conditions is met: Scenario 1: Deleting this instance will not cause the remaining effective capacity of this type of instance to become negative; Scenario 2: After deleting the instance, if the server is not idle or the remaining effective capacity of the system allows for the deployment of an instance that directly contacts the user, in order to increase the remaining effective capacity of the system.

Images