A service offloading method, device and system

Abstract

A service offloading method, device and system. The system comprises a cloud management platform node, a plurality of resource pools and an offloading node, wherein each resource pool comprises a plurality of hosts for running services for a plurality of tenants, at least one instance is run on each host, an instance cluster corresponding to a target service of a target tenant is created in each resource pool, and the instances in the instance cluster are used to run the target service; in the method, the cloud management platform node acquires available resource information of each resource pool associated with a target service, wherein the available resource information of each resource pool indicates the number of instances that the resource pool can provide to the instance cluster of the target service within a time period; the cloud management platform node generates an offloading plan of the target service within the time period based on the available resource information of each resource pool; and the offloading node distributes service traffic of the target service within the time period to the plurality of resource pools according to the offloading plan.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202210132528.9, filed on February 14, 2022, entitled "A Data Processing Method and Computer", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of cloud computing technology, and in particular to a business offloading method, apparatus and system. Background Technology

[0004] Load balancing is a technology that distributes business traffic across available servers in a cluster of instances using load balancing algorithms. By managing the business traffic entering the instance cluster, load balancing aims to provide network visitors with the best possible network experience.

[0005] Currently, load balancing strategies include load balancing algorithms and preset traffic splitting ratios. Load balancing algorithms are primarily used to select instance clusters for traffic splitting. For example, they might poll the instance clusters corresponding to a service, distributing service requests to instance clusters with lower loads for processing, or select instance clusters located closer to the user device that triggered the service request to respond to that request. Preset traffic splitting ratios refer to distributing traffic according to a preset proportion of multiple instance clusters corresponding to a service.

[0006] However, when business traffic surges, or when the resource availability of multiple instance clusters corresponding to a business is inconsistent, selecting the instance cluster with the lowest load or allocating traffic according to a preset traffic ratio can only achieve coarse-grained traffic allocation. This may result in business requests allocated to instance clusters not being processed in a timely manner, exacerbating the situation in traffic surge scenarios and reducing the experience of network visitors. Summary of the Invention

[0007] This application provides a service offloading method, apparatus, and system for achieving fine-grained and precise offloading, ensuring that service requests can be processed in a timely manner.

[0008] Firstly, this application provides a service traffic splitting method applicable to a cloud computing system, which includes a cloud management platform node, multiple resource pools, and a traffic splitting node. Each resource pool includes multiple hosts for running services for multiple tenants, each host runs at least one instance, and each resource pool can create an instance cluster corresponding to a target service of a target tenant. The instances in the instance cluster are used to run the target service. The method includes: the cloud management platform node obtaining available resource information for each resource pool associated with the target service, wherein the available resource information for each resource pool indicates the number of instances that the resource pool can provide to the target service within a time period (denoted as the target time period); the cloud management platform node generating a traffic splitting plan for the target service within the target time period based on the available resource information of each resource pool; and the traffic splitting node allocating the service traffic of the target service within the target time period to one or more resource pools according to the traffic splitting plan.

[0009] In the above technical solution, the cloud management platform node determines the traffic distribution plan for the target business within the target time period based on the available resource information of the resource pool associated with the target business. This allows for the pre-determination of the business traffic of the target business to be allocated to each resource pool within different time periods, which helps to better realize traffic distribution planning, avoids the business traffic allocated to the instance cluster from exceeding the carrying capacity of its resource pool, and ensures that the business requests allocated to the instance cluster can be processed in a timely manner as much as possible, achieving fine-grained traffic distribution and reducing or avoiding large-scale congestion of business requests when business traffic suddenly surges.

[0010] In one possible implementation, the available resource information for each resource pool indicates the number of idle instances in that resource pool during the target time period, where idle instances are those not occupied by other tenants during that time period.

[0011] In the above technical solution, compared with the load balancing strategy, this application no longer focuses on the load of the instance cluster, but determines the number of idle instances in the resource pool during the target time period. The cloud management platform node formulates a traffic distribution plan based on the number of idle instances. In this way, regardless of whether the resource availability of multiple instance clusters corresponding to the business is consistent, a more granular traffic distribution can be achieved compared with load balancing and other strategies.

[0012] In one possible implementation, the traffic splitting plan indicates the maximum amount of traffic that each resource pool can handle for the target service within a target time period, or the proportion of traffic for the target service allocated to each resource pool within the time period.

[0013] In the above technical solution, the cloud management platform node determines the traffic distribution plan based on the available resource information of each resource pool, indicating the maximum value of the target service traffic that each resource pool can handle, thus preventing the service traffic allocated to the instance cluster from exceeding the maximum carrying capacity of its respective resource pool. When the traffic distribution plan indicates a traffic ratio, it can be compatible with the traffic distribution nodes in the aforementioned load balancing strategy that distribute traffic according to a preset traffic ratio, improving the applicability of the technical solution in this application.

[0014] In one possible implementation, traffic routing planning instructs the traffic of a target service to be allocated to each resource pool priority information within a target time period.

[0015] In the above technical solution, the order in which the traffic of the target service is allocated into the resource pool can be adjusted based on the priority information of the resource pool, making the traffic allocation method more flexible.

[0016] In one possible implementation, the method further includes: a cloud management platform node acquiring resource demand information of the target service, which indicates the predicted business traffic of the target service within a target time period; and the cloud management platform node generating a traffic distribution plan based on the resource demand information of the target service and the available resource information of each resource pool.

[0017] In the above technical solution, a traffic allocation plan is generated based on the resource demand information of the target business and the available resource information of each resource pool, which can realize the coordinated scheduling of computing resources and business needs and achieve more granular traffic allocation.

[0018] In one possible implementation, the sum of the service traffic of the target services allocated to each resource pool within the target time period is equal to the predicted service traffic value, and the service traffic of the target services allocated to each resource pool within the target time period does not exceed the maximum service traffic of the target services that the resource pool can bear.

[0019] In one possible implementation, the traffic splitting plan satisfies a cost strategy that minimizes the cost of traffic from the target service allocated to each resource pool within a target time period.

[0020] The above technical solution provides a new cost strategy for target tenants. When the cost strategy is used to determine the traffic diversion plan, it can also effectively reduce the cost of target tenants.

[0021] In one possible implementation, the cost incurred by the service traffic of the target service allocated to each resource pool within the target time period includes at least instance cost and communication cost; instance cost indicates the rental cost of the instance required for the service traffic of the target service allocated to each resource pool within the said time period, and communication cost indicates the communication cost required for the distribution node to transmit the service traffic of the target service to each resource pool.

[0022] In one possible implementation, the maximum service traffic that each resource pool can handle for the target service is determined based on the number of instances in the instance cluster that the resource pool can provide to the target service within the target time period and the resource conversion information of the target service, which indicates the number of instances required to process a single service request of the target service.

[0023] Secondly, embodiments of this application also provide a computing device that has the function of implementing the cloud management platform node in the first aspect or any possible implementation of the first aspect. The beneficial effects are described in the first aspect and will not be repeated here. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the device structure includes an acquisition module and a determination module; optionally, it may also include a communication module. These modules can perform the corresponding functions in the method examples of the first aspect, as detailed in the method examples, and will not be repeated here.

[0024] Thirdly, embodiments of this application also provide a computing device, which includes a processor and a memory, and may further include a communication interface. The processor executes program instructions stored in the memory to perform the method provided in the first aspect or any possible implementation thereof. The memory is coupled to the processor and stores program instructions and data necessary for determining the traffic splitting plan. The communication interface is used to communicate with other devices, such as sending the traffic splitting plan.

[0025] Fourthly, this application provides a computing device cluster including at least one computing device. Each computing device includes a memory and a processor. The processor of at least one computing device is used to access code in the memory to execute the methods provided in the first aspect or any possible implementation thereof.

[0026] Fifthly, this application provides a computer-readable storage medium that, when executed by a computing device, performs the method provided in the first aspect or any possible implementation thereof. The storage medium stores a program. The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid-state drive (SSD).

[0027] Sixthly, this application provides a computer program product, which includes computer instructions that, when executed by a computing device, enable the computing device to perform the methods provided in the first aspect or any possible implementation thereof. The computer program product can be a software installation package, which can be downloaded and executed on a computing device when the methods provided in the first aspect or any possible implementation thereof are required.

[0028] In a seventh aspect, this application also provides a computer chip connected to a memory, the chip being used to read and execute a software program stored in the memory, and to execute the method provided in the first aspect or any possible implementation thereof.

[0029] For the beneficial effects of any of the implementation methods in aspects two through seven mentioned above, please refer to the description of aspect one, which will not be repeated here. Attached Figure Description

[0030] Figure 1 This is a schematic diagram illustrating the relationship between a region and an availability zone;

[0031] Figure 2 A possible network architecture diagram provided for an embodiment of this application;

[0032] Figure 3 This is a schematic diagram illustrating another possible network architecture provided for an embodiment of this application;

[0033] Figure 4 A flowchart illustrating the service diversion method provided in this application embodiment;

[0034] Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0035] Figure 6 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0036] Figure 7 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0037] To facilitate understanding, some technical terms used in the embodiments of this application will be explained first.

[0038] (1) Region and Availability Zone (AZ) are used to describe the location of a data center. A region refers to the area where the data center is located, which can be a region (e.g., North China) or a city (e.g., Beijing, Tianjin). An availability zone refers to the physical area where the data center or site is located, and has the characteristics of independent energy consumption and network.

[0039] See Figure 1 As shown, a Region typically contains multiple low-latency interconnected Availability Zones (AZs) for scenarios and services such as disaster recovery and load balancing within the same region. For example, in Beijing (Region), there are two data centers; these two data centers are two Availability Zones, each with its own independent water, electricity, and network infrastructure. Multiple AZs within a Region are connected via the data center's internal network (high-speed fiber optic) to meet the needs of tenants building high-availability systems across AZs. Different Regions need to be interconnected via the public internet.

[0040] (2) Instances can refer to software programs or computing resources used to run business operations, and can also be called computing instances, computing modules, algorithm instances, etc.

[0041] (3) A Virtual Machine (VM) is a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. Any task that can be performed on a physical computer (referred to as a physical machine) can also be performed in a VM. When creating a VM on a physical machine, some of the physical machine's hardware resources (such as CPU, memory, and hard disk) are used as the VM's hardware resources. Each VM has its own independent operating system and can be operated just like a physical machine. In practical applications, a single physical host can be used to virtualize multiple VMs. VMs can also be called Elastic Compute Service (ECS) or Elastic Instances (different cloud service providers may use different names).

[0042] (4) Containers are a way to virtualize the operating system, allowing users to run applications and their dependencies in processes where resources are isolated.

[0043] (5) Bare metal server refers to a physical server that can provide tenants with dedicated cloud resources, i.e., a host.

[0044] Figure 2 This application provides a schematic diagram of a possible cloud computing system architecture. The cloud computing system includes a cloud management platform 1 and one or more resource pools (…). Figure 2 Three resource pools, 20, 21, and 22, are shown, but this is not a limitation.

[0045] First, let's introduce resource pools. Typically, each resource pool includes multiple hosts, and each host runs one or more instances. For example, the same resource pool can be used within the same Region; that is, a resource pool can include all instances running within a Region. In this embodiment, an instance can be any one or more combinations of computing resources at different granularities, such as virtual machines, containers, and hosts.

[0046] Tenants can purchase instances from one or more specific resource pools. Correspondingly, instance clusters for the target tenant's target business can be created within one or more resource pools, such as... Figure 2 In this context, resource pool 20 contains instance cluster 200 containing the target tenant's target service; resource pool 21 contains instance cluster 210 containing the target tenant's target service; and resource pool 22 contains instance cluster 220 containing the target tenant's target service. Each instance cluster includes instances leased by the target tenant from that resource pool, which may include one or more of virtual machines, containers, and bare metal servers, used to run the target service, such as... Figure 2 The right side shows the service traffic sent by users through user devices 101, 102, 103, etc. Each instance cluster can contain one or more of the following: virtual machines, containers, and bare metal servers. For clarity, the following explanation uses virtual machines as an example.

[0047] In practical applications, each resource pool can include virtual machines of various specifications. When a target tenant leases a virtual machine from a resource pool, they can specify one or more specifications of the virtual machine. Different specifications of virtual machines can have different hardware configurations, including but not limited to: the number of CPU cores, memory capacity, disk space, and bandwidth. Table 1 exemplarily shows several virtual machine specifications within a resource pool and their corresponding pricing standards. It should be noted that Table 1 is only an example and does not constitute a limitation on actual applications.

[0048] Table 1

[0049]

[0050]

[0051] It should be noted that the specifications of virtual machines included in different resource pools can be exactly the same, not exactly the same, or completely different. Furthermore, virtual machines of the same specifications may have different pricing standards in different resource pools, which is related to the operating costs of the resource pool itself. Additionally, it should be noted that the specifications of virtual machines leased by the target tenant in different resource pools may be different. For example, the virtual machines in instance cluster 200 may be VM_1 and VM_2, the virtual machines in instance cluster 210 may be VM_2, and the virtual machines in instance cluster 220 may be VM_1.

[0052] Within the resource pool, in addition to virtual machines leased to tenants (i.e., virtual machines included in the instance cluster), there are also idle virtual machines. These can be understood as virtual machines not occupied or sold by other tenants, and can be used to expand the existing instance clusters in the resource pool. Typically, target tenants do not purchase a fixed number of virtual machines. In other words, the number of virtual machines included in instance clusters 200, 210, and 220 is not fixed and can be expanded or reduced using elastic scaling technology. Elastic scaling technology refers to automatically increasing or decreasing the number of virtual machines based on business needs. For example, when increased business traffic leads to insufficient computing power, the number of virtual machines in the instance cluster is increased, that is, idle virtual machines in the resource pool are included in the instance cluster. This continues until business traffic decreases and computing power becomes surplus, at which point the number of virtual machines in the instance cluster is reduced, that is, some idle virtual machines in the instance cluster are released back to the resource pool.

[0053] The cloud management platform 1 is described below. The cloud management platform 1 includes a monitoring system 10, a cloud management platform node 11, and a traffic distribution node 12.

[0054] The monitoring system 10 includes a monitoring node 113 and a database 114.

[0055] The monitoring module 113 is used to monitor the performance indicators of the resource pool, including the monitoring of various physical and virtual resources, such as the number of VMs in each instance cluster in the resource pool and the number of idle VMs of different specifications in the resource pool. The monitoring module 113 is responsible for collecting the values ​​of various performance indicators of the resource pool in real time or periodically. The database 114 is used to store the data collected by the monitoring module 113. Optionally, the database 114 can also be used to store other information, such as the specifications of various VMs included in each resource pool and the corresponding charging standards (see Table 1), the instance clusters corresponding to the target service, the resource pool where the instance clusters are located (the resource pool associated with the target service), and the mapping relationship of the VM specifications specified in the resource pool, etc., which are not limited in this application.

[0056] Cloud management platform node 11 is used to execute the business traffic splitting method provided in this application embodiment. For example, cloud management platform node 11 is used to obtain the available resource information of each resource pool associated with the target business; and determine the traffic splitting plan for the target business in a future time period (denoted as the target time period) based on the available resource information of each resource pool associated with the target business. Optionally, cloud management platform node 11 is also used to provide a configuration interface, on which the target tenant can configure business parameters, such as the resource pool associated with the target business, the specifications of the virtual machines used to run the target business in the resource pool, the elastic scaling strategy applied to the instance cluster, and the cost strategy for specifying the traffic splitting plan (described below, not repeated here), etc. These business parameters can be stored in database 114.

[0057] Split node 12 is the traffic interface for the target service, used to receive the service traffic of the target service, such as... Figure 2 As shown on the right, the user device can be a regular computer 101, a tablet computer 102, a smartphone 103, etc. Users can send service requests through their user devices. The traffic distribution node 12 is also used to distribute the traffic of the target service within a target time period to multiple resource pools according to the traffic distribution plan generated by the cloud management platform node 11. In this application, service traffic can be measured by the number of service requests. For example, based on the traffic distribution plan, the traffic distribution node 12 sends 2000 service requests of the target service within the target time period to instance cluster 200, and sends the other 3000 service requests of the target service within the target time period to instance cluster 210. Exemplarily, the traffic distribution node 12 can communicate with the resource pools via a network (such as the Internet).

[0058] In an optional implementation, the traffic splitter 12 may be located in a resource pool associated with the target service to save network communication costs between the traffic splitter 12 and the instance clusters in that resource pool. For example, if the target service of the target tenant corresponds to instance clusters 200, 210, and 220, then the associated resource pools for the target service include resource pools 20, 21, and 22. The traffic splitter 12 for the target service may be located in resource pool 20, resource pool 21, or resource pool 22. See also Figure 3 As shown, assuming that the traffic distribution node 12 of the target service is located in the resource pool 20, when the traffic distribution node 12 sends service traffic to the instance cluster 200, it does not need to be transmitted through the network, thereby saving the communication cost between the two.

[0059] It should be noted that the "user" and "tenant" in this application are different. The tenant is the business entity, and the user is the party using the services provided by the business entity. For example, suppose the business entity provides an app. If the app is a search engine, then the user is the party using the search engine. A business request triggered by running the search engine on the user's device could be a webpage retrieval request, etc. Similarly, if the app is video software, the user is the party using the video software. A business request triggered by running the video software on the user's device could be a video retrieval request, etc. Furthermore, if the app is conferencing software, the user can run the conferencing software on their device, triggering business requests such as creating a meeting or joining a meeting. Correspondingly, the virtual machines within the instance cluster corresponding to the target business can be used to process the business requests of the target business. For example, for a meeting creation request, meeting resources are created and a meeting link is generated. The meeting link and other information are placed in the meeting response and returned to the distribution node 12, which is then returned to the corresponding user by the distribution model 13.

[0060] It should be noted that, Figure 2 or Figure 3 The system architecture shown is for illustrative purposes only. In practical applications, cloud computing systems can include relatively... Figure 2 The number of nodes may be 3 or more or fewer; this application embodiment does not limit this.

[0061] This application provides a business traffic splitting method. When formulating the traffic splitting plan, the traffic splitting plan is formulated based on the processing capacity of each resource pool associated with the target business, so as to ensure that the business requests allocated to the instance cluster can be processed in a timely manner, thereby achieving fine-grained traffic splitting.

[0062] Next, we will combine the appendix Figure 4 The service diversion method provided in the embodiments of this application is applied to Figure 3 The method will be explained in detail using the system shown as an example. For ease of explanation, a virtual machine will still be used as an example. In the following text, "virtual machine" can be replaced with "instance". Figure 3 In this context, the target tenant's target business corresponds to instance clusters 200, 210, and 220. For ease of description, the "target tenant's target business" will be referred to as "target business" in the following text.

[0063] Figure 4 This is a flowchart illustrating a service diversion method provided in an embodiment of this application. Figure 4 As shown, the method includes the following steps:

[0064] Step 401: Cloud management platform node 11 obtains the available resource information of each resource pool associated with the target business.

[0065] The resource pool associated with the target service refers to the resource pool where the instance cluster corresponding to the target service resides, for example, Figure 3 In this context, if the target business corresponds to instance clusters 200, 210, and 220, then the resource pools associated with the target business include resource pool 20, resource pool 21, and resource pool 22.

[0066] The available resource information for each resource pool indicates the number of virtual machines (VMs) that the resource pool can provide to the target service within the target time period (denoted as the target number). For example, the target number is the number of VMs in the resource pool that can be used to expand the instance cluster corresponding to the target service.

[0067] For example, the target quantity refers to the number of idle virtual machines of a target specification in the resource pool within a target time period. The target specification indicates the virtual machine specification specified by the target service in that resource pool. For instance, see Table 2, which exemplarily illustrates the mapping relationship between the target service and the corresponding instance cluster, resource pool, and virtual machine specification.

[0068] Table 2

[0069]

[0070] Specifically, the number of virtual machines that resource pool 20 can provide to the target service during the target time period is equal to the number of idle virtual machines of specification VM_1 in resource pool 20 during the target time period. Similarly, the number of virtual machines that resource pool 21 can provide to the target service during the target time period is equal to the number of idle virtual machines of specification VM_1 in resource pool 21 during the target time period.

[0071] Optionally, when multiple services (including the target service) within the resource pool specify the same virtual machine specification, the target quantity can be determined based on the number of idle virtual machines of the target specification in the resource pool during the target time period and the proportion corresponding to the target service within the resource pool. For example, referring to Table 2, assuming that the target specification for both the target service (such as service A) and service B in resource pool 20 is VM_1, and assuming that the proportion corresponding to the target service in resource pool 20 is 2 / 3, if the number of idle virtual machines of specification VM_1 in resource pool 20 during the target time period is 30, then the number of virtual machines that resource pool 20 can provide to the target service during the target time period is 30 * 2 / 3 = 20. The proportion corresponding to the target service can be a preset value or based on the ratio of the size of the instance cluster corresponding to the target service to the size of the instance cluster corresponding to service B in resource pool 20 before the target time period. The size of the instance cluster can be represented by the number of virtual machines contained in the instance cluster.

[0072] It is worth noting that the target service can correspond to multiple specified virtual machine specifications within the resource pool. This application does not limit this; furthermore, the virtual machine specifications specified for the target service in different resource pools can be the same or different, without specific limitations. Table 3 illustrates another mapping relationship for the target service.

[0073] Table 3

[0074]

[0075] Referring to Table 3, the number of virtual machines that resource pool 20 can provide to the target service during the target time period is the sum of the number of idle virtual machines of specification VM_1 and idle virtual machines of specification VM_2 in resource pool 20 during the target time period. For example, if resource pool 20 has 20 idle virtual machines of specification VM_1 and 30 idle virtual machines of specification VM_2 during the target time period, then the resource pool can provide 50 virtual machines to the target service during the target time period. Similarly, the number of virtual machines that resource pool 21 can provide to the target service during the target time period is the sum of the number of idle virtual machines of specification VM_2 in resource pool 21 during the target time period. The number of virtual machines that resource pool 22 can provide to the target service during the target time period is the sum of the number of idle virtual machines of specification VM_1 and idle virtual machines of specification VM_3 in resource pool 22 during the target time period.

[0076] Optionally, when the virtual machine specifications specified by multiple services (including the target service) within the resource pool partially or completely overlap, the target quantity can be determined based on the number of idle virtual machines of the target specification in the resource pool during the target time period and the proportion corresponding to the target service within the resource pool. For example, referring to Table 3, the target specifications corresponding to the target service (such as service A) in resource pool 20 are VM_1 and VM_2. Assuming that the target specifications corresponding to service B in resource pool 20 are all VM_1, and assuming that the proportion corresponding to the target service in resource pool 20 is 2 / 3, if the number of idle virtual machines of specification VM_1 in resource pool 20 during the target time period is 30, and the number of idle virtual machines of specification VM_2 in resource pool 20 during the target time period is 15, then the number of virtual machines that resource pool 20 can provide to the target service during the target time period (i.e., the target quantity) is 30*2 / 3+15=35. For example, suppose that the target specifications for the target service (such as service A) and service B in resource pool 20 are both VM_1 and VM_2, and suppose that the ratio of service A to service B in resource pool 20 is 2:1. If the total number of idle virtual machines of specification VM_1 and idle virtual machines of specification VM_2 in resource pool 20 during the target time period is 60, then the number of virtual machines that resource pool 20 can provide to the target service during the target time period (i.e., the target number) is 60*2 / 3 = 40. Therefore, the number of virtual machines that resource pool 20 can provide to the target service during the target time period (i.e., the target number) is 40.

[0077] In practical applications, for ease of management, the same tenant typically specifies the same type of virtual machine for the same service across different resource pools. The following example illustrates this, using Table 2 as an example, where the virtual machines specified by the target tenant for running the target service are all of the same specification. It should be noted that Table 2 is merely an example and does not constitute a limitation on the mapping relationships involved in the embodiments of this application. For instance, Table 2 may not include the "instance cluster" column, or it may be split into multiple lists for storage; this application does not impose any limitations on these aspects.

[0078] The following section explains how to determine the number (or target number) of virtual machines that each resource pool can provide to the target business within the target time period.

[0079] Taking a resource pool such as resource pool 20 as an example, the prediction process may include: predicting the number of idle virtual machines of the target specification in resource pool 20 within a target time period based on the number of idle virtual machines of the target specification in resource pool 20 within a historical period (denoted as the first historical window).

[0080] For example, the first historical window can be an adjacent time period before the target time period. For instance, if the target time period is 2:00-2:01 on a certain day, the first historical window could be 1:30-2:00 on the same day. For example, referring to Table 2, when 2:00 is reached, based on multiple sampled data from resource pool 20 within 1:30-2:00 on that day, the number of idle virtual machines of specification VM_1 within 2:00-2:01 on that day is predicted. The multiple sampled data represent the number of idle virtual machines of specification VM_1 in resource pool 20 at different times within 1:30-2:00 on that day. For example, if the sampling interval is 5 minutes, the multiple sampled data could include the number of idle virtual machines of specification VM_1 in resource pool 20 at 1:30, 1:35, 1:40, ..., 2:00 on that day. Similarly, when 2:01 is reached, the number of idle virtual machines of specification VM_1 for the period from 2:01 to 2:02 is predicted based on multiple sampled data from resource pool 20 during the period from 1:31 to 2:01 of that day. When 2:02 is reached, the number of idle virtual machines of specification VM_1 for the period from 2:02 to 2:03 of that day is predicted based on multiple sampled data from resource pool 20 during the period from 1:32 to 2:02 of that day. The sampled data within the first historical window can be obtained from database 114 or from other devices. For example, this sampled data can be collected by monitoring module 113. This application embodiment does not limit this, and similar details will not be repeated below. The above method can also be called real-time prediction, and is typically applied in scenarios where high prediction accuracy is required or the number of idle virtual machines in the resource pool does not exhibit a periodic pattern.

[0081] For another example, the first historical window is a historical window within the target time period. For instance, when the number of idle virtual machines of the target specification in resource pool 20 exhibits a periodic pattern, the first historical window can be a historical window within the target time period. For example, if the number of idle virtual machines of the target specification in resource pool 20 exhibits an intraday pattern, assuming the target time period is 0:00-24:00 on April 10, 2024, the first historical window could be 0:00-24:00 on April 9, 2024, or 0:00-24:00 on April 8, 2024, and so on. The first historical window is k days apart from the target time period, where k is a positive integer. For example, when the number of idle virtual machines of the target size in resource pool 20 exhibits a weekly pattern, assuming the target time period is 0:00-24:00 on April 25, 2024, the first historical window could be 0:00-24:00 on April 18, 2024, or 0:00-24:00 on April 11, 2024, and so on. The number of idle virtual machines of the target size in the resource pool may also exhibit a monthly pattern or other variations over different time periods; the specifics are not limited. This prediction method is typically applied to scenarios where the number of idle virtual machines of the target size in the resource pool exhibits a periodic pattern, reducing computational overhead while maintaining accuracy.

[0082] It should be noted that the above examples are merely illustrations. The length of the first historical window, sampling interval, prediction interval, output data interval (which can be equal to the length of the target time period), and the length of the target time period can also be other values, without any specific limitation. Furthermore, it should be noted that when performing prediction, the number of first historical windows can be one or more. For example, these multiple historical windows may include one or more adjacent time periods before the target time period, and / or one or more historical windows from the same period of the target time period. The time lengths of these multiple second historical windows can be the same, different, or not entirely the same, and this application does not limit this. For example, if the target time period is 0:00–24:00 on April 25, 2024, then the corresponding multiple first historical windows could be 0:00–24:00 on April 18, 2024, and 0:00–24:00 on April 11, 2024, or 0:00–24:00 on April 18, 2024, and 23:00–24:00 on April 24, 2024, etc. Furthermore, the aforementioned prediction methods are merely examples and are not intended to limit the specific implementation. Any prediction method is applicable to the embodiments of this application.

[0083] Using the methods described above, the available resource information for each resource pool associated with the target service is obtained. This prediction process can be executed by the cloud management platform node 11 or by other devices (such as monitoring module 113), without limitation. If other devices are used, the cloud management platform node 11 obtains the available resource information for each resource pool associated with the target service from those devices. Assume the available resource information for each resource pool associated with the target service obtained by the cloud management platform node 11 is shown in Table 4 below.

[0084] Table 4

[0085]

[0086] It should be noted that Table 4 is for illustrative purposes only, and this application does not limit the storage format and content of the available resource information of the resource pool.

[0087] Step 402: Cloud management platform node 11 obtains the resource requirement information of the target business.

[0088] Resource requirement information for the target service can be used to indicate the predicted traffic volume of the target service within a target time period. For example, this prediction process may include: predicting the traffic volume of the target service within the target time period based on traffic volume data of the target service over a historical period (denoted as the second historical window), and the resulting value is the predicted traffic volume. This prediction process can be executed by cloud management platform node 11. Alternatively, it can be executed by other devices (such as monitoring module 113), in which case cloud management platform node 11 can obtain resource requirement information for the target service from other devices.

[0089] Similarly, the second historical window can be an adjacent time period preceding the target time period. Alternatively, it can be a historical window from the same period of the target time period, such as when the business traffic of the target service exhibits a cyclical pattern, such as intraday or weekly patterns.

[0090] It should be noted that the length of the second historical window, the sampling interval, the prediction interval, the output data interval (which can be equal to the length of the target time period), and the length of the target time period can also be other values, without any specific limitation. Furthermore, it should be noted that the number of second historical windows can be one or more when performing a prediction. Multiple historical windows may include one or more time windows adjacent to the target time period, and / or one or more historical windows contemporaneous with the target time period. The time lengths of multiple second historical windows can be the same, different, or not entirely the same; this application does not impose any limitation in this regard. For details, please refer to the foregoing description of predicting the number of idle virtual machines in the resource pool within the target time period based on the first historical window; it will not be repeated here.

[0091] Step 403: Cloud management platform node 11 generates the traffic distribution plan for the target business within the target time period.

[0092] The following describes two methods for determining traffic diversion plans:

[0093] Method 1: Generate a traffic distribution plan for the target business within the target time period based on the available resource information of each resource pool associated with the target business.

[0094] This traffic distribution plan indicates the maximum traffic volume that each resource pool can handle for the target service within a target time period.

[0095] For example, based on the resource conversion information of the target service, the number of virtual machines that the resource pool can provide to the target service within a target time period can be converted into the maximum value of the service traffic that the resource pool can handle for the target service. The resource conversion information of the target service indicates the number of computing resources required to process a single service request of the target service. These computing resources can be computing resources of different granularities, such as virtual machines or CPU cores. For example, the resource conversion information of the target service indicates the number of CPU cores or VMs required to run a service request of the target service.

[0096] For example, taking Table 4 as an example, assuming the resource conversion information of the target service indicates that a service request requires 0.1 VMs of specification VM_1, we can determine, based on Table 4, the maximum service traffic that each resource pool associated with the target service can handle within the target time period. For example, the maximum service traffic that resource pool 20 can handle is 100 / 0.1 = 1000 service requests. Based on this method, we calculate the maximum service traffic that each resource pool associated with the target service can handle within the target time period, as shown in Table 5.

[0097] Table 5

[0098]

[0099] If the resource conversion information of the target service is used to indicate the number of CPU cores and other computing resources required to run a service request of the target service, then the maximum service traffic that each resource pool associated with the target service can handle within the target time period can be determined by combining the available resource information of resource pool 20, the resource conversion information of the target service, and the virtual machine specification information. The resource specification information is used to indicate the number of computing resources included in the virtual machine specification, as shown in Table 1.

[0100] For example, the resource conversion information of the target service indicates that a service request requires 0.1 CPU cores. Referring to Table 1, it can be determined that a virtual machine with specification VM_1 includes 1 CPU core. Then, combined with Table 5, it can be determined that within the target time period, the maximum service traffic of the target service that resource pool 20 can handle is 100*1 / 0.1 = 1000 service requests.

[0101] Method 2: Based on the resource demand information of the target business and the available resource information of each resource pool associated with the target business, generate a traffic distribution plan for the target business within the target time period.

[0102] This traffic offloading plan indicates that, within a target time period, the sum of the traffic of the target service allocated to one or more resource pools equals the predicted traffic value, and that the traffic of the target service allocated to each resource pool within the target time period does not exceed the maximum traffic capacity of that resource pool. In other words, this traffic offloading plan indicates which resource pools to allocate the traffic of the target service to within the target time period, and how much traffic is allocated to each resource pool.

[0103] It is understandable that there are multiple traffic distribution plans that meet this condition. For example, continuing with the example in Table 5, assuming that the predicted traffic volume for the target service is 1000 service requests within the target time period, the traffic distribution plan could instruct that 1000 service requests be allocated to resource pool 20, or that 500 service requests be allocated to resource pool 20 and the remaining 500 service requests be allocated to resource pool 21. Alternatively, the traffic distribution plan could instruct that 500 service requests be allocated to resource pool 20 and the remaining 500 service requests be allocated to resource pool 22, and so on. In an optional implementation, the cloud management platform node 11 can select a traffic distribution plan based on a cost strategy, such as the cost strategy including minimizing the cost of allocating the predicted traffic volume of the target service to one or more resource pools within the target time period.

[0104] For example, the fee includes, but is not limited to, virtual machine fees and communication fees. The virtual machine fee indicates the sum of the rental fees for virtual machines required by each resource pool to handle the allocated traffic of the predicted target service within a target time period, when the traffic is distributed to one or more resource pools. The virtual machine rental fee can be billed on a per-machine-hour basis, where per-machine-hour = number of machines * time the machines are occupied (e.g., in hours). Table 1 shows the charging standards for virtual machines of various specifications within one resource pool. In this application, the virtual machine rental fee may include the number of virtual machines required by each resource pool to handle the allocated traffic of the target service when the traffic is distributed to one or more resource pools * the length of the target time period ( / h) * the cost per machine-hour of the virtual machine of that specification within that resource pool. It should be understood that virtual machines of the same specification may have different prices in different resource pools, which is related to the operating costs of the resource pool itself (e.g., water, electricity, etc.). For example, the operating costs of a resource pool located in the city center are higher than those in the suburbs, and correspondingly, the price of virtual machines in the resource pool with higher operating costs is also higher.

[0105] The communication cost indicates the communication cost required for the splitter node to transmit the service traffic of the target service to each resource pool. For example, the communication cost may include the bandwidth cost required for the splitter node 12 to send the service traffic of the target service to each resource pool, and the bandwidth cost of the service response returned by each target resource pool. It is worth noting that the bandwidth cost between the splitter node 12 and the target resource pool can be 0, such as... Figure 3 In the process, when the traffic distribution node 12 distributes the business requests of the target business into the instance cluster 200, no bandwidth fee is required.

[0106] Furthermore, in an optional implementation, the cloud management platform node 11 can also determine the traffic distribution plan based on constraints, such as: the traffic distribution plan must meet the service level agreement (SLA) of the target service. The SLA can be evaluated from metrics such as instance cluster response latency and jitter, which will not be discussed in detail here. Theoretically, tenants will choose to deploy services in resource pools that meet the SLA, meaning that all resource pools for the target service can meet the SLA. However, when the SLA of the target service changes, there may be situations where the resource pool where the target service resides cannot meet the target service's SLA. In this case, for example, the monitoring module 113 can measure the information needed to evaluate the service quality of each resource pool in real time or periodically, thereby calculating the SLA of that resource pool and storing the calculated SLAs of each resource pool in the database 114. This allows the cloud management platform node 11 to obtain the SLA of each resource pool and filter out resource pools that can meet the SLA of the target service from multiple resource pools associated with it. Additionally, the SLA and other information for the target business can be configured and updated by the business administrator on node 11 of the cloud management platform, and the updated SLA information can be stored in database 114, or it can be stored on other devices; there are no specific limitations. It should be noted that constraints may also include other conditions, such as not exceeding the maximum number of connections in an AZ or Region, etc., but this application does not impose any limitations on these.

[0107] In the two methods described above, the traffic distribution plan can be output in absolute value format, indicating the number of service requests for the target service that each resource pool can handle. For example, within the target time period, the maximum service traffic that resource pools 20, 21, and 22 can handle for the target service is 1000, 2000, and 3000 service requests, respectively. Alternatively, the traffic distribution plan can be output in traffic ratio format, indicating the proportion of the target service's traffic allocated to each resource pool within the target time period. For example, based on Table 5, it can be determined that within the target time period, the proportion of the target service's traffic allocated to resource pools 20, 21, and 22 is 1:2:3. When the traffic distribution plan indicates a traffic ratio, it is compatible with the traffic distribution nodes that distribute traffic according to a preset traffic ratio in the aforementioned load balancing strategy, improving the applicability of the technical solution in this application.

[0108] Optionally, the traffic allocation plan can also instruct the traffic of the target service to be allocated to each resource pool priority information within a target time period. For example, the traffic of the target service is preferentially allocated to the resource pool with higher priority. When the traffic allocated to that resource pool reaches the maximum traffic capacity of that resource pool, the traffic of the target service is then allocated to the resource pool with lower priority, and so on.

[0109] The priority information of resource pools can be determined based on the cost required for each resource pool to process the traffic of the target service. For example, the priority information of multiple resource pools can be determined based on the cost ratio of the multiple resource pools. For instance, the cost ratio of multiple resource pools can be the ratio of the cost of each resource pool processing a single service request. The lower the cost required for a resource pool to process a single service request, the higher the priority of the resource pool. Virtual machine cost refers to the rental cost of the virtual machine required to process a single service request. If the target service specifies multiple virtual machine specifications in a resource pool, the virtual machine cost can be determined by the weighted average of the costs of the multiple specifications. For example, if the target service specifies virtual machine specifications VM_1 and VM_2 in resource pool 20, and resource pool 20 can provide 30 VM_1 virtual machines and 20 VM_2 virtual machines to the target service during the target time period, with a cost per VM_1 virtual machine per hour of 'a' and a cost per VM_2 virtual machine per hour of 'b', then the average cost per virtual machine is a*3 / 5 + b*2 / 5. Then calculate the average number of business requests that each virtual machine can handle, and thus calculate the average rental cost of the virtual machines required to process one business request within resource pool 20.

[0110] Communication costs refer to the communication costs required to transmit a single service request, such as the bandwidth costs required for the distribution node 12 to send service traffic to the resource pool, and the bandwidth costs for receiving the service response returned by the resource pool for that service request. It is worth noting that when the distribution node 12 is located within the resource pool, the bandwidth cost between the distribution node 12 and the resource pool is 0, as explained above, and will not be repeated here.

[0111] It should be noted that there are multiple ways to determine the priority information of multiple resource pools. The above is just an example, and the embodiments of this application do not limit this.

[0112] Step 404: Cloud management platform node 11 sends the traffic splitting plan to traffic splitting node 12.

[0113] Step 405: According to the traffic distribution plan, the traffic distribution node 12 distributes the traffic of the target service within the target time period to one or more resource pools.

[0114] For example, the traffic distribution plan indicates that during the target time period (e.g., 16:00-16:01 on April 9, 2024), resource pools 20, 21, and 22 can handle a maximum of 1000, 2000, and 3000 service requests respectively. According to this traffic distribution plan, distribution node 12 allocates the service traffic of the target service during 16:00-16:01 on April 9, 2024 to one or more resource pools. The allocation order can be random, based on load balancing round-robin, a preset order, or determined by the priority information of multiple resource pools indicated in the previous traffic distribution plan. Specifically, the number of service requests allocated to resource pool 21 shall not exceed 1000, the number of service requests allocated to resource pool 21 shall not exceed 2000, and the number of service requests allocated to resource pool 22 shall not exceed 3000.

[0115] If the traffic splitting plan also indicates that the priority order of the multiple resource pools corresponding to the target service is: resource pool 20 > resource pool 21 > resource pool 22, then during the period from 16:00 to 16:01 on April 9, 2024, the traffic splitting node 12 will first allocate the received traffic of the target service to resource pool 20. When the traffic allocated to resource pool 20 reaches 1,000 service requests, the traffic of the target service will be allocated to resource pool 21. When the traffic allocated to resource pool 21 reaches 2,000 service requests, the traffic of the target service will be allocated to resource pool 22, until the traffic allocated to resource pool 22 reaches 3,000. It should be noted that the above-described traffic distribution plan is a pre-allocation. The actual number of service requests for the target service received by the traffic distribution node 12 within the target time period is not a fixed value. The traffic distribution plan does not limit the number to 6000 (1000+2000+3000). For example, if the number of service requests for the target service received by the traffic distribution node within the target time period is 600, then the traffic distribution node 12 can allocate the 600 received service requests to resource pool 20. Similar situations will not be repeated below.

[0116] For another example, the traffic distribution plan indicates that within a target time period, the number of service requests allocated to resource pool 20 (or instance cluster 200) is 1000, the number allocated to resource pool 21 (or instance cluster 210) is 500, and the number allocated to resource pool 22 (or instance) is 400. According to this traffic distribution plan, the traffic distribution node 12 will distribute the service requests received within the target time period to one or more resource pools.

[0117] If the traffic splitting plan also indicates that the priority order of the multiple resource pools corresponding to the target service is: resource pool 20 > resource pool 22 > resource pool 21, then during the period from 16:00 to 16:01 on April 9, 2024, the traffic splitting node 12 will first send the received service requests of the target service to resource pool 20. When the number of service requests sent to resource pool 20 reaches 1000, if more service requests of the target service are received, the received service requests of the target service will be sent to resource pool 22. When the number of service requests sent to resource pool 22 reaches 400, if more service requests of the target service are received, the received service requests of the target service will be sent to resource pool 21, until the number reaches 500.

[0118] It should be noted that step 404 is optional. If cloud management platform node 11 and traffic distribution node 12 are located on the same computing device, cloud management platform node 11 may not send traffic distribution plans to traffic distribution node 12. Furthermore, when determining the number of instances that each resource pool can provide to the target service instance cluster within the target time period, the above only includes the number of virtual machines that the resource pool can provide for expanding the instance cluster of the target service within the target time period. Optionally, it may also include the number of virtual machines included in the instance cluster of the target service itself, such as the number of virtual machines in the instance cluster at the start of the target time period.

[0119] Based on the above design, cloud management platform node 11 determines the traffic distribution plan for the target business within a target time period based on the available resource information of each resource pool associated with the target business. This allows for the pre-determining of the traffic allocated to each resource pool for the target business in different time periods, facilitating better traffic distribution planning and preventing the traffic allocated to the instance cluster from exceeding the capacity of its respective resource pool. It enables coordinated scheduling of computing resources and business needs, achieving fine-grained traffic distribution and reducing or avoiding large-scale congestion of business requests in traffic surge scenarios. Furthermore, it provides a new cost strategy for target tenants; when using this cost strategy to determine the traffic distribution plan, it can effectively reduce the costs for target tenants.

[0120] Based on the same inventive concept as the method embodiments, this application also provides a computing device for performing the above-described... Figure 4 or Figure 5 The method implemented by cloud management platform node 11 in the method embodiment. For example... Figure 5 As shown, the computing device 500 includes an acquisition module 501 and a determination module 502; specifically, in the computing device 500, the modules are connected to each other through a communication path.

[0121] Module 501 is used to obtain available resource information for each resource pool associated with the target service. For details on the implementation, please refer to [link to implementation details]. Figure 4 The description of step 401 will not be repeated here.

[0122] Module 502 is used to determine the traffic distribution plan for the target service over a future time period based on the available resource information of each resource pool associated with the target service. For detailed implementation details, please refer to [link to implementation details]. Figure 4 The description of step 402 in the previous section will not be repeated here.

[0123] In one possible implementation, the available resource information for each resource pool indicates the number of idle instances in that resource pool during the time period, wherein the idle instances are those instances in that resource pool that were not occupied by other tenants during the time period.

[0124] In one possible implementation, the traffic distribution plan instructs the traffic of the target service to be allocated to each resource pool priority information within the time period.

[0125] In one possible implementation, the acquisition module 501 is further configured to acquire resource requirement information of the target service, wherein the resource requirement information indicates the predicted service traffic value of the target service within the time period; for specific implementation details, please refer to [link to implementation details]. Figure 4 The description of step 402 in the previous section will not be repeated here.

[0126] In one possible implementation, the sum of the service traffic of the target service allocated to each resource pool during the time period is equal to the predicted service traffic value, and the service traffic of the target service allocated to each resource pool during the time period does not exceed the maximum service traffic of the target service that the resource pool can bear.

[0127] In one possible implementation, the traffic splitting plan satisfies a cost strategy that minimizes the cost of the service traffic of the target service allocated to each resource pool during the time period.

[0128] In one possible implementation, the cost incurred by the service traffic of the target service allocated to each resource pool during the time period includes at least instance costs and communication costs; the instance cost indicates the rental cost of the instance required for the service traffic of the target service allocated to each resource pool during the time period, and the communication cost indicates the communication cost required for the distribution node to transmit the service traffic of the target service to each resource pool.

[0129] In one possible implementation, the maximum service traffic that each resource pool can handle for the target service is determined based on the number of instances that the resource pool can provide to the instance cluster of the target service within the time period and the resource conversion information of the target service, wherein the resource conversion information indicates the number of instances required to process a single service request of the target service.

[0130] For example, the implementation of the determination module 502 in the computing device 500 will be described below. Similarly, the implementation of the acquisition module 501 can be referenced to the implementation of the determination module 502.

[0131] When implemented in software, module 502 can be an application or code block running on a computer device. The computer device can be at least one of a physical host, virtual machine, container, or other computing device. Furthermore, the aforementioned computer device can be one or more. For example, module 502 can be an application running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application can be distributed within the same availability zone (AZ) or in different AZs. Similarly, the multiple hosts / virtual machines / containers used to run the application can be distributed within the same region or in different regions. Typically, a region can include multiple AZs.

[0132] Similarly, multiple hosts / virtual machines / containers used to run the application can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a region can include multiple VPCs, and a VPC can include multiple Availability Zones (AZs).

[0133] When implemented in hardware, the determining module 502 may include at least one computing device, such as a server. Alternatively, the determining module 502 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0134] The multiple computing devices included in module 502 can be distributed within the same Availability Zone (AZ) or in different AZs. Similarly, the multiple computing devices included in module 502 can be distributed within the same region or in different regions. Likewise, the multiple computing devices included in module 502 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0135] This application also provides a computing device 600. For example... Figure 6 As shown, the computing device 600 includes a bus 602, a processor 604, a memory 606, and a communication interface 608. The processor 604, the memory 606, and the communication interface 608 communicate with each other via the bus 602. The computing device 600 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 600.

[0136] Bus 602 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 6 The bus 602 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 602 may include a path for transmitting information between various components of the computing device 600 (e.g., memory 606, processor 604, communication interface 608).

[0137] Processor 604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0138] Memory 606 may include volatile memory, such as random access memory (RAM). Processor 604 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0139] The memory 606 stores executable program code, and the processor 604 executes the executable program code to implement the functions of the aforementioned acquisition module 501 and determination module 502, thereby realizing the service diversion method. That is, the memory 606 stores instructions for the computing device 500 to execute the service diversion method provided in this application.

[0140] The communication interface 608 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 600 and other devices or communication networks.

[0141] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0142] like Figure 7 As shown, the computing device cluster includes at least one computing device 600. The memory 606 of one or more computing devices 600 in the computing device cluster may store instructions for the same computing device 500 to execute the service offloading method provided in this application.

[0143] In some possible implementations, one or more computing devices 600 in the computing device cluster can also be used to execute some of the instructions of the computing device 500 for executing the service offloading method provided in this application. In other words, a combination of one or more computing devices 600 can jointly execute the instructions of the computing device 500 for executing the service offloading method provided in this application.

[0144] It should be noted that the memory 606 in different computing devices 600 within the computing device cluster can store different instructions for executing some functions of the computing device 500. That is, the instructions stored in the memory 606 of different computing devices 600 can implement the functions of one or more modules in the acquisition module 501 and determination module 602.

[0145] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computer device, it causes the at least one computer device to perform the above-described... Figure 4 or Figure 5 The service routing method executed by cloud management platform node 11 in this embodiment is described in [reference needed]. Figure 4 or Figure 5 The details of each step will not be repeated here.

[0146] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the above-described... Figure 4 or Figure 5 The service routing method executed by cloud management platform node 11 in this embodiment is described in [reference needed]. Figure 4 or Figure 5 The details of each step will not be repeated here.

[0147] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0148] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0149] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] Furthermore, the functional units (or modules) in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0151] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0153] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0154] The various illustrative logic units and circuits described in the embodiments of this application can be implemented or operate the described functions using a general-purpose processor, digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor; alternatively, it can also be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented using a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0155] The steps of the methods or algorithms described in the embodiments of this application can be directly embedded in hardware, software units executed by a processor, or a combination of both. The software units can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and storage medium can be housed in an ASIC.

[0156] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0157] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely illustrative descriptions of the application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Thus, if such modifications and modifications fall within the scope of the claims and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A business traffic diversion method, characterized in that, The method is applied to a cloud computing system, which includes at least a cloud management platform node, multiple resource pools and a traffic distribution node. Each resource pool includes multiple hosts for running services for multiple tenants. Each host runs at least one instance. Each resource pool creates an instance cluster corresponding to the target service of the target tenant. The instances in the instance cluster are used to run the target service. The method includes: The cloud management platform node obtains the available resource information of each resource pool associated with the target service, wherein the available resource information of each resource pool indicates the number of instances that the resource pool can provide to the instance cluster of the target service within a time period. The cloud management platform node obtains the resource requirement information of the target service, and the resource requirement information indicates the predicted business traffic value of the target service within the time period; The cloud management platform node generates a traffic distribution plan for the target service within the specified time period based on the resource demand information and the available resource information of each resource pool. The traffic distribution plan indicates the service traffic of the target service allocated to each resource pool within the specified time period. The sum of the service traffic of the target service allocated to each resource pool within the specified time period equals the predicted service traffic value, and the service traffic of the target service allocated to each resource pool within the specified time period does not exceed the maximum service traffic capacity of that resource pool. The maximum service traffic capacity of each resource pool is determined based on the number of instances in the instance cluster that the resource pool can provide to the target service within the specified time period and the resource conversion information of the target service. The resource conversion information indicates the number of instances required to process a single service request of the target service. The traffic distribution node allocates the traffic of the target service to the multiple resource pools within the time period according to the traffic distribution plan.

2. The method as described in claim 1, characterized in that, The available resource information for each resource pool indicates the number of idle instances in that resource pool during the specified time period, where the idle instances are those not occupied by other tenants during that time period.

3. The method as described in claim 1 or 2, characterized in that, The traffic allocation plan indicates that the traffic of the target service is allocated to each resource pool priority information within the time period.

4. The method according to any one of claims 1-3, characterized in that, The traffic allocation plan satisfies a cost strategy, which includes minimizing the cost of the target service traffic allocated to each resource pool during the time period.

5. The method as described in claim 4, characterized in that, The minimum cost incurred for the service traffic of the target service allocated to each resource pool during the time period includes instance costs and communication costs. The instance cost indicates the rental cost of an instance required for the service traffic of the target service allocated to each resource pool during the time period, and the communication cost indicates the communication cost required for the distribution node to transmit the service traffic of the target service to each resource pool.

6. A service diversion device, characterized in that, The device includes: The acquisition module is used to acquire the available resource information of each resource pool associated with the target service, wherein the available resource information of each resource pool indicates the number of instances that the resource pool can provide to the instance cluster of the target service within a time period; The acquisition module is further configured to acquire resource requirement information of the target service, wherein the resource requirement information indicates the predicted service traffic value of the target service within the time period; The processing module is configured to generate a traffic distribution plan for the target service within the specified time period based on the resource demand information and the available resource information of each resource pool; wherein the traffic distribution plan indicates the service traffic of the target service allocated to each resource pool within the specified time period; the maximum service traffic that each resource pool can handle for the target service is determined based on the number of instances in the instance cluster that the resource pool can provide to the target service within the specified time period and the resource conversion information of the target service, wherein the resource conversion information indicates the number of instances required to process a single service request of the target service; the sum of the service traffic of the target service allocated to each resource pool within the specified time period is equal to the predicted service traffic value, and the service traffic of the target service allocated to each resource pool within the specified time period does not exceed the maximum service traffic of the target service that the resource pool can handle.

7. The apparatus as claimed in claim 6, characterized in that, The available resource information for each resource pool indicates the number of idle instances in that resource pool during the specified time period, where the idle instances are those not occupied by other tenants during that time period.

8. The apparatus as claimed in claim 6 or 7, characterized in that, The traffic allocation plan is also used to indicate the priority information of each resource pool for the traffic of the target service during the time period.

9. The apparatus according to any one of claims 6-8, characterized in that, The traffic allocation plan satisfies a cost strategy, which includes minimizing the cost of the target service traffic allocated to each resource pool during the time period.

10. The apparatus as claimed in claim 9, characterized in that, The minimum cost incurred for the service traffic of the target service allocated to each resource pool during the time period includes instance costs and communication costs. The instance cost indicates the rental cost of an instance required for the service traffic of the target service to be allocated to each resource pool during the time period, and the communication cost indicates the communication cost required for the distribution node to transmit the service traffic of the target service to each resource pool.

11. A cloud computing system, characterized in that, The system includes at least a cloud management platform node, multiple resource pools and a traffic distribution node. Each resource pool includes multiple hosts for running services for multiple tenants. Each host runs at least one instance. Each resource pool has an instance cluster corresponding to the target service of the target tenant. The instances in the instance cluster are used to run the target service. The cloud management platform node is configured to: acquire available resource information for each resource pool associated with the target service, wherein the available resource information for each resource pool indicates the number of instances that the resource pool can provide to the instance cluster of the target service within a time period; acquire resource demand information for the target service, wherein the resource demand information indicates the predicted service traffic of the target service within the time period; generate a traffic distribution plan for the target service within the time period based on the resource demand information and the available resource information of each resource pool; wherein the traffic distribution plan indicates the service traffic of the target service allocated to each resource pool within the time period; the sum of the service traffic of the target service allocated to each resource pool within the time period equals the predicted service traffic, and the service traffic of the target service allocated to each resource pool within the time period does not exceed the maximum service traffic of the target service that the resource pool can handle; the maximum service traffic of the target service that each resource pool can handle is determined based on the number of instances that the resource pool can provide to the instance cluster of the target service within the time period and the resource conversion information of the target service, wherein the resource conversion information indicates the number of instances required to process a single service request of the target service. The traffic distribution node is used to distribute the traffic of the target service within the time period to the multiple resource pools according to the traffic distribution plan.

12. A computing device, characterized in that, The computing device includes a processor and memory; The memory is used to store computer-executed instructions; The processor is configured to execute computer execution instructions stored in the memory to cause the computing device to perform the method as described in any one of claims 1-5.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program, which, when invoked by a processor, executes the method according to any one of claims 1-5.

14. A computer program product containing instructions, characterized in that, When the instructions are executed by a cluster of computer devices, the cluster of computer devices causes the cluster of computer devices to perform the method as described in any one of claims 1-5.

Images