Computing resource allocation method, apparatus, device, medium, and product

Abstract

The specification provides an operation resource allocation method, device, equipment, medium and product, wherein the method comprises: periodically acquiring a system historical request quantity set in a set historical period and a historical service feature set of service requests received in the historical period; the end of the historical period is the current time, the system historical request quantity set comprises a plurality of system request quantity values collected at a plurality of sampling time points in the historical period; calling a pre-trained request quantity prediction model to process the system historical request quantity set and the historical service feature set to obtain a system future request quantity prediction result; determining a future request quantity of each service processing module according to the system future request quantity prediction result, and determining a target service processing module needing operation resource adjustment and a resource allocation strategy for adjusting the processing capacity of the target service processing module according to the future request quantity of each service processing module.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to a method, apparatus, device, medium and product for allocating computing resources. Background Technology

[0002] With the rapid development of internet technology, cloud computing, and big data, online services (such as e-commerce, social media, online games, live video streaming, and financial transactions) have become an indispensable part of social production and daily life. The core of these services lies in providing a high-concurrency, high-availability, and low-latency access experience for a massive number of users.

[0003] However, due to the suddenness of online trending events or the instantaneous explosive effect of marketing campaigns, online service systems often face the severe challenge of sudden traffic surges. These surges typically manifest as an exponential or even dozens of times increase in request volume within a very short period, far exceeding the system's normal load capacity. However, related technologies generally suffer from drawbacks such as slow response times, lack of foresight, and unintelligent resource utilization when facing such traffic surges. Summary of the Invention

[0004] In view of this, in order to at least solve the technical problems of slow response and lack of foresight when facing sudden traffic surges in related technologies, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a computing resource allocation method is proposed, applied to a service system, the service system being configured with multiple business processing modules for processing business requests, including:

[0006] The system periodically acquires a set of historical request volumes within a set historical period, as well as a set of historical service characteristics of service requests received within the historical period; wherein the end point of the historical period is the current time, and the set of historical request volumes includes multiple system request volume values ​​collected at multiple sampling time points within the historical period.

[0007] The pre-trained request volume prediction model is invoked to process the historical request volume set and the historical business feature set of the system to obtain the future request volume prediction result of the system.

[0008] Based on the system's future request volume prediction results, the future request volume of each business processing module is determined, and based on the future request volume of each business processing module, the target business processing module that needs to have its computing resources adjusted, as well as the resource allocation strategy of the target business processing module, are determined; the resource allocation strategy is used to adjust the processing capacity of the target business processing module.

[0009] According to a second aspect of one or more embodiments of this specification, a computing resource allocation apparatus is provided, comprising:

[0010] The acquisition module is configured to periodically acquire a set of historical system request volumes within a set historical period, and a set of historical service characteristics of service requests received within the historical period; wherein the end point of the historical period is the current time, and the set of historical system request volumes includes multiple system request volume values ​​collected at multiple sampling time points within the historical period.

[0011] The prediction module is configured to: call a pre-trained request volume prediction model to process the system's historical request volume set and the historical business feature set to obtain the system's future request volume prediction result;

[0012] The resource allocation module is configured to: determine the future request volume of each business processing module based on the future request volume prediction results of the system, and determine the target business processing module that needs to have its computing resources adjusted, as well as the resource allocation strategy of the target business processing module, based on the future request volume of each business processing module; the resource allocation strategy is used to adjust the processing capacity of the target business processing module.

[0013] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the computing resource allocation method provided in the first aspect by executing the executable instructions.

[0014] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the computing resource allocation method provided in the first aspect above.

[0015] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the computing resource allocation method provided in the first aspect above.

[0016] As can be seen from the above embodiments, this specification, during the process of the service system processing business requests, periodically acquires a set of historical system request volumes formed by multiple system request volume values ​​collected at multiple sampling time points within a set historical period with the current time as the endpoint, and a set of historical business characteristics formed by the business characteristics of the business requests received by the system within that historical period. A pre-trained request volume prediction model is then invoked to process the system based on the historical request volume set and the historical business characteristic set to obtain a prediction result for the future system request volume. This allows the request volume prediction model to accurately predict the future system request volume in each prediction period by combining the system business request volume and business request characteristics within the most recent historical period, thereby achieving advance prediction of traffic peaks. Based on this, after predicting the future request volume of the system in each prediction cycle, the system further analyzes the future request volume of each business processing module in the service system based on the prediction results. Then, based on the future request volume of each business processing module, the system determines the target business processing module that needs to adjust computing resources and the resource allocation strategy for the target business processing module. This allows the system to specifically locate the target business processing module with a large load during the traffic peak before it arrives and allocate computing resources to the target business processing module in advance. This not only effectively avoids the overload of the target business processing module when the traffic peak arrives and effectively solves the problem of resource allocation lag, thereby improving the stability and high availability of the service system under extreme traffic impact, but also allows the system to allocate computing resources only to the target business processing module, which can reduce the computing load of resource allocation to a certain extent and improve the efficiency of resource allocation. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the architecture of a service system provided in an exemplary embodiment.

[0018] Figure 2 This is a flowchart of a computing resource allocation method provided in an exemplary embodiment.

[0019] Figure 3 This is a flowchart of a target business processing module determination scheme provided in an exemplary embodiment.

[0020] Figure 4 This is a schematic structural diagram of a device provided in an exemplary embodiment.

[0021] Figure 5 This is a structural block diagram of a computing resource allocation device provided in an exemplary embodiment. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0023] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with relevant laws, regulations and standards, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0024] With the rapid development of internet technology, cloud computing, and big data, online services have become an indispensable part of social production and daily life. The core of these services lies in providing a high-concurrency, high-availability, and low-latency access experience for massive numbers of users. However, due to the suddenness of online hot topics or the instantaneous explosive effect of marketing campaigns, online service systems often face the severe challenge of sudden traffic surges. These surges typically manifest as an exponential or even dozens of times increase in request volume within a very short period, far exceeding the system's normal load-bearing capacity.

[0025] To cope with peak traffic and ensure service stability, related technologies typically employ the following resource allocation strategies:

[0026] The first method is a static resource expansion solution:

[0027] The most traditional approach is to pre-configure sufficient hardware resources such as servers and network bandwidth. While this can alleviate traffic pressure to some extent, its drawbacks are also obvious: First, during off-peak hours, a large number of idle resources lead to high operating costs; second, for unexpected and explosive traffic surges, statically configured resources will still be exhausted instantly, resulting in service unavailability.

[0028] The second method is an automatic scaling solution based on thresholds:

[0029] To improve resource utilization and flexibility, automatic scaling based on monitoring metrics is commonly used. This approach monitors server performance metrics such as CPU utilization, memory usage, and network throughput in real time. When these metrics exceed preset thresholds, it automatically triggers scaling, adding new server instances. Conversely, when the load decreases, it automatically reduces the number of instances. While this approach is more dynamic and economical than the first approach, it still has the following inherent drawbacks when dealing with sudden traffic surges:

[0030] Response lag: From the moment the monitoring system detects that a metric has exceeded its limits, to the time it triggers a scaling decision, and then to the time when the new instance completes startup, application deployment, service registration, and actually begins to handle traffic, there is a significant delay (usually on the order of minutes). Therefore, this lag is fatal for rapidly changing traffic surges, often causing the system to crash due to overload before new resources become available.

[0031] Limited decision-making dimensions: Because this approach typically relies on general system performance metrics, it cannot understand business-level logic. For example, it cannot distinguish whether a processor-consuming request comes from core transaction business or non-core data analysis task, thus failing to perform differentiated and more intelligent resource scheduling.

[0032] The third approach is a load balancing and caching solution:

[0033] This solution distributes the load by distributing requests to multiple backend servers. While this improves the overall throughput of the system to some extent, load balancing itself cannot create new processing capacity when all backend servers are fully loaded, and its capacity is very limited in scenarios with sudden surges in traffic.

[0034] The fourth solution is to limit traffic and degrade services:

[0035] This solution addresses sudden traffic surges by limiting traffic (e.g., rejecting some requests) or degrading services (shutting down non-core functions while ensuring the availability of core functions). While it can prevent the entire system from crashing, it sacrifices user experience and business integrity, making it less than ideal resource allocation strategies.

[0036] In summary, when faced with sudden surges in traffic, the relevant technologies generally suffer from drawbacks such as slow response, lack of foresight, unintelligent resource utilization, and the inability to sacrifice user experience.

[0037] Based on this, in order to at least solve the technical problems of slow response and lack of foresight when facing traffic surges in related technologies, the computing resource allocation method provided in one or more embodiments of this specification periodically acquires a set of historical system request volumes formed by multiple system request volume values ​​collected at multiple sampling time points within a set historical period with the current time as the endpoint, and a set of historical business characteristics formed by the business characteristics of the business requests received by the system within the historical period, during the process of the service system processing business requests. Then, a pre-trained request volume prediction model is called to process the system's future request volume prediction results based on the system's historical request volume set and the historical business characteristic set. This enables the request volume prediction model to accurately predict the system's future request volume in the future period by combining the system business request volume and business request characteristics in the most recent historical period in each prediction cycle, thereby achieving advance prediction of traffic surges. Based on this, after predicting the future request volume of the system in each prediction cycle, the system further analyzes the future request volume of each business processing module in the service system based on the prediction results. Then, based on the future request volume of each business processing module, the system determines the target business processing module that needs to adjust computing resources and the resource allocation strategy for the target business processing module. This allows the system to specifically locate the target business processing module with a large load during the traffic peak before it arrives and allocate computing resources to the target business processing module in advance. This not only effectively avoids the overload of the target business processing module when the traffic peak arrives and effectively solves the problem of resource allocation lag, thereby improving the stability and high availability of the service system under extreme traffic impact, but also allows the system to allocate computing resources only to the target business processing module, which can reduce the computing load of resource allocation to a certain extent and improve the efficiency of resource allocation.

[0038] The following is an explanation of some technical terms used in this manual:

[0039] Service chaining is a network traffic processing mechanism that forces network data packets to be processed sequentially through a series of network service nodes in a predefined order. For example, in the business scenario of personal consumer loan approval, relevant personnel can assemble multiple business processing modules (such as anti-fraud processing modules and credit scoring processing modules) according to a predefined approval order, forming a business request processing flow instance. This business request processing flow instance can be understood as a service chain. Each business processing module can be considered an atomic service.

[0040] DSL (Domain-Specific Language): A programming language, markup language, or high-level language designed for a specific domain, problem, or workflow. It is used to declaratively describe the logical steps of a service chain, service dependencies, data mapping, and exception handling strategies without writing traditional code.

[0041] Federal governance refers to a data integration method that achieves secure collaborative computing of distributed and heterogeneous data sources by establishing unified access, cleansing, and standardization rules without moving the original data.

[0042] Let me first introduce an application scenario example of the computing resource allocation method provided in this manual:

[0043] Figure 1 This is a schematic diagram of the architecture of a service system provided in an exemplary embodiment. For example... Figure 1 As shown, the system may include a server 11, a network 12, and several electronic devices, such as a PC (Personal Computer) 13, a mobile phone 14, etc.

[0044] Server 11 can be a physical server containing an independent host, or it can be a virtual server hosted in a host cluster. During operation, server 11 can run server-side programs for a specific application to implement the relevant functions of that application. For example, when server 11 runs a business service program, it can function as a corresponding business service platform.

[0045] PC13 and mobile phone14 are just some of the types of electronic devices that users can use. In reality, users can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and one or more embodiments in this specification do not limit this. During operation, the electronic device can run a client-side program of an application to implement the relevant functions of that application. For example, when the electronic device runs a business service program, it can act as a client for that business service. The aforementioned business service client application can be launched and run on the electronic device. This client-side program can be a native application installed on the electronic device, or it can be a mini-program, quick app, or other similar form. Of course, when using web technologies such as HTML5 or similar, the relevant functions can be implemented through a page displayed by a browser. This browser can be a standalone browser application or a browser module embedded in some applications.

[0046] As for the network 12 that enables interaction between electronic devices such as PC13 and mobile phone 14 and server 11, communication can be achieved using either wired or wireless networks, depending on the communication methods supported by the respective electronic devices. This specification does not impose any restrictions on this. For example, PC13 can support both wired and wireless communication, so it can use either wired or wireless networks as needed. Mobile phone 14 typically only supports wireless communication, so it can use a wireless network for communication.

[0047] The computing resource allocation method provided in one or more embodiments of this specification can be applied to server 11 in the above-mentioned service system. To improve the flexibility of business experts in orchestrating service chains on demand according to business scenarios, during the service development phase of a business scenario, the business service application involved in the current business scenario can be divided into multiple atomic services. An atomic service can be considered a business processing module. It is understood that a server can be configured with multiple business processing modules, and each business processing module is implemented as an independent atomic service. Based on this, during the service chain orchestration process, business experts can assemble the corresponding business processing modules sequentially according to the processing flow of various types of business requests involved in the business scenario to form a service chain. After orchestrating each service chain, business experts can trigger a storage instruction to enable the server to store each service chain and the matching relationship between the service chain and the business request type. This allows the server to, in subsequent application phases, upon receiving a business request, call the service chain matching the current business request type from the stored matching relationship to process the current business request, output the corresponding processing result, and feed it back to the business requesting end that initiated the business request.

[0048] Taking the service system as an example of a credit reporting platform system, the following explains the process of handling business requests:

[0049] Credit reporting platforms typically provide services for credit business scenarios such as credit card approval, loan applications, and fraud investigations. Loan application scenarios can include, but are not limited to: personal consumer loans, corporate consumer loans, mortgage loans, auto loans, and small cash loans.

[0050] After a user submits a personal consumer loan application through a business request platform (such as a bank's mobile app), the credit reporting platform system will receive the user's loan application request. This loan application request may include, but is not limited to, the user's device information, the applicant's information, and the loan amount. The user's device information includes, but is not limited to, device ID, IP address, and operating system version; the applicant's information includes, but is not limited to, ID number, name, and occupation.

[0051] After receiving a loan request, the credit scoring platform system can use a scenario recognition engine to identify the loan scenario and output the loan scenario type. The recognition principle is detailed in relevant technical documents and will not be elaborated upon here.

[0052] After the credit scoring platform system learns the loan scenario type of the current loan application, it can retrieve the target service chain matching the loan scenario type from the pre-stored matching relationships by calling the service orchestration engine. In this example, the identified loan scenario type is a personal consumer loan scenario. Therefore, the target service chain is the service chain matching the personal consumer loan scenario. This target service chain can be: anti-fraud service → credit scoring service → report generation service, but is not limited to these.

[0053] After obtaining the target service chain, the service orchestration engine sequentially calls each business processing module to process the current loan request, according to the order recorded in the target service chain. In this example, the anti-fraud business processing module is called first to perform anti-fraud checks on the current loan request. The anti-fraud business processing module can obtain user profile data from the pre-stored data lake through federated governance, and perform anti-fraud analysis based on the user profile data, returning the anti-fraud results. The technical principles of the anti-fraud analysis can be found in related technologies and will not be detailed here.

[0054] After receiving the anti-fraud result, the service orchestration engine determines whether to continue calling the next business processing module based on the result. For example, if the anti-fraud result indicates that the current business request was triggered by fraudulent behavior, the target service chain can be stopped, and the processing result of rejecting the loan application and the reason for rejection can be fed back to the business request end. In addition, to improve the security of user accounts, warning messages can also be sent to other devices bound to the user or to relevant institutions to prevent others from stealing the user's account to apply for loans.

[0055] Conversely, if the anti-fraud result indicates that the current business request was not triggered by fraudulent behavior, the service orchestration engine calls the next business processing module after the anti-fraud business processing module—the credit assessment business processing module. The credit assessment business processing module can also obtain user credit characteristic data from the data lake through a federated governance approach, and combine this credit characteristic data with user profile data to perform credit assessment processing, returning a credit score. The technical principles behind obtaining the user's credit score through credit assessment processing can be found in related technologies and will not be detailed here.

[0056] After receiving the credit score, the service orchestration engine calls the next business processing module after the credit assessment business processing module—the report generation business processing module. The report generation business processing module can generate a complete credit report based on the anti-fraud results, credit score, and the current business request, and return it to the service orchestration engine. The principles behind credit report generation can be found in relevant technologies and will not be detailed here.

[0057] After receiving the credit report, the service orchestration engine can feed back the credit report or the allowed loan amount recorded in the credit report to the business requesting party, thereby completing the processing of the business request.

[0058] As described above, a service chain comprises multiple business processing modules called sequentially. During the execution of the service chain, if some information corresponding to a business request fails to pass the checks of a certain business processing module (such as anti-fraud checks), the continued execution of the service chain will be interrupted, resulting in different computational loads for different business processing modules. Furthermore, different types of business requests have different service chains. Different service chains may contain some identical or completely different business processing modules. Within the same service chain, the same business processing module may be called once or multiple times when handling a single business request, further leading to different computational loads for different modules. This difference in computational load is even more pronounced during sudden traffic surges (such as large-scale promotional events with a large number of business requests). Therefore, if all business processing modules are simultaneously expanded with additional resources, some modules will obviously have idle resources, wasting resources and potentially making it difficult for heavily loaded modules to cope with sudden traffic surges.

[0059] Therefore, to address the technical problems of slow response and lack of foresight when facing sudden traffic surges, and / or the waste of resources due to unreasonable resource allocation and the inability of some business processing modules to cope with sudden traffic surges, the above problems can be solved by executing the computing resource allocation method provided in one or more embodiments of this specification during the operation of the service system. Please refer to... Figure 2 , Figure 2 This is a flowchart of a computing resource allocation method provided in an exemplary embodiment, the method including the following steps:

[0060] In step S100, the system historical request volume set within a set historical period and the historical service feature set of service requests received within the historical period are periodically acquired; wherein, the end point of the historical period is the current time, and the system historical request volume set includes multiple system request volume values ​​collected at multiple sampling time points within the historical period.

[0061] In step S200, a pre-trained request volume prediction model is invoked to process the system's historical request volume set and the historical business feature set to obtain the system's future request volume prediction result.

[0062] In step S300, the future request volume of each business processing module is determined based on the system's future request volume prediction results, and the target business processing module that needs to have its computing resources adjusted and the resource allocation strategy of the target business processing module are determined based on the future request volume of each business processing module; the resource allocation strategy is used to adjust the processing capacity of the target business processing module.

[0063] Understandably, the server can execute the computing resource allocation method provided in one or more embodiments of this specification in parallel during the process of processing business requests, so as to realize the advance prediction of the future load (i.e. the future request volume) of each business processing module, and based on the advance prediction results, realize the advance determination of the resource allocation strategy for the target business processing module with a large future load, thereby ensuring that the server can respond to the surge in traffic in a timely and reliable manner, solve the problems of slow resource allocation response and lack of foresight, and improve the rationality of resource allocation.

[0064] First, step S100 is executed to periodically acquire system request volume data collected by the system monitoring module within a set historical period according to a set cycle, forming a system historical request volume set, and to acquire the historical business characteristics of the business requests received within the historical period, forming a historical business characteristic set.

[0065] In the above, the period can be set according to actual needs or experience, for example, 1 minute or 5 minutes, but is not limited to these. Within each period, the historical time period involved can be represented as [t-Δt, t], where Δt is the duration set according to actual needs or experience, for example, 10 minutes or 60 minutes, but is not limited to these; t is the current time, i.e., the time at the start of this period. Multiple sampling time points within the historical time period can be multiple time points divided according to a preset sampling interval, where the sampling interval can also be set according to actual needs or experience, for example, 1 minute, but is not limited to these. The set of historical system request volumes collected within a historical period is the system request volume collected at multiple sampling time points. The system request volume can be represented by the value of QPS (Queries Per Second). Based on this, assuming that there are 10 sampling time points obtained by dividing the historical period according to the sampling interval, and the system request volumes collected at these 10 sampling time points are QPS1~QPS10, then to ensure the accuracy of model prediction, QPS1~QPS10 can be arranged in the order of the sampling time points to form the set of historical system request volumes {QPS1, QPS2, QPS3, ..., QPS8, QPS9, QPS10}.

[0066] The historical business characteristic set can include the business characteristics of all business requests received by the system within the aforementioned historical period. These business characteristics include, but are not limited to, one or more of the following: the time period of the business activity corresponding to the business request, the activity identifier of the business activity corresponding to the business request, and the business request type. The time period of the business activity can include one or more of the initiation time and validity period of the business activity; the activity identifier of the business activity can include, but is not limited to: an activity identifier indicating that the business activity is a regular activity, an activity identifier indicating that the business activity is a promotional activity, an activity identifier indicating that the business activity is a discount activity, an activity identifier indicating that the business activity is a lottery activity, and an activity identifier indicating that the business activity is a discount activity; the identifier of the business activity corresponding to a business request is usually unique; the business request type is as described above and will not be repeated here.

[0067] In some embodiments, the time sequence of the business features recorded in the historical business feature set is consistent with the time sequence of the QPS values ​​recorded in the system historical request volume set. That is, the data recorded in each set is sorted in chronological order.

[0068] After obtaining the system's historical request volume set and historical business feature set, step S200 is executed: the system's historical request volume set and historical business feature set are input into the pre-trained request volume prediction model. After processing by the request volume prediction model, the system's future request volume prediction result is output. The system's future request volume prediction result includes at least one predicted system request volume value at a future time point.

[0069] In some embodiments, to better ensure the system maintains stability when facing sudden traffic surges, provide better support for resource allocation strategies with different response times, and avoid long-term idle waste of resources, the system's future request volume prediction results may include system QPS prediction values ​​at three different future time points. These three future time points may be, but are not limited to, 5 minutes, 10 minutes, and 15 minutes in the future. These future time points may be relative to the last time point in the aforementioned historical period (i.e., the current time t mentioned above). For example, assuming the current time t mentioned above is 10:00, then the time point corresponding to 5 minutes in the future is 10:05. The same applies to other future time points, which will not be elaborated here.

[0070] To ensure the model's prediction accuracy, in some embodiments, the request volume prediction model can be trained using an LSTM (Long Short-Term Memory) model based on a pre-built training sample set. The training sample set includes multiple training sample sequences arranged chronologically. Data in these training sample sequences can be obtained from system historical records. For example, when constructing a training sample set, the system QPS values ​​and business characteristics of all received business requests within a set time period can be obtained, starting from the current time when the training sample set is needed, to construct the training sample sequence. The set time period can be determined based on actual training needs or historical experience, such as one month or half a year, but is not limited to these. Each training sample sequence includes an input sample sequence and a sample label sequence. The input sample sequence includes a system QPS value sequence and a business characteristic sequence with a time length equal to the aforementioned historical time period. The data contained in the business characteristic sequence can be found in the description of the historical business characteristic set above, and will not be repeated here. The sample label sequence includes at least one future time point, where the future time point is relative to the time of the last system QPS value belonging to the same training sample sequence. Therefore, the LSTM model can be iteratively trained using the aforementioned training sample set until it converges, resulting in the requested volume prediction model. The model training principle can be found in related technical documents and will not be detailed here.

[0071] In some examples, if it is necessary to maintain the long-term stability of the system in the face of sudden traffic surges, the sample label sequence can include the measured system QPS values ​​at three different future time points.

[0072] After obtaining the system's future request volume prediction result, step S300 is executed to determine the future request volume of each business processing module based on the system's future request volume prediction result. In some examples, the system's future request volume prediction result can be decomposed according to the ratio between the historical request volume of each business processing module and the total historical request volume of the system to obtain the future request volume of each business processing module. This can improve the calculation efficiency of the future request volume of each business processing module and reduce the system's computational burden. Based on this, the step of determining the future request volume of each business processing module based on the system's future request volume prediction result may include:

[0073] In step S301, the ratio of the historical request volume of each business processing module to the total historical request volume of the system is calculated to obtain the request volume ratio of each business processing module.

[0074] In step S302, the product of the request volume ratio of each business processing module and the future request volume prediction result of the system is calculated to obtain the future request volume of each business processing module.

[0075] The following uses the example of a future QPS value for the system's future request volume prediction to illustrate the technical principles of steps S301 to S302 above:

[0076] Assuming the system's future QPS is 1000, there are three business processing modules with historical request volumes of 300, 400, and 1300 respectively, and a total historical request volume of 2000. The historical request volume of each business processing module can be obtained by accumulating request data over a predetermined time period ending at the current calculation time. In essence, the historical request volume of each business processing module represents the total number of requests it received within that predetermined time period, or the total number of requests invoked by the system. This predetermined time period can be configured based on actual needs or experience; for example, it could be one year, six months, or one month, but is not limited to these.

[0077] Based on this, when it is necessary to determine the future request volume of each business processing module, we can first count the historical request volume of each business processing module and the total historical request volume of the system. Then, we can execute step S301 to calculate the ratio of the historical request volume of each business processing module to the total historical request volume of the system, and obtain the request volume ratio of each business processing module. As shown in the example above, the request volume ratios of each business processing module obtained after executing step S301 are: 0.15 (the value of 300 / 2000), 0.2 (the value of 400 / 2000), and 0.65 (the value of 1300 / 2000). Subsequently, step S302 is executed to calculate the product of the request volume percentage of each business processing module and the system's future request volume prediction result, thus obtaining the future request volume of each business processing module. Continuing with the above example, the future request volumes (i.e., future QPS) of each business processing module obtained after executing step S302 are: 150 (a value of 0.15 × 1000), 200 (a value of 0.2 × 1000), and 650 (a value of 0.65 × 1000). Therefore, the future request volume of each business processing module can be calculated based on the system's future request volume prediction result. If the system's future request volume prediction result includes multiple system future QPS values, the future request volume of each business processing module at different future time points can be calculated using the above calculation principle, which will not be elaborated here.

[0078] After obtaining the future request volume of each business processing module, step S300 is executed to further determine the target business processing module that needs to have its computing resources adjusted based on the future request volume of each module. In some examples, the future request volume of each business processing module can be compared with a set request volume threshold, and then the business processing module whose future request volume is greater than the request volume threshold is selected as the target business processing module. The request volume threshold can be set based on the processing performance of each business processing module or experience. The principle of setting it based on processing performance can be found in relevant technologies, which will not be detailed here.

[0079] Because the above-mentioned scheme for determining the target business processing module only considers the future request volume of the business processing module, it may lead to the omission of business processing modules that also need resource adjustments. In reality, the processing load on a business processing module is not only affected by the future request volume, but may also be affected by system factors or other factors. Therefore, to improve the accuracy of determining the target business processing module, avoid omitting business processing modules that should have resource adjustments, and thus improve the reliability and stability of the service system in response to sudden traffic surges, in some embodiments, the computing resource allocation method provided in one or more embodiments of this specification also provides another scheme for determining the target business processing module. Please refer to [link to relevant documentation]. Figure 3 , Figure 3This is a flowchart of a target service processing module determination scheme provided in an exemplary embodiment. In step S300 above, the step of determining the target service processing module requiring computing resource adjustment based on the future request volume of each service processing module includes:

[0080] In step S311, the ratio of the future request volume of each service processing module to the set maximum system processing volume is calculated to obtain the future load pressure coefficient of each service processing module.

[0081] In step S312, the decision routing weight of each business processing module is calculated based on the future load pressure coefficient, priority coefficient, and current resource utilization of each business processing module.

[0082] In step S313, the service processing module whose decision routing weight is greater than the set routing threshold is determined as the target service processing module.

[0083] The following explanation uses the determination of whether a business processing module is the target business processing module as an example to illustrate the technical principles of steps S311 to S313 above:

[0084] First, execute step S311 to calculate the ratio of the future request volume of the business processing module to the maximum processing volume of the system, and obtain the future load pressure coefficient of the business processing module. The maximum processing volume of the system is the maximum theoretical processing capacity of the computing cluster where the business processing module is located. It can be calculated in advance based on the performance parameters of the computing cluster or other relevant parameters through relevant technologies, which will not be described in detail here.

[0085] In the above, the future load pressure coefficient can characterize the degree of impact of future load on the computing cluster where the business processing module is located. If the future load pressure coefficient is close to or greater than 1, it indicates that the future load may reach or exceed the limit of the computing cluster. Conversely, if the future load pressure coefficient is much less than 1, it indicates that the computing cluster still has sufficient redundancy processing capacity.

[0086] Step S311 enables subsequent resource allocation strategies to consider the comparison between future load and system limits. Combined with subsequent steps, this can proactively prevent performance bottlenecks, rather than simply responding to real-time pressure changes that have already occurred.

[0087] Next, step S312 is executed to calculate the decision routing weight of the business processing module based on its future load pressure coefficient, priority coefficient, and current resource utilization. In some examples, the sum or product of the future load pressure coefficient, priority coefficient, and current resource utilization can be used as the decision routing weight of the business processing module. In other examples, to improve the rationality of the decision routing weight and thus the rationality of subsequent resource allocation, corresponding weights can be configured based on the degree of influence of the future load pressure coefficient, priority coefficient, and current resource utilization on the system's computational burden. Then, the weighted sum of the future load pressure coefficient, priority coefficient, and current resource utilization is calculated to obtain the decision routing weight of the business processing module. As an example of weight values, the weight of the future load pressure coefficient can be 0.3, the weight of the priority coefficient can be 0.6, and the weight of the current resource utilization can be 0.1. The priority coefficient is used to characterize the priority of the services provided by the business processing module. Different services may have the same or different priority coefficients, as some services may have the same priority while others may have different priorities. The priority of a service can be determined based on its importance, real-time requirements, and resource consumption. For example, in a credit scenario, services that play the most critical role in determining the approval of a loan application, such as anti-fraud services and credit scoring services, can be given high priority. Similarly, services that require immediate results to advance the process, such as identity verification services, can also be given high priority. Furthermore, services with high resource consumption, typically requiring computationally intensive or input / output intensive data, or those with long processing times, can also be given high priority. Other services besides the high-priority services can be assigned a standard priority, but are not limited to this. Based on this, in some examples, the priority coefficient of a high-priority business processing module can be set to 0.7, and the priority coefficient of a standard-priority business processing module can be set to 0.3, but is not limited to this.

[0088] After obtaining the decision routing weight of the business processing module, step S313 is executed, comparing the decision routing weight of the business module with the set routing threshold. If the decision routing weight of the business processing module is greater than the routing threshold, the business processing module is determined as the target business processing module; otherwise, if the decision routing weight of the business processing module is less than or equal to the routing threshold, no resource adjustment is required for the business processing module. However, in this case, to avoid resource waste, in some embodiments, resource adjustment can be performed for the purpose of scaling down. For example, the decision routing weight can be compared with a scaling down routing threshold that is less than the aforementioned routing threshold. If the decision routing weight is less than or equal to the scaling down routing threshold, the corresponding business processing module can be used as a scaling down business processing module, and the operation of reducing the number of instances of the business processing module can be performed, or the business processing module can be routed from its current cluster to a lower-performance cluster. If the decision routing weight is greater than the scaling down routing threshold and less than or equal to the routing threshold, the original state can be maintained, for example, no scaling down processing or routing cluster adjustment processing is performed. The thresholds involved can be set based on experience or experiments, and will not be detailed here.

[0089] After identifying the target business processing module from among the various business processing modules, step S300 is executed to obtain the resource allocation strategy for the target business processing module. In some examples, the resource allocation strategy for all target business processing modules can be determined to immediately perform a scaling operation or route them to a high-performance cluster with higher performance than the original cluster. This unified allocation strategy can improve resource allocation efficiency, but it may lead to unnecessary resource waste because the future load of different target business processing modules may vary. If the same allocation strategy is used for all of them, the computing resources of the target business processing modules with larger loads may not be increased enough, while the target business processing modules with smaller loads may have wasted resources.

[0090] Based on this, in order to achieve a more reasonable allocation of resources to the target business processing module and better improve the reliability and stability of the target business processing module in the face of future traffic surges, in some embodiments, the computing resource allocation method provided in one or more embodiments of this specification also provides a scheme for determining at least one of the following resource allocation strategies:

[0091] The first strategy is immediate expansion:

[0092] The immediate scaling strategy represents the immediate scaling up of the number of instances of the target business processing module to the first target number of instances. Based on this, the process of determining the resource allocation strategy for the target business processing module includes:

[0093] In step S321, if the decision routing weight of the target service processing module is greater than the set high load threshold, the resource allocation strategy of the target service processing module is determined to be an immediate expansion strategy.

[0094] The second approach is a pre-emptive expansion strategy:

[0095] The pre-expansion strategy represents expanding the number of instances of the target business processing module to the second target number after setting a future time period. The future time period can be set according to actual needs, but it cannot exceed the future time point corresponding to the system's future request volume prediction result, and the expansion operation must be completed before that future time point.

[0096] Based on this, the process of determining the resource allocation strategy for the target business processing module includes:

[0097] In step S322, if the decision routing weight of the target service processing module is greater than the set early warning threshold and less than or equal to the set high load threshold, the resource allocation strategy of the target service processing module is determined to be a pre-expansion strategy.

[0098] The third method is a routing optimization strategy:

[0099] The routing optimization strategy represents routing the target service processing module to the system's target cluster, where the processing performance of the target cluster is higher than that of the original cluster where the target service processing module resides. Based on this, the process of determining the resource allocation strategy for the target service processing module includes:

[0100] In step S323, if the decision routing weight of the target service processing module is greater than the set routing threshold and less than or equal to the set warning threshold, the resource allocation strategy of the target service processing module is determined to be a routing optimization strategy.

[0101] Understandably, after obtaining the target business processing module and its decision routing weight, we can first analyze which of the following numerical ranges the decision routing weight falls into: (high load threshold, +∞), (early warning threshold, high load threshold), (routing threshold, early warning threshold).

[0102] If the analysis results indicate that the decision routing weight falls within the numerical range (high load threshold, +∞), meaning the decision routing weight is greater than the high load threshold, then the resource allocation strategy for the corresponding target business processing module adopts an immediate scaling strategy, immediately expanding the number of instances of the target business processing module to the first target number of instances. The principle behind this instance expansion can be found in relevant technologies and will not be detailed here. The first target number of instances can be a value that is a multiple larger than the current number of instances of the target business processing module, for example, 1 time, 1.5 times, or 3 times larger, but is not limited to these.

[0103] While the above-mentioned instance number determination scheme can simplify the instance expansion process and, to a certain extent, ensure the stability of the target business processing module in dealing with sudden traffic surges, there may still be situations of insufficient or wasted resources. Therefore, to better improve the stability and reliability of the target business processing module in dealing with sudden traffic surges, in some embodiments, the computing resource allocation method provided by one or more embodiments of this specification also provides another scheme for calculating the first target instance number, that is, the calculation process of the first target instance number includes:

[0104] In step S321-1, the maximum request processing capacity of a single instance of the target business processing module that matches the future request volume of the target business processing module is obtained from the pre-stored instance processing capacity table.

[0105] In step S321-2, the first target instance number of the target business processing module is calculated based on the maximum request processing volume of a single instance of the target business processing module and the future request volume of the target business processing module.

[0106] Understandably, if the resource allocation strategy for the target business processing module is determined to be an immediate expansion strategy, steps S321-1 to S321-2 are executed to obtain the first target number of instances.

[0107] During step S321-1, the instance processing capacity table is invoked, and the maximum computing capacity of a single instance of the target business processing module—the maximum request processing capacity—is retrieved from the table based on the future request volume of the target business processing module. The instance processing capacity table records the maximum request processing capacity that a single instance of each business processing module can handle under different request volume ranges. These different request volume ranges and maximum request volumes can be obtained through testing. For example, for each business processing module, business requests of different load levels can be sent to a single instance of the business processing module in batches. Different load levels can refer to different total number of requests initiated at once, such as 10, 100, or 1000 requests, but are not limited to these. Then, the system waits for the single instance to process all business requests under the current load level. If the waiting time exceeds the set response time, it indicates that the single instance may be overloaded, and further waiting is unnecessary. Within each load tier, for each completed business request by a single instance, target business requests with response times less than a set response time threshold can be identified. The number of these target business requests is then counted, and this number represents the maximum request processing capacity that a single instance of the business processing module can handle within the current load tier. This allows us to obtain the maximum request processing capacity of a single instance in different business processing modules across different load tiers (i.e., the different request volume ranges mentioned above), and record the matching relationships to form the instance processing capacity table. The response time threshold can be set based on actual needs or experience; for example, it could be set to 50ms, but is not limited to this.

[0108] Therefore, by using an instance processing capacity table to obtain the maximum request processing capacity of a single instance of the target business processing module under the predicted future request volume, the processing capacity of a single instance of the target business processing module can be more accurately reflected. This is because the processing capacity of a single instance is not fixed under different load levels, which can further improve the accuracy of the subsequent first target instance count, and thus better improve the reliability and stability of the target business processing module in dealing with sudden traffic surges.

[0109] After obtaining the maximum request processing capacity of a single instance of the target business processing module, step S321-2 is executed. Based on the maximum request processing capacity of a single instance of the target business processing module and the future request volume of the target business processing module, the first target instance number of the target business processing module is calculated. In some examples, the first target instance number can be calculated using the instance number calculation principle of related technologies, that is, first target instance number = ceil(future request volume / maximum request volume), where ceil() is the ceiling function used to round up. For example, when the value of future request volume / maximum request volume is 90.5, the first target instance number is 91.

[0110] Since the future request volume may have certain prediction errors, or the actual future request volume may be affected by future instantaneous traffic fluctuations, in order to cope with prediction errors and instantaneous traffic fluctuations and further ensure the reliability and stability of the business processing module and service system, in some embodiments, the computing resource allocation method provided by one or more embodiments of this specification also provides another calculation scheme for the first target instance number. That is, in the above step S321-2, calculating the first target instance number of the target business processing module based on the maximum request processing volume of a single instance of the target business processing module and the future request volume of the target business processing module may include:

[0111] In steps S321-21, the ratio of the future request volume of the target business processing module to the maximum request processing volume of a single instance of the target business processing module is calculated to obtain the basic number of instances of the target business processing module;

[0112] In steps S321-22, the product of the basic number of instances and the set redundancy coefficient is rounded up to obtain the first target number of instances of the target service processing module, wherein the redundancy coefficient is greater than 1.

[0113] Understandably, the first target number of instances with redundancy can be calculated through steps S321-21 to S321-22. The calculation principle of step S321-21 can be found in the relevant description above and will not be repeated here. After obtaining the basic number of instances through step S321-21, step S321-22 is executed to round up the product of the basic number of instances and the redundancy coefficient to obtain the first target number of instances for the target business processing module. Therefore, the first target number of instances will have a certain margin, enabling the business processing module to cope with prediction errors and instantaneous traffic fluctuations. The redundancy coefficient can be set according to actual needs or experience; for example, it can be set to 1.5, but it is not limited to this.

[0114] Once the first target number of instances is obtained, an immediate scaling strategy can be executed to increase the number of instances of the target business processing module by the first target number of instances.

[0115] If the analysis results indicate that the decision routing weight falls within the numerical range (warning threshold, high load threshold), that is, the decision routing weight is greater than the warning threshold and less than or equal to the high load threshold, then the resource allocation strategy for the corresponding target business processing module adopts the pre-expansion strategy, and the number of instances of the target business processing module will be expanded to the second target number of instances after a future time period is set.

[0116] The second target number of instances can be a value that is a multiple greater than the current number of instances of the target business processing module. The second target number of instances can be less than the first target number of instances, or greater than or equal to the first target number of instances. However, since the preparatory scaling strategy is adopted because the predicted future load has not yet reached the level that requires the immediate scaling strategy, in order to avoid resource waste, in some examples, the second target number of instances is less than the first target number of instances.

[0117] While the above-described instance number determination scheme can simplify the instance expansion process and, to some extent, ensure the stability of the target business processing module in handling sudden traffic surges, there may still be situations of insufficient or wasted resources. Therefore, to better improve the stability and reliability of the target business processing module in handling sudden traffic surges, in some embodiments, the computing resource allocation method provided in one or more embodiments of this specification also provides another scheme for calculating the second target instance number, that is, the calculation process of the second target instance number includes:

[0118] In step S322-1, the maximum request processing capacity of a single instance of the target business processing module that matches the future request volume of the target business processing module is obtained from the pre-stored instance processing capacity table.

[0119] In step S322-2, the future request increment of the target service processing module is calculated based on the future request volume of the target service processing module and the current request volume of the target service processing module;

[0120] In step S322-3, the second target number of the target business processing module is obtained based on the future request increment of the target business processing module, the set reserve ratio, and the maximum request processing volume of a single instance of the target business processing module.

[0121] Understandably, if the resource allocation strategy of the target business processing module is determined to be a pre-expansion strategy, steps S322-1 to S322-3 are executed to obtain the second target number of instances.

[0122] During step S322-1, the instance processing capacity table is invoked, and the maximum computing capacity of a single instance of the target business processing module—the maximum request processing capacity—is retrieved from the table based on the future request volume of the target business processing module. The instance processing capacity table is as described above and will not be repeated here.

[0123] After obtaining the maximum request processing capacity of a single instance of the target business processing module, execute step S322-2 to calculate the difference between the future request capacity of the target business processing module and the current request capacity of the target business processing module, and obtain the future request increment of the target business processing module.

[0124] Next, step S322-3 is executed. Based on the future request increment of the target business processing module, the set reserve ratio, and the maximum request processing capacity of a single instance of the target business processing module, the second target number of instances of the target business processing module is calculated. In some examples, the product of the future request increment and the reserve ratio of the target business processing module can be calculated, and the ratio of the product to the maximum request processing capacity of a single instance of the target business processing module can be rounded up to obtain the reserve number of instances. Then, the reserve number of instances is added to the current number of instances of the target business processing module to obtain the second target number of instances of the target business processing module.

[0125] In the above, the reserve ratio can be set according to experience or actual needs. For example, it can be set to 0.6, but it is not limited to this. This means that 60% of the expected increase in instances can be prepared in advance.

[0126] However, since the pre-expansion strategy is essentially a resource reservation strategy, it can be understood as informing the system in advance when and how many instances the target business processing module will need, so that the system can prepare relevant resources in advance for the expansion of the target business. To fulfill this promise, although the system will reserve relevant resources for the target business processing module, it cannot reserve resources for a certain target business processing module indefinitely, as this may lead to resource waste or inability to serve other business requests. Therefore, it is necessary to configure an upper limit for resource reservation to ensure the stable operation of the system. Based on this, in some embodiments, the computing resource allocation method provided in one or more embodiments of this specification also provides another scheme for calculating the second target instance number, that is, the step in step S322-3 above, which calculates the second target instance number of the target business processing module based on the future request increment of the target business processing module, the set reserve ratio, and the maximum request processing capacity of a single instance of the target business processing module, includes:

[0127] In steps S322-31, the product of the future request increment of the target service processing module and the reserve ratio is calculated, and the ratio of the product to the maximum request processing volume of a single instance of the target service processing module is rounded up to obtain the number of reserve instances of the target service processing module.

[0128] In steps S322-32, the smaller of the number of prepared instances and the maximum number of prepared instances is calculated and summed with the current number of instances of the target service processing module to obtain the second target number of instances of the target service processing module.

[0129] Understandably, the second target number of instances, which does not exceed the system resource reservation limit, can be calculated through steps S322-31 to S322-32. The calculation principle of step S322-31 can be found in the relevant description above and will not be repeated here. After obtaining the reserve instance number through step S322-31, step S322-32 is executed. The smaller value between the reserve instance number and the maximum reserve instance number is obtained, and then this value is summed with the current instance number of the target business processing module to obtain the second target instance number. The maximum reserve instance number can be configured based on experience or actual needs, or it can be pre-obtained based on the maximum number of instances the system can provide for each business processing module. The principle behind this acquisition can be found in relevant technologies and will not be repeated here.

[0130] After obtaining the second target number of instances, the number of instances of the target business processing module can be increased to the second target number of instances when the time for executing the preparatory expansion strategy arrives.

[0131] If the analysis results indicate that the decision routing weight falls within the numerical range (routing threshold, warning threshold), i.e., the decision routing weight is greater than the routing threshold and less than or equal to the warning threshold, then the resource allocation strategy for the corresponding target business processing module adopts a routing optimization strategy. This route the target business processing module to the system's target cluster, whose processing performance is higher than the original cluster where the target business processing module resides. The timing for executing the routing optimization strategy can be the current moment or any point in time before the future time corresponding to the system's future request volume prediction arrives, ensuring the routing optimization strategy is completed.

[0132] Figure 4 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 4 As shown, device 400 mainly consists of a communication interface 402, a user interface 404, a processor 406, and a data storage 408. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 410. The communication interface 402 enables device 400 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 402 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 402 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 402 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 402 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0133] User interface 404 includes receiving user input and providing output to the user. Therefore, user interface 404 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 404 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 404 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 400 may support remote access from other devices via communication interface 402 or another physical interface (not shown). User interface 404 may be configured to receive user input, the position and movement of which may be indicated by an indicator or cursor described herein. User interface 404 may also be configured as a display device for rendering or displaying text fragments.

[0134] Processor 406 may contain one or more general-purpose processors and / or special-purpose processors.

[0135] Data storage 408 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 406. Data storage 408 may include removable and non-removable components.

[0136] Processor 406 is capable of executing program instructions 418 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 408 to perform the various functions described herein. Data storage 408 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 400, enable device 400 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 406 executing program instructions 418 may result in processor 406 using data 412.

[0137] For example, program instructions 418 may include an operating system 422 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 400 and one or more applications 420 (e.g., a browser, social application, or game application). Similarly, data 412 may include operating system data 416 and application data 414. Operating system data 416 is primarily accessible to the operating system 422, while application data 414 is primarily accessible to one or more applications 420. Application data 414 may reside in a file system visible or hidden from the user of device 400.

[0138] Application 420 can communicate with operating system 422 through one or more application programming interfaces (APIs). These APIs help application 420 read and / or write application data 414, transmit or receive information via communication interface 402, receive or display information on user interface 404, etc.

[0139] In some terminology, application 420 may be simply referred to as "app". Furthermore, application 420 can be downloaded to device 400 through one or more online app stores or app markets. However, applications can also be installed on device 400 in other ways, such as through a web browser or a physical interface on device 400 (e.g., a USB port).

[0140] Please refer to Figure 5 , Figure 5 This is a structural block diagram of a computing resource allocation device provided in an exemplary embodiment. The computing resource allocation device can be applied to, for example... Figure 4 The device shown implements the technical solution of this specification. The computing resource allocation device 500 may include:

[0141] The acquisition module 510 is configured to periodically acquire a set of historical system request volumes within a set historical period, and a set of historical service characteristics of service requests received within the historical period; wherein the end point of the historical period is the current time, and the set of historical system request volumes includes multiple system request volume values ​​collected at multiple sampling time points within the historical period.

[0142] Prediction module 520 is configured to: call a pre-trained request volume prediction model to process the system's historical request volume set and the historical business feature set to obtain the system's future request volume prediction result;

[0143] The resource allocation module 530 is configured to: determine the future request volume of each business processing module based on the future request volume prediction results of the system, and determine the target business processing module that needs to have its computing resources adjusted, as well as the resource allocation strategy of the target business processing module, based on the future request volume of each business processing module; the resource allocation strategy is used to adjust the processing capacity of the target business processing module.

[0144] In some embodiments, the process by which the resource allocation module 530 determines the future request volume of each service processing module based on the system's future request volume prediction results is configured to include:

[0145] Calculate the ratio of the historical request volume of each business processing module to the total historical request volume of the system to obtain the request volume proportion of each business processing module;

[0146] The future request volume of each business processing module is obtained by multiplying the request volume percentage of each business processing module with the predicted future request volume of the system.

[0147] In some embodiments, the process by which the resource allocation module 530 determines the target business processing module that needs to have its computing resources adjusted based on the future request volume of each business processing module is configured to include:

[0148] Calculate the ratio of the future request volume of each business processing module to the set maximum system processing volume to obtain the future load pressure coefficient of each business processing module;

[0149] Calculate the decision routing weight of each business processing module based on the future load pressure coefficient, priority coefficient, and current resource utilization of each business processing module.

[0150] The service processing module whose decision routing weight is greater than the set routing threshold is identified as the target service processing module.

[0151] In some embodiments, the process by which the resource allocation module 530 determines the resource allocation strategy for the target service processing module is configured to include at least one of the following methods:

[0152] The first approach is to determine the resource allocation strategy for the target business processing module as an immediate expansion strategy when the decision routing weight of the target business processing module is greater than the set high load threshold. The immediate expansion strategy means that the number of instances of the target business processing module is immediately expanded to the first target number of instances.

[0153] The second approach is to determine the resource allocation strategy of the target business processing module as a pre-expansion strategy when the decision routing weight of the target business processing module is greater than the set early warning threshold and less than or equal to the set high load threshold. The pre-expansion strategy indicates that the number of instances of the target business processing module will be expanded to the second target number of instances after a set future time period.

[0154] The third approach: When the decision routing weight of the target service processing module is greater than the set routing threshold and less than or equal to the set warning threshold, the resource allocation strategy of the target service processing module is determined to be a routing optimization strategy. The routing optimization strategy indicates that the target service processing module is routed to the target cluster of the system, and the processing performance of the target cluster is higher than that of the original cluster where the target service processing module is located.

[0155] In some embodiments, the process by which the resource allocation module 530 calculates the first target number of instances is configured to include:

[0156] From the pre-stored instance processing capacity table, obtain the maximum request processing capacity of a single instance of the target business processing module that matches the future request volume of the target business processing module;

[0157] The first target number of instances of the target business processing module is calculated based on the maximum request processing volume of a single instance of the target business processing module and the future request volume of the target business processing module.

[0158] In some embodiments, the process by which the resource allocation module 530 calculates the first target number of instances of the target business processing module based on the maximum request processing volume of a single instance of the target business processing module and the future request volume of the target business processing module is configured to include:

[0159] Calculate the ratio of the future request volume of the target business processing module to the maximum request processing volume of a single instance of the target business processing module to obtain the basic number of instances of the target business processing module;

[0160] The product of the basic number of instances and the set redundancy coefficient is rounded up to obtain the first target number of instances of the target business processing module; wherein the redundancy coefficient is greater than 1.

[0161] In some embodiments, the process by which the resource allocation module 530 calculates the second target number of instances is configured to include:

[0162] From the pre-stored instance processing capacity table, obtain the maximum request processing capacity of a single instance of the target business processing module that matches the future request volume of the target business processing module;

[0163] Calculate the future request increment of the target business processing module based on the future request volume of the target business processing module and the current request volume of the target business processing module;

[0164] The second target number of instances of the target business processing module is obtained based on the future request increment of the target business processing module, the set reserve ratio, and the maximum request processing capacity of a single instance of the target business processing module.

[0165] In some embodiments, the process by which the resource allocation module 530 obtains the second target number of instances of the target business processing module based on the future request increment of the target business processing module, a set reserve ratio, and the maximum request processing capacity of a single instance of the target business processing module is configured to include:

[0166] Calculate the product of the future request increment of the target business processing module and the reserve ratio, and round up the ratio of the product to the maximum request processing volume of a single instance of the target business processing module to obtain the number of reserve instances of the target business processing module.

[0167] The smaller of the number of prepared instances and the maximum number of prepared instances is calculated and summed with the current number of instances of the target business processing module to obtain the second target number of instances of the target business processing module.

[0168] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0169] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0170] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0171] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0172] What those skilled in the art will understand is:

[0173] In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0174] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0175] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0176] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0177] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0178] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0179] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A method for allocating computing resources, applied to a service system, the service system being configured with multiple business processing modules for processing business requests, including: The system periodically acquires a set of historical request volumes within a set historical period, as well as a set of historical service characteristics of service requests received within the historical period; wherein the end point of the historical period is the current time, and the set of historical request volumes includes multiple system request volume values ​​collected at multiple sampling time points within the historical period. The pre-trained request volume prediction model is invoked to process the historical request volume set and the historical business feature set of the system to obtain the future request volume prediction result of the system. Based on the system's future request volume prediction results, the future request volume of each business processing module is determined, and based on the future request volume of each business processing module, the target business processing module that requires computing resource adjustment and the resource allocation strategy of the target business processing module are determined; the resource allocation strategy is used to adjust the processing capacity of the target business processing module. The step of determining the future request volume of each business processing module based on the system's future request volume prediction results includes: calculating the ratio of the historical request volume of each business processing module to the total historical request volume of the system to obtain the request volume percentage of each business processing module; and calculating the product of the request volume percentage of each business processing module and the system's future request volume prediction results to obtain the future request volume of each business processing module.

2. The method according to claim 1, wherein the step of determining the target business processing module requiring computing resource adjustment based on the future request volume of each business processing module includes: Calculate the ratio of the future request volume of each business processing module to the set maximum system processing volume to obtain the future load pressure coefficient of each business processing module; Calculate the decision routing weight of each business processing module based on the future load pressure coefficient, priority coefficient, and current resource utilization of each business processing module. The service processing module whose decision routing weight is greater than the set routing threshold is identified as the target service processing module.

3. The method according to claim 2, wherein the process of determining the resource allocation strategy of the target business processing module includes: If the decision routing weight of the target business processing module is greater than the set high load threshold, the resource allocation strategy of the target business processing module is determined to be an immediate expansion strategy. The immediate expansion strategy means that the number of instances of the target business processing module is immediately expanded to the first target number of instances.

4. The method according to claim 2, wherein the process of determining the resource allocation strategy of the target business processing module includes: If the decision routing weight of the target service processing module is greater than the set early warning threshold and less than or equal to the set high load threshold, the resource allocation strategy of the target service processing module is determined to be a pre-expansion strategy. The pre-expansion strategy indicates that the number of instances of the target service processing module will be expanded to a second target number of instances after a set future time period.

5. The method according to any one of claims 1 to 4, wherein the process of determining the resource allocation strategy of the target business processing module includes: If the decision routing weight of the target service processing module is greater than the set routing threshold and less than or equal to the set warning threshold, the resource allocation strategy of the target service processing module is determined to be a routing optimization strategy. The routing optimization strategy indicates that the target service processing module is routed to the target cluster of the system, and the processing performance of the target cluster is higher than that of the original cluster where the target service processing module is located.

6. The method according to claim 3, wherein the calculation process of the first target number of instances includes: From the pre-stored instance processing capacity table, obtain the maximum request processing capacity of a single instance of the target business processing module that matches the future request volume of the target business processing module; The first target number of instances of the target business processing module is calculated based on the maximum request processing volume of a single instance of the target business processing module and the future request volume of the target business processing module.

7. The method according to claim 6, characterized in that, The step of calculating the first target number of instances of the target business processing module based on the maximum request processing volume of a single instance of the target business processing module and the future request volume of the target business processing module includes: Calculate the ratio of the future request volume of the target business processing module to the maximum request processing volume of a single instance of the target business processing module to obtain the basic number of instances of the target business processing module; The product of the basic number of instances and the set redundancy coefficient is rounded up to obtain the first target number of instances of the target business processing module; wherein the redundancy coefficient is greater than 1.

8. The method according to claim 4, wherein the calculation process of the second target number of instances includes: From the pre-stored instance processing capacity table, obtain the maximum request processing capacity of a single instance of the target business processing module that matches the future request volume of the target business processing module; Calculate the future request increment of the target business processing module based on the future request volume of the target business processing module and the current request volume of the target business processing module; The second target number of instances of the target business processing module is obtained based on the future request increment of the target business processing module, the set reserve ratio, and the maximum request processing capacity of a single instance of the target business processing module.

9. The method according to claim 8, characterized in that, The step of obtaining the second target number of instances of the target business processing module based on the future request increment of the target business processing module, the set reserve ratio, and the maximum request processing capacity of a single instance of the target business processing module includes: Calculate the product of the future request increment of the target business processing module and the reserve ratio, and round up the ratio of the product to the maximum request processing volume of a single instance of the target business processing module to obtain the number of reserve instances of the target business processing module. The smaller of the number of prepared instances and the maximum number of prepared instances is calculated and summed with the current number of instances of the target business processing module to obtain the second target number of instances of the target business processing module.

10. A computing resource allocation device, applied to a service system, the service system being configured with multiple business processing modules for processing business requests, comprising: The acquisition module is configured to periodically acquire a set of historical system request volumes within a set historical period, and a set of historical service characteristics of service requests received within the historical period; wherein the end point of the historical period is the current time, and the set of historical system request volumes includes multiple system request volume values ​​collected at multiple sampling time points within the historical period. The prediction module is configured to: call a pre-trained request volume prediction model to process the system's historical request volume set and the historical business feature set to obtain the system's future request volume prediction result; The resource allocation module is configured to: determine the future request volume of each business processing module based on the system's future request volume prediction results, and determine the target business processing module requiring computing resource adjustment and the resource allocation strategy for the target business processing module based on the future request volume of each business processing module; the resource allocation strategy is used to adjust the processing capacity of the target business processing module; determining the future request volume of each business processing module based on the system's future request volume prediction results includes: calculating the ratio of the historical request volume of each business processing module to the total historical request volume of the system to obtain the request volume percentage of each business processing module; and calculating the product of the request volume percentage of each business processing module and the system's future request volume prediction results to obtain the future request volume of each business processing module.

11. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1 to 9 by executing the executable instructions.

12. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 9.

Images