Service request processing method, device, equipment and storage medium

Abstract

The present invention relates to the field of R&D management technology, and discloses a service request processing method, device, equipment and storage medium. When a failed service request is detected in a third-party service providing system, a log analysis tool is used to analyze the failure factors in the log of the failed service, and a corresponding compensation mechanism is matched based on the analyzed failure factors. The failed service is retried based on the compensation mechanism. The retry here is to use at least two different retry control strategies to perform retry control. Such retry control is more flexible, occupies less server resources, improves the stability of the server, and the probability of successful compensation is also greatly improved. In addition, the present invention also relates to blockchain technology, and the log and retry control strategy can be stored in the blockchain.

Description

Technical Field

[0001] The present invention relates to the technical field of research and development management, and in particular to a service request processing method, device, equipment and storage medium. Background Art

[0002] At present, the degree of informatization in various industries is getting higher and higher, and the business segmentation is becoming more and more refined. As a platform system, it is inevitable to access various third-party services. For example: payment, maps, logistics / express delivery, image recognition, voice recognition, qualification review, basic data services and other businesses. As the business increases, the carrying capacity and stability of the server that extracts the business service will be affected, resulting in service failure.

[0003] In order to reduce the impact of service failure on the business, in the prior art, a service rerun or retry processing mechanism is configured to compensate. However, the current compensation mechanism of rerun or retry is too violent or rigid, mainly by controlling the failed business to keep retrying, which will occupy too many server operating resources and easily cause server instability. Summary of the invention

[0004] The main purpose of the present invention is to solve the technical problem that the retry solution in the prior art is prone to unstable server operation.

[0005] A first aspect of the present invention provides a service request processing method, which includes: detecting in real time whether there is a service with a failed service request in the third-party service providing system; if so, collecting the corresponding request log from the log storage area of ​​the third-party service providing system according to the service request, and calling a preset log analysis tool to parse the service request parameters recorded in the request log, and generating a failure factor based on the service request parameters; according to the failure factor, matching the corresponding compensable failure case from a preset compensable failure list to obtain a matching result; according to the matching result, determining the corresponding compensation mechanism, and executing the compensation mechanism to retry the failed service, wherein the compensation mechanism includes at least two different retry control strategies.

[0006] Optionally, in a first implementation method of the first aspect of the present invention, the failure factors include a request method and a failure occurrence node, and according to the failure factors, matching corresponding compensable failure cases from a preset compensable failure list to obtain a matching result includes: matching the request method with request methods of different types of services, and determining the service type corresponding to the service request, wherein the service types include query services, operation services, and notification services; determining a corresponding compensable failure list according to the service type, and using the failure occurrence node as a matching index, matching corresponding compensable failure cases from the compensable failure list to generate a matching result.

[0007] Optionally, in a second implementation method of the first aspect of the present invention, determining a corresponding compensation mechanism based on the matching result, and executing the compensation mechanism to retry the failed service includes: identifying whether repeated requests for compensable failure cases in the matching result affect normal requests for other services; if not, determining that the compensation mechanism includes two different first retry control strategies and second retry control strategies; executing the first retry control strategy to re-request the failed service; if no feedback information of the requested service is received after the re-request, starting a timer; after the timer expires, executing the second retry control strategy to re-request the service that failed after the re-request.

[0008] Optionally, in a third implementation method of the first aspect of the present invention, if the repeated requests for identifying compensable failure cases in the matching results affect normal requests of other services, after determining that the compensation mechanism includes two different first retry control strategies and second retry control strategies, it also includes: calling a query service interface to send a status query request to the service to inquire whether the service has been retried or whether the failure has been processed; if so, terminating the retry operation on the service; if not, retrying the failed service according to the first retry control strategy.

[0009] Optionally, in a fourth implementation method of the first aspect of the present invention, if the service type is an operation service, the start timer timing includes: adjusting the state of the failed service to a suspended state, and generating a warning signal based on the failure factor; executing the warning signal and triggering the timer timing; detecting whether there is a change in the suspended state; if so, monitoring whether there is feedback information corresponding to the service request; if not, after the timer timing is reached, executing the second retry control strategy to re-request the service that failed after the re-request.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, executing the first retry control strategy to re-request the failed service includes: parsing the time parameters of at least one retry in the first retry control strategy; generating a retry scheduling control code based on the time parameters of at least one retry; performing a retry operation on the failed service according to the retry scheduling control code; after the retry operation is completed, querying the status of the failed service after the retry; if the status is a failed status, starting a timer to perform a countdown calculation for a first time threshold; if the timing is reached, executing the retry scheduling control code to retry the failed service for a second time, until the timing reaches the time threshold corresponding to the time parameter of the at least one retry, and then executing the second retry control strategy to re-request the service that failed after the second request.

[0011] Optionally, in the sixth implementation method of the first aspect of the present invention, after executing the second retry control strategy to re-request the service that failed after the re-request, it also includes: detecting whether the status of the failed service is a successful status; if not, maintaining the status of the failed service in a failed status, and generating a fault warning signal to notify the user to troubleshoot the problem.

[0012] The second aspect of the present invention provides a service request processing device, which includes: a detection module, which is used to detect in real time whether there is a service with a service request failure in the third-party service providing system; a generation module, which is used to collect the corresponding request log from the log storage area of ​​the third-party service providing system according to the service request when detecting that there is a service with a service request failure, and call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters; a matching module, which is used to match the corresponding compensable failure case from a preset compensable failure list according to the failure factor to obtain a matching result; a retry module, which is used to determine the corresponding compensation mechanism according to the matching result, and execute the compensation mechanism to retry the failed service, wherein the compensation mechanism includes at least two different retry control strategies.

[0013] Optionally, in a first implementation manner of the second aspect of the present invention, the failure factors include a request method and a failure occurrence node, and the matching module is specifically used to: match the request method with request methods of different types of services, and determine the service type corresponding to the service request, wherein the service type includes query type services, operation type services, and notification type services; determine a corresponding compensable failure list based on the service type, and use the failure occurrence node as a matching index to match the corresponding compensable failure case from the compensable failure list to generate a matching result.

[0014] Optionally, in a second implementation of the second aspect of the present invention, the retry module includes: an identification unit, used to identify whether the repeated requests for compensable failure cases in the matching results have an impact on normal requests for other services; a determination unit, used to determine, when there is an impact, that the compensation mechanism includes two different first retry control strategies and second retry control strategies; a first retry unit, used to execute the first retry control strategy to re-request the failed service; a timing unit, used to start a timer if no feedback information of the requested service is received after the re-request; and a second retry unit, used to execute the second retry control strategy to re-request the service that failed after the re-request after the timer expires.

[0015] Optionally, in a third implementation method of the second aspect of the present invention, the service request processing device also includes a failure processing module, which is used to call the query service interface to send a status query request to the service when the repeated requests for compensable failure cases in the identified matching results affect the normal requests of other services, to inquire whether the service has been retried or whether the failure has been processed; if so, terminate the retry operation on the service; if not, retry the failed service according to the first retry control strategy.

[0016] Optionally, in a fourth implementation method of the second aspect of the present invention, the timing unit is also used to: if the service type is an operation service, adjust the state of the failed service to a suspended state, and generate a warning signal based on the failure factor; execute the warning signal and trigger the timer timing; detect whether there is a change in the suspended state; if so, monitor whether there is feedback information corresponding to the service request; if not, the second retry unit is used to execute the second retry control strategy to re-request the service that failed after the timer timing is reached.

[0017] Optionally, in a fifth implementation of the second aspect of the present invention, the first retry unit is specifically used to parse the time parameters of at least one retry in the first retry control strategy; generate a retry scheduling control code according to the time parameters of at least one retry; perform a retry operation on the failed service according to the retry scheduling control code; after the retry operation is completed, query the status of the failed service after the retry; if the status is a failed status, start the timer to perform a countdown calculation of the first time threshold; if the timing is reached, execute the retry scheduling control code to retry the failed service for a second time, until the timing reaches the time threshold corresponding to the time parameter of the at least one retry, and then execute the second retry control strategy to re-request the service that failed after the re-request.

[0018] Optionally, in a sixth implementation method of the second aspect of the present invention, the service request processing device also includes a prompt module for detecting whether the status of the failed service is a successful status; if not, the status of the failed service is maintained in a failed status, and a fault warning signal is generated to notify the user to perform troubleshooting.

[0019] The third aspect of the present invention provides a service request processing device, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor calls the instructions in the memory so that the service request processing device executes the above-mentioned service request processing method.

[0020] A fourth aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the above-mentioned service request processing method.

[0021] In the technical solution of the present invention, when a failed service request is detected in a third-party service providing system, a log analysis tool is used to analyze the failure factors in the logs of the failed service, and a corresponding compensation mechanism is matched based on the analyzed failure factors. The failed service is retried based on the compensation mechanism. The retry here uses at least two different retry control strategies to perform retry control. Such retry control is more flexible, occupies less server resources, improves the stability of the server, and the probability of successful compensation is also greatly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 A schematic diagram of a first embodiment of a method for processing a service request in an embodiment of the present invention;

[0023] Figure 2 A schematic diagram of a second embodiment of the service request processing method in an embodiment of the present invention;

[0024] Figure 3 A schematic diagram of a third embodiment of the service request processing method in an embodiment of the present invention;

[0025] Figure 4 This is a schematic diagram of a fourth embodiment of the method for processing a service request in an embodiment of the present invention;

[0026] Figure 5 A schematic diagram of an embodiment of a service request processing device in an embodiment of the present invention;

[0027] Figure 6 A schematic diagram of another embodiment of a service request processing device in an embodiment of the present invention;

[0028] Figure 7The figure is a schematic diagram of an embodiment of a service request processing device in an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The embodiments of the present invention provide a service request processing method, apparatus, device and storage medium, formulate a corresponding compensation mechanism based on the cause of the service request failure, make multiple requests for the failed service based on the compensation mechanism, and analyze the cause of failure after each compensation request fails to adjust the compensation mechanism to improve the success rate of compensation. Compared with the prior art, the compensation method of the present application is more flexible, occupies less server resources, and improves the stability of the server.

[0030] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] For ease of understanding, the specific process of the embodiment of the present invention is described below. Figure 1 , the first embodiment of the service request processing method in the embodiment of the present invention, the implementation steps of the method are as follows:

[0032] 101. Real-time detection of whether there are services with failed service requests in the third-party service provider system;

[0033] In this embodiment, when detecting the third-party service providing system, real-time monitoring is performed through a non-service interface, or monitoring is performed by calling a service interface in the third-party service providing system.

[0034] In actual applications, when it is detected that a service request is being executed in a third-party service provider system, the requested service interface is monitored by calling a monitoring command, specifically, whether the service interface receives the return information of the service. The return information can be an identification type of information or an instruction information. If it is detected that the interface receives such information, it is determined that the service request is successful.

[0035] Furthermore, during the monitoring process, a monitoring time is set, and the monitoring time is set according to the reaction time of the service request. The transmission distance between the service provider and the service receiver is specifically determined, and the transmission time of the signal is calculated based on the transmission speed of the signal. At the same time, the reaction time of the service provider to the service request is determined, and the monitoring time is calculated based on the transmission time and the reaction time. Of course, the monitoring time can also be set to be greater than or equal to the sum of the transmission time and the reaction time through an error. This allows for more accurate monitoring and a quick response to the service request to perform subsequent compensation operations.

[0036] 102. If so, collect the corresponding request log from the log storage area of ​​the third-party service provider system according to the service request, call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters;

[0037] In this step, after detecting a failed service request, the analysis program is executed, and the failure factors of the failed service request are analyzed using the analysis program. Specifically, the type of service request is first analyzed, and the analysis method is determined according to the type. The work log generated by the service request is queried by calling a non-service interface, and the cause of the failure is determined based on the information recorded in the work log, thereby extracting the failure factors.

[0038] In this embodiment, after collecting the request log, a log analysis tool is used to identify the access parameters in the request log, and the issuing terminal of the service request is determined based on the access parameters, and the registration information of the issuing terminal in the third-party service provision system is extracted, wherein the registration information includes the proxy server information and the access terminal information configured by the issuing terminal, and a match is made between whether the proxy server information exists in the request log. If so, it is determined that the issuance of the service request has been successful. Furthermore, a match is made between whether the access terminal information exists in the request log. If not, it is determined that the cause of failure of the service request is a reception failure, and a reception failure factor is generated.

[0039] In practical applications, it can be implemented in two steps:

[0040] (1) First, confirm whether the requester has issued a request: By configuring the proxy, you can confirm whether the requester has issued a request.

[0041] (2) Secondly, confirm whether the request has reached the server: Preferably, this can be confirmed through the service log, and the request can be received on the server, but no feedback on the request is received on the request end.

[0042] From the above (1) and (2), we can see that the request sent by the requester did not reach the server. Therefore, we guess that the problem may occur in the merge request service. Here is an explanation of the merge request service. In fact, it is about splitting the merge request and forwarding it to the requester and server separately.

[0043] 103. According to the failure factor, a corresponding compensable failure case is matched from a preset compensable failure list to obtain a matching result;

[0044] Before this step, it also includes setting compensable cases and analyzing the failure factors of these cases to form a compensable failure list, and then determining the factors corresponding to the service requests that failed under the current monitoring, and querying whether there are corresponding cases from the compensable failure list based on the factors. If so, it is determined that the service request is a compensable request, otherwise it is not compensable, thereby generating a matching result.

[0045] In this embodiment, specifically, the service type corresponding to the service request is determined by matching the request mode with request modes of different types of services, wherein the service types include query services, operation services, and notification services;

[0046] A corresponding compensable failure list is determined according to the service type, and the failure occurrence node is used as a matching index to match the corresponding compensable failure case from the compensable failure list to generate a matching result.

[0047] 104. Determine a corresponding compensation mechanism based on the matching result, and execute the compensation mechanism to retry the failed service.

[0048] In this step, the compensation mechanism includes at least two different retry control strategies.

[0049] In this embodiment, the automatic retry mechanism defined in the compensation mechanism specifically includes:

[0050] a. The number of automatic retries must be controllable (for example, support configuration or dynamic modification). It is generally recommended to use 3-5 retries per round, and the number of retries can be adjusted at any time according to business needs.

[0051] b. The automatic retry interval can follow the principle of short first and long later. For example, if the query fails, you can directly start the first retry. If the first retry still fails, try again after a period of time (such as 2 seconds). If the second retry still fails, try again after a longer interval (such as 5 seconds). And so on. The third time is 10 seconds, the fourth time is 30 seconds, and the fifth time is 60 seconds. Of course, the interval time can also be adjusted appropriately according to actual business needs. Each time the automatic retry fails, it is necessary to judge the cause of the failure. If the failure can still be compensated, the next retry will be carried out. The purpose of continuously extending the retry interval is to skip the temporary inability to request caused by line problems or service downtime.

[0052] Regardless of the number of automatic retries, if a clear failure response is received from the business party and it is not a compensable failure, the subsequent retries will be terminated and the request will be directly treated as a failure, with service downgrade or corresponding error prompt information. At the same time, an alarm notification or message will be sent to the technical staff to notify the relevant personnel to intervene in time to troubleshoot the problem to ensure that the next request will be successful.

[0053] If a round of retries still fails, it must be processed as a failure, and the service must be downgraded or a corresponding error prompt message must be given. At the same time, an alarm notification or message is sent to the technical staff to notify the relevant personnel to intervene in time to troubleshoot the problem to ensure that the next request can be successful.

[0054] If the query failure occurs in a local transaction and the subsequent transaction depends on the query result, the transaction needs to be suspended, and an alarm notification or message is sent to the technical staff to notify the relevant personnel to intervene in time to troubleshoot the problem. After that, a retry is triggered manually or automatically after a period of time to end the suspension state.

[0055] By implementing the above methods, appropriate compensation mechanisms can be selected according to the characteristics of different failure factors to solve problems more efficiently and specifically. At the same time, by reusing existing and relatively mature solutions, work efficiency can be improved, the difficulty and workload of connecting with third-party services can be reduced, and the risk of errors made by novices or inexperienced personnel when connecting to third-party services can be reduced.

[0056] See also Figure 2 , a second embodiment of the service request processing method in the embodiment of the present invention includes:

[0057] 201. Real-time detection of whether there are services with failed service requests in the third-party service provider system;

[0058] In this step, the network link status between the third-party service providing system and the requesting end sending the service request may be detected;

[0059] If the network link status is connected or disconnected, determining that there is an operation of failed request in the third-party service provider system;

[0060] If the network link is connected or connected, it is queried whether the service request corresponding to the request end is marked. If so, it is determined that there is an operation of failed request in the third-party service providing system.

[0061] 202. If so, collect the corresponding request log from the log storage area of ​​the third-party service provider system according to the service request, call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters;

[0062] 203. According to the failure factor, a corresponding compensable failure case is matched from a preset compensable failure list to obtain a matching result;

[0063] 204. Identify whether repeated requests for compensable failure cases in matching results have an impact on normal requests of other services;

[0064] In this step, the request method of the service request is specifically analyzed to identify whether the repeated request of the service request has an impact on other requests. For example, when the request method of the service needs to call the calling interface of other services to implement the request, it is judged to have an impact. If it has its own separate calling interface, it is judged to have no impact.

[0065] 205. If not, determine that the compensation mechanism includes two different first retry control strategies and a second retry control strategy;

[0066] In this embodiment, there are at least two retry control strategies in the compensation mechanism. Each retry control strategy has different retry control time and number for service requests. It is generally recommended to have 3-5 times as a round. The number of retries can be adjusted at any time according to business needs, and the automatic retry interval can follow the principle of short first and long later, such as: if the query fails, the first retry can be started directly. If the first retry still fails, it will be retried again after a period of time (such as 2 seconds). If the second retry still fails, it will be retried after a longer interval (such as 5 seconds), and so on. The third time is 10 seconds, the fourth time is 30 seconds, and the fifth time is 60 seconds; of course, the interval time can also be adjusted appropriately according to actual business needs. Each time the automatic retry fails, it is necessary to judge the cause of the failure. If the failure can still be compensated, the next retry will be performed. The purpose of continuously extending the retry interval is to skip the temporary inability to request caused by line problems or service downtime.

[0067] 206. Execute the first retry control strategy to request the failed service again;

[0068] In this step, specifically according to the number of retries set in the first retry control strategy, the service request is repeatedly retried, and the number of retries is calculated by a counter during the retries. When the number of retries set in the first retry control strategy is reached, the retry operation is terminated; further, after each retry is completed, it is retried again after a certain period of time. When feedback information is received within the waiting period, the retry operation is terminated.

[0069] 207. If no feedback information of the requested service is received after the second request, a timer is started;

[0070] In this embodiment, after completing all retries of the first retry control strategy, if no feedback information is received, it is determined that the compensation has failed, and the timer is started to count down the service request. The length of this countdown time is 2 times or more of the entire retry duration in the first retry control strategy. Within this duration, the analysis program is restarted to analyze the factors of failure again, obtain the analysis results, and adjust the second retry control strategy according to the analysis results.

[0071] In practical applications, if the service type is an operation service, the starting timer timing includes:

[0072] Adjusting the state of the failed service to a suspended state, and generating an early warning signal according to the failure factor;

[0073] Execute the warning signal and trigger the timer to start timing;

[0074] Detecting whether there is a change in the suspended state;

[0075] If so, monitoring whether there is feedback information corresponding to the service request;

[0076] If not, after the timer expires, the second retry control strategy is executed to request again the service that failed after the second request.

[0077] 208. After the timer expires, execute the second retry control strategy to request again the service that failed after the second request.

[0078] In this step, before executing the second retry control strategy, the second retry control strategy is also adjusted based on the classification according to the cause of the first compensation failure. For example, when the request failure belongs to the notification failure, the following method can be used as the second control strategy:

[0079] Method 1:

[0080] Service Provider:

[0081] Provide subscription services (not within the scope of this proposal and will not be elaborated in detail) and notification services, and the notification service supports retry upon failure.

[0082] When a status change or other situation that requires notification to a third party occurs, the notification receiving interface provided by the corresponding service subscriber is called. If the agreed success mark is not obtained, retries are performed according to the agreed number of retries and retry interval until the maximum number of retries is reached.

[0083] Service users:

[0084] Provides a service interface for receiving notifications, and the interface has anti-duplicate and idempotent processing capabilities.

[0085] After receiving the notification, the local subsequent processing logic is executed according to the notification status or other data information.

[0086] The disadvantages of this solution are:

[0087] If the business status is in order, but the new status in the notification is not the next status corresponding to the current status. For example, theoretically the status order in the notification is 1, 2, 3, 4, 5, but the actual notification order is 1, 4, 5 or 1, 4, 2, 3, 5), when the current status is 1 but a notification of status 4 is received, it is impossible to determine whether the status order is wrong or the status is lost, which will cause great trouble or risk to your processing.

[0088] If you never receive subsequent status notifications and you cannot know the actual situation of the service provider, you will generate dirty data in the intermediate state that cannot be processed. For example, theoretically the status in the notification is 1, 2, 3, 4, 5, but in reality only notifications 1, 2, 3 are received.

[0089] Therefore, this solution is only suitable for simple status notifications, such as success / failure; yes / no. And the stop loss processing logic for not receiving notifications for a long time must be agreed upon.

[0090] Method 2:

[0091] Service Provider:

[0092] Provides subscription services, notification services, and supporting query service interfaces.

[0093] When a status change or other situation that requires notification to a third party occurs, the notification receiving interface provided by the corresponding service subscriber is called. If the agreed success mark is not obtained, retries are performed according to the agreed number of retries and retry interval until the maximum number of retries is reached.

[0094] Service users:

[0095] Provides a service interface for receiving notifications, and the interface has anti-duplicate and idempotent processing capabilities.

[0096] After receiving the notification, execute the local subsequent processing logic according to the notification status or other data information. When the status in the notification is not as expected, missing or out of order, first request the query interface to query, and execute the corresponding subsequent processing logic based on the queried data. If the notification is not received for a long time, you can also actively query and execute the corresponding processing logic according to the query results.

[0097] Through the implementation of the above-mentioned method, a corresponding compensation mechanism is formulated based on the reason for the failure of the service request, multiple requests are made to the failed service based on the compensation mechanism, and the reason for the failure is analyzed after each failure of the compensation request to adjust the compensation mechanism to improve the success rate of compensation. Compared with the prior art, the compensation method of the present application is more flexible and occupies less server resources.

[0098] See also Figure 3 A third embodiment of the service request processing method in the embodiment of the present invention includes:

[0099] 301. Real-time detection of whether there are services with failed service requests in the third-party service provider system;

[0100] 302. If so, collect the corresponding request log from the log storage area of ​​the third-party service provider system according to the service request, call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters;

[0101] 303. According to the failure factor, a corresponding compensable failure case is matched from a preset compensable failure list to obtain a matching result;

[0102] 304. Identify whether repeated requests for compensable failure cases in matching results have an impact on normal requests for other services;

[0103] 305. If not, determine that the compensation mechanism includes two different first retry control strategies and a second retry control strategy;

[0104] 306. Call the query service interface to send a status query request to the service to query whether the service has been retried or whether the failure has been processed;

[0105] 307. If yes, then end the retry operation on the service;

[0106] 308. If not, execute the first retry control strategy to request the failed service again;

[0107] In actual applications, the first retry control strategy includes a multi-round retry strategy. The retry methods used are different according to the different types of failed services. When the operation service synchronization processing interface of the third-party system fails, if it is a compensable failure listed in the previous article, the operation service interface itself has side effects and cannot be retried rashly. Therefore, the query service interface needs to be called to query the current transaction status, and then appropriate follow-up processing is taken:

[0108] If it is found that the current transaction has been processed successfully, it means that the service provider has received the request and processed it successfully. It is just that the service user has not successfully received the feedback. The subsequent processing can be successfully carried out according to the request.

[0109] If it is found that the current transaction has failed to be processed, it means that the service provider has received the request but failed to process it. This may be due to parameter errors or unsatisfied business conditions. You can perform subsequent processing according to the request failure: fail and discard the current transaction, roll back the transaction and give a clear failure prompt message.

[0110] If no information related to the current transaction is found, it means that the service provider has not received the request, and the operation request can be retried. If the operation request continues to fail with compensable failures, it is necessary to query again. The process of "operation-query-confirmation result" can be repeated. The number of retries and retry intervals can refer to the relevant content of "1. Query services" above. However, the operation request cannot be retried multiple times in a row to avoid a large number of repeated transactions, thereby expanding asset losses.

[0111] If the first round of retries still fails, the current transaction will be suspended and an alarm notification or message will be sent to the technical staff to notify the relevant personnel to intervene and troubleshoot the problem in time. When the problem is solved or the scheduled time is reached, the suspension state can be ended manually or automatically to enter the second round of retries.

[0112] If the second round of retries still fails, it needs to be processed as a failure: fail and discard the current transaction, roll back the transaction and give a clear failure prompt message, try to call the service interface for the undo operation, and in addition, send an alarm notification or message to the technical staff to notify the relevant personnel to intervene in time to troubleshoot the problem to ensure the success of the next request.

[0113] One thing to note is that only when the query result shows that the current transaction has failed to be processed or no relevant information about the current transaction is found, can it be judged as a failure and processed as a failure. Otherwise, for example, when the query fails to obtain results, the safest way is to suspend the transaction and let humans determine whether to continue or fail.

[0114] 309. If no feedback information of the requested service is received after the second request, a timer is started;

[0115] 310. After the timer expires, execute the second retry control strategy to request again the service that failed after the second request.

[0116] Furthermore, for internal businesses that are complex or take a long time to process and cannot be processed synchronously, an asynchronous processing operation service interface that meets business needs is provided, and a matching query service interface is also provided. The query interface is a method and way provided to the user to confirm the result / status of the operation of the calling operation interface. The specific retry operations are as follows:

[0117] a. The operation service interface is an asynchronous processing interface. The subsequent processing suggestions and principles for successful requests are as follows:

[0118] The request operation interface returns success, which only means that the request is successful and the service provider has accepted the request, but does not mean that the actual request has been successfully processed. Therefore, after the request is successful, it is necessary to request the query interface again after the agreed time interval (the interval here is reserved for the service provider to asynchronously execute the business) (the query interface compensation mechanism can be referred to in the previous "1. Query services"), and judge the operation execution status according to the query result: pending, processing, success, failure; if successful, the subsequent logic is executed according to success; if failed, the subsequent logic is executed according to failure; if pending or processing, the query can be retried, and the retry query can refer to the relevant content of the previous "1. Query services".

[0119] b. The operation service interface is an asynchronous processing interface. If a compensable failure occurs, the suggestions and principles for compensation processing are as follows:

[0120] After a compensable failure occurs in the request operation interface, the query interface is requested to query and the operation execution status is determined based on the query result.

[0121] If the current transaction is found and is being processed, it means that the service provider has received the request but has not yet completed the processing. You need to continue to retry the query until you get a success or failure result.

[0122] If it is found that the current transaction has been processed successfully, it means that the service provider has received the request and processed it successfully. It is just that the service user has not successfully received the feedback. The subsequent processing can be successfully carried out according to the request.

[0123] If it is found that the current transaction has failed to be processed, it means that the service provider has received the request but failed to process it. This may be due to parameter errors or unsatisfied business conditions. You can perform subsequent processing according to the request failure: fail and discard the current transaction, roll back the transaction and give a clear failure prompt message.

[0124] If no information related to the current transaction is found, it means that the service provider has not received the request, and the operation request can be retried. If the operation request continues to fail with compensable failures, it is necessary to query again. The process of "operation-query-confirmation result" can be repeated. The number of retries and retry intervals can refer to the relevant content of "1. Query services" above. However, the operation request cannot be retried multiple times in a row to avoid a large number of repeated transactions, thereby expanding asset losses.

[0125] If the first round of retries still fails, the current transaction will be suspended and an alarm notification or message will be sent to the technical staff to notify the relevant personnel to intervene and troubleshoot the problem in time. When the problem is solved or the scheduled time is reached, the suspension state can be ended manually or automatically to enter the second round of retries.

[0126] If the second round of retries still fails, it needs to be processed as a failure: fail and discard the current transaction, roll back the transaction and give a clear failure prompt message, try to call the service interface for the undo operation, and in addition, send an alarm notification or message to the technical staff to notify the relevant personnel to intervene in time to troubleshoot the problem to ensure the success of the next request.

[0127] One thing to note is that only when the query result shows that the current transaction has failed to be processed or no relevant information about the current transaction is found, can it be judged as a failure and processed as a failure. Otherwise, for example, when the query fails to obtain results, the safest way is to suspend the transaction and let humans determine whether to continue or fail.

[0128] See also Figure 4 , a fourth embodiment of the service request processing method in the embodiment of the present invention includes:

[0129] 401, real-time detection of whether there are services with failed service requests in the third-party service provider system;

[0130] 402. If so, collect the corresponding request log from the log storage area of ​​the third-party service provider system according to the service request, call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters;

[0131] 403. According to the failure factor, a corresponding compensable failure case is matched from a preset compensable failure list to obtain a matching result;

[0132] 404, identify whether repeated requests for compensable failure cases in matching results have an impact on normal requests of other services;

[0133] 405. If not, determine that the compensation mechanism includes two different first retry control strategies and a second retry control strategy;

[0134] 406. Retry the failed service according to the first retry control strategy and the second retry control strategy.

[0135] In this step, the first retry control strategy is specifically executed to retry the failed service;

[0136] If no feedback information of the requested service is received after the retry operation, the timer is started;

[0137] After the timer expires, the second retry control strategy is executed to request again the service that failed after the second request.

[0138] In this embodiment, specifically, the time parameter of at least one retry in the first retry control strategy is parsed; a retry scheduling control code is generated according to the time parameter of at least one retry; a retry operation is performed on the failed service according to the retry scheduling control code; after the retry operation is completed, the state of the failed service after the retry is queried; if the state is a failed state, a timer is started to perform a countdown calculation of the first time threshold;

[0139] If the timing is reached, the retry scheduling control code is executed to retry the failed service for a second time, until the timing reaches the time threshold corresponding to the time parameter of at least one retry, and then the second retry control strategy is executed to re-request the service that failed after the second request.

[0140] In this embodiment, after executing the second retry control strategy to request again the service that failed after the second request, the method further includes:

[0141] Detecting whether the status of the failed service is a successful status;

[0142] If not, the status of the failed service is maintained as a failed status, and a fault warning signal is generated to notify the user to perform troubleshooting.

[0143] Through the implementation of the above-mentioned solution, the following effects are achieved:

[0144] 1. According to the characteristics of different scenarios, appropriate compensation mechanisms can be selected to solve problems more efficiently and specifically.

[0145] 2. By reusing existing and relatively mature solutions, work efficiency can be improved, the difficulty and workload of connecting with third-party services can be reduced, and the risk of errors made by novices or inexperienced personnel when connecting with third-party services can be reduced.

[0146] 3. The compensation mechanism listed in this proposal is a basic solution that has been refined and summarized. In actual production, it can be flexibly combined and spliced ​​according to the current business situation to form more combined solutions to solve more complex problems.

[0147] The service request processing method in the embodiment of the present invention is described above. The service request processing device in the embodiment of the present invention is described below. Please refer to Figure 5 , an embodiment of the service request processing device in the embodiment of the present invention includes:

[0148] A detection module 501 is used to detect in real time whether there is a service whose service request fails in the third-party service providing system;

[0149] A generating module 502 is used to collect corresponding request logs from the log storage area of ​​the third-party service providing system according to the service request when detecting a service with a service request failure, and call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters;

[0150] A matching module 503 is used to match corresponding compensable failure cases from a preset compensable failure list according to the failure factor to obtain a matching result;

[0151] The retry module 504 is used to determine a corresponding compensation mechanism according to the matching result, and execute the compensation mechanism to retry the failed service, wherein the compensation mechanism includes at least two different retry control strategies.

[0152] By implementing the above methods, appropriate compensation mechanisms can be selected according to the characteristics of different failure factors to solve problems more efficiently and specifically. At the same time, by reusing existing and relatively mature solutions, work efficiency can be improved, the difficulty and workload of connecting with third-party services can be reduced, and the risk of errors made by novices or inexperienced personnel when connecting to third-party services can be reduced.

[0153] See also Figure 6 Another embodiment of the service request processing device in the embodiment of the present invention includes:

[0154] A detection module 501 is used to detect in real time whether there is a service whose service request fails in the third-party service providing system;

[0155] A generating module 502 is used to collect corresponding request logs from the log storage area of ​​the third-party service providing system according to the service request when detecting a service with a service request failure, and call a preset log analysis tool to parse the service request parameters recorded in the request log, and generate a failure factor based on the service request parameters;

[0156] A matching module 503 is used to match corresponding compensable failure cases from a preset compensable failure list according to the failure factor to obtain a matching result;

[0157] The retry module 504 is used to determine a corresponding compensation mechanism according to the matching result, and execute the compensation mechanism to retry the failed service, wherein the compensation mechanism includes at least two different retry control strategies.

[0158] In this embodiment, the failure factors include a request method and a failure occurrence node, and the matching module 503 is specifically used to: match the request method with request methods of different types of services, and determine the service type corresponding to the service request, wherein the service type includes query type services, operation type services, and notification type services; determine the corresponding compensable failure list according to the service type, and use the failure occurrence node as a matching index to match the corresponding compensable failure case from the compensable failure list to generate a matching result.

[0159] In this embodiment, the retry module 504 includes:

[0160] An identification unit 5041 is used to identify whether the repeated requests of the compensable failure case in the matching result have an impact on the normal requests of other services;

[0161] A determining unit 5042, configured to determine, when there is an impact, that the compensation mechanism includes two different first retry control strategies and a second retry control strategy;

[0162] A first retry unit 5043, configured to execute the first retry control strategy to request the failed service again;

[0163] The timing unit 5044 is used to start a timer if no feedback information of the requested service is received after the second request;

[0164] The second retry unit 5045 is used to execute the second retry control strategy to re-request the service that failed after the timer expires.

[0165] In this embodiment, the service request processing device further includes a failure processing module 505, which is specifically used to:

[0166] When the repeated requests for identifying the compensable failure cases in the matching results have an impact on the normal requests of other services, calling the query service interface to send a status query request to the service to query whether the service has been retried or whether the failure has been processed;

[0167] If yes, then end the retry operation on the service;

[0168] If not, retry the failed service according to the first retry control strategy.

[0169] In this embodiment, the timing unit 5044 is also used for:

[0170] If the service type is an operation service, the state of the failed service is adjusted to a suspended state, and a warning signal is generated according to the failure factor;

[0171] Executing the warning signal and triggering a timer to start timing; detecting whether there is a change in the suspended state;

[0172] If so, monitoring whether there is feedback information corresponding to the service request;

[0173] If not, the second retry unit is used to execute the second retry control strategy to re-request the service that failed after the re-request after the timer expires.

[0174] In this embodiment, the first retry unit 5043 is specifically used for:

[0175] Parsing the time parameter of at least one retry in the first retry control strategy; generating a retry scheduling control code according to the time parameter of at least one retry;

[0176] Perform a retry operation on the failed service according to the retry scheduling control code;

[0177] After the retry operation is completed, query the status of the failed service after the retry;

[0178] If the state is a failure state, starting a timer to perform a countdown calculation for a first time threshold;

[0179] If the timing is reached, the retry scheduling control code is executed to retry the failed service for a second time, until the timing reaches the time threshold corresponding to the time parameter of at least one retry, and then the second retry control strategy is executed to re-request the service that failed after the second request.

[0180] In this embodiment, the service request processing device also includes a prompt module 506 for detecting whether the status of the failed service is a successful status; if not, the status of the failed service is maintained as a failed status, and a fault warning signal is generated to notify the user to perform troubleshooting.

[0181] Through the implementation of the above method, when a failed service request is detected in the third-party service provider system, the log analysis tool is used to analyze the failure factors in the logs of the failed service, and the corresponding compensation mechanism is matched based on the analyzed failure factors. The failed service is retried based on the compensation mechanism. The retry here uses at least two different retry control strategies to perform retry control. Such retry control is more flexible, occupies less server resources, improves the stability of the server, and the probability of successful compensation is also greatly improved.

[0182] See also Figure 7 , an embodiment of the service request processing device in the embodiment of the present invention is described in detail below from the perspective of hardware processing.

[0183] Figure 7 : is a structural diagram of a service request processing device provided by an embodiment of the present invention. The service request processing device 700 may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) 710 (for example, one or more processors) and a memory 720, and one or more storage media 730 (for example, one or more mass storage devices) storing application programs 733 or data 732. Among them, the memory 720 and the storage medium 730 can be short-term storage or permanent storage. The program stored in the storage medium 730 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the routing-based service request processing device 700. Furthermore, the processor 710 may be configured to communicate with the storage medium 730 to execute a series of instruction operations in the storage medium 730 on the service request processing device 700.

[0184] The service request processing device 700 may also include one or more power supplies 740, one or more wired or wireless network interfaces 750, one or more input and output interfaces 760, and / or one or more operating systems 731, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. It will be appreciated by those skilled in the art that Figure 7 The structure of the service request processing device shown does not constitute a limitation on the service request processing device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0185] The blockchain referred to in this invention is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the blockchain underlying platform, platform product service layer, and application service layer.

[0186] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions are executed on a computer, the computer executes the steps of the service request processing method.

[0187] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0188] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the whole or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0189] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A service request processing method, applied to a third-party service provision system, characterized in that: The service request processing method comprises: Real-time detection of whether there are services with failed service requests in the third-party service provider system; If so, collecting the corresponding request log from the log storage area of ​​the third-party service providing system according to the service request, identifying the access parameters in the request log using a log analysis tool, determining the issuing terminal of the service request based on the access parameters, extracting the proxy server information and access terminal information configured by the issuing terminal in the third-party service providing system, and generating the failure factor of the service request based on the proxy server information and the access terminal information; According to the failure factor, a corresponding compensable failure case is matched from a preset compensable failure list to obtain a matching result; Identify whether repeated requests for compensable failure cases in the matching results have an impact on normal requests for other services; If not, determining the compensation mechanism includes two mutually different first retry control strategies and second retry control strategies; Execute the first retry control strategy to request the failed service again; If no feedback information is received after the second request, the timer is started; After the timer expires, the second retry control strategy is executed to request again the service that failed after the second request.

2. The service request processing method according to claim 1, characterized in that: The failure factors include the request mode and the failure occurrence node. According to the failure factors, the corresponding compensable failure cases are matched from the preset compensable failure list, and the matching results include: Matching the request mode with request modes of different types of services to determine the service type corresponding to the service request, wherein the service type includes query type service, operation type service and notification type service; A corresponding compensable failure list is determined according to the service type, and the failure occurrence node is used as a matching index to match the corresponding compensable failure case from the compensable failure list to generate a matching result.

3. The service request processing method according to claim 1, characterized in that: If the repeated requests for identifying the compensable failure cases in the matching results have an impact on normal requests of other services, after determining that the compensation mechanism includes two different first retry control strategies and second retry control strategies, the method further includes: Calling the query service interface to send a status query request to the service to query whether the service has been retried or whether the failure has been processed; If yes, then end the retry operation on the service; If not, retry the failed service according to the first retry control strategy.

4. The service request processing method according to claim 3, characterized in that: If the service type is an operation service, the starting timer timing includes: Adjusting the state of the failed service to a suspended state, and generating an early warning signal according to the failure factor; Execute the warning signal and trigger the timer to start timing; Detecting whether there is a change in the suspended state; If so, monitoring whether there is feedback information corresponding to the service request; If not, after the timer expires, the second retry control strategy is executed to request again the service that failed after the second request.

5. The service request processing method according to claim 1, 3 or 4, characterized in that: The executing the first retry control strategy to request the failed service again comprises: parsing a time parameter of at least one retry in the first retry control strategy; Generate a retry scheduling control code according to a time parameter of at least one retry; Perform a retry operation on the failed service according to the retry scheduling control code; After the retry operation is completed, query the status of the failed service after the retry; If the state is a failure state, starting a timer to perform a countdown calculation for a first time threshold; If the timing is reached, the retry scheduling control code is executed to retry the failed service for a second time, until the timing reaches the time threshold corresponding to the time parameter of at least one retry, and then the second retry control strategy is executed to re-request the service that failed after the second request.

6. The service request processing method according to claim 5, characterized in that: After executing the second retry control strategy to request again the service that failed after the second request, the method further includes: Detecting whether the status of the failed service is a successful status; If not, the status of the failed service is maintained as a failed status, and a fault warning signal is generated to notify the user to perform troubleshooting.

7. A service request processing device, characterized in that: The service request processing device comprises: A detection module is used to detect in real time whether there are services with failed service requests in the third-party service provider system; A generation module, for, when detecting a service with a failed service request, collecting a corresponding request log from a log storage area of ​​the third-party service providing system according to the service request, identifying access parameters in the request log using a log analysis tool, determining an issuing terminal of the service request based on the access parameters, extracting proxy server information and access terminal information configured by the issuing terminal in the third-party service providing system, and generating a failure factor of the service request based on the proxy server information and the access terminal information; A matching module, used to match corresponding compensable failure cases from a preset compensable failure list according to the failure factor to obtain a matching result; A retry module is used to identify whether repeated requests for compensable failure cases in the matching results have an impact on normal requests for other services; if not, determine that the compensation mechanism includes two different first retry control strategies and a second retry control strategy; execute the first retry control strategy to request the failed service again; if no feedback information of the requested service is received after the second request, start a timer; after the timer expires, execute the second retry control strategy to request the service that failed after the second request again.

8. A service request processing device, characterized in that: The service request processing device comprises: a memory and at least one processor, wherein instructions are stored in the memory; The at least one processor calls the instruction in the memory to enable the service request processing device to execute the service request processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the service request processing method according to any one of claims 1 to 6 is implemented.

Images