Resource adjustment method, device, apparatus, medium and program product

Abstract

This application provides a resource adjustment method, apparatus, device, medium, and program product, relating to the field of cloud computing technology, which addresses the technical problem of poor system resource adjustment effectiveness. The method includes: performing a risk assessment on multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, the risk score representing the probability that the corresponding payment request is risky; determining a risk ratio based on the assessment result, the risk ratio representing the proportion of high-risk payment requests among the multiple payment requests; and expanding or shrinking the computing resources in the server based on the risk ratio, wherein the computing resources are those used to process the payment requests received by the server. This application can improve the resource adjustment effect.

Description

Technical Field

[0001] This application belongs to the field of cloud computing technology, specifically relating to a resource adjustment method, apparatus, equipment, medium, and program product. Background Technology

[0002] In the field of cloud computing resource scheduling, especially in the specific application scenario of financial risk control, resource scheduling methods include static resource allocation methods and business indicator expansion methods. Static resource allocation methods suffer from a technical problem of dynamic disconnect between resource supply and business demand, failing to detect real-time changes in risk control load. As for business indicator expansion methods, since there is no direct correlation between transaction volume and risk control computing load, using transaction volume as the scheduling basis leads to ineffective capacity expansion during peak business periods such as normal promotions and critical security checks, wasting significant system resources. Therefore, these technologies exhibit poor system resource adjustment effectiveness in peak payment scenarios. Summary of the Invention

[0003] This application provides a resource adjustment method, apparatus, device, medium, and program product to solve the problem of poor system resource adjustment effect.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a resource adjustment method applied to a server, the method comprising: A risk assessment is performed on multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. Based on the assessment results, a risk ratio is determined. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment request is the payment request whose risk score is greater than a first threshold. The computing resources in the server are expanded or reduced based on the risk ratio, wherein the computing resources are used to process payment requests received by the server.

[0005] Secondly, embodiments of this application provide a resource adjustment device applied to a server, the device comprising: An evaluation module is used to perform risk assessment on multiple payment requests received by the server and obtain an evaluation result. The evaluation result includes a risk score for each payment request among the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. The determination module is used to determine the risk ratio based on the assessment results. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment requests are payment requests whose risk scores are greater than a first threshold. The processing module is used to expand or shrink the computing resources in the server based on the risk ratio, wherein the computing resources are computing resources used to process payment requests received by the server.

[0006] Thirdly, embodiments of this application provide an electronic device, including a transceiver and a processor, wherein the processor is used for: A risk assessment is performed on multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. Based on the assessment results, a risk ratio is determined. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment request is the payment request whose risk score is greater than a first threshold. The computing resources in the server are expanded or reduced based on the risk ratio, wherein the computing resources are used to process payment requests received by the server.

[0007] Fourthly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the resource adjustment method described in the first aspect above.

[0008] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the resource adjustment method described in the first aspect above.

[0009] In a sixth aspect, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the resource adjustment method as described in the first aspect above.

[0010] In this embodiment, multiple received payment requests are risk-assessed, and a risk ratio is determined. Based on the risk ratio, the computing resources in the server are expanded or reduced. During peak business periods, such as high transaction volume and low risk, although the transaction volume is high, the risk ratio is low, so the system determines that expansion is not necessary, and resource costs are controlled. Furthermore, when subjected to a small number of high-risk attacks, although the transaction volume is low, the risk ratio is high, so the system will trigger expansion to ensure that high computing power consumption attacks can be processed in a timely manner, thereby reducing the false negative rate and improving the system resource adjustment effect. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of a resource adjustment method provided in an embodiment of this application; Figure 2 This is one of the business process diagrams of a resource adjustment method provided in the embodiments of this application; Figure 3 This is a second business process diagram of a resource adjustment method provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a resource adjustment device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0014] For ease of understanding, the following describes some aspects of the embodiments of this application: (I) Company Business and Application Scenarios: For companies whose main business covers internet finance, mobile payment, transaction settlement, etc., there are two core issues during peak payment scenarios (such as e-commerce promotions and holiday red envelopes): 1. The contradiction between risk control underreporting and resource waste: When there is a sudden high-risk transaction, the risk control service has high response delay due to insufficient resources, resulting in underreporting and a surge in the proportion of risky transactions; during off-peak hours, 80% of the risk control servers are idle, resulting in a large amount of idle servers and wasting operating costs such as data center rental and electricity, but manual staff dare not reduce capacity, considering that the traffic will not be able to respond in time.

[0015] Understandably, during peak payment periods, risk control services become overloaded, creating a dilemma: choosing a downgraded risk control strategy would increase the false negative rate, while manually scaling up would increase resource costs.

[0016] 2. Lack of dynamic adaptation in cloud-native architecture: Traditional resource scheduling (such as K8sHPA) only relies on CPU / memory metrics and cannot perceive the risk control business load (such as the proportion of high-risk transactions), resulting in significant lag in scaling. The operations and maintenance team cannot perceive the risk control load in real time and can only respond passively.

[0017] Therefore, a business-aware resource scheduling system needs to be built to achieve a dynamic balance between risk control security and cloud resource costs, and support the payment business SLA (99.99% availability, less than 200ms latency).

[0018] (ii) Commonly known technological basis: 1. Cloud-native elastic scheduling (HPA): (1) Definition: HorizontalPodAutoscaler (HPA) is one of the core elastic components of Kubernetes and a key automated scaling mechanism in the cloud-native technology stack. Its core goal is to dynamically adjust the number of application instances (pods) based on real-time load, thereby achieving resource utilization optimization, high availability, and cost control.

[0019] (2) Core mechanism: ① Monitoring metrics: HPA continuously monitors specified metrics of the application (such as CPU utilization, memory usage, custom metrics, or external metrics). ② Comparison with target value: Based on the preset target threshold, HPA determines whether the current indicator exceeds or falls short of the standard; ③ Automatic scaling up and down: Scaling up: When the metric exceeds the target value, HPA automatically increases the number of Pods to distribute the load; Scaling down: When the metric is below the target value, HPA reduces the number of Pods to save resources.

[0020] (3) Application limitations: It only responds to infrastructure indicators and is disconnected from business semantics such as payment risk control.

[0021] 2. Multimodal risk control technology: (1) Definition: Multimodal risk control technology refers to a technical system that integrates and analyzes data of multiple modalities (such as text, images, voice, video, behavior logs, device information, etc.), combines artificial intelligence algorithms and big data analysis capabilities, and constructs a multi-dimensional risk assessment model to more accurately identify and prevent complex risks (such as financial fraud, credit default, black market attacks, etc.).

[0022] (2) Technical principles: By integrating heterogeneous data from multiple sources, including text, images, voice, behavior logs, and device information (such as ID card photos, call recordings, and GPS location data), the system utilizes artificial intelligence algorithms to extract unimodal features and mines potential correlations (such as voiceprint aggregation to identify mediation attacks and image background consistency to detect forged documents) through cross-modal modeling (such as relational graphs and vector similarity calculations). Combining real-time data processing (such as video stream analysis) with dynamic model decision-making (rule engines and deep learning), the system outputs risk scores and triggers interception or review. Simultaneously, online learning and federated learning are used to continuously optimize the model to address emerging attacks such as AI face-swapping and deepfakes.

[0023] (3) Performance bottleneck: Complex model inference consumes a lot of resources during peak traffic, requiring dynamic resource guarantee.

[0024] (III) Analysis of relevant technical solutions: There are currently two approaches to improvement in the industry, but neither has fundamentally solved the technical problems: Option 1: Heap resource scheme (1) Implementation method: Deploy a large number of backup servers in advance and manually start them during peak hours.

[0025] (2) Differences from this application: In Scheme 1, server resources need to be deployed 1 hour in advance, the server is idle 90% of the time, and it relies on manual judgment. In this application, server resources can be expanded in seconds, and expansion is driven by risk perception through payment risk control.

[0026] 2. Option 2: Expansion of Simple Business Metrics (1) Implementation method: Add transaction volume indicators (such as the number of payments per minute) to the risk control resource scheduler. If the transaction volume is high, the risk control application cluster will be automatically expanded.

[0027] (2) Differences from this application: In Scheme 2, when a sudden fraud attack occurs, the system will not automatically expand its capacity due to the low transaction volume, resulting in missed fraud attacks. However, during normal peak periods, the transaction volume increases, and the system will automatically expand the payment risk control cluster, leading to resource waste. This application focuses on the risk ratio. When a sudden fraud attack occurs, the risk ratio surges, and the risk control system immediately expands its capacity. During peak business periods, when the risk ratio is low, the system maintains its normal state.

[0028] (iv) Technological biases and ingrained mindsets in related technologies: Through analysis of relevant technologies and common industry practices, two main technical biases and ingrained mindsets have long existed in the field of cloud computing resource scheduling, especially in the specific application scenario of financial risk control: 1. The tendency towards infrastructure-centric scheduling: For a long time, operations and maintenance personnel in this field have limited their focus on resource scheduling to infrastructure-layer metrics (such as CPU and memory utilization) or simple application-layer counting metrics (such as transactions per second - TPS, concurrent users). The fundamental idea behind this approach is to "indirectly infer business needs through the external performance of resources (utilization) or the macroscopic number of requests," rather than directly measuring the computing needs of the business itself.

[0029] 2. Homogeneous Assumption of Business Requests: Related solutions implicitly assume that all request types consume the same or similar amounts of computing resources when processing business requests. For example, they consider the computing power consumed by a device fingerprint verification request and a facial biometric recognition request to be equivalent. This assumption, which contradicts business realities, is the root cause of resource misallocation problems.

[0030] While resource elastic scheduling technology itself is quite mature, the aforementioned inherent mindset limits its effectiveness. Technological improvements in this field have consistently focused on how to more accurately predict CPU load or how to scale up more quickly, without ever questioning whether there are fundamental flaws in the decision-making basis (i.e., scheduling metrics) themselves. This application is based on a groundbreaking understanding of this technological bias.

[0031] Therefore, the relevant technology has the following technical defects: (a) Option 1: Static resource allocation scheme Technical Defect 1: Dynamic Disconnection Between Resource Supply and Business Demand Resource allocation is based on historical peak values ​​and cannot detect real-time changes in risk control load (such as a sudden surge in fraudulent transactions). Expansion decisions lag behind business needs, resulting in backlogs in risk control service queues during peak hours and missed risky transactions; and high resource idle rates during off-peak hours.

[0032] The solution proposed in this application is to dynamically link risk control outputs with resource instructions.

[0033] 1. Risk Quantification: Dynamic Monitoring of the Risk Control Engine The risk control engine analyzes business flow data in real time (such as transaction behavior, device fingerprints, and network requests) and calculates the risk ratio using the following model: Risk Ratio = (Total number of high-risk events / Total number of events) × 100% Rule engines (such as Drools): Preset threshold rules Streaming computing frameworks (such as Flink): Window statistics 2. Decision Making: Intelligent Decision Making by the Elastic Scheduler The elastic scheduler receives the risk ratio value and makes judgments based on pre-configured policies (ensuring cooling events and boundary control: scaling down requires a stable 300 seconds to avoid jittery boundary control; minimum number of replicas ensures service availability). ifrisk_ratio>threshold: # If the risk exceeds the threshold trigger_scale_out() # Perform scale expansion elifcontinuous_low_risk(): # If the risk remains low trigger_scale_in() # Perform scale-down 3. Resource scheduling: Container scaling up and down in seconds ScaleOut: Dynamically increase the number of Pod replicas by calling the Kubernetes API.

[0034] ScaleIn: Based on historical load prediction (ARIMA model), smoothly release resources.

[0035] Technical Defect 2: Manual Decision-Making Chain Introduces Scheduling Delay Operations and maintenance personnel need to monitor business metrics (risk rate) and technical metrics simultaneously, manually assess risk trends and manually expand capacity, with an average response latency of ≥5 minutes.

[0036] The solution proposed in this application is to dynamically link risk control outputs with resource instructions.

[0037] A closed-loop control system for risk control and scheduling was constructed, and a direct connection channel from "multimodal risk control output to scheduling API" was designed to eliminate manual intervention and reduce scheduling latency to the second level.

[0038] (II) Option 2: Business Indicator Expansion Plan Technical Defect 1: Dynamic Disconnection Between Resource Supply and Business Demand Since there is no direct correlation between transaction volume and risk control computational load, using transaction volume instead of risk ratio as the scheduling basis leads to ineffective capacity expansion during peak business periods such as normal promotions and critical insurance (high transaction volume and low risk), wasting a lot of system resources; while no capacity expansion is performed during sudden fraud (low transaction volume and high risk), resulting in a surge in the false negative rate.

[0039] The solution proposed in this application is to define specific metrics for risk control load.

[0040] Use the risk control ratio as a direct indicator.

[0041] Technical defect 2: Inability to distinguish load type leads to over-scheduling Because the scheduler lacks an understanding of the semantics of risk control business, when the system processes all transaction types uniformly, low-risk transactions (such as QR code payments) crowd out the resources required for high-risk transactions (such as large-amount transfers).

[0042] The solution proposed in this application is load type-aware differentiated scheduling.

[0043] Resource weights are dynamically allocated based on the risk control model type (face / behavior / device).

[0044] (III) Potential drawbacks of virtual machine cooperative scheduling schemes Technical Defect 1: The scheduling granularity is incompatible with the payment risk control scenario. Coordinated scheduling based on whole-machine virtual machines (such as VMware vMotion) results in coarse-grained scaling, which cannot adapt to the second-level elasticity requirements of risk control services. Virtual machine startup latency ≥ 1 minute vs. container startup latency < 2.5 seconds.

[0045] The solution proposed in this application is a containerized risk control microservice architecture.

[0046] The risk control engine is broken down into independent container groups (such as face detection container group and transaction analysis container group), which supports scaling by component granularity.

[0047] Technical Flaw 2: The two-level scheduling architecture exacerbates semantic fragmentation. A semantic gap exists between the Virtual Machine Monitor (VMM) and the guest operating system, causing the VMM to be unable to detect blocking events in risk control services (such as database query blocking), resulting in delayed resource allocation.

[0048] The solution proposed in this application is a host-level risk control event pass-through mechanism.

[0049] The system call events (such as database query delays) of the risk control container are captured by the eBPF program and then pushed to the scheduler in real time to trigger preventive scaling.

[0050] In this application embodiment, a resource adjustment method, apparatus, device, medium, and program product are proposed to solve the problem of poor system resource adjustment effect.

[0051] See Figure 1 , Figure 1 This is a flowchart of a resource adjustment method provided in an embodiment of this application, applied to a server, such as... Figure 1 As shown, the method includes the following steps: Step 101: Perform a risk assessment on the multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk.

[0052] It is understandable that the aforementioned servers can specifically be cloud computing nodes or container clusters, such as Kubernetes clusters, that deploy payment risk control services.

[0053] In this step, the aforementioned payment request can refer to a transaction instruction initiated by the user, such as a transfer, payment, or receipt of a red envelope.

[0054] The aforementioned risk assessment can be a process of analyzing the risks of each payment request based on relevant data and analytical models. For example, transaction behavior sequences, lightweight facial recognition models, and device fingerprint data can be integrated to assess the risk of each payment request and generate a comprehensive risk score.

[0055] The risk score mentioned above can be a numerical output, used to quantify the probability that a transaction carries risk. For example, 0 points represents complete confidence, while 100 points represents extreme risk.

[0056] Step 102: Determine the risk ratio based on the assessment results. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment requests are payment requests with a risk score greater than a first threshold.

[0057] In this step, the aforementioned first threshold can be a preset score limit. For example, if the first threshold is set to 80 points, payment requests with a score greater than 80 points will be judged as high-risk payment requests.

[0058] The above-mentioned risk ratio can be calculated as the ratio of the number of high-risk payment requests to the total number of payment requests.

[0059] Step 103: Expand or shrink the computing resources in the server based on the risk ratio, wherein the computing resources are computing resources used to process payment requests received by the server.

[0060] In this step, the aforementioned computing resources can be the computing power required to process payment requests. Understandably, in a cloud-native environment, this can be represented by the number of Pod replicas.

[0061] The aforementioned scaling up can involve increasing the number of Pod replicas to improve computing power supply. The aforementioned scaling down can involve reducing the number of Pod replicas to free up idle computing resources and reduce operating costs.

[0062] In this embodiment, multiple received payment requests are risk-assessed, and a risk ratio is determined. Based on the risk ratio, the computing resources in the server are expanded or reduced. During peak business periods, such as high transaction volume and low risk, although the transaction volume is high, the risk ratio is low, so the system determines that expansion is not necessary, and resource costs are controlled. Furthermore, when subjected to a small number of high-risk attacks, although the transaction volume is low, the risk ratio is high, so the system will trigger expansion to ensure that high computing power consumption attacks can be processed in a timely manner, thereby reducing the false negative rate and improving the system resource adjustment effect.

[0063] Optionally, the step of expanding or shrinking the computing resources in the server based on the risk ratio includes: If the risk ratio is greater than or equal to the second threshold, a first value is determined based on the number of Pod replicas of the computing power resources, and the number of Pod replicas of the computing power resources is increased to the first value; The method further includes: If the risk ratio calculated for K consecutive times is less than the second threshold, the number of Pod replicas of the computing power resource is reduced to a second value, which is less than the number of Pod replicas of the computing power resource.

[0064] Specifically, the aforementioned second threshold can be a preset numerical limit used to trigger a capacity expansion operation. It is understood that when the risk ratio is greater than or equal to the second threshold, the system can determine that capacity expansion is currently necessary to reduce the false negative rate.

[0065] Understandably, in containerized platforms like Kubernetes, a Pod is the smallest unit for running risk control services. The number of Pod replicas mentioned above could refer to the number of currently running risk control engine instances.

[0066] The first value mentioned above can be the target number of Pod replicas, used to indicate the total number of expected Pod replicas after scaling.

[0067] The above K is a preset positive integer, for example, K can be 3 or 5.

[0068] The second value mentioned above can be the target number of Pod replicas after scaling down. The second value can be determined based on a preset scaling down model or algorithm, such as gradually reducing it by a certain percentage, or predicting a minimum value based on historical load as the second value.

[0069] In this implementation, when the risk ratio is greater than or equal to the second threshold, a first value is determined based on the number of Pod replicas of the computing power resources, and the number of Pod replicas of the computing power resources is increased to the first value, so as to ensure the accuracy of resource increment.

[0070] Furthermore, since the risk ratio fluctuates in real time, it may suddenly decrease due to network jitter. If the risk ratio calculated for K consecutive times is less than the second threshold, the number of Pod replicas of the computing power resources will be reduced to the second value. This can avoid the system from frequently scaling up and down, thereby improving stability and reducing operating costs.

[0071] Optionally, determining the first value based on the number of Pod replicas of the computing power resources includes: The ratio of the stated risk ratio to the preset risk ratio is determined as a first ratio. A first value is determined based on the first ratio and the number of Pod replicas.

[0072] Specifically, the aforementioned preset risk ratio can be a preset target value, which can be used to characterize the ideal risk ratio that the system expects to maintain. It can be understood that if the risk ratio is less than the preset risk ratio, the current resource allocation can be considered to be effective and no adjustment is needed.

[0073] Based on the first ratio and the number of Pod replicas, the first value can be determined by multiplying the first ratio and the number of Pod replicas and then rounding up to obtain the first value.

[0074] For example, the formula for calculating the first value can be: First value = ceil(current number of Pod replicas × (risk ratio / preset risk ratio)).

[0075] In this implementation, a first ratio is determined by the ratio of the risk ratio to the preset risk ratio, and a first value is determined based on the first ratio and the number of Pod replicas, so that the expansion range is proportional to the degree of risk exceeding the limit, thereby ensuring the accuracy of resource increment and reducing resource waste.

[0076] Optionally, the evaluation result also includes the risk type corresponding to each payment request, wherein the risk type is one of at least two preset risk types, and determining the first value based on the number of Pod replicas of the computing power resources includes: Based on the evaluation results, the number of payment requests corresponding to each of the at least two preset risk types is determined, wherein the number of payment requests corresponding to the first risk type is the number of payment requests among the plurality of payment requests that have the risk of the first risk type, and the first risk type is any one of the at least two preset risk types; The weighted risk load value is calculated based on the number of payment requests corresponding to each preset risk type, the risk weight corresponding to each preset risk type, and the total number of multiple payment requests. The ratio of the weighted risk load value to the preset weighted risk load value is determined as the second ratio. The first value is determined based on the second ratio and the number of Pod replicas.

[0077] Specifically, the aforementioned risk types can be specific classification labels for the risk sources or risk patterns of payment requests, such as device fingerprint forgery, facial recognition attacks, abnormal behavior sequences, and large-sum transfer fraud.

[0078] The above-mentioned at least two preset risk types can be a predefined set of risk categories. It is understood that the risk category set is a configurable and extensible set that can be updated based on actual needs.

[0079] The number of payment requests corresponding to each of the above preset risk types can be the number of transactions marked as the corresponding specific risk type among the multiple payment requests.

[0080] The aforementioned risk weights can be pre-assigned numerical coefficients for each risk type, primarily used to quantify the relative amount of computing resources required to process payment requests for the corresponding risk type.

[0081] For example, assuming the weight corresponding to device fingerprint forgery is 1.0 and the weight corresponding to face synthesis attack is 3.5, it can be understood that the computing power consumption for processing 1 face synthesis transaction is equivalent to the computing power consumption for processing 3.5 device forgery transactions.

[0082] The total number of requests mentioned above can be the number of payment requests among the multiple payment requests.

[0083] The aforementioned weighted risk load value can be the ratio of the first value to the total number of multiple payment requests. The first value is the sum of the products of the number of payment requests corresponding to each preset risk type and the corresponding risk weight. The aforementioned weighted risk load value can be used to characterize the total computing power demand intensity of the current multiple payment requests.

[0084] For example, the formula for calculating the weighted risk load value can be: Weighted risk load value = Σ(number of payment requests for each risk type × corresponding risk weight) / total number of requests.

[0085] It should be noted that the above-mentioned weighted risk load value can be calculated based on a preset algorithm or a preset weight mapping model. The risk weights in the weight mapping model can be configured based on specific needs.

[0086] The aforementioned preset weighted risk load value can be a preset target value, which can be used to characterize the ideal weighted risk load value that the system expects to maintain. For example, it can be 5%, which corresponds to a 5% load rate, to reserve sufficient performance buffer.

[0087] For example, the formula for calculating the first value can be: First value = ceil(current number of Pod replicas × (current weighted risk load value / preset weighted risk load value)).

[0088] In this implementation, by setting risk weights for each preset risk type, different preset risk types can be distinguished during the calculation process. This allows resource scheduling decisions to be based on actual computing power needs, thereby triggering sufficient capacity expansion to ensure the acquisition of necessary computing resources and reduce unnecessary computing resources. This, in turn, improves resource utilization and reduces false alarm rate.

[0089] Furthermore, since risk weights can be configured and dynamically updated based on specific circumstances and needs, the corresponding risk weights can be adjusted according to business strategies. For example, the weight corresponding to large-amount transfer fraud can be increased during critical periods to make the system more sensitive to this type of risk. The weights of the facial recognition model can also be updated based on algorithm iterations, enabling the scheduling system to adapt to constantly changing business needs and attack methods, thereby improving the system's security.

[0090] Optionally, before calculating the weighted risk load value based on the number of payment requests corresponding to each preset risk type, the risk weight corresponding to each preset risk type, and the total number of payment requests, the method further includes: A computing power test is performed on the preset baseline request type and the payment request corresponding to each preset risk type to determine the computing power consumption value of the baseline request type and each preset risk type; The risk weight corresponding to each preset risk type is determined based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type.

[0091] Specifically, the aforementioned benchmark request type can be selected from the system as the request type with the lowest computational complexity and the most representative nature. For example, a request for a pure rule verification (such as a monetary threshold judgment) can be set as the benchmark, and its weight can be defined as 1.0.

[0092] The aforementioned computing power test can be conducted in an independent test environment to perform performance profiling on various risky requests that require defined weights. On Pods with the same hardware specifications, performance analysis tools can be used to statistically analyze the core resource consumption when processing a single type of request.

[0093] The aforementioned computing power consumption value can be a numerical value obtained through computing power testing, quantifying the computing resources required to process a single request. For example, it can specifically include the following metrics: CPU time: The CPU time consumed in processing a single request (e.g., obtained through ptrace or APM toolchain). Memory bandwidth or usage: the rate or peak usage of memory allocation during request processing; External call latency: such as the time spent calling external services like facial recognition APIs and blockchain explorers.

[0094] The risk weight corresponding to each of the above-mentioned preset risk types can be the computing power consumption ratio of the preset risk type, or it can be a weight value obtained by fine-tuning other business factors based on the computing power consumption ratio. Specifically, the computing power consumption ratio of the preset risk type can be the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type. For example, the computing power consumption ratio of request type A = the average CPU time (or total time) of request type A / the average CPU time (or total time) of the baseline request.

[0095] In this implementation, since the risk weight corresponding to each preset risk type is determined based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type, that is, the risk weight is determined based on the ratio of computing power consumption values, which is a relative ratio rather than an absolute value. This ensures that when the system configuration changes, even if the absolute processing time of the payment request changes, the relative computing power consumption ratio between different request types usually remains stable, thus eliminating the need for extensive parameter tuning and reducing operating costs.

[0096] Optionally, determining the risk weight corresponding to each preset risk type based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type includes: Determine the priority weight corresponding to the first risk type, wherein the priority weight is used to characterize the priority of the first risk type; Based on the ratio of the computing power consumption value of the first risk type to the computing power consumption value of the baseline request type, and the priority weight corresponding to the first risk type, the risk weight corresponding to the first risk type is obtained.

[0097] Specifically, the aforementioned priority weights can be configurable business factors that quantify the priority of specific risk types in terms of business value or security importance. These weights can be set according to the business scenario; for example, transaction types involving higher financial risks, such as large-amount transfers and cross-border payments, may be assigned higher priority weights.

[0098] The risk weight corresponding to the first risk type is obtained by taking the ratio of the computing power consumption value of the first risk type to the computing power consumption value of the baseline request type, and the priority weight corresponding to the first risk type. This can be done by directly multiplying the ratio and the priority weight corresponding to the first risk type as the risk weight corresponding to the first risk type, or by multiplying the priority weight corresponding to the first risk type and a preset value and the ratio as the risk weight corresponding to the first risk type. The preset value can be 1, 2, or other positive numbers.

[0099] It is understandable that, when the ratio of the computing power consumption value of the first risk type to the computing power consumption value of the baseline request type is the same, the greater the priority weight, the greater the risk weight corresponding to the first risk type.

[0100] For example, as shown in Table 1 below: Table 1 To illustrate with specific business examples, during major promotional periods, the priority of risk types such as flash sales and limited-time offers can be increased to ensure a better transaction experience. Alternatively, during critical periods, the priority of risk types such as large-amount transfers and cross-border payments can be increased to ensure fund security.

[0101] In this implementation, the risk weight corresponding to the first risk type is obtained based on the ratio of the computing power consumption value of the first risk type to the computing power consumption value of the baseline request type, and the priority weight corresponding to the first risk type. This allows the risk weight to be adjusted based on the priority weight, thereby improving the flexibility of resource adjustment by flexibly changing the resource adjustment strategy by adjusting the priority weight of different risk types without modifying the code or retesting the computing power.

[0102] Optionally, the method further includes: The payment requests corresponding to each preset risk type are monitored in real time to obtain the actual processing time of each preset risk type within a preset period. Based on the actual processing time of payment requests corresponding to each preset risk type within the preset period, the risk weight corresponding to each preset risk type is updated.

[0103] Specifically, the payment request corresponding to each of the above-mentioned preset risk types can be understood as a payment request for a risk that has a corresponding preset risk type, or it can refer to the payment request that corresponds one-to-one with the preset risk type as indicated in the assessment results.

[0104] The aforementioned real-time monitoring can refer to the continuous collection and recording of performance data related to the processing of various risk requests.

[0105] The aforementioned preset period can be a pre-set time window, such as a period of 7 days or 30 days.

[0106] The actual processing time mentioned above can be the real time elapsed from when the server receives the payment request to when the final processing is completed. It is understood that the actual processing time may vary due to factors such as changes in data distribution, model updates, and fluctuations in hardware performance.

[0107] The risk weight corresponding to each preset risk type is updated based on the actual processing time of the payment request corresponding to each preset risk type within the preset period. This can be achieved by using newly collected actual processing time data to calculate a new risk weight and replace the old risk weight.

[0108] For example, the above specific implementation can be accomplished through a timed automated script or job. The script first retrieves the average processing time of each risk type in the most recent period from the monitoring system, then recalculates the computing power consumption ratio of each risk type using the average processing time of the baseline request type as the denominator, and finally updates the new weights to the weight mapping table.

[0109] In this implementation, the risk weight is updated periodically based on the actual processing time, so that the risk weight can be automatically updated to keep up with the actual situation, maintain an accurate reflection of the actual computing power consumption, and avoid resource scheduling deviations caused by inaccurate weights.

[0110] For example, Figure 2 This is one of the business process diagrams of a resource adjustment method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: Step 1: Real-time collection and exposure of risk control indicators 1. Execution Node: Each payment request is executed immediately after the risk control engine completes the risk analysis. This is a continuous streaming process.

[0111] 2. Execution scenario: Completed within the risk control engine Pod deployed in a Kubernetes cluster.

[0112] 3. Implementation Mode: (1) Multimodal risk analysis: The risk control engine integrates transaction behavior sequences, lightweight face recognition models and device fingerprint data to conduct risk assessment on each transaction and generate a comprehensive risk score (0-100) and risk type (e.g., fraud_behavior, fake_face, device_emulator).

[0113] (2) Indicator calculation and exposure: A PrometheusClientLibrary is integrated within the risk control engine.

[0114] ① Define a custom metric current_risk_score, whose value is the risk score of the latest transaction.

[0115] ② Define a counter high_risk_transaction_total, which increments by 1 whenever the score exceeds the high-risk threshold (e.g., 80).

[0116] ③ The risk control engine provides an HTTP endpoint (such as / metrics) for the Prometheus server to retrieve the aforementioned custom metric data.

[0117] Step Two: Risk Indicator Aggregation and Conversion 1. Execution Node: The Prometheus server periodically pulls data from the / metrics endpoint of all risk control engine Pods according to a preset fetch interval (e.g., 15 seconds).

[0118] 2. Execution scenario: Completed on a standalone Prometheus server.

[0119] 3. Implementation Mode: (1) Data aggregation: Prometheus collects indicator data from all risk control engine instances.

[0120] (2) Indicator Conversion: Through PromQL query statements, the core indicator used for scheduling decisions, namely the high-risk ratio, is calculated in real time, for example: #Calculate the percentage of high-risk trades in the total number of trades over the past minute. high_risk_ratio= sum(rate(high_risk_transaction_total[1m])) / sum(rate(all_transactions_total[1m])) (3) Expose API: Deploy the prometheus-adapter component, which converts the above PromQL query results into a custom metric API (custom.metrics.k8s.io / v1beta1) that KubernetesHPA can recognize, and exposes the high_risk_ratio metric.

[0121] Step 3: Elastic scheduling decision (the elastic scheduler decides whether to scale up or down based on the risk ratio) 1. Execution Node: The HPA controller queries the Kubernetes API every cycle (default 15 seconds) to obtain the specified custom metric value.

[0122] 2. Execution scenario: Completed in the HPAController component of the Kubernetes Master node.

[0123] 3. Implementation method: (1) Define HPA objects: Instead of creating HPA for CPU / memory, create HPA for the high_risk_ratio metric.

[0124] (2) Decision-making logic: Decision algorithm: HPAController continuously compares the current actual high_risk_ratio (e.g., 0.08) with the target value (0.05).

[0125] Formula for calculating the expected number of replicas: Expected number of replicas = ceil(current number of replicas × (current metric value / target metric value)); For example, substituting into the formula: expected number of replicas = ceil(10×(0.08 / 0.05)) = ceil(16) = 16, therefore, HPA will calculate that the number of Pod replicas of the risk control engine needs to be increased from 10 to 16.

[0126] Step 4: Execution of scheduling instructions and resource allocation (the executor (K8sAPIServer) adjusts the number of risk control engine Pod replicas) 1. Execution Node: Once the HPAController makes a decision, it is executed immediately.

[0127] 2. Execution scenario: Completed in the Kubernetes API Server.

[0128] 3. Implementation method: (1) HPAController calls the Kubernetes API to modify the replicas field of the Deployment object corresponding to the risk control engine.

[0129] (2) Resource allocation: The Kubernetes scheduler detects changes in the number of Pod replicas and, based on resource availability, schedules the newly added Pod to a node with sufficient CPU or memory and starts the container. Within approximately 10-30 seconds, the new risk control engine Pod can start up and register with the load balancer, begin processing traffic, improve risk control processing capabilities, and bring the proportion of high-risk transactions back to near the target value.

[0130] For example, assuming that transactions with a risk score ≥ the threshold (e.g., 80 points) are uniformly classified as "high risk", then out of 1000 transactions, 950 transactions with "device forgery" (risk 85 points) and 50 transactions with "face synthesis" (risk 95 points) are all judged as high risk. Therefore, the high risk ratio = (950 + 50) / 1000 = 100%.

[0131] Assuming HPA is pre-set to have a "high-risk ratio ≤ 5% under normal load" (i.e., a target load rate of 5%, corresponding to a maximum computing power consumption of 0.05 units per transaction per Pod), when the actual high-risk ratio reaches 100%, HPA will scale up based on the number of transactions. Expansion ratio = Actual high-risk ratio / Target ratio = 100% / 5% = 20 times; If the initial cluster has 10 Pods, it will eventually expand to 10 × 20 = 200 Pods.

[0132] Figure 3 This is a second business process diagram of a resource adjustment method provided in an embodiment of this application, such as... Figure 3 As shown, it includes the following steps: Step 1: Risk Data Reporting and Tagging 1. Execution Node: Execute immediately after the risk control engine completes the risk analysis of a transaction (this is a continuous, real-time streaming process).

[0133] 2. Execution scenario: Completed within the risk control engine service deployed in a Kubernetes Pod.

[0134] 3. Implementation method: (1) After processing a transaction, the risk control engine not only generates a risk score, but also determines the risk type.

[0135] (2) When exposing metrics through PrometheusClientLibrary, add a label named risk_type to the metrics.

[0136] Step 2: Calculation of Weighted Indicators 1. Execution node: After the rometheus server fetches the raw metrics at the configured fetch interval (e.g., 15 seconds), it calculates them in real time when the HPA controller queries the custom metrics API.

[0137] 2. Execution Scenario: This is accomplished within the Prometheus-adapter component. This component is deployed within the cluster and is responsible for converting PromQL queries into a format that the Kubernetes API can understand.

[0138] 3. Implementation method: (1) The PromQL query statement for calculating weighted risk is pre-configured in the Prometheus-adapter.

[0139] (2) This statement will query the risk_transaction_total indicator and group and weight the sum according to its risk_type label.

[0140] Processing method: Weighted risk load = Σ(Number of times for each risk type × corresponding weight) / Total number of transactions; For example, in 1000 transactions, 10 are "fake_face" (weight 3.0) and 20 are "fraud_behavior" (weight 1.5), then the weighted risk load = (10*3.0+20*1.5) / 1000 = 0.06.

[0141] Step 3: Differentiated scaling up / down decision 1. Execution Node: Every time the HPA controller makes a scaling up or down decision cycle (default 15 seconds).

[0142] 2. Execution scenario: Completed in the HPAController component of the Kubernetes Master node.

[0143] 3. Implementation method: (1) HPAController queries the custom metrics API and obtains the weighted_risk_load metric calculated in the previous step, instead of the original simple count.

[0144] (2) The subsequent decision-making process is exactly the same as the standard HPA: expected number of replicas = ceil(current number of replicas * (current weighted risk load / target weighted risk load)).

[0145] (3) Since the input indicators are already weighted values, HPA can make more accurate decisions without any modifications.

[0146] It is understood that the above-described embodiments have the following technical effects: (1) Extremely refined resource allocation: The business semantics ("This is a high-consumption risk type") are directly converted into technical instructions, avoiding the problem of low-priority tasks crowding out high-priority task resources.

[0147] (2) Maximizing cost-effectiveness: Every computing resource is used effectively, and at the same cost, compared to Figure 2 The proposed solution is more effective at dealing with attack types that truly consume resources.

[0148] (3) Dynamically adjustable: Operation and maintenance personnel can adjust the risk weight corresponding to each risk type in real time according to business changes and attack trends, making the strategy extremely flexible.

[0149] Specifically, the core of the above solution is to quantify the differences in computing power consumption of different attacks through weighting coefficients, allowing HPA to scale based on the actual computing power load rather than the number of transactions, ultimately achieving precise resource matching and zero missed detection of core risks. The specific logic is as follows: ① Weighting coefficient setting: Scientific mapping based on computing power consumption ratio The setting of the weight mapping table (risk_weight_map) in the weight mapping model is the core of this solution to achieve precise scheduling. Its assignment does not rely on empirical estimation, but is based on a scientific and quantifiable method for calculating the ratio of computing power consumption.

[0150] The specific steps are as follows: a. Benchmarking and Quantification of Computing Power Consumption: Establish a baseline request type: Select the request type with the lowest computational complexity and the most representative nature as the baseline. For example, set a request for pure rule validation (such as determining a monetary threshold) as the baseline and define its weight as 1.0.

[0151] Performance Profiling and Measurement: In an independent test environment, performance profiling is performed on various risky requests requiring defined weights. On Pods with the same hardware specifications, performance analysis tools are used to statistically analyze the core resource consumption when processing a single type of request. CPU time: The CPU time consumed in processing a single request (e.g., obtained through ptrace or APM toolchain).

[0152] Memory bandwidth or usage: The rate or peak usage of memory allocation during request processing.

[0153] External call latency: such as the time spent calling external services like facial recognition APIs and blockchain explorers.

[0154] Calculate the computing power consumption ratio: Using the computing power consumption of the baseline request as the denominator, calculate the relative computing power consumption ratio of other request types.

[0155] The computing power consumption ratio of request type A = the average CPU time (or total time) of request type A / the average CPU time (or total time) of the baseline request.

[0156] b. Weight assignment and normalization: The calculated computing power consumption ratio is directly used as the initial value of the weight coefficient. For example, if the baseline request takes 5ms, while the average time for a request with the risk type "face recognition" is 75ms, then the initial weight of "face recognition" = 75 / 5 = 15.0.

[0157] Furthermore, the importance of business operations can be fine-tuned: in some scenarios, the importance of business operations may need to be weighted on top of pure computing power.

[0158] Final weight confirmation: Update the fine-tuned weight values ​​to risk_weight_map.

[0159] c. Dynamic feedback and optimization: The weight mapping model is not static; the system continuously monitors the actual processing time of each risk request in the production environment. Using this monitoring data, the computing power consumption ratio can be recalculated periodically (e.g., monthly) to iteratively optimize and calibrate the weight mapping table, ensuring it always accurately reflects the current computing power requirements. This process can be completed through a simple operation and maintenance script or automated job, achieving continuous optimization and self-learning of the weights.

[0160] After the calculations described above, under the same Pod configuration (2 cores, 4GB RAM), process 1000 cases of "device spoofing" and "face synthesis" respectively, and calculate the average processing time and computing power consumption: Weight mapping table: Device forgery = 1.0 (base unit), face synthesis = 3.5 (computing power consumption ratio), ensuring that the weights are strongly bound to the actual computing power requirements.

[0161] ② Weighted load calculation: Reproducing the actual computing power pressure Computational logic: The essence of weighted load balancing is to convert the computing power requirements of different attacks into a unified benchmark unit (device forgery) in order to quantify the overall computing power pressure. Total weighted computing power requirement = (number of device forgeries × weight) + (number of face synthesis attempts × weight) = 950 × 1.0 + 50 × 3.5 = 950 + 175 = 1125 units; Weighted load = Total weighted computing power requirement / Total number of transactions = 1125 / 1000 = 1.125.

[0162] It should be noted that 1.125 does not represent "112.5% ​​of the high-risk transactions," but rather "the total computing power requirement for 1,000 transactions is equivalent to the computing power requirement for 1,125 forged transactions." In other words, this value directly reflects "the actual computing power pressure that the cluster needs to bear," rather than the apparent quantity.

[0163] ③ Precise HPA Expansion: Targeted Scheduling Based on "Computing Power Multiplier" Scaling logic: HPA still uses "target load rate 5% (average computing power requirement per transaction ≤ 0.05 units)" as the benchmark. At this time, the scaling factor needs to be calculated based on "weighted load / target load". Expansion ratio = Weighted load / Target load = 1.125 / 0.05 = 22.5 times; The initial number of Pods is 10, and the final number of Pods is ceil(10×22.5)=225 (wherein, the ceil function ensures that the number of Pods is an integer to avoid insufficient computing power).

[0164] The accuracy is reflected in the fact that the total computing power supply of 225 Pods = 225 × 5 = 1125 units, which perfectly matches the "actual computing power requirement of 1125 units", without being redundant or wasteful, or insufficient.

[0165] ④ Efficient resource allocation: "Dual coverage" of low-computing power and high-computing power attacks. Parallel processing capability: After 225 Pods are started, resources can be dynamically allocated according to "computing power requirements": Low-computing-power task: 950 device forgeries require 950 units of computing power, but can be processed in 1 minute with only 190 Pods (950 / 5=190).

[0166] High-computing-power task: 50 face synthesis requires 175 units of computing power. The remaining 35 Pods (225-190=35) can be processed within 1 minute (175 / 35=5 units / Pod, just at full load).

[0167] Business assurance: All transactions are processed within the time limit, the false negative rate of face synthesis is reduced to 0%, and low computing power tasks are prevented from competing for high computing power resources, so as to ensure that no risks are missed and no resources are idle.

[0168] ⑤ Optimal resource utilization: a balance between cost and risk Utilization quantification: Total computing power supply of 225 Pods = 1125 units, actual consumption = 1125 units, nominal utilization = 100%, effective utilization = 100%, meaning there are no idle resources and no need to expand for invalid quantities (compared to adopting...). Figure 2 The corresponding solution yielded 200 Pods, which is 25 more than the original solution, but it fully covered the core risks, and the increased cost was far less than the loss from missed detections.

[0169] Long-term value: The weighting coefficient can be dynamically iterated (e.g., if the black market upgrades its face synthesis technology, causing the computing power consumption to increase to 4.0 units, the weight can be updated to 4.0 simultaneously), ensuring that HPA is always scheduled based on the latest computing power demand, achieving the optimal balance between risk control effect and resource cost.

[0170] Of the 225 Pods added, 190 handle "device spoofing" payment requests (950 tasks, which may take 15 minutes to complete), and 35 handle "face synthesis" payment requests (50 high-computing tasks, which may take 30 minutes).

[0171] It should be noted that in this situation, there are only two possibilities for the item being idle: In the first 15 minutes: 190 low-risk Pods will be temporarily idle after completing their tasks, but 35 high-risk Pods will still be running at full capacity (core requirements will not be stopped). 30 minutes later: All tasks were completed, and all 225 Pods were idle. However, this idleness is a normal state after the tasks are completed, rather than a resource mismatch.

[0172] This kind of idleness is short-term and controllable, and is on the premise that the core risks have been resolved (100% face compositing processing), which is a reasonable cost after the core objectives have been achieved.

[0173] To verify the significant advancements of this solution compared to related technologies, a comparative experiment was designed to simulate mixed attack traffic in a real payment scenario (including a large number of low-computing-power attacks and a small number of high-computing-power attacks).

[0174] Experimental group: The scheduling scheme based on computing power demand (risk-weighted load) of this application is adopted.

[0175] Comparative example: The mainstream elastic scheduling scheme based on transaction volume is adopted in related technologies.

[0176] The specific comparison results are shown in Table 2 below: Table 2 Experimental conclusion analysis: Although the comparative model maintained a high resource utilization rate, a large amount of its resources were consumed in processing low-value, low-risk simple requests, resulting in insufficient protection against high-computing-power attacks (high false negative rate), which is a highly efficient error.

[0177] This application achieves more efficient resource utilization because it precisely allocates computing power to the most demanding workloads, thereby significantly reducing costs while substantially improving risk control and response speed. This dual positive benefit of reducing costs and improving efficiency is something that traditional quantity-based scheduling schemes simply cannot achieve, fully demonstrating the non-obvious technical effects of this application.

[0178] Compared with elastic scheduling schemes based on infrastructure metrics (such as CPU utilization) or simple business metrics (such as transaction volume) in related technologies, this application has the following technical advantages: (i) It has achieved a high-precision match between resource supply and actual business needs, fundamentally solving the problem of resource mismatch: Technical advantages: This application completely eliminates the phenomenon of both oversupply and undersupply in resource allocation. The system can dynamically allocate sufficient resources to risky transactions with high computing load, while avoiding over-allocation of resources to transactions with low computing load, thereby achieving optimal resource utilization while ensuring business security.

[0179] Implementation Method: This application abandons traditional metrics that are disconnected from business logic, and uses risk-weighted load as the core decision-making basis for elastic scheduling. This metric accurately quantifies the real-time computing needs of the risk control system by applying different weight coefficients to different risk types (such as facial recognition and behavioral analysis). The scheduler makes decisions based on this metric, ensuring that the extent of scaling up and down strictly corresponds to the actual consumption of the business.

[0180] (ii) It significantly reduced the underreporting rate of high-risk transactions, thereby improving the security and reliability of the payment system: Technical advantages: During peak trading periods or when targeted attacks occur, the system can prioritize the computing resources required for complex risk control models (such as facial recognition) to ensure their timely execution. This significantly reduces the risk of missed transactions or analysis timeouts caused by resource contention, directly enhancing the system's anti-fraud capabilities.

[0181] Implementation: The aforementioned advantages are due to the application of a differentiated weighting mapping model, which assigns higher weights to high-computational-cost risk types (such as "face synthesis"). When the proportion of such transactions increases, even if the total transaction volume remains unchanged, the risk-weighted load index will increase significantly, thereby triggering the scheduler to expand its capacity more substantially, reserving dedicated resources to process these high-value, high-cost transactions and preventing them from starving in the queue.

[0182] (iii) It improved the overall throughput and stability of the system, avoiding sharp performance drops and avalanche effects: Technical advantages: The system can maintain a stable high throughput without experiencing a sharp drop in overall performance when processing computationally intensive transactions. At the same time, the system's resilience is enhanced, enabling it to better absorb traffic surges and cope with performance fluctuations, effectively preventing cascading failures caused by excessive load.

[0183] Implementation method: This application creates sufficient performance buffer margin for the system by setting and maintaining a low target load rate (e.g., 5%). This margin is specifically used to absorb the additional load from computationally intensive transactions and handle burst traffic, ensuring stable and low-latency system response time.

[0184] (iv) It provides more granular system monitoring and insight capabilities, realizing the transformation from black box to white box: Technical advantages: Operations personnel can obtain a single, aggregated golden indicator that directly reflects the core status of the business (risk control pressure), rather than observing multiple technical indicators such as CPU, network, and transaction volume in isolation, which greatly simplifies the process of locating performance bottlenecks and analyzing root causes.

[0185] Implementation method: This advantage stems from the closed-loop feedback architecture constructed in this application. The indicator converter in this architecture continuously combines the business tags (risk types) output by the risk control engine with the weight mapping table, calculating and exposing the "risk-weighted load" indicator in real time. This allows any changes to resources to be directly correlated with business events (such as a surge in attacks), providing business visibility for operations and maintenance.

[0186] See Figure 4 , Figure 4 This is a schematic diagram of the structure of a resource adjustment device provided in an embodiment of this application, as shown below. Figure 4 As shown, the resource adjustment device 400 includes: The evaluation module 401 is used to perform risk assessment on multiple payment requests received by the server and obtain an evaluation result. The evaluation result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. The determination module 402 is used to determine the risk ratio based on the evaluation result. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment request is the payment request whose risk score is greater than a first threshold. The processing module 403 is used to expand or shrink the computing resources in the server based on the risk ratio, wherein the computing resources are computing resources used to process payment requests received by the server.

[0187] Optionally, the processing module 403 includes: The determining unit is configured to, when the risk ratio is greater than or equal to a second threshold, determine a first value based on the number of Pod replicas of the computing power resources, and expand the number of Pod replicas of the computing power resources to the first value; The device further includes: The scaling-down module is used to reduce the number of Pod replicas of the computing power resource to a second value when the risk ratio calculated for K consecutive times is less than the second threshold. The second value is less than the number of Pod replicas of the computing power resource.

[0188] Optionally, the determining unit is specifically used for: The ratio of the stated risk ratio to the preset risk ratio is determined as a first ratio. A first value is determined based on the first ratio and the number of Pod replicas.

[0189] Optionally, the evaluation result also includes the risk type corresponding to each payment request, wherein the risk type is one of at least two preset risk types, and the determining unit is specifically used for: Based on the evaluation results, the number of payment requests corresponding to each of the at least two preset risk types is determined, wherein the number of payment requests corresponding to the first risk type is the number of payment requests among the plurality of payment requests that have the risk of the first risk type, and the first risk type is any one of the at least two preset risk types; The weighted risk load value is calculated based on the number of payment requests corresponding to each preset risk type, the risk weight corresponding to each preset risk type, and the total number of multiple payment requests. The ratio of the weighted risk load value to the preset weighted risk load value is determined as the second ratio. The first value is determined based on the second ratio and the number of Pod replicas.

[0190] Optionally, the determining unit is further configured to: A computing power test is performed on the preset baseline request type and the payment request corresponding to each preset risk type to determine the computing power consumption value of the baseline request type and each preset risk type; The risk weight corresponding to each preset risk type is determined based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type.

[0191] Optionally, determining the risk weight corresponding to each preset risk type based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type includes: Determine the priority weight corresponding to the first risk type, wherein the priority weight is used to characterize the priority of the first risk type; Based on the ratio of the computing power consumption value of the first risk type to the computing power consumption value of the baseline request type, and the priority weight corresponding to the first risk type, the risk weight corresponding to the first risk type is obtained.

[0192] Optionally, the device further includes: The monitoring module is used to monitor the payment requests corresponding to each preset risk type in real time and obtain the actual processing time of the payment requests corresponding to each preset risk type within a preset period. The update module is used to update the risk weight corresponding to each preset risk type based on the actual processing time of the payment request corresponding to each preset risk type within the preset period.

[0193] It should be noted that the resource adjustment device provided in this application embodiment is a device capable of executing the above-described resource adjustment method. Therefore, all implementation methods in the above-described resource adjustment method embodiments are applicable to this device and can achieve the same or similar beneficial effects. To avoid repetition, this embodiment will not elaborate further.

[0194] For details, see Figure 5 As shown in the figure, this application embodiment also provides an electronic device, including a bus 501, a transceiver 502, an antenna 503, a bus interface 504, a processor 505, and a memory 506.

[0195] Processor 505, used for: A risk assessment is performed on multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. Based on the assessment results, a risk ratio is determined. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment request is the payment request whose risk score is greater than a first threshold. The computing resources in the server are expanded or reduced based on the risk ratio, wherein the computing resources are used to process payment requests received by the server.

[0196] exist Figure 5In this document, a bus architecture (represented by bus 501) is used. Bus 501 can include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 505 and memory represented by memory 506. Bus 501 can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 504 provides an interface between bus 501 and transceiver 502. Transceiver 502 can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 505 is transmitted over a wireless medium via antenna 503, which further receives data and transmits it to processor 505.

[0197] Processor 505 manages bus 501 and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 506 can be used to store data used by processor 505 during operation.

[0198] Optionally, the processor 505 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD).

[0199] It should be noted that the electronic device provided in this application embodiment is a device capable of executing the above-described resource adjustment method. Therefore, all implementations of the above-described resource adjustment method embodiments are applicable to this electronic device and can achieve the same or similar beneficial effects. To avoid repetition, this embodiment will not elaborate further.

[0200] This application also provides an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the various processes of the above-described resource adjustment method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0201] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the resource adjustment method embodiments described above and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0202] This application also provides a computer program product, including computer instructions. When executed by a processor, these computer instructions implement the various processes of the above-described resource adjustment method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0203] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0204] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0205] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A resource adjustment method, applied to a server, characterized in that, The method includes: A risk assessment is performed on multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. Based on the assessment results, a risk ratio is determined. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment request is the payment request whose risk score is greater than a first threshold. The computing resources in the server are expanded or reduced based on the risk ratio, wherein the computing resources are used to process payment requests received by the server.

2. The method according to claim 1, characterized in that, The process of expanding or shrinking the computing resources in the server based on the risk ratio includes: If the risk ratio is greater than or equal to the second threshold, a first value is determined based on the number of Pod replicas of the computing power resources, and the number of Pod replicas of the computing power resources is increased to the first value; The method further includes: If the risk ratio calculated for K consecutive times is less than the second threshold, the number of Pod replicas of the computing power resource is reduced to a second value, which is less than the number of Pod replicas of the computing power resource.

3. The method according to claim 2, characterized in that, The determination of the first value based on the number of Pod replicas of the computing power resources includes: The ratio of the stated risk ratio to the preset risk ratio is determined as a first ratio. A first value is determined based on the first ratio and the number of Pod replicas.

4. The method according to claim 2, characterized in that, The evaluation result also includes the risk type corresponding to each payment request, wherein the risk type is one of at least two preset risk types, and the determination of the first value based on the number of Pod replicas of the computing power resources includes: Based on the evaluation results, the number of payment requests corresponding to each of the at least two preset risk types is determined, wherein the number of payment requests corresponding to the first risk type is the number of payment requests among the plurality of payment requests that have the risk of the first risk type, and the first risk type is any one of the at least two preset risk types; The weighted risk load value is calculated based on the number of payment requests corresponding to each preset risk type, the risk weight corresponding to each preset risk type, and the total number of multiple payment requests. The ratio of the weighted risk load value to the preset weighted risk load value is determined as the second ratio. The first value is determined based on the second ratio and the number of Pod replicas.

5. The method according to claim 4, characterized in that, Before calculating the weighted risk load value based on the number of payment requests corresponding to each preset risk type, the risk weight corresponding to each preset risk type, and the total number of payment requests, the method further includes: A computing power test is performed on the preset baseline request type and the payment request corresponding to each preset risk type to determine the computing power consumption value of the baseline request type and each preset risk type; The risk weight corresponding to each preset risk type is determined based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type.

6. The method according to claim 5, characterized in that, The method of determining the risk weight corresponding to each preset risk type based on the ratio of the computing power consumption value of the preset risk type to the computing power consumption value of the baseline request type includes: Determine the priority weight corresponding to the first risk type, wherein the priority weight is used to characterize the priority of the first risk type; Based on the ratio of the computing power consumption value of the first risk type to the computing power consumption value of the baseline request type, and the priority weight corresponding to the first risk type, the risk weight corresponding to the first risk type is obtained.

7. The method according to claim 5 or 6, characterized in that, The method further includes: The payment requests corresponding to each preset risk type are monitored in real time to obtain the actual processing time of each preset risk type within a preset period. Based on the actual processing time of payment requests corresponding to each preset risk type within the preset period, the risk weight corresponding to each preset risk type is updated.

8. A resource adjustment device, applied to a server, characterized in that, The device includes: An evaluation module is used to perform risk assessment on multiple payment requests received by the server and obtain an evaluation result. The evaluation result includes a risk score for each payment request among the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. The determination module is used to determine the risk ratio based on the assessment results. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment requests are payment requests whose risk scores are greater than a first threshold. The processing module is used to expand or shrink the computing resources in the server based on the risk ratio, wherein the computing resources are computing resources used to process payment requests received by the server.

9. An electronic device, characterized in that, Includes a transceiver and a processor, the processor being used for: A risk assessment is performed on multiple payment requests received by the server to obtain an assessment result, wherein the assessment result includes a risk score corresponding to each of the multiple payment requests, and the risk score is used to characterize the probability that the corresponding payment request has a risk. Based on the assessment results, a risk ratio is determined. The risk ratio is used to characterize the proportion of high-risk payment requests among the multiple payment requests. The high-risk payment request is the payment request whose risk score is greater than a first threshold. The computing resources in the server are expanded or reduced based on the risk ratio, wherein the computing resources are used to process payment requests received by the server.

10. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the resource adjustment method as described in any one of claims 1 to 7.

11. 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 steps of the resource adjustment method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the resource adjustment method as described in any one of claims 1 to 7.

Images