Network service elastic scheduling method based on cloud native architecture

Abstract

This invention discloses a network service elastic scheduling method based on cloud-native architecture, relating to the field of cloud-native service scheduling technology. Specifically, it includes: acquiring request records of the target network service and generating request path labels; establishing path operation readiness records in each software running unit according to the request path labels; calculating path operation readiness based on path baseline records; acquiring a target path demand table containing predicted request volumes for each request path label; calculating the effective processing capacity of the path during the target time period based on theoretical request processing capacity, target time period length, and path operation readiness; determining the path gap set accordingly; generating a path-oriented pre-preparation probe sequence during expansion; gradually connecting real traffic according to the path routing weight table after the path operation readiness reaches the path admission threshold; and identifying and protecting the bearer units of scarce coverage paths during shrinkage, then determining the target shrinkage unit from the remaining running units.

Description

Technical Field

[0001] This invention relates to the field of cloud-native service scheduling technology, and more specifically to a method for elastic scheduling of network services based on cloud-native architecture. Background Technology

[0002] In cloud-native architectures, network services are typically provided by multiple software runtime units. These software runtime units can be container groups, virtual machine instances, service process groups, or business execution instances managed uniformly by a cloud-native resource scheduling platform. Existing network service elastic scheduling methods typically determine the number of units to scale up or down based on CPU utilization, memory utilization, request rate, number of concurrent requests, average response time, or historical traffic predictions, and create, add, or delete software runtime units through the resource scheduling platform.

[0003] In specific business systems, the same software execution unit often simultaneously handles multiple request paths. In the order service of an online transaction system, a single order service instance can process both regular user order query requests and merchant batch reconciliation requests. If an order service instance primarily processes regular user order query requests for a period of time, the cached content, processing steps, and dependent connections required for that request path may already be ready for operation. However, since merchant batch reconciliation requests are accessed less frequently, their required cached content, processing steps, and dependent connections may not yet be ready for operation. In this case, although the order service instance appears available through the readiness probe and at the overall level, its actual processing capacity for merchant batch reconciliation requests may still be lower than in a fully prepared state. When a concentrated number of merchant batch reconciliation requests arrive within a target time period, existing overall replica scaling methods may overestimate the instance's processing capacity for that request path, leading to increased response times or failure rates for merchant batch reconciliation requests.

[0004] Furthermore, existing fixed probe requests typically cover health checks, status queries, or a few fixed pre-preparation interfaces, making it difficult to guarantee consistency with the actual request paths during the target period. If the fixed probe covers user query paths, while the actual traffic during the target period is concentrated on merchant batch reconciliation, batch transfers, or flash sale order requests, then even if a new software running unit uses fixed probes, it may not have completed the runtime preparation for the target request paths. Simultaneously, during the scaling-down phase, existing methods typically select objects to be recycled based on overall load, overall capacity contribution, or the number of replicas. Some software running units, despite having low overall load, may be among the few that have already completed runtime preparation for low-frequency critical request paths. Directly recycling such software running units may result in insufficient remaining effective processing capacity for that request path after scaling down, leading to a decline in the service quality of that specific request path.

[0005] Therefore, there is an urgent need for a network service elastic scheduling method based on cloud-native architecture to solve the problems in existing technologies, such as the difficulty in estimating the overall capacity of software running units to reflect the differences in the operational readiness of different request paths, the difficulty in matching the actual request paths during the target time period with the pre-preparation of fixed probes, and the lack of scarce path protection during scaling down. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the present invention aims to provide a method for elastic scheduling of network services based on cloud-native architecture.

[0007] To achieve the above objectives, the present invention provides the following technical solution: S1: Generate request path labels based on the request records of the target network service; establish path operation preparation records in each software operation unit of the target network service according to the request path labels; calculate the path operation preparation degree of each software operation unit under each request path label based on the path operation preparation records and the path baseline records corresponding to the request path labels. S2: Based on the path readiness, adjust the theoretical request processing capacity of each software running unit under each request path label to obtain the effective processing capacity of the path; based on the target path demand table and the effective processing capacity of the path for the target time period, calculate the target number of software running units that can meet the processing requirements of each request path for the target time period. S3: If the target number is greater than the number of real-time running units within the target network service, or if there is a capacity gap for any requested path label in the target path requirement table, then construct a path gap set; generate a path orientation pre-preparation probe sequence based on the path gap set, and update the path operation preparation record; calculate the path operation preparation degree of the new software running unit for the requested path label in the path gap set. S4: Recalculate the effective processing capacity of the path based on the updated path readiness, increment the actual traffic weight of the new software running unit for the requested path label in the path routing weight table, or keep the path routing weight table in a prohibited access state, mirrored access state, or low-weight access state. S5: If the target number is less than the number of real-time running units, then determine the scarce coverage path based on the real-time running units; determine the target shrinkage unit based on the scarce coverage path, and reclaim the target shrinkage unit.

[0008] Furthermore, the step of generating request path tags based on the request records of the target network service includes: extracting service entry field, business interface identifier, request method field, business operation field, and resource object field from the request records; performing format normalization processing on the extracted fields; and concatenating the normalized fields in a preset order, or performing hash processing on the concatenation result to obtain the request path tags.

[0009] Furthermore, the path baseline record is obtained through the following process: before the target network service performs elastic scheduling or within a low-load maintenance window, a representative request corresponding to the request path label is selected; a representative request is sent to the target network service and running data is collected within multiple preset sampling windows; when the fluctuation range of the cache hit rate, processing step readiness rate, dependency connection reuse rate, and path response time statistics within multiple consecutive sampling windows is less than the corresponding preset fluctuation threshold, the data within the consecutive sampling windows is determined as the path baseline record for the corresponding request path label.

[0010] Further, the path gap set is determined as follows: the predicted request volume of each request path label in the target time period is compared with the sum of the effective processing capacity of all real-time running units under that request path label in the target time period; the request path labels whose sum of effective processing capacity is lower than the corresponding predicted request volume are determined as request path labels with insufficient capacity; and the request path labels with insufficient capacity are combined into a path gap set.

[0011] Furthermore, the step of generating a path-oriented pre-prepared probe sequence based on the path gap set includes: reading the capacity insufficiency reason corresponding to the requested path label in the path gap set; matching the probe template corresponding to the requested path label in the probe template table; adjusting the request parameters of the probe request in the probe template according to the capacity insufficiency reason; and combining the probe requests into a path-oriented pre-prepared probe sequence according to the execution order based on the adjusted request parameters.

[0012] Furthermore, the probe request includes a read-only request, an idempotent request, a sandbox account request, or a transaction rollback request.

[0013] Furthermore, the recalculation of the effective processing capacity of the path based on the updated path readiness needs to meet the following condition: the path readiness of the newly added software running unit for at least one requested path label in the path gap set reaches the path admission threshold corresponding to that requested path label.

[0014] Furthermore, determining scarce coverage paths based on real-time running units includes: traversing the request path tags in the target path requirement table; counting the number of real-time running units under each request path tag whose path operation readiness reaches the corresponding path admission threshold; determining a preset retention quantity based on the service level requirements and business criticality of the request path tag; and determining the request path tag as a scarce coverage path when the counted number of real-time running units is less than or equal to the preset retention quantity.

[0015] Further, determining the target scaling-down unit includes: identifying real-time operating units that carry scarce coverage paths and whose path operation readiness reaches the path admission threshold as protection units; excluding protection units from the real-time operating units to obtain the remaining real-time operating units, calculating the sum of the effective path processing capacity of each remaining real-time operating unit under each request path label; selecting the real-time operating unit with the smallest sum of effective path processing capacity as a candidate scaling-down unit; simulating the removal of candidate scaling-down units to determine the target scaling-down unit.

[0016] Furthermore, reclaiming the target scaling unit includes: stopping the allocation of new real requests to the target scaling unit; waiting for the target scaling unit to complete the processing of existing requests or reach a preset waiting time; recording the request path label, path readiness, and effective processing capacity corresponding to the target scaling unit; clearing the local non-persistent business data in the target scaling unit; and updating the path routing weight table and the running unit status.

[0017] Compared with the prior art, the present invention has the following beneficial effects: 1. The present invention establishes a path operation preparation record according to the request path, and calculates the effective processing capacity of the software operation unit corresponding to the request path within the target time period based on the path operation preparation degree, which can reduce the capacity estimation deviation caused by equating the overall readiness state of the software operation unit with the processing capacity of each request path.

[0018] 2. This invention generates a path-oriented pre-preparation probe sequence based on the path gap set, enabling newly added software running units to prioritize completing the cache access, processing steps execution, and dependency connection establishment required for request paths with insufficient capacity. This reduces the risk of newly added software running units prematurely accepting real traffic for unprepared request paths. By increasing the weight of real traffic according to the request path through the path routing weight table, request paths that have reached the path admission threshold are given priority for traffic access, while request paths that have not reached the path admission threshold continue to be blocked from access, mirrored access, or low-weight access. This reduces the risk of newly added software running units being subjected to overall traffic access before some request paths are fully prepared.

[0019] 3. This invention identifies scarce coverage paths during the scaling-down phase and protects real-time operating units that carry scarce coverage paths and have reached the path admission threshold, thereby reducing the risk of insufficient effective processing capacity for specific request paths after scaling-down. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the elastic scheduling method for network services based on cloud-native architecture. Figure 2 A flowchart illustrating the process of determining the set of path gaps; Figure 3 A flowchart illustrating the process of determining scarce coverage paths based on real-time operating units. Detailed Implementation

[0021] Example 1: Refer to Figures 1 to 3 A network service elastic scheduling method based on cloud-native architecture includes: This embodiment provides a method for elastic scheduling of network services based on a cloud-native architecture. This method can be applied to online transaction systems, order services, payment services, reconciliation services, interface aggregation services, or other network services running through a cloud-native resource scheduling platform.

[0022] In this embodiment, the target network service consists of multiple software execution units. Each software execution unit includes at least a business process, a request recording component, a path execution preparation recording component, and a runtime data acquisition component. The target network service provides a unified service entry point to the outside world through a service gateway, load balancing component, or service mesh.

[0023] In this embodiment, the scheduling system is a control system used to execute the elastic scheduling logic of this application. It can be deployed as a controller, service mesh control component, gateway scheduling component, automatic scaling controller in a cloud-native resource scheduling platform, or a combination of the above components.

[0024] In this embodiment, the request path tag is an identifier generated based on fields in the request record that can distinguish the business processing path. The request path tag is generated from at least the service entry field, business interface identifier, request method field, business operation field, and resource object field.

[0025] S1: Generate request path labels based on the request records of the target network service; establish path operation preparation records in each software operation unit of the target network service according to the request path labels; calculate the path operation preparation degree of each software operation unit under each request path label based on the path operation preparation records and the path baseline records corresponding to the request path labels.

[0026] Request records for the target network service can be generated by service gateways, business process tracking points, call chain tracing components, or log collection components. Request records must include at least the service entry field, business interface identifier, request method field, business operation field, and resource object field.

[0027] The Service Entry field indicates the entry point for a request to access the target network service; the Business Interface Identifier indicates the business interface accessed by the request; the Request Method field indicates the request method; the Business Operation field indicates the operation action identified within the business system; and the Resource Object field indicates the type of business object processed by the request.

[0028] The above fields are extracted from the request record, and their format is normalized. Format normalization may include removing invalid spaces, standardizing case, standardizing path separators, removing random parameters that do not affect the business processing path, and merging resource object fields by type. After normalization, the scheduling system concatenates the fields in a preset order, or hashes the concatenated result to obtain the request path label.

[0029] In one implementation, if the request record also includes a tenant type field, a batch processing flag field, a database access group number, or an external service call group number, the scheduling system determines whether the supplementary fields will affect cache access, processing step execution, or dependent calls of the request path. If they will, the supplementary fields are incorporated into the generation field set of the request path tag; if they will not, the supplementary fields are saved as associated attributes of the request path tag. The tenant type field is used to distinguish between ordinary users, merchants, institutional customers, etc.; the batch processing flag field is used to distinguish between single requests and batch requests; the database access group number is used to indicate a set of database access statements mainly triggered by the request; and the external service call group number is used to indicate a set of external dependent services mainly called by the request.

[0030] After generating request path labels, each software execution unit establishes a path execution preparation record according to the request path labels. The request records are grouped according to a preset sampling window. Within each sampling window, the total number of cache accesses, cache hits, total number of path processing steps, number of prepared path processing steps, total number of dependency calls, number of reused connection calls, and path response time statistics for each request path label are statistically analyzed. The statistical results are then associated with the software execution unit identifier, request path label, and sampling window identifier to form a path execution preparation record. The path execution preparation record includes the total number of cache accesses, cache hits, total number of path processing steps, number of prepared path processing steps, total number of dependency calls, number of reused connection calls, and the path response time statistics within the current sampling window.

[0031] The total number of cache accesses represents the number of times the cache is accessed when processing the corresponding request path, and the number of cache hits represents the number of times the cache is accessed and a hit occurs. The total number of path processing steps represents the number of core processing functions involved in processing the request path, and the number of prepared path processing steps represents the number of core processing functions that have completed loading, runtime compilation optimization, configuration rule initialization, or access permission initialization. The total number of dependency calls represents the total number of times the database, cache, middleware, or external services are called when processing the corresponding request path, and the number of reused connection calls represents the number of times the above dependency calls are completed using established connections or connections from the connection pool. The path response time statistics can be average response time, percentile response time, or maximum response time.

[0032] In this embodiment, the sampling window is a preset statistical interval for the scheduling system to perform grouped statistics on the target network service operation data. The sampling window can be a time window or a request quantity window. The time window can be 30 seconds, 1 minute, or 5 minutes, and the request quantity window can be a statistical window formed after the cumulative number of requests reaches a preset number.

[0033] To further illustrate the process of establishing the path execution preparation record, the following explanation uses the order service in an online transaction system as an example. The order service is deployed using multiple container groups, each serving as a software execution unit. The order service includes at least the user's ordinary order query request path, the merchant's batch reconciliation request path, and the promotional activity order placement request path.

[0034] For a user's regular order query request, the service entry field can be "order-service", the business interface identifier can be " / order / query", the request method field can be "POST", the business operation field can be "queryNormalOrder", and the resource object field can be "normalOrder". The scheduling system generates the regular order query request path label accordingly. For a merchant's batch reconciliation request, the service entry field can be "order-service", the business interface identifier can be " / order / reconcile", the request method field can be "POST", the business operation field can be "batchReconcile", and the resource object field can be "merchantBill". The scheduling system generates the merchant's batch reconciliation request path label accordingly.

[0035] Within a sampling window, if software execution unit A processes 1000 ordinary order query requests, including 1000 accesses to the local order cache with 920 cache hits, then the total number of cache accesses for the ordinary order query request path within software execution unit A is 1000, and the number of cache hits is 920. If the request path includes five path processing steps: parameter parsing, user permission verification, order cache reading, order status transition, and response result assembly, and all five path processing steps have been loaded, initialized, or optimized at runtime, then the total number of path processing steps is 5, and the number of prepared path processing steps is 5. If the request path calls the database, cache service, or user service 300 times within the sampling window, with 270 of these calls using established connections or connections from the connection pool, then the total number of dependent calls is 300, and the number of reused connection calls is 270. The scheduling system further calculates the average response time, percentile response time, or maximum response time for this request path within the sampling window as the path response time statistics.

[0036] If, within the same sampling window, software unit A processes only 3 merchant batch reconciliation requests, and this request path involves processing steps such as reconciliation rule loading, merchant bill reading, historical order detail reading, reconciliation difference calculation, and result generation, and only reconciliation rule loading and merchant bill reading have been initialized, then the total number of path processing steps for this request path can be recorded as 5, and the number of prepared path processing steps can be recorded as 2. If this request path accesses the cache 10 times and only hits it 2 times, and calls the bill service, order detail service, and reconciliation rule service a total of 15 times, with only 3 of those calls using a reused connection, then the scheduling system will form a path execution preparation record for software unit A for the merchant batch reconciliation request path. Therefore, although the same software unit is generally in an available state, its path execution preparation records for different request paths can have significant differences.

[0037] The scheduling system associates and saves the above statistical results with the software execution unit identifier, request path label, and sampling window identifier. For example, the path execution preparation record may include: software execution unit identifier "pod-A", request path label "order-service+ / order / reconcile+POST+batchReconcile+merchantBill", sampling window identifier "window-20260519-2100", total number of cache accesses, number of cache hits, total number of path processing steps, number of prepared path processing steps, total number of dependency calls, number of reused connection calls, and path response time statistics. The character "+" is only used to distinguish different fields in the request path label and does not represent mathematical operations.

[0038] For each request path, the scheduling system pre-establishes a path baseline record. This record can be established before the target network service performs elastic scheduling, or it can be established within a low-load maintenance window. During the establishment process, the scheduling system selects representative requests corresponding to the request path label, sends a preset number of representative requests to the target network service, and collects runtime data within multiple sampling windows. When the fluctuation range of the cache hit rate, processing step readiness rate, dependency connection reuse rate, and path response time statistics within multiple consecutive sampling windows is less than the corresponding preset fluctuation threshold, the data within that consecutive sampling window is determined as the path baseline record for the corresponding request path label.

[0039] Cache hit rate refers to the ratio between the number of cache hits and the total number of cache accesses when a software execution unit processes a request corresponding to a specific request path tag within a preset sampling window. The total number of cache accesses represents the total number of times the software execution unit accesses the local cache, application-layer cache, distributed cache, or other cache components used to accelerate business processing during the processing of requests under the corresponding request path tag. The number of cache hits represents the number of times the target data or intermediate result is directly retrieved from the cache without needing to be retrieved again from the source data service, database, or external dependent services.

[0040] In this embodiment, a representative request refers to a sample request that can trigger the main processing logic, main cache access objects, and main dependent call objects of the corresponding request path. For example, for a normal order query request path, a representative request may include query requests for different order statuses, different order time ranges, and different tenant types to trigger processing logic such as order cache reading, order status transition, and user permission verification.

[0041] After the path baseline record is established, the path readiness degree is calculated based on the path preparation record and the path baseline record. Let the software execution unit be u, the requested path label be r, and the current sampling window be w.

[0042] Within the current sampling window, the current cache hit rate is calculated using the following formula: in, This represents the current cache hit rate. This represents the number of cache hits in the current sampling window. This represents the total number of cache accesses in the current sampling window.

[0043] The current processing step's readiness rate is calculated using the following formula: in, For the current processing step's readiness rate, The number of steps to process the prepared path. This represents the total number of path processing steps.

[0044] The current dependency connection reuse rate is calculated using the following formula: in, The current dependency connection reuse rate, To reuse connection calls, This represents the total number of dependency calls.

[0045] The current path response time statistics are recorded as follows: .

[0046] In one embodiment, the baseline cache hit rate, baseline dependency connection reuse rate, and baseline response time statistics are all derived from historical stable sampling windows of the request path label in a fully prepared state. When establishing a path baseline record, the scheduling system sends representative requests to the corresponding request path or collects real requests for the request path during normal business operation. When the fluctuation range of the cache hit rate, processing step readiness rate, dependency connection reuse rate, and path response time statistics is less than a preset fluctuation threshold within multiple consecutive sampling windows, and the error rate is lower than a preset error rate threshold, the request path is considered to have entered a fully prepared state on the software running unit or a similar software running unit.

[0047] The cache hit rate during the stable phase is used as the baseline cache hit rate, and the dependency connection reuse rate is used as the baseline dependency connection reuse rate. The path response time is used as the baseline response time. The baseline cache hit rate, baseline processing step readiness rate, baseline dependency connection reuse rate, and baseline response time corresponding to the request path tag r are respectively denoted as: , , , .

[0048] Further calculations are performed on the cache readiness value, processing step readiness value, dependency connection readiness value, and response time stability value. The cache readiness value is calculated using the formula: The processing steps and preparation values ​​are calculated using the following formula: Dependency join readiness values ​​are calculated using the following formula: The stable value of the response time is calculated using the following formula: , To prevent extremely small positive numbers with a denominator of 0.

[0049] When the denominator of a certain indicator is non-existent or zero, the corresponding readiness value is marked as an invalid readiness value. When the total number of samples of real requests and probe requests in the current sampling window is lower than the preset minimum number of samples, the path readiness is marked as low confidence, or the path readiness is reduced according to the ratio of the number of samples to the preset minimum number of samples. The lowest value is selected from the above valid readiness values, and combined with the low confidence processing result, the path readiness is obtained, which is between 0 and 1.

[0050] In this embodiment, the current processing step readiness rate represents the degree of readiness of a software running unit for a specific request path tag within the current sampling window. It is determined based on the correspondence between the number of prepared path processing steps and the total number of path processing steps. For example, a merchant batch reconciliation request path includes seven path processing steps: request parameter verification, merchant permission verification, reconciliation rule loading, bill detail reading, historical order detail reading, difference calculation, and result assembly. If the current software running unit only completes the initialization or runtime optimization of four steps—request parameter verification, merchant permission verification, reconciliation rule loading, and bill detail reading—then the total number of path processing steps for this request path in that software running unit is seven, and the number of prepared path processing steps is four. The scheduling system determines the current processing step readiness rate accordingly.

[0051] For a specific request path, if any of the following—caching, processing functions, dependency connections, or response time—is not ready to stably handle requests, the actual processing capacity of that request path will be limited. Therefore, path readiness reflects the bottleneck readiness of the software runtime unit for that request path.

[0052] S2: Based on the path readiness, adjust the theoretical request processing capacity of each software running unit under each request path label to obtain the effective processing capacity of the path; based on the target path demand table and the effective processing capacity of the path for the target time period, calculate the target number of software running units that can meet the processing requirements of each request path for the target time period.

[0053] The target path requirement table includes the request path label, the predicted request volume for the target time period, the request percentage for the target time period, and the length of the target time period. The predicted request volume for the target time period represents the number of requests expected to arrive at the target network service within the target time period and belong to the corresponding request path label. For example, if the scheduled task table shows that 600 merchants' batch reconciliation tasks need to be executed from 21:00 to 21:10, and each merchant is expected to generate 2 reconciliation requests, then the original predicted request volume for this request path label within the target time period is 1200 requests. If some of these merchants are large merchants, and their single reconciliation requests involve a large number of order details, the reconciliation requests of different sizes can be converted and summarized according to the standard request equivalent to obtain the predicted request volume within the target time period.

[0054] The target path demand table can be generated based on at least one of the following: historical request logs, scheduled task tables, activity configuration tables, tenant access plans, and real-time request growth trends. Specifically, after reading the above data sources, the scheduling system summarizes the number of requests expected to arrive within the target time period according to the request path labels. When different requests under the same request path label have different parameter scales or resource consumption, the scheduling system converts the number of requests into the standard request equivalent number according to a preset equivalent coefficient. Finally, the request path label, predicted request volume, request percentage, and target time period length are written into the target path demand table.

[0055] In this embodiment, historical request logs refer to request data recorded by the service gateway, business process, call chain tracing component, or log collection component during historical operation. Scheduled task table refers to planned task data recorded in the business system or task scheduling platform. Activity configuration table refers to activity plan data recorded in the business activity management system. Tenant access plan table refers to access plan data pre-submitted by tenants, merchants, institutional customers, or internal business systems. Real-time request growth trend refers to short-term trend data obtained by the scheduling system based on changes in the number of requests, request growth rate, request path proportion, or response time within recent sampling windows.

[0056] Standard request equivalents are used to represent the relative consumption of processing resources by different requests. The scheduling system can determine the request equivalent coefficient based on request parameter size, historical average processing time, historical CPU usage time, database access count, or external dependency call count. After determining the request equivalent coefficient, the number of requests of each type within the target time period is multiplied by the corresponding request equivalent coefficient, and the multiplication results are summarized according to the request path label to obtain the predicted request volume for that request path label within the target time period. For example, for merchant batch reconciliation requests, if a request with a batch size of 100 records is defined as 1 standard request equivalent, then a request with a batch size of 500 records can be converted into 5 standard request equivalents. In this way, even if the request parameter sizes are different under the same request path label, the measurement standards on the demand and supply sides can be kept consistent.

[0057] In this embodiment, the request parameter scale refers to the size of parameters or the scope of business objects that affect processing resource consumption in a single request. For example, in a merchant batch reconciliation request, "reconciliation batch size," "accounting period range," and "number of merchant identifiers" are request parameter scales; in an order query request, "number of page entries," "query time range," and "number of order statuses" are request parameter scales.

[0058] In this embodiment, the number of various requests refers to the number of different request categories obtained by further dividing them under the same request path label according to request parameter size, tenant type, batch processing flag, resource consumption level, or dependent call group number. For example, for the merchant batch reconciliation request path, requests can be divided into small batch requests, medium batch requests, and large batch requests according to the reconciliation batch size; for the order query request path, requests can be divided into short time range query requests and long time range query requests according to the query time range; for the batch transfer request path, requests can be divided into low number of transfer batch requests and high number of transfer batch requests according to the number of transfers.

[0059] The request equivalent factor is used to represent the resource consumption multiple of a certain type of request relative to a baseline type of request. For example, in a merchant batch reconciliation request path, a reconciliation request with a batch size of 100 records is taken as the baseline type of request, and its request equivalent factor is set to 1. If historical records show that the average processing time for a reconciliation request with a batch size of 500 records is approximately 4.5 times that of the baseline type of request, the number of database accesses is approximately 5 times that of the baseline type of request, and the number of external dependency calls is approximately 4 times that of the baseline type of request, then the scheduling system can determine the request equivalent factor for a reconciliation request with a batch size of 500 records to be a value between 4.5 and 5 based on the above indicators.

[0060] Obtain the theoretical request processing capacity of each software execution unit under each request path label. The acquisition process includes: obtaining the historical processing records of the software execution unit in a fully prepared state under the corresponding request path label; selecting stable sampling windows that meet the error rate threshold and response time threshold from the historical processing records; and determining the theoretical request processing capacity of the software execution unit under the corresponding request path label based on the number of requests or standard request equivalents completed within the stable sampling window and the duration of the sampling window.

[0061] The effective processing capacity of a path is calculated based on the theoretical request processing capacity, the target time period length, and the path operation readiness. This includes: obtaining the theoretical request processing capacity of the software running unit when it is fully prepared under the corresponding request path label; obtaining the target time period length, and reducing the number of processable requests generated by the theoretical request processing capacity within the target time period according to the path operation readiness to obtain the effective processing capacity of the software running unit for the request path label within the target time period.

[0062] In one implementation, the effective processing capacity of the path is determined according to the following formula: in Represents the software execution unit During the target period Internal targeting of request path tags Effective processing capacity of the path Represents the software execution unit For request path tags Theoretical request processing capacity Indicates the target time period Duration Represents the software execution unit For request path tags The readiness of the path operation.

[0063] Theoretical request processing capacity is the number of requests or standard request equivalents that can be processed per unit of time; effective path processing capacity is the number of requests or standard request equivalents that can be processed within a target time period. Effective path processing capacity is used to compare with the predicted request volume for the target time period; both are quantitative concepts.

[0064] For example, a certain order service instance has a path readiness of 0.92 for a user's regular order query request path and a path readiness of 0.38 for a merchant's batch reconciliation request path. If the target time period is 10 minutes long, and the theoretical request processing capacity of this instance for the merchant batch reconciliation request path is 100 standard request equivalents per minute, then the effective processing capacity of this instance for the merchant batch reconciliation request path within the target time period is 100 × 10 × 0.38, or 380 standard request equivalents. This value represents the number of processes that this instance can contribute to this request path within the target time period.

[0065] In this embodiment, both the predicted request volume and the effective processing capacity of the path for the target time period are expressed quantitatively. The predicted request volume for the target time period represents the number of requests or standard request equivalents that need to be processed within the target time period; the effective processing capacity of the path represents the number of requests or standard request equivalents that the software execution unit can process for the corresponding request path label within the target time period. The theoretical request processing capacity is only used as an intermediate parameter for calculating the effective processing capacity of the path. Therefore, this embodiment does not directly compare the request rate with the processing capacity, but rather compares the predicted request volume with the effective processing capacity of the path within the same request path label and the same target time period.

[0066] Based on the target path demand table and the effective processing capacity of each software running unit, calculate the target number of software running units that can meet the processing requirements of each request path during the target time period. For each request path label in the target path demand table, calculate the sum of the effective processing capacities of all real-time running units under that request path label; if the sum of capacities is lower than the predicted request volume for the target time period corresponding to that request path label, it indicates that there is a capacity gap for that request path.

[0067] In one implementation, the capacity gap corresponding to the request path label is determined according to the following formula: ) in, Indicates the request path tag During the target period The corresponding capacity gap inside, This indicates the request path label in the target path requirement table. During the target period Predicted request volume within, Represents the software execution unit During the target period Internal targeting of request path tags Effective processing capacity of the path Represents all real-time operating units During the target period Internal targeting of request path tags The sum of the effective processing capacity of the paths.

[0068] The number of new software running units needed is determined based on the capacity gap of each request path, and the target number of software running units is obtained. When at least one capacity gap exists, the effective processing capacity of candidate new software running units under each request path label is obtained. Candidate new software running units are added one by one, and the effective processing capacity of new software running units for each request path label is accumulated. When the capacity gap of each request path label is covered by the accumulated effective processing capacity, the sum of the real-time running unit number and the accumulated number of new software running units is determined as the target number of software running units.

[0069] If there are multiple specifications or different initialization states for the candidate new software running units, the candidate new software running unit that can reduce the remaining capacity gap the most is selected first, and the above accumulation process is repeated until the capacity gap of all request path tags is covered.

[0070] S3: If the target number is greater than the number of real-time running units within the target network service, or if there is a capacity gap for any requested path label in the target path requirement table, then construct a path gap set; generate a path orientation pre-preparation probe sequence based on the path gap set, and update the path operation preparation record; calculate the path operation readiness degree of the new software running unit for the requested path label in the path gap set.

[0071] If the target number of software running units is greater than the number of real-time running units within the target network service, or if the predicted request volume corresponding to at least one request path label in the target path demand table is greater than the sum of the effective processing capacity of all real-time running units under that request path label within the target time period, then the request path label with insufficient capacity will be added to the path gap set.

[0072] Specifically, the predicted request volume of each request path label in the target time period is compared with the sum of the effective processing capacity of all real-time running units under that request path label in the target time period; request path labels whose sum of effective processing capacity is lower than the corresponding predicted request volume are identified as request path labels with insufficient capacity; and request path labels with insufficient capacity are grouped into a path gap set.

[0073] Each request path tag in the path gap set corresponds to at least one reason for insufficient capacity. For example, a merchant batch reconciliation request path may enter the path gap set because the number of software running units that have reached the path admission threshold is insufficient; a flash sale order request path may enter the path gap set because the predicted request volume for the target period is rapidly increasing; and a batch transfer request path may enter the path gap set because the current path response time is not stable enough.

[0074] The scheduling system generates a path-oriented pre-prepared probe sequence based on the path gap set. The generation process includes: reading the capacity insufficiency reason corresponding to the requested path label in the path gap set; matching the probe template corresponding to the requested path label in the probe template table; adjusting the request parameters of the probe template, such as the parameter value range, number of probes, probe order, and probe injection frequency, according to the capacity insufficiency reason; configuring a data isolation flag for the probe request, enabling the probe request to be processed as read-only, idempotent, sandboxed, or transaction rollback; and combining the adjusted probe requests in execution order into a path-oriented pre-prepared probe sequence.

[0075] In this embodiment, the reason for insufficient capacity is the specific reason why a certain request path label enters the path gap set. The reason for insufficient capacity can be determined based on the path operation readiness components of each software running unit under the request path label. If the cache readiness value is lower than the preset cache readiness threshold, the reason for insufficient capacity includes insufficient cache readiness; if the processing step readiness value is lower than the preset processing step readiness threshold, the reason for insufficient capacity includes insufficient path processing step readiness, etc.

[0076] The parameter value range refers to the range of request parameters in a probe request that can affect the request processing path, cached access objects, dependent call objects, or resource consumption. For example, the parameter value range for a merchant batch reconciliation request path may include the merchant identifier set, payment period range, reconciliation batch size, and bill type; the parameter value range for an order query request path may include order status, query time range, number of pages, and tenant type.

[0077] The probe order refers to the execution sequence of different probe requests within the path-oriented pre-prepared probe sequence. Probe requests are arranged from light to heavy, from read-only to rollbackable, and from cached access to full path processing. For example, for a merchant batch reconciliation request path, the merchant permission read probe and reconciliation rule read probe can be executed first, followed by the bill detail read probe, then the historical order detail read probe, and finally the reconciliation difference simulation calculation probe. The probe injection frequency refers to the frequency at which probe requests are sent to the new software execution unit per unit of time.

[0078] Read-only processing means that probe requests only perform query, read, validation, or cache loading operations, and do not perform operations to add, delete, modify, or submit business status. Idempotent processing means that even if probe requests are executed repeatedly, they will not cause repeated or irreversible changes to the business status. Sandbox account processing means that probe requests are executed using isolated test tenants, sandbox merchants, or virtual accounts, and the data generated is isolated from real production business data. Transaction rollback processing means that probe requests are executed within database transactions, business transactions, or compensation transactions, and after completing path processing steps, cache access, and dependency calls, the temporary write results are rolled back, without retaining the actual changes to the business status.

[0079] For example, regarding the merchant batch reconciliation request path, when the main reason for insufficient capacity is inadequate cache preparation, the scheduling system can expand the merchant identifier set and billing period range in the probe template, increase the number of probes for reading bill details, and set the probe order to read merchant basic information first, then bill summary, and then order details. When the main reason for insufficient capacity is insufficient reuse of dependent connections, the scheduling system can increase the proportion of probe requests calling the bill service, order detail service, and reconciliation rule service, and continuously inject them at a lower frequency to encourage newly added software units to establish and reuse relevant connections. When the main reason for insufficient capacity is insufficient preparation of path processing steps, the scheduling system can add a complete reconciliation process simulation probe and execute it through sandbox account processing or transaction rollback processing to trigger reconciliation rule loading, difference calculation logic initialization, and result assembly logic optimization.

[0080] In this embodiment, the probe template table is a data table used by the scheduling system to generate path-oriented pre-prepared probe sequences. The probe template table stores probe templates corresponding to request path tags. Each probe template describes the request entry point, request method, business operation, resource object, parameter range, and data isolation method required when executing a pre-prepared probe request for the corresponding request path. Each probe template includes at least the request path tag, service entry point field, business interface identifier, request method field, business operation field, resource object field, parameter value range, data isolation identifier, probe type, execution order, probe injection frequency, and probe result collection field.

[0081] For example, for a merchant batch reconciliation request path, the probe template may include the service entry field "order-service", the business interface identifier " / order / reconcile", the request method field "POST", the business operation field "batchReconcile", the resource object field "merchantBill", the parameter value range "merchant identifier set, billing period range, reconciliation batch size", and the data isolation identifier "sandbox account processing" or "transaction rollback processing".

[0082] The path-oriented pre-preparation probe sequence is used to trigger the new software runtime unit to access the cache, execute path processing steps, and make dependency calls for the corresponding request path. Probe requests can be read-only requests, idempotent requests, sandbox account requests, or transaction rollback requests. For probe requests with write risk, the new software runtime unit will send the request to a sandbox account, read-only copy, or isolated transaction for processing based on the data isolation identifier, or roll back the temporary state after processing, thereby avoiding changes to the actual business data.

[0083] After injecting the path orientation pre-preparation probe sequence into the new software execution unit, the new software execution unit updates its path execution preparation record. The scheduling system then recalculates the path execution preparation degree of the new software execution unit for the requested path labels in the path gap set based on the updated path execution preparation record.

[0084] If the path readiness of a newly added software running unit for a specific request path label does not increase within a consecutive preset sampling window, or if the increase is less than a preset range, the scheduling system adjusts the path-oriented pre-preparation probe sequence corresponding to that request path label. Adjustment methods include expanding the parameter value range, increasing the proportion of dependency call probes, increasing the proportion of cache access probes, increasing the proportion of path processing step trigger probes, or increasing the injection frequency of probe requests corresponding to that request path label.

[0085] For example, if the cache readiness value of the merchant batch reconciliation request path has not increased for a long time, the scope of merchant accounts or billing periods covered by the probe can be expanded; if the dependency connection readiness value has not increased for a long time, the proportion of probes related to reconciliation rules service, billing service and order details service can be increased; if the processing step readiness value has not increased for a long time, the injection frequency of probes triggered by the core processing steps of batch reconciliation can be increased.

[0086] S4: Recalculate the effective processing capacity of the path based on the updated path readiness, increment the actual traffic weight of the new software running unit for the requested path label in the path routing weight table, or keep the path in a prohibited access state, mirrored access state, or low-weight access state in the path routing weight table.

[0087] When the path readiness of a new software running unit for at least one requested path label in the path gap set reaches the path admission threshold corresponding to that requested path label, the scheduling system performs capacity recalibration based on the updated effective processing capacity of the path and increments the actual traffic weight of the new software running unit for that requested path label in the path routing weight table.

[0088] Path admission thresholds can be set separately for each request path. Higher thresholds can be set for request paths that are sensitive to response time or have high failure costs; lower thresholds can be set for ordinary query request paths. Path admission thresholds can be determined based on at least one of the following: service level requirements corresponding to the request path label, business criticality, or anomaly occurrences in historical operation records.

[0089] Service level requirements may include at least one of the following: target response time, allowable error rate, timeout threshold, availability requirements, maximum queuing time, and degradation strategy. For example, the target response time and allowable error rate requirements for a payment confirmation request path are typically higher than those for a regular order query request path; therefore, a higher path admission threshold can be configured for the payment confirmation request path.

[0090] Business criticality can be categorized into three levels: high, medium, and low, or it can be represented by a numerical level. For example, request paths such as payment confirmation, batch transfers, and order creation belong to high business criticality; while request paths such as ordinary order list queries and product browsing may belong to medium-low business criticality. Abnormal occurrences in historical operation records refer to anomalies recorded within the historical sampling window for the corresponding request path tags, such as timeouts, error responses, retries, circuit breakers, rate limiting, dependency call failures, decreased path readiness, or sudden increases in response time.

[0091] For example, the basic path admission threshold for ordinary query request paths can be set to 0.75; if the business criticality of the request path is high, the path admission threshold can be increased to 0.85; if the request path has a high number of historical anomalies or has experienced concentrated timeouts due to insufficient warm-up, it can be further increased to 0.90. For request paths that are not sensitive to response time, can be retried after failure, and have low business criticality, a lower path admission threshold can be set; for request paths such as fund transactions, batch transfers, payment confirmation, and merchant reconciliation, a higher path admission threshold can be set.

[0092] The path routing weight table includes request path labels, software execution unit identifiers, and actual traffic weights. When accessing actual traffic, the scheduling system reads the current actual traffic weight of the software execution unit to be added for the corresponding request path label from the path routing weight table. When the path readiness reaches the path access threshold, the current actual traffic weight is increased from a prohibited access state or a low-weight access state to the first weight. In subsequent sampling windows, path readiness records, path response time, and error rate are continuously collected. If the path readiness does not decrease and the path response time and error rate do not exceed the corresponding thresholds, the actual traffic weight continues to increase according to a preset weight step size. If the path readiness decreases, the path response time exceeds the threshold, or the error rate exceeds the threshold, the actual traffic weight of the corresponding request path label is rolled back. The actual traffic weight refers to the weight value in the path routing weight table used to control the allocation ratio of actual user requests.

[0093] For example, for a normal order query request path, the actual traffic weights of software running units A, B, and C are 40, 40, and 20, respectively. Then, the scheduling system can allocate approximately 40% of normal order query requests to software running unit A, approximately 40% to software running unit B, and approximately 20% to software running unit C.

[0094] For request path tags whose operational readiness has not reached the corresponding path admission threshold, the scheduling system maintains a prohibited access status, a mirrored access status, or a low-weight access status in the path routing weight table. Therefore, the same new software operating unit can gradually accept request paths that have met the admission criteria, while continuing to restrict request paths that have not yet met the admission criteria.

[0095] For example, a service instance awaiting new orders may have a path readiness score of 0.90 for the user's regular order query request path, exceeding the path's admission threshold of 0.80; however, its path readiness score for the merchant's batch reconciliation request path is only 0.50, below the path's admission threshold of 0.85. In this case, the scheduling system can increase the actual traffic weight of this instance for the user's regular order query request path in the path routing weight table, but still prohibit or reduce the access of actual traffic for the merchant's batch reconciliation request path.

[0096] During the process of increasing the actual traffic weight, the scheduling system continuously collects the path preparation records under the corresponding request path label. If a request path experiences a decrease in path preparation, a path response time exceeding a threshold, or an error rate exceeding a threshold after the actual traffic weight is increased, the scheduling system will roll back the actual traffic weight corresponding to that request path label, without having to remove the entire software running unit to be added.

[0097] For example, once the path readiness of newly added software running unit D for merchant batch reconciliation request paths reaches 0.90, exceeding the path admission threshold of 0.85, the scheduling system can first set its actual traffic weight under that request path label to 5. After one sampling window, if the path response time and error rate are stable, the actual traffic weight is increased to 10; after another sampling window, it is further increased to 20. If, after increasing to 20, the response time exceeds the threshold or the path readiness decreases, the scheduling system will roll back the actual traffic weight of software running unit D under that request path label to 10 or set it to a low-weight state. For other request path labels for which this software running unit has not yet reached the path admission threshold, the scheduling system will maintain the states of prohibited access, mirrored access, or low-weight access.

[0098] S5: If the target number is less than the number of real-time running units, then determine the scarce coverage path based on the real-time running units; determine the target shrinkage unit based on the scarce coverage path, and reclaim the target shrinkage unit.

[0099] If the target number of software running units is less than the number of real-time running units within the target network service, the scheduling system triggers a scaling-down process. First, scarce coverage paths are identified. By traversing the request path tags in the target path requirement table, the number of real-time running units under each request path tag that have reached the corresponding path admission threshold is counted. A preset retention quantity is determined based on the service level requirements and business criticality of the request path tag. When the counted number of real-time running units is less than or equal to the preset retention quantity, the request path tag is identified as a scarce coverage path.

[0100] The preset retention quantity can be set according to the business criticality and service level requirements of the request path. The higher the service level requirements, the higher the business criticality, the more historical anomalies, or the more concentrated the predicted request volume in the target period, the larger the preset retention quantity for the corresponding request path tag. For example, for a critical transaction path, the preset retention quantity can be set to 3; for a normal query path, the preset retention quantity can be set to 1.

[0101] Real-time operating units that carry scarce coverage paths and whose path operation readiness reaches the path access threshold are identified as protection units. Protection units are still real-time operating units, but they do not enter the target shrinkage unit.

[0102] For the remaining real-time running units, the scheduling system determines the target shrinkage unit based on the effective processing capacity of the path. In one implementation, the scheduling system calculates the sum of the effective processing capacity of each remaining real-time running unit under each request path label; selects candidate shrinkage units in ascending order of the sum of the effective processing capacity of the path; simulates the removal of candidate shrinkage units, and recalculates the sum of the effective processing capacity of the remaining real-time running units under each request path label.

[0103] If, after simulating the removal of candidate scaling units, the sum of the effective processing capacities of the remaining paths corresponding to each request path label is not less than the predicted request volume of the corresponding request path label in the target path demand table, then the candidate scaling unit is determined as the target scaling unit. If, after simulating the removal of candidate scaling units, the sum of the effective processing capacities of the remaining paths corresponding to any request path label is less than the predicted request volume of the corresponding request path label in the target path demand table, then the scaling qualification of the candidate scaling unit is cancelled, and the next candidate scaling unit is examined.

[0104] Reclaiming a target scaling unit includes: stopping the allocation of new real requests to the target scaling unit; waiting for existing requests to be processed by the target scaling unit; recording the request path label and path readiness level corresponding to the target scaling unit; clearing local non-persistent business data in the target scaling unit; and updating the routing status of the target scaling unit. Local non-persistent business data refers to temporary business-related data stored only in the local memory, local temporary directory, local cache, or local runtime context of a specific software runtime unit.

[0105] Through the above methods, this embodiment can avoid accidentally deleting software running units carrying scarce coverage paths during the scaling-down phase, while prioritizing the recovery of running units that contribute less to the effective capacity of each requested path.

[0106] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for elastic scheduling of network services based on cloud-native architecture, characterized in that, include: S1: Generate request path tags based on the request records of the target network service; In each software operation unit of the target network service, establish a path operation preparation record according to the request path label; Based on the path preparation record and the path baseline record corresponding to the requested path label, calculate the path preparation degree of each software operation unit under each requested path label. S2: Based on the path readiness, the theoretical request processing capacity of each software running unit under each request path label is corrected to obtain the effective processing capacity of the path; Based on the target path demand table and the effective processing capacity of the path during the target time period, calculate the target number of software running units that can meet the processing requirements of each request path during the target time period. S3: If the target number is greater than the number of real-time running units within the target network service, or if there is a capacity gap for any requested path label in the target path requirement table, then construct a path gap set; generate a path orientation pre-preparation probe sequence based on the path gap set, and update the path operation preparation record; calculate the path operation preparation degree of the new software running unit for the requested path label in the path gap set. S4: Recalculate the effective processing capacity of the path based on the updated path readiness, increment the actual traffic weight of the new software running unit for the requested path label in the path routing weight table, or keep the path routing weight table in a prohibited access state, mirrored access state, or low-weight access state. S5: If the number of targets is less than the number of real-time running units, then the scarce coverage path is determined based on the real-time running units; Target shrinkage units are determined based on scarce coverage paths, and then the target shrinkage units are recycled.

2. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The step of generating request path tags based on the request records of the target network service includes: extracting service entry field, business interface identifier, request method field, business operation field, and resource object field from the request records; performing format normalization processing on the extracted fields; and concatenating the normalized fields in a preset order, or performing hash processing on the concatenation result to obtain the request path tags.

3. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The path baseline record is obtained through the following process: before the target network service performs elastic scheduling or within a low-load maintenance window, a representative request corresponding to the request path label is selected; a representative request is sent to the target network service and running data is collected within multiple preset sampling windows; when the fluctuation range of the cache hit rate, processing step readiness rate, dependency connection reuse rate, and path response time statistics within multiple consecutive sampling windows is less than the corresponding preset fluctuation threshold, the data within the consecutive sampling windows is determined as the path baseline record for the corresponding request path label.

4. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The path gap set is determined by comparing the predicted request volume of each request path label within the target time period with the sum of the effective processing capacity of all real-time running units under that request path label within the target time period. Request path labels whose sum of effective processing capacity is lower than the corresponding predicted request volume are identified as request path labels with insufficient capacity; request path labels with insufficient capacity are grouped into a path gap set.

5. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The step of generating a path-oriented pre-prepared probe sequence based on the path gap set includes: reading the capacity insufficiency reason corresponding to the requested path label in the path gap set; matching the probe template corresponding to the requested path label in the probe template table; adjusting the request parameters of the probe request in the probe template according to the capacity insufficiency reason; and combining the probe requests into a path-oriented pre-prepared probe sequence according to the execution order based on the adjusted request parameters.

6. The network service elastic scheduling method based on cloud-native architecture according to claim 5, characterized in that, The probe requests include read-only requests, idempotent requests, sandbox account requests, or transaction rollback requests.

7. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The recalculation of the effective processing capacity of the path based on the updated path readiness requires the following condition to be met: the path readiness of the newly added software running unit for at least one requested path label in the path gap set reaches the path admission threshold corresponding to that requested path label.

8. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The process of determining scarce coverage paths based on real-time running units includes: traversing the request path tags in the target path requirement table; counting the number of real-time running units under each request path tag whose path operation readiness has reached the corresponding path admission threshold; determining a preset retention quantity based on the service level requirements and business criticality of the request path tag; and determining the request path tag as a scarce coverage path when the counted number of real-time running units is less than or equal to the preset retention quantity.

9. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, The process of determining the target scaling-down unit includes: identifying real-time operating units that carry scarce coverage paths and whose path operation readiness reaches the path admission threshold as protection units; excluding protection units from the real-time operating units to obtain the remaining real-time operating units, and calculating the sum of the effective path processing capacity of each remaining real-time operating unit under each request path label; selecting the real-time operating unit with the smallest sum of effective path processing capacity as a candidate scaling-down unit; and simulating the removal of candidate scaling-down units to determine the target scaling-down unit.

10. The network service elastic scheduling method based on cloud-native architecture according to claim 1, characterized in that, Reclaiming the target scaling unit includes: stopping the allocation of new real requests to the target scaling unit; waiting for the target scaling unit to complete the processing of existing requests or reach a preset waiting time; recording the request path label, path readiness, and effective processing capacity of the target scaling unit; clearing the local non-persistent business data in the target scaling unit; and updating the path routing weight table and the running unit status of the target scaling unit.

Images