Bank cloud application resource allocation method and device

Abstract

The application discloses a bank cloud application resource allocation method and device, wherein the method comprises the following steps: collecting resource consumption data, business flow and calling chain data, expansion and contraction event data and user operation behavior data of each branch company on a bank cloud application system; calculating a first index, a second index and a third index of each branch company on each cloud application system respectively; determining a weight coefficient according to a pre-established weight determination model, and generating a resource allocation coefficient of each branch company on the bank cloud application system according to the weight coefficient and the corresponding index; identifying a use intention type of each branch company on the bank cloud application system through a machine learning model based on the user operation behavior data; and determining a resource allocation amount based on the resource allocation coefficient and the use intention type. The application can provide a more accurate and flexible resource allocation solution for a bank.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method and apparatus for allocating resources in bank cloud applications. Background Technology

[0002] As banks increasingly adopt cloud systems to provide services to their subsidiaries, the key challenge in ensuring the overall system performance and stability is how to efficiently and rationally allocate limited cloud resources among the subsidiaries.

[0003] Common practices include allocating resources directly based on resource consumption (such as CPU and memory), using fixed amounts or percentages, or calculating based on a single business metric, such as the number of transactions. However, these methods often deviate from actual business scenarios, failing to differentiate the actual value and resource utilization efficiency of different businesses, and are ill-suited to the changing characteristics of cloud environments and businesses. Furthermore, due to the lack of identification of the purpose and intent of subsidiary systems, resource allocation results often lack specific justification, affecting not only the accuracy of internal settlements but also hindering resource management. Existing resource allocation methods are insufficient in both accuracy and flexibility.

[0004] Therefore, there is an urgent need for an adaptive resource allocation method to solve the above problems. Summary of the Invention

[0005] This invention provides a method for allocating resources in a bank cloud application to improve the accuracy and flexibility of internal resource allocation calculations. The method includes: Collect resource consumption data, business flow and call chain data, scaling up and down event data, and user operation behavior data of each subsidiary on the bank's cloud application system. Based on resource consumption data, business flow and call chain data, and scaling up and down event data, calculate the first, second and third indicators for each subsidiary's cloud application system. Based on the pre-established weight determination model, the weight coefficients of the first indicator, the second indicator, and the third indicator are determined respectively. Based on the weight coefficients and corresponding indicators, the resource allocation coefficients of each subsidiary to the bank cloud application system are generated. Based on user behavior data, machine learning models are used to identify the types of intent of each subsidiary to use the bank's cloud application system. Based on the resource allocation coefficients and usage intent types of each subsidiary for the bank cloud application system, the resource allocation amount for the corresponding subsidiary for the bank cloud application system is determined.

[0006] This invention also provides a bank cloud application resource allocation device to improve the accuracy and flexibility of internal bank resource allocation calculations. The device includes: The data acquisition module is used to collect data on resource consumption, business flow and call chain, scaling up and down events, and user operation behavior of each subsidiary on the bank's cloud application system. The indicator calculation module is used to calculate the first, second and third indicators of each subsidiary for each cloud application system based on resource consumption data, business flow and call chain data and scaling up and down event data. The resource allocation coefficient calculation module is used to determine the weight coefficients of the first indicator, the second indicator, and the third indicator respectively based on the pre-established weight determination model, and generate the resource allocation coefficients of each subsidiary for the bank cloud application system based on the weight coefficients and corresponding indicators. The intent type determination module is used to identify the intent type of each subsidiary to use the bank's cloud application system based on user operation behavior data and through machine learning models. The resource allocation determination module is used to determine the resource allocation amount of each subsidiary to the bank cloud application system based on the resource allocation coefficient and usage intent type of each subsidiary.

[0007] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-mentioned bank cloud application resource allocation method.

[0008] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described bank cloud application resource allocation method.

[0009] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described bank cloud application resource allocation method.

[0010] In this embodiment of the invention, resource consumption data, business flow and call chain data, scaling-up and scaling-down event data, and user operation behavior data of each subsidiary on the bank's cloud application system are collected. Based on the resource consumption data, business flow and call chain data, and scaling-up and scaling-down event data, a first indicator, a second indicator, and a third indicator for each subsidiary on each cloud application system are calculated. The second indicator is used to characterize the service call frequency; the third indicator is used to characterize the degree of dependency of the call relationship between services. According to a pre-established weight determination model, the weight coefficients of the first indicator, the second indicator, and the third indicator are determined respectively. Based on the weight coefficients and corresponding indicators, resource allocation coefficients for each subsidiary on the bank's cloud application system are generated. Based on user operation behavior data, the usage intent type of each subsidiary on the bank's cloud application system is identified through a machine learning model. Based on the resource allocation coefficients and usage intent types of each subsidiary on the bank's cloud application system, the resource allocation amount for the corresponding subsidiary on the bank's cloud application system is determined. Compared with existing technologies that rely solely on resource consumption or fixed rules for allocation, this invention calculates resource allocation coefficients based on three indicators: resource consumption intensity, business value density, and system dependence. Furthermore, by introducing a weighted determination model, the invention uses the type of usage intent identified through machine learning as a key factor in calculating resource allocation. This not only allows the final resource allocation to more accurately reflect the actual resource consumption, business value contribution, and system importance of each subsidiary, but also flexibly distinguishes resource ownership under different usage intents, thus providing a more accurate and flexible resource allocation solution for the bank. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart of the bank cloud application resource allocation method in an embodiment of the present invention; Figure 2 This is a flowchart for determining the first indicator in an embodiment of the present invention; Figure 3 This is a flowchart for determining the second indicator in an embodiment of the present invention; Figure 4 This is a flowchart for determining the third indicator in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the process of establishing a weight determination model in an embodiment of the present invention; Figure 6This is a flowchart for determining the type of intent in an embodiment of the present invention; Figure 7 This is a flowchart illustrating the calculation of resource allocation in an embodiment of the present invention; Figure 8 This is a schematic diagram of a bank cloud application resource allocation device in an embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0013] The acquisition, transmission, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0014] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0015] Figure 1 This is a flowchart of a bank cloud application resource allocation method in an embodiment of the present invention. The method includes: Step 101: Collect resource consumption data, business flow and call chain data, scaling up and down event data, and user operation behavior data of each subsidiary for the bank's cloud application system; Step 102: Based on resource consumption data, business flow and call chain data, and scaling up / down event data, calculate the first, second, and third indicators for each subsidiary's cloud application system; the second indicator is used to characterize the service call frequency; the third indicator is used to characterize the degree of dependency of the call relationship between services. Step 103: Based on the pre-established weight determination model, determine the weight coefficients of the first indicator, the second indicator, and the third indicator respectively, and generate the resource allocation coefficients of each subsidiary for the bank cloud application system based on the weight coefficients and corresponding indicators. Step 104: Based on user operation behavior data, identify the types of intent of each subsidiary to use the bank's cloud application system through machine learning models; Step 105: Based on the resource allocation coefficients and usage intent types of each subsidiary for the bank cloud application system, determine the resource allocation amount for the corresponding subsidiary for the bank cloud application system.

[0016] Each step is explained in detail below.

[0017] In step 101, data on resource consumption, business flow and call chain, scaling up and down events, and user operation behavior of each subsidiary on the bank's cloud application system are collected.

[0018] In a specific embodiment, resource consumption data includes: Computing resources: CPU utilization, CPU core usage, memory usage, and memory utilization rate of application containers or virtual machines belonging to each subsidiary. Storage resources: Storage capacity usage, IOPS (read / write operations per second), and throughput of persistent volumes (PVs). Network resources: Network inflow / outflow traffic and number of network connections.

[0019] Business transaction data includes: transaction number, transaction time, transaction type, transaction amount, transaction status, and the subsidiary accounts involved.

[0020] The call chain data includes: the trace ID of each business request, the service nodes traversed, the start and end times of the inter-service call, the call depth, the API interface path called, and the call status.

[0021] User action data includes: Action context: action time, operator ID (associated with subsidiary), login IP address, and client used. Action behavior: accessed functional modules (e.g., "Loan Approval," "Risk Management Report"), specific actions performed (e.g., "Query," "Export," "Approval Passed"), and input query conditions. Data access pattern: queried database tables, returned data volume, and frequently accessed time periods.

[0022] Scaling up and down events include: event occurrence time, event type (e.g., Pod scaling up / HPA, Pod scaling down), the resource object that triggered the event, the number of replicas before and after the change, and the reason for triggering the event.

[0023] In step 102, based on resource consumption data, business flow and call chain data, and scaling up / down event data, the first indicator, second indicator, and third indicator for each subsidiary to each cloud application system are calculated respectively; the second indicator is used to characterize the call frequency of the service; the third indicator is used to characterize the degree of dependency of the call relationship between services.

[0024] In a specific embodiment, the resource consumption intensity index (i.e., the first index) refers to a quantitative value calculated by combining the actual resource occupancy rate and the stability penalty factor introduced by the elastic scaling behavior of instances. It is used to characterize the absolute amount of resource occupancy and fluctuating resources.

[0025] Business value density index (i.e., the second index): refers to a quantitative value calculated based on parameters such as transaction success rate, risk weight, number of API calls and peak business hours, used to characterize the effective business output supported by the unit system processing capacity.

[0026] System dependency index (i.e., the third index): refers to a quantitative value calculated based on the service call chain depth and dependency strength coefficient, used to characterize the depth and criticality of the application being called by other services.

[0027] Figure 2 This is a flowchart illustrating the determination of the first indicator in an embodiment of the present invention. In one embodiment, based on resource consumption data, business flow and call chain data, and scaling up / down event data, the first, second, and third indicators for each subsidiary's impact on each cloud application system are calculated, including: Step 201: Determine the resource utilization rate based on resource consumption data; determine the elastic scaling penalty factor based on scaling up / down event data. Step 202: Determine the first indicator based on resource utilization rate and elastic scaling penalty factor.

[0028] In one embodiment, the first index is determined according to the following formula: ; in, The primary indicator for subsidiaries. Resource utilization rate is the percentage of actual resource usage out of the total available resources. This represents the percentage of actual memory resources used out of the total available memory in the resource utilization rate. This is the penalty factor for elastic expansion and contraction. This is the end time of the current cycle. This is the starting time of the current cycle.

[0029] In a specific embodiment, after collecting resource consumption data, the resource utilization rate is calculated for each resource instance of each subsidiary under the cloud application according to a predetermined evaluation period (e.g., 1 hour). First, the CPU utilization rate sequence and memory usage sequence of the resource instance within an evaluation period T are obtained from the time-series database. Simultaneously, the resource quota allocated to the resource instance is obtained: the total number of CPU cores and the total memory capacity. The resource utilization rate within the evaluation period, including CPU utilization rate and memory utilization rate, is then calculated.

[0030] In a specific embodiment, Instead of fixed rule parameters, these are dynamically calculated using a stability cost evaluation algorithm. This algorithm analyzes the scaling event sequence of an instance within a time window, uses Dynamic Time Warping (DTW) to calculate the deviation between its resource change pattern and the historical baseline pattern, and maps this deviation to a sigmoid function. Value. The greater the deviation, The higher the value, the better. The specific process is as follows: Define a review time window N (e.g., the past 24 hours). For the target instance, extract all events within window N from the scaling event log to generate an actual resource size sequence. The actual resource size sequence is a time series, for example, [(t1, 2), (t2, 4), (t3, 2), ...], where (t1, 2) represents the instance scaling up to 2 at time t1, and (t2, 4) represents scaling up to 4 at time t2.

[0031] The system maintains a historical stable baseline sequence. This baseline sequence can be obtained by calculating the average resource size sequence of the instance during historical periods of stable operation (e.g., the same time period each day over the past 30 calendar days). The minimum cumulative distance (DTW distance) between the actual resource size sequence and the baseline sequence is calculated using a dynamic time warping algorithm. The minimum cumulative distance (DTW distance) reflects the deviation of the actual scaling pattern from the overall shape of the stable baseline.

[0032] The Sigmoid function is used to map the continuously changing deviation to an elastic expansion / contraction penalty factor.

[0033] By using the dynamic time warping algorithm and the Sigmoid function, the resource instability that is difficult to quantify is transformed into a computable penalty factor, so that the final resource allocation is not only based on the static resource consumption, but also reflects the additional consumption caused by excessive elastic scaling.

[0034] Figure 3 This is a flowchart illustrating the determination of the second indicator in an embodiment of the present invention. In one embodiment, based on resource consumption data, business flow and call chain data, and scaling up / down event data, the first, second, and third indicators for each subsidiary's impact on each cloud application system are calculated, including: Step 301: Based on business transaction data and call chain data, obtain transaction success rate, risk weight coefficient, number of API calls, and peak business duration. Step 302: Determine the second indicator based on the transaction success rate, risk weighting coefficient, number of API calls, and peak business hours.

[0035] In one embodiment, the second index is determined according to the following formula:

[0036] in, To improve the success rate of transactions, For risk weighting coefficients, For the number of API calls, For peak business hours, This is the second indicator for the subsidiary.

[0037] In a specific implementation, during the evaluation period, the total number of transactions N_total initiated by the subsidiary through the target cloud application is counted. The number of transactions with a successful status N_success is then counted. The success rate is calculated as: Transaction_amt = N_success / N_total. The success rate, ranging from 0 to 1, reflects the reliability and quality of business processing.

[0038] From the business transaction data, extract the transaction type (e.g., large transfers, small payments, account inquiries, cross-border remittances) for each transaction within the assessment period. Assign a risk weight value to each transaction based on a mapping table. For example: {Cross-border remittance: risk weight 1.5, large transfer: risk weight 1.2, small payment: risk weight 1.0, account inquiry: risk weight 0.5}. A higher weight indicates a higher risk control cost for that transaction. The total risk weight generated by the subsidiary within the assessment period is the risk weight coefficient.

[0039] During the evaluation period, all call chains triggered by subsidiary business requests were tracked. The total number of times the cloud application API interfaces were called within the call chains was statistically analyzed. This allowed for the measurement of the processing workload and computing resource consumption required by the subsidiary businesses.

[0040] Analyze historical data (e.g., the past 30 days) to determine the average transaction volume of cloud applications at different times of the day, forming a business volume baseline curve. Within the date type (e.g., weekdays, holidays) of the current assessment period, identify consecutive periods where the transaction volume consistently exceeds the baseline by a certain percentage (e.g., 150%). This refers to the total length (in hours) of the peak business period that falls within the current assessment period. This is used to amplify the value contribution of business during peak hours, because peak hours have higher requirements for system stability and resource security.

[0041] Figure 4 This is a flowchart illustrating the determination of the third indicator in an embodiment of the present invention. In one embodiment, based on resource consumption data, business flow and call chain data, and scaling up / down event data, the first, second, and third indicators for each subsidiary's cloud application system are calculated, including: Step 401: Based on the call chain data, extract the call chain depth and dependency strength coefficient; Step 402: Determine the third metric based on the call chain depth and dependency strength coefficient.

[0042] In one embodiment, the third index is determined according to the following formula:

[0043] in, The third metric for the subsidiary is A, where A represents the call chain depth. This is the dependence intensity coefficient.

[0044] In a specific embodiment, the call chain depth refers to the number of different service calls a business request goes through from the entry service to the current service.

[0045] The dependency strength coefficient is a parameter used to quantify the strength of dependencies between systems. It can quantify the existence of a strong dependency as a binary flag (1 if yes, 0 if no); or it can be set to different levels of value according to the tightness of the dependency (e.g., 1.0 for strong dependency, 0.5 for weak dependency, and 0 for no dependency).

[0046] In step 103, the weight coefficients of the first indicator, the second indicator, and the third indicator are determined according to the pre-established weight determination model. Based on the weight coefficients and the corresponding indicators, the resource allocation coefficients of each subsidiary to the bank cloud application system are generated.

[0047] Figure 5 This is a flowchart illustrating the process of establishing a weight determination model in one embodiment of the present invention. In one embodiment, establishing the weight determination model includes: Step 501: Obtain the first, second, and third indicators of the historical period and the corresponding baseline resource allocation. Step 502: Use the first, second, and third indicators of the historical cycle as inputs and the benchmark resource allocation amount as the training target to train the machine learning model. Step 503: Determine initial weight coefficients by minimizing the error between the predicted resource allocation output by the machine learning model and the baseline resource allocation, so as to establish a weight determination model.

[0048] In a specific embodiment, a historical time period is selected as the training period, such as the past 12 complete calendar months. This time period should cover the complete business cycle (such as quarterly or annual settlement) and typical technical events. For each billing cycle (such as monthly) within the training period, the first indicator, the second indicator, and the third indicator are extracted.

[0049] The baseline resource allocation refers to the actual resource allocation of the subsidiary to the bank's cloud applications within a historical period. It serves as a supervisory signal for model learning, providing a learning objective for the machine learning model.

[0050] Establish a mapping function F, and express the resource allocation C predicted by the machine learning model as: ; in, Let F be the baseline resource allocation. F is a multiple linear regression model, formally represented as follows: ; , , These correspond to the weighting coefficients for resource consumption intensity, business value density, and system dependence, respectively, with b being the bias term.

[0051] The mean squared error (MSE) is used as the loss function, and the goal is to minimize the error between the predicted resource allocation and the baseline resource allocation.

[0052] After the model training converges, the optimal weight coefficients and bias terms are obtained. At this point, the machine learning model is determined to be a weight-determined model.

[0053] In one embodiment, the weight coefficients of the first indicator, the second indicator, and the third indicator are determined according to a pre-established weight determination model, including: Obtain the first, second, and third indicators of each subsidiary's performance on the bank's cloud application system within the current period; Input the current first, second, and third indicators into the weight determination model, and output the weight coefficients of the first, second, and third indicators respectively.

[0054] In one embodiment, resource allocation coefficients for each subsidiary to the bank's cloud application system are generated based on weighting coefficients and corresponding indicators, including: Calculate the resource allocation coefficient using the following formula:

[0055] Where W is the resource allocation coefficient. , , These are the weighting coefficients of the first indicator R, the second indicator V, and the third indicator D, respectively.

[0056] In a specific embodiment, the weighting coefficients of the first indicator, the second indicator, and the third indicator are dynamically adjusted. The specific steps include: Based on the weighting coefficients of the first indicator, the second indicator, and the third indicator, calculate the current resource allocation effectiveness indicator. Determine whether the resource allocation performance indicators meet the preset trigger conditions; If the triggering conditions are met, the weight fine-tuning program is started. Based on the current resource allocation effect indicators and historical effect data, at least one of the weight coefficients of the first indicator, the second indicator, and the third indicator is adjusted to generate optimized weight coefficients. The optimized weighting coefficients are applied to the weighting determination for the next period.

[0057] In step 104, based on user operation behavior data, the type of intent of each subsidiary to use the bank's cloud application system is identified through a machine learning model.

[0058] Figure 6 This is a flowchart illustrating the process of determining the type of usage intent in an embodiment of the present invention. In one embodiment, based on user operation behavior data, a machine learning model is used to identify the type of usage intent of each subsidiary towards the bank's cloud application system, including: Step 601: Extract features from user operation behavior data to obtain feature vectors for intent recognition; Step 602: Input the feature vector into the pre-trained machine learning model and output the corresponding usage intent type, which includes business operation, system test, resource usage and abnormal operation.

[0059] In a specific embodiment, the type of usage intent identified by machine learning is used as a key variable to correct resource allocation decisions. The specific steps are as follows: After feature extraction from user action data, the data is input into a pre-trained machine learning classification model. The model then classifies the session or action sequence into one of the following categories: normal business operation, system testing, resource exploration, or abnormal operation.

[0060] A pre-defined resource allocation adjustment coefficient is used for each intent type. The intent type recognition result output by the model is directly converted into a resource allocation adjustment coefficient, which is used to dynamically adjust the resource allocation amount. Specifically: For normal business operations: the resource allocation adjustment coefficient is 1; resource requirements generated by this type of operation will be fully allocated according to its initial resource allocation coefficient. For system testing / resource exploration: the resource allocation adjustment coefficient is 0.3-0.8, thus avoiding excessive consumption of resources applied to business operations during stress testing for system stability. For abnormal operations: the resource allocation adjustment coefficient is >1 or marked for auditing; abnormal operations are automatically detected and marked, and their resource consumption is handled separately, thereby controlling risk.

[0061] By identifying usage intent to adjust resource allocation, the entire process is completed automatically by the system, reducing reliance on human judgment, improving resource efficiency, and providing banks with a means to simultaneously consider resource efficiency and risk control.

[0062] In step 105, the resource allocation amount of each subsidiary to the bank cloud application system is determined based on the resource allocation coefficient and usage intent type of each subsidiary.

[0063] Figure 7This is a flowchart illustrating the calculation of resource allocation in an embodiment of the present invention. In one embodiment, based on the resource allocation coefficients and usage intent types of each subsidiary for the bank cloud application system, the resource allocation amount for the corresponding subsidiary to the bank cloud application system is determined, including: Step 701: Obtain the resource allocation coefficients and usage intent types for each subsidiary; Step 702: Based on the usage intent type, match the preset usage intent with the calculation rule of resource allocation amount. The calculation rule is the mapping relationship between different usage intent types and resource allocation coefficients and resource allocation amounts. Step 703: Based on the calculation rules obtained from the matching, calculate the resource allocation amount of each subsidiary to the bank's cloud application system.

[0064] In a specific implementation, weighted coefficients based on three indicators—resource consumption intensity, business value density, and system dependency—are calculated for each subsidiary to reflect its relative resource consumption. The resource consumption percentage of each subsidiary is statistically analyzed, categorized into four intent types: normal business operation, system testing, exploratory resource use, and abnormal operation (e.g., when normal business operation consumes 70% of CPU cores, system testing consumes 20%, and exploratory use consumes 10%).

[0065] A mapping table is pre-defined for usage intent type, resource allocation adjustment coefficient, and resource allocation amount calculation rule. The resource allocation amount calculation rule is: Subsidiary resource = Resource allocation coefficient × Resource allocation adjustment coefficient × Corresponding resource in the total resource pool.

[0066] Resource allocation is adjusted based on the different resource usage intentions of subsidiaries. Total resource allocation coefficient for subsidiaries. The calculation formula is as follows: ; in, W The resource allocation coefficient is calculated based on the weighting coefficient and the corresponding indicator. I represents the proportion of resource consumption by the subsidiary under each type of usage intent. This is the allocation coefficient corresponding to the amount of resources allocated.

[0067] Subsidiary A has a resource allocation coefficient of 0.1. Its usage intent type distribution is: normal business (70%, λ=1.0), system testing (20%, λ=0.5), and exploratory use (10%, λ=0.8). Therefore, its effective resource allocation coefficient is: W_effective_A=0.1 (70%) 1.0 + 20% 0.5 + 10% 0.8) = 0.1 (0.70 + 0.10 + 0.08) = 0.088; The adjusted effective resource allocation coefficient is applied to the total resource pool of the cloud application. The initial resource allocation C of the subsidiary can be expressed as: C = W_effective_A The corresponding resource consumption in the total resource pool.

[0068] This invention also provides a bank cloud application resource allocation device, as described in the following embodiments. Since the principle by which this device solves the problem is similar to the bank cloud application resource allocation method, the implementation of this device can refer to the implementation of the bank cloud application resource allocation method; repeated details will not be elaborated further.

[0069] Figure 8 This is a schematic diagram of a bank cloud application resource allocation device according to an embodiment of the present invention. The device includes: The data acquisition module 801 is used to collect resource consumption data, business flow and call chain data, scaling up and down event data, and user operation behavior data of each subsidiary on the bank's cloud application system. The indicator calculation module 802 is used to calculate the first indicator, the second indicator, and the third indicator for each subsidiary to each cloud application system based on resource consumption data, business flow and call chain data, and scaling up and down event data; the second indicator is used to characterize the call frequency of the service; the third indicator is used to characterize the degree of dependency of the call relationship between services. The resource allocation coefficient calculation module 803 is used to determine the weight coefficients of the first indicator, the second indicator, and the third indicator respectively according to the pre-established weight determination model, and to generate the resource allocation coefficients of each subsidiary for the bank cloud application system based on the weight coefficients and corresponding indicators. The intent type determination module 804 is used to identify the intent type of each subsidiary to use the bank cloud application system based on user operation behavior data and through a machine learning model. The resource allocation determination module 805 is used to determine the resource allocation amount of the corresponding subsidiary to the bank cloud application system based on the resource allocation coefficient and usage intent type of each subsidiary.

[0070] In one embodiment, the indicator calculation module 802 is specifically used for: Based on resource consumption data, determine resource utilization rate; based on scaling up and down event data, determine elastic scaling up and down penalty factor; The first indicator is determined based on resource utilization rate and elastic scaling penalty factor.

[0071] In one embodiment, the first index is determined according to the following formula: ; in, The primary indicator for subsidiaries. Resource utilization rate is the percentage of actual resource usage out of the total available resources. This represents the percentage of actual memory resources used out of the total available memory in the resource utilization rate. This is the penalty factor for elastic expansion and contraction. This is the end time of the current cycle. This is the starting time of the current cycle.

[0072] In one embodiment, the indicator calculation module 802 is specifically used for: Based on business transaction data and call chain data, obtain transaction success rate, risk weight coefficient, number of API calls and peak business duration; The second indicator is determined based on transaction success rate, risk weighting coefficient, number of API calls, and peak business hours.

[0073] In one embodiment, the second index is determined according to the following formula:

[0074] in, To improve the success rate of transactions, For risk weighting coefficients, For the number of API calls, For peak business hours, This is the second indicator for the subsidiary.

[0075] In one embodiment, the indicator calculation module 802 is specifically used for: Based on the call chain data, extract the call chain depth and dependency strength coefficient; The third metric is determined based on the call chain depth and dependency strength coefficient.

[0076] In one embodiment, the third index is determined according to the following formula:

[0077] in, The third metric for the subsidiary is A, where A represents the call chain depth. This is the dependence intensity coefficient.

[0078] In one embodiment, the system further includes a weight determination model building module, specifically used for: Obtain the first, second, and third indicators of the historical period, as well as the corresponding baseline resource allocation; The machine learning model is trained by taking the first, second, and third indicators of the historical cycle as input and the benchmark resource allocation as the training target. An initial weighting coefficient is determined by minimizing the error between the predicted resource allocation output by the machine learning model and the baseline resource allocation, in order to establish a weight determination model.

[0079] In one embodiment, the resource allocation coefficient calculation module 803 is specifically used for: Obtain the first, second, and third indicators of each subsidiary's performance on the bank's cloud application system within the current period; Input the current first, second, and third indicators into the weight determination model, and output the weight coefficients of the first, second, and third indicators respectively.

[0080] In one embodiment, the resource allocation coefficient calculation module 803 is specifically used for: Calculate the resource allocation coefficient using the following formula:

[0081] Where W is the resource allocation coefficient. , , These are the weighting coefficients of the first indicator R, the second indicator V, and the third indicator D, respectively.

[0082] In one embodiment, the intent type determination module 804 is used specifically for: Feature extraction is performed on user operation behavior data to obtain feature vectors for intent recognition; The feature vector is input into a pre-trained machine learning model, and the corresponding usage intent type is output. The usage intent type includes business operation, system test, resource usage, and abnormal operation.

[0083] In one embodiment, the resource allocation determination module 805 is specifically used for: Obtain the resource allocation coefficients and usage intent types for each subsidiary; Based on the type of usage intent, a preset calculation rule is used to match the usage intent with the resource allocation amount. The calculation rule is a mapping relationship between different types of usage intent and resource allocation coefficients and resource allocation amounts. Based on the calculation rules obtained from the matching, the resource allocation amount of each subsidiary to the bank's cloud application system is calculated.

[0084] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-mentioned bank cloud application resource allocation method.

[0085] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described bank cloud application resource allocation method.

[0086] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described bank cloud application resource allocation method.

[0087] In this embodiment of the invention, resource consumption data, business flow and call chain data, scaling-up and scaling-down event data, and user operation behavior data of each subsidiary on the bank's cloud application system are collected. Based on the resource consumption data, business flow and call chain data, and scaling-up and scaling-down event data, a first indicator, a second indicator, and a third indicator for each subsidiary on each cloud application system are calculated. The second indicator is used to characterize the service call frequency; the third indicator is used to characterize the degree of dependency of the call relationship between services. According to a pre-established weight determination model, the weight coefficients of the first indicator, the second indicator, and the third indicator are determined respectively. Based on the weight coefficients and corresponding indicators, resource allocation coefficients for each subsidiary on the bank's cloud application system are generated. Based on user operation behavior data, the usage intent type of each subsidiary on the bank's cloud application system is identified through a machine learning model. Based on the resource allocation coefficients and usage intent types of each subsidiary on the bank's cloud application system, the resource allocation amount for the corresponding subsidiary on the bank's cloud application system is determined. Compared with existing technologies that rely solely on resource consumption or fixed rules for allocation, this invention calculates resource allocation coefficients based on three indicators: resource consumption intensity, business value density, and system dependence. Furthermore, by introducing a weighted determination model, the invention uses the type of usage intent identified through machine learning as a key factor in calculating resource allocation. This not only allows the final resource allocation to more accurately reflect the actual resource consumption, business value contribution, and system importance of each subsidiary, but also flexibly distinguishes resource ownership under different usage intents, thus providing a more accurate and flexible resource allocation solution for the bank.

[0088] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0090] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

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

[0092] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for allocating resources in a bank cloud application, characterized in that, include: Collect resource consumption data, business flow and call chain data, scaling up and down event data, and user operation behavior data of each subsidiary on the bank's cloud application system. Based on resource consumption data, business flow and call chain data, and scaling up / down event data, the first, second, and third indicators for each subsidiary's cloud application systems are calculated respectively; the first indicator is used to characterize the actual resource utilization rate; the second indicator is used to characterize the service call frequency; and the third indicator is used to characterize the degree of dependency of the call relationship between services. Based on the pre-established weight determination model, the weight coefficients of the first indicator, the second indicator, and the third indicator are determined respectively. Based on the weight coefficients and corresponding indicators, the resource allocation coefficients of each subsidiary to the bank cloud application system are generated. Based on user behavior data, machine learning models are used to identify the types of intent of each subsidiary to use the bank's cloud application system. Based on the resource allocation coefficients and usage intent types of each subsidiary for the bank cloud application system, the resource allocation amount for the corresponding subsidiary for the bank cloud application system is determined.

2. The method as described in claim 1, characterized in that, Based on resource consumption data, business flow and call chain data, and scaling up / down event data, calculate the first, second, and third indicators for each subsidiary's cloud application systems, including: Based on resource consumption data, determine resource utilization rate; based on scaling up and down event data, determine elastic scaling up and down penalty factor; The first indicator is determined based on resource utilization rate and elastic scaling penalty factor.

3. The method as described in claim 2, characterized in that, The first indicator is determined according to the following formula: ； in, The primary indicator for subsidiaries. Resource utilization rate is the percentage of actual resource usage out of the total available resources. This represents the percentage of actual memory resources used out of the total available memory in the resource utilization rate. This is the penalty factor for elastic expansion and contraction. This is the end time of the current cycle. This is the starting time of the current cycle.

4. The method as described in claim 1, characterized in that, Based on resource consumption data, business flow and call chain data, and scaling up / down event data, calculate the first, second, and third indicators for each subsidiary's cloud application systems, including: Based on business transaction data and call chain data, obtain transaction success rate, risk weight coefficient, number of API calls and peak business duration; The second indicator is determined based on transaction success rate, risk weighting coefficient, number of API calls, and peak business hours.

5. The method as described in claim 4, characterized in that, The second indicator is determined using the following formula: in, To improve the success rate of transactions, For risk weighting coefficients, For the number of API calls, For peak business hours, This is the second indicator for the subsidiary.

6. The method as described in claim 1, characterized in that, Based on resource consumption data, business flow and call chain data, and scaling up / down event data, calculate the first, second, and third indicators for each subsidiary's cloud application systems, including: Based on the call chain data, extract the call chain depth and dependency strength coefficient; The third metric is determined based on the call chain depth and dependency strength coefficient.

7. The method as described in claim 6, characterized in that, The third indicator is determined using the following formula: in, The third metric for the subsidiary is A, where A represents the call chain depth. This is the dependence intensity coefficient.

8. The method as described in claim 1, characterized in that, Establish a weight determination model, including: Obtain the first, second, and third indicators of the historical period, as well as the corresponding baseline resource allocation; The machine learning model is trained by taking the first, second, and third indicators of the historical cycle as input and the benchmark resource allocation as the training target. An initial weighting coefficient is determined by minimizing the error between the predicted resource allocation output by the machine learning model and the baseline resource allocation, in order to establish a weight determination model.

9. The method as described in claim 8, characterized in that, Based on the pre-established weighting model, the weighting coefficients for the first indicator, the second indicator, and the third indicator are determined respectively, including: Obtain the first, second, and third indicators of each subsidiary's performance on the bank's cloud application system within the current period; Input the current first, second, and third indicators into the weight determination model, and output the weight coefficients of the first, second, and third indicators respectively.

10. The method as described in claim 9, characterized in that, Resource allocation coefficients for the bank's cloud application system are generated for each subsidiary based on weighting coefficients and corresponding indicators, including: Calculate the resource allocation coefficient using the following formula: Where W is the resource allocation coefficient. , , These are the weighting coefficients of the first indicator R, the second indicator V, and the third indicator D, respectively.

11. The method as described in claim 1, characterized in that, Based on user behavior data, machine learning models are used to identify the types of intent of each subsidiary to use the bank's cloud application system, including: Feature extraction is performed on user operation behavior data to obtain feature vectors for intent recognition; The feature vector is input into a pre-trained machine learning model, and the corresponding usage intent type is output. The usage intent type includes business operation, system test, resource usage, and abnormal operation.

12. The method as described in claim 1, characterized in that, Based on the resource allocation coefficients and usage intent types of each subsidiary for the bank's cloud application system, the resource allocation amount for the corresponding subsidiary for the bank's cloud application system is determined, including: Obtain the resource allocation coefficients and usage intent types for each subsidiary; Based on the type of usage intent, a preset calculation rule is used to match the usage intent with the resource allocation amount. The calculation rule is a mapping relationship between different types of usage intent and resource allocation coefficients and resource allocation amounts. Based on the calculation rules obtained from the matching, the resource allocation amount of each subsidiary to the bank's cloud application system is calculated.

13. A resource allocation device for a bank cloud application, characterized in that, include: The data acquisition module is used to collect data on resource consumption, business flow and call chain, scaling up and down events, and user operation behavior of each subsidiary on the bank's cloud application system. The indicator calculation module is used to calculate the first indicator, second indicator, and third indicator for each subsidiary on each cloud application system based on resource consumption data, business flow and call chain data, and scaling up and down event data; the second indicator is used to characterize the call frequency of the service; the third indicator is used to characterize the degree of dependency of the call relationship between services. The resource allocation coefficient calculation module is used to determine the weight coefficients of the first indicator, the second indicator, and the third indicator respectively based on the pre-established weight determination model, and generate the resource allocation coefficients of each subsidiary for the bank cloud application system based on the weight coefficients and corresponding indicators. The intent type determination module is used to identify the intent type of each subsidiary to use the bank's cloud application system based on user operation behavior data and through machine learning models. The resource allocation determination module is used to determine the resource allocation amount of each subsidiary to the bank cloud application system based on the resource allocation coefficient and usage intent type of each subsidiary.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 12.

16. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 12.

Images