Request allocation method, device, electronic device and storage medium

Abstract

The present application provides a request allocation method, device, electronic device and storage medium. It includes: obtaining the first request amount and the second request amount of the root node and the leaf node of the decision tree in each unit time within the preset time length from the current time, the root node refers to the node corresponding to the business interface receiving the business request, the rule node refers to the node used to judge the request direction according to the rule, and the leaf node refers to the node corresponding to the service provider providing the specified capability; predicting the third request amount of the root node in the next unit time according to the first request amount, and predicting the fourth request amount of the leaf node in the next unit time according to the second request amount; calling the rule node to judge the node direction of the business request received by the business interface according to the preset judgment rule and the third request amount, and obtaining the target leaf node corresponding to the business request; and allocating the business request according to the fourth request amount corresponding to the target leaf node.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a request allocation method, device, electronic device and storage medium. Background Art

[0002] In current production business systems, we often encounter scenarios where we need to call a capability that has multiple service providers in the business process (such as connecting a standard transaction process to multiple user channels, connecting the SMS function to multiple platform service providers, building a self-built service as a backup for the supplier's cloud service, etc.).

[0003] In the existing technical solutions, there are usually the following problems and shortcomings:

[0004] 1. Request allocation based on business rules (usually through hard coding or configuration files) and request allocation based on flow control (usually based on underlying technical means) are separated from each other, which makes it difficult to coordinate and control. For example, all requests in a certain business scenario call different providers according to a specified ratio.

[0005] 2. Common traffic control measures are load balancing between different machine nodes under the same service provider. There is a lack of perfect solutions for traffic control between multiple service providers.

[0006] 3. In the scenario of flow control, the traditional counting-based flow limiting technology may cause uneven actual flow due to the coarse window granularity, as shown in the following example. And because of the network overhead between consumers and providers, and the inability to strictly align the time windows of both parties, the difference will be magnified, causing the peak flow actually received by the provider to be higher than the peak flow controlled by the consumer. Summary of the invention

[0007] The technical problem to be solved by the embodiments of the present application is to provide a request allocation method, device, electronic device and storage medium, so as to effectively solve the problem of uneven traffic caused by the counter-based current limiting method and the mismatch between the peak traffic of the consumer and the provider, realize fine control of request allocation, and solve the problem of uneven traffic at the same time.

[0008] In a first aspect, an embodiment of the present application provides a request allocation method, the method comprising:

[0009] Obtaining a first request amount and a second request amount of a root node and a leaf node of a decision tree, respectively, for each unit time within a preset time length from a current time, wherein the decision tree is composed of the root node, the rule node, and the leaf node, wherein the root node refers to a node corresponding to a service interface for receiving service requests, the rule node refers to a node for determining a request direction according to a rule, and the leaf node refers to a node corresponding to a service provider that provides a specified capability;

[0010] Predicting a third request amount of the root node in the next unit time according to the first request amount, and predicting a fourth request amount of the leaf node in the next unit time according to the second request amount;

[0011] Calling the rule node to perform node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount, and obtaining a target leaf node corresponding to the service request;

[0012] The service request is allocated according to the fourth request amount corresponding to the target leaf node.

[0013] In a second aspect, an embodiment of the present application provides a request allocation device, the device comprising:

[0014] A request volume acquisition module, used to obtain the first request volume and the second request volume of the root node and the leaf node of the decision tree for each unit time within a preset time length from the current time, respectively. The decision tree is composed of the root node, the rule node and the leaf node. The root node refers to the node corresponding to the business interface that receives the business request, the rule node refers to the node used to determine the direction of the request according to the rule, and the leaf node refers to the node corresponding to the service provider that provides the specified capability;

[0015] a request volume prediction module, configured to predict a third request volume of the root node in the next unit time according to the first request volume, and to predict a fourth request volume of the leaf node in the next unit time according to the second request volume;

[0016] A target leaf node acquisition module is used to call the rule node to perform node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount, and obtain the target leaf node corresponding to the service request;

[0017] The service request allocation module is used to allocate the service request according to the fourth request amount corresponding to the target leaf node.

[0018] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0019] A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, any one of the request allocation methods described above is implemented.

[0020] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium. When instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any of the request allocation methods described above.

[0021] Compared with the prior art, the embodiments of the present application have the following advantages:

[0022] In the embodiment of the present application, by obtaining the first request amount and the second request amount of each unit time within the preset time length from the current time of the root node and the leaf node of the decision tree, the decision tree is composed of the root node, the rule node and the leaf node, the root node refers to the node corresponding to the business interface receiving the business request, the rule node refers to the node used to judge the request direction according to the rule, and the leaf node refers to the node corresponding to the service provider providing the specified capability. The third request amount of the root node in the next unit time is predicted according to the first request amount, and the fourth request amount of the leaf node in the next unit time is predicted according to the second request amount. The rule node is called according to the preset judgment rule and the third request amount, and the node direction judgment of the business request received by the business interface is obtained to obtain the target leaf node corresponding to the business request. According to the fourth request amount corresponding to the target leaf node, the business request is allocated. The embodiment of the present application can realize multi-dimensional real-time statistics of requests and request allocation based on rules and statistics for calling different provider services by designing a decision tree structure with rule execution and statistical functions, so as to realize various types of fine control for request allocation in production business. At the same time, the problem of limiting the number of requests is transformed into a problem of distributing requests with a certain probability, so that the request flow is completely smooth and uniform while ensuring the flow limiting effect remains unchanged, solving the problems of uneven flow caused by the counter-based flow limiting method and the mismatch in peak flow between consumers and providers.

[0023] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A flowchart of a request allocation method provided in an embodiment of the present application;

[0025] Figure 2 A flowchart of a method for predicting request volume provided in an embodiment of the present application;

[0026] Figure 3 A flowchart of a method for obtaining a result node provided in an embodiment of the present application;

[0027] Figure 4 A flowchart of a method for allocating service requests provided in an embodiment of the present application;

[0028] Figure 5 A schematic diagram of a rule node judgment process provided in an embodiment of the present application;

[0029] Figure 6A schematic diagram of another rule node judgment process provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of a request allocation process provided in an embodiment of the present application;

[0031] Figure 8 A schematic diagram of a request volume prediction provided in an embodiment of the present application;

[0032] Fig. 9 A schematic diagram of a request statistics and allocation decision execution process provided in an embodiment of the present application;

[0033] Fig.10 A schematic diagram of the structure of a request allocation device provided in an embodiment of the present application;

[0034] Fig.11 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0036] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0037] Reference Figure 1 , shows a flowchart of the steps of a request allocation method provided by an embodiment of the present application, such as Figure 1 As shown, the request allocation method may include: step 101, step 102, step 103 and step 104.

[0038] Step 101: Obtain the first request amount and the second request amount of the root node and the leaf node of the decision tree for each unit time within a preset time length from the current time, respectively. The decision tree is composed of the root node, the rule node and the leaf node. The root node refers to the node corresponding to the business interface that receives the business request, the rule node refers to the node used to determine the direction of the request according to the rule, and the leaf node refers to the node corresponding to the service provider that provides the specified capability.

[0039] In this embodiment, the decision tree can be composed of a root node, a rule node and a leaf node, which can be generated by integrating business rules and traffic control policies. The input of the decision tree can include request contexts such as request interface, request parameters, user information, etc. for decision-making. The decision tree is executed and finally outputs the supplier for which the request is allocated.

[0040] The root node refers to the node corresponding to the business interface that receives the business request. The root node is the starting point of the decision tree. In the context of business routing, the root node can be regarded as an entry point. All business requests entering the system will first pass through the root node.

[0041] A rule node is a node used to determine the direction of a request based on a rule. A rule node is an intermediate node in a decision tree. When a request reaches a rule node, the node will evaluate the request based on the preset rules and direct the request to the next node (which may be another rule node or a leaf node) based on the evaluation result. Figure 5 As shown, rule node 1 can determine the direction of the incoming request based on conditions 1.1 and 1.2. If condition 1.1 is met, the request is assigned to result node 1. If condition 1.2 is met, rule node 2 is used to determine the direction of the request that meets condition 1.2 based on conditions 2.1 and 2.2. Requests that meet condition 2.1 are assigned to result node 2, and requests that meet condition 2.2 are assigned to result node 3, and so on.

[0042] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0043] Leaf nodes are nodes corresponding to service providers that provide specified capabilities. Leaf nodes are the end points of the decision tree. In the context of business routing, leaf nodes can be regarded as service providers, which are responsible for processing business requests that arrive here. In this example, a leaf node can include one service provider or multiple service providers.

[0044] The first request quantity refers to the number of requests per unit time of the root node within a preset time length from the current time.

[0045] The second request quantity refers to the number of requests per unit time of the leaf node within a preset time length from the current time.

[0046] The preset duration may be 30 minutes, 3 hours, etc. Specifically, the specific value of the preset duration may be determined according to business requirements, and this embodiment does not impose any limitation on this.

[0047] The unit time can be a time period of every minute, every 30 seconds, etc. within the preset duration. For example, the preset duration is 10 minutes, and 0 to 10 minutes can be divided into 10 time periods, each minute being a time period, i.e. 0 to 1, 1 to 2, ..., 9 to 10, and each time period can be used as a unit time, etc.

[0048] When performing request allocation, the first request amount and the second request amount of the root node and the leaf node of the decision tree can be obtained for each unit time within the preset time length from the current time. In a specific implementation, statistical units (such as statistical threads, etc.) can be set at the root node and the leaf node respectively, and the statistical unit of the root node can be used to count the first request amount of the root node for each unit time within the preset time length from the current time. The statistical unit of the leaf node can be used to count the second request amount of the leaf node for each unit time within the preset time length from the current time. The statistical unit can be used to count the incoming request amount at the unit time granularity, and can also obtain the historical and real-time request amounts of multiple unit times in the recent period, and calculate the request amount for the next unit time based on the recent history.

[0049] After obtaining the first request amount and the second request amount of the root node and the leaf node of the decision tree at each unit time within a preset time length from the current time, step 102 is performed.

[0050] Step 102: Predicting a third request volume of the root node in the next unit time based on the first request volume, and predicting a fourth request volume of the leaf node in the next unit time based on the second request volume.

[0051] The third request quantity refers to the predicted number of requests that the root node will receive in the next unit time.

[0052] The fourth request quantity refers to the predicted number of requests of the leaf node in the next unit time.

[0053] After obtaining the first request amount and the second request amount, the third request amount of the root node in the next unit time can be predicted based on the first request amount, and the fourth request amount of the leaf node in the next unit time can be predicted based on the second request amount. In this embodiment, the weight corresponding to each unit time within the preset time length can be obtained, and then the first request amount and the second request amount are weighted and summed respectively in combination with the weights to obtain the corresponding third request amount and fourth request amount respectively. Figure 2 This is described in detail as follows.

[0054] Reference Figure 2 , shows a flowchart of the steps of a request volume prediction method provided by an embodiment of the present application. Figure 2As shown, the request volume prediction method may include: step 201, step 202 and step 203.

[0055] Step 201: Obtain the weight corresponding to each unit time within the preset time length.

[0056] In this embodiment, the weight corresponding to each unit time within the preset duration can be obtained. The sum of the weights of all unit times within the preset duration is 1, and considering that the closer the time is, the more it can reflect the current request call situation, the front weight can be set smaller and the back weight can be set larger. The unit time closer to the current time has a larger weight, and the unit time farther from the current time has a smaller weight.

[0057] After the weight corresponding to each unit time within the preset duration is obtained, step 202 and step 203 are executed.

[0058] Step 202: performing weighted summation on the first request quantity per unit time within the preset duration and the weight corresponding to each unit time to obtain the third request quantity.

[0059] After obtaining the weight corresponding to each unit time within the preset duration, the first request amount for each unit time within the preset duration and the weight corresponding to each unit time can be weighted and summed to obtain the third request amount. For example, if the preset duration is 10 minutes, 0 to 10 minutes can be divided into 10 time periods, each minute is a time period, that is, 0 to 1, 1 to 2, ..., 9 to 10, and the weights corresponding to the 10 unit times are weight 1, weight 2, ..., weight 10, and the first request amounts corresponding to the 10 unit times are: request amount 1, request amount 2, ..., request amount 10, then the third request amount = weight 1 × request amount 1 + weight 2 × request amount 2 + ... + weight 10 × request amount 10, etc.

[0060] Step 203: performing weighted summation on the second request quantity per unit time within the preset time length and the weight corresponding to each unit time to obtain the fourth request quantity.

[0061] After obtaining the weight corresponding to each unit time within the preset duration, the second request quantity for each unit time within the preset duration and the weight corresponding to each unit time can be weighted and summed to obtain the fourth request quantity. The calculation method is similar to the calculation method of the third request quantity in the above step 202, and this embodiment will not be repeated here.

[0062] The calculation method for predicting the request volume can be combined with Figure 8 The following description is given.

[0063] like Figure 8 As shown, the number of requests in the past s units of time can be counted, and s units of time can be recorded as: [t n-s+1 ,t n-s+2 ,t n-s+3 ,...,t n-2 ,t n-1 ,t n ], s units of time [t n-s+1 ,t n-s+2 ,t n-s+3 ,...,t n-2 ,t n-1 ,t n ] are as follows: n-s+1 ,q n-s+2 ,q n-s+3 ,...,q n-2 ,q n-1 ,q n ], and the weights of the past s units of time are set as follows: [w n-s+1 ,w n-s+2 ,w n-s+3 ,...,w n-2 ,w n-1 ,w n ]. Then the calculation formula for the predicted request volume f1 of the next unit time can be as follows:

[0064] f1=q n-s+1 × n-s+1 +q n-s+2 × n-s+2 +q n-s+3 × n-s+3 +...+q n-2 × n-2 +q n-1 × n-1 +q n × n

[0065] After the measurement is completed, the predicted request volume can be updated, and the predicted request volume for the next unit time can be predicted, etc.

[0066] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0067] After the third request amount of the root node in the next unit time is predicted based on the first request amount, and the fourth request amount of the leaf node in the next unit time is predicted based on the second request amount, step 103 is executed.

[0068] Step 103: Call the rule node to perform node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount, and obtain the target leaf node corresponding to the service request.

[0069] After obtaining the third request volume, the rule node can be called to perform node direction judgment on the business request received by the business interface according to the preset judgment rules and the third request volume to obtain the target leaf node corresponding to the business request, wherein the target leaf node is the node in the leaf node that processes the received business request, and the target leaf node is the result node.

[0070] In this example, the preset judgment rules can be scene judgment rules and request volume judgment rules. The process of performing request judgment result trend according to the preset judgment rules can be combined with Figure 3 This is described in detail as follows.

[0071] Reference Figure 3 , shows a flowchart of the steps of a method for obtaining a result node provided by an embodiment of the present application. Figure 3 As shown, the result node acquisition method may include: step 301 and step 302.

[0072] Step 301: calling the rule node to perform node direction judgment on the business request according to the scenario judgment rule, and obtaining business requests under different business scenarios.

[0073] In this embodiment, the rule node may be called to perform node direction judgment on the service request according to the scenario judgment rule to obtain the service requests under different service scenarios.

[0074] Of course, in actual applications, a statistical unit can also be built into the rule node. The statistical unit of the rule node can be used to obtain the number of requests for the corresponding business scenario, such as the number of pick-up route plans is 100, the number of drop-off route plans is 900, and so on.

[0075] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions provided by the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0076] After the calling rule node performs node trend judgment on the business request according to the scenario judgment rule to obtain business requests under different business scenarios, step 302 is executed.

[0077] Step 302: According to the request volume judgment rule, the node trend of the business request volume in each business scenario is judged according to the third request volume, and the target leaf nodes corresponding to the business requests in different business scenarios are obtained.

[0078] After the calling rule node performs node direction judgment on the business request according to the scenario judgment rule to obtain the business requests under different business scenarios, the node direction judgment can be performed on the business requests under each business scenario according to the third request volume according to the request volume judgment rule to obtain the target leaf node (i.e., the result node in the leaf node) corresponding to the business request under different business scenarios. The above judgment process can be as follows Figure 6 As shown, rule node 1 can make a judgment based on the business scenario and assign the business request belonging to business scenario 1 to result node 1 (the request is processed by supplier A under result node 1). Then, rule node 2 can be used to make a judgment on QPS (Queries Per Second, that is, the number of requests that the system can process per second). If the number of business requests counted by the root node is less than 1000, the business request belonging to business scenario 2 is assigned to result node 2, so that supplier A under result node 2 processes the request. If the number of business requests counted by the root node is greater than or equal to 1000, the business request belonging to business scenario 2 is assigned to result node 3, so that supplier A under the result node processes the business requests within 1000, and supplier B under result node 3 processes the business requests exceeding 1000 (including 1000), etc.

[0079] It can be understood that the above examples are merely examples listed for a better understanding of the technical solutions of the embodiments of the present application, and are not intended to be the sole limitation to the embodiments.

[0080] The embodiments of the present application can facilitate management and maintenance by uniformly maintaining a request allocation scheme based on business rules and flow control.

[0081] After the calling rule node performs node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount and obtains the target leaf node corresponding to the service request, step 104 is executed.

[0082] Step 104: Allocate the service request according to the fourth request amount corresponding to the target leaf node.

[0083] After the calling rule node judges the node direction of the service request received by the service interface according to the preset judgment rule and the third request amount, and obtains the target leaf node corresponding to the service request, the service request can be allocated according to the fourth request amount corresponding to the target leaf node. In this example, the service provider under the target leaf node is determined based on the size relationship between the fourth request amount and the request amount threshold. Figure 4 This is described in detail as follows.

[0084] Reference Figure 4, shows a flow chart of the steps of a service request allocation method provided by an embodiment of the present application. Figure 4 As shown, the service request allocation method may include: step 401 and step 402.

[0085] Step 401: Obtain the limit condition of the target leaf node.

[0086] In this embodiment, the limiting condition refers to a condition that the target leaf node limits the number of requests per unit time.

[0087] After obtaining the target leaf node corresponding to the business request, the limit condition of the target leaf node can be obtained.

[0088] Step 402: Allocate the service requests of the fourth request quantity of the target leaf node according to the fourth request quantity of the target leaf node and the limit condition of the target leaf node.

[0089] After the limit condition of the target leaf node is obtained, the service requests of the fourth request quantity of the target leaf node can be allocated according to the fourth request quantity of the target leaf node and the limit condition of the target leaf node. Figure 7 As shown, for business requests greater than or equal to 1000, they can be assigned to result node 3 for processing, so that supplier A can process the part within 1000, and supplier B can process the part exceeding 1000.

[0090] According to the fourth request amount of the target leaf node and the limit condition of the target leaf node, the manner of allocating the service requests of the fourth request amount of the target leaf node may include the following four specific implementation manners:

[0091] In a specific implementation of the present application, when the number of service providers of the target leaf node is one and the limit condition is an unlimited number condition, the business requests of the fourth request amount of the target leaf node are allocated to the service provider of the target leaf node. That is, when there is only one service provider of the target leaf node and the number of requests is not limited, all the business requests of the fourth request amount are allocated to the service provider.

[0092] In the second specific implementation manner of the present application, when the number of service providers at the target leaf node is one and the limit condition is the limit per unit time, obtain the first limited request volume of the service provider per unit time. When the fourth request volume is less than or equal to the first limited request volume, allocate the service requests with the fourth request volume to the service provider at the target leaf node. When the fourth request volume is greater than the first limited request volume, generate the first random number corresponding to each service request with the fourth request volume, allocate the service requests with the first random number less than or equal to the first value among the service requests with the fourth request volume to the service provider under the target leaf node, and intercept the service requests with the first random number greater than the first value among the service requests with the fourth request volume, where the first value is the ratio of the first limited request volume to the fourth request volume.

[0093] For example, for a single supplier with a limited request volume and the limit request volume per unit time is l.

[0094] Obtain the next unit time request volume n measured by the statistical unit of the result node.

[0095] If n ≤ l, directly call the supplier, that is, allocate all service requests going to the result node to the supplier.

[0096] If n > l, call the supplier with a probability of l / n (i.e., the first value in this example). Specifically, a random number in the range [0, 1] can be generated. If the random number ≤ l / n, call the supplier; otherwise, do not call.

[0097] In the third embodiment of the present application, when the number of service providers at the target leaf node is multiple and the limit condition is the proportional allocation condition, obtain the allocation ratios of the multiple service providers of the target leaf node set in advance. And allocate the service requests with the fourth request volume to the multiple service providers of the target leaf node according to the allocation ratios of the multiple service providers.

[0098] For example, for multiple suppliers with proportional allocation, and the ratios of each supplier are p1, p2...

[0099] Call the corresponding suppliers with probabilities of p1, p2... Specifically, generate a random number in the range [0, 1]. If the random number < p1, call the first supplier; if the random number ≥ p1 and the random number < p1 + p2, call the second supplier, and so on.

[0100] In the fourth embodiment of the present application, when there are multiple service providers of the target leaf node and the limit condition is a condition of limit per unit time, the second limited request quantity per unit time of the multiple service providers of the target leaf node is obtained. According to the multiple second limited request quantities, the total limited request quantity of the target leaf node is determined. When the fourth request quantity is less than or equal to the total limited request quantity, the business requests of the fourth request quantity are allocated to the multiple service providers under the target leaf node according to the second limited request quantity of each service provider and the pre-set allocation ratio of the multiple service providers. When the fourth request quantity is greater than or equal to the total limited request quantity, a second random number of business requests of the fourth request quantity is generated, and the target business request is screened out from the business requests of the fourth request quantity according to the second random number, and the target business request is allocated to the multiple service providers under the target leaf node according to the second limited request quantity of each service provider and the pre-set allocation ratio of the multiple service providers.

[0101] For example, multiple suppliers limit the request quantity, and the request quantity per unit time is l1, l2, etc.

[0102] The request quantity n for the next unit time measured by the statistical unit of the result node is obtained, and the total limit request quantity l=l1+l2+… is calculated.

[0103] If n≤l, multiple suppliers will be allocated proportionally, where the allocation ratios are: p1=l1 / l, p2=l2 / l...

[0104] If n>l, first determine whether to call with a probability of l / n. If a call is made, allocate it to multiple suppliers in proportion, where p1=l1 / l, p2=l2 / l...

[0105] like Fig. 9 As shown in the figure, result nodes 1 and 2, namely [Supplier A], only contain one result item of the full amount of supplier A (type 1). Result node 3, namely [Supplier A (part within 1000), Supplier B (part exceeding 1000)], consists of two result items: (a) Supplier A limited to 1000 QPS (type 2); (b) Supplier B full amount (type 1).

[0106] The embodiment of the present application transforms the problem of limiting the number of requests into the problem of distributing requests with a certain probability, thereby ensuring that the flow of requests is completely smooth and uniform while ensuring that the limiting effect remains unchanged. At the same time, the embodiment of the present application disassembles all supplier allocation plans into a sequence of four basic types of result items, and binds statistical units, which can flexibly support various types of fine control of request allocation in production business.

[0107] The request allocation method provided in the embodiment of the present application obtains the first request amount and the second request amount of each unit time within the preset time length from the current time of the root node and the leaf node of the decision tree, respectively. The decision tree is composed of the root node, the rule node and the leaf node. The root node refers to the node corresponding to the business interface receiving the business request, the rule node refers to the node used to judge the request direction according to the rule, and the leaf node refers to the node corresponding to the service provider providing the specified capability. The third request amount of the root node in the next unit time is predicted according to the first request amount, and the fourth request amount of the leaf node in the next unit time is predicted according to the second request amount. The rule node is called to judge the node direction of the business request received by the business interface according to the preset judgment rule and the third request amount, and the target leaf node corresponding to the business request is obtained. According to the fourth request amount corresponding to the target leaf node, the business request is allocated. The embodiment of the present application can realize multi-dimensional real-time statistics of requests and request allocation based on rules and statistics for calling different provider services by designing a decision tree structure with rule execution and statistical functions, so as to realize fine control of various types of request allocation in production business. At the same time, the problem of limiting the number of requests is transformed into a problem of distributing requests with a certain probability, so that the request flow is completely smooth and uniform while ensuring the flow limiting effect remains unchanged, solving the problems of uneven flow caused by the counter-based flow limiting method and the mismatch in peak flow between consumers and providers.

[0108] Reference Fig.10 , shows a schematic diagram of the structure of a request allocation device provided in an embodiment of the present application, such as Fig.10 As shown, the request allocation device 1000 may include the following modules:

[0109] The request volume acquisition module 1001 is used to obtain the first request volume and the second request volume of the root node and the leaf node of the decision tree within a preset time length from the current time, respectively, and the decision tree is composed of the root node, the rule node and the leaf node. The root node refers to the node corresponding to the business interface that receives the business request, the rule node refers to the node used to determine the direction of the request according to the rule, and the leaf node refers to the node corresponding to the service provider that provides the specified capability;

[0110] A request volume prediction module 1002 is used to predict a third request volume of the root node in the next unit time according to the first request volume, and to predict a fourth request volume of the leaf node in the next unit time according to the second request volume;

[0111] The target leaf node acquisition module 1003 is used to call the rule node to perform node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount, and obtain the target leaf node corresponding to the service request;

[0112] The service request allocation module 1004 is used to allocate the service requests according to the fourth request amount corresponding to the target leaf node.

[0113] Optionally, the request volume prediction module includes:

[0114] A weight acquisition unit, used to acquire a weight corresponding to each unit time within the preset time length;

[0115] A third request quantity acquisition unit, configured to perform a weighted summation of the first request quantity per unit time within the preset duration and the weight corresponding to each unit time to obtain the third request quantity;

[0116] a fourth request quantity acquisition unit, configured to perform a weighted summation of the second request quantity per unit time within the preset time length and a weight corresponding to each unit time to obtain the fourth request quantity;

[0117] The sum of the weights of all unit times within the preset time length is 1.

[0118] Optionally, the target leaf node acquisition module includes:

[0119] A business request acquisition unit, used to call the rule node to perform node direction judgment on the business request according to the scenario judgment rule, and obtain business requests under different business scenarios;

[0120] The target leaf node acquisition unit is used to perform node trend judgment on the business requests in each business scenario according to the third request volume according to the request volume judgment rule, and obtain the target leaf nodes corresponding to the business requests in different business scenarios.

[0121] Optionally, the service request allocation module includes:

[0122] A limit condition acquisition unit, used to acquire the limit condition of the target leaf node;

[0123] The service request allocation unit is used to allocate the service requests of the fourth request amount of the target leaf node according to the fourth request amount of the target leaf node and the limit condition of the target leaf node.

[0124] Optionally, the service request allocation unit includes:

[0125] The first request allocation subunit is used to allocate the business requests of the fourth request quantity of the target leaf node to the service providers under the target leaf node when the number of service providers of the target leaf node is one and the limit condition is an unlimited number condition.

[0126] Optionally, the service request allocation unit includes:

[0127] A first limited quantity acquisition subunit is used to acquire a first limited request quantity per unit time of the service provider when the number of the service provider of the target leaf node is one and the limited condition is a condition of limited quantity per unit time;

[0128] A second request allocation subunit is used to allocate the business requests of the fourth request amount to the service provider under the target leaf node when the fourth request amount is less than or equal to the first limited request amount;

[0129] a third request allocation subunit, configured to, when the fourth request amount is greater than the first limited request amount, generate a first random number corresponding to each service request of the fourth request amount, allocate the service requests whose first random number is less than or equal to the first value among the service requests of the fourth request amount to the service providers under the result nodes of each service scenario, and intercept the service requests whose first random number is greater than the first value among the service requests of the fourth request amount;

[0130] The first value is a ratio of the first limited requested amount to the fourth requested amount.

[0131] Optionally, the service request allocation unit includes:

[0132] an allocation ratio acquisition subunit, configured to acquire a preset allocation ratio of multiple service providers of the target leaf node when there are multiple service providers of the target leaf node and the limit condition is a condition of proportional allocation;

[0133] The fourth request allocation subunit is used to allocate the business requests of the fourth request amount to multiple service providers of the target leaf node according to the allocation ratio.

[0134] Optionally, the service request allocation unit includes:

[0135] A second limited quantity acquisition subunit is used to acquire the second limited request quantities per unit time of the multiple service providers of the target leaf node respectively when there are multiple service providers of the target leaf node and the limited condition is a condition of limited quantity per unit time;

[0136] A limited total amount determination subunit, configured to determine a limited total amount of requests for the target leaf node according to a plurality of the second limited request amounts;

[0137] a fifth request allocation subunit, configured to allocate the business requests of the fourth request amount to the multiple service providers of the target leaf node according to the second limited request amount of each of the service providers and a preset allocation ratio of the multiple service providers when the fourth request amount is less than or equal to the limited total request amount;

[0138] The sixth request allocation subunit is used to generate a second random number of business requests for the fourth request amount when the fourth request amount is greater than or equal to the limited total request amount, filter out target business requests from the business requests for the fourth request amount according to the second random number, and allocate the target business requests to multiple service providers of the target leaf node according to the second limited request amount of each service provider and a pre-set allocation ratio of the multiple service providers.

[0139] The request allocation device provided in the embodiment of the present application obtains the first request amount and the second request amount of each unit time within the preset time length from the root node and the leaf node of the decision tree, respectively. The decision tree is composed of the root node, the rule node and the leaf node. The root node refers to the node corresponding to the business interface receiving the business request, the rule node refers to the node used to judge the request direction according to the rule, and the leaf node refers to the node corresponding to the service provider providing the specified capability. The third request amount of the root node in the next unit time is predicted according to the first request amount, and the fourth request amount of the leaf node in the next unit time is predicted according to the second request amount. The rule node is called to judge the node direction of the business request received by the business interface according to the preset judgment rule and the third request amount, and the target leaf node corresponding to the business request is obtained. According to the fourth request amount corresponding to the target leaf node, the business request is allocated. The embodiment of the present application can realize multi-dimensional real-time statistics of requests and request allocation based on rules and statistics for calling different provider services by designing a decision tree structure with rule execution and statistical functions, so as to realize fine control of various types of request allocation in production business. At the same time, the problem of limiting the number of requests is transformed into a problem of distributing requests with a certain probability, so that the request flow is completely smooth and uniform while ensuring the flow limiting effect remains unchanged, solving the problems of uneven flow caused by the counter-based flow limiting method and the mismatch in peak flow between consumers and providers.

[0140] An embodiment of the present application further provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the above-mentioned request allocation method when executed by the processor.

[0141] Fig.11 FIG. 1 is a schematic diagram showing the structure of an electronic device 1100 according to an embodiment of the present invention. Fig.11As shown, the electronic device 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 1102 or computer program instructions loaded from a storage unit 1108 to a random access memory (RAM) 1103. In the RAM 1103, various programs and data required for the operation of the electronic device 1100 can also be stored. The CPU 1101, the ROM 1102, and the RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0142] Multiple components in the electronic device 1100 are connected to the I / O interface 1105, including: an input unit 1106, such as a keyboard, a mouse, a microphone, etc.; an output unit 1107, such as various types of displays, speakers, etc.; a storage unit 1108, such as a disk, an optical disk, etc.; and a communication unit 1109, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 1109 allows the electronic device 1100 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0143] The various processes and processing described above may be performed by the processing unit 1101. For example, the method of any of the above embodiments may be implemented as a computer software program, which is tangibly contained in a computer-readable medium, such as the storage unit 1108. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 1100 via the ROM 1102 and / or the communication unit 1109. When the computer program is loaded into the RAM 1103 and executed by the CPU 1101, one or more actions in the method described above may be performed.

[0144] In addition, an embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned request allocation method is implemented.

[0145] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0146] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminals (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0148] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0149] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal so that a series of operating steps are executed on the computer or other programmable terminal to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable terminal. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0150] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0151] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or terminal including the elements.

[0152] The above is a detailed introduction to a request allocation method, a request allocation device, an electronic device and a computer-readable storage medium provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for a person skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A request allocation method, characterized in that: The method comprises: Obtaining a first request amount and a second request amount of a root node and a leaf node of a decision tree, respectively, for each unit time within a preset time length from a current time, wherein the decision tree is composed of the root node, the rule node, and the leaf node, wherein the root node refers to a node corresponding to a service interface for receiving service requests, the rule node refers to a node for determining a request direction according to a rule, and the leaf node refers to a node corresponding to a service provider that provides a specified capability; Predicting a third request amount of the root node in the next unit time according to the first request amount, and predicting a fourth request amount of the leaf node in the next unit time according to the second request amount; Calling the rule node to perform node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount, and obtaining a target leaf node corresponding to the service request; The service requests are allocated according to the fourth request amount corresponding to the target leaf node.

2. The method according to claim 1, characterized in that The predicting of obtaining a third request amount of the root node in a next unit time according to the first request amount, and predicting of obtaining a fourth request amount of the leaf node in a next unit time according to the second request amount, includes: Obtaining a weight corresponding to each unit time within the preset duration; Performing a weighted summation on the first request amount per unit time within the preset time length and the weight corresponding to each unit time to obtain the third request amount; Performing a weighted summation on the second request amount per unit time within the preset time length and the weight corresponding to each unit time to obtain the fourth request amount; The sum of the weights of all unit times within the preset time length is 1.

3. The method according to claim 1, characterized in that The calling of the rule node performs node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount to obtain the target leaf node corresponding to the service request, including: Calling the rule node to perform node direction judgment on the business request according to the scenario judgment rule to obtain business requests under different business scenarios; According to the request volume judgment rule, the node direction of the business request in each business scenario is judged according to the third request volume, so as to obtain the target leaf nodes corresponding to the business requests in different business scenarios.

4. The method according to claim 3, characterized in that: The allocating the service request according to the fourth request amount corresponding to the target leaf node includes: Obtaining the limiting condition of the target leaf node; The service requests for the fourth request amount of the target leaf node are allocated according to the fourth request amount of the target leaf node and the limit condition of the target leaf node.

5. The method according to claim 4, characterized in that The allocating the service requests of the fourth request amount of the target leaf node according to the fourth request amount of the target leaf node and the limit condition of the target leaf node includes: When the number of service providers of the target leaf node is one and the limit condition is an unlimited number condition, the business requests of the fourth request quantity of the target leaf node are allocated to the service providers under the target leaf node.

6. The method according to claim 4, characterized in that The allocating the service requests of the fourth request amount of the target leaf node according to the fourth request amount of the target leaf node and the limit condition of the target leaf node includes: When the number of service providers of the target leaf node is one and the limit condition is a condition of limit per unit time, obtaining a first limited request quantity of the service provider per unit time; In a case where the fourth request amount is less than or equal to the first limited request amount, allocating the service requests of the fourth request amount to the service provider under the target leaf node; In the case where the fourth request amount is greater than the first limited request amount, generating a first random number corresponding to each service request of the fourth request amount, allocating service requests whose first random number is less than or equal to the first value among the service requests of the fourth request amount to the service provider under the target leaf node, and intercepting service requests whose first random number is greater than the first value among the service requests of the fourth request amount; The first value is a ratio of the first limited requested amount to the fourth requested amount.

7. The method according to claim 4, characterized in that The allocating the service requests of the fourth request amount of the target leaf node according to the fourth request amount of the target leaf node and the limit condition of the target leaf node includes: When there are multiple service providers of the target leaf node and the limit condition is a condition of proportional allocation, obtaining a preset allocation ratio of the multiple service providers of the target leaf node; According to the allocation ratio, the business requests of the fourth request amount are allocated to multiple service providers of the target leaf node.

8. The method according to claim 4, characterized in that The allocating the service requests of the fourth request amount of the target leaf node according to the fourth request amount of the target leaf node and the limit condition of the target leaf node includes: When there are multiple service providers of the target leaf node and the limit condition is a condition of limit per unit time, obtaining the second limited request quantities per unit time of the multiple service providers of the target leaf node respectively; Determining the total limited request amount of the target leaf node according to the plurality of the second limited request amounts; In the case where the fourth request amount is less than or equal to the limited total request amount, allocating the business requests of the fourth request amount to the multiple service providers of the target leaf node according to the second limited request amount of each of the service providers and a preset allocation ratio of the multiple service providers; In the case where the fourth request amount is greater than or equal to the limited total request amount, a second random number of business requests for the fourth request amount is generated, target business requests are screened out from the business requests for the fourth request amount according to the second random number, and the target business requests are allocated to multiple service providers of the target leaf node according to the second limited request amount of each service provider and a pre-set allocation ratio of multiple service providers.

9. A request allocation device, characterized in that: The device comprises: A request volume acquisition module, used to obtain the first request volume and the second request volume of the root node and the leaf node of the decision tree for each unit time within a preset time length from the current time, respectively. The decision tree is composed of the root node, the rule node and the leaf node. The root node refers to the node corresponding to the business interface that receives the business request, the rule node refers to the node used to determine the direction of the request according to the rule, and the leaf node refers to the node corresponding to the service provider that provides the specified capability; a request volume prediction module, configured to predict a third request volume of the root node in the next unit time according to the first request volume, and to predict a fourth request volume of the leaf node in the next unit time according to the second request volume; A target leaf node acquisition module is used to call the rule node to perform node direction judgment on the service request received by the service interface according to the preset judgment rule and the third request amount, and obtain the target leaf node corresponding to the service request; The service request allocation module is used to allocate the service request according to the fourth request amount corresponding to the target leaf node.

10. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements the request allocation method according to any one of claims 1 to 8 when executing the program.

11. A computer-readable storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the request allocation method according to any one of claims 1 to 8.

Images