Load balancing method, system and apparatus, and electronic device

Abstract

Provided in the embodiments of the present disclosure are a load balancing method, system and apparatus, and an electronic device. The method comprises: acquiring a weight determination request, wherein the weight determination request comprises first resource usage information corresponding to a target pod, and the first resource usage information is related to host machine resource information currently used by the target pod and host machine resource information requested by the target pod; on the basis of the first resource usage information, a first weight and average resource usage information of a plurality of pods, determining a second weight corresponding to the target pod, wherein the first weight is a weight corresponding to the target pod when an access request was historically allocated to the target pod, and the plurality of pods include the target pod; and on the basis of the second weight of the target pod, allocating an access request to the target pod. Therefore, a weight is dynamically allocated to a pod on the basis of the resource occupancy of the pod, and an access request is allocated to the pod on the basis of the dynamically allocated weight, thereby facilitating the scaling-down of a plurality of pods, and reducing the cost.

Description

Load balancing methods, systems, devices and electronic equipment

[0001] This application claims priority to Chinese Patent Application No. 202410509880.9, filed on April 25, 2024, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure relates to a load balancing method, system, apparatus, and electronic device. Background Technology

[0003] For microservices, the runtime environment, operating system, and corresponding program instructions required by the microservice can be encapsulated in container groups (PODs) to enable rapid setup and migration of microservices across different physical servers. Multiple container groups encapsulating microservices form a POD cluster for the microservice.

[0004] To ensure a relatively balanced load across multiple containers, load balancing techniques can be used to distribute access traffic to multiple PODs.

[0005] Current load balancing algorithms cannot fully utilize container groups, resulting in higher costs for microservices. Summary of the Invention

[0006] This disclosure provides a load balancing method, system, apparatus, and electronic device.

[0007] In a first aspect, embodiments of this disclosure provide a container cluster load balancing method, the method comprising: obtaining a weight determination request, the weight determination request including first resource usage information corresponding to a target container group, the first resource usage information being related to host resource information currently used by the target container group and host resource information requested by the target container group; determining a second weight corresponding to the target container group based on the first resource usage information, a first weight, and average resource usage information of multiple container groups; wherein the first weight is the weight corresponding to the target container group when historically allocating access requests to the target container group, and the multiple container groups include the target container group; and allocating access requests to the target container group based on the second weight of the target container group.

[0008] Secondly, embodiments of this disclosure provide a container cluster load balancing method, the method comprising: obtaining host resource information currently used by a target container group; determining first resource usage information of the target container group based on the currently used host resource information and the host resource information requested by the target container group; generating a weight determination request based on the first resource usage information; and sending the weight determination request to a controller, so that the controller determines a second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were historically allocated to the target container group.

[0009] Thirdly, embodiments of this disclosure provide a container cluster load balancing method, the method comprising: obtaining a second weight of a target container group, wherein the second weight of the target container group is determined based on the current first resource usage information of the target container group, a first weight, and the average resource usage information of multiple container groups, the first weight being the weight corresponding to the target container group when historically allocating access requests to the target container group; and allocating access requests to the target container group based on the second weight.

[0010] Fourthly, this disclosure provides a container cluster load balancing system, including: multiple container groups running on a host machine, a controller, and a distributor, wherein an agent module runs in each container group; wherein the agent module is configured to: obtain host machine resource information currently used by a target container group; determine first resource usage information of the target container group based on the currently used host machine resource information and the host machine resource information requested by the target container group; generate a weight determination request based on the first resource usage information; and send the weight determination request to the controller, so that the controller determines a second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the previous allocation of access requests to the target container group; the controller is configured to: obtain the weight determination request, wherein the weight determination request... The distribution mechanism includes: first resource usage information corresponding to a target container group, which is related to the host resources currently used by the target container group and the host resources requested by the target container group; determining a second weight corresponding to the target container group based on the first resource usage information, a first weight, and the average resource usage information of multiple container groups; wherein the first weight is the weight corresponding to the target container group when historically allocating access requests to the target container group, and the multiple container groups include the target container group; allocating access requests to the target container group based on the second weight of the target container group; and the distributor being configured to: obtain the second weight of the target container group, wherein the second weight of the target container group is determined based on the current first resource usage information, the first weight, and the average resource usage information of multiple container groups; and allocating access requests to the target container group based on the second weight.

[0011] Fifthly, embodiments of this disclosure provide a container cluster load balancing device, the device comprising: a first acquisition unit, configured to acquire a weight determination request, the weight determination request including first resource usage information corresponding to a target container group, the first resource usage information being related to host resource information currently used by the target container group and host resource information requested by the target container group; a first determination unit, configured to determine a second weight corresponding to the target container group based on the first resource usage information, a first weight, and average resource usage information of multiple container groups; wherein the first weight is the weight corresponding to the target container group when historically allocating access requests to the target container group, and the multiple container groups include the target container group; and a first allocation unit, configured to allocate access requests to the target container group based on the second weight of the target container group.

[0012] Sixthly, embodiments of this disclosure provide a container cluster load balancing device, the device comprising: a second acquisition unit, configured to acquire host resource information currently used by a target container group; a second determination unit, configured to determine first resource usage information of the target container group based on the currently used host resource information and the host resource information requested by the target container group; a third determination unit, configured to generate a weight determination request based on the first resource usage information; and a sending unit, configured to send the weight determination request to a controller, so that the controller determines a second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were historically allocated to the target container group.

[0013] In a seventh aspect, embodiments of this disclosure provide a container cluster load balancing device, the device comprising: a third acquisition unit, configured to acquire a second weight of a target container group, wherein the second weight of the target container group is determined based on the current first resource usage information of the target container group, a first weight, and average resource usage information of multiple container groups, and the first weight is the weight corresponding to the target container group when historically allocating access requests to the target container group; and a second allocation unit, configured to allocate access requests to the target container group based on the second weight.

[0014] Eighthly, embodiments of this disclosure provide an electronic device, including: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the at least one processor to perform the methods described in the first, second, and third aspects above, as well as various possible designs of the first, second, and third aspects.

[0015] Ninthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the methods described in the first, second, and third aspects above, as well as various possible designs of the first, second, and third aspects.

[0016] In a tenth aspect, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the methods described above in the first, second, and third aspects, as well as various possible designs of the first, second, and third aspects. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 is a schematic diagram of the application scenarios provided in this disclosure;

[0019] Figure 2 is a schematic flowchart of the load balancing method provided in this disclosure;

[0020] Figure 3 is a schematic flowchart of the load balancing method provided in this disclosure;

[0021] Figure 4 is a schematic flowchart of the load balancing method provided in this disclosure;

[0022] Figure 5 is a schematic diagram of the load balancing system provided in this disclosure;

[0023] Figure 6 is a structural block diagram of the load balancing device provided in an embodiment of this disclosure;

[0024] Figure 7 is a structural block diagram of the load balancing device provided in an embodiment of this disclosure;

[0025] Figure 8 is a structural block diagram of the load balancing device provided in an embodiment of this disclosure;

[0026] Figure 9 is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] Figure 1 is a schematic diagram of an application scenario of this disclosure. As shown in Figure 1, the application scenario includes a terminal device 101, a container group (POD) 102, and a distributor 103. The POD 102 runs on a host machine 104. The POD 102 runs a preset service instance. One or more PODs 102 can run on a single host machine 104. Multiple PODs 102 can form a POD cluster. Multiple PODs can run on one or more host machines 104.

[0029] Multiple terminal devices 101 can send access requests related to preset service instances to the POD cluster. Distributor 103 distributes multiple access requests to different PODs 102 according to a load balancing algorithm, and the preset service instances in different PODs 102 process and respond to the multiple access requests.

[0030] In one example, distributor 103 can use a static load balancing algorithm to distribute multiple access requests to multiple PODs. Static load balancing algorithms, such as round-robin, IP address hashing, URL hashing, and least connections, distribute multiple access requests to multiple backend PODs running preset service instances according to static allocation rules. If the performance of the multiple hosts hosting the multiple PODs is uniform, static load balancing algorithms can achieve good load balancing results. However, static load balancing algorithms do not consider the performance differences between the multiple hosts.

[0031] Typically, multiple PODs in a POD cluster run on different host machines. Inevitably, these numerous host machines exhibit differences in hardware and / or software performance. The processing power of host machines with different performance levels also varies significantly, resulting in uneven resource consumption for each POD. Taking the Central Processing Unit (CPU) as an example, for the same access request, a POD running on a host with superior processing power will actually use less CPU, thus having a lower peak utilization; conversely, a POD running on a host with inferior processing power will actually use more CPU, thus having a higher peak utilization.

[0032] For example, service instance A is running across 100 Points of Demand (PODs), with an average CPU consumption of 17% across these 100 PODs. However, in reality, 50 of these PODs have a CPU consumption of 12%, and the remaining 50 PODs have CPU consumption between 25% and 28%, showing inconsistent CPU consumption rates. In some application scenarios, the CPU consumption of the less performing servers will reach its limit, thus preventing the POD cluster corresponding to service A from further scaling down. This hinders further optimization of the POD cluster's CPU utilization and limits further cost reduction.

[0033] Therefore, for a POD cluster running on multiple host machines with different performance levels, the inconsistent peak CPU utilization of the PODs, with some PODs having higher peak resource utilization, will lead to an overall decrease in service performance.

[0034] Additionally, to reduce service costs, the POD cluster can be scaled down. However, scaling down reduces the number of PODs in the cluster, increasing the load on individual PODs. Excessive CPU utilization by a POD can severely impact service performance.

[0035] To address the issue of static load balancing algorithms severely impacting service performance in the above example scenario, in one example, for a POD cluster running on multiple hosts with varying performance, a weighted load balancing algorithm can be used to determine the weight of each host and distribute multiple access requests to the PODs running on each host based on the host's weight.

[0036] Weighted load balancing algorithms typically assign higher weights to high-performing hosts to improve the overall cluster utilization. However, since services usually run in PODs (Portable Container Registries), the online and offline processes of each container become extremely frequent, and statically determining the weight of each host cannot adapt to scenarios with frequent online and offline processes.

[0037] In another example, a dynamic load balancing algorithm can be used to distribute multiple access requests. Dynamic load balancing algorithms typically allocate access requests to each POD based on the resource usage of the host machine where the POD resides. However, because dynamic load balancing algorithms assign weights to PODs running on the host machine based on the host's resource usage rather than delving into the POD's own resource consumption, the computing power of the high-performance host machine cannot be fully utilized, resulting in wasted resources.

[0038] In their research on reducing the cost of pre-installed services, the inventors discovered that, on the one hand, performance differences exist between different host machines. For example, there are significant variations in CPU clock speeds, the frequency and size of L1, L2, and L3 caches, and pipeline optimization methods. CPUs with higher clock speeds require less time to process the same access request, or consume fewer CPUs. Furthermore, inconsistent cache frequencies lead to inconsistent data delivery speeds to the CPU, resulting in inconsistent overall efficiency in processing access requests.

[0039] Furthermore, the operating environment on different operating systems can also affect the performance of default services. For example, whether Turbo Boost is enabled and the supported microcode version will affect the efficiency of processing access requests.

[0040] On the other hand, when different container groups are co-located on the host machine, the resource utilization of the host machine will increase. The resource utilization of the host machine will affect the performance of the pre-defined service instances running in the container groups. When scheduling processes, the host kernel can prioritize waking up the CPU cores previously used by the pre-defined service processes, provided that the L1 and L2 caches corresponding to these CPU cores are still valid for the pre-defined service processes to be scheduled, meaning that the L1 or L2 caches still store the data required by the processes. However, when these CPU cores are not idle, for example, if there are co-located container groups on the host machine, the overall CPU utilization of the host machine will become very high, such as 70%. Due to the co-location of multiple container groups (multiple container groups can run different service instances), the probability of processes of different service container groups running on different CPU cores increases. After process 1 of service 1 finishes, CPU core 1 runs process 2 of service 2. At this time, the cache corresponding to CPU core 1 no longer contains the data required for process 1 of service 1 to run. Similarly, when CPU logical core 1 is running process 2 of service 2, there is no data in the cache required for process 2 to run. Therefore, when the CPU logical core utilization is high, the runtime of a single instruction is lengthened, the performance of the default service decreases, and the utilization of host resources increases further.

[0041] To address the issue of wasted resources caused by inconsistent host machine performance and the inability to fully utilize the computing power of high-performance hosts in a POD cluster with mixed POD deployments, this disclosure provides a solution that dynamically determines a container group's second weight based on its current first resource usage information and first weight. Access requests are then allocated to the container group according to this second weight. This approach balances the challenges of inconsistent host machine performance and mixed container group deployments. When processing access requests allocated using this solution, each container group operates with a relatively balanced resource utilization distribution, ensuring the correctness of pre-defined services and facilitating the scaling down of these services to reduce costs.

[0042] Please refer to Figure 2, which is a schematic flowchart of the load balancing method provided in this disclosure. As shown in Figure 2, the method includes the following steps:

[0043] S201: Obtain weight determination request. The weight determination request includes the first resource usage information corresponding to the target container group. The first resource usage information is related to the host resource information currently used by the target container group and the host resource information requested by the target container group.

[0044] S202: Based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups, determine the second weight corresponding to the target container group; wherein, the first weight is the weight corresponding to the target container group when historical access requests were allocated to the target container group, and the multiple container groups include the target container group.

[0045] S203: Assign an access request to the target container group based on the second weight of the target container group.

[0046] In this embodiment, the execution entity of the load balancing method can be applied to the controller. The controller can run on a server.

[0047] The target container group here can be any one of multiple container groups (PODs). Each container group can include multiple containers, storage resources, an independent network IP address, etc. Multiple containers in a POD need to work together and share resources to provide services. A POD includes a main container and several sidecar containers. The main container can run pre-defined service instances. The sidecar containers assist the main container in completing the corresponding services. These pre-defined services can be various types of services, such as microservices.

[0048] Multiple containers corresponding to the same POD can run on the same host machine. The host machine can be a physical server or a virtual server.

[0049] POD can correspond to host resources requested from the host in advance. The requested host resources include, but are not limited to, the number of CPUs, memory size, and I / O interface size.

[0050] When POD is run, it generates information about the actual resource usage of the host machine.

[0051] The current primary resource usage information can be determined based on the host resources currently being used by the POD and the host resources requested by the POD. This primary resource usage information includes the primary resource utilization rate.

[0052] The aforementioned weight determination request can be sent by the target container group.

[0053] As one implementation, an agent module also runs within the POD. The aforementioned weight determination request can be sent to the controller by the agent module. The agent module can run within an auxiliary container of the POD. The agent module can determine the first resource usage information at preset time intervals.

[0054] The preset time interval can be, for example, 1 minute, 2 minutes, etc. The preset time interval can be set according to the specific application scenario, and there is no limitation here.

[0055] The proxy module can determine the first resource usage information based on the host resource information currently used by the POD and the host resource information requested by the POD.

[0056] In some application scenarios, the controller can store the first weight of the POD. The proxy module can send a weight determination request to the controller, which is generated by the proxy module based on the first resource usage information. Upon receiving the weight determination request, the controller can read the first weight of the POD from the locally stored data.

[0057] In some embodiments, the POD may store its own corresponding first weight. In these embodiments, the agent module can obtain the first weight stored in the POD, generate a weight determination request based on the determined first resource usage information and the first weight, and send the weight determination request to the controller. In these embodiments, the controller can obtain the first weight from the weight determination request.

[0058] The aforementioned weight determination request may also include one or more of the following information: information about the preset service, information about the POD cluster where multiple PODs reside, information about the data center where the host machine is located, etc.

[0059] In these implementations, a proxy module for performing weight adjustments is set up in the POD, thereby decoupling the weight adjustment logic from the business code of the preset services and building a loosely coupled architecture. This reduces the mutual influence between the weight adjustment of the target container group and the preset services provided to users.

[0060] The aforementioned controller runs on a host machine, which can be a host machine running a POD or a standalone host machine.

[0061] In some application scenarios, the controller described above can receive weight determination requests from multiple PODs. The controller can then determine the average resource usage of multiple PODs in the POD cluster based on the initial resource usage information of each POD.

[0062] The first resource usage information of the target container group may include the first resource utilization rate. The first resource utilization rate of the target container group is determined by the host resource information currently used by the target container group and the host resource information requested by the target container group.

[0063] Average resource information can include the average resource utilization of multiple PODs.

[0064] Taking CPU as an example, the first resource usage information of POD can include the first CPU utilization rate. The first CPU utilization rate CR1 is determined by the following formula (1):

[0065] in,

[0066] CRN represents the number of CPU logical units currently used by the POD on the host machine, and CRP represents the number of CPU logical units requested by the POD on the host machine.

[0067] If the POD cluster includes POD1, POD2 and POD3, the first CPU utilization rate of POD1 is calculated as CR11, the first CPU utilization rate of POD2 is CR12 and the first CPU utilization rate of POD3 is CR13 using the above formula (1).

[0068] The average CPU utilization CR of POD1, POD2 and POD3 in the POD cluster can be calculated using the following formula (2):

[0069] Similarly, the average resource utilization of other resources (such as memory) in the POD cluster can be calculated.

[0070] For each POD, the controller can determine the second weight of the container group based on the POD's first resource usage information, first weight, and average resource usage information of the POD cluster.

[0071] The first weight here can be the weight of the target container group when historical access requests were assigned to the target container group.

[0072] In some embodiments, the average resource usage information includes the average resource utilization rate, and the first resource usage information includes the first resource utilization rate, which represents the proportion of the host resources currently used by the target container group in the requested host resources; the second weight of the target POD is positively correlated with the first weight, the average resource utilization rate of the POD cluster to which the target POD is located, and negatively correlated with the first resource utilization rate of the target POD.

[0073] Taking CPU as an example, after receiving the weight determination request from the agent module of the target POD, the controller can calculate the average CPU utilization of multiple PODs in the POD cluster where the target POD is located. The second weight corresponding to the target POD is determined based on the target POD's first CPU utilization, first weight, and the average CPU utilization of multiple PODs.

[0074] Schematic, the second weight of the target POD can be calculated by the following formula (3):

[0075] in,

[0076] W2 is the second weight of the target POD, W1 is the first weight of the target POD, CR is the average CPU utilization of multiple PODs, and CR1 is the current first CPU utilization of the target POD.

[0077] As can be seen from the above formula (3), the second weight of the target POD is related to the first weight of the target POD, the average CPU utilization of the POD cluster where the target POD is located, and the first CPU utilization of the target POD. The second weight is positively correlated with the first weight of the target POD and the average CPU utilization of the POD cluster, and negatively correlated with the first resource utilization. That is to say, the higher the first resource utilization, the lower the second weight, and the fewer access requests are allocated to the target POD based on the second weight. In other words, the higher the first resource utilization of the target POD, the fewer access requests can be allocated to the target POD.

[0078] If the first CPU utilization of the target POD remains unchanged, while the average CPU utilization of the POD cluster increases, it indicates that the CPU utilization of other PODs has increased. Therefore, the second weight of the target POD can be increased, that is, more access requests are allocated to the target POD through the second weight, and access requests allocated to other PODs are reduced, thereby reducing the CPU utilization of the POD cluster.

[0079] It is understandable that if the resource information includes other resources, the second weight of the other resources can be calculated in the above manner.

[0080] If the resource information includes multiple resources, a preset ratio can be set for the second weight corresponding to each resource. For the target POD, when calculating the second weight of the target POD, the sum of the products of the second weight of each resource and the preset ratio is calculated, and this sum is used as the final second weight of the target POD.

[0081] In some application scenarios, if the target POD's first CPU utilization rate is higher than a preset CPU utilization threshold, the controller can calculate the target POD's second weight and synchronize this second weight to the target POD's proxy module and distributor. The distributor can then distribute access requests to the target POD based on its second weight.

[0082] After determining the second weight of the target container group, access requests can be allocated to the target container based on this second weight. Specifically, after obtaining the second weight of the target container group, the controller can send it to the dispatcher. The dispatcher then allocates access requests to the target container group based on its second weight. In some application scenarios, the current weight of other container groups within a plurality of container groups can be their first weight. In other application scenarios, the current weight of other container groups within a plurality of container groups can be their respective second weights.

[0083] Based on the target container group's second weight, access requests are allocated to the target container group. This allows for rapid adjustment of the number of access requests allocated to the target POD when its resource usage deviates significantly from the average resource usage of the POD cluster, thus alleviating the load pressure on the target container group in a timely manner. It can be understood that after each calculation of the second weight and allocation of access requests to the target POD based on that weight, the aforementioned second weight of the POD can be considered as the target POD's first weight.

[0084] In this embodiment, a weight determination request is obtained. This request includes first resource usage information corresponding to the target container group. This first resource usage information is related to the host machine resources currently used by the target container group and the host machine resources requested by the target container group. Based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups, a second weight corresponding to the target container group is determined. The first weight is the weight corresponding to the target container group when historical access requests were allocated to it, and the multiple container groups include the target container group. An access request is allocated to the target container group based on its second weight. This scheme can accommodate situations where host machine performance is inconsistent and container groups running different service instances are mixed on the host machine. When multiple container groups process access requests allocated using this scheme, they operate in a relatively balanced resource utilization distribution, ensuring the efficiency and correctness of the services provided to users. Furthermore, it facilitates scaling down multiple container groups, reducing costs.

[0085] In some embodiments, step S203 includes:

[0086] In response to the first resource usage information of the target container group satisfying the first preset condition, an access request is allocated to the target container group based on the second weight.

[0087] Schematic, the aforementioned first preset condition includes the first resource utilization rate indicated by the first resource utilization information being greater than or equal to a preset resource utilization rate threshold, etc.

[0088] As one implementation method, the average resource usage information includes the average resource utilization rate, and the first resource usage information includes the first resource utilization rate; the first preset condition includes: the offset of the first resource utilization rate relative to the average resource utilization rate is greater than or equal to the first preset threshold.

[0089] One approach is to calculate the difference between the first resource utilization rate and the average resource utilization rate, and use the absolute value of the difference as the offset of the first utilization rate relative to the average resource utilization rate.

[0090] The aforementioned first preset threshold can be pre-set and adjusted according to specific application scenarios. For example, the first preset threshold could be 10%.

[0091] In these embodiments, an access request based on a second weight is only triggered after the first resource usage information meets the first preset condition. Frequent changes in weights will also lead to frequent changes in the access requests allocated to container groups, which will cause system stability issues. Since the distributor distributes access requests to each container group based on the weight corresponding to each container group, and only triggers the allocation of access requests based on the second weight after the first resource usage information meets the preset condition, the system stability issues caused by frequent weight changes can be avoided.

[0092] In some embodiments, step S203 includes:

[0093] The process involves assigning access requests to the target container group in stages and multiple rounds, based on the second weight.

[0094] In these embodiments, if the rate of change of the second weight relative to the first weight is large, the allocation of access requests based on the second weight can be completed in stages and multiple rounds. If the first weight was originally 50 and the second weight is 100, the first stage completes the first round of weight adjustment, for example, changing the weight of the target POD from 50 to 70; then in the next round, it is determined whether the first weight of the target POD should be adjusted to 100 based on the first weight of 70. If it needs to be adjusted to 100, the weight of the POD can be adjusted to 85 in the second round, and so on. By completing the allocation of access requests based on the second weight in stages and multiple rounds, the problems caused by excessive adjustment of the POD weight in a single instance can be avoided, which is conducive to ensuring the stability of the load balancing system.

[0095] In some embodiments, the method further includes:

[0096] In response to the first resource usage information of the target container group not meeting the first preset condition, an access request is allocated to the target container group based on the first weight corresponding to the target container group.

[0097] Taking the first resource information, including the first CPU utilization rate, as an example, when the first CPU utilization rate is lower than the first preset threshold corresponding to the CPU, the first weight of the target container group can still be used to allocate access requests to the target container group in the past. This reduces the frequency of changing the weight of the access request allocation to the target container group, which can help ensure the stability of the load balancing system.

[0098] In some embodiments, the load balancing method further includes:

[0099] Display one or more of the following information:

[0100] Average resource usage information for multiple container groups;

[0101] The first resource usage information corresponding to each of the multiple container groups.

[0102] In these embodiments, the controller can generate average resource usage information for multiple container groups in a container group cluster; and / or first resource usage information for a single container group. In some embodiments, the controller can display the above information using a display device on the host machine.

[0103] By displaying the above information, users can intuitively understand the average resource usage and primary resource usage of the container cluster.

[0104] The following scenario illustrates how CPU utilization of the POD cluster corresponding to the preset service was collected without applying this load balancing solution. For example, the CPU utilization of each POD in the POD cluster was collected from 15:37 to 17:16 on March 13th. Analysis shows that the CPU utilization of a single POD has relatively small differences over time. However, the CPU utilization of different PODs at the same time varies widely, ranging from about 20% to about 60%. Therefore, the uneven CPU utilization of different PODs in the POD cluster limits the scaling down of the POD cluster and prevents further reduction in the cost of the preset service.

[0105] The load balancing method provided in this disclosure can be applied to the POD cluster providing the preset service. After applying the method, relevant data is collected. The CPU utilization of each POD in the POD cluster was collected from 15:37 to 17:16 on March 14th. Analysis shows that the CPU utilization of individual PODs exhibits relatively small differences over time. The range of CPU utilization distribution among different PODs at the same time is small, with the difference in CPU utilization across the POD cluster at the same time being approximately 5%. Therefore, the CPU utilization of different PODs in the POD cluster is relatively balanced, which is beneficial for scaling down multiple container groups providing the preset service to reduce the cost of the preset service.

[0106] You can also compare the average CPU utilization of the POD cluster before and after applying the load balancing method provided in this disclosure. You can monitor the average CPU utilization of the POD cluster after scaling down using the load balancing method provided in this disclosure from 15:37 to 17:16 on March 14th, and the average CPU utilization of the POD cluster before scaling down from 15:37 to 17:16 on March 13th without using the load balancing method provided in this disclosure. The average CPU utilization of the POD cluster using the load balancing method provided in this disclosure is higher than the average CPU utilization of the POD cluster without using the load balancing method provided in this disclosure.

[0107] The CPU utilization of PODs with poor host performance can also be compared. From 20:45 to 22:08 on March 13th, the CPU utilization distribution of PODs with poor host performance using the load balancing method provided in this disclosure and without using the load balancing method provided in this disclosure were monitored. At the same time, after using the load balancing method provided in this disclosure and scaling down, the CPU utilization of PODs with poor host performance was lower than that of PODs with poor host performance before scaling down without using the load balancing method provided in this disclosure. Furthermore, before scaling down, the CPU utilization of PODs with poor host performance without using the load balancing method provided in this disclosure fluctuated significantly at different times, showing poor stability. After scaling down, the CPU utilization of PODs with poor host performance using the load balancing method provided in this disclosure showed smaller fluctuations at different times, exhibiting better stability.

[0108] Please refer to Figure 3, which is a schematic flowchart of the load balancing method provided in this disclosure. As shown in Figure 3, the method includes the following steps:

[0109] S301: Obtain information about the host resources currently used by the target container group.

[0110] In this embodiment, the execution entity can be a proxy module running in the target container group. The target container group can be any one of multiple container groups corresponding to a preset service. Each of these multiple container groups can include a main container and auxiliary containers.

[0111] A primary container in a container group can run a pre-defined service instance, while secondary containers can provide data, resources, and other support for the aforementioned pre-defined service instance.

[0112] In this embodiment, the proxy module can run in an auxiliary container of the target container group. One proxy module can run in each container group. The auxiliary container where the proxy module resides can share processes with the main container. It is understood that one proxy module can run in each container group.

[0113] The proxy module of the target container group can obtain information about the host resources currently used by the target container group in various ways.

[0114] In some embodiments, the host machine resource information currently used by the container group where the agent module is located is obtained through a preset communication interface between the target container group and the host machine.

[0115] The aforementioned proxy module can read the host machine resource information currently used by the target container group from the host machine through a preset communication interface. This information includes the number of CPU logical cores, memory usage, etc. The preset communication interface can be an interface provided by the host machine.

[0116] In some embodiments, step S301 includes: in response to the current time meeting a second preset condition, obtaining host resource information used by the target container group, wherein the second preset condition includes: the time interval between the current time and the time when the first resource information of the target container group was determined in the past is greater than or equal to a preset time interval.

[0117] The time when the first resource information of the target container group is determined here can be the time when the first resource usage information of the container group was last determined. The above preset time interval is 1 minute, 2 minutes, etc.

[0118] In other words, the proxy module collects host resource information used by the target container group every preset time interval. Based on the host resource information collected each time, it determines the first resource usage information for that time and determines the weight determination request for that time.

[0119] In these embodiments, when collecting host resource usage information, if the time difference between the current collection time and the previous collection time is too small, and the host resource usage information is fluctuating due to system adjustments to access requests, the current host resource usage information may differ significantly from the previous information. This generates spikes in the first resource usage information, which can cause a large weight change rate. If the current time meets the second preset condition, acquiring the host resource information used by the target container group ensures that the obtained first resource usage information is relatively stable and will not affect the weight change rate due to fluctuations caused by system adjustments to access requests.

[0120] S302: Based on the currently used host resource information and the host resource information requested by the target container group, determine the first resource usage information of the target container group.

[0121] In some embodiments, the proxy module described above can read the resource information requested by the target container group from the target container group.

[0122] The aforementioned proxy module can determine the first resource usage information based on the currently used host machine resource information and the resource information requested by the target container group.

[0123] Specifically, formula (1) can be used to calculate the first resource usage information. For a detailed explanation, please refer to the relevant parts of the embodiment shown in Figure 2, which will not be repeated here.

[0124] S303: Generate a weight determination request based on the first resource usage information.

[0125] The aforementioned proxy module can generate a weight determination request based on the first resource usage information. This weight determination request may also include one or more of the following information: information about the preset service, information about the POD cluster where the target POD resides, and information about the data center where the host machine is located.

[0126] At regular intervals, the proxy module of the target container group can generate a weight determination request. This can be viewed as multiple periods on a timeline, with the proxy module of the target container group sending a weight determination request to the controller within each period. For each weight determination request received within a period, a second weight corresponding to that period can be determined for the target container group based on the weight determination request. S304: The weight determination request is sent to the controller, so that the controller determines the second weight of the target container group based on the first resource usage information and the first weight, in order to allocate access requests to the target container group based on the second weight. The first weight is the weight corresponding to the target container group when access requests were previously allocated to it.

[0127] In some application scenarios, the first weights corresponding to multiple container groups can be stored in the controller or in electronic devices accessible to the controller.

[0128] In these application scenarios, after receiving a weight determination request from the target container group, the controller can extract the first weight of the target container group from its own stored data, or obtain the first weight of the target container group from an accessible electronic device that stores the weight data of the container group.

[0129] In some application scenarios, the proxy module of the target container group can store the first weight corresponding to the target container group, or the proxy module can access the electronic device that stores the first weight of the target container group. The first weight is the weight that was historically assigned to the target container group for access requests.

[0130] In these application scenarios, step S303 above may include the following steps:

[0131] First, obtain the first weight of the target container group.

[0132] Secondly, a weight determination request is generated based on the first resource usage information and the first weight.

[0133] In these application scenarios, the proxy module of the target container group can extract the first weight of the target container group from its own stored data, or access the electronic device that stores the first weight of the target container group to obtain the first weight.

[0134] After obtaining the first weight, a weight determination request can be generated based on the first weight and the first resource usage information. Then, the aforementioned proxy module can send the weight determination request for the target container group to the controller.

[0135] The proxy module of the target container group can send the weight determination request to the controller. After receiving the weight determination request, the controller determines the second weight of the target container group based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups in the current period. Specifically, the specific implementation of the controller determining the second weight can be referred to the description of the relevant parts of the embodiment shown in Figure 2, which will not be repeated here.

[0136] As one implementation, after determining the second weight of the target container group, the controller can send the second weight to the dispatcher. The dispatcher can then allocate access requests to each container group based on either the second weight or the first weight of the target container group.

[0137] In this embodiment, the proxy module obtains the host machine resource information currently used by the target container group; then, based on the currently used host machine resource information and the host machine resource information requested by the target container group, it determines the first resource usage information of the target container group; next, it generates a weight determination request based on the first resource usage information; finally, it sends the weight determination request to the controller, so that the controller determines the second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight. The first weight is the weight corresponding to the previous allocation of access requests to the target container group, realizing dynamic determination of the target container group's weight. This is beneficial for allocating access requests to the target container group based on the dynamically determined target container group weight. It can accommodate situations where host machine performance is inconsistent and container groups with different services are mixed on the host machine, allocating access requests to various container groups. It is also beneficial for scaling down multiple container groups and reducing costs.

[0138] Please refer to Figure 4, which is a schematic flowchart of the load balancing method provided in this disclosure. As shown in Figure 4, the method includes the following steps:

[0139] S401: Obtain the second weight of the target container group, wherein the second weight of the target container group is determined based on the current first resource usage information, the first weight, and the average resource usage information of multiple container groups of the target container group, and the first weight is the weight of the target container group when access requests were allocated to the target container group in the past.

[0140] S402: Assign access requests to the target container group based on the second weight.

[0141] In this embodiment, the load balancing method can be executed by a distributor, which can run on a host machine. The host machine on which the distributor runs can be the same server as the host machine running the container group, or it can be a separate server.

[0142] In some embodiments, the dispatcher can obtain the second weight of each target container group from the proxy module corresponding to the target container group.

[0143] In some embodiments, the dispatcher can obtain the second weight corresponding to each target container group from the controller.

[0144] The aforementioned second weight is determined based on the current first resource usage information of the target container group, the first weight, and the average resource usage information of multiple container groups.

[0145] Specifically, the second weight can be determined based on formula (3), and the relevant part of the embodiment shown in Figure 2 can be referred to for details, which will not be repeated here.

[0146] After receiving the second weight of the target container group, the dispatcher can allocate access requests to the target container group based on the second weight. Specifically, the dispatcher can determine the current weights of multiple container groups in the container group cluster. The current weights of other container groups in the container group cluster besides the target container group can include the first weight and / or the second weight. For example, one other container group may have the first weight as its current weight, and another other container group may have the second weight as its current weight (that is, the controller determines the second weight based on the weight determination request sent by that other container group).

[0147] The dispatcher can allocate access requests to each container group based on their current weight. As one implementation, the number of access requests allocated to a target container group can be positively correlated with the second full weight.

[0148] The aforementioned second weight is determined by the current first resource usage information of the target container group, the first weight, and the dynamics of multiple container groups. Therefore, the dispatcher can dynamically adjust the number of access requests to the target container group based on the dynamic weight of the target container group.

[0149] In this embodiment, a second weight of the container group is obtained. This second weight is determined based on the container group's current first resource usage information, its first weight, and the average resource usage information of multiple container groups. The first weight corresponds to the weights historically assigned to the container group. Access requests are then assigned to the container group based on the second weight. This achieves the allocation of access requests to the target container group according to the dynamically determined weight. It can accommodate situations where host machine performance is inconsistent and container groups are mixed on the host machine, thus facilitating the scaling down of preset services and reducing service costs.

[0150] Please refer to Figure 5, which is a schematic diagram of the load balancing system provided in this disclosure. As shown in Figure 5, the load balancing system includes a host machine 501, a container group 502, a controller 503, and a distributor 504 running on the host machine 501. An agent module 5021 runs in the container group 502.

[0151] The proxy module 5021 is used to: obtain the host resource information currently used by the target container group; determine the first resource usage information of the target container group based on the currently used host resource information and the host resource information requested by the target container group; generate a weight determination request based on the first resource usage information; and send the weight determination request to the controller so that the controller can determine the second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were allocated to the target container group in the past.

[0152] The controller 503 is configured to: obtain a weight determination request, the weight determination request including first resource usage information corresponding to the target container group, the first resource usage information being related to the host resource information currently used by the target container group and the host resource information requested by the target container group; determine a second weight corresponding to the target container group based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups; wherein, the first weight is the weight corresponding to the target container group when historically allocating access requests to the target container group, and the multiple container groups include the target container group; and allocate access requests to the target container group based on the second weight of the target container group.

[0153] Distributor 504 is used to: obtain a second weight of a target container group, wherein the second weight of the target container group is determined based on the current first resource usage information of the target container group, the first weight, and the average resource usage information of multiple container groups; and distribute access requests to the target container group based on the second weight.

[0154] Corresponding to the load balancing method of the embodiment shown in Figure 2 above, Figure 6 is a structural block diagram of the load balancing device provided in the embodiments of this disclosure. For ease of explanation, only the parts related to the embodiments of this disclosure are shown. Referring to Figure 6, the device 60 includes a first acquisition unit 601, a first determination unit 602, and a first allocation unit 603.

[0155] The first acquisition unit 601 is used to acquire a weight determination request. The weight determination request includes first resource usage information corresponding to the target container group. The first resource usage information is related to the host resource information currently used by the target container group and the host resource information requested by the target container group.

[0156] The first determining unit 602 is used to determine the second weight corresponding to the target container group based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups; wherein, the first weight is the weight corresponding to the target container group when historical access requests were allocated to the target container group, and the multiple container groups include the target container group.

[0157] The first allocation unit 603 is used to allocate access requests to the target container group based on the second weight of the target container group.

[0158] In one embodiment of this disclosure, the first resource usage information is determined by a proxy module running in the target container group based on the host machine resource information currently used by the target container group and the host machine resource information requested by the target container group. The proxy module determines the first resource usage rate once every preset time interval.

[0159] In one embodiment of this disclosure, the average resource usage information includes the average resource utilization rate, and the first resource usage information includes the first resource utilization rate, which represents the proportion of the host resources currently used by the target container group in the requested host resources.

[0160] The second weight is positively correlated with the first weight and the average resource utilization rate, and negatively correlated with the first resource utilization rate.

[0161] In one embodiment of this disclosure, the first allocation unit 603 is further configured to:

[0162] In response to the first resource usage information of the target container group satisfying a first preset condition, an access request is allocated to the target container group based on a second weight. In one embodiment of this disclosure, the average resource usage information includes an average resource utilization rate, and the first resource usage information includes a first resource utilization rate; the first resource utilization rate characterizes the proportion of the host resources currently used by the target container group in the requested host resources; the first preset condition includes:

[0163] The deviation of the first resource utilization rate from the average resource utilization rate is greater than the first preset threshold.

[0164] In one embodiment of this disclosure, the first allocation unit 603 is further configured to:

[0165] In response to the first resource usage information of the target container group not meeting the first preset condition, an access request is allocated to the target container group based on the first weight corresponding to the target container group. In one embodiment of this disclosure, the apparatus further includes a display unit (not shown in the figure), the display unit being used for:

[0166] Display one or more of the following information:

[0167] Average resource usage information for multiple container groups;

[0168] The first resource usage information corresponding to each of the multiple container groups.

[0169] Corresponding to the load balancing method of the embodiment shown in Figure 3 above, Figure 7 is a structural block diagram of the load balancing device provided in the embodiments of this disclosure. For ease of explanation, only the parts related to the embodiments of this disclosure are shown. Referring to Figure 7, the device 70 includes a second acquisition unit 701, a second determination unit 702, a third determination unit 703, and a sending unit 704.

[0170] The second acquisition unit 701 is used to acquire the host machine resource information currently used by the target container group;

[0171] The second determining unit 702 is used to determine the first resource usage information of the target container group based on the currently used host resource information and the host resource information requested by the target container group.

[0172] The third determining unit 703 is used to generate a weight determining request based on the first resource usage information;

[0173] The sending unit 704 is used to send a weight determination request to the controller so that the controller can determine the second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were allocated to the target container group in the past.

[0174] In one embodiment of this disclosure, the third determining unit 703 is further configured to:

[0175] Obtain the first weight of the target container group;

[0176] A weight determination request is generated based on the first resource usage information and the first weight.

[0177] In one embodiment of this disclosure, the second acquisition unit 701 is further configured to: in response to the current time meeting a second preset condition, acquire host resource information used by the target container group, wherein the second preset condition includes: the time interval between the current time and the time when the first resource information of the target container group was historically determined is greater than or equal to a preset time interval.

[0178] Corresponding to the load balancing method of the embodiment shown in Figure 4 above, Figure 8 is a structural block diagram of the load balancing device provided in the embodiment of this disclosure. For ease of explanation, only the parts related to the embodiment of this disclosure are shown. Referring to Figure 8, the device 80 includes a third acquisition unit 801 and a second allocation unit 802. Wherein,

[0179] The third acquisition unit 801 is used to acquire the second weight of the target container group, wherein the second weight of the target container group is determined based on the current first resource usage information, the first weight, and the average resource usage information of multiple container groups of the target container group, and the first weight is the weight of the target container group when access requests were allocated to the target container group in the past.

[0180] The second allocation unit 802 is used to allocate access requests to the target container group based on the second weight.

[0181] To implement the above embodiments, this disclosure also provides an electronic device.

[0182] Referring to Figure 9, a schematic diagram of the structure of an electronic device 900 suitable for implementing embodiments of the present disclosure is shown. The electronic device 900 can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), portable Android devices (PADs), portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. The electronic device shown in Figure 9 is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present disclosure.

[0183] As shown in Figure 9, the electronic device 900 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage device 908 into a random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the operation of the electronic device 900. The processing unit 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0184] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic device 900 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 9 shows electronic device 900 with various devices, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0185] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 909, or installed from a storage device 908, or installed from a ROM 902. When the computer program is executed by a processing device 901, it performs the functions defined in the methods of embodiments of this disclosure.

[0186] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program (computer-executable instructions) that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0187] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0188] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods shown in the above embodiments.

[0189] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0190] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0191] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0192] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0193] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0194] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0195] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0196] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A load balancing method, comprising: Obtain a weight determination request, the weight determination request including first resource usage information corresponding to the target container group, the first resource usage information being related to the host resource information currently used by the target container group and the host resource information requested by the target container group; Based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups, a second weight corresponding to the target container group is determined; wherein, the first weight is the weight corresponding to the target container group when historical access requests were allocated to the target container group, and the multiple container groups include the target container group; Access requests are assigned to the target container group based on the second weight of the target container group.

2. The method according to claim 1, wherein, The first resource usage information is determined by the agent module running in the target container group based on the host resource information currently used by the target container group and the host resource information requested by the target container group. The agent module determines the first resource usage information once every preset time interval.

3. The method according to claim 1 or 2, wherein, The average resource usage information includes the average resource utilization rate, and the first resource usage information includes the first resource utilization rate, which represents the proportion of the host resources currently used by the target container group in the requested host resources. The second weight is positively correlated with the first weight and the average resource utilization rate, and negatively correlated with the first resource utilization rate.

4. The method according to any one of claims 1-3, wherein, The step of allocating access requests to the target container group based on the second weight of the target container group includes: In response to the first resource usage information of the target container group satisfying the first preset condition, the access request is allocated to the target container group based on the second weight.

5. The method according to claim 4, wherein, The average resource usage information includes the average resource utilization rate, and the first resource usage information includes the first resource utilization rate; The first resource utilization rate represents the proportion of the host resources currently used by the target container group in the requested host resources; The first preset conditions include: The offset of the first resource utilization rate relative to the average resource utilization rate is greater than a first preset threshold.

6. The method according to claim 4, further comprising: In response to the first resource usage information of the target container group not meeting the first preset condition, the access request is allocated to the target container group based on the first weight corresponding to the target container group.

7. The method according to any one of claims 1-6, further comprising: Display one or more of the following information: Average resource usage information for multiple container groups; The first resource usage information corresponding to each of the multiple container groups.

8. A load balancing method, comprising: Obtain information about the host resources currently used by the target container group; Based on the currently used host resource information and the host resource information requested by the target container group, the first resource usage information of the target container group is determined; Generate a weight determination request based on the first resource usage information; The weight determination request is sent to the controller, so that the controller determines the second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were previously allocated to the target container group.

9. The method according to claim 8, wherein, The step of generating a weight determination request based on the first resource usage information includes: Obtain the first weight of the target container group; A weight determination request is generated based on the first resource usage information and the first weight.

10. The method according to claim 8 or 9, wherein, The process of obtaining the host machine resource information currently used by the target container group where the proxy module is located includes: In response to the current moment meeting a second preset condition, the host resource information used by the target container group is obtained. The second preset condition includes: the time interval between the current moment and the moment when the first resource information of the target container group was determined in the past is greater than or equal to a preset time interval.

11. A load balancing method, comprising: Obtain the second weight of the target container group, wherein the second weight of the target container group is determined based on the current first resource usage information, the first weight, and the average resource usage information of multiple container groups of the target container group, and the first weight is the weight of the target container group when access requests were allocated to the target container group in the past; Access requests are assigned to the target container group based on the second weight.

12. A load balancing system, comprising a host machine, multiple container groups, a controller, and a distributor running on the host machine, wherein an agent module runs in each container group; wherein, The proxy module is configured to: obtain the host machine resource information currently used by the target container group; Based on the currently used host resource information and the host resource information requested by the target container group, the first resource usage information of the target container group is determined; A weight determination request is generated based on the first resource usage information; the weight determination request is sent to the controller, so that the controller determines the second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were allocated to the target container group in the past; The controller is configured to: acquire a weight determination request, the weight determination request including first resource usage information corresponding to a target container group, the first resource usage information being related to the host resource information currently used by the target container group and the host resource information requested by the target container group; determine a second weight corresponding to the target container group based on the first resource usage information, a first weight, and average resource usage information of multiple container groups; wherein the first weight is the weight corresponding to the target container group when historical access requests were allocated to the target container group, and the multiple container groups include the target container group; and allocate access requests to the target container group based on the second weight of the target container group. The distributor is configured to: obtain a second weight of a target container group, wherein the second weight of the target container group is determined based on the current first resource usage information of the target container group, the first weight, and the average resource usage information of multiple container groups; and allocate access requests to the target container group based on the second weight.

13. A load balancing device, comprising: The first acquisition unit is configured to acquire a weight determination request, the weight determination request including first resource usage information corresponding to the target container group, the first resource usage information being related to the host resource information currently used by the target container group and the host resource information requested by the target container group; The first determining unit is configured to determine a second weight corresponding to the target container group based on the first resource usage information, the first weight, and the average resource usage information of multiple container groups; wherein, the first weight is the weight corresponding to the target container group when historical access requests were allocated to the target container group, and the multiple container groups include the target container group. The first allocation unit is configured to allocate access requests to the target container group based on a second weight of the target container group.

14. A load balancing device, comprising: The second acquisition unit is configured to acquire information about the host resources currently used by the target container group. The second determining unit is configured to determine the first resource usage information of the target container group based on the currently used host resource information and the host resource information requested by the target container group; The third determining unit is configured to generate a weight determining request based on the first resource usage information. The sending unit is configured to send the weight determination request to the controller, so that the controller can determine the second weight of the target container group based on the first resource usage information and the first weight, so as to allocate access requests to the target container group based on the second weight, wherein the first weight is the weight corresponding to the target container group when access requests were previously allocated to the target container group.

15. A load balancing device, comprising: The third acquisition unit is configured to acquire the second weight of the target container group, wherein the second weight of the target container group is determined based on the current first resource usage information, the first weight of the target container group and the average resource usage information of multiple container groups, and the first weight is the weight of the target container group when access requests were allocated to the target container group in the past. The second allocation unit is configured to allocate access requests to the target container group based on the second weight.

16. An electronic device comprising a processor and a memory, wherein The memory is configured to store computer-executed instructions; The processor is configured to execute the computer execution instructions stored in the memory, causing the processor to perform the load balancing method as described in any one of claims 1 to 11.

17. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the load balancing method as described in any one of claims 1 to 11.

Images