CN113326153A - Service request processing method and device - Google Patents
Service request processing method and device Download PDFInfo
- Publication number
- CN113326153A CN113326153A CN202110708175.8A CN202110708175A CN113326153A CN 113326153 A CN113326153 A CN 113326153A CN 202110708175 A CN202110708175 A CN 202110708175A CN 113326153 A CN113326153 A CN 113326153A
- Authority
- CN
- China
- Prior art keywords
- service request
- interceptor
- service
- request
- hierarchy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a method and a device for processing a service request, wherein the method comprises the following steps: the service system receives the service request, and acquires an interceptor task level chain when judging that the service request meets service protection conditions according to the historical service request execution condition; the interceptor task level chain is divided into different levels according to an execution sequence aiming at all interceptor components in a business system, and each interceptor component in the same level has no dependency relationship; sequentially calling interceptor components of each level according to an interceptor task level chain to determine whether the service request needs to be intercepted; executing the business logic of the business request after the business request is not intercepted by each interceptor component in the interceptor task hierarchy chain. Therefore, the calling time of the interceptor component is reduced, the intercepting time of the service request is shortened, and the efficiency of processing the service request is improved.
Description
Technical Field
The invention relates to the field of financial technology (Fintech), in particular to a method and a device for processing a service request.
Background
With the development of computer technology, more and more technologies (such as block chains, cloud computing or big data) are applied to the financial field, the traditional financial industry is gradually changing to the financial technology, the big data technology is no exception, but higher requirements are provided for the processing of service requests in the big data technology due to the requirements of the security and the real-time performance of the financial and payment industries.
In the prior art, an interceptor component is used for intercepting a service request, such as verifying a network address of the service request, intercepting an unregistered user and an audit log. Specifically, the configuration of the interceptor component of any business activity is configured by user definition, and the interceptor component is called to intercept the business request in the business activity.
Currently, a plurality of interceptor components of any business activity are called serially for a business request, for example, a transaction request in a shopping activity includes two security interceptor components a and B, a security interceptor component C for performing security interception on the transaction request and a payment interceptor component C for providing a payment channel, and the calling sequence of the interceptor components is a, B, and C.
However, in the above technical solution, for the payment interceptor component C, the call of the security interceptor components a and B is required to be completed, and the call is performed after the service request passes, so as to ensure the payment security. However, for the security interceptor components a and B, the security of the service request is verified without considering the call sequence, i.e., without serial call, and the interceptor components a and B can be called in parallel, and the serial call will result in long call time of the interceptor components, resulting in long service processing request time and low efficiency.
Therefore, there is a need for an interceptor component calling method that reduces the calling time of an interceptor component, thereby shortening the intercepting time of a service request and improving the efficiency of service request processing.
Disclosure of Invention
The embodiment of the invention provides a method and a device for processing a service request, which are used for reducing the calling time of an interceptor component, thereby shortening the intercepting time of the service request and improving the efficiency of processing the service request.
In a first aspect, a method for processing a service request provided in an embodiment of the present invention includes:
a service system receives a service request;
the service system determines the service protection condition of the service request according to the set factors in the service request; the service protection condition is used for ensuring that the execution response of the service request meets the set requirement;
the service system judges whether the service request meets the service protection condition according to the execution condition of the historical service request; if yes, acquiring an interceptor task level chain; the interceptor task level chain is divided into different levels according to an execution sequence aiming at all interceptor components in the service system, and each interceptor component in the same level has no dependency relationship;
the service system sequentially calls the interceptor components of each level according to the interceptor task level chain to determine whether the service request needs to be intercepted;
and the service system executes the service logic of the service request after the service request is not intercepted by each interceptor component in the interceptor task hierarchy chain.
In the above technical solution, the interceptor task hierarchy chain includes a plurality of hierarchies, and it is important that there is no dependency relationship between the interceptor components in the same hierarchy, that is, the interceptor components in the same hierarchy can be called concurrently, so as to reduce the calling time of the interceptor components, thereby shortening the intercepting time for the service request and improving the efficiency of processing the service request.
The historical service request execution status in the invention is used for determining the processing status of the service request in real time, namely success or failure, so that the user can know in real time and the service request experience of the user is improved. Specifically, when the service request meets the service protection condition, it is determined that the service request is passed through resource protection, that is, the service request is allowed to be executed, so that the security of processing the service request is improved, wherein the historical service request execution status is determined according to all service requests before the task request, that is, the historical service request execution status does not include the execution status of the service request.
Optionally, the setting factor in the service request includes at least one of the following: interfaces, merchants, and channels;
the traffic protection condition includes at least one of: the request response time exceeds a time threshold; the failure rate of the sliding window of the service request exceeds a failure rate threshold; the number of service requests exceeds the request number threshold.
In the technical scheme, the setting factors comprise an interface, a merchant and a channel, and the merchant and the channel are protected by resources only through the interface in the prior art, so that differentiated resource protection on the merchant and the channel is realized, and the granularity of service request protection is refined.
Optionally, if the service request meets the service protection condition, acquiring an interceptor task level chain, including:
the service system judges whether the service request exceeds a request number threshold value; if not, acquiring the interceptor task level chain;
if yes, determining the sliding window failure rate of the service request, and acquiring the interceptor task level chain when the response time of the service request is determined not to exceed the time threshold and the sliding window failure rate of the service request is determined not to exceed the failure rate threshold.
In the technical scheme, the problem of overlarge sliding window failure rate caused by too small quantity of service requests is solved through the request number threshold, the execution condition of the service requests is determined by the service system by mistake, whether the current service requests are too crowded is determined through the sliding window failure rate of the service requests and the time threshold, and the service system is prevented from avalanche.
Optionally, determining the sliding window failure rate of the service request includes:
the service system determines the service request failure rate of each small window in the sliding window based on the sliding window at the service request moment;
and determining the sum of the service request failure rates of the small windows as the sliding window failure rate of the service request.
In the above technical solution, the sliding window is also the time window of the service request time, and the failure rate in the sliding time window is determined, so as to improve the accuracy of the failure rate in the time window, that is, improve the accuracy of the judgment on the current service request.
Optionally, the method further includes:
when the service system determines that the service request does not meet the service protection condition according to the execution condition of the historical service request, collecting the abnormal execution condition of the service request, and updating the execution condition of the historical service request; the abnormal execution condition comprises that the response time of the service request exceeds a time threshold and the failure rate of the sliding window of the service request exceeds a failure rate threshold;
the service system determines a current limiting strategy for the set factors according to the abnormal execution condition; the current limiting strategy comprises a preset current limiting algorithm.
In the above technical solution, when the service request meets the service protection condition, it is proved that the current service request is too crowded, the number of service requests needs to be reduced by a certain policy, and the corresponding current limiting policy is automatically determined and executed according to the abnormal execution condition of the service request, so as to implement the automation of current limiting, and the current limiting policy is directed at an interface, a merchant and a channel in the set factors, so as to refine the granularity of service request protection.
Optionally, before executing the service logic of the service request, the method further includes:
the service system determines whether the service request meets an isolation condition according to the type of the service request and an interface executing the service request; a method for performing thread resource isolation is preset in the interface;
and if so, isolating the thread resource of the service request.
In the technical scheme, an interface for executing the service request is determined according to the type of the service request, a thread resource isolation method or a non-thread resource isolation method is preset in the interface, and whether the service request needs to be subjected to thread resource isolation is determined according to the determined interface for executing the service request, so that differentiation of the service request is realized, namely the importance degree of the service request is distinguished, and the execution failure or delay of the important service request is avoided.
Optionally, the interceptor task hierarchy chain is obtained by:
after the business system is started, acquiring various interceptor components with annotations;
the business system constructs a directed acyclic graph according to the dependency relationship among the interceptor components;
and the service system determines the task level chain of the interceptor according to the directed acyclic graph.
In the technical scheme, the association relationship between the interceptor components is determined through annotation, that is, for any interceptor component, other interceptor components having a dependency relationship with the interceptor component are determined, so that a directed acyclic graph can be constructed, then an interceptor task level chain is determined according to the direction of the directed acyclic graph, and further each level interceptor component having no dependency relationship is determined, so that parallel calling of the interceptor components is realized, and the calling time of the interceptor components is reduced.
Optionally, the service system sequentially calls the interceptor components of each level according to the interceptor task level chain, and includes:
for any interceptor component of a hierarchy to be called, determining whether the interceptor component of a hierarchy previous to the hierarchy to be called is called completely; the previous level is a previous level in the interceptor task hierarchy chain adjacent to the level to be invoked;
if yes, calling interceptor components in the hierarchy to be called in parallel;
determining whether the level to be invoked has an interceptor component of a subsequent level; the next level is a next level in the interceptor task hierarchy chain adjacent to the level to be invoked;
and if so, updating the hierarchy to be called to the next hierarchy.
In the technical scheme, the interceptor components are called through the hierarchy, so that the front-back dependency of the interceptor components on the calling sequence is ensured, and the calling time of the interceptor components can be reduced, thereby shortening the intercepting time of the service request and improving the efficiency of service request processing.
In a second aspect, an embodiment of the present invention provides a device for processing a service request, including:
the receiving module is used for receiving the service request;
the processing module is used for determining the service protection condition of the service request according to the set factors in the service request; the service protection condition is used for ensuring that the execution response of the service request meets the set requirement;
judging whether the service request meets the service protection condition or not according to the execution condition of the historical service request; if yes, acquiring an interceptor task level chain; the interceptor task level chain is divided into different levels according to an execution sequence aiming at all interceptor components in the service system, and each interceptor component in the same level has no dependency relationship;
sequentially calling interceptor components of each level according to the interceptor task level chain to determine whether the service request needs to be intercepted;
executing the business logic of the business request after the business request is not intercepted by each interceptor component in the interceptor task hierarchy chain.
Optionally, the setting factor in the service request includes at least one of the following: interfaces, merchants, and channels;
the traffic protection condition includes at least one of: the request response time exceeds a time threshold; the failure rate of the sliding window of the service request exceeds a failure rate threshold; the number of service requests exceeds the request number threshold.
Optionally, the processing module is specifically configured to:
judging whether the service request exceeds a request number threshold value; if not, acquiring the interceptor task level chain;
if yes, determining the sliding window failure rate of the service request, and acquiring the interceptor task level chain when the response time of the service request is determined not to exceed the time threshold and the sliding window failure rate of the service request is determined not to exceed the failure rate threshold.
Optionally, the processing module is specifically configured to:
determining the service request failure rate of each small window in the sliding window based on the sliding window at the service request moment;
and determining the sum of the service request failure rates of the small windows as the sliding window failure rate of the service request.
Optionally, the processing module is further configured to:
when the service request is determined not to meet the service protection condition according to the execution condition of the historical service request, collecting the abnormal execution condition of the service request, and updating the execution condition of the historical service request; the abnormal execution condition comprises that the response time of the service request exceeds a time threshold and the failure rate of the sliding window of the service request exceeds a failure rate threshold;
determining a current limiting strategy for the set factors according to the abnormal execution condition; the current limiting strategy comprises a preset current limiting algorithm.
Optionally, the processing module is further configured to:
before executing the service logic of the service request, determining whether the service request meets an isolation condition according to the type of the service request and an interface executing the service request; a method for performing thread resource isolation is preset in the interface;
and if so, isolating the thread resource of the service request.
Optionally, the processing module is specifically configured to:
obtaining interceptor components having annotations;
constructing a directed acyclic graph according to the dependency relationship among the interceptor components;
and determining the interceptor task level chain according to the directed acyclic graph.
Optionally, the processing module is specifically configured to:
for any interceptor component of a hierarchy to be called, determining whether the interceptor component of a hierarchy previous to the hierarchy to be called is called completely; the previous level is a previous level in the interceptor task hierarchy chain adjacent to the level to be invoked;
if yes, calling interceptor components in the hierarchy to be called in parallel;
determining whether the level to be invoked has an interceptor component of a subsequent level; the next level is a next level in the interceptor task hierarchy chain adjacent to the level to be invoked;
and if so, updating the hierarchy to be called to the next hierarchy.
In a third aspect, an embodiment of the present invention further provides a computer device, including:
a memory for storing program instructions;
and the processor is used for calling the program instruction stored in the memory and executing the processing method of the service request according to the obtained program.
In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, where the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are configured to enable a computer to execute the method for processing the service request.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a system architecture diagram according to an embodiment of the present invention;
fig. 2 is a schematic flowchart of a method for processing a service request according to an embodiment of the present invention;
FIG. 3 is a diagram illustrating a fixed window according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of a sliding window according to an embodiment of the present invention;
FIG. 5 is a schematic diagram of a token bucket algorithm according to an embodiment of the present invention;
fig. 6 is a schematic diagram of a determination process according to an embodiment of the present invention;
FIG. 7 is a diagram illustrating a directed acyclic graph according to an embodiment of the present invention;
FIG. 8 is a diagram illustrating an exception lookup table according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram of a service request processing apparatus according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In the prior art, a plurality of interceptor components configured for a business activity are all called serially, however, in a certain business activity, there is no dependency relationship between the plurality of interceptor components, for example, different security verification means are different (e.g., whether a network address of an interceptor component a used for verifying a business request is public, whether a network address of a business request is legal, etc.), for different security verifications, the called interceptor components are different, but there is no business dependency relationship between the interceptor component a and the interceptor component B, that is, there is no need to consider the calling order of the interceptor component a and the interceptor component B, serial calling is not needed, and two interceptors can be called in parallel.
Similarly, for some interceptor components, a dependency relationship exists, and if the service request is a payment request, security verification needs to be performed on the payment request (the interceptor component a and the interceptor component B) first, and then whether a payment password for the payment request is correct is verified (the interceptor component C is used for verifying whether the payment password for the payment request is correct), then the interceptor component C has a dependency relationship with the interceptor component a and the interceptor component B, that is, a calling precedence relationship exists, and further, the interceptor component a and the interceptor component B need to be called first, and then the interceptor component C is called.
Therefore, there is a need for an interceptor component calling method in service request processing, which reduces the calling time of the interceptor component, thereby shortening the intercepting time of a service request and improving the efficiency of service request processing.
Fig. 1 illustrates an exemplary system architecture to which embodiments of the present invention are applicable, which includes a client 110, an interception scheduler 120, a resource protector 130, an interception registrar 140, a configuration manager 150, a state collector 160, and an exception scheduler 170.
The client 110 is configured to send a service request, and the client 110 may be a terminal (e.g., a mobile phone, a notebook, etc.), a server, etc., and is not limited herein.
The intercept scheduler 120 is configured to send a service request to the resource protector 130, request the intercept register 140 after the resource protector determines that the service request meets a service protection condition, call an interceptor task hierarchy chain in the intercept register 140, then sequentially call interceptor components of each hierarchy according to the interceptor task hierarchy chain, and execute a service logic of the service request after the service request is not intercepted by each interceptor component in the interceptor task hierarchy chain.
And the resource protector 130 is configured to determine whether the service request satisfies a service protection condition according to a historical execution status of the service request.
The interception registrar 140 is configured to construct a directed acyclic graph according to each interceptor component with the annotation, determine an interceptor task level chain, and obtain a dependency relationship between the interceptor components.
The configuration manager 150 is used to provide the resource protector with set factors including time thresholds, failure rate thresholds, and request count thresholds for the interface, merchant, and channel.
And the state collector 160 is used for determining the historical execution condition of the service request, including the request response time, the failure rate of the sliding window of the service request and the number of the service requests.
And the exception scheduler 170 is configured to determine an exception cause for executing the failed service request, and return the exception cause to the value client 110.
It should be noted that the structure shown in fig. 1 is only an example, and the embodiment of the present invention is not limited thereto.
Based on the above description, fig. 2 exemplarily illustrates a flow chart of a service request processing method provided by an embodiment of the present invention, and the flow chart may be executed by a service request processing apparatus.
As shown in fig. 2, the process specifically includes:
In the embodiment of the invention, the service request is directed to a service request of a certain service activity, such as a payment request of a shopping activity, a login request using a webpage or an APP, and the like.
In the embodiment of the invention, the service protection condition is used for ensuring that the execution response of the service request meets the set requirement.
In the embodiment of the invention, the interceptor task level chain is divided into different levels according to the execution sequence aiming at all interceptor components in the service system, and each interceptor component in the same level has no dependency relationship.
In the embodiment of the invention, the calling of the interceptor component is determined according to the hierarchical sequence of the interceptor task hierarchical chain.
In the embodiment of the invention, the service request is not intercepted by each interceptor component in the interceptor task hierarchy chain, the service request is proved to pass the verification, and the service logic of the service request is allowed to be executed.
In step 220, after receiving the service request, resource protection judgment needs to be performed on the service request, specifically, the service system determines a service protection condition of the service request according to a set factor in the service request; the service protection condition is used for ensuring that the execution response of the service request meets the set requirement.
In the embodiment of the present invention, the setting factors include an interface, a merchant, and a channel, that is, different protection conditions may be set for different setting factors, and the setting of the protection conditions for different interfaces is not limited.
In step 230, the historical service request execution status refers to a sliding window failure rate at the current service request time, which is equivalent to a sliding window failure rate at the current service request time, and the historical service request number, so that the service system determines the current service request number. If the number of the historical service requests is 50, the current service request is a 51 st service request.
Wherein the service protection condition comprises at least one of the following: the request response time exceeds a time threshold; the failure rate of the sliding window of the service request exceeds a failure rate threshold; the number of service requests exceeds the request number threshold.
Specifically, the service system judges whether the service request exceeds a request number threshold; if not, acquiring an interceptor task level chain; if yes, determining the failure rate of the sliding window of the service request, and acquiring the interceptor task level chain when the response time of the service request does not exceed the time threshold and the failure rate of the sliding window of the service request does not exceed the failure rate threshold.
In the embodiment of the present invention, the request number threshold is used to prevent that, in a cold start stage of a service system, due to a small number of service requests, when calculating a sliding window failure rate or a request response time, a sliding window failure rate is too large due to a small base number, or a request response time is too long, for example, when the number of service requests is 10, if one service request failure occurs therein, the sliding window failure rate is 10%, and when the number of service requests is 100, if two service request failures occur therein, the sliding window failure rate is 2%. Note that the cold start refers to restart.
Therefore, in the embodiment of the present invention, when the service request amount does not exceed the request number threshold, it is determined that the service request satisfies the service protection condition.
In an implementation, the window failure rate may be determined using a fixed window, and fig. 3 exemplarily shows a schematic diagram of the fixed window, and as shown in fig. 3, assuming that the failure rate threshold is 1% in 1 minute, and the time of the fixed window is 1 minute, the fixed window failure rate is determined in 1 minute of the fixed window.
However, the fixed window has a fault tolerance disadvantage, for example, when the request amount in the first fixed window is 1000 times, the first 59s fails for 0 time, and the last 1s fails for 9 times, the failure rate of the first fixed window is 0.9%, the request amount in the second fixed window is 1000 times, the first 1s fails for 8 times, and the last 59s fails for 0 time, the failure rate of the second fixed window is 0.8%. Therefore, the situation that the end time of the first fixed window and the initial time of the second fixed window are easy to actually exceed the failure rate threshold value and cause system avalanche is easy to occur can be determined.
In the embodiment of the present invention, the window failure rate is determined by sliding the window, specifically, the service system determines the service request failure rate of each small window in the sliding window based on the sliding window at the service request time; and determining the sum of the service request failure rates of the small windows as the sliding window failure rate of the service request.
For example, fig. 4 exemplarily shows a schematic diagram of a sliding window, as shown in fig. 4, the sliding window period is divided into a plurality of small window periods, and the sliding window period is slid at the next time of the small window periods, and for any time, the sliding window failure rate of the service request is determined according to the total number of the service requests and the service request failure number in the plurality of small window periods.
For example, the time of the sliding window is 1 minute, the sliding window is subdivided into 6 small windows, each of which is 10 seconds, and based on the example of fig. 3, if the failure rate of the last small window (corresponding to the last 10 seconds of the first fixed window) of the first sliding window is 0.9%, and the failure rate of the last small window of the second sliding window is 0.8%, the failure rate of the second sliding window is 1.7%, so that the problem of the fixed window can be avoided, and the accuracy of determining whether the window failure rate exceeds the failure rate threshold value is improved.
In another practical manner, for the sliding window, a QPS (Query Per Second) of the sliding window may also be used as a traffic protection condition, for example, the QPS of the sliding window is smaller than a Query threshold, which is not limited herein.
In the embodiment of the invention, when the service request is determined not to meet the service protection condition, the service request is limited according to the preset current limiting algorithm, so that the resource protection is realized.
Specifically, when the service system determines that the service request does not meet the service protection condition according to the execution condition of the historical service request, the abnormal execution condition of the service request is collected, and the execution condition of the historical service request is updated; the abnormal execution condition comprises that the response time of the service request exceeds a time threshold and the failure rate of the sliding window of the service request exceeds a failure rate threshold; determining a current limiting strategy for the set factors according to the abnormal execution condition; wherein the current limiting strategy comprises a preset current limiting algorithm.
For example, the current limiting algorithm is a token bucket algorithm, a counter algorithm, a sliding window algorithm, a leaky bucket algorithm, and the like, and is not particularly limited herein.
Taking a token bucket algorithm as an example, fig. 5 exemplarily shows a schematic diagram of a token bucket algorithm, as shown in fig. 5, a token is generated into a token bucket according to a QPS of preset current limiting parameters, after a service system receives a service request, the token of the service request is obtained in the token bucket, if the obtaining is successful, a service logic of the service request is executed, otherwise, the service request is not processed.
Taking the sliding window algorithm as an example, the current limitation may be performed on the setting factor by increasing or decreasing the number of the small windows in the sliding window, that is, the execution status of the historical service request is changed, so as to determine whether the service request needs to be subjected to the current limitation.
And for the request response time of the service request, when the request response time of the service request does not exceed the time threshold, continuously determining whether the failure rate of the sliding window of the current service request time exceeds the failure rate threshold, and if not, determining that the service request meets the service protection condition.
In another implementable manner, for resource protection of the service request, the service protection condition may not be used, and the resource protection may be directly performed on the service request according to a preset current limiting algorithm, such as the token bucket algorithm, which is not specifically limited herein.
To better illustrate the above technical solution of the service protection condition, fig. 6 exemplarily shows a schematic diagram of a judgment process, as shown in fig. 6, including:
For example, if the threshold of the number of requests is 100 and the number of current service requests is 50, that is, the service request is the 50 th service request, it is determined that the service request does not exceed the threshold of the number of requests.
In step 630, it is determined whether the service request exceeds the time threshold, if yes, step 660 is executed, otherwise step 640 is executed.
After determining that the number of current service requests exceeds the request number threshold, determining whether the request response time of the service request exceeds a time threshold, for example, the request response time of the service request is 50 milliseconds, and the time threshold is 1 second. The request response time for the service request does not exceed the time threshold.
After determining that the number of current service requests does not exceed the time threshold, determining whether the failure rate of the sliding window of the current time of the service request exceeds the failure rate threshold, for example, the failure rate of the sliding window of the current time of the service request is 1.7%, and the failure rate threshold is 1%. The sliding window failure rate for the service request exceeds the failure rate threshold.
And 660, current limiting protection.
And determining a preset current limiting strategy, namely a preset current limiting algorithm, and performing resource protection.
In the embodiment of the present invention, the time threshold, the failure rate threshold, and the request number threshold may be preset values according to experience by a programmer, for example, the time threshold is 1 second, the failure rate threshold is 1%, the request number threshold is 100, and the like.
Different time thresholds, failure rate thresholds, and request count thresholds may be set for the setting factors, including the interface, merchant, and channel, that is, for different setting factors, as exemplified in table 1 below.
TABLE 1
As can be seen from table 1, for the service requests of different interfaces, merchants, and channels, the corresponding service protection conditions are different, and when the service request does not satisfy the service protection conditions, the current limiting policy (token bucket algorithm) is executed.
It should be noted that, for different setting factors, the throttling values in the throttling policy may be different, and by way of example, in conjunction with table 1, the throttling value of the token bucket throttling algorithm for "interface C1+ merchant M1+ channel D1" is "QPS 300", and the throttling value of the token bucket throttling algorithm for "interface C2+ merchant M2+ channel D2" is "QPS 100".
For the same setting factor, different abnormal execution conditions may trigger different throttling strategies, which is exemplified by combining table 1, and if the time threshold does not satisfy the traffic protection condition, the token bucket throttling algorithm with the throttling value "QPS ═ 200" is executed for "interface C1+ merchant M1+ channel D1". And if the failure rate threshold value does not meet the service protection condition, executing a token bucket current limiting algorithm with a current limiting value of 'QPS ═ 400'.
In step 230, the interceptor task hierarchy chain is determined according to the preset annotations in each interceptor component, specifically, after the service system is started, each interceptor component with the annotations is obtained, and a directed acyclic graph is constructed according to the dependency relationship between the interceptor components; from the directed acyclic graph, a chain of interceptor task levels is determined.
Further, aiming at the annotation of any interceptor component, determining the previous interceptor component and the next interceptor component which are adjacent to the interceptor component in the calling sequence relation, namely other interceptor components having the dependency relation with the interceptor component, and obtaining the directed acyclic graph of each interceptor; the directed acyclic graph is used for representing the calling sequence of each interceptor and the dependency relationship among the interceptors.
By way of example, fig. 7 exemplarily shows a schematic diagram of a directed acyclic graph, as shown in fig. 7, the interceptor component includes an interceptor component a, an interceptor component B, an interceptor component C, and an interceptor component D, the interceptor components having a dependency relationship of a → B, a → C, a → D, B → D, and C → D, respectively, such that it can be determined that the interceptor component a is at a first level, the interceptor components B and C are at a second level, and the interceptor component D is at a third level, wherein the interceptor component at the next level has a dependency relationship with the interceptor component at the adjacent previous level (e.g., the interceptor component B has a dependency relationship with the interceptor component a), and the interceptor components at the same level have no dependency relationship with each other (e.g., the interceptor component B has no dependency relationship with the interceptor component C), such that a task level chain of interceptor can be determined, the interceptor task level chain may be embodied as levelList [0] ═ { a }, levelList [1] ═ { B, C }, levelList [2] ═ { D }.
In step 240, when each interceptor component in the interceptor task hierarchical chain is called, it is determined according to the interceptor task hierarchical chain hierarchy, and specifically for any interceptor component of a hierarchy to be called, the business system determines whether the calling of the interceptor component of a hierarchy previous to the hierarchy to be called is completed; a previous level is a previous level in the interceptor task hierarchy chain adjacent to the level to be invoked; if yes, calling interceptor components in the hierarchy to be called in parallel;
the service system determines whether the hierarchy to be called has an interceptor component of a next hierarchy; the next level is the next level in the interceptor task hierarchy chain adjacent to the hierarchy to be called; and if so, updating the hierarchy to be called to the next hierarchy.
Taking the example of fig. 7, first, a sequential hierarchy (first hierarchy) is determined as a hierarchy to be called, then it is determined whether a previous-hierarchy interceptor of the first hierarchy is called completely, because the first hierarchy has no previous hierarchy, and thus, it is default that the previous-hierarchy interceptor of the first hierarchy is called completely, then, after it is determined whether the first hierarchy has a next hierarchy (second hierarchy), the second hierarchy is updated to the hierarchy to be called after it is determined that there is the second hierarchy, then it is determined whether each interceptor component in a previous-hierarchy (first hierarchy) of the second hierarchy is called completely, and if so, each interceptor component in the second hierarchy is called in parallel.
After each interceptor component call in the second level is completed, it is determined whether the second level has a next level (third level) until it is determined that the to-be-called level does not have a next level pole.
For each interceptor component of any level, when calling, calling in parallel, for example, for the interceptor component B and the interceptor component C of the second level, when calling, calling in parallel, calling the interceptor component B and the interceptor component C, so as to reduce calling time of the interceptor components, thereby shortening intercepting time of service requests and improving service request processing efficiency.
It should be noted that, when determining whether the interceptor component is called completely, in an implementable manner, after the interceptor component is called completely, the interceptor component may be tagged in the interceptor task hierarchy chain for characterization to call completely.
In the embodiment of the invention, for any interceptor component, after the calling of the interceptor component is completed, the interceptor component is removed from the chain of interceptor task hierarchies, and in any hierarchy, if no interceptor component exists in the hierarchy, the hierarchy is characterized to be called to be completed.
Before executing the service logic of the service request, the type of the service request needs to be determined, so as to determine whether to perform resource isolation on the service request in step 250.
Specifically, the service system determines whether the service request meets an isolation condition according to the type of the service request, and if so, isolates the thread resource of the service request.
Further, the service system determines an interface for executing the service request according to the type of the service request; and presetting a method for thread resource isolation in the interface.
In this embodiment of the present invention, the type of the service request may include a payment request, an inquiry request, a login request, and the like, which is not limited herein.
Taking the payment request as an example, when the service request is an inquiry request, determining that an interface for executing the payment request is a second interface, and setting a non-thread resource isolation method in the second interface. When the service request is a payment request, determining that an interface for executing the payment request is a first interface, and setting a thread resource isolation method in the first interface, so as to realize resource isolation of the payment request.
When the service logic of the service request is executed, if an execution exception occurs, a preset exception registry is searched through an exception invoker, fig. 8 exemplarily shows a schematic diagram for searching the exception registry, as shown in fig. 8, preset exception reasons (such as response timeout, payment failure, and the like) are stored in the exception registry, after the corresponding exception reason is found, the exception reason is fed back to the client, the client knows the exception reason, and when the corresponding exception reason is found, the service system sends out alarm information so that a programmer handles the exception and feeds back preset information to the client.
Based on the same technical concept, fig. 9 exemplarily shows a schematic structural diagram of a service request processing apparatus according to an embodiment of the present invention, and the apparatus can execute a flow of a service request processing method.
As shown in fig. 9, the apparatus specifically includes:
a receiving module 910, configured to receive a service request;
a processing module 920, configured to obtain an interceptor task level chain when the service request needs to call an interceptor component; the interceptor task level chain is divided into different levels according to an execution sequence aiming at all interceptor components in the service system, and each interceptor component in the same level has no dependency relationship;
sequentially calling interceptor components of each level according to the interceptor task level chain to determine whether the service request needs to be intercepted;
executing the business logic of the business request after the business request is not intercepted by each interceptor component in the interceptor task hierarchy chain.
Optionally, the processing module 920 is further configured to:
after the business logic of the business request is executed, the execution status of the business request is collected;
after receiving a service request and before acquiring an interceptor task hierarchy chain, determining a service protection condition of the service request according to a set factor in the service request; the service protection condition is used for ensuring that the execution response of the service request meets the set requirement;
judging whether the service request meets the service protection condition or not according to the historical execution condition of the service request;
if so, acquiring the interceptor task hierarchy chain.
Optionally, the setting factor in the service request includes at least one of the following: interfaces, merchants, and channels;
the traffic protection condition includes at least one of: the request response time exceeds a time threshold; the failure rate of the sliding window of the service request exceeds a failure rate threshold; the number of service requests exceeds the request number threshold.
Optionally, the processing module 920 is further configured to:
before executing the service logic of the service request, determining whether the service request meets an isolation condition according to the type of the service request, and if so, isolating the thread resource of the service request.
Optionally, the processing module 920 is specifically configured to:
determining an interface for executing the service request according to the type of the service request; and presetting a method for thread resource isolation in the interface.
Optionally, the processing module 920 is specifically configured to:
obtaining interceptor components having annotations;
constructing a directed acyclic graph according to the dependency relationship among the interceptor components;
and determining the interceptor task level chain according to the directed acyclic graph.
Optionally, the processing module 920 is specifically configured to:
for any interceptor component of a hierarchy to be called, determining whether the interceptor component of a hierarchy previous to the hierarchy to be called is called completely; the previous level is a previous level in the interceptor task hierarchy chain adjacent to the level to be invoked;
if yes, calling interceptor components in the hierarchy to be called in parallel;
determining whether the level to be invoked has an interceptor component of a subsequent level; the next level is a next level in the interceptor task hierarchy chain adjacent to the level to be invoked;
and if so, updating the hierarchy to be called to the next hierarchy.
Based on the same technical concept, an embodiment of the present invention further provides a computer device, including:
a memory for storing program instructions;
and the processor is used for calling the program instruction stored in the memory and executing the processing method of the service request according to the obtained program.
Based on the same technical concept, an embodiment of the present invention further provides a computer-readable storage medium, where computer-executable instructions are stored, and the computer-executable instructions are configured to enable a computer to execute the method for processing the service request.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may 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, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (10)
1. A method for processing service request is characterized by comprising the following steps:
a service system receives a service request;
the service system determines the service protection condition of the service request according to the set factors in the service request; the service protection condition is used for ensuring that the execution response of the service request meets the set requirement;
the service system judges whether the service request meets the service protection condition according to the execution condition of the historical service request; if yes, acquiring an interceptor task level chain; the interceptor task level chain is divided into different levels according to an execution sequence aiming at all interceptor components in the service system, and each interceptor component in the same level has no dependency relationship;
the service system sequentially calls the interceptor components of each level according to the interceptor task level chain to determine whether the service request needs to be intercepted;
and the service system executes the service logic of the service request after the service request is not intercepted by each interceptor component in the interceptor task hierarchy chain.
2. The method of claim 1, wherein the set factor in the service request comprises at least one of: interfaces, merchants, and channels;
the traffic protection condition includes at least one of: the request response time exceeds a time threshold; the failure rate of the sliding window of the service request exceeds a failure rate threshold; the number of service requests exceeds the request number threshold.
3. The method of claim 2, wherein obtaining a hierarchy chain of interceptor tasks if a service request satisfies the service protection condition comprises:
the service system judges whether the service request exceeds a request number threshold value; if not, acquiring the interceptor task level chain;
if yes, determining the sliding window failure rate of the service request, and acquiring the interceptor task level chain when the response time of the service request is determined not to exceed the time threshold and the sliding window failure rate of the service request is determined not to exceed the failure rate threshold.
4. The method of claim 3, wherein determining a sliding window failure rate for the service request comprises:
the service system determines the service request failure rate of each small window in the sliding window based on the sliding window at the service request moment;
and determining the sum of the service request failure rates of the small windows as the sliding window failure rate of the service request.
5. The method of claim 1, wherein the method further comprises:
when the service system determines that the service request does not meet the service protection condition according to the execution condition of the historical service request, collecting the abnormal execution condition of the service request, and updating the execution condition of the historical service request; the abnormal execution condition comprises that the response time of the service request exceeds a time threshold and the failure rate of the sliding window of the service request exceeds a failure rate threshold;
the service system determines a current limiting strategy for the set factors according to the abnormal execution condition; the current limiting strategy comprises a preset current limiting algorithm.
6. The method of claim 1, wherein prior to executing the service logic of the service request, further comprising:
the service system determines whether the service request meets an isolation condition according to the type of the service request and an interface executing the service request; a method for performing thread resource isolation is preset in the interface;
and if so, isolating the thread resource of the service request.
7. The method of any of claims 1 to 6, comprising:
the interceptor task hierarchy chain is obtained by:
after the business system is started, acquiring various interceptor components with annotations;
the business system constructs a directed acyclic graph according to the dependency relationship among the interceptor components;
and the service system determines the task level chain of the interceptor according to the directed acyclic graph.
8. The method according to any of claims 1 to 6, wherein said business system invoking interceptor components of each level in sequence according to said interceptor task level chain comprises:
for any interceptor component of a hierarchy to be called, the business system determining whether the interceptor component of a hierarchy previous to the hierarchy to be called is called completely; the previous level is a previous level in the interceptor task hierarchy chain adjacent to the level to be invoked;
if yes, calling interceptor components in the hierarchy to be called in parallel;
the business system determines whether the hierarchy to be called has an interceptor component of a next hierarchy; the next level is a next level in the interceptor task hierarchy chain adjacent to the level to be invoked;
and if so, updating the hierarchy to be called to the next hierarchy.
9. An apparatus for processing service requests, comprising:
the receiving module is used for receiving the service request;
the processing module is used for acquiring an interceptor task level chain when the service request needs to call the interceptor component; the interceptor task level chain is divided into different levels according to an execution sequence aiming at all interceptor components in the service system, and each interceptor component in the same level has no dependency relationship;
sequentially calling interceptor components of each level according to the interceptor task level chain to determine whether the service request needs to be intercepted;
executing the business logic of the business request after the business request is not intercepted by each interceptor component in the interceptor task hierarchy chain.
10. A computer-readable storage medium having stored thereon computer-executable instructions for causing a computer to perform the method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110708175.8A CN113326153A (en) | 2021-06-25 | 2021-06-25 | Service request processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110708175.8A CN113326153A (en) | 2021-06-25 | 2021-06-25 | Service request processing method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113326153A true CN113326153A (en) | 2021-08-31 |
Family
ID=77424692
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110708175.8A Pending CN113326153A (en) | 2021-06-25 | 2021-06-25 | Service request processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113326153A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115082053A (en) * | 2022-04-27 | 2022-09-20 | 银联商务股份有限公司 | Business processing method and device, storage medium and computer equipment |
| CN116418751A (en) * | 2021-12-30 | 2023-07-11 | 北京字跳网络技术有限公司 | Flow control method, flow control device, electronic equipment, medium and program product |
| CN120030526A (en) * | 2025-04-23 | 2025-05-23 | 北京微步在线科技有限公司 | Cross-order multi-level authority authentication method, device, medium and program product |
-
2021
- 2021-06-25 CN CN202110708175.8A patent/CN113326153A/en active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116418751A (en) * | 2021-12-30 | 2023-07-11 | 北京字跳网络技术有限公司 | Flow control method, flow control device, electronic equipment, medium and program product |
| CN115082053A (en) * | 2022-04-27 | 2022-09-20 | 银联商务股份有限公司 | Business processing method and device, storage medium and computer equipment |
| CN120030526A (en) * | 2025-04-23 | 2025-05-23 | 北京微步在线科技有限公司 | Cross-order multi-level authority authentication method, device, medium and program product |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11343103B2 (en) | Sending cross-chain authenticatable messages | |
| US20200177388A1 (en) | Cross-blockchain resource transmission | |
| CN113326153A (en) | Service request processing method and device | |
| WO2020181813A1 (en) | Task scheduling method based on data processing and related device | |
| CN112866136B (en) | Service data processing method and device | |
| TW201816692A (en) | Risk identification method, client device, and risk identification system | |
| CN111585913B (en) | Service flow limiting method based on recovery token and storage medium | |
| US10558810B2 (en) | Device monitoring policy | |
| CN110381150B (en) | Data processing method and device on block chain, electronic equipment and storage medium | |
| CN108416665B (en) | Data interaction method and device, computer equipment and storage medium | |
| US8819155B2 (en) | System and method for performing centralized common tasks for a set of functions | |
| CN110955523B (en) | Service processing method and device | |
| CN111835790B (en) | Risk identification method, device and system | |
| CN111209110A (en) | Task scheduling management method, system and storage medium for realizing load balance | |
| CN113157411B (en) | Celery-based reliable configurable task system and device | |
| CN111405024A (en) | Service processing method, gateway, electronic device and storage medium | |
| CN111400283B (en) | Data processing method, system, electronic equipment and storage medium | |
| CN114338811B (en) | Transaction flow limiting method, device, server, storage medium and product | |
| WO2023082798A1 (en) | Consortium blockchain system-based service processing method and apparatus | |
| CN110263551A (en) | A kind of test method and device | |
| CN112995051B (en) | Network traffic recovery method and device | |
| CN107958414B (en) | Method and system for eliminating long transactions of CICS (common integrated circuit chip) system | |
| CN113973084B (en) | A flow control method and device | |
| CN111782378A (en) | Adaptive processing performance adjusting method, server and readable storage medium | |
| CN115499492A (en) | Application service exception handling method, device, equipment and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |