A method and apparatus for processing a service request

Abstract

The application discloses a kind of processing method and device of service request, including: service system receives service request, when according to historical service request execution condition judging service request meets service protection condition, obtain interceptor task hierarchical chain;Interceptor task hierarchical chain is divided into different levels according to execution order for all interceptor components in service system, and there is no dependent relationship between each interceptor component in the same level;According to interceptor task hierarchical chain, the interceptor component of each level is called in turn, to determine whether service request needs to be intercepted;After service request is not intercepted by each interceptor component in the interceptor task hierarchical chain, the business logic of service request is executed.

Description

Technical Field

[0001] This invention relates to the field of financial technology (Fintech), and more particularly to a method and apparatus for processing business requests. Background Technology

[0002] With the development of computer technology, more and more technologies (such as blockchain, cloud computing or big data) are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology, and big data technology is no exception. However, due to the security and real-time requirements of the financial and payment industries, higher requirements are also placed on the processing of business requests in big data technology.

[0003] In existing technologies, interceptor components are used to intercept and process business requests, such as verifying the network address of business requests, blocking unlogged users, and auditing logs. Specifically, the configuration of the interceptor component for any business activity is user-defined. For business requests within a business activity, the interceptor component is invoked to intercept the requests.

[0004] Currently, for any business activity, multiple interceptor components are called sequentially for business requests. For example, a transaction request in a shopping activity includes two security interceptor components A and B to perform security interception of the transaction request and a payment interceptor component C to provide a payment channel. The order of calling the interceptor components is A, B, C.

[0005] However, in the above technical solution, for payment interceptor component C, the call is only made after security interceptor components A and B have completed their calls and the business request has passed, to ensure payment security. But for security interceptor components A and B, which are used to verify the security of the business request, the order of calls does not need to be considered; that is, serial calls are not required. Interceptor components A and B can be called in parallel. Serial calls would lead to long call times for the interceptor components, resulting in long processing times for the business request and low efficiency.

[0006] Therefore, there is a need for an interceptor component invocation method to reduce the interceptor component invocation time, thereby shortening the interception time of business requests and improving the efficiency of business request processing. Summary of the Invention

[0007] This invention provides a method and apparatus for processing business requests, which reduces the call time of interceptor components, thereby shortening the interception time of business requests and improving the efficiency of business request processing.

[0008] In a first aspect, embodiments of the present invention provide a method for processing service requests, comprising:

[0009] The business system receives business requests;

[0010] The business system determines the business protection conditions for the business request based on the set factors in the business request; the business protection conditions are used to ensure that the execution response of the business request meets the set requirements.

[0011] The business system determines whether the business request meets the business protection conditions based on the historical business request execution status; if it does, it obtains the interceptor task hierarchy chain; the interceptor task hierarchy chain is a hierarchy of interceptor components in the business system divided into different levels according to the execution order, and there is no dependency between interceptor components in the same level.

[0012] The business system calls the interceptor components at each level in sequence according to the interceptor task hierarchy chain to determine whether the business request needs to be intercepted.

[0013] The business system executes the business logic of the business request after the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy chain.

[0014] In the above technical solution, the interceptor task hierarchy chain includes multiple levels. Importantly, there is no dependency between the interceptor components at the same level. In other words, the interceptor components at the same level can be called concurrently, thereby reducing the call time of the interceptor components, thus shortening the interception time of business requests and improving the efficiency of business request processing. Furthermore, the interceptor task hierarchy chain has configurable, component-based, and portable features, making it easy for business systems to use.

[0015] The historical business request execution status in this invention is used to determine the processing status of business requests in real time, i.e., whether they were successful or not, so that users can be informed in real time and improve the user's business request experience. By setting factors and business protection conditions, resource protection is provided for business requests. Specifically, when a business request meets the business protection conditions, it is determined that the resource protection of the business request has passed, i.e., the execution of the business request is allowed, thereby improving the security of business request processing. The historical business request execution status is determined based on all business requests before this task request, i.e., it does not include the execution status of this business request.

[0016] Optionally, the setting factors in the business request include at least one of the following: interface, merchant, and channel;

[0017] The business protection conditions include at least one of the following: the request response time exceeds a time threshold; the sliding window failure rate of the business request exceeds a failure rate threshold; the number of business requests exceeds a request number threshold.

[0018] In the above technical solution, the setting factors include interfaces, merchants, and channels. This is because existing technologies only protect resources for business requests through interfaces, while this application also protects resources for merchants and channels, achieving differentiated resource protection for merchants and channels, thereby refining the granularity of business request protection.

[0019] Optionally, if a business request meets the aforementioned business protection conditions, the interceptor task hierarchy chain is obtained, including:

[0020] The business system determines whether the number of business requests exceeds the request threshold; if not, it obtains the interceptor task hierarchy chain.

[0021] If so, the sliding window failure rate of the business request is determined, and the interceptor task hierarchy chain is obtained when it is determined that the response time of the business request does not exceed the time threshold and the sliding window failure rate of the business request does not exceed the failure rate threshold.

[0022] In the above technical solution, a request number threshold is used to prevent the sliding window failure rate from being too high due to an insufficient number of business requests, thus avoiding the business system from incorrectly determining the execution status of business requests. The sliding window failure rate and time threshold of business requests are used to determine whether the current business requests are too congested, preventing the business system from avalanche.

[0023] Optionally, determining the sliding window failure rate of the service request includes:

[0024] The business system determines the failure rate of each small window in the sliding window based on the sliding window at the time of the business request.

[0025] The sum of the failure rates of the business requests in each of the small windows is determined as the sliding window failure rate of the business request.

[0026] In the above technical solution, the sliding window is the time window at the moment of the business request. Determining the failure rate within the sliding time window is used to improve the accuracy of the failure rate within the time window, that is, to improve the accuracy of the judgment of the current business request.

[0027] Optionally, the method further includes:

[0028] When the business system determines that a business request does not meet the business protection conditions based on the historical business request execution status, it collects the abnormal execution status of the business request and updates the historical business request execution status; the abnormal execution status includes the response time of the business request exceeding a time threshold and the sliding window failure rate of the business request exceeding a failure rate threshold.

[0029] The business system determines a rate limiting strategy based on the set factors according to the abnormal execution status; the rate limiting strategy includes a preset rate limiting algorithm.

[0030] In the above technical solution, when a business request fails to meet the business protection conditions, it proves that the current business requests are too congested and a certain strategy is needed to reduce the number of business requests. By analyzing the abnormal execution status of business requests, the corresponding rate limiting strategy is automatically determined and executed to achieve the automation of rate limiting. Moreover, the rate limiting strategy is targeted at the interface, merchant, and channel in the set factors, thereby refining the granularity of business request protection.

[0031] Optionally, before executing the business logic of the business request, the following steps are also included:

[0032] The business system determines whether the business request meets the isolation conditions based on the type of the business request and the interface that executes the business request; the interface has a preset method for whether to perform thread resource isolation.

[0033] If the conditions are met, the thread resources for the business request will be isolated.

[0034] In the above technical solution, the interface for executing the business request is determined by the type of the business request. The interface is pre-set with either a thread resource isolation method or a non-thread resource isolation method. By determining the interface for executing the business request, it is determined whether the business request needs to be thread resource isolated, thereby differentiating the business requests, that is, distinguishing the importance of the business requests, and avoiding failure or delay of important business requests.

[0035] Optionally, the interceptor task hierarchy chain is obtained in the following ways:

[0036] After the business system starts, it obtains each interceptor component with annotations.

[0037] The business system constructs a directed acyclic graph based on the dependencies between the interceptor components;

[0038] The business system determines the interceptor task hierarchy chain based on the directed acyclic graph.

[0039] In the above technical solution, the relationship between each interceptor component is determined by annotation. That is, for any interceptor component, other interceptor components that have a dependency relationship with it are identified. In this way, a directed acyclic graph can be constructed. Then, the interceptor task hierarchy chain is determined according to the direction of the directed acyclic graph, and then the interceptor components at each level without dependency relationship are identified, so as to realize the parallel invocation of interceptor components and reduce the invocation time of interceptor components.

[0040] Optionally, the business system sequentially calls the interceptor components at each level according to the interceptor task hierarchy chain, including:

[0041] For any interceptor component at a level to be invoked, determine whether the interceptor component at the level preceding the level to be invoked has been invoked; the level preceding the level is the one adjacent to the level to be invoked in the interceptor task hierarchy chain.

[0042] If so, the interceptor components in the level to be invoked are called in parallel;

[0043] Determine whether the level to be invoked has an interceptor component at the next level; the next level is the next level in the interceptor task hierarchy that is adjacent to the level to be invoked.

[0044] If so, update the level to be called to the next level.

[0045] In the above technical solution, the interceptor components are called in a hierarchical manner, which not only ensures the sequential dependency of the interceptor components in terms of calling order, but also reduces the calling time of the interceptor components, thereby shortening the interception time of business requests and improving the efficiency of business request processing.

[0046] Secondly, embodiments of the present invention provide a service request processing apparatus, comprising:

[0047] The receiving module is used to receive business requests;

[0048] The processing module is used to determine the service protection conditions of the service request based on the set factors in the service request; the service protection conditions are used to ensure that the execution response of the service request meets the set requirements;

[0049] Based on the historical execution status of business requests, determine whether the business request meets the business protection conditions; if it does, obtain the interceptor task hierarchy chain; the interceptor task hierarchy chain is a chain that divides all interceptor components in the business system into different levels according to the execution order, and there is no dependency between the interceptor components in the same level.

[0050] According to the interceptor task hierarchy chain, the interceptor components at each level are called sequentially to determine whether the business request needs to be intercepted.

[0051] After the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy, the business logic of the business request is executed.

[0052] Optionally, the setting factors in the business request include at least one of the following: interface, merchant, and channel;

[0053] The business protection conditions include at least one of the following: the request response time exceeds a time threshold; the sliding window failure rate of the business request exceeds a failure rate threshold; the number of business requests exceeds a request number threshold.

[0054] Optionally, the processing module is specifically used for:

[0055] Determine whether the number of business requests exceeds the request threshold; if not, obtain the interceptor task hierarchy chain.

[0056] If so, the sliding window failure rate of the business request is determined, and the interceptor task hierarchy chain is obtained when it is determined that the response time of the business request does not exceed the time threshold and the sliding window failure rate of the business request does not exceed the failure rate threshold.

[0057] Optionally, the processing module is specifically used for:

[0058] Based on the sliding window at the time of the business request, determine the business request failure rate of each small window in the sliding window;

[0059] The sum of the failure rates of the business requests in each of the small windows is determined as the sliding window failure rate of the business request.

[0060] Optionally, the processing module is further configured to:

[0061] When it is determined from the historical execution status of business requests that the business request does not meet the business protection conditions, the abnormal execution status of the business request is collected and the historical execution status of the business request is updated; the abnormal execution status includes the response time of the business request exceeding the time threshold and the sliding window failure rate of the business request exceeding the failure rate threshold.

[0062] A rate limiting strategy is determined based on the set factors according to the abnormal execution status; the rate limiting strategy includes a preset rate limiting algorithm.

[0063] Optionally, the processing module is further configured to:

[0064] Before executing the business logic of the business request, it is determined whether the business request meets the isolation conditions based on the type of the business request and the interface that executes the business request; the interface has a preset method for whether to perform thread resource isolation.

[0065] If the conditions are met, the thread resources for the business request will be isolated.

[0066] Optionally, the processing module is specifically used for:

[0067] Retrieve each interceptor component with annotations;

[0068] Construct a directed acyclic graph based on the dependencies between the interceptor components;

[0069] The interceptor task hierarchy chain is determined based on the directed acyclic graph.

[0070] Optionally, the processing module is specifically used for:

[0071] For any interceptor component at a level to be invoked, determine whether the interceptor component at the level preceding the level to be invoked has been invoked; the level preceding the level is the one adjacent to the level to be invoked in the interceptor task hierarchy chain.

[0072] If so, the interceptor components in the level to be invoked are called in parallel;

[0073] Determine whether the level to be invoked has an interceptor component at the next level; the next level is the next level in the interceptor task hierarchy that is adjacent to the level to be invoked.

[0074] If so, update the level to be called to the next level.

[0075] Thirdly, embodiments of the present invention also provide a computer device, comprising:

[0076] Memory, used to store program instructions;

[0077] The processor is used to call the program instructions stored in the memory and execute the processing method of the above-mentioned business request according to the obtained program.

[0078] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the aforementioned processing method for the business request. Attached Figure Description

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

[0080] Figure 1 A schematic diagram of a system architecture provided for an embodiment of the present invention;

[0081] Figure 2 A flowchart illustrating a method for processing business requests provided in an embodiment of the present invention;

[0082] Figure 3A schematic diagram of a fixed window provided in an embodiment of the present invention;

[0083] Figure 4 A schematic diagram of a sliding window provided in an embodiment of the present invention;

[0084] Figure 5 A schematic diagram of a token bucket algorithm provided in an embodiment of the present invention;

[0085] Figure 6 A schematic diagram of a judgment process provided in an embodiment of the present invention;

[0086] Figure 7 This is a schematic diagram of a directed acyclic graph provided in an embodiment of the present invention;

[0087] Figure 8 A schematic diagram illustrating the process of searching for abnormal registry entries, provided as an embodiment of the present invention;

[0088] Figure 9 This is a schematic diagram of the structure of a service request processing device provided in an embodiment of the present invention. Detailed Implementation

[0089] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0090] In existing technologies, multiple interceptor components configured for a business activity are called serially. However, in a certain business activity, there may be multiple interceptor components that have no dependency relationship. For example, different security verification methods may be used (interceptor component A is used to verify whether the network address of the business request is public, while interceptor component B is used to verify whether the network address of the business request is legitimate, etc.). Different interceptor components are called for different security verifications, but there is no business dependency relationship between interceptor component A and interceptor component B. That is, there is no need to consider the calling order of interceptor component A and interceptor component B, and there is no need to call them serially. The two interceptors can be called in parallel.

[0091] Similarly, for some interceptor components, there are dependencies. For example, if the business request is a payment request, the payment request needs to be verified for security first (interceptor component A and interceptor component B), and then the payment password needs to be verified for correctness (interceptor component C is used to verify whether the payment password of the payment request is correct). In this case, interceptor component C has a dependency relationship with interceptor component A and interceptor component B, that is, there is a call order relationship. Furthermore, interceptor component A and interceptor component B need to be called first, and then interceptor component C needs to be called.

[0092] Therefore, there is a need for a method to call the interceptor component in business request processing, which reduces the call time of the interceptor component, thereby shortening the interception time of business requests and improving the efficiency of business request processing.

[0093] Figure 1 An exemplary system architecture applicable to an embodiment of the present invention is shown, which includes a client 110, an intercept scheduler 120, a resource protector 130, an intercept registrar 140, a configuration manager 150, a state collector 160, and an exception scheduler 170.

[0094] The client 110 is used to send business requests. The client 110 can be a terminal (such as a mobile phone, laptop, etc.), a server, etc., and no specific limitation is made here.

[0095] The interceptor scheduler 120 is used to send the service request to the resource protector 130. After the resource protector determines that the service request meets the service protection conditions, it requests the interceptor registrar 140. The interceptor registrar 140 calls the interceptor task hierarchy chain and then calls the interceptor components at each level in sequence according to the interceptor task hierarchy chain. After the service request is not intercepted by any of the interceptor components in the interceptor task hierarchy chain, the business logic of the service request is executed.

[0096] Resource protector 130 is used to determine whether a business request meets the business protection conditions based on the historical execution status of the business request.

[0097] Interceptor Registry 140 is used to construct a directed acyclic graph based on each annotated interceptor component, determine the interceptor task hierarchy chain, and obtain the dependencies between each interceptor component.

[0098] Configuration Manager 150 is used to provide settings to the resource protector, including time thresholds, failure rate thresholds, and request count thresholds for interfaces, merchants, and channels.

[0099] The state collector 160 is used to determine the historical execution status of business requests, including request response time, sliding window failure rate of business requests, and number of business requests.

[0100] The exception scheduler 170 is used to determine the exception reason for the failed execution of the business request and return the exception reason to the client 110.

[0101] It should be noted that the above Figure 1 The structure shown is merely an example, and the embodiments of the present invention are not limited thereto.

[0102] Based on the above description Figure 2 An exemplary flowchart of a service request processing method provided by an embodiment of the present invention is shown, which can be executed by a service request processing device.

[0103] like Figure 2 As shown, the process specifically includes:

[0104] Step 210: The business system receives the business request.

[0105] In this embodiment of the invention, the business request refers to a business request for a specific business activity, such as a payment request for a shopping activity, or a login request for using a webpage or APP.

[0106] Step 220: The business system determines the business protection conditions of the business request based on the set factors in the business request.

[0107] In this embodiment of the invention, the service protection condition is used to ensure that the execution response of the service request meets the set requirements.

[0108] Step 230: The business system determines whether the business request meets the business protection conditions based on the historical business request execution status; if it does, the interceptor task hierarchy chain is obtained.

[0109] In this embodiment of the invention, the interceptor task hierarchy chain is used to divide all interceptor components in the business system into different levels according to their execution order, and there is no dependency between the interceptor components in the same level.

[0110] Step 240: The business system calls the interceptor components at each level in sequence according to the interceptor task hierarchy chain to determine whether the business request needs to be intercepted.

[0111] In this embodiment of the invention, the invocation of the interceptor component is determined according to the hierarchical order of the interceptor task hierarchy chain.

[0112] Step 250: After the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy chain, the business system executes the business logic of the business request.

[0113] In this embodiment of the invention, if the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy chain, it proves that the business request has passed verification and the business logic of the business request is allowed to be executed.

[0114] In step 220, after receiving the service request, a resource protection judgment needs to be performed on the service request. Specifically, the service system determines the service protection conditions of the service request based on the set factors in the service request; the service protection conditions are used to ensure that the execution response of the service request meets the set requirements.

[0115] In this embodiment of the invention, the setting factors include interfaces, merchants, and channels. That is to say, different protection conditions can be set for different setting factors, and it is not limited to setting corresponding protection conditions for different interfaces.

[0116] In step 230, the historical business request execution status refers to the sliding window failure rate at the current business request moment. This is equivalent to the failure rate of the sliding time window at that moment, along with the number of historical business requests, so that the business system can determine the number of current business requests. For example, if the number of historical business requests is 50, then the current business request is the 51st business request.

[0117] The business protection conditions include at least one of the following: the request response time exceeds the time threshold; the sliding window failure rate of the business request exceeds the failure rate threshold; the number of business requests exceeds the request number threshold.

[0118] Specifically, the business system determines whether the number of business requests exceeds the request threshold; if not, it obtains the interceptor task hierarchy chain; if so, it determines the sliding window failure rate of the business request, and obtains the interceptor task hierarchy chain when it is determined that the response time of the business request does not exceed the time threshold and the sliding window failure rate of the business request does not exceed the failure rate threshold.

[0119] In this embodiment of the invention, the request count threshold is used to prevent the business system from experiencing an excessively high sliding window failure rate or excessively long request response time during the cold start phase due to the small number of business requests. For example, when the number of business requests is 10, if one of them fails, the sliding window failure rate is 10%; when the number of business requests is 100, if two of them fail, the sliding window failure rate is 2%. It should be noted that cold start refers to restarting.

[0120] Therefore, in this embodiment of the invention, if the number of service requests does not exceed the request number threshold, it is determined that the service request meets the service protection conditions.

[0121] In one feasible approach, the window failure rate can be determined using a fixed window. Figure 3 An exemplary schematic diagram of a fixed window is shown, such as... Figure 3 As shown, assuming the failure rate threshold is 1% within 1 minute and the fixed window time is 1 minute, the fixed window failure rate is determined within 1 minute of the fixed window.

[0122] However, fixed windows have limitations in fault tolerance. For example, in two adjacent fixed windows, if the first fixed window handles 1000 requests, with 0 failures in the first 59 seconds and 9 failures in the last second, the failure rate for the first fixed window is 0.9%. Similarly, if the second fixed window handles 1000 requests, with 8 failures in the first second and 0 failures in the last 59 seconds, the failure rate for the second fixed window is 0.8%. Therefore, it can be determined that the actual failure rate exceeds the threshold at the end of the first fixed window and the beginning of the second fixed window, potentially leading to a system avalanche.

[0123] In this embodiment of the invention, the window failure rate is determined by a sliding window. Specifically, the business system determines the business request failure rate of each small window in the sliding window based on the sliding window at the time of the business request; the sum of the business request failure rates of each small window is determined as the sliding window failure rate of the business request.

[0124] For example, Figure 4 An exemplary schematic diagram of a sliding window is shown, such as... Figure 4 As shown, the sliding window period is divided into multiple smaller window periods, and the sliding window is moved to the next time step of each smaller window period. For any given time step, the sliding window failure rate of the business requests is determined based on the total number of business requests and the number of failed business requests within the multiple smaller window periods.

[0125] For example, the sliding window lasts for 1 minute, and is divided into 6 smaller windows, each lasting 10 seconds, as described above. Figure 3 Based on the example, assuming the failure rate of the last small window of the first sliding window (equivalent to the last 10 seconds of the first fixed window) is 0.9%, and the failure rate of the last small window of the second sliding window is 0.8%, then the failure rate of the second sliding window is 1.7%. This can avoid the problems that occur with the fixed window and improve the accuracy of determining whether the window failure rate exceeds the failure rate threshold.

[0126] In another feasible approach, for sliding windows, the QPS (Query Per Second) of the sliding window can also be used as a business protection condition. For example, if the QPS of the sliding window is less than the query threshold, no further restrictions are imposed here.

[0127] In this embodiment of the invention, when it is determined that a service request does not meet the service protection conditions, the service request is rate-limited according to a preset rate-limiting algorithm, thereby achieving resource protection.

[0128] Specifically, when the business system determines that a business request does not meet the business protection conditions based on the historical business request execution status, it collects the abnormal execution status of the business request and updates the historical business request execution status. Abnormal execution status includes the response time of the business request exceeding the time threshold and the sliding window failure rate of the business request exceeding the failure rate threshold. Based on the abnormal execution status, a rate limiting strategy is determined for the set factors. The rate limiting strategy includes a preset rate limiting algorithm.

[0129] For example, rate limiting algorithms include token bucket algorithm, counter algorithm, sliding window algorithm and leaky bucket algorithm, etc., without specific limitations here.

[0130] Taking the token bucket algorithm as an example, Figure 5 An exemplary schematic diagram of a token bucket algorithm is shown, such as... Figure 5 As shown, a token is generated into the token bucket according to the QPS of the preset rate limiting parameters. After receiving a business request, the business system retrieves the token for the business request from the token bucket. If the retrieval is successful, the business logic of the business request is executed; otherwise, the business request is not processed.

[0131] Taking the sliding window algorithm as an example, rate limiting can be applied to set factors by increasing or decreasing the number of small windows in the sliding window. This changes the execution status of historical business requests, thereby determining whether business requests need to be rate-limited.

[0132] For the request response time of a business request, if the request response time of the business request does not exceed the time threshold, we continue to determine whether the sliding window failure rate of the current business request time exceeds the failure rate threshold. If it does not exceed the threshold, we determine that the business request meets the business protection conditions.

[0133] In another feasible approach, resource protection for business requests can be achieved without using business protection conditions. Instead, resource protection for business requests can be directly implemented based on a preset rate limiting algorithm, such as the token bucket algorithm mentioned above. No specific limitations are specified here.

[0134] To better explain the technical solutions for the aforementioned business protection conditions Figure 6 An exemplary schematic diagram of a judgment process is shown, such as... Figure 6 As shown, it includes:

[0135] Step 610: Receive service requests.

[0136] Step 620: Determine whether the number of business requests exceeds the request threshold. If yes, proceed to step 630; otherwise, proceed to step 650.

[0137] For example, if the request count threshold is 100 and the current business request count is 50, meaning this business request is the 50th business request, then it is determined that this business request has not exceeded the request count threshold.

[0138] Step 630: Determine whether the business request exceeds the time threshold. If yes, proceed to step 660; otherwise, proceed to step 640.

[0139] After determining that the number of current business requests exceeds the request count threshold, it is then determined whether the request response time of that business request exceeds the time threshold. For example, if the request response time of that business request is 50 milliseconds and the time threshold is 1 second, then the request response time of that business request does not exceed the time threshold.

[0140] Step 640: Determine whether the business request exceeds the failure rate threshold. If yes, proceed to step 660; otherwise, proceed to step 650.

[0141] After determining that the number of current business requests does not exceed the time threshold, it is then determined whether the sliding window failure rate of the business request at the current time exceeds the failure rate threshold. For example, if the sliding window failure rate of the business request at the current time is 1.7% and the failure rate threshold is 1%, then the sliding window failure rate of the business request exceeds the failure rate threshold.

[0142] Step 650: Obtain the interceptor task hierarchy chain.

[0143] Step 660, current limiting protection.

[0144] Determine the preset rate limiting strategy, i.e. the preset rate limiting algorithm, to protect resources.

[0145] In this embodiment of the invention, the time threshold, failure rate threshold, and request number threshold can be preset values ​​by the programmer based on experience, such as a time threshold of 1 second, a failure rate threshold of 1%, and a request number threshold of 100.

[0146] The settings factors include interfaces, merchants, and channels. In other words, different time thresholds, failure rate thresholds, and request number thresholds can be set for different settings factors, as illustrated in Table 1 below.

[0147] Table 1

[0148]

[0149]

[0150] As can be seen from Table 1 above, the business protection conditions are different for business requests from different interfaces, merchants and channels. When a business request does not meet the business protection conditions, a rate limiting strategy (token bucket algorithm) is executed.

[0151] It should be noted that the rate limiting value in the rate limiting strategy can be different for different setting factors. Taking Table 1 above as an example, the rate limiting value of the token bucket rate limiting algorithm for "interface C1 + merchant M1 + channel D1" is "QPS = 300", and the rate limiting value of the token bucket rate limiting algorithm for "interface C2 + merchant M2 + channel D2" is "QPS = 100".

[0152] For the same set of factors, different abnormal execution conditions can trigger different rate limiting strategies. Referring to Table 1 above, for "Interface C1 + Merchant M1 + Channel D1", if the time threshold does not meet the business protection conditions, a token bucket rate limiting algorithm with a rate limiting value of "QPS = 200" will be executed. If the failure rate threshold does not meet the business protection conditions, a token bucket rate limiting algorithm with a rate limiting value of "QPS = 400" will be executed.

[0153] In step 230, the interceptor task hierarchy chain is determined based on the preset annotations in each interceptor component. Specifically, after the business system starts, it obtains each interceptor component with annotations, constructs a directed acyclic graph based on the dependencies between each interceptor component, and determines the interceptor task hierarchy chain based on the directed acyclic graph.

[0154] Furthermore, for the annotation of any interceptor component, the previous and next interceptor components adjacent to the interceptor component are determined in terms of the call order relationship, that is, other interceptor components that have a dependency relationship with the interceptor component, to obtain the directed acyclic graph of each interceptor; the directed acyclic graph is used to represent the call order of each interceptor and the dependency relationship between each interceptor.

[0155] For example, Figure 7 An exemplary schematic diagram of a directed acyclic graph is shown, such as... Figure 7 As shown, the interceptor components include interceptor component A, interceptor component B, interceptor component C and interceptor component D. The dependencies of each interceptor component are A→B, A→C, A→D, B→D, C→D. Therefore, it can be determined that interceptor component A is the first level, interceptor components B and C are the second level, and interceptor component D is the third level. Among them, the interceptor component of the next level has a dependency relationship with the interceptor component of the adjacent previous level (such as interceptor component B having a dependency relationship with interceptor component A), and the interceptor components of the same level do not have a dependency relationship (such as interceptor component B not having a dependency relationship with interceptor component C). Therefore, the interceptor task hierarchy chain can be determined. The interceptor task hierarchy chain can be represented as levelList[0]={A}, levelList[1]={B,C}, levelList[2]={D}.

[0156] In step 240, when calling each interceptor component in the interceptor task hierarchy chain, the hierarchy is determined according to the interceptor task hierarchy chain. Specifically, for any interceptor component in a level to be called, the business system determines whether the interceptor component in the previous level of the level to be called has been called. The previous level is the level in the interceptor task hierarchy chain that is adjacent to the level to be called. If so, the interceptor components in the level to be called are called in parallel.

[0157] The business system determines whether the layer to be called has an interceptor component at the next level; the next level is the next level in the interceptor task hierarchy that is adjacent to the layer to be called; if it does, the layer to be called is updated to the next level.

[0158] Based on the above Figure 7 For example, firstly, the first level (first level) is determined as the level to be called. Then, it is determined whether the interceptor of the previous level of the first level has been called. Since the first level has no previous level, it is assumed that the interceptor of the previous level of the first level has been called. Then, it is determined whether the first level has a next level (second level). After determining that there is a second level, the second level is updated as the level to be called. Then, it is determined whether each interceptor component in the upper level of the second level (first level) has been called. If so, each interceptor component in the second level is called in parallel.

[0159] After each interceptor component in the second level has been invoked, it is determined whether the second level has a subsequent level (the third level), until it is determined that the level to be invoked does not have a subsequent level.

[0160] For each interceptor component at any level, they are invoked in parallel. For example, for interceptor components B and C at the second level, they are invoked in parallel to reduce the call time of the interceptor components, thereby shortening the interception time of business requests and improving the efficiency of business request processing.

[0161] It should be noted that, in determining whether an interceptor component has completed its invocation, one feasible approach is to tag the interceptor component in the interceptor task hierarchy after the invocation is completed, in order to indicate that the invocation has been completed.

[0162] In this embodiment of the invention, for any interceptor component, after the interceptor component is invoked, the interceptor component is removed from the interceptor task hierarchy chain. If there is no interceptor component in any hierarchy, it indicates that the hierarchy has been invoked.

[0163] In step 250, before executing the business logic of the business request, it is also necessary to determine the type of the business request in order to decide whether to isolate the business request for resources.

[0164] Specifically, the business system determines whether the business request meets the isolation conditions based on the type of the business request. If it does, the thread resources of the business request are isolated.

[0165] Furthermore, the business system determines the interface to execute the business request based on the type of the business request; the interface is pre-configured with a method for whether to perform thread resource isolation.

[0166] In this embodiment of the invention, the type of business request may include payment request, query request, login request, etc., and is not limited thereto.

[0167] Taking a payment request as an example, when the business request is a query request, the interface for executing the payment request is determined to be the second interface, which contains a non-threaded resource isolation method. When the business request is a payment request, the interface for executing the payment request is determined to be the first interface, which contains a threaded resource isolation method, thereby achieving resource isolation for the payment request.

[0168] If an execution exception occurs during the execution of the business logic of a business request, the exception caller searches the preset exception registry. Figure 8 An exemplary diagram illustrating the process of locating an abnormal registry entry is shown, such as... Figure 8 As shown, the exception registry stores preset exception reasons (such as response timeout, payment failure, etc.). After finding the corresponding exception reason, the exception reason is fed back to the client so that the client is aware of the exception reason. If the corresponding exception reason is not found, the business system issues an alarm message so that the programmer can handle the exception and feed back preset information to the client.

[0169] Based on the same technological concept Figure 9 An exemplary schematic diagram of a service request processing apparatus provided in an embodiment of the present invention is shown. This apparatus can execute the process flow of a service request processing method.

[0170] like Figure 9 As shown, the device specifically includes:

[0171] Receiver module 910 is used to receive service requests;

[0172] The processing module 920 is used to obtain the interceptor task hierarchy chain when the business request needs to call the interceptor component; the interceptor task hierarchy chain is to divide all interceptor components in the business system into different levels according to the execution order, and there is no dependency relationship between the interceptor components in the same level.

[0173] According to the interceptor task hierarchy chain, the interceptor components at each level are called sequentially to determine whether the business request needs to be intercepted.

[0174] After the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy, the business logic of the business request is executed.

[0175] Optionally, the processing module 920 is further configured to:

[0176] After executing the business logic of the business request, collect the execution status of the business request;

[0177] After receiving a service request, before obtaining the interceptor task hierarchy chain, the service protection conditions for the service request are determined based on the set factors in the service request; the service protection conditions are used to ensure that the execution response of the service request meets the set requirements.

[0178] Determine whether the business request meets the business protection conditions based on the historical execution status of the business request.

[0179] If the conditions are met, then obtain the interceptor task hierarchy chain.

[0180] Optionally, the setting factors in the business request include at least one of the following: interface, merchant, and channel;

[0181] The business protection conditions include at least one of the following: the request response time exceeds a time threshold; the sliding window failure rate of the business request exceeds a failure rate threshold; the number of business requests exceeds a request number threshold.

[0182] Optionally, the processing module 920 is further configured to:

[0183] Before executing the business logic of the business request, it is determined whether the business request meets the isolation conditions based on the type of the business request. If it does, the thread resources of the business request are isolated.

[0184] Optionally, the processing module 920 is specifically used for:

[0185] Based on the type of the business request, determine the interface to execute the business request; the interface may have a pre-defined method for thread resource isolation.

[0186] Optionally, the processing module 920 is specifically used for:

[0187] Retrieve each interceptor component with annotations;

[0188] Construct a directed acyclic graph based on the dependencies between the interceptor components;

[0189] The interceptor task hierarchy chain is determined based on the directed acyclic graph.

[0190] Optionally, the processing module 920 is specifically used for:

[0191] For any interceptor component at a level to be invoked, determine whether the interceptor component at the level preceding the level to be invoked has been invoked; the level preceding the level is the one adjacent to the level to be invoked in the interceptor task hierarchy chain.

[0192] If so, the interceptor components in the level to be invoked are called in parallel;

[0193] Determine whether the level to be invoked has an interceptor component at the next level; the next level is the next level in the interceptor task hierarchy that is adjacent to the level to be invoked.

[0194] If so, update the level to be called to the next level.

[0195] Based on the same technical concept, embodiments of the present invention also provide a computer device, including:

[0196] Memory, used to store program instructions;

[0197] The processor is used to call the program instructions stored in the memory and execute the processing method of the above-mentioned business request according to the obtained program.

[0198] Based on the same technical concept, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-mentioned processing method for the business request.

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

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

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

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

[0203] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for processing business requests, characterized in that, include: The business system receives business requests; The business system determines the business protection conditions of the business request based on the set factors in the business request; The business protection conditions are used to ensure that the execution response of the business request meets the set requirements; The business system determines whether the business request meets the business protection conditions based on the historical business request execution status; if it does, it obtains the interceptor task hierarchy chain. The interceptor task hierarchy chain is a hierarchy that divides all interceptor components in the business system into different levels according to their execution order, and there is no dependency between interceptor components in the same level. The business system calls the interceptor components at each level in sequence according to the interceptor task hierarchy chain to determine whether the business request needs to be intercepted. The business system executes the business logic of the business request after the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy chain.

2. The method as described in claim 1, characterized in that, The settings in the business request include at least one of the following: interface, merchant, and channel; The business protection conditions include at least one of the following: the request response time exceeds a time threshold; the sliding window failure rate of the business request exceeds a failure rate threshold; the number of business requests exceeds a request number threshold.

3. The method as described in claim 2, characterized in that, If the service request meets the aforementioned service protection conditions, then the interceptor task hierarchy chain is obtained, including: The business system determines whether the number of business requests exceeds the request threshold; if not, it obtains the interceptor task hierarchy chain. If so, the sliding window failure rate of the business request is determined, and the interceptor task hierarchy chain is obtained when it is determined that the response time of the business request does not exceed the time threshold and the sliding window failure rate of the business request does not exceed the failure rate threshold.

4. The method as described in claim 3, characterized in that, Determining the sliding window failure rate of the service request includes: The business system determines the failure rate of business requests in each small window of the sliding window based on the sliding window at the time of the business request. The sum of the failure rates of the business requests in each of the small windows is determined as the sliding window failure rate of the business request.

5. The method as described in claim 1, characterized in that, The method further includes: When the business system determines that a business request does not meet the business protection conditions based on the historical business request execution status, it collects the abnormal execution status of the business request and updates the historical business request execution status; the abnormal execution status includes the response time of the business request exceeding a time threshold and the sliding window failure rate of the business request exceeding a failure rate threshold. The business system determines a rate limiting strategy based on the set factors according to the abnormal execution status; the rate limiting strategy includes a preset rate limiting algorithm.

6. The method as described in claim 1, characterized in that, Before executing the business logic of the aforementioned business request, the following is also included: The business system determines whether the business request meets the isolation conditions based on the type of the business request and the interface that executes the business request; the interface has a preset method for whether to perform thread resource isolation. If the conditions are met, the thread resources for the business request will be isolated.

7. The method according to any one of claims 1 to 6, characterized in that, include: The interceptor task hierarchy chain is obtained in the following ways: After the business system starts, it obtains each interceptor component with annotations. The business system constructs a directed acyclic graph based on the dependencies between the interceptor components; The business system determines the interceptor task hierarchy chain based on the directed acyclic graph.

8. The method according to any one of claims 1 to 6, characterized in that, The business system calls the interceptor components at each level sequentially according to the interceptor task hierarchy chain, including: For any interceptor component at a level to be invoked, the business system determines whether the interceptor component at the level preceding the level to be invoked has been invoked; the level preceding the level is the one adjacent to the level to be invoked in the interceptor task hierarchy chain. If so, the interceptor components in the level to be invoked are called in parallel; The business system determines whether the level to be invoked has an interceptor component at the next level; the next level is the next level in the interceptor task hierarchy that is adjacent to the level to be invoked. If so, update the level to be called to the next level.

9. A processing apparatus for business requests, characterized in that, The apparatus is used to perform the method according to any one of claims 1 to 8; The device includes: The receiving module is used to receive business requests; The processing module is used to obtain the interceptor task hierarchy chain when the business request needs to call the interceptor component; the interceptor task hierarchy chain is to divide all interceptor components in the business system into different levels according to the execution order, and there is no dependency relationship between the interceptor components in the same level. According to the interceptor task hierarchy chain, the interceptor components at each level are called sequentially to determine whether the business request needs to be intercepted. After the business request is not intercepted by any of the interceptor components in the interceptor task hierarchy, the business logic of the business request is executed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the method according to any one of claims 1 to 8.

Images