Calculation network cooperation differentiation resource guarantee system based on service types

Abstract

The invention provides a computing network collaborative differentiated resource guarantee system based on a service type, and the system comprises a service type recognition module which is configured to perform service type recognition according to at least one service request, and obtain a target service type and / or a normalized service portrait corresponding to the service request; the differentiated resource strategy generation module is configured to generate a target unified strategy according to the target service type and / or the normalized service portrait, and the target unified strategy comprises computing power resource parameters and network resource parameters corresponding to the service request; and the computing network joint admission module is configured to judge whether the service request is admitted to a target resource domain or not according to the target unified strategy. Through the system, the problems of low resource management efficiency and lack of uniformity for differentiated services in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing resource management, container resource orchestration, and data center network service quality assurance, and particularly to a differentiated resource assurance system for cloud computing network collaboration based on business type. Background Technology

[0002] With the widespread adoption of cloud-native and microservice architectures, concurrent services running on the same infrastructure exhibit significant heterogeneity: some services require strict throughput or latency determinism, some are latency-sensitive but tolerate some jitter and burst sharing, and others operate on a best-effort basis with a higher tolerance for performance fluctuations. Existing resource management technologies typically have the following shortcomings: The disconnect between computing power and network: resource access and guarantee strategies are often configured independently in computing scheduling and network QoS, lacking a unified end-to-end consistency check, leading to problems such as "sufficient computing power but network congestion" or "network guarantee but insufficient computing power".

[0003] Lack of automatic semantic-to-policy mapping: When submitting, businesses can usually only provide general resource requests or a few metrics, making it difficult to automatically deduce their resource guarantee semantics (reservation / minimum guarantee / maximum guarantee) and form an executable policy.

[0004] Limited granularity of protection: It only supports reservation or quota, and cannot simultaneously express the three-layer semantics of "must be available for startup", "must be available for operation", and "can only be used at most", thus making it difficult to achieve a balance between isolation and utilization.

[0005] Inconsistent handling of admission failures: When admission fails, there is usually a lack of standardized candidate solution output and processing procedures, requiring repeated manual adjustments on the business side, which affects delivery efficiency and system stability. Summary of the Invention

[0006] This application provides a network-based collaborative differentiated resource guarantee system based on business type to solve the problems of low efficiency and lack of uniformity in resource management for differentiated businesses in existing technologies.

[0007] The system includes: A business type identification module is configured to identify the business type based on at least one business request, and obtain the target business type and / or normalized business profile corresponding to the business request. A differentiated resource strategy generation module is configured to generate a target unified strategy based on the target service type and / or the normalized service profile. The target unified strategy includes computing resource parameters and network resource parameters corresponding to the service request. The computing network joint access module is configured to determine whether the service request should be admitted to the target resource domain based on the target unified policy.

[0008] Preferably, the service types include deterministic services, latency-sensitive services, and best-effort services; The business type identification module is also configured as follows: The business type is determined based on the business parameters to obtain the target business type of the business request and / or the normalized business profile; the business parameters include business scenario information, whether service interruption is allowed, whether latency jitter is allowed, and / or business criticality information.

[0009] Preferably, the service type identification module is further configured as follows: Determine whether the critical business information is not less than 1, whether the service interruption information is indicated as no, and whether the latency jitter information is indicated as no; if yes, mark the business type of the business request as the deterministic service. Determine whether the business scenario information belongs to a strongly deterministic scenario set, whether the service interruption information is allowed, and whether the latency jitter information is allowed; if so, mark the business type of the business request as the deterministic service.

[0010] Preferably, the service type identification module is further configured as follows: Determine whether the information on whether service interruption is allowed is negative and whether the information on whether latency jitter is allowed is negative; if yes, mark the service type of the service request as the latency-sensitive service. Determine whether the business scenario information belongs to the interactive online scenario set and whether the information on whether service interruption is allowed is indicated as no; if yes, mark the business type of the business request as the latency-sensitive service. Determine whether the criticality information of the business is not less than 2 and whether the information on whether service interruption is allowed is indicated as no; if yes, mark the business type of the business request as the latency-sensitive service.

[0011] Preferably, the service type identification module is further configured as follows: When the service request does not meet the requirements of the latency-sensitive service and the deterministic service, the service type of the service request is marked as the best-effort service.

[0012] Preferably, the computing power resource parameters include computing power reservation parameters, computing power upper limit parameters, and computing power lower limit parameters; the network resource parameters include network reservation parameters, network upper limit parameters, and network lower limit parameters.

[0013] Preferably, the differentiated resource strategy generation module is further configured to: When the service type of the service request is the deterministic service, a first target unified strategy is generated; the first target unified strategy includes setting the computing power reservation parameter to be greater than 0, setting the computing power reservation parameter, the computing power upper limit parameter and the computing power lower limit parameter to be equal, setting the network reservation parameter to be greater than 0, and setting the network reservation parameter, the network upper limit parameter and the network lower limit parameter to be equal. The network joint admission module is also configured as follows: When the service type of the service request is the deterministic service, determine whether the available remaining computing power and network resources in the target resource domain of the service request are greater than the computing power reservation parameter and the network reservation parameter; if so, the service request is admitted to the target resource domain.

[0014] Preferably, the differentiated resource strategy generation module is further configured to: When the service type of the service request is the latency-sensitive service, a second target unified strategy is generated; the second target unified strategy includes setting the computing power reservation parameter to 0, setting the computing power upper limit parameter to be no less than the computing power lower limit parameter, setting the computing power lower limit parameter to be greater than 0, setting the network reservation parameter to 0, setting the network upper limit parameter to be no less than the network lower limit parameter, and setting the network lower limit parameter to be greater than 0; The network joint admission module is also configured as follows: When the service type of the service request is the deterministic service, determine whether the available remaining computing power and network capacity in the target resource domain of the service request are greater than the lower limit parameter of computing power and the lower limit parameter of network capacity; if so, the service request is admitted to the target resource domain.

[0015] Preferably, the differentiated resource strategy generation module is further configured to: When the service type of the service request is the best-effort service, a third objective unified strategy is generated; the third objective unified strategy includes setting the computing power reservation parameter, the network reservation parameter, the computing power lower limit parameter, and the network lower limit parameter to 0.

[0016] Preferably, the computer network joint admission module is further configured as follows: When the service request fails to be admitted to the target resource domain, the service request is queued until the resources of the target resource domain are available, the service type of the service request is downgraded and the target unified policy is regenerated, or the service request is canceled.

[0017] As described above, this application provides a network-computer collaborative differentiated resource guarantee system based on service type. The system includes a service type identification module configured to identify the service type based on at least one service request, obtaining a target service type and / or a normalized service profile corresponding to the service request; a differentiated resource policy generation module configured to generate a target unified policy based on the target service type and / or the normalized service profile, the target unified policy including computing resource parameters and network resource parameters corresponding to the service request; and a network-computer joint access module configured to determine whether the service request is allowed access to the target resource domain based on the target unified policy. This application solves the problems of low efficiency and lack of uniformity in resource management for differentiated services in existing technologies through the above system. Attached Figure Description

[0018] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a network-based collaborative differentiated resource guarantee system based on business type, as proposed in this application. Detailed Implementation

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

[0021] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0022] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0023] With the continuous evolution of cloud computing technology, cloud-native architecture has become an important paradigm for modern software construction and deployment. Its core features include containerized encapsulation and microservice design, which decouple complex monolithic applications into multiple independent, modular, and lightweight microservice nodes. This effectively reduces dependencies between modules and significantly improves the concurrency and robustness of system development. Microservice architecture, by dividing applications into a series of small, independent services, allows each service to be deployed and scaled independently. Combined with containerization technology, it enables agile resource iteration, on-demand allocation, and elastic scaling, and is being increasingly accepted by various industries.

[0024] Against this backdrop, concurrent services running on the same infrastructure exhibit significant heterogeneity. Different services have distinct resource requirements and performance goals: some critical services (such as real-time transactions and streaming media services) require strict throughput or latency determinism; some services (such as interactive web applications) are latency-sensitive but tolerate some jitter and bursts of sharing; and many background jobs (such as data analysis and report generation) are best-effort type services with a high tolerance for performance fluctuations. This heterogeneity leads to significant differences in the resource requirements of microservice applications, including CPU-sensitive services as well as memory-sensitive or I / O-sensitive services, resulting in uneven resource utilization.

[0025] A prominent problem in current resource management technologies is the fragmented management of computing power and network resources. Resource access and guarantee strategies are often configured independently in computing scheduling and network QoS, lacking a unified end-to-end consistency verification mechanism. This fragmentation often leads to the dilemma of "sufficient computing power but network congestion" or "network guarantee but insufficient computing power".

[0026] In real-world scenarios, microservice architectures typically comprise multiple services of different types, each with varying resource requirements and characteristics. Due to the loose coupling and fine-grained nature of microservices, a single task execution (such as an e-commerce transaction) may require the participation of hundreds or even thousands of microservice units. The collaborative and competitive relationships among these massive numbers of nodes, including serial, parallel, and remote calls, inevitably impact the overall service quality of the task. Most existing resource management methods employ a distributed architecture, where each microservice node independently requests resources from the resource pool that can accommodate its own latency, without considering the performance of other nodes and lacking consideration for the overall QoS of the task.

[0027] Another significant drawback of existing resource management technologies is the lack of automatic mapping capabilities from business semantics to resource policies. When submitting requests, businesses typically only provide general resource requests or a few performance metrics, making it difficult for the system to automatically deduce their resource guarantee semantics (such as reservation / minimum guarantee / maximum guarantee) and formulate executable policies.

[0028] This problem is particularly pronounced in hybrid multi-cloud environments. The number, complexity, and data volume of enterprise business systems are increasing exponentially, making it difficult to meet the growing demands for system and data interaction, agile innovative applications, and data sharing through traditional deployment and integration models. In the past, most enterprises' infrastructure management and application management were disconnected, failing to provide consistent and one-stop management capabilities. As business operations and applications expand into a multi-cloud hybrid state, infrastructure architecture capabilities need to continuously evolve to support innovation anywhere.

[0029] Current resource management technologies only support relatively simple guarantee granularity and cannot simultaneously express complex resource demand semantics. Most systems only support simple strategies such as reservation or quotas, making it difficult to express the three-layer resource semantics of "must be available at startup," "must be available to run," and "can only be used at most," thus making it difficult to achieve a balance between isolation and resource utilization.

[0030] In a microservice architecture, improving overall system efficiency and meeting end-to-end QoS requirements hinges on effective resource scheduling and management across container nodes. However, the complex interactions between microservice nodes further complicate resource management. Because the load on microservice applications often fluctuates dynamically, different services may experience peaks or troughs in request volume at different times and under different environments. This uncertainty makes it difficult to accurately predict resource demands in a short period, thus impacting the formulation of optimal resource adjustment strategies.

[0031] Existing resource management technologies lack a unified standard for handling access failures. When resource requests cannot be fulfilled, the system typically lacks standardized candidate solution outputs and processing procedures, requiring repeated manual adjustments on the business side, which severely impacts delivery efficiency and system stability.

[0032] In practice, enterprise users face challenges such as high transmission costs, difficulties in resource integration and collaboration, and challenges in cross-vendor interoperability of equipment. To achieve efficient cross-regional allocation of computing resources and accurately schedule computing demands to appropriate resource nodes, not only is a "network" necessary, but also "computing power." If there is "computing power without a network," computing power will become isolated; if there is a "network without computing power," the network will also be ineffective. Currently, although the national government is promoting the construction of computing power networks, within metropolitan areas, the "last mile" network between computing centers and end users still suffers from bottlenecks such as high latency, inflexible bandwidth, and unstable performance, hindering the efficient utilization of computing resources.

[0033] Based on the above problems, this application provides the following implementation method.

[0034] Figure 1 This is a schematic diagram of a network-based collaborative differentiated resource guarantee system based on business type, as proposed in this application.

[0035] See Figure 1 As can be seen, this embodiment provides a differentiated resource guarantee system for computing network collaboration based on service type, the system including: A business type identification module is configured to identify the business type based on at least one business request, and obtain the target business type and / or normalized business profile corresponding to the business request.

[0036] Specifically, in this embodiment, the service type identification module receives service requests from the service orchestration system or users, automatically determines the target service type based on the service semantics input by the user, and classifies the services into: deterministic services, latency-sensitive services, and best-effort services.

[0037] For example, input: Required fields: scenario: business scenario, allow_stall: whether service pauses are allowed, allow_jitter: whether latency jitter is allowed, criticality: business criticality (high / medium / low or numerical level).

[0038] Optional fields: User suggestions: limit on computing resources (cpu_limit_user), limit on network resources (bw_limit_user), etc.

[0039] Output: biz_type: Service type (deterministic service, latency-sensitive service, best-effort service) biz_profile: Normalized business profile (optional).

[0040] The system also includes: A differentiated resource strategy generation module is configured to generate a target unified strategy based on the target service type and / or the normalized service profile. The target unified strategy includes computing resource parameters and network resource parameters corresponding to the service request.

[0041] Specifically, in this embodiment, the differentiated resource policy generation module is used to map service level and service profile to a unified policy, including computing resource parameters and network resource parameters. The computing resource parameters include at least CPU computing power reservation parameters, minimum guaranteed CPU computing power parameters, and maximum CPU computing power parameters. The network resource parameters include at least bandwidth reservation parameters, minimum guaranteed bandwidth parameters, maximum bandwidth parameters, and queue or QoS parameters.

[0042] For example, input: biz_type: Business type; biz_profile: Normalized business profile.

[0043] Output: res_conf: Resource policy computing power side (CPU reservation parameters, minimum guaranteed CPU parameters, maximum CPU parameters), network side (bandwidth reservation parameters, minimum guaranteed bandwidth parameters, maximum bandwidth parameters).

[0044] The differentiated resource strategy generation module has the following functions for different business types: The criteria for determining whether a service is a deterministic service are as follows: The service type identification module determines whether the service critical information is not less than 1, whether the service interruption information is indicated as no, and whether the latency jitter information is indicated as no; if so, the service type of the service request is marked as the deterministic service. The business type identification module determines whether the business scenario information belongs to a strongly deterministic scenario set, whether the service interruption information is allowed, and whether the latency jitter information is allowed; if so, the business type of the business request is marked as the deterministic service.

[0045] For example: A: Deterministic service determination: A1: criticality ≥ threshold 1, and allow_stall = no, allow_jitter = no.

[0046] A2: scenario∈strong deterministic scenario set, and allow_stall=no, allow_jitter=no.

[0047] In this case, either A1 or A2 can be used to mark a business request as a deterministic service.

[0048] The criteria for determining whether a service type is a latency-sensitive service are as follows: The service type identification module determines whether the information on whether service interruption is allowed is negative and whether the information on whether latency jitter is allowed is negative; if so, the service type of the service request is marked as the latency-sensitive service. The business type identification module determines whether the business scenario information belongs to the interactive online scenario set and whether the service interruption information is indicated as no; if yes, the business type of the business request is marked as the latency-sensitive service. The service type identification module determines whether the service criticality information is not less than 2 and whether the service interruption information is indicated as no; if so, the service type of the service request is marked as the latency-sensitive service.

[0049] For example: B: Determination of latency-sensitive services: B1: allow_stall = No, allow_jitter = Yes.

[0050] B2: scenario∈Interactive online scenario set, and allow_stall=No.

[0051] B3: criticality ≥ threshold 2, and allow_stall = no.

[0052] Among them, meeting B1, B2, or B3 can mark a service request as a latency-sensitive service.

[0053] The criteria for determining whether a service type is a best-effort service are as follows: When the service request does not meet the requirements of the latency-sensitive service and the deterministic service, the service type identification module marks the service type of the service request as the best-effort service.

[0054] For example: C: Best-effort service judgment (default): C1: Other cases.

[0055] Among them, all cases that do not satisfy A and B are categorized as C, which is the best effort service.

[0056] The system also includes: The computing network joint access module is configured to determine whether the service request should be admitted to the target resource domain based on the target unified policy.

[0057] Specifically, in this embodiment, the computing and network joint admission module performs joint admission verification of computing power and network based on resource policies and configures resource protection, and executes unified business processing logic when admission fails.

[0058] Access successful: Triggers the collaborative distribution of resource guarantee configurations by the computing power side and the network side and starts the service.

[0059] The resource strategy is abstracted into three types of parameters: reservation (locking), lower limit (minimum guarantee), and upper limit (maximum usage).

[0060] (1) Reserved: refers to the amount of resources that must be verified and locked during the admission phase. If the requirement is not met, the system cannot be started; if the requirement is met, the resources are locked. On the computing power side, it is the number of cores or equivalent quota (cpu_reserved), and on the network side, it is the amount of locked bandwidth (bw_reserved).

[0061] (2) Lower limit: refers to the minimum resource limit provided for the service during the operation phase. No resource locking is performed. It provides a "minimum amount" lower limit guarantee and allows burst sharing within the upper limit. On the computing power side, it is the minimum CPU quota lower limit (cpu_guarantee), and on the network side, it is the bandwidth lower limit (bw_guarantee).

[0062] (3) Upper limit: refers to the maximum amount of resources that a service can use. It provides an upper limit on "how much can be used at most" to isolate and control bursts and prevent uncontrollable interference to other services. On the computing power side, it is the CPU quota limit (cpu_limit), and on the network side, it is the bandwidth limit (bw_limit).

[0063] The strategy for the deterministic service type is generated as follows: When the service type of the service request is the deterministic service, a first target unified strategy is generated through the differentiated resource strategy generation module; the first target unified strategy includes setting the computing power reservation parameter to be greater than 0, setting the computing power reservation parameter, the computing power upper limit parameter, and the computing power lower limit parameter to be equal, setting the network reservation parameter to be greater than 0, and setting the network reservation parameter, the network upper limit parameter, and the network lower limit parameter to be equal. When the service type of the service request is the deterministic service, the computing and network joint admission module determines whether the available remaining computing power and network resources in the target resource domain of the service request are greater than the computing power reservation parameter and the network reservation parameter; if so, the service request is admitted to the target resource domain.

[0064] For example: Deterministic services: Computing power constraints: cpu_reserved>0; cpu_guarantee=cpu_reserved; cpu_limit=cpu_reserved.

[0065] Network-side constraints: bw_reserved>0; bw_guarantee=bw_reserved; bw_limit=bw_reserved.

[0066] Joint Admission Requirements: It must be ensured that the remaining amount within the target resource domain is greater than cpu_reserved and bw_reserved.

[0067] The strategy for the service type, which is a latency-sensitive service, is generated as follows: When the service type of the service request is the latency-sensitive service, a second target unified strategy is generated through the differentiated resource strategy generation module; the second target unified strategy includes setting the computing power reservation parameter to 0, setting the computing power upper limit parameter to be no less than the computing power lower limit parameter, setting the computing power lower limit parameter to be greater than 0, setting the network reservation parameter to 0, setting the network upper limit parameter to be no less than the network lower limit parameter, and setting the network lower limit parameter to be greater than 0; When the service type of the service request is the deterministic service, the computing and network joint admission module determines whether the computing power and the guaranteed remaining amount of the network in the target resource domain of the service request are greater than the lower limit parameter of computing power and the lower limit parameter of the network; if so, the service request is admitted to the target resource domain.

[0068] For example: Latency-sensitive services: Computing power constraints: cpu_reserved=0; cpu_limit≥cpu_guarantee; cpu_guarantee>0.

[0069] Network-side constraints: bw_reserved=0; bw_limit≥bw_guarantee; bw_guarantee>0.

[0070] Joint Admission Requirements: It must be ensured that the remaining amount within the target resource domain is greater than cpu_guarantee and bw_guarantee.

[0071] The business type is generated as follows using a best-effort service strategy: When the service type of the service request is the best-effort service, a third target unified strategy is generated through the differentiated resource strategy generation module; the third target unified strategy includes setting the computing power reservation parameter, the network reservation parameter, the computing power lower limit parameter, and the network lower limit parameter to 0.

[0072] For example: Do your best to serve Computing power constraints: cpu_reserved=0; cpu_limit (optional); cpu_guarantee=0.

[0073] Network-side constraints: bw_reserved=0; bw_limit (optional); bw_guarantee=0.

[0074] Joint Admission Requirements: No verification is performed.

[0075] Among them, the unified process for determining the parameters reserved / guarantee / limit for both computing power and network resources is included when generating business resource parameter configurations. This process consists of two steps: first, determining the upper limit parameter limit, and then calculating and verifying reserved / guarantee under the limit constraint.

[0076] (1) limit: If the user provides an upper limit, then the user-provided upper limit will be used.

[0077] Otherwise, if a business resource profile estimate exists, the profile estimate will be used.

[0078] Otherwise, use the default business type.

[0079] (2) guarantee / reserved: Deterministic services: reserved=guarantee=limit.

[0080] Latency-sensitive services: reserved=0, the guarantee can be specified by the user or estimated by the system based on the business profile / default policy.

[0081] Provide services to the best of one's ability: reserved=0, guarantee=0.

[0082] The handling scheme for access verification failure is as follows: When the admission verification fails, the network joint admission module returns candidate solutions to the user and waits for the user to select one: ① Waiting in line for resources to be available; ② Downgrade to a lower type and regenerate the resource policy configuration; ③ Cancel the service (default).

[0083] If the user does not make a selection within the deadline, the service will be cancelled.

[0084] The following process can be used as the method implementation process (corresponding to the data flow and control flow between system modules), and is executed consistently on both the computing power and network sides.

[0085] 1. Receiving business requests The business orchestration system or user submits a business request. The request must include at least the following parameters: scenario, allow_stall, allow_jitter, and criticality, and may optionally include suggested parameters such as cpu_limit_user and bw_limit_user.

[0086] 2. Business type identification The business type identification module outputs biz_type based on the business semantic decision tree; optionally, if historical monitoring or profile data is available, a biz_profile (normalized business profile) is generated for use by the strategy generation module.

[0087] 3. Generation of differentiated resource strategies The strategy generation module outputs res_conf resource parameters based on biz_type and biz_profile, including cpu_reserved, cpu_guarantee, and cpu_limit parameters on the computing power side; The network side parameters include bw_reserved, bw_guarantee, and bw_limit. Resource parameters are determined according to established rules. First, the limit is determined, and then the reserved / guarantee is determined and verified under the limit constraint. The resource semantic constraints of each service type are enforced to meet the requirements (e.g., deterministic services: all three are equal; latency-sensitive services: limit ≥ guarantee, etc.).

[0088] 4. Joint access verification of computing network The joint admission module simultaneously verifies whether the remaining computing power and network capacity within the target resource domain meet the corresponding admission conditions. Deterministic service: Verify and lock cpu_reserved and bw_reserved; Latency-sensitive services: Verify cpu_guarantee and bw_guarantee; Best effort service: No verification performed.

[0089] 5. Resource allocation and service launch Successful access will trigger a coordinated distribution: On the computing power side, CPU reservation / quota lower limit / quota upper limit configuration is executed; The network side performs bandwidth guarantees / limits and configures queuing or QoS, etc. Then start the business instance.

[0090] 6. Handling of Access Failures When admission fails, return candidate options to the user and wait for selection: ① Queue and wait for resources to be available; ② Downgrade and regenerate the policy before granting admission; ③ Cancel (default). Cancel if no deadline is selected.

[0091] Example 1: Deterministic Services (Strongly Deterministic Scenarios) Input: scenario=strong deterministic scenario set, allow_stall=no, allow_jitter=no, criticality=high, cpu_limit_user=4 cores, bw_limit_user=10M.

[0092] Identification: biz_type = deterministic service.

[0093] Strategy: cpu_reserved=cpu_guarantee=cpu_limit=4 cores, bw_reserved=bw_guarantee=bw_limit=10M.

[0094] Admission criteria: Simultaneously verify that the available computing power capacity is ≥ cpu_reserved and the network can guarantee that the remaining capacity is ≥ bw_reserved. Once approved, the data is locked and distributed.

[0095] Effect: Provides strong end-to-end protection upon startup, suitable for businesses with extremely high performance determinism requirements.

[0096] Example 2: Latency-Sensitive Service (Online Interaction) Input: scenario=within the online interactive scenario set, allow_stall=no, allow_jitter=yes, criticality=medium.

[0097] Identification: biz_type=latency-sensitive service.

[0098] Strategy: cpu_reserved=0, bw_reserved=0; the system estimates cpu_guarantee=2 cores, bw_guarantee=5M, and sets cpu_limit=4 cores, bw_limit=8M.

[0099] Admission: Verify that the available computing power capacity is ≥ cpu_guarantee; Furthermore, the network can guarantee that the remaining amount is greater than or equal to bw_guarantee, and the guarantee and limit will be issued after approval.

[0100] Effects: Ensures minimum performance, allows bursts within limits, improves resource utilization, and reduces jitter risk.

[0101] Example 3: Best-effort service (offline download task) Input: allow_stall=Yes, criticality=Low.

[0102] Identification: biz_type=best effort service.

[0103] Strategy: reserved=0, guarantee=0, limit uses the default value.

[0104] Access: No verification is performed; the system starts directly.

[0105] Effect: Maximizes carrying capacity, suitable for background batch processing and other businesses that tolerate fluctuations.

[0106] This embodiment has the following advantages: This embodiment proposes a differentiated resource guarantee system for computing network collaboration based on service type. It utilizes a service semantic decision tree to identify service types, uniformly constructs a three-layer resource semantic structure (reserved / guarantee / limit), and generates consistent resource policies on both the computing power and network sides, executing joint access control, collaborative resource allocation, and closed-loop processing for access failures. This solution balances strong guarantee, low jitter, and high utilization, demonstrating good engineering feasibility and promotional value.

[0107] This embodiment can be widely applied to scenarios such as multi-tenant cloud platforms, edge clouds, integrated computing power and network scheduling, cloud-native container platforms, and mixed deployment of online interactive services and critical production services. Through computing-network collaboration and differentiated protection, it can significantly reduce the probability of critical service failures and performance fluctuations, and improve overall resource utilization and automated operation and maintenance levels.

[0108] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the discussion in some embodiments is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the contents of this disclosure, thereby enabling those skilled in the art to better utilize the embodiments.

Claims

1. A differentiated resource guarantee system for computing network collaboration based on business type, characterized in that, The system includes: A business type identification module is configured to identify the business type based on at least one business request, and obtain the target business type and / or normalized business profile corresponding to the business request. A differentiated resource strategy generation module is configured to generate a target unified strategy based on the target service type and / or the normalized service profile. The target unified strategy includes computing resource parameters and network resource parameters corresponding to the service request. The computing network joint access module is configured to determine whether the service request should be admitted to the target resource domain based on the target unified policy.

2. The differentiated resource guarantee system for computing network collaboration based on business type as described in claim 1, characterized in that, The service types include deterministic services, latency-sensitive services, and best-effort services; The business type identification module is also configured as follows: The business type is determined based on the business parameters to obtain the target business type of the business request and / or the normalized business profile; the business parameters include business scenario information, whether service interruption is allowed, whether latency jitter is allowed, and / or business criticality information.

3. The differentiated resource guarantee system for computing network collaboration based on business type as described in claim 2, characterized in that, The business type identification module is also configured as follows: Determine whether the critical business information is not less than 1, whether the service interruption information is indicated as no, and whether the latency jitter information is indicated as no; if yes, mark the business type of the business request as the deterministic service. Determine whether the business scenario information belongs to a strongly deterministic scenario set, whether the service interruption information is allowed is characterized as no, and whether the latency jitter information is allowed is characterized as no; If so, the service type of the service request is marked as the deterministic service.

4. The differentiated resource guarantee system for computing network collaboration based on business type as described in claim 3, characterized in that, The business type identification module is also configured as follows: Determine whether the information on whether service interruption is allowed is negative and whether the information on whether latency jitter is allowed is negative; if yes, mark the service type of the service request as the latency-sensitive service. Determine whether the business scenario information belongs to the interactive online scenario set and whether the information on whether service interruption is allowed is characterized as no; If so, then mark the service type of the service request as the latency-sensitive service; Determine whether the critical business information is not less than 2 and whether the service interruption information is indicated as no; If so, the service type of the service request will be marked as the latency-sensitive service.

5. A differentiated resource guarantee system for computing network collaboration based on business type as described in claim 4, characterized in that, The business type identification module is also configured as follows: When the service request does not meet the requirements of the latency-sensitive service and the deterministic service, the service type of the service request is marked as the best-effort service.

6. A differentiated resource guarantee system for computing network collaboration based on business type as described in claim 5, characterized in that, The computing power resource parameters include computing power reservation parameters, computing power upper limit parameters, and computing power lower limit parameters; the network resource parameters include network reservation parameters, network upper limit parameters, and network lower limit parameters.

7. A differentiated resource guarantee system for computing network collaboration based on business type as described in claim 6, characterized in that, The differentiated resource strategy generation module is also configured to: When the service type of the service request is the deterministic service, a first target unified strategy is generated; the first target unified strategy includes setting the computing power reservation parameter to be greater than 0, setting the computing power reservation parameter, the computing power upper limit parameter and the computing power lower limit parameter to be equal, setting the network reservation parameter to be greater than 0, and setting the network reservation parameter, the network upper limit parameter and the network lower limit parameter to be equal. The network joint admission module is also configured as follows: When the service type of the service request is the deterministic service, determine whether the available remaining computing power and network resources in the target resource domain of the service request are greater than the computing power reservation parameter and the network reservation parameter. If so, the service request is granted access to the target resource domain.

8. A differentiated resource guarantee system for computing network collaboration based on business type as described in claim 6, characterized in that, The differentiated resource strategy generation module is also configured to: When the service type of the service request is the latency-sensitive service, a second target unified strategy is generated; the second target unified strategy includes setting the computing power reservation parameter to 0, setting the computing power upper limit parameter to be no less than the computing power lower limit parameter, setting the computing power lower limit parameter to be greater than 0, setting the network reservation parameter to 0, setting the network upper limit parameter to be no less than the network lower limit parameter, and setting the network lower limit parameter to be greater than 0; The network joint admission module is also configured as follows: When the service type of the service request is the deterministic service, determine whether the computing power and the guaranteed remaining amount of the network in the target resource domain of the service request are greater than the computing power lower limit parameter and the network lower limit parameter. If so, the service request is granted access to the target resource domain.

9. A differentiated resource guarantee system for computing network collaboration based on business type as described in claim 6, characterized in that, The differentiated resource strategy generation module is also configured to: When the service type of the service request is the best-effort service, a third objective unified strategy is generated; the third objective unified strategy includes setting the computing power reservation parameter, the network reservation parameter, the computing power lower limit parameter, and the network lower limit parameter to 0.

10. A network-based collaborative differentiated resource guarantee system according to claim 1, characterized in that, The network joint admission module is also configured as follows: When the service request fails to be admitted to the target resource domain, the service request is queued until the resources of the target resource domain are available, the service type of the service request is downgraded and the target unified policy is regenerated, or the service request is canceled.

Images