Flow control method and device based on model, medium, equipment and product

Abstract

The embodiment of the invention provides a flow control method and device based on a model, a medium, equipment and a product, and the method comprises the steps: obtaining a related parameter corresponding to a first call request in response to the received first call request, carrying out the feature construction of the related parameter, and obtaining a multi-modal feature corresponding to the first call request; the multi-modal features are input into a pre-trained risk assessment model, a prediction result corresponding to the first call request is output, and under the condition that the prediction result indicates that the call initiation object has a risk, a target flow control strategy is determined according to a risk type corresponding to the call initiation object, and the target flow control strategy is used for performing flow control operation on the target API. Through the method and the device, the problem of relatively low accuracy of abnormal call risk identification in related technologies is solved, and the effect of improving the safety and the stability of a data interaction platform is further achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a model-based flow control method, apparatus, medium, device, and product. Background Technology

[0002] In today's digital age, open platforms provide numerous Independent Software Vendors (ISVs) with rich Application Programming Interfaces (APIs), enabling data interaction and function sharing between different systems. However, related flow control technologies have gradually revealed many shortcomings. When faced with complex and ever-changing call patterns, rate limiting strategies based on simple rules cannot accurately identify abnormal call behavior, easily leading to misjudgments or omissions. For example, flow control technologies in related fields may struggle to distinguish between normal high-frequency calls and malicious DDoS attacks because they primarily rely on preset thresholds for judgment. These thresholds are often one-size-fits-all and cannot adapt to different business scenarios and call patterns. In some cases, such as during promotional activities, normal user behavior may cause a significant increase in API call frequency, but this does not constitute an actual security threat. If a fixed rate limiting strategy is adopted, these normal calls may be mistakenly regarded as abnormal behavior, resulting in legitimate users' requests being rejected without cause. Therefore, related technologies suffer from the technical problem of relatively low accuracy in identifying abnormal call risks. Summary of the Invention

[0003] This application provides a model-based flow control method, apparatus, medium, device, and product to at least address the technical problem of low accuracy in identifying abnormal call risks in related technologies.

[0004] According to one aspect of the embodiments of this application, a model-based flow control method is provided, applied to a data interaction platform, the data interaction platform including at least one API. The method includes: in response to a received first call request, obtaining relevant parameters corresponding to the first call request, wherein the relevant parameters include a set of call parameters corresponding to the first call request and a set of response parameters corresponding to the first call request; performing feature construction on the relevant parameters to obtain multimodal features corresponding to the first call request; inputting the multimodal features into a pre-trained risk assessment model, and outputting a prediction result corresponding to the first call request, wherein the prediction result includes a risk type corresponding to the call initiating object; and, if the prediction result indicates that the call initiating object has a risk, determining a target flow control strategy based on the risk type corresponding to the call initiating object, wherein the target flow control strategy is used to perform flow control operations on a target API, wherein the target API is the API that received the first call request.

[0005] According to another aspect of the embodiments of this application, a model-based flow control device is also provided, applied to a data interaction platform, the data interaction platform including at least one API, the device comprising: an acquisition unit, configured to acquire relevant parameters corresponding to the first call request in response to a received first call request, wherein the relevant parameters include a set of call parameters and a set of response parameters corresponding to the first call request; a construction unit, configured to perform feature construction on the relevant parameters to obtain multimodal features corresponding to the first call request; an output unit, configured to input the multimodal features into a pre-trained risk assessment model and output a prediction result corresponding to the first call request, wherein the prediction result includes a risk type corresponding to the call initiating object; and a determination unit, configured to determine a target flow control strategy based on the risk type corresponding to the call initiating object when the prediction result indicates that the call initiating object has a risk, wherein the target flow control strategy is used to perform flow control operations on a target API, wherein the target API is the API that received the first call request.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0007] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0009] This application addresses the issue of low accuracy in identifying API call risks by accurately identifying API call risks. Upon receiving a first call request, relevant parameters are obtained, and features are constructed based on these parameters. The constructed multimodal features and a pre-trained risk assessment model are then used to perform a risk assessment, yielding a prediction result. If the prediction result indicates a risk in the call initiating object, a target flow control strategy is determined based on the risk type of the call initiating object. This approach improves the accuracy of API call risk identification, solves the problem of low accuracy in identifying abnormal call risks in related technologies, and enhances the security and stability of the data interaction platform through the implementation of the flow control strategy. Attached Figure Description

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of a model-based flow control method according to an embodiment of this application;

[0011] Figure 2 This is a flowchart illustrating an optional model-based flow control method according to an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of an optional model-based flow control method according to an embodiment of this application;

[0013] Figure 4 This is a schematic diagram of an optional model training process according to an embodiment of this application;

[0014] Figure 5 This is a flowchart illustrating another optional model-based flow control method according to an embodiment of this application;

[0015] Figure 6 This is a structural block diagram of an optional model-based flow control device according to an embodiment of this application;

[0016] Figure 7This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

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

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] According to one aspect of the embodiments of this application, a model-based flow control method is provided. Optionally, in this embodiment, the above-described model-based flow control method may be applied to, but is not limited to, [examples of other methods]. Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0020] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0021] The model-based flow control method of this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the model-based flow control method of this application embodiment can be executed by a client installed on terminal device 102.

[0022] Model-based flow control methods can be applied to data interaction platforms, which may include at least one API. These platforms receive call requests through at least one API.

[0023] Taking the model-based flow control method in this embodiment executed by terminal device 102 as an example, Figure 2 This is a flowchart illustrating an optional model-based flow control method according to an embodiment of this application, such as... Figure 2 As shown, the process of this method may include the following steps:

[0024] Step S202: In response to the received first call request, obtain the relevant parameters corresponding to the first call request, wherein the relevant parameters include a set of call parameters corresponding to the first call request and a set of response parameters corresponding to the first call request;

[0025] Step S204: Perform feature construction on the relevant parameters to obtain the multimodal features corresponding to the first call request;

[0026] Step S206: Input the multimodal features into the pre-trained risk assessment model and output the prediction result corresponding to the first call request, wherein the prediction result includes the risk type corresponding to the call initiating object;

[0027] Step S208: If the prediction result indicates that there is a risk in the calling object, determine the target flow control strategy according to the risk type corresponding to the calling object. The target flow control strategy is used to perform flow control operations on the target API, where the target API is the API that received the first call request.

[0028] The model-based flow control method in this embodiment can be applied to the field of computer technology and to digital service scenarios, such as data interaction in financial transactions and e-commerce platforms. Open platforms provide API interfaces to ISVs, enabling rich functional integration and data exchange. However, traditional flow control technologies, when processing API calls, rely solely on preset rules and thresholds, making it difficult to handle abnormal call patterns in complex scenarios. For example, it is difficult to distinguish between normal high traffic during peak promotional periods and distributed denial-of-service (DDoS) attacks. Furthermore, when processing multimodal (interface name, service ID, call time, IP address, etc.) call data, it lacks in-depth analysis capabilities, resulting in a low accuracy rate in identifying abnormal call risks.

[0029] To at least partially solve the aforementioned technical problems, in this embodiment, upon receiving a first call request, relevant parameters corresponding to the first call request are obtained. Features are constructed based on these parameters, and the constructed multimodal features corresponding to the first call request and a pre-trained risk assessment model are used to perform risk assessment and obtain prediction results. If the prediction results indicate that the call initiating object has risks, a target flow control strategy is determined based on the risk type corresponding to the call initiating object. This achieves accurate identification of API call risks, improves the accuracy of API call risk identification, solves the problem of low risk identification accuracy in related technologies, and enhances the security and stability of the data interaction platform through the implementation of dynamic flow control strategies.

[0030] It's important to note that a data interaction platform can refer to the target platform for API calls made by Independent Software Vendors (ISVs) or other external systems. A data interaction platform can be any type of server-side application; for example, it could be an API gateway for a cloud service provider, an internal service API for an enterprise, or an open API platform in fields such as finance, e-commerce, or social networks. Its primary responsibility is to receive and process API call requests from ISVs, execute the corresponding service or data processing logic, and then return the results to the caller as response parameters.

[0031] The first call request can be an instruction initiated to the data interaction platform to call a specific API. This request can include various call parameters, such as the interface ID, the IP address of the calling object, the call time, and parameter values, used to request specific services or data. Related parameters can include a set of call parameters and a set of response parameters. The set of call parameters can be a collection of parameters provided by the calling object when calling the API, such as the interface name, request headers, request body, and the unique identifier of the caller (i.e., the identifier of the calling object). The set of response parameters is a set of parameters returned by the platform after the API call, typically including the call status, response time, and error information. The response parameters are feedback information sent by the data interaction platform to the calling object after processing the call request, informing them of the request processing status, result, and possible error information. These parameters are crucial for the calling object, providing key information about the success or failure of the request, the system's health status, and serving as the basis for subsequent processing, troubleshooting, or business logic judgment. For example, response parameters might include a status code indicating whether the request was successful (e.g., 200 for success, 400 for client error, and 500 for server error); response time, used to measure the efficiency of request processing; and error messages to help the calling object understand the specific reasons for the failed request so that it can take appropriate corrective or handling actions. The calling object is the object that initiated the first call request.

[0032] Multimodal features are a set of attributes and indicators that can be extracted from a set of call parameters and a set of response parameters during feature construction. They can reflect the call behavior model. Multimodal features can integrate data information from different sources and of different natures, such as call frequency, call time, call duration, etc., to provide richer input for subsequent risk assessment models.

[0033] The pre-trained risk assessment model can be a machine learning or deep learning-based model. It can be trained and validated using historical call data to identify and predict the types of risks associated with API calls. This model has the ability to identify abnormal call patterns and distinguish between malicious attacks and normal business calls. Optionally, algorithms such as XGBoost or LSTM can be used to learn the correlation between call patterns and risks based on historical data for real-time risk assessment.

[0034] Risk identification models can utilize deep learning frameworks such as XGBoost, LSTM, or GNN, or unsupervised learning models like Isolation Forest and AutoEncoder. Machine learning models such as XGBoost and LightGBM, or MLLM, can also be chosen. XGBoost is well-suited for processing structured data, accurately capturing key risk factors in call patterns through feature importance analysis. LSTM excels at time-series analysis, modeling dynamic changes in call frequency and duration to predict future risk trends. GNN focuses on the relationship network between callers, such as API call chains, identifying group activities or abnormal propagation patterns. The model is fed with multimodal data, including API names, service IDs, call times and durations, APP IDs (unique identifiers of calling applications), historical behavior, and IP address information. Through feature extraction and fusion, it learns distinguishing features between normal and abnormal calls, enabling real-time risk assessment and intelligent flow control. This model training strategy effectively improves the accuracy of risk identification, ensuring the platform's responsiveness and self-protection mechanisms in the face of complex attacks.

[0035] Of course, the structure of a risk identification model can be composed of a single model framework or multiple models.

[0036] The prediction result can be the output conclusion of a pre-trained risk assessment model after analyzing the first call request, and can include the risk type corresponding to the call initiating object determined based on this call request. Optionally, the risk type can include multiple security risks, multiple business risks, and multiple performance risks. Specifically, as shown in Table 1.

[0037] Table 1

[0038]

[0039] Optionally, based on the risk type indicated in the prediction results, a specific strategy for traffic control of the target API can be determined, i.e., the target flow control strategy. Optionally, the flow control strategy may include, but is not limited to, token bucket strategies, time window counter strategies, blacklist strategies, etc., aiming to reduce platform load and prevent potential abnormal call behavior by limiting the frequency, number, or source of API calls. Flow control operations can be the flow control operations performed on the target API according to the target flow control strategy. It should be noted that if a risk is detected, a risk warning will be issued immediately to notify relevant personnel, who can then manually intervene to investigate the problem.

[0040] Optionally, the data interaction platform contains at least one API. The target API is the API that receives the first call request, i.e., the API interface that currently requires risk assessment and flow control operations.

[0041] Optionally, the first call request can be any API call request sent to the data interaction platform. Of course, the data interaction platform can also set up a flow control record table to record the call initiating object that is being subjected to flow control operations. If the identification information of the call initiating object does not exist in the current flow control record table, the call request initiated by the call initiating object (i.e., the first call request) can be risk-identified.

[0042] In one example, such as Figure 3 As shown, the data interaction platform can include a development platform, tools, agents, and models (i.e., pre-trained risk assessment models). Within the data interaction platform, the tools first load the agent to establish a connection between the tools and the agent. The development platform can input relevant parameters into the agent, which performs preliminary processing on these parameters. The pre-processed parameters are then input into the model, and the agent retrieves the corresponding analysis results, i.e., the prediction results.

[0043] It should be noted that if the first call request is identified as risky, i.e., the calling object is at risk, a predefined response can be returned, such as an error code, a warning message, or an empty response, indicating that the call has been intercepted by the system or is considered abnormal, which helps prevent sensitive information from being leaked to potential attackers.

[0044] Through the embodiments provided in this application, in response to receiving a first call request, relevant parameters corresponding to the first call request are obtained, and features are constructed based on the relevant parameters. Then, the multimodal features corresponding to the constructed first call request and a pre-trained risk assessment model are used to perform risk assessment and obtain prediction results. If the prediction results indicate that the call initiating object has risks, a target flow control strategy is determined according to the risk type corresponding to the call initiating object. This achieves accurate identification of API call risks, improves the accuracy of API call risk identification, solves the problem of low accuracy in abnormal call risk identification in related technologies, and improves the security and stability of the data interaction platform through the implementation of flow control strategies.

[0045] In an exemplary embodiment, the relevant parameters further include the call frequency of the calling object in a first preset historical period, the abnormal call frequency in a second preset historical period, the call duration corresponding to the first call request, the number of calls to the target API in a third preset historical period, and the call success rate in a fourth preset historical period; step S204 includes: performing feature extraction operations on each call parameter in a set of call parameters to obtain a set of basic call features; performing feature extraction operations on each response parameter in a set of response parameters to obtain a set of basic response features; performing feature construction on the call frequency, abnormal call frequency, and call duration to obtain the associated features corresponding to the first call request; performing feature construction on the number of calls and the call success rate to obtain the statistical features corresponding to the first call request; and performing feature fusion processing on a set of basic call features, a set of basic response features, associated features, and statistical features to obtain the multimodal features corresponding to the first call request.

[0046] It should be noted that the relevant parameters refer to information related to the first call request during risk assessment. This can include a set of call parameters and a set of response parameters corresponding to the first call request, as well as historical call behavior statistics of the calling initiator and the runtime status information of the target API. The calling initiator can be the object that initiates the API call, which can be an independent software vendor (ISV), a user, or other external system, specifically referring to the initiator of the first call request.

[0047] The first, second, third, and fourth preset historical time periods can refer to specific historical time windows used to analyze call frequency, abnormal call frequency, call count, and call success rate. These specific historical time windows can be of fixed length, such as the last 5 minutes, the last 10 minutes, the last 30 minutes, the last 24 hours, etc. The end time of the first, second, third, and fourth preset historical time periods can be the time when the first call request is received. The length of the corresponding time periods can be determined based on empirical values, and this application does not impose any limitations on this.

[0048] The call frequency of the initiating object within the first preset historical period can be the frequency at which the initiating object sends call requests to the data interaction platform through different APP IDs (i.e. through different API interfaces in the data interaction platform) within the first preset historical period.

[0049] The abnormal call frequency within the second preset historical period refers to the frequency of abnormal call requests recorded by the API that received the first call request within the second preset historical period. Abnormal call requests can be failed call requests. The call latency corresponding to the first call request refers to the length of time from when the ISV or external system initiates a specific API call request to the data interaction platform, from when the data platform receives the request to when it completes processing and obtains the response parameters. Call latency reflects the efficiency of the data interaction platform in processing call requests; abnormal call latency may be a signal of system resource constraints, slow query attacks, or internal failures.

[0050] The number of calls to the target API within the third preset historical period indicates the frequency with which the target API was invoked during that period. The call success rate within the fourth preset historical period indicates the percentage of requests successfully executed when the target API was invoked during that period. The number of calls to the target API within the third preset historical period can be used to monitor its usage frequency. The call success rate within the fourth preset historical period can reflect the stability and health of the API. Using these two metrics together helps the data processing platform more accurately assess the risk level in the current call context, adjust flow control strategies in a timely manner, and ensure service quality and security.

[0051] Optionally, the basic characteristics of the call can be basic attributes or metrics directly extracted from the call parameters, such as the interface name, service ID, unique identifier of the calling application (APP ID), and IP address of the calling object. These characteristics reflect the basic information and structure of the call request. The basic characteristics of the response can be attributes directly extracted from the response parameters, such as call status, response time, and error code, providing direct feedback information after the call request is processed.

[0052] Optionally, the correlation features can be features constructed by analyzing data such as call frequency, abnormal call frequency, and call duration, which can reflect the interrelationships between call behaviors. Optionally, there may be a positive correlation between the call frequency of the calling object within a specific time period and the frequency of abnormal calls in its historical time period, or there may be a negative correlation between call duration and call frequency.

[0053] Optionally, statistical features can be features calculated using statistical methods based on historical data such as the number of calls and the success rate of calls. For example, the average number of calls, standard deviation, and average success rate of the target API over a period of time can help determine whether the current call deviates from the historical baseline and whether there are potential risks.

[0054] Optionally, feature fusion can be implemented through one of the following methods: vector concatenation, weighted summation, or deep learning fusion. Vector concatenation involves concatenating various feature vectors in a specific order to form a comprehensive feature vector. Weighted summation assigns different weights to different types of features and performs a weighted summation to reflect the importance of each feature in risk assessment. Deep learning fusion utilizes neural network models to map features to a higher-dimensional space, learn the non-linear relationships between features, and capture deeper-level risk patterns.

[0055] In one example, for instance, if the first call request is a payment-related call request, the corresponding set of call parameters might include the interface name (interface type: payment), service ID, APP ID, call time, etc., while the set of response parameters might include the response code, call duration, etc. The construction process for basic features can directly extract a set of call parameters and a set of response parameters. The construction process for associated features might include: calculating the month-on-month change or deviation from the daily average of the call frequency of the calling initiating object within a first preset historical period to detect sudden increases in call volume and obtain the call frequency change rate; identifying the concentration of abnormal calls within a second preset historical period, such as the proportion of abnormal calls per unit time, to obtain the abnormal call clustering degree; standardizing call duration to determine whether the duration significantly exceeds the historical baseline, indicating potential performance bottlenecks or attack behaviors, to obtain the distribution characteristics of call duration; and fusing these three features to obtain the associated features. The process of constructing statistical features may include: analyzing the trend of target API call volume over time by setting a sliding window to identify potential overload risks, i.e., obtaining the call count trend; analyzing the time-series fluctuations of success rate, such as using the Prophet prediction model to predict the call success rate, comparing it with the actual value, and discovering abnormal fluctuations, i.e., obtaining the call success rate fluctuation situation; and performing feature fusion processing on the call count trend and the call success rate fluctuation situation to obtain statistical features.

[0056] In another example, suppose a payment system monitors call behavior on its data interaction platform. Upon receiving the first call request, it first records the interface name, APP ID, IP address, etc., from the request parameters. Then, it queries the historical records to obtain the call frequency of the calling object in the last 5 minutes (first preset historical period), the abnormal call frequency in the last 30 minutes (second preset historical period), and the duration of the first call request. It also obtains the total number of calls to the target API (i.e., the API being called) and the call success rate (fourth preset historical period) in the past 24 hours.

[0057] Subsequently, multi-level feature construction was performed. For call parameters, the sensitivity level of the interface and the historical behavior pattern of the APPID were extracted as basic call features; for response parameters, the percentile of response time and the classification of error codes were extracted as basic response features. For call frequency, abnormal call frequency, and call duration, the temporal clustering of call behavior was analyzed using a time-series statistical model to obtain correlation features; and for the number of calls and call success rate, the average and variance within the sliding window were calculated to obtain statistical features. Finally, through feature fusion, all the above features were integrated into a multimodal feature vector, which was input into a pre-trained risk assessment model to obtain the risk type of the first call request, such as "potential DDoS attack" or "suspicious account theft behavior". Based on the output of the pre-trained risk assessment model, the platform can immediately take corresponding flow control measures, such as limiting the call frequency or temporarily blocking IP addresses, to maintain the stability and security of the platform.

[0058] In this embodiment, multimodal feature fusion takes into account the real-time information and historical behavior data of the call request, as well as the operating status of the target API, which enhances the pre-trained risk identification model's deep understanding of call behavior and risk identification capabilities, making risk identification more comprehensive and accurate.

[0059] In an exemplary embodiment, the prediction result includes multiple risk types corresponding to the calling object and a predicted probability value for each of the multiple risk types. The method further includes: if the predicted probability value for a risk type in the prediction result is greater than a preset probability threshold, determining that the prediction result indicates that the calling object has a risk.

[0060] It should be noted that the prediction result refers to the output of the pre-trained risk identification model after assessing the risk of the initiating object's call behavior, including various possible risk types and their corresponding predicted probability values. These risk types can be security risks (such as DDoS attacks and password brute-force attacks), business risks (such as abnormal payment behavior and API abuse), performance risks (such as API overload and response latency), etc.

[0061] For each risk type, the pre-trained risk identification model outputs a corresponding probability value, representing the likelihood of that risk type occurring in the current call. A higher probability value indicates that the call is more likely to fall under that risk type. A preset probability threshold can be set to identify risks. When the predicted probability value for a certain risk type output by the pre-trained risk identification model exceeds this threshold, the calling object is considered to have a risk of that type, requiring further monitoring and processing. The preset probability threshold can be set based on historical data and business requirements.

[0062] Optionally, a preset period can be set to update the pre-trained risk assessment model according to the preset period, so as to improve the accuracy of the model prediction.

[0063] This embodiment demonstrates how setting a preset probability threshold can automatically filter out high-risk call behaviors, reducing false alarms and missed alarms, and improving the accuracy and timeliness of risk warnings.

[0064] In an exemplary embodiment, to quickly match the corresponding process strategy, a flow control strategy library can be set up in the data interaction platform. The flow control strategy library includes preset flow control strategies corresponding to multiple risk types; the prediction result includes multiple risk types corresponding to the call initiating object and the predicted probability value for each of the multiple risk types; step S208 includes: determining the target risk type corresponding to the call initiating object based on the predicted probability value for each risk type; and determining the preset flow control strategy in the flow control strategy library corresponding to the target risk type as the target flow control strategy based on the target risk type.

[0065] It should be noted that the flow control policy library contains different preset flow control policies for various predefined risk types. Each policy is designed with specific triggering conditions and execution actions to implement flow control when a certain risk type is detected. The preset flow control policies can be control schemes pre-defined in the flow control policy library for each risk type. For example, for security risks, possible policies include IP blacklisting and rate limiting; for business risks, policies may include additional verification or suspension of certain service permissions; and for performance risks, policies may involve dynamically adjusting resource allocation.

[0066] Optionally, the risk type with the highest predicted probability value in the prediction results can be used as the target risk type corresponding to the initiating object. Alternatively, the risk type with a predicted probability value greater than a preset probability threshold can also be used as the target risk type corresponding to the initiating object. That is, the number of target risk types can be one or more. When there are multiple target risk types, multiple target flow control policies are set for the initiating object. For example, if there are two target risk types, two target flow control policies are set for the initiating object: a first preset flow control policy and a second preset flow control policy. A subsequent call request sent by the initiating object will only be processed if both target flow control policies are simultaneously satisfied.

[0067] This embodiment allows for the rapid identification of high-risk calls by comparing them with predicted probability values, thus avoiding wasting resources on low-risk events and ensuring the effectiveness and relevance of flow control strategies.

[0068] In an exemplary embodiment, after determining the target flow control policy based on the risk type corresponding to the initiating object, the method further includes: if the target flow control policy is a first preset flow control policy, determining the number of target tokens corresponding to the initiating object, wherein the first preset flow control policy is used to instruct the initiating object to be flow-limited according to a first flow-limiting mechanism, and the number of target tokens represents the ability to process the initiating object's initiating request; if a second initiating request is detected and the number of existing tokens in the token bucket is greater than or equal to the number of target tokens, receiving the second initiating request, wherein the number of existing tokens represents the current data interaction platform's ability to process the initiating request; if a second initiating request is detected and the number of existing tokens is less than the number of target tokens, delaying or rejecting the second initiating request.

[0069] It should be noted that the first preset flow control strategy can refer to a strategy that uses the token bucket algorithm as a rate limiting mechanism to control the request frequency of the initiating object and prevent abnormal or high-risk calls from causing system overload. The second call request can be a subsequent call request received from the same object after identifying and evaluating the risk type of the initiating object.

[0070] The first rate limiting mechanism can be a rate limiting mechanism implemented on the calling object according to a first preset flow control strategy. The first preset flow control strategy can solve the problem of how to control high-frequency calls.

[0071] The number of target tokens characterizes the capacity of the data interaction platform to process call requests sent by the initiating object. Optionally, the number of target tokens can be a token limit set for the initiating object, reflecting its capacity to initiate call requests. The number of target tokens can be dynamically adjusted based on risk assessment to accommodate different risk levels. Optionally, the number of target tokens can be a preset threshold, typically a maximum set number of tokens. Alternatively, it can be determined based on the predicted probability value of the target risk type in the prediction results for the initiating object; generally, the higher the predicted probability value, the more target tokens are required. Of course, it can also be determined based on both the predicted probability value of the target risk type in the prediction results for the initiating object and the initiating object's historical records.

[0072] The number of tokens currently in the token bucket can be the number of tokens currently existing in the token bucket corresponding to the call initiating object, as recorded by the data interaction platform. Specifically, if it is determined that the call initiating object needs to adopt the first preset flow control strategy, a token bucket can be set for the call initiating object, and tokens can be added to the token bucket at a preset rate, i.e., increasing the number of tokens in the token bucket. When a second call request sent by the call initiating object is detected, the number of tokens currently in the token bucket corresponding to the call initiating object is compared with the number of target tokens. If the number of tokens currently in the token bucket is greater than or equal to the number of target tokens, the second call request is received and processed, and then the number of tokens in the token bucket that is the same as the number of target tokens is deducted, or all existing tokens in the token bucket are cleared. For example, when the number of existing tokens in the token bucket is 6 and the number of target tokens is 5, 5 tokens can be directly deducted, or all can be cleared to zero.

[0073] If the number of tokens currently in the token bucket is less than the target number of tokens, the second call request will be either delayed or rejected. Optionally, a smaller number of tokens in the token bucket than the target number of tokens may mean that the data interaction platform's current resources are insufficient to handle the additional request, or that the request poses a certain risk. In this case, the system will delay or directly reject the second call request according to a preset flow control policy until the number of existing tokens is restored to a level sufficient to cover the target number of tokens.

[0074] This embodiment, by comparing the number of target tokens with the number of existing tokens, enables precise rate limiting for high-risk call initiators, ensuring that platform resources are not excessively consumed, while preventing malicious calls or abnormal behavior from impacting platform security and stability. The token mechanism smooths request arrival rates, avoiding system overload caused by a large number of requests in a short period, thus making resource allocation more rational and improving overall processing capacity and response speed.

[0075] In an exemplary embodiment, after determining the target flow control policy based on the risk type corresponding to the initiating object, the method further includes: if the target flow control policy is a second preset flow control policy, obtaining the target number of second call requests sent by the initiating object within a preset time window, wherein the preset time window is the time range from a historical moment with a preset duration from the current moment to the current moment, and the second preset flow control policy is used to instruct the initiating object to be flow-limited according to the second flow-limiting mechanism; if the target number is greater than a preset number threshold, the initiating object is flow-limited.

[0076] It should be noted that the second preset flow control strategy can be a strategy that instructs the initiating object to be rate-limited according to the second rate-limiting mechanism, which is different from the first preset flow control strategy. The preset time window can be used to define the time interval for evaluating the request frequency of the initiating object. For example, it can be one minute, ten minutes, or any other time length, used to calculate the number of requests within a certain time. The preset time window can include a time range from a historical moment with a preset duration from the current moment to the current moment. The target number of second call requests can be used to determine the number of call requests sent by the initiating object within the preset time window. This reflects the activity intensity and frequency of the initiating object. The second rate-limiting mechanism can determine whether to rate-limit the initiating object by counting the number of call requests within the preset time window. The preset quantity threshold can refer to a threshold set to implement rate limiting. When the target quantity exceeds this threshold, rate limiting will be applied to the initiating object, generally by rejection or delay.

[0077] Optionally, the preset time window and preset quantity threshold can be adjusted according to different risk types and business needs, making the rate limiting strategy highly flexible and adaptable, and able to cope with various complex scenarios.

[0078] In one example, suppose a second preset flow control strategy is applied to the initiating object Y, with a preset time window of 5 minutes and a preset threshold of 10. All call requests from Y are continuously monitored within the 5-minute window. If Y's call requests reach 10 within 5 minutes (i.e., the target number equals the preset threshold), monitoring continues without restriction. However, if any request sent by Y in the following seconds causes the number of requests within 5 minutes to exceed 10 (i.e., the target number exceeds the preset threshold), Y will be immediately rate-limited, such as pausing Y's request processing for a period, increasing response time, or reducing the acceptable request frequency.

[0079] This embodiment effectively identifies and responds to abnormally high-frequency call behavior by setting a preset quantity threshold and monitoring the request frequency within a preset time window, especially those call requests that may originate from attacks or improper use.

[0080] In an exemplary embodiment, after determining the target flow control policy based on the risk type corresponding to the initiating object, the method further includes: if the target flow control policy is a third preset flow control policy and a second initiating request is received from the initiating object, refusing to process the second initiating request, wherein the third preset flow control policy is used to indicate that the initiating object is in a preset blacklist.

[0081] It should be noted that the third preset flow control policy can be a flow control mechanism targeting call initiators listed on a blacklist, with the aim of completely preventing blacklisted objects from accessing the system or specific services. The preset blacklist can be a list containing information about known high-risk call initiators, such as IP addresses, APP IDs, or other identifiers. The system will periodically update this blacklist to reflect the latest risk information. The second call request can be a call request issued by the object after the risk type of the call initiator has been identified and assessed.

[0082] In one example, suppose the initiating object Z is identified as extremely high-risk by the intelligent flow control system due to previously exhibited abnormal behavior patterns, such as frequent brute-force attacks or participation in DDoS attack attempts, and is subsequently added to a preset blacklist. When the system adopts a third preset flow control policy, it immediately checks the blacklist. In a certain call scenario, when Z's second call request arrives, the system first identifies Z as the request initiator. Then, it quickly checks the preset blacklist and finds Z listed there. According to the third preset flow control policy, no further processing is performed on Z's second call request; that is, the request is immediately rejected, no resources or tokens are allocated, and no subsequent rate limiting or delay options are considered.

[0083] It's worth noting that the data interaction platform can also be configured with routing monitoring, providing real-time monitoring of API call status. This covers key metrics such as maximum, minimum, and average latency, total calls, success and failure counts, and unhandled errors. The operations team can use this to gain insight into the health of APIs, quickly locate anomalies, and anticipate flow control risks. By displaying real-time call statistics for each API on the interface, including but not limited to latency distribution, call frequency, and success rate, this information helps operations personnel quickly identify which APIs are under high load or have potential security vulnerabilities. For example, excessively long response times may indicate resource contention or attack attempts. Based on this real-time feedback, the operations team can quickly take action to adjust API flow control strategies, such as increasing rate limiting thresholds or enabling backup servers, effectively preventing service interruptions due to overload or attacks.

[0084] This embodiment effectively protects itself from known malicious behavior and ensures the security of the platform and services by immediately rejecting requests from blacklisted call initiators. Furthermore, the automated blacklist checking and request rejection mechanism reduces the time and cost of manual review and handling of abnormal calls, improving overall operational efficiency.

[0085] In an exemplary embodiment, the method further includes: obtaining a historical parameter sample set, wherein each historical parameter sample in the historical parameter sample set includes relevant parameter samples corresponding to historical call requests and annotation information corresponding to historical call requests, wherein the annotation information is used to indicate the risk type corresponding to the historical call requests; performing feature construction processing and feature partitioning processing on each historical parameter sample in the historical parameter sample set to obtain a training set and a validation set; inputting training samples from the training set into the risk assessment model through a first message queue to train the risk assessment model, and inputting validation samples from the validation set into the risk assessment model through a second message queue to validate the risk assessment model, until the risk assessment model converges to obtain a pre-trained risk assessment model.

[0086] It should be noted that the historical parameter sample set can refer to the collection of all request and response parameter records from past API calls. These records include caller identity, call time, interface type, call frequency, response time, call result (success / failure), and call risk type tagged manually or automatically. Relevant parameter samples can be specific data samples contained in each historical call request, used to describe the characteristics of the call request. Labeling information can be risk type tags manually added for historical call requests, such as "normal call," "potential DDoS attack," "abnormal payment behavior," etc., used to guide the model in learning risk identification patterns. Feature construction processing can be used to extract and construct data from the historical parameter samples that helps the model understand call risk characteristics, such as time series features, statistical features, and correlation features. Feature partitioning processing can be used to randomly or proportionally divide the processed sample data into training and validation sets. The training set is used for model learning, and the validation set is used to evaluate model performance. The first and second message queues can be middleware used for data transmission; the first message queue is responsible for sending the training set to the model, and the second message queue is responsible for sending the validation set. The risk assessment model can be a model used to learn and predict the risk types of API calls. Convergence, in the context of model training, refers to the state where the prediction error gradually stabilizes within an acceptable range, signifying the completion of model training. Specifically, during training, the first message queue continuously feeds training set data into the risk assessment model, which then learns how to identify risk types from the characteristics of call requests. Simultaneously, the second message queue sends validation set data to periodically evaluate the model's accuracy and generalization ability. Model parameters are adjusted based on the validation results until the model converges, meaning its performance on the validation set stabilizes, resulting in a pre-trained risk assessment model. This model can intelligently analyze the risks of new call requests in real-time flow control decisions, ensuring the platform's secure operation.

[0087] Alternatively, during the validation process, cross-validation can be used to evaluate model performance, ensuring that the model not only performs well on the training data, but also maintains good generalization ability on unseen validation data.

[0088] Message queues can separate data processing and model training processes, enabling asynchronous communication. This means that data collection and preprocessing can be performed independently outside of model training. When the data is ready, it can be pushed to the model training task via the message queue without waiting for the model to complete, thereby improving the overall efficiency and flexibility of the system.

[0089] In one example, such as Figure 4 As shown, Figure 4 The process of model training is described. Specifically, the ISV interacts with the open platform via API. The platform records the request and response parameters for each call, including the interface name and service ID. These parameters, after being processed to a unified format, are sent to the model platform via a message queue. The model learns the characteristics of the call data, such as call frequency and time intervals, to identify abnormal patterns. After training, the model can intelligently analyze API call risks and achieve precise flow control.

[0090] By integrating multimodal information, the comprehensiveness and accuracy of risk identification are enhanced; by processing heterogeneous data, the uniformity and high quality of model training data are ensured; by utilizing the deep learning capabilities of the model, intelligent analysis of complex calling patterns is achieved; and by implementing an automated flow control decision-making process, manual intervention is reduced, and the security and stability of the platform are improved.

[0091] In this embodiment, by learning the characteristics of historical samples, the risk assessment model can accurately identify the risk types in API calls, improving the accuracy of flow control. The use of training and validation sets ensures that the model not only performs well on training data but also makes stable predictions on unseen data, enhancing its generalization ability.

[0092] Figure 5 This is a flowchart illustrating the model-based flow control method in this optional example, such as... Figure 5 As shown, the process of this model-based flow control method may include the following steps:

[0093] Step S502: Receive the first call request;

[0094] Specifically, the data interaction platform receives the first call request sent from the ISV.

[0095] Step S504: Process the first call request and obtain the response parameters;

[0096] Specifically, after obtaining the response parameters, other relevant parameters are obtained, such as the call frequency of the calling object in the first preset historical period, the abnormal call frequency in the second preset historical period, the call time corresponding to the first call request, the number of calls to the target API in the third preset historical period, the call success rate in the fourth preset historical period, etc.

[0097] Of course, a rule engine can also be set up, which includes a series of risk identification rules. These rules typically include conditional judgments, such as interface type, call time, call frequency, IP address, APP ID historical behavior, etc., to quickly filter out potential risky calls. If a risk type needs to be determined, rules with multiple parameters need to be compared. The rule engine can use a random sampling method to obtain a call request and calculate a risk score based on the number of matching rules and the severity. Calls with high scores will be marked as high-risk. The risk score can be compared with the model output results. If the difference is too large, an alert will be issued to remind operations personnel of the anomaly.

[0098] Step S506: Perform feature construction processing on the relevant parameters;

[0099] Specifically, the data preprocessing module performs a unified format conversion and then performs feature construction processing on the relevant parameters after data preprocessing to obtain the multimodal features corresponding to the first call request.

[0100] Step S508: Input the multimodal features into the pre-trained risk assessment model;

[0101] Specifically, multimodal features are sent to a pre-trained risk assessment model via an agent to obtain prediction results.

[0102] Step S510: Perform flow control processing based on the prediction results.

[0103] This optional example receives and processes the first call request, obtains key parameters, and transforms these parameters into multimodal features that the model can parse. This effectively integrates multi-dimensional data such as interface information, call patterns, and IP behavior. The multi-dimensional data is input into a pre-trained risk assessment model, which uses machine learning techniques to accurately predict the risk of each call, significantly improving the accuracy and speed of anomaly call identification. Finally, based on the model's predictions, flow control strategies are dynamically adjusted, such as intelligent rate limiting or IP blocking, to quickly respond to potential threats while ensuring the efficient operation of normal services. This model-driven approach enhances the intelligence of real-time monitoring, optimizes resource allocation, and improves the real-time performance and accuracy of flow control decisions.

[0104] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to 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 prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0106] According to another aspect of the embodiments of this application, a model-based flow control device is also provided, which can be used to implement the model-based flow control method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0107] Figure 6 This is a structural block diagram of an optional model-based flow control device according to an embodiment of this application, such as... Figure 6 As shown, the model-based flow control device includes:

[0108] The acquisition unit 602 is used to acquire relevant parameters corresponding to the first call request in response to the received first call request, wherein the relevant parameters include a set of call parameters corresponding to the first call request and a set of response parameters corresponding to the first call request;

[0109] Construction unit 604 is used to construct features from relevant parameters to obtain the multimodal features corresponding to the first call request;

[0110] The output unit 606 is used to input multimodal features into a pre-trained risk assessment model and output the prediction result corresponding to the first call request, wherein the prediction result includes the risk type corresponding to the call initiating object;

[0111] The determining unit 608 is used to determine the target flow control strategy based on the risk type corresponding to the call initiating object when the prediction result indicates that there is a risk in the call initiating object. The target flow control strategy is used to perform flow control operations on the target API, which is the API that received the first call request.

[0112] It should be noted that the acquisition unit 602 in this embodiment can be used to execute the above step S202, the construction unit 604 in this embodiment can be used to execute the above step S204, the output unit 606 in this embodiment can be used to execute the above step S206, and the determination unit 608 in this embodiment can be used to execute the above step S208.

[0113] Through the embodiments provided in this application, in response to receiving a first call request, relevant parameters corresponding to the first call request are obtained, and features are constructed based on the relevant parameters. Then, the multimodal features corresponding to the constructed first call request and a pre-trained risk assessment model are used to perform risk assessment and obtain prediction results. If the prediction results indicate that the call initiating object has risks, a target flow control strategy is determined according to the risk type corresponding to the call initiating object. This achieves accurate identification of API call risks, improves the accuracy of API call risk identification, solves the problem of low accuracy in abnormal call risk identification in related technologies, and improves the security and stability of the data interaction platform through the implementation of flow control strategies.

[0114] In an exemplary embodiment, the relevant parameters also include the call frequency of the calling object in the first preset historical period, the abnormal call frequency in the second preset historical period, the call time corresponding to the first call request, the number of calls to the target API in the third preset historical period, and the call success rate in the fourth preset historical period;

[0115] The construction unit 604 is further configured to: perform feature extraction operations on each call parameter in a set of call parameters to obtain a set of basic call features; perform feature extraction operations on each response parameter in a set of response parameters to obtain a set of basic response features; construct features for call frequency, abnormal call frequency, and call duration to obtain associated features corresponding to the first call request; construct features for the number of calls and call success rate to obtain statistical features corresponding to the first call request; and perform feature fusion processing on a set of basic call features, a set of basic response features, associated features, and statistical features to obtain multimodal features corresponding to the first call request.

[0116] In an exemplary embodiment, the prediction result includes multiple risk types corresponding to the calling object and a predicted probability value corresponding to each of the multiple risk types. The device further includes an indication unit, which determines that the prediction result indicates that the calling object has a risk when the predicted probability value corresponding to a risk type in the prediction result is greater than a preset probability threshold.

[0117] In an exemplary embodiment, the data interaction platform is provided with a flow control strategy library, wherein the flow control strategy library includes preset flow control strategies corresponding to multiple risk types; the prediction result includes multiple risk types corresponding to the call initiating object and a predicted probability value corresponding to each of the multiple risk types; the determining unit is further configured to: determine the target risk type corresponding to the call initiating object based on the predicted probability value corresponding to each risk type; and determine the preset flow control strategy in the flow control strategy library corresponding to the target risk type as the target flow control strategy based on the target risk type.

[0118] In one exemplary embodiment, the apparatus further includes: a first execution unit, configured to, after determining a target flow control policy based on the risk type corresponding to the call initiating object, determine the number of target tokens corresponding to the call initiating object if the target flow control policy is a first preset flow control policy, wherein the first preset flow control policy is used to instruct the call initiating object to be flow-limited according to a first flow-limiting mechanism, and the number of target tokens represents the ability to process call requests sent by the call initiating object; receive a second call request if a second call request sent by the call initiating object is detected and the number of existing tokens in the token bucket is greater than or equal to the number of target tokens, wherein the number of existing tokens represents the ability of the current data interaction platform to process call requests sent by the call initiating object; and delay or reject the second call request if a second call request sent by the call initiating object is detected and the number of existing tokens is less than the number of target tokens.

[0119] In an exemplary embodiment, the above apparatus further includes: a second execution unit, configured to, after determining the target flow control policy based on the risk type corresponding to the initiating object, obtain the target number of second call requests sent by the initiating object within a preset time window if the target flow control policy is a second preset flow control policy, wherein the preset time window is a time range from a historical moment with a preset duration from the current moment to the current moment, and the second preset flow control policy is used to instruct the initiating object to be flow-limited according to the second flow-limiting mechanism; and to perform flow-limiting processing on the initiating object if the target number is greater than a preset number threshold.

[0120] In an exemplary embodiment, the above apparatus further includes: a third execution unit, configured to, after determining the target flow control policy based on the risk type corresponding to the call initiating object, refuse to process the second call request if the target flow control policy is a third preset flow control policy and a second call request sent by the call initiating object is received, wherein the third preset flow control policy is used to indicate that the call initiating object is in a preset blacklist.

[0121] In an exemplary embodiment, the above apparatus further includes: a training unit, configured to acquire a historical parameter sample set, wherein each historical parameter sample in the historical parameter sample set includes relevant parameter samples corresponding to a historical call request and annotation information corresponding to the historical call request, wherein the annotation information is used to indicate the risk type corresponding to the historical call request; perform feature construction processing and feature segmentation processing on each historical parameter sample in the historical parameter sample set to obtain a training set and a validation set; input training samples from the training set into the risk assessment model through a first message queue to train the risk assessment model, and input validation samples from the validation set into the risk assessment model through a second message queue to validate the risk assessment model, until the risk assessment model converges to obtain a pre-trained risk assessment model.

[0122] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0123] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0124] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0125] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0126] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0127] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0128] Figure 7 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in ROM 702 or programs loaded into RAM 703 from storage section 708. Random access memory 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0129] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card (NIC), modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0130] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions defined in the system of this application.

[0131] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0132] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0133] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A model-based flow control method, characterized in that, Applied to a data interaction platform, the data interaction platform including at least one API, the method includes: In response to the received first call request, relevant parameters corresponding to the first call request are obtained, wherein the relevant parameters include a set of call parameters corresponding to the first call request and a set of response parameters corresponding to the first call request; Based on the relevant parameters, feature construction is performed to obtain the multimodal features corresponding to the first call request; The multimodal features are input into a pre-trained risk assessment model, and the prediction result corresponding to the first call request is output, wherein the prediction result includes the risk type corresponding to the call initiating object; If the prediction result indicates that the initiating object has a risk, a target flow control strategy is determined according to the risk type corresponding to the initiating object. The target flow control strategy is used to perform flow control operations on a target API, wherein the target API is the API that received the first invocation request.

2. The method according to claim 1, characterized in that, The relevant parameters also include the call frequency of the call initiating object in the first preset historical period, the abnormal call frequency in the second preset historical period, the call time corresponding to the first call request, the number of calls to the target API in the third preset historical period, and the call success rate in the fourth preset historical period; The step of constructing features from the relevant parameters to obtain the multimodal features corresponding to the first call request includes: Perform feature extraction on each of the set of call parameters to obtain a set of basic call features; perform feature extraction on each of the set of response parameters to obtain a set of basic response features; Features are constructed based on the call frequency, the abnormal call frequency, and the call duration to obtain the associated features corresponding to the first call request; Based on the number of calls and the call success rate, feature construction is performed to obtain the statistical features corresponding to the first call request; The set of basic call features, the set of basic response features, the associated features, and the statistical features are subjected to feature fusion processing to obtain the multimodal features corresponding to the first call request.

3. The method according to claim 1, characterized in that, The prediction result includes multiple risk types corresponding to the initiating object and a predicted probability value for each of the multiple risk types. The method further includes: If the predicted probability value corresponding to a risk type in the prediction results is greater than a preset probability threshold, it is determined that the prediction results indicate that the initiating object has a risk.

4. The method according to claim 1, characterized in that, The data interaction platform is equipped with a flow control strategy library, which includes preset flow control strategies corresponding to multiple risk types; the prediction result includes multiple risk types corresponding to the call initiating object and the prediction probability value corresponding to each of the multiple risk types. The step of determining the target flow control strategy based on the risk type corresponding to the initiating object includes: Based on the predicted probability value corresponding to each risk type, the target risk type corresponding to the initiating object is determined; Based on the target risk type, the preset flow control strategy corresponding to the target risk type in the flow control strategy library is determined as the target flow control strategy.

5. The method according to any one of claims 1 to 4, characterized in that, After determining the target flow control strategy based on the risk type corresponding to the initiating object, the method further includes: When the target flow control policy is the first preset flow control policy, the number of target tokens corresponding to the call initiating object is determined, wherein the first preset flow control policy is used to instruct the call initiating object to be flow-limited according to the first flow-limiting mechanism, and the number of target tokens represents the ability to process the call request sent by the call initiating object; If a second call request is detected by the call initiating object and the number of existing tokens in the token bucket is greater than or equal to the number of target tokens, the second call request is received, wherein the number of existing tokens represents the current ability of the data interaction platform to process the call request sent by the call initiating object; If a second call request is detected from the call initiating object and the number of existing tokens is less than the number of target tokens, the second call request will be delayed or rejected.

6. The method according to any one of claims 1 to 4, characterized in that, After determining the target flow control strategy based on the risk type corresponding to the initiating object, the method further includes: When the target flow control policy is the second preset flow control policy, the target number of second call requests sent by the call initiating object within a preset time window is obtained, wherein the preset time window is the time range from a historical moment with a preset duration from the current moment to the current moment, and the second preset flow control policy is used to instruct the call initiating object to be flow-limited according to the second flow limiting mechanism; If the target number exceeds a preset threshold, rate limiting is applied to the initiating object.

7. The method according to any one of claims 1 to 4, characterized in that, After determining the target flow control strategy based on the risk type corresponding to the initiating object, the method further includes: If the target flow control policy is the third preset flow control policy, and a second call request is received from the call initiating object, the second call request will not be processed. The third preset flow control policy is used to indicate that the call initiating object is in a preset blacklist.

8. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Obtain a set of historical parameter samples, wherein each historical parameter sample in the set includes a relevant parameter sample corresponding to a historical call request and annotation information corresponding to the historical call request, wherein the annotation information is used to indicate the risk type corresponding to the historical call request; For each historical parameter sample in the historical parameter sample set, feature construction and feature partitioning are performed to obtain a training set and a validation set. The training samples from the training set are input into the risk assessment model through the first message queue to train the risk assessment model. The verification samples from the verification set are input into the risk assessment model through the second message queue to verify the risk assessment model, until the risk assessment model converges, thus obtaining the pre-trained risk assessment model.

9. A model-based flow control device, characterized in that, Applied to a data interaction platform, the data interaction platform including at least one API, the device includes: The acquisition unit is configured to, in response to a received first call request, acquire relevant parameters corresponding to the first call request, wherein the relevant parameters include a set of call parameters corresponding to the first call request and a set of response parameters corresponding to the first call request; The construction unit is used to construct features from the relevant parameters to obtain the multimodal features corresponding to the first call request; The output unit is used to input the multimodal features into a pre-trained risk assessment model and output the prediction result corresponding to the first call request, wherein the prediction result includes the risk type corresponding to the call initiating object; The determining unit is configured to determine a target flow control strategy based on the risk type corresponding to the call initiating object when the prediction result indicates that the call initiating object has a risk, wherein the target flow control strategy is used to perform flow control operations on a target API, wherein the target API is the API that received the first call request.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 8.

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

12. An electronic 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 steps of the method according to any one of claims 1 to 8.

Images