A processing method and device of a scheduling entity of a cluster, an apparatus, a computer readable storage medium and a computer program product

Abstract

The application provides a processing method and device of a scheduling entity of a cluster, equipment, a computer program product and a computer readable storage medium; the embodiment of the application can be applied to the expansion or contraction of the scheduling entity of the game background service and the social network background service; the method comprises the following steps: sending a prediction result synchronization request to a second equipment for a first time period; receiving a predicted load returned by the second equipment for the prediction result synchronization request, the predicted load being a load predicted by the second equipment for the cluster, and the cluster comprising a plurality of scheduling entities; receiving a first entity quantity sent by a third equipment; determining a second entity quantity of the first time period based on the predicted load, an expected load and the first entity quantity; and sending the second entity quantity to the third equipment, the third equipment being used for expanding or contracting the scheduling entity according to the second entity quantity and the first entity quantity. Through the application, the computing resources consumed in the case of load mutation can be saved.

Description

Technical Field

[0001] This application relates to computer technology, and more particularly to a method, apparatus, device, computer-readable storage medium, and computer program product for processing a cluster scheduling entity. Background Technology

[0002] In cloud services, scaling up and down scheduling entities is often involved to match the number of scheduling entities with the business load. However, the handling of scheduling instances in related technologies suffers from high computational resource consumption when dealing with sudden load changes. Summary of the Invention

[0003] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product for processing the scheduling entity of a cluster, which can save computing resources consumed in the event of sudden load changes.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a method for processing a cluster scheduling entity, applied to a first device, the method comprising:

[0006] For the first time period, a prediction result synchronization request is sent to the second device, the prediction result synchronization request being used to request a predicted load from the second device;

[0007] The system receives the predicted load returned by the second device in response to the synchronization request for the prediction result. The predicted load is the load predicted by the second device for the cluster, and the cluster includes multiple scheduling entities.

[0008] The number of the first entities received from the third device;

[0009] Based on the predicted load, expected load, and the number of the first entity, determine the number of the second entity for the first time period;

[0010] The third device sends the second entity quantity to the third device, which is used to expand or shrink the scheduling entity based on the second entity quantity and the first entity quantity.

[0011] This application provides a method for processing a cluster scheduling entity, applied to a second device, the method comprising:

[0012] Receive the prediction result synchronization request sent by the first device for the first time period;

[0013] In response to the synchronization request for the prediction results, a predicted load is returned to the first device. The predicted load is the load predicted for the cluster, which includes multiple scheduling entities.

[0014] The first device is used to determine the second number of entities based on the predicted load, the expected load, and the first number of entities sent by the third device, and to send the second number of entities to the third device. The third device is used to expand or shrink the scheduling entities according to the first number of entities and the second number of entities.

[0015] This application provides a method for processing a cluster scheduling entity, applied to a third device, the method comprising:

[0016] Send the first number of entities to the first device;

[0017] Receive the second entity count sent by the first device; wherein the second entity count is determined by the first device based on the predicted load, the expected load and the first entity count, the predicted load is returned by the second device in response to the prediction result synchronization request of the first device, and the prediction result synchronization request is sent by the first device for a first time period;

[0018] Based on the number of the first entity and the number of the second entity, the scheduling entity is expanded or reduced in size.

[0019] This application provides a processing apparatus for a cluster scheduling entity, comprising:

[0020] The first sending module is used to send a prediction result synchronization request to the second device for a first time period, the prediction result synchronization request being used to request a predicted load from the second device; and to send a second entity number to the third device, the third device being used to expand or shrink the scheduling entity according to the second entity number and the first entity number.

[0021] The first receiving module is configured to receive the predicted load returned by the second device in response to the synchronization request of the prediction result, wherein the predicted load is the load predicted by the second device for the cluster, and the cluster includes multiple scheduling entities; and to receive the first number of entities sent by the third device.

[0022] The quantity determination module is used to determine the number of second entities in the first time period based on the predicted load, expected load, and the number of the first entities.

[0023] In the above scheme, the quantity determination module is further configured to filter the maximum load of the first time period from the predicted load and the current load; and determine the second entity quantity of the first time period based on the maximum load, the expected load and the first entity quantity.

[0024] In the above scheme, the quantity determination module is further configured to calculate a first load ratio based on the maximum load and the expected load; and determine the second entity quantity in the first time period based on the first entity quantity and the first load ratio.

[0025] In the above scheme, the quantity determination module is further configured to calculate a second load ratio based on the predicted load and the expected load; and determine the second entity quantity in the first time period based on the first entity quantity and the second load ratio.

[0026] In the above scheme, the first receiving module is further configured to receive a scheduling entity waiting to be shut down sent by the third device; wherein the scheduling entity waiting to be shut down is determined by the third device from the scheduling entities currently in operation when scaling down the scheduling entity; and to receive the status information of the service process sent by the first management server; wherein the service process runs in the scheduling entity waiting to be shut down, and the first management server is a server that manages the service process.

[0027] The first sending module is further configured to send a blocking instruction to the first management server for the scheduling entity waiting to be shut down when the status information indicates that the service process is running; the blocking instruction is used to initiate the shrinkage and emptying of the scheduling entity waiting to be shut down.

[0028] In the above scheme, the first sending module is further configured to send a drain completion message to the third device when the scheduling entity waiting to be closed completes its shrinkage and draining. The third device is configured to close the scheduling entity waiting to be closed upon receiving the drain completion message.

[0029] In the above scheme, the first receiving module is further configured to receive the real-time load of the cluster sent by the second management server; the second management server is a server that performs statistics on and sends the real-time load of the cluster.

[0030] The first sending module is further configured to send the real-time load of the cluster to the second device, wherein the second device is configured to store the real-time load in a database.

[0031] This application provides a processing apparatus for a cluster scheduling entity, comprising:

[0032] The second receiving module is used to receive the prediction result synchronization request sent by the first device for the first time period;

[0033] The second sending module is used to return a predicted load to the first device in response to the prediction result synchronization request. The predicted load is the load predicted for the cluster, and the cluster includes multiple scheduling entities. The first device is used to determine a second number of entities based on the predicted load, the expected load, and the number of first entities sent by the third device, and send the number of second entities to the third device. The third device is used to expand or shrink the scheduling entities according to the number of first entities and the number of second entities.

[0034] In the above scheme, the second sending module is further configured to read the prediction load of the first time period from the database in response to the prediction result synchronization request; and send the prediction load to the first device.

[0035] In the above scheme, the processing device of the scheduling entity further includes: a load prediction module, used to read a first quantity of historical loads from the database when the prediction time is reached; wherein, the first quantity is determined based on the expansion timeout time and the time granularity corresponding to the historical loads; based on the first quantity of historical loads, the predicted load for the first time period is determined; and the predicted loads are stored in the database.

[0036] In the above scheme, the load prediction module is further configured to perform load prediction for the first time period using a load prediction model and the first number of historical loads, and determine the prediction result as the predicted load.

[0037] In the above scheme, the load prediction module is further configured to determine a second time period based on the historical load change trend characteristics; determine training data based on the second time period and the time granularity; train the initial prediction model using the training data; and obtain the load prediction model when the training termination condition is reached.

[0038] In the above scheme, the load prediction module is further configured to use the training data to train the initial prediction model at at least two autoregressive orders, and obtain at least two trained prediction models when the training termination condition is reached; use test data to determine the prediction error of each trained prediction model; and use the trained prediction model with the smallest prediction error as the load prediction model.

[0039] In the above scheme, the second receiving module is further configured to receive the real-time load of the cluster sent by the first device and store the real-time load in the database; wherein the real-time load is sent to the first device by the second management server, and the second management server is a server that performs statistics and sends the real-time load of the cluster.

[0040] This application provides a processing apparatus for a cluster scheduling entity, comprising:

[0041] The third sending module is used to send the first entity quantity to the first device;

[0042] The third receiving module is used to receive the second entity quantity sent by the first device; wherein the second entity quantity is determined by the first device based on the predicted load, the expected load and the first entity quantity, the predicted load is returned by the second device in response to the prediction result synchronization request of the first device, and the prediction result synchronization request is sent by the first device for a first time period;

[0043] The entity processing module is used to expand or shrink the scheduling entity according to the first entity quantity and the second entity quantity.

[0044] In the above scheme, the entity processing module is further configured to expand the scheduling entity when the number of the first entity is less than the number of the second entity, and shrink the scheduling entity when the number of the first entity is greater than the number of the second entity.

[0045] In the above scheme, the entity processing module is further configured to determine the scheduling entities waiting to be shut down from the scheduling entities currently in the running state;

[0046] The third sending module is further configured to send the scheduling entity waiting to be shut down to the first device; wherein, the first device is configured to send a blocking instruction to the first management server, the second management server is a server that manages the business processes running in the scheduling entity waiting to be shut down, and the blocking instruction is configured to initiate the shrinkage and emptying of the scheduling entity waiting to be shut down.

[0047] In the above scheme, the third receiving module is also used to receive the emptying completion message sent by the first device;

[0048] The entity processing module is also used to close the scheduling entity that is waiting to be closed.

[0049] This application provides a first device, the first device comprising:

[0050] The first memory is used to store computer-executable instructions or computer programs;

[0051] The first processor, when executing computer-executable instructions or computer programs stored in the first memory, implements the processing method of the cluster scheduling entity on the first device side provided in the embodiments of this application.

[0052] This application provides a second device, the second device comprising:

[0053] Secondary memory is used to store computer-executable instructions or computer programs;

[0054] The second processor, when executing computer-executable instructions or computer programs stored in the second memory, implements the processing method of the cluster scheduling entity on the second device side provided in the embodiments of this application.

[0055] This application embodiment provides a third device, the third device comprising:

[0056] The third memory is used to store computer-executable instructions or computer programs;

[0057] The third processor, when executing computer-executable instructions or computer programs stored in the third memory, implements the processing method of the cluster scheduling entity on the third device side provided in the embodiments of this application.

[0058] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implement the processing method of the scheduling entity of the first device-side cluster, the processing method of the scheduling entity of the second device-side cluster, or the processing method of the scheduling entity of the third device-side cluster provided in this application.

[0059] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the processing method of the scheduling entity of the first device-side cluster, the processing method of the scheduling entity of the second device-side cluster, or the processing method of the scheduling entity of the third device-side cluster provided in this application.

[0060] The embodiments of this application have the following beneficial effects: By requesting a synchronization of prediction results, the predicted load for a first time period is obtained from the second device. Simultaneously, the number of scheduling entities currently in operation (i.e., the first entity count) reported by the third device is received. Then, combining the predicted load, expected load, and first entity count for the first time period, the expected second entity count for the first time period is determined. This second entity count is then sent to the third device, enabling the third device to scale up or down the scheduling entities based on the first and second entity counts—that is, to deploy or shut down scheduling entities. Calculating the second entity count based on the predicted load for scaling up or down reduces the frequency of frequent scaling up or down due to load fluctuations, thus enabling better handling of load changes. Furthermore, the number of scheduling entities calculated based on the predicted load matches the load for the first time period, reducing wasted computing resources. In this way, the computing resources consumed in the event of load fluctuations can be saved. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of the automatic capacity expansion scheme;

[0062] Figure 2 This is a schematic diagram of the architecture of the cluster scheduling entity processing system provided in the embodiments of this application;

[0063] Figure 3 This is a schematic diagram of the server structure provided in the embodiments of this application. Figure 1 ;

[0064] Figure 4 This is a schematic diagram of the server structure provided in the embodiments of this application. Figure 2 ;

[0065] Figure 5 This is a schematic diagram of the server structure provided in the embodiments of this application. Figure 3 ;

[0066] Figure 6 This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 1 ;

[0067] Figure 7 This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 2 ;

[0068] Figure 8 This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 3 ;

[0069] Figure 9This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 4 ;

[0070] Figure 10 This is a schematic diagram of the Pod replica scaling architecture provided in the embodiments of this application;

[0071] Figure 11 This is a flowchart illustrating the implementation of automatic scaling provided in the embodiments of this application;

[0072] Figure 12 This is a flowchart illustrating the implementation of calculating the desired number of Pod replicas provided in an embodiment of this application.

[0073] Figure 13 This is a schematic diagram of load changes provided in the embodiments of this application. Figure 1 ;

[0074] Figure 14 This is a schematic diagram of load changes provided in the embodiments of this application. Figure 2 ;

[0075] Figure 15 This is a schematic diagram of load changes provided in the embodiments of this application. Figure 3 ;

[0076] Figure 16 This is a schematic diagram of the load prediction process provided in the embodiments of this application;

[0077] Figure 17 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 1 ;

[0078] Figure 18 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 2 ;

[0079] Figure 19 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 3 ;

[0080] Figure 20 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 4 . Detailed Implementation

[0081] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0082] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0083] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0084] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0085] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0086] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0087] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0088] 1) A Pod is the smallest deployment unit in a container orchestration system that can be scheduled to a cluster of computer nodes. It can be a collection of containers. Containers are used to encapsulate applications and their runtime dependencies, enabling applications to run consistently on any operating system that supports container technology. A container orchestration system is a software system that manages the lifecycle, deployment, and high availability of containers.

[0089] 2) A cluster refers to a collection of scheduling entities that can work together to complete specific tasks or provide services, such as providing background services for games.

[0090] 3) Load refers to the overall workload of a cluster in processing requests and executing tasks. Load can be measured by some performance metrics, such as CPU utilization, memory utilization, request response time, etc.

[0091] 4) Expected load refers to the expected load level of the cluster within a given time period. Expected load plays a crucial role in the scaling up and down of the scheduling entity. In other words, the goal of scaling up and down the scheduling entity is to make the real-time load of the cluster match the expected load as closely as possible.

[0092] 5) Scaling up or down refers to the process of dynamically adjusting the number of scheduling entities according to the needs of business load. For example, increasing the number of scheduling entities to cope with load peaks, or reducing the number of scheduling entities to save computing resources.

[0093] 6) Expansion timeout refers to the maximum waiting time required when expanding the capacity of the scheduling entity, that is, the maximum allowed time from the initiation of the expansion command to the successful start-up and readiness of the scheduling entity to process business requests.

[0094] 7) Forecasted load refers to the result of load prediction for a cluster at a certain time in the future. Thus, the forecasted load reflects the load level that may occur during that time period.

[0095] 9) Shrinking and emptying refers to the process of preventing business processes running in the scheduling entity from receiving new business requests and waiting for the business processes to complete the processing of existing business requests.

[0096] 10) Time granularity, which refers to the time unit corresponding to the historical loads recorded in the database. It determines the time span between two consecutive historical loads in chronological order, thus reflecting how historical loads are recorded over time. For example, if the time granularity corresponding to a historical load is minutes, then two consecutive historical loads in chronological order will be spaced 1 minute apart.

[0097] 11) A business process refers to a process that runs business logic. For example, when the business scenario is a game scenario, the business process can be the main logic process in the game, such as the process that handles the action logic and combat logic of game characters. In this embodiment, the business process can run in a scheduling entity.

[0098] 12) Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize the computing, storage, processing, and sharing of data.

[0099] In cloud technology, scaling up and down scheduling entities is often involved to match the number of scheduling entities with the business load. In related technologies, scaling up and down scheduling entities is typically achieved using a Horizontal Pod Autoscaler (HPA). Below, we will use scaling up as an example to illustrate the principle and time consumption of the HPA solution.

[0100] Figure 1 This is a schematic diagram of the automatic capacity expansion scheme. (See attached diagram.) Figure 1 The horizontal Pod autoscaler 1-1 needs to periodically obtain real-time load from the metric collection component 1-2 (a component used to collect resource usage metrics of computer nodes and Pods, i.e., the Metric Server). When the real-time load reaches the load threshold, it triggers Pod scaling and sends a request to the resource object 1-3, which manages stateless services, to increase the number of scheduling entities. Then, it enters the control cycle of the Cluster Autoscaler (CA). In this control cycle, the cluster autoscaler container 1-4 triggers the scaling of computer nodes 1-5, which takes about 20 minutes. After the computer nodes are successfully scaled up, the container image needs to be downloaded and the package synchronized 1-6 to complete the preparation work for the startup of the scheduling instance, which takes about 3 minutes. After the preparation work is completed, the scaled scheduling entity enters the running state 1-7, thus completing the scaling of the scheduling instance. The whole process takes about 30 minutes.

[0101] Therefore, scaling up and down scheduling instances takes a considerable amount of time, while the load can change rapidly, making it difficult for the number of scheduling entities after scaling to support the current load. For example, when the load suddenly increases, the long scaling time may lead to overload due to untimely scaling, affecting the processing speed of business requests and even interrupting services; conversely, when the load suddenly decreases, computing resources are wasted. While related technologies can address sudden load increases by reserving additional buffer space during scaling, this method occupies additional computer nodes, resulting in extra consumption of computing resources.

[0102] In summary, the related technologies for handling scheduled instances suffer from excessive computational resource consumption when dealing with sudden load changes.

[0103] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product for processing a cluster scheduling entity, which can save computing resources consumed under load fluctuations. Exemplary applications of the first, second, and third devices provided in this application are described below. The first, second, and third devices provided in this application can all be implemented as servers. Exemplary applications of the first, second, and third devices when implemented as servers will be described below.

[0104] See Figure 2 , Figure 2 This is a schematic diagram of the architecture of a cluster scheduling entity processing system provided in this application embodiment. To support the processing application of a scheduling entity, in the cluster scheduling entity processing system 100, server 400 is connected to server 200 via network 300, and server 600 is connected to server 200 via network 300. Network 300 can be a wide area network (WAN), a local area network (LAN), or a combination of both. The scheduling entity processing system 100 also includes a database 500 for providing data support to server 400. Database 500 can be independent of server 400 or configured within server 400. Figure 2 This illustrates the scenario where database 500 is independent of server 400.

[0105] Server 200 is used to send a prediction result synchronization request to server 400 for a first time period, the prediction result synchronization request being used to request predicted load from the second device; receive the predicted load returned by server 400 in response to the prediction result synchronization request; receive the first entity count sent by server 600, wherein the first entity count is the number of scheduled entities currently in running state; determine the second entity count for the first time period based on the predicted load, expected load, and the first entity count; and send the second entity count to server 600.

[0106] Server 400 is used to receive the prediction result synchronization request sent by server 200 for the first time period; and to return the prediction load to server 200 in response to the prediction result synchronization request.

[0107] Server 600 is used to send a first number of entities to server 200; receive a second number of entities sent by server 200; and scale up or down the scheduling entities according to the first number of entities and the second number of entities.

[0108] In some embodiments, servers 200, 400, and 600 may be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. No restrictions are imposed in the embodiments of this application.

[0109] See Figure 3 , Figure 3 This is a schematic diagram of the server structure provided in the embodiments of this application. Figure 1 , Figure 3 The server 200 shown includes at least one first processor 210, a first memory 250, and at least one first network interface 220. The various components of the server 200 are coupled together via a first bus system 240. It is understood that the first bus system 240 is used to implement communication between these components. In addition to a data bus, the first bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 3 The general designated all buses as the first bus system 240.

[0110] The first processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0111] The first memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The first memory 250 may optionally include one or more storage devices physically located remote from the first processor 210.

[0112] The first memory 250 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The first memory 250 described in this application embodiment is intended to include any suitable type of memory.

[0113] In some embodiments, the first memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0114] The first operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0115] The first network communication module 252 is used to reach other electronic devices via one or more (wired or wireless) first network interfaces 220, exemplary first network interfaces 220 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0116] In some embodiments, the processing apparatus for the scheduling entity provided in this application can be implemented in software. Figure 3 A processing device 255 for a cluster scheduling entity stored in a first memory 250 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a first sending module 2551, a first receiving module 2552, and a quantity determination module 2553. These modules are logically linked and can therefore be arbitrarily combined or further split according to their implemented functions. The functions of each module will be described below.

[0117] See Figure 4 , Figure 4 This is a schematic diagram of the server structure provided in the embodiments of this application. Figure 2 , Figure 4 The server 400 shown includes at least one second processor 410, a second memory 450, and at least one second network interface 420. The various components of the server 400 are coupled together via a second bus system 440. It is understood that the second bus system 440 is used to implement communication between these components. In addition to a data bus, the second bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 4 The various buses are all labeled as the second bus system 440.

[0118] The second processor 410 is implemented in a manner that is basically similar to that of the first processor 210, and will not be described again here.

[0119] The second memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The second memory 450 may optionally include one or more storage devices physically located remote from the second processor 410.

[0120] The second memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The second memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0121] In some embodiments, the second memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0122] The second operating system 451 is implemented in a manner that is basically similar to that of the first operating system 251, and will not be described again.

[0123] The second network communication module 452 is implemented in a manner that is basically similar to that of the first network communication module 251, and will not be described again.

[0124] In some embodiments, the processing apparatus for the scheduling entity provided in this application can be implemented in software. Figure 4 A processing device 455 for a cluster scheduling entity stored in a second memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a second receiving module 4551, a second transmitting module 4552, and a load prediction module 4553. These modules are logically linked and can therefore be arbitrarily combined or further split according to their implemented functions. The functions of each module will be described below.

[0125] See Figure 5 , Figure 5 This is a schematic diagram of the server structure provided in the embodiments of this application. Figure 3 , Figure 5The server 600 shown includes at least one third processor 610, a third memory 650, and at least one third network interface 620. The various components in the server 600 are coupled together via a third bus system 640. It is understood that the third bus system 640 is used to implement communication between these components. In addition to a data bus, the third bus system 640 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 5 The general labeled all buses as the third bus system 640.

[0126] The third processor 610 is implemented in a manner that is basically similar to that of the first processor 210, and will not be described again here.

[0127] The third memory 650 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The third memory 650 may optionally include one or more storage devices physically located remote from the third processor 610.

[0128] The third memory 650 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The third memory 650 described in this application embodiment is intended to include any suitable type of memory.

[0129] In some embodiments, the third memory 650 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0130] The third operating system 651 is implemented in a manner that is basically similar to that of the first operating system 251, and will not be described again.

[0131] The third network communication module 652, it should be noted that the implementation of the second network communication module 652 is basically similar to the implementation of the first network communication module 251, and will not be described again;

[0132] In some embodiments, the processing apparatus for the scheduling entity provided in this application can be implemented in software. Figure 5A processing device 655 for scheduling entities of a cluster stored in a third memory 650 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a third transmitting module 6551, a third receiving module 6552, and an entity processing module 6553. These modules are logically linked and can therefore be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0133] In other embodiments, the processing device of the cluster scheduling entity provided in this application embodiment can be implemented in hardware. As an example, the processing device of the cluster scheduling entity provided in this application embodiment can be a processor in the form of a hardware decoding processor, which is programmed to execute the processing method of the cluster scheduling entity provided in this application embodiment. For example, the processor in the form of a hardware decoding processor can be one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0134] In some embodiments, the server can implement the cluster scheduling entity processing method provided in this application embodiment by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run, such as a scheduling entity management APP; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0135] The following will describe the processing method of the cluster scheduling entity provided in the embodiments of this application, with reference to the exemplary applications and implementations of the first device, the second device and the third device provided in the embodiments of this application.

[0136] See Figure 6 , Figure 6This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 1 , will combine Figure 6 The steps shown are explained.

[0137] Step 101: The first device sends a prediction result synchronization request to the second device for the first time period.

[0138] This application embodiment is implemented in a scenario where the scheduling entity is expanded or reduced in size, so that the number of scheduling entities in the running state matches the load. After the processing flow of the scheduling entity begins, the first device generates a prediction result synchronization request for a first time period and sends the prediction result synchronization request to the second device. The prediction result synchronization request is used to request the prediction load from the second device. The second device receives the prediction result synchronization request sent by the first device for the first time period.

[0139] Here, the first time period refers to the period starting from the current time and ending at the sum of the current time and the expansion timeout. In other words, the first time period is the period formed by extending the current time forward by the expansion timeout. For example, if the current time is t and the expansion timeout is y, then the first time period can be written as [t, t+y]. It is clear that the first time period is a future period, and therefore, the first device obtains the predicted load for the future time period from the second device through a synchronization request based on the predicted results.

[0140] It's important to note that the scaling timeout refers to the maximum waiting time required when scaling up a scheduling entity; that is, the maximum allowed time from the start of scaling up until the scheduling entity successfully starts and is ready to process requests. Generally, the waiting time during scaling up will not exceed the scaling timeout. Here, determining the first time period based on the scaling timeout ensures that the predicted load matches the maximum waiting time during scaling up. This avoids situations where the load changes during scaling up or down based on a specific load, requiring further scaling up or down after the initial scaling up or down phase. This helps address sudden load changes. Furthermore, the number of scheduling entities calculated based on this predicted load matches the load with the longest waiting time during scaling up, allowing for scaling up or down according to this number and reducing wasted computing resources.

[0141] In this embodiment, the first device can automatically send a prediction result synchronization request to the second device when the requested time is reached. At this time, the current time is the requested time, and the first time period is the time period that starts with the requested time and ends with the sum of the requested time and the expansion timeout time. Here, the requested time can be a single point in time (which can be specified in advance by the user), a series of point in time with fixed time intervals (e.g., a series of point in time with intervals of 1 minute or 10 minutes), or a series of point in time with variable time intervals (e.g., 3 point in time with intervals of 8 minutes and 5 minutes respectively). This embodiment does not limit the scope of the request.

[0142] Of course, the first device can also send a prediction result synchronization request to the second device for the first time period when it receives the user's request to send the instruction. In this case, the current time is the time when the user's request to send the instruction is received. Therefore, the start time of the first time period is the time when the user's request to send the instruction is received, and the end time is the sum of the time when the user's request to send the instruction is received and the expansion timeout.

[0143] Here, the prediction result synchronization request can be a Hypertext Transfer Protocol request (HTTP request), a File Transfer Protocol (FTP) request, etc., and this embodiment of the application does not limit it.

[0144] A scheduling entity is the smallest deployment unit in a container orchestration system that can be scheduled to a cluster of computer nodes. It can be a collection of containers, where containers encapsulate applications and their runtime dependencies, enabling applications to run consistently on any operating system that supports container technology. Thus, business processes executing business logic can run within the scheduling entity. A container orchestration system is a software system that manages the lifecycle, deployment, and high availability of containers. In this embodiment, the scheduling instance can be a Pod or a ReplicaSet; this embodiment does not impose any limitations.

[0145] Step 102: The second device returns the predicted load to the first device in response to the prediction result synchronization request.

[0146] When the second device receives a prediction result synchronization request from the first device, it responds to the request, obtains the predicted load of the cluster for the first time period, and sends the predicted load to the first device via the network. The first device receives the predicted load returned by the second device in response to the prediction result synchronization request. The predicted load is the load predicted by the second device for the cluster, which includes multiple scheduling entities.

[0147] It should be noted that the second device can retrieve the generated predicted load from the database and return it to the first device; the second device can also start load prediction for the first time period when it receives a prediction synchronization result request, and return the obtained prediction result, i.e., the predicted load, to the first device after completing the load prediction.

[0148] In some embodiments of this application, Figure 6 Step 102, in which the second device returns the predicted load to the first device in response to the prediction result synchronization request, can be achieved through the following process: in response to the prediction result synchronization request, read the predicted load for the first time period from the database; and return the predicted load to the first device.

[0149] In other words, the second device will perform load prediction for the first time period in advance and store the predicted load in the database; when it receives a prediction result synchronization request sent by the first device, the second device can directly read the predicted load for the first time period from the database and return it to the first device.

[0150] It should be noted that the database here can be a relational database, in which case the predicted load corresponding to different time periods can be stored in a data table, where the time period can be used as the column of the data table and the predicted load corresponding to the time period can be used as the row of the data table; the database here can also be a key-value database, in which case the predicted load corresponding to different time periods can be stored in a key-value pair, where the time period can be used as the key and the predicted load can be used as the value.

[0151] Step 103: The third device sends the first entity quantity to the first device.

[0152] The third device counts the number of scheduling entities currently in operation, obtains the first entity count, and sends the first entity count to the first device via the network. The first device receives the first entity count sent by the third device. The first entity count is the number of scheduling entities currently in operation.

[0153] In this embodiment of the application, the third device can obtain detailed information of each scheduling entity in the cluster and determine the current state of each scheduling entity from the detailed information (for example, by reading the field value representing the current state) so as to count the number of scheduling entities in the running state and obtain the first entity count.

[0154] It should be noted that the third device can automatically report the number of the first entity to the first device when the reporting time is reached. The reporting time can be a single point in time (which can be set by the user), a series of points in time with fixed time intervals, or a series of points in time with random time intervals.

[0155] It should be noted that steps 103 and steps 101 to 102 may be executed in a different order than those described above. For example, steps 103 may be executed first, followed by steps 101 to 102. This embodiment of the application does not limit this.

[0156] Step 104: The first device determines the number of second entities for the first time period based on the predicted load, expected load, and the number of first entities.

[0157] After obtaining the predicted load and the first number of entities, the first device also needs to combine this with the cluster's expected load to calculate the number of scheduled entities required for the first time period. This number is the second number of entities. The expected load refers to the expected load level the cluster should achieve within the first time period. In other words, the expected load is a anticipated performance target that defines the load level the cluster should reach within the first time period. Examples include the expected CPU utilization and memory utilization.

[0158] It should be noted that the expected load can be set by the user (e.g., administrator, operations personnel, etc.) or by the first device based on at least one of the business objectives, application requirements, and performance metrics. For example, the first device can use a deep learning model capable of determining the expected load to analyze at least one of the business objectives, application requirements, and performance metrics to generate the corresponding expected load; wherein, the deep learning model can acquire this capability through training, and the training data can be generated based on existing expected loads and at least one of the business objectives, application requirements, and performance metrics corresponding to the expected load.

[0159] The second device can calculate the number of second entities based solely on the predicted load, expected load, and the number of first entities, or it can calculate the number of second entities by combining the predicted load, expected load, and the number of first entities with the current load of the cluster.

[0160] See Figure 7 , Figure 7 This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 2 In some embodiments of this application, Figure 6Step 104, whereby the first device determines the number of second entities for the first time period based on the predicted load, expected load, and the number of first entities, can be achieved through the following processing:

[0161] Step 1041: The first device filters the maximum load for the first time period from the predicted load and the current load.

[0162] The first device compares the predicted load with the current load and takes the larger of these two loads as the maximum load for the first time period. This comparison of the predicted and current loads to filter for the maximum load ensures that the number of second entities is always determined based on the larger load. Here, the current load refers to the cluster load at the current moment.

[0163] Step 1042: The first device determines the number of second entities for the first time period based on the maximum load, the expected load, and the number of first entities.

[0164] After determining the maximum load, the first device can combine the maximum load, the expected load, and the number of scheduling entities currently in operation to calculate the number of scheduling entities required for the first time period, thereby obtaining the second number of entities.

[0165] In some embodiments of this application, Figure 7 Step 1042, namely, the first device determining the number of second entities for the first time period based on the maximum load, the expected load, and the number of first entities, can be achieved through the following processing: calculating the first load ratio based on the maximum load and the expected load; and determining the number of second entities for the first time period based on the number of first entities and the first load ratio.

[0166] The first device can compare the maximum load with the expected load to obtain the first load ratio, and then adjust the first entity quantity using the first load ratio to obtain the second entity quantity.

[0167] The first device can use the desired load as the numerator and the maximum load as the denominator to obtain the first load ratio, or it can use the maximum load as the numerator and the desired load as the denominator to obtain the first load ratio. When the desired load is used as the numerator, the first device can multiply the first load ratio and the first entity quantity to obtain the second entity quantity; when the maximum load is used as the denominator, the first device can divide the first entity quantity by the first load ratio to obtain the second entity quantity.

[0168] This completes the determination of the number of second entities while considering the current load.

[0169] It is understood that in the embodiments of this application, comparing the predicted load with the current load to filter the maximum load and calculating the number of second entities based on the maximum load is to ensure that the number of second entities is always determined based on a larger load, thereby ensuring that the determined number of second entities can cope with future loads and thus avoid overload when the predicted load is inaccurate.

[0170] In other embodiments of this application, Figure 7 Step 1042, whereby the first device determines the number of second entities for the first time period based on the maximum load, the expected load, and the number of first entities, can also be achieved through the following processing: calculating the second load ratio based on the predicted load and the expected load; and determining the number of second entities for the first time period based on the number of first entities and the second load ratio.

[0171] In other words, the first device can directly calculate the number of second entities based on the predicted load. Specifically, the first device can use the expected load as the numerator and the predicted load as the denominator to obtain the second load ratio, or it can use the predicted load as the numerator and the expected load as the denominator to obtain the second load ratio. When using the expected load as the numerator, the first device can multiply the second load ratio and the number of first entities to obtain the number of second entities; when using the predicted load as the denominator, the first device can divide the number of first entities by the second load ratio to obtain the number of second entities.

[0172] Step 105: The first device sends the second entity quantity to the third device.

[0173] After determining the quantity of the second entity, the first device sends the quantity of the second entity to the third device via the network, and the third device receives the quantity of the second entity sent by the first device. The first device sending the quantity of the second entity to the third device can be seen as the first device's response to the first entity quantity sent by the third device.

[0174] Step 106: The third device expands or shrinks the capacity of the scheduling entity based on the number of the first entity and the number of the second entity.

[0175] After obtaining the second number of entities, the third device will combine the first and second number of entities to determine whether to expand or shrink the scheduling entities. Expanding refers to increasing the number of scheduling entities in operation, i.e., deploying new scheduling entities on computer nodes; shrinking refers to reducing the number of scheduling entities in operation, i.e., removing some scheduling entities from computer nodes.

[0176] In some embodiments of this application, Figure 6Step 106, which is to expand or shrink the scheduling entity according to the number of the first entity and the number of the second entity, can be achieved by the following process: when the number of the first entity is less than the number of the second entity, the scheduling entity is expanded; when the number of the first entity is greater than the number of the second entity, the scheduling entity is shrunk.

[0177] In other words, the third device compares the number of the first entity and the number of the second entity. When the number of the first entity is smaller, it means that more scheduling entities need to be started to enable the cluster to reach the expected load, thus requiring scaling up. When the number of the second entity is smaller, it means that there are too many scheduling entities currently in operation, thus requiring scaling down.

[0178] The third device expands the capacity of the scheduling entities by first determining the number N of scheduling entities to be deployed (N can be determined by the difference between the number of second entities and the number of first entities, i.e., the number of second entities - the number of first entities = N), and then selecting one or more computer nodes to deploy N scheduling entities.

[0179] It should be noted that the third device can select a suitable computer node for the scheduling entity from multiple computer nodes based on the resource capacity of the computer node (such as the number of CPUs, memory size, and disk space size) and the resource requirements of the scheduling entity (such as CPU requirements and memory requirements); the third device can also use the computer node specified by the administrator as the computer node of the scheduling entity to be deployed.

[0180] When the third device deploys a scheduling entity to a computer node, it can send a command to the management agent of the scheduling entity running on the computer node to start the scheduling entity. Upon receiving this command, the management agent will download the container image (the management agent can download container images from a configured image repository; a container image is a lightweight, executable software package containing everything needed to run an application), create containers (instantiate the container image to obtain containers, and set appropriate namespaces, environment variables, resource displays, etc. for each container), start the containers (i.e., execute the container's entry point (main program or command)), configure the network (assign routing addresses to the scheduling entity and set routing rules), and change the status field (i.e., set the value of the scheduling entity's status field to indicate that the scheduling entity is in a running state, such as "running"). In this way, the scaling up of the scheduling entity can be completed.

[0181] See Figure 8 , Figure 8 This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 3In some embodiments of this application, scaling down the scheduling entity can be achieved through the following processes:

[0182] Step 201: The third device determines the scheduling entity waiting to be shut down from the scheduling entities currently in operation.

[0183] It should be noted that when the third device scales down the scheduling entities, it can select M scheduling entities waiting to be shut down based on the priority of the scheduling entities currently in operation (M can be determined by the difference between the number of the first entity and the number of the second entity, i.e., the number of the first entity - the number of the second entity = M). For example, from the scheduling entities currently in operation, the M scheduling entities with the lowest priority can be selected as the scheduling entities waiting to be shut down. The third device can also check the health status of the scheduling entities currently in operation and select scheduling entities with poor health status as the scheduling entities waiting to be shut down. Of course, the third device can also select scheduling entities specified by the administrator as the scheduling entities waiting to be shut down.

[0184] Step 202: The third device sends the scheduling entity waiting to be shut down to the first device.

[0185] After identifying the scheduling entities awaiting shutdown, the third device reports these entities to the first device via the network. The first device then receives the list of scheduling entities awaiting shutdown from the third device. These scheduling entities are identified by the third device from among the currently running scheduling entities when scaling down the scheduling entity pool.

[0186] Step 203: The first device receives the status information of the business process sent by the first management server.

[0187] Here, the business process runs in a scheduling entity that is waiting to be shut down, and the first management server is the server that manages the business process.

[0188] It should be noted that the scheduling entity awaiting closure may contain running business processes. These business processes handle various user requests; for example, in a game, they might process requests for movement and skill activation during combat. Closing the scheduling entity directly would shut down these business processes, affecting the processing of requests (e.g., no response when using skills, or being forcibly exited from the game). Therefore, after receiving the scheduling entity awaiting closure reported by the third device, the first device needs to obtain the status information of the business processes running within that entity from the first management server. This status information indicates whether the business processes are running, i.e., whether they are processing user requests.

[0189] In this embodiment of the application, at least one business process can run in each scheduling entity, and the first management server is used to manage the business processes running in the scheduling entity. Thus, each scheduling entity has its corresponding first management server.

[0190] Step 204: When the status information indicates that the service process is running, the first device sends a blocking command to the first management server for the scheduling entity waiting to be shut down.

[0191] The first device parses the received status information of the service process to determine whether the service process is running. When the service status information indicates that the service process is running, the first device sends a blocking command to the first management server corresponding to the scheduling entity waiting to be shut down. The blocking command is used to initiate the scaling down and emptying of the scheduling entity waiting to be shut down.

[0192] Scaling down and emptying out refers to the process of preventing business processes running in a scheduling entity from accepting new business requests and waiting for the business processes to complete processing of existing business requests. Therefore, scaling down and emptying out scheduling entities awaiting closure ensures that the processing of user business requests is not affected during the scaling down process.

[0193] After receiving the blocking instruction from the first device, the first management server will stop the access of new service requests for the service processes running in the scheduling entities waiting to be shut down (this can be done by modifying the routing to redirect new service requests to other scheduling entities currently running, i.e., scheduling entities other than those waiting to be shut down, so that the service processes in other scheduling entities can process the new service requests). A certain grace period will be set for the service requests that are being processed, so that these service requests can be processed within the grace period (if these service requests are still not processed after the grace period ends, a forced shutdown signal can be sent to the service processes to forcibly shut them down).

[0194] See also Figure 8 In step 204, when the status information indicates that the service process is running, after the first device sends a blocking command to the second management server for the scheduling entity waiting to be shut down, the method further includes:

[0195] Step 205: When the scheduling entity waiting to be shut down completes its shrinkage and emptying, the first device sends an emptying completion message to the third device for the scheduling entity waiting to be shut down.

[0196] The first management server detects whether the business processes in the scheduling entity awaiting closure have completed processing existing business requests, i.e., whether they are in an idle state. If they are in an idle state, the server sends a message to the first device indicating that the business process is in an idle state. After receiving this message, the first device determines that the scheduling entity awaiting closure has completed its scaling down and emptying process, and sends a message to the third device indicating that the scaling down and emptying process has been completed, i.e., an emptying completion message. The third device receives the emptying completion message sent by the first device.

[0197] Step 206: The third device shuts down the scheduling entity that is waiting to be shut down.

[0198] After receiving the drain completion message from the first device, the third device will shut down the scheduling entity awaiting closure, that is, remove the scheduling entity from the computer node. During the removal process, the third device can send a removal command to the management agent of the scheduling entity running on the computer node. Upon receiving the command, the management agent will terminate all processes in the scheduling entity awaiting closure and release computing resources, completing the removal of the scheduling entity. In this way, the scaling down of the scheduling entity can be achieved.

[0199] Understandably, compared to related technologies, which use additional buffer space during expansion to address the issue of wasting computing resources when dealing with sudden load changes, this application embodiment addresses this problem by reserving extra computer nodes during expansion. The first device obtains the predicted load for the first time period from the second device through a prediction result synchronization request, and simultaneously receives the number of scheduling entities currently in operation reported by the third device, i.e., the first entity number. Then, by combining the predicted load, expected load, and first entity number for the first time period, the first device determines the expected second entity number for the first time period and sends the second entity number to the third device. This allows the third device to expand or shrink the scheduling entities based on the first and second entity numbers, i.e., to start or shut down the scheduling entities. Since the first time period is determined based on the current moment and the expansion timeout, the predicted load is the load that will appear during the timeout waiting period during expansion. Therefore, the number of second entities is calculated based on the predicted load for scaling up and down. This reduces the frequency of frequent scaling up and down due to load fluctuations, thus enabling better handling of load changes. Furthermore, the number of scheduling entities calculated based on this predicted load matches the future load in the first time period, reducing wasted computing resources. In this way, the goal of conserving computing resources consumed in the event of load fluctuations can be achieved.

[0200] The following section explains the process of determining the predicted load for the first time period, which is stored in the database.

[0201] In some embodiments of this application, before the second device reads the predicted load for the first time period from the database in response to the prediction result synchronization request, the method may further include the following processing: when the prediction time is reached, the second device reads a first number of historical loads from the database; the second device determines the predicted load for the first time period based on the first number of historical loads; and the second device stores the predicted load in the database.

[0202] In other words, when the prediction time arrives, the second device can first read the historical load from the database according to the determined first quantity, and use all the obtained historical loads to perform load prediction for the first time period. The resulting prediction is the predicted load. Finally, the second device writes the predicted load to the database so that the predicted load can be read from the database later.

[0203] It should be noted that the prediction time here refers to the time when load prediction is started. It can be a single point in time, such as a point in time specified by the administrator, or a series of points in time with a fixed time interval (such as a series of points in time with a 1-minute interval), or a series of points in time with a random time interval. This application embodiment does not limit it here.

[0204] The first quantity is determined based on the expansion timeout time and the time granularity corresponding to the historical load. The time granularity corresponding to the historical load is the time unit associated with that historical load, which determines the time span between two consecutive historical loads in chronological order. For example, if the time granularity of the historical load is 1 minute, then two consecutive historical loads in chronological order will be spaced 1 minute apart. The time granularity can be set by the administrator or determined by the second device based on the time granularity used for load forecasting (e.g., forecasting once per hour, once every 10 minutes, once per minute, etc., which can be a commonly used time granularity for load forecasting in the industry).

[0205] The second device can compare the expansion timeout time with the time granularity (expansion timeout time is the denominator and time granularity is the numerator), and use the resulting ratio as the first quantity; the second device can also adjust the resulting ratio, for example, by increasing the resulting ratio by 2 times or decreasing it by 1.5 times (the specific multiple can be set according to the actual situation), and use the adjusted ratio as the first quantity.

[0206] In some embodiments of this application, the second device determines the predicted load for a first time period based on a first number of historical loads. This can be achieved through the following process: using a load prediction model and the first number of historical loads, the load for the first time period is predicted, and the prediction result is determined as the predicted load.

[0207] The second device can read in a first number of historical loads through a load prediction model to perform load prediction, and use the prediction results generated by the load prediction model as the predicted load for the first time period. It should be noted that the load prediction model in this embodiment can be a time series prediction model based on a neural network (i.e., Neuralprophet).

[0208] Load forecasting models can be trained to predict load for a given time period based on historical load data. The training process for load forecasting models is explained below.

[0209] In some embodiments, before performing load prediction for a first time period using a load prediction model and a first number of historical loads, and determining the prediction result as the predicted load, the method may further include the following processing: determining a second time period based on the changing trend characteristics of historical loads; determining training data based on the second time period and time granularity; training the initial prediction model using the training data, and obtaining the load prediction model when the training termination condition is reached.

[0210] Here, the historical load change trend feature is a feature that describes the trend of historical load changes. Through this trend feature, the change cycle of historical load can be clearly identified, for example, changing on a daily or weekly basis. This change cycle is usually related to the business scenario of the scheduling entity. The change trend feature can be a text-type feature that describes the historical load change cycle, such as "changing on a weekly basis." Thus, the second device can parse the historical load change cycle knowledge from the change trend feature. Alternatively, the change trend feature can be an encoding that represents the historical load change cycle, such as "1001." Thus, the electronic device can obtain the historical load change cycle knowledge from a table that records the mapping relationship between the encoding and the change cycle.

[0211] The second time period refers to the time period covered by the training data, that is, the time span formed by the earliest and latest historical loads in the training data. For example, the second device can directly use one or more change cycles, such as one week, as the length of the second time period, and the prediction time, or a point in time before the prediction, as the end time of the second time period. By using the end time and the length of the second time period, the start time of the second time period can be determined, thus obtaining the second time period.

[0212] Understandably, the second device determines the second time period based on the changing trend characteristics. That is, based on the historical load change patterns, it determines which historical loads need to be extracted as training data for this round of model training. In this way, the training data contains knowledge of the historical load change patterns, so that the load prediction model can learn this knowledge through model training and subsequently combine this knowledge to make more accurate load predictions.

[0213] After obtaining the second time period, the second device will combine the aforementioned time granularity to determine which historical loads need to be acquired, and use the dataset formed by these historical loads as training data. For example, when the duration of the second time period is 15 days, and the end time of the second time period is time point 1 with a time granularity of 1 minute, the second device can acquire the historical loads for each minute within the 15 days prior to time point 1 to obtain training data.

[0214] After obtaining the training data, the second device acquires an initial prediction model and trains it using the training data. The training data includes the first number of historical training loads corresponding to each prediction time, and the actual load for the first training time period corresponding to each prediction time (i.e., the time period starting from the prediction time and ending with the sum of the prediction time and the scaling timeout). More specifically, the second device uses the initial prediction model to predict the load for the first number of historical training loads at each prediction time (predicting the load for the first training time period). It calculates the loss value using the difference between the predicted load and the actual load for the first training time period, backpropagates the loss value in the initial prediction model, and adjusts the parameters accordingly. This completes one iteration of training. The second device continues this iteration and exits the training process when the training termination condition is met. The initial prediction model after multiple iterations becomes the load prediction model.

[0215] It should be noted that the training termination condition in this application embodiment can be set according to the actual situation. It can be that the number of iterations reaches a threshold, such as 10,000 times, or the prediction accuracy during training reaches an accuracy threshold, such as 99%. This application embodiment does not limit this.

[0216] It should also be noted that for time series prediction models based on neural networks, hyperparameters (parameters that are not directly learned by the model during training but are set before training; hyperparameters can be set based on experience and experiments) may affect the prediction results. For example, the autoregression order reflects the lagged correlation of the predicted load. Different autoregression orders result in different models (these differences are specifically reflected in the model parameters; that is, different autoregression orders correspond to models with the same structure but different model parameters), and the prediction results are also different. Therefore, during training, it is also necessary to determine the most suitable autoregression order for the model.

[0217] Therefore, in some embodiments, the above-described method of training the initial prediction model using training data and obtaining the load prediction model when the training termination condition is met can be achieved through the following process: using training data, training the initial prediction model at at least two autoregressive orders, and obtaining at least two trained prediction models when the training termination condition is met; using test data, determining the prediction error of each trained prediction model; and selecting the trained prediction model with the smallest prediction error as the load prediction model.

[0218] The test data is used to evaluate the prediction accuracy of the trained prediction model. It can also be obtained from historical loads stored in the database, but it should avoid overlapping with the training data. The second device processes the test data using the trained prediction model corresponding to each autoregressive order to obtain the corresponding prediction error. The processing of the test data is similar to the processing of the training data described above, and will not be repeated here.

[0219] This completes the process of load forecasting for the first time period based on the load forecasting model.

[0220] Of course, in some other embodiments of this application, the second device can determine the predicted load for the first time period based on the first quantity of historical loads, which can also be achieved by the following process: determining the average value of the first quantity of historical loads as the predicted load for the first time period.

[0221] In other words, the second device can calculate the average of the first number of historical loads, and the resulting average is the predicted load for the first time period. This method of determining predicted load is simple and efficient, and can facilitate rapid load prediction.

[0222] Figure 9 This is a flowchart illustrating the cluster scheduling entity processing method provided in the embodiments of this application. Figure 4 In some embodiments of this application, in Figure 6Before step 101, that is, before the first device sends a synchronization request for the prediction result to the second device for the first time period, the method may further include the following processing:

[0223] Step 107: The first device receives the real-time load of the cluster sent by the second management server.

[0224] The second management server is responsible for statistically analyzing and transmitting the real-time load of the cluster. It obtains the real-time load of the cluster by averaging or taking the maximum value of the real-time load of each computer node in the cluster, and then sends the real-time load data to the first device.

[0225] Step 108: The second device receives the real-time load of the cluster sent by the first device and stores the real-time load in the database.

[0226] After receiving the real-time load of the cluster reported by the second management server, the first device synchronizes the real-time load of the cluster to the second device, so that the second device writes the real-time load of the cluster into the database for use in subsequent load prediction or training of load prediction models.

[0227] The following describes the application scenarios of the cluster scheduling entity processing method provided in the embodiments of this application.

[0228] The cluster scheduling entity processing method of this application embodiment can be applied to game background processing. In this case, the scheduling entity is used to encapsulate and run the game program, that is, the business process in the scheduling entity, which is used to process the user's business requests in the game. At this time, the first device sends a prediction result synchronization request to the second device for a first time period, wherein the first time period is a time period with the current time as the start time and the sum of the current time and the expansion timeout time as the end time; the first device receives the prediction load returned by the second device in response to the prediction result synchronization request; the first device receives the first entity number reported by the third device, that is, the number of scheduling entities in the running state at the current time; the first device determines the second entity number for the first time period based on the prediction load, the expected load and the first entity number; the first device sends the second entity number to the third device so that the third device can expand or shrink the scheduling entity according to the second entity number.

[0229] The cluster scheduling entity processing method of this application embodiment can also be applied to social networking services. In this case, the scheduling entity is used to encapsulate and run social applications, i.e., the business processes in the scheduling entity are used to process user business requests in the social networking service. At this time, the first device sends a prediction result synchronization request to the second device for a first time period, wherein the first time period is a time period with the current time as the start time and the sum of the current time and the expansion timeout time as the end time; the first device receives the prediction load returned by the second device in response to the prediction result synchronization request; the first device receives the first entity number reported by the third device, i.e., the number of scheduling entities in the running state at the current time; the first device determines the second entity number for the first time period based on the prediction load, the expected load and the first entity number; the first device issues the second entity number to the third device so that the third device can expand or shrink the scheduling entity according to the second entity number.

[0230] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0231] This application embodiment is implemented in a scenario where Pod replicas (scheduling entities) used for packaging and running game programs are scaled up or down. First, the overall architecture of Pod replica scaling in this application embodiment will be described.

[0232] The overall architecture for scaling up and down Pod replicas in this application mainly includes a coordination server (corresponding to the first device), a prediction server (corresponding to the second device), and a device for executing a GPU-based Horizontal Pod Autoscaler (GPA) (hereinafter referred to as the GPA device, which corresponds to the third device).

[0233] The coordinating server, acting as the decision-maker for scaling up and down Pod replicas, primarily performs the following functions: receiving real-time load reports, periodically synchronizing real-time load to the prediction server, obtaining predicted load from the prediction server, calculating the desired number of Pod replicas (corresponding to the number of second entities), and issuing the desired number of Pod replicas. The prediction server, acting as the executor of load prediction, primarily performs the following functions: receiving and storing the real-time load synchronized by the coordinating server, launching the prediction model (corresponding to the load prediction model) for load prediction, and training the prediction model. The GPA device, acting as the actual executor of scaling up and down Pod replicas, primarily performs the following functions: reporting the current number of Pod replicas (corresponding to the number of first entities) to the coordinating server, receiving the desired number of Pod replicas, and scaling up or down Pod replicas.

[0234] For example, Figure 10 This is a schematic diagram of the Pod replica scaling architecture provided in this application embodiment. In the Pod replica scaling architecture 10-1, there are a coordination server 10-11, a prediction server 10-12, a GPA device 10-13, a Pod cluster 10-14, a Pod cluster 10-15, and a Pod replica controller 10-16. Specifically, the coordination server 10-11 synchronizes real-time load with the prediction server 10-12 and obtains predicted load from the prediction server 10-12; the coordination server 10-11 receives the real-time load of the cluster reported by the management center 10-141 (corresponding to the second management server) of cluster 10-14, and receives the real-time load of the cluster reported by the management center 10-151 in cluster 10-15. Here, the management center 10-141 is used to manage the Pod agent 10-142 (corresponding to the first management server) in cluster 10-14, for example, by receiving the real-time load reported by the Pod agent 10-142. The real-time load of the Pod cluster is statistically obtained. Pod agent 10-142 is used to manage the DS process (corresponding to the business process) that executes the game logic. Similarly, the management center 10-151 is used to manage Pod agent 10-152 (corresponding to the first management server) in cluster 10-15. GPA device 10-13 reports the current number of Pod replicas to the coordination server 10-11 and receives the expected number of Pod replicas issued by the coordination server 10-11. By comparing the current number of Pod replicas and the expected number of Pod replicas, it determines whether to scale up or down the Pod replicas. When scaling up or down, GPA device 10-13 issues instructions to Pod replica controller 10-16 so that Pod replica controller 10-16 can create new Pod replicas or delete Pod replicas. The scaling architecture 10-1 for Pod replicas may also include a device (referred to as CA device) 10-17 for the horizontal scaling mechanism (Cluster Autoscaler, CA) of execution nodes, which is used to scale up or down computer nodes, such as purchasing or delisting machines from cloud service providers.

[0235] Figure 11 This is a flowchart illustrating the implementation of automatic scaling according to an embodiment of this application. See also... Figure 11 The method includes the following processing:

[0236] Step 301: The management center of the Pod cluster reports the real-time load of the cluster to the coordination server.

[0237] Step 302: The coordination server receives the current number of Pod replicas reported by the GPA device.

[0238] Step 303: The coordinating server calculates the desired number of Pod replicas.

[0239] Step 304: The coordination server sends the desired number of Pod replicas to the GPA device.

[0240] Step 305: The Pod agent synchronizes state information with the coordination server.

[0241] This status information is used to characterize the running status of the ds process in the Pod replica.

[0242] Step 306: When the Pod replica corresponding to the Pod agent (corresponding to the scheduling entity waiting to be shut down) needs to be shut down, the coordination server issues a blocking command.

[0243] Step 307: Coordinate the server to check for scaling down and emptying of Pod replicas.

[0244] Repeat the above process.

[0245] Figure 12 This is a flowchart illustrating the implementation of calculating the desired number of Pod replicas provided in an embodiment of this application. See also... Figure 12 The method includes the following processing:

[0246] Step 401: The coordination server periodically reports the real-time load of the Pod cluster to the prediction server.

[0247] Step 402: The prediction server writes the received real-time load into the database.

[0248] Step 403: The prediction server performs load prediction to obtain the predicted load.

[0249] Step 404: The prediction server writes the predicted load into the database.

[0250] Step 405: The coordination server requests the prediction results from the prediction server (this request corresponds to the prediction result synchronization request).

[0251] Step 406: The prediction server returns the predicted load to the coordination server.

[0252] Step 407: Coordinate the server to calculate the number of Pod replicas.

[0253] It should be noted that in this embodiment of the application, the prediction server can automatically start load prediction as soon as the predetermined time (corresponding to the predicted time) is reached, for example... Figure 12 As shown, a predetermined time is reached between steps 405 and 406, so that step 408 can be executed as follows:

[0254] Step 408: The prediction server performs the next round of load prediction.

[0255] The design concept of the load prediction strategy in the embodiments of this application will be explained below.

[0256] First, load forecasting primarily addresses the issue of Pod replica count calculation lag caused by the time-consuming scaling process during rapid load increases in the short term. Therefore, load forecasting is essentially a short-term prediction. During scaling down, the time from the actual termination of a Pod replica to the machine's reclamation also takes a considerable amount of time. However, for game applications, simply disabling the Pod replicas to be scaled down can be considered a complete scaling down, achieving sub-second scaling. Therefore, scaling down can be considered immediate, making scaling down based on the current load decision reasonable. Furthermore, from a risk control perspective, premature scaling down may not be appropriate.

[0257] For example, Figure 13 This is a schematic diagram of load changes provided in the embodiments of this application. Figure 1 See also Figure 13 If the load at time t2 is used to determine the current time, i.e., the scaling down starts at time t1, the scaling down will be brought forward, so the predicted load seems to be unsuitable for scaling down.

[0258] However, since the time required for capacity expansion can be affected by many factors, it is not a fixed time, which can easily lead to frequent capacity expansions. Figure 14 This is a schematic diagram of load changes provided in the embodiments of this application. Figure 2 ,like Figure 14 As shown, when calculating Pod replicas and deciding on scaling up at time t using the load at time t+x, it may be due to some reasons that the scaling up can only be completed at time t1. However, the load continues to increase between time t and t1. Therefore, when the scaling up is completed, the same problem needs to be faced, namely, using the number of Pod replicas at time t+x to cope with the load at time t1.

[0259] It is evident that using predicted load at a future point in time to calculate the number of Pod replicas may be insufficient to handle sudden load fluctuations. Therefore, the scaling-up / scaling decision-making approach can be tentatively defined as follows: use the current load to decide whether to scale down, and use the maximum load from the current time t to time t+y (corresponding to the first time period) to calculate the number of Pod replicas and decide whether to scale up. Here, y represents the estimated scaling-up timeout.

[0260] Figure 15 This is a schematic diagram of load changes provided in the embodiments of this application. Figure 3 .from Figure 15 It can be seen that the following two situations may occur with this strategy:

[0261] 1) If it is determined at time t1 that capacity reduction is required based on the current load, but at time t3 (t3 < t1 + y), if the load peak arrives, then the time left for capacity expansion is insufficient.

[0262] 2) If it is determined at time t1 based on the predicted load that the load is the largest at time t3, and a decision is made to expand capacity, but the capacity expansion is completed at time t2. Thus, the number of Pod replicas at this time is for carrying the load peak at time t3, and this number of Pod replicas is originally greater than the number of Pod replicas required at time t2. Therefore, capacity reduction may occur at time t2.

[0263] As can be seen from the above, if only the current load is used to determine whether to reduce capacity, it is easy to cause the problem of premature capacity reduction. Therefore, capacity reduction also needs to be associated with the predicted load. Based on the above analysis, the decision-making idea for capacity expansion and reduction can be set as follows: Calculate the number of Pod replicas using the maximum load from the current time t to the time t + y, which is y minutes later in the future, and decide whether to expand or reduce capacity.

[0264] In this case, although it is certain that the maximum load within the next y minutes is greater than or equal to the current load, considering that there may be risks in load prediction (i.e., inaccurate prediction), the maximum value of the predicted load and the current load (corresponding to the maximum load) can be used to complete the calculation of the number of Pod replicas and the decision-making for capacity expansion and reduction. Thus, the final formula for the load used to calculate the number of Pod replicas can be shown as in Equation (1):

[0265]

[0266] where, forecastPayload i is the predicted load, payload is the load finally used to calculate the number of Pod replicas, and forecastPayload is the maximum value in the predicted load.

[0267] After obtaining the load used to calculate the number of Pod replicas, the expected number of Pod replicas can be calculated according to Equation (2):

[0268]

[0269] where, payload is the load finally used to calculate the number of Pod replicas, desirePayload is the expected load (corresponding to the expected load), curReplicas is the current number of Pod replicas (corresponding to the first entity quantity), and desireReplicas is the expected number of Pod replicas.

[0270] It's important to note that in order to periodically and continuously obtain future load forecasts within a short timeframe, each prediction needs to be completed quickly, or at least for a longer duration. However, the accuracy of load forecasting is related to the forecast duration and the size of the training set. If the training set is too large, the model training time will increase. Conversely, if the forecast duration is too long, the accuracy of load forecasting will decrease.

[0271] In this embodiment, load prediction is implemented using real-time prediction. In this embodiment, a fixed-size training set n (corresponding to training data) is set. The prediction server continuously receives real-time load reports from the coordination server and maintains a training set of length n based on the received load. This training set is continuously updated. The prediction server periodically calls the prediction model (corresponding to the load prediction model) to complete short-term predictions and stores the obtained predicted loads so that they can be returned when the coordination server requests predicted loads.

[0272] For example, Figure 16 This is a schematic diagram illustrating the load prediction process provided in an embodiment of this application. See also... Figure 16 Coordination server 16-1 reports real-time load to prediction server 16-2, and prediction server 16-2 calls the prediction model to perform load prediction 16-3. During load prediction, the input length is the same each time, for example... Figure 16 The inputs (x1, x2, ..., x) for two consecutive load forecasts shown are shown. n ) and (x 31 ,x 32 ,…,x n+30 ), whose length is n; (x1,x2,…,x n The output of ) is (y n+1 ,y n+2 ,…,y n+30 ), (x 31 ,x 32 ,…,x n+30 The output of ) is (y n+31 ,y n+32 ,…,x n+60 Afterwards, prediction server 16-2 stores the predicted load and returns the predicted load to coordination server 16-1 when coordination server 16-1 requests the predicted load.

[0273] In this embodiment, NeuralProphet (corresponding to the load prediction model) can be used for load prediction. The autoregressive order n_lags of NeuralProphet has a significant impact on the predicted load, reflecting the lag correlation of the predicted load. The autoregressive order n_lags is correlated with the size of the training set and the prediction length; therefore, the size of the training set and the prediction duration need to be determined before setting the autoregressive order n_lags.

[0274] Here, due to the specific daily and weekly seasonality of game load (corresponding to changing trend characteristics), and because NeuralProphet requires twice the data when modeling periodically, at least 14 days of data are needed for model training. In this embodiment, the training set size is set to 15 days. Furthermore, since NeuralProphet supports a minimum granularity of minutes for prediction, combined with an average scaling time of 20 minutes, the prediction time can be set to 30 minutes. This means the coordinating server selects the maximum load for the next 30 minutes to calculate the expected number of Pod replicas.

[0275] As can be seen, in this embodiment of the application, the training set size is 15 days, the prediction length is 30 minutes, and the time granularity is minutes. Thus, the prediction server can extract 21,600 historical loads for model training. These data occupy less than 1MB of memory, and a single prediction takes 80 seconds, occupying approximately 500MB of memory.

[0276] Next, we need to determine the autoregression order, n_lags. At this point, we can set up multiple experimental groups, for example, n_lags = 60 * 2 (meaning regression using historical data from the last 2 hours), n_lags = 60 * 24 (meaning regression using historical data from the last 24 hours), n_lags = 60 * 24 * 2 (meaning regression using historical data from the last 2 days), and n_lags = 60 * 24 * 7 (meaning regression using historical data from the last week). This will give us the data in Table 1:

[0277] Table 1

[0278]

[0279] As shown in Table 1, setting the autoregressive order n_lags to 2 days is reasonable. Therefore, the hyperparameters used in the final prediction are shown in Table 2:

[0280] Table 2

[0281] Parameter name Parameter value Parameter meaning training set 15 days Training set size Data resolution 1min Training set data granularity n_forecasts 30 Predicted length n_lags 24*60*2 Autoregressive order changepoints_range 0.95 Mutation search range daily_seasonality 10 Daily Fourier terms weekly_seasonality 8 Zhou Fourier terms yearly_seasonality false Annual seasonal seasonlity_mode additive Seasonal patterns

[0282] The prediction accuracy of the prediction server in the embodiments of this application will be described below.

[0283] To verify the accuracy of the prediction server's predictions, the coordination server continuously provides the historical load data of the game to the prediction server. The prediction server periodically starts load prediction to obtain the predicted load. Then, curves are plotted for the predicted load and the actual load for comparison.

[0284] Figure 17 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 1 See also Figure 17 Curve 17-1 represents the predicted load from the morning to the evening peak, while curve 17-2 represents the actual load from the morning to the evening peak. It can be seen that the overall trends of the predicted load and the actual load are basically consistent during this period.

[0285] Figure 18 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 2 See also Figure 18 Curve 18-1 represents the predicted load from the evening peak to the early morning of the next day, while curve 18-2 represents the actual load from the evening peak to the early morning of the next day. It can be seen that during this period, the overall trends of the predicted load and the actual load are basically consistent.

[0286] Figure 19 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 3 See also Figure 19 Curve 19-1 represents the predicted load for 24 hours, and curve 19-2 represents the actual load for 24 hours. It can be seen that the overall trends of the predicted load and the actual load are basically consistent throughout the day.

[0287] Figure 20 This is a schematic diagram comparing the predicted load and the actual load provided in the embodiments of this application. Figure 4 See also Figure 20 Curve 20-1 represents the predicted load from Thursday to Sunday, and curve 20-2 represents the actual load from Thursday to Sunday. It can be seen that the prediction server can simulate the higher load on Friday evening compared to Thursday evening, and can also simulate the midday peak on Saturday and Sunday. Although there are some errors in the midday peak on Saturday, it can be adjusted quickly. It can also predict that the highest load of the week will occur on Saturday evening, and the load will decrease on Sunday evening.

[0288] In summary, the prediction server in this application embodiment can accurately predict the load.

[0289] It is understood that in the embodiments of this application, user information, such as game requests and other related data, is involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0290] The following description continues to illustrate the exemplary structure of the cluster scheduling entity processing device 255 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 3 As shown, the software modules in the processing device 255 of the cluster scheduling entity stored in the first memory 250 may include:

[0291] The first sending module 2551 is used to send a prediction result synchronization request to the second device for a first time period, the prediction result synchronization request being used to request a predicted load from the second device; and to send a second entity number to the third device, the third device being used to expand or shrink the scheduling entity according to the second entity number and the first entity number.

[0292] The first receiving module 2552 is configured to receive the predicted load returned by the second device in response to the synchronization request of the prediction result, wherein the predicted load is the load predicted by the second device for the cluster, and the cluster includes multiple scheduling entities; and to receive the first number of entities sent by the third device.

[0293] The quantity determination module 2553 is used to determine the number of second entities in the first time period based on the predicted load, expected load and the number of the first entities.

[0294] In the above scheme, the quantity determination module 2553 is further configured to filter the maximum load of the first time period from the predicted load and the current load; and determine the second entity quantity of the first time period based on the maximum load, the expected load and the first entity quantity.

[0295] In the above scheme, the quantity determination module 2553 is further configured to calculate a first load ratio based on the maximum load and the expected load; and determine the second entity quantity in the first time period based on the first entity quantity and the first load ratio.

[0296] In the above scheme, the quantity determination module 2553 is further configured to calculate a second load ratio based on the predicted load and the expected load; and determine the second entity quantity in the first time period based on the first entity quantity and the second load ratio.

[0297] In the above scheme, the first receiving module 2552 is further configured to receive a scheduling entity waiting to be closed sent by the third device; wherein, the scheduling entity waiting to be closed is determined by the third device from the scheduling entities currently in operation when scaling down the scheduling entity; and to receive the status information of the service process sent by the first management server; wherein, the service process runs in the scheduling entity waiting to be closed, and the first management server is the server that manages the service process.

[0298] The first sending module 2551 is further configured to send a blocking instruction to the first management server for the scheduling entity waiting to be closed when the status information indicates that the service process is running; the blocking instruction is used to initiate the shrinkage and emptying of the scheduling entity waiting to be closed.

[0299] In the above scheme, the first sending module 2551 is further configured to send a drain completion message to the third device when the scheduling entity waiting to be closed completes the shrinkage and draining. The third device is configured to close the scheduling entity waiting to be closed when it receives the drain completion message.

[0300] In the above scheme, the first receiving module 2552 is also used to receive the real-time load of the cluster sent by the second management server; the second management server is a server that performs statistics and sends the real-time load of the cluster.

[0301] The first sending module 2551 is further configured to send the real-time load of the cluster to the second device, wherein the second device is configured to store the real-time load in a database.

[0302] The following description continues to illustrate the exemplary structure of the cluster scheduling entity processing device 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 4 As shown, the software modules in the processing device 455 of the cluster scheduling entity stored in the second memory 450 may include:

[0303] The second receiving module 4551 is used to receive the prediction result synchronization request sent by the first device for the first time period;

[0304] The second sending module 4552 is used to return a predicted load to the first device in response to the prediction result synchronization request. The predicted load is the load predicted for the cluster, and the cluster includes multiple scheduling entities. The first device is used to determine a second number of entities based on the predicted load, the expected load, and the number of first entities sent by the third device, and send the number of second entities to the third device. The third device is used to expand or shrink the scheduling entities according to the number of first entities and the number of second entities.

[0305] In the above scheme, the second sending module 4552 is further configured to read the predicted load of the first time period from the database in response to the prediction result synchronization request; and return the predicted load to the first device.

[0306] In the above scheme, the processing device 455 of the cluster scheduling entity further includes: a load prediction module 4553, used to read a first quantity of historical loads from the database when the prediction time is reached; wherein, the first quantity is determined based on the expansion timeout time and the time granularity corresponding to the historical loads; based on the first quantity of historical loads, the predicted load for the first time period is determined; and the predicted loads are stored in the database.

[0307] In the above scheme, the load prediction module 4553 is further configured to perform load prediction for the first time period using the load prediction model and the first number of historical loads, and determine the prediction result as the predicted load.

[0308] In the above scheme, the load prediction module 4553 is further configured to determine a second time period based on the historical load change trend characteristics; determine training data based on the second time period and the time granularity; train the initial prediction model using the training data; and obtain the load prediction model when the training termination condition is reached.

[0309] In the above scheme, the load prediction module 4553 is further configured to use the training data to train the initial prediction model at at least two autoregressive orders, and obtain at least two trained prediction models when the training termination condition is reached; use test data to determine the prediction error of each trained prediction model; and use the trained prediction model with the smallest prediction error as the load prediction model.

[0310] In the above scheme, the second receiving module 4551 is further configured to receive the real-time load of the cluster sent by the first device and store the real-time load in the database; wherein the real-time load is sent to the first device by the second management server, and the second management server is a server that performs statistics and sends the real-time load of the cluster.

[0311] The following description continues to illustrate the exemplary structure of the cluster scheduling entity processing device 655 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 5 As shown, the software modules in the processing device 655 of the cluster scheduling entity stored in the third memory 650 may include:

[0312] The third sending module 6551 is used to send the first entity quantity to the first device;

[0313] The third receiving module 6552 is used to receive the second entity quantity sent by the first device; wherein the second entity quantity is determined by the first device based on the predicted load, the expected load and the first entity quantity, the predicted load is returned by the second device in response to the prediction result synchronization request of the first device, and the prediction result synchronization request is sent by the first device for a first time period;

[0314] The entity processing module 6553 is used to expand or shrink the scheduling entity according to the first entity quantity and the second entity quantity.

[0315] In the above scheme, the entity processing module 6553 is further configured to expand the scheduling entity when the number of the first entity is less than the number of the second entity, and to shrink the scheduling entity when the number of the first entity is greater than the number of the second entity.

[0316] In the above scheme, the entity processing module 6553 is further configured to determine the scheduling entities waiting to be shut down from the scheduling entities currently in the running state;

[0317] The third sending module 6551 is further configured to send the scheduling entity waiting to be shut down to the first device; wherein, the first device is configured to send a blocking instruction to the first management server, the second management server is a server that manages the business processes running in the scheduling entity waiting to be shut down, and the blocking instruction is configured to initiate the shrinkage and emptying of the scheduling entity waiting to be shut down.

[0318] In the above scheme, the third receiving module 6552 is also used to receive the emptying completion message sent by the first device;

[0319] The entity processing module 6553 is also used to close the scheduling entity waiting to be closed.

[0320] This application provides a computer program product including a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the cluster scheduling entity processing method described above in this application embodiment.

[0321] This application provides a computer-readable storage medium storing computer-executable instructions or computer programs. When the computer-executable instructions or computer programs are executed by a processor, the processor will execute the processing method of the scheduling entity of the first device-side cluster, the processing method of the scheduling entity of the second device-side cluster, or the processing method of the scheduling entity of the third device-side cluster provided in this application.

[0322] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0323] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0324] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0325] As an example, computer-executable instructions may be deployed to execute on an electronic device (which may be any one or more of a first device, a second device, and a third device), or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected by a communication network.

[0326] In summary, through the embodiments of this application, the predicted load is the load that occurs during the timeout waiting period during scaling up. Based on this predicted load, the number of second entities is calculated for scaling up and down. This reduces the frequency of frequent scaling up and down due to load fluctuations, thus enabling better handling of load changes. Furthermore, the number of scheduling entities calculated based on the predicted load matches the load in the first time period, and scaling up and down according to this number reduces wasted computing resources. Therefore, it achieves the effect of saving computing resources consumed in the event of load fluctuations.

[0327] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for processing a cluster scheduling entity, characterized in that, Applied to a first device, the method includes: For the first time period, a prediction result synchronization request is sent to the second device, the prediction result synchronization request being used to request a predicted load from the second device; The system receives the predicted load returned by the second device in response to the synchronization request for the prediction result. The predicted load is the load predicted by the second device for the cluster, and the cluster includes multiple scheduling entities. The number of the first entities received from the third device; Based on the predicted load, expected load, and the number of the first entity, determine the number of the second entity for the first time period; The third device sends the second entity quantity to the third device, which is used to expand or shrink the scheduling entity based on the second entity quantity and the first entity quantity.

2. The method according to claim 1, characterized in that, Determining the number of second entities for the first time period based on the predicted load, expected load, and the number of first entities includes: Filter the maximum load for the first time period from the predicted load and the current load; The number of the second entities in the first time period is determined based on the maximum load, the expected load, and the number of the first entities.

3. The method according to claim 2, characterized in that, Determining the number of the second entities in the first time period based on the maximum load, the expected load, and the number of the first entities includes: The first load ratio is calculated based on the maximum load and the expected load. The number of the second entity is determined based on the first entity number and the first load ratio.

4. The method according to claim 1, characterized in that, Determining the number of second entities for the first time period based on the predicted load, expected load, and the number of first entities includes: Based on the predicted load and the expected load, the second load ratio is calculated; The number of the second entities is determined based on the first entity count and the second load ratio for the first time period.

5. The method according to any one of claims 1 to 4, characterized in that, After sending the second entity quantity to the third device, the method further includes: The third device receives a scheduling entity awaiting shutdown; wherein the scheduling entity awaiting shutdown is determined by the third device from the scheduling entities currently in operation when scaling down the scheduling entity. Receive status information of the service process sent by the first management server; wherein the service process runs in the scheduling entity waiting to be shut down, and the first management server is the server that manages the service process; When the status information indicates that the service process is running, a blocking instruction is sent to the first management server for the scheduling entity waiting to be shut down; the blocking instruction is used to initiate the scaling down and emptying of the scheduling entity waiting to be shut down.

6. The method according to claim 5, characterized in that, After sending a blocking command to the first management server for the scheduling entity waiting to be shut down, the method further includes: When the scheduling entity waiting to be shut down completes its scaling down and emptying, it sends an emptying completion message to the third device. The third device then shuts down the scheduling entity waiting to be shut down upon receiving the emptying completion message.

7. The method according to any one of claims 1 to 6, characterized in that, Before sending the prediction result synchronization request to the second device for the first time period, the method further includes: Receive the real-time load of the cluster sent by the second management server; the second management server is a server that performs statistics on and sends the real-time load of the cluster. The real-time load of the cluster is sent to the second device, wherein the second device is used to store the real-time load in a database.

8. A method for processing a cluster scheduling entity, characterized in that, Applied to a second device, the method includes: Receive the prediction result synchronization request sent by the first device for the first time period; In response to the synchronization request for the prediction results, a predicted load is returned to the first device. The predicted load is the load predicted for the cluster, which includes multiple scheduling entities. The first device is used to determine the second number of entities based on the predicted load, the expected load, and the first number of entities sent by the third device, and to send the second number of entities to the third device. The third device is used to expand or shrink the scheduling entities according to the first number of entities and the second number of entities.

9. The method according to claim 8, characterized in that, The step of returning the predicted load to the first device in response to the synchronization request for the predicted result includes: In response to the prediction result synchronization request, the prediction load for the first time period is read from the database; The predicted load is returned to the first device.

10. The method according to claim 9, characterized in that, Before reading the prediction load for the first time period from the database in response to the prediction result synchronization request, the method further includes: When the predicted time is reached, a first quantity of historical load is read from the database; wherein, the first quantity is determined based on the expansion timeout time and the time granularity corresponding to the historical load; Based on the first number of historical loads, determine the predicted load for the first time period; The predicted load is stored in the database.

11. The method according to claim 10, characterized in that, Determining the predicted load for the first time period based on the first number of historical loads includes: Using a load forecasting model and the first number of historical loads, load forecasting is performed for the first time period, and the forecast result is determined as the predicted load.

12. The method according to claim 11, characterized in that, Before determining the predicted load by using a load prediction model and the first number of historical loads to predict the load for the first time period, the method further includes: Based on the historical load change trend characteristics, a second time period is determined; Based on the second time period and the time granularity, the training data is determined; The initial prediction model is trained using the training data, and the load prediction model is obtained when the training termination condition is met.

13. The method according to claim 12, characterized in that, The step of training the initial prediction model using the training data and obtaining the load prediction model upon reaching the training termination condition includes: Using the training data, the initial prediction model is trained at at least two autoregressive orders, and at least two trained prediction models are obtained when the training termination condition is met. Using test data, determine the prediction error of each trained prediction model; The training prediction model with the smallest prediction error is used as the load prediction model.

14. The method according to any one of claims 10 to 13, characterized in that, Before reading a first quantity of historical load from the database when the predicted time is reached, the method further includes: The system receives the real-time load of the cluster sent by the first device and stores the real-time load in a database; wherein the real-time load is sent to the first device by a second management server, which is a server that performs statistics and sends the real-time load of the cluster.

15. A method for processing a cluster scheduling entity, characterized in that, Applied to a third device, the method includes: Send the first quantity of entities to the first device; Receive the second entity count sent by the first device; wherein the second entity count is determined by the first device based on the predicted load, the expected load and the first entity count, the predicted load is returned by the second device in response to the prediction result synchronization request of the first device, and the prediction result synchronization request is sent by the first device for a first time period; Based on the number of the first entity and the number of the second entity, the scheduling entity is expanded or reduced in size.

16. The method according to claim 15, characterized in that, The step of scaling up or down the scheduling entity based on the first entity quantity and the second entity quantity includes: When the number of the first entity is less than the number of the second entity, the scheduling entity is expanded. When the number of the first entity is greater than the number of the second entity, the scheduling entity is scaled down.

17. The method according to claim 16, characterized in that, The scaling down of the scheduling entity includes: From the currently running scheduling entities, identify the scheduling entities that are waiting to be shut down; The scheduling entity awaiting closure is sent to the first device; wherein, the first device is used to send a blocking instruction to the first management server, the first management server is a server that manages the business processes running in the scheduling entity awaiting closure, and the blocking instruction is used to initiate the shrinking and emptying of the scheduling entity awaiting closure.

18. The method according to claim 17, characterized in that, After sending the scheduling entity waiting to be shut down to the first device, the method further includes: Receive the emptying complete message sent by the first device; The scheduling entity that is waiting to be shut down is shut down.

19. A processing apparatus for a cluster scheduling entity, characterized in that, The device includes: The first sending module is used to send a prediction result synchronization request to the second device for a first time period, the prediction result synchronization request being used to request a predicted load from the second device; and to send a second entity number to the third device, the third device being used to expand or shrink the scheduling entity according to the second entity number and the first entity number. The first receiving module is configured to receive the predicted load returned by the second device in response to the synchronization request of the prediction result, wherein the predicted load is the load predicted by the second device for the cluster, and the cluster includes multiple scheduling entities; and to receive the first number of entities sent by the third device. The quantity determination module is used to determine the number of second entities in the first time period based on the predicted load, expected load, and the number of the first entities.

20. A processing apparatus for a cluster scheduling entity, characterized in that, The device includes: The second receiving module is used to receive the prediction result synchronization request sent by the first device for the first time period; The second sending module is used to return a predicted load to the first device in response to the prediction result synchronization request. The predicted load is the load predicted for the cluster, and the cluster includes multiple scheduling entities. The first device is used to determine a second number of entities based on the predicted load, the expected load, and the number of first entities sent by the third device, and send the number of second entities to the third device. The third device is used to expand or shrink the scheduling entities according to the number of first entities and the number of second entities.

21. A processing apparatus for a cluster scheduling entity, characterized in that, The device includes: The third sending module is used to send the first entity quantity to the first device; The third receiving module is used to receive the second entity quantity sent by the first device; wherein the second entity quantity is determined by the first device based on the predicted load, the expected load and the first entity quantity, the predicted load is returned by the second device in response to the prediction result synchronization request of the first device, and the prediction result synchronization request is sent by the first device for a first time period; The entity processing module is used to expand or shrink the scheduling entity according to the first entity quantity and the second entity quantity.

22. A first device, characterized in that, The first device includes: The first memory is used to store computer-executable instructions or computer programs; The first processor, when executing computer-executable instructions or computer programs stored in the first memory, implements the method according to any one of claims 1 to 7.

23. A second device, characterized in that, The second device includes: Secondary memory is used to store computer-executable instructions or computer programs; The second processor, when executing computer-executable instructions or computer programs stored in the second memory, implements the method according to any one of claims 8 to 14.

24. A third device, characterized in that, The third device includes: The third memory is used to store computer-executable instructions or computer programs; A third processor, when executing computer-executable instructions or computer programs stored in the third memory, implements the method according to any one of claims 15 to 18.

25. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method of any one of claims 1 to 7, the method of any one of claims 8 to 14, or the method of any one of claims 15 to 18.

26. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method of any one of claims 1 to 7, the method of any one of claims 8 to 14, or the method of any one of claims 15 to 18.

Images