Processing method and device for service calling

Abstract

The invention discloses a processing method and device for service calling, and relates to the field of distributed technologies. The method comprises the following steps: detecting whether a target service has idempotent attributes or not; when it is detected that the target service has idempotent attributes and the calling result of the target service is in a suspicious state, S times of calling processing is conducted on the target service, and the calling state of the target service is marked according to the processing result of the S times of calling processing; when it is detected that the target service does not have idempotent attributes and the calling result of the target service is in a suspicious state, determining whether the target service is a target abnormal service according to a first configuration table; and when it is detected that the target service is the target abnormal service, calling the query service to query the target service to obtain a query result, and marking a calling state of the target service according to the query result. According to the method and the device, the technical problem that the uncertainty of the transaction state is increased due to the fact that result suspicious states are frequently encountered when online services are called in batch jobs is solved.

Description

Technical Field

[0001] This application relates to the field of distributed technology, and more specifically, to a method and apparatus for processing service calls. Background Technology

[0002] In today's era of distributed service architecture, batch job processing in large-scale software systems faces unprecedented challenges. Batch jobs typically involve calls to multiple online services. Under high concurrency, unstable networks, or high system load, this can easily lead to service response delays, timeouts, or non-final states, making the transaction results uncertain and increasing system complexity and operational costs. Traditional batch job processing strategies, such as retry logic for a single service or manual review of suspicious transactions, can alleviate the problem to some extent, but they lack a unified consideration of the entire system and intelligent processing capabilities, making them unsuitable for the requirements of today's large-scale distributed systems.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method and apparatus for processing service calls, which at least solves the technical problem that in large software systems with distributed services, batch job calls to online services frequently encounter suspicious results, leading to increased uncertainty in transaction status.

[0005] According to one aspect of this application, a method for processing service calls is provided, comprising: detecting whether a target service has an idempotent property, wherein the idempotent property is used to characterize that the number of calls to the target service does not affect the resource status on the server; when the target service is detected to have an idempotent property and the call result of the target service is a suspicious state, performing S call processing on the target service, and marking the call status of the target service according to the processing results of the S call processing, wherein S is an integer greater than 1 and less than or equal to a preset number, the processing result is a call success or a call failure, and a suspicious state is a state other than a call success or a call failure; when the target service is detected not to have an idempotent property and the call result of the target service is a suspicious state, determining whether the target service is a target abnormal service according to a first configuration table, wherein the first configuration table is used to manage update-type service information that needs to be queried for call status; when the target service is detected to be a target abnormal service, calling a query service to query the target service, obtaining query results, and marking the call status of the target service according to the query results, wherein the query service is used to query the call information of the target service.

[0006] Optionally, before detecting whether the target service has idempotent properties, the method further includes: obtaining the call result of the target service; obtaining the target value and error code from the call result, wherein the target value is used to characterize the call status of the target service, and the error code is used to characterize the error reason code; when the target value and / or error code meet any of the following conditions, the call result of the target service is determined to be in a suspicious state: a first condition, wherein the first condition is used to characterize the target value as 2; a second condition, wherein the second condition is used to characterize the target value as empty; a third condition, wherein the third condition is used to characterize the target value as 1 and the error code type as either type 1 or type 2, wherein type 1 is used to characterize the target service as requiring call status confirmation, and type 2 is used to characterize the target service as requiring multiple re-call processing.

[0007] Optionally, the query service is invoked to query the target service, obtain query results, and mark the call status of the target service based on the query results. This includes: obtaining the target class from the first configuration table and invoking the query service based on the target class, wherein the target class is used to load components from the first configuration table for querying and confirming the call status of the target service; obtaining log information of the target service during the call process through the query service; querying the call status information of the target service from the log information, obtaining query results, and marking the call status of the target service based on the query results.

[0008] Optionally, query the call status information of the target service from the log information to obtain the query results, and mark the call status of the target service according to the query results, including: when the query result is detected as a successful or failed call, mark the call status of the target service according to the query results; when the query result is detected as a suspicious status, perform R query processing on the log information to obtain the query results, where R is an integer greater than 1 and less than or equal to a first preset number of times; when the query results corresponding to the R query processing are all suspicious statuses, mark the call status of the target service as a failed call; when the query result corresponding to any one of the R query processing is a successful or failed call, mark the call status of the target service according to the query result.

[0009] Optionally, the method further includes: when it is detected that the call to the target service is in a rate-limited state, obtaining the sleep time from the target configuration table, wherein the target configuration table is used to manage the parameter configuration during the service call process; after the time for stopping the call to the target service is greater than the sleep time, performing T call processing on the target service, wherein T is an integer greater than 1; when it is detected that T is greater than or equal to a second preset number of times, if the call to the target service is in a rate-limited state, then marking the call status of the target service as a call failure.

[0010] Optionally, after determining whether the target service is a target abnormal service based on the first configuration table, the method further includes: if the configuration information of the target service is not found in the first configuration table, determining the processing logic of the target service based on the third configuration, wherein the third configuration is used to uniformly manage and distribute configuration information, and the processing logic is used to characterize whether the target service is processed by multiple calls; and processing the target service according to the processing logic.

[0011] Optionally, the method further includes: detecting the service type of the target service, wherein the service type is a query service or an update service; when the service type of the target service is detected to be an update service, if an error code exists in the first configuration table, then the error code type is determined to be the first type; when the service type of the target service is detected to be a query service, if an error code exists in the second configuration table, then the error code type is determined to be the second type, wherein the second configuration table is used to manage the error code list corresponding to the query service, and all error codes in the error code list are of the second type.

[0012] According to another aspect of this application, a processing apparatus for service calls is also provided, comprising: a first detection unit, configured to detect whether a target service possesses an idempotent property, wherein the idempotent property characterizes that the number of calls to the target service does not affect the resource status on the server; a first processing unit, configured to perform S call processing on the target service when the target service is detected to possess an idempotent property and the call result of the target service is in a suspicious state, and to mark the call status of the target service according to the processing results of the S call processing, wherein S is an integer greater than 1 and less than or equal to a preset number, the processing result is a call success or a call failure, and a suspicious state is a state other than a call success or a call failure; a first determination unit, configured to determine whether the target service is a target abnormal service according to a first configuration table when the target service is detected to lack an idempotent property and the call result of the target service is in a suspicious state, wherein the first configuration table is used to manage update-type service information that requires call status query; and a second processing unit, configured to call a query service to query the target service when the target service is detected to be a target abnormal service, obtain query results, and mark the call status of the target service according to the query results, wherein the query service is used to query the call information of the target service.

[0013] According to another aspect of this application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the above-described processing method for service invocation.

[0014] According to another aspect of this application, an electronic device is also provided, including one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the above-described processing method for service invocation.

[0015] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps of the above-described processing method for service invocation.

[0016] In this application, the first step is to detect whether the target service possesses idempotency, where idempotency characterizes that the number of calls to the target service does not affect the resource status on the server. If the target service is detected to possess idempotency and the call result is suspicious, the target service is processed with S calls, and the call status is marked based on the processing results of these S calls, where S is an integer greater than 1 and less than or equal to a preset number of calls, and the processing result is either a successful call or a failed call. Suspicious status refers to any status other than successful or failed calls. If the target service is detected to lack idempotency and the call result is suspicious, the first configuration table is used to determine whether the target service is an abnormal service. This first configuration table manages update-type service information that requires call status queries. If the target service is detected to be an abnormal service, a query service is invoked to query the target service, obtain the query result, and mark the call status of the target service based on the query result. This query service is used to query the call information of the target service. In other words, by using intelligent judgment, dynamic retry and confirmation processes, the system achieves the goal of automatically identifying and handling uncertain states in service call results, thereby improving the success rate of batch job calls and system stability. This solves the technical problem of frequently encountering suspicious results when batch job calls online services in large-scale distributed service software systems, which leads to increased uncertainty in transaction status. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a flowchart of an optional processing method for service invocation according to an embodiment of this application;

[0019] Figure 2 This is an optional batch service suspicious status automatic retry filter link flowchart according to an embodiment of this application;

[0020] Figure 3 This is a flowchart of an optional batch service automatic retry for suspicious requests according to an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of an optional processing apparatus for service invocation according to an embodiment of this application. Detailed Implementation

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

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

[0024] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0025] According to an embodiment of this application, a method embodiment for processing service calls is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0026] It should be noted that an intelligent processing system can serve as the execution subject of the service invocation processing method in this application embodiment. It is understood that the service invocation processing method provided in this application embodiment can also be executed by other systems or devices, and this application embodiment does not specifically limit this.

[0027] Figure 1 This is a flowchart of an optional processing method for service invocation according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0028] Step S101: Detect whether the target service has idempotent properties.

[0029] In step S101, the idempotency attribute is used to characterize that the number of times the target service is called does not affect the resource status on the server.

[0030] Optionally, idempotency is a property of the target service that ensures the same impact on server resource state regardless of how many times the service is called; that is, multiple calls are equivalent to a single call. In distributed systems, idempotency in service calls means that the system state and final result remain consistent regardless of how many times the same operation is executed, and no side effects are generated due to multiple executions.

[0031] Optionally, the intelligent processing system will first check whether the target service supports idempotency. By checking the service's invoked interface or the service idempotency information in the configuration table, the system can determine whether the service meets the idempotency condition. This step helps in formulating subsequent retry strategies and avoids data security issues that may be caused by retries of non-idempotent services.

[0032] Step S102: When it is detected that the target service has idempotent properties and the call result of the target service is suspicious, the target service is processed by S calls, and the call status of the target service is marked according to the processing result of the S calls.

[0033] In step S102, S is an integer greater than 1 and less than or equal to a preset number of times. The processing result is either a successful call or a failed call. Suspicious states are states other than successful and failed calls.

[0034] Optionally, suspicious states include: when a service call returns a timeout, a status indicating that the transaction is in progress or pending confirmation, or a null value is returned if no data is obtained from the server, or various custom error codes are returned, and further confirmation or retry is required, the service call is deemed suspicious.

[0035] Optionally, the S-call processing refers to the number of automatic retries performed on the idempotent service based on configuration parameters, where S is an integer greater than 1 but does not exceed the preset maximum number of retries. In this embodiment, S is 3.

[0036] Optionally, when the intelligent processing system detects that the result of a target service call with idempotent properties is in a suspicious state, it will automatically trigger a retry process. The system will retry the service S times, where the value of S can usually be preset according to the service characteristics and network environment. If the service call succeeds after S retries, it is marked as successful; if it still fails, it is marked as failed, and detailed retry information is recorded for subsequent fault analysis and handling.

[0037] Step S103: When it is detected that the target service does not have idempotent properties and the call result of the target service is suspicious, determine whether the target service is an abnormal target service according to the first configuration table.

[0038] In step S103, the first configuration table is used to manage update-type service information that requires call status query.

[0039] Optionally, the first configuration table (also known as the service retry configuration table) manages information on update-type services that require call status queries, i.e., a list of non-idempotent services that require additional confirmation.

[0040] Optionally, for target services that do not possess idempotency, the intelligent processing system checks whether their call results are also in a suspicious state. If so, it identifies whether the service is marked as an abnormal service by querying the "first configuration table," meaning a service whose final state requires an additional confirmation process. This step is designed for the special case of non-idempotent services to avoid potential data state errors or resource waste that might result from direct retries.

[0041] Step S104: When the target service is detected as an abnormal target service, the query service is invoked to query the target service, the query results are obtained, and the call status of the target service is marked according to the query results.

[0042] In step S104, the query service is used to query the call information of the target service.

[0043] Optionally, a query service: This service is specifically designed to query and confirm the status of service calls. It uses information such as channel logs to determine the actual processing results of update-type services.

[0044] Optionally, once a non-idempotent target service is determined to be an abnormal service and its call result is suspicious, the intelligent processing system will invoke the "Query Service." The Query Service will use a specific Handler class to confirm the suspicious transaction based on information in the "Service Suspicious Transaction Retry Configuration" table. It analyzes channel logs or server-side status to determine the actual processing result of the service call, confirming whether the transaction was successful or failed, thus avoiding the uncertainty and erroneous data states that may result from direct retries. If a clear status cannot be determined after multiple attempts, it is marked as a failure, and relevant logs are recorded for subsequent tracking and troubleshooting.

[0045] As can be seen from steps S101 to S104, in this application, firstly, it is detected whether the target service has an idempotent property, where the idempotent property is used to characterize that the number of calls to the target service does not affect the resource status on the server; when it is detected that the target service has an idempotent property and the call result of the target service is suspicious, the target service is processed by S calls, and the call status of the target service is marked according to the processing result of the S calls, where S is an integer greater than 1 and less than or equal to a preset number, the processing result is a call success or a call failure, and a suspicious status is a status other than a call success or a call failure; when it is detected that the target service does not have an idempotent property and the call result of the target service is suspicious, it is determined whether the target service is a target abnormal service according to the first configuration table, where the first configuration table is used to manage update service information that needs to be queried for call status; when it is detected that the target service is a target abnormal service, the query service is called to query the target service, the query result is obtained, and the call status of the target service is marked according to the query result, where the query service is used to query the call information of the target service. In other words, by using intelligent judgment, dynamic retry and confirmation processes, the system achieves the goal of automatically identifying and handling uncertain states in service call results, thereby improving the success rate of batch job calls and system stability. This solves the technical problem of frequently encountering suspicious results when batch job calls online services in large-scale distributed service software systems, which leads to increased uncertainty in transaction status.

[0046] In one optional embodiment, the intelligent processing system obtains the call result of the target service, and then obtains the target value and error code from the call result. The target value is used to characterize the call status of the target service, and the error code is used to characterize the error reason. When the target value and / or error code meet any of the following conditions, the call result of the target service is determined to be in a suspicious state: a first condition, wherein the first condition is used to characterize the target value as 2; a second condition, wherein the second condition is used to characterize the target value as empty; a third condition, wherein the third condition is used to characterize the target value as 1 and the error code type as either a first type or a second type, wherein the first type is used to characterize the target service as requiring call status confirmation, and the second type is used to characterize the target service as requiring multiple re-call processing.

[0047] Optionally, during batch job execution, after each service call is completed, the intelligent processing system immediately captures the call result of the target service. The call result contains all information returned after the service execution, including but not limited to the target value and error code. The target value is a key indicator used to intuitively reflect the status of the service call; while the error code provides clues about specific problems that may have occurred during the service call process.

[0048] Optionally, the system will then further parse the call result to extract the target value and error code. The target value may be an enumerated value or a status code, used to characterize the service's execution status; the error code is a standard or custom error code that reveals the specific reason for the service call failure. The system will check these two parameters one by one to determine whether the service call result falls into the category of suspicious states.

[0049] Optionally, the intelligent processing system evaluates the target value and error code according to preset suspicious status judgment rules. Specifically, the judgment of a suspicious status follows one of the following three conditions: First condition: The target value is 2. This usually means that the service call returned a non-final state, such as transaction processing or awaiting confirmation. This type of state requires further confirmation or processing to determine its true result. Second condition: The target value is empty. An empty value often indicates that some form of data loss or network failure occurred during the service call, causing the server to fail to respond correctly or return valid status information. Third condition: The target value is 1 and the error code belongs to the first or second type. Here, 1 usually means that the service call appears to be successful, but there may actually be hidden errors or exceptions, requiring further retry or confirmation. The first and second types of error codes correspond to scenarios where the service call needs status confirmation and scenarios where multiple calls need to be made, respectively. These types are specified in the "Service Suspicious Account Retry Configuration" table to ensure that the system can respond appropriately according to the characteristics of the service.

[0050] Optionally, once the call result is determined to be suspicious, the intelligent processing system will take different strategies based on the service's attributes (idempotency).

[0051] As described above, by employing refined target value and error code checks, intelligent identification and handling of suspicious states encountered when batch jobs call online services are achieved. This method not only promptly captures uncertainties in service responses but also reacts quickly based on specific conditions, avoiding resource waste caused by blind retries and invalid acknowledgments. More importantly, it significantly improves the success rate of batch job processing and the overall stability of the system without increasing manual intervention. It is particularly suitable for handling call anomalies in large-scale, high-concurrency distributed service environments, effectively maintaining data integrity and transaction continuity.

[0052] In one optional embodiment, the intelligent processing system obtains the target class from the first configuration table and calls the query service based on the target class. The target class is used to load the component for querying and confirming the call status of the target service from the first configuration table. Then, the system obtains the log information of the target service during the call process through the query service, queries the call status information of the target service from the log information, obtains the query result, and marks the call status of the target service according to the query result.

[0053] Optionally, after identifying a service call result as suspicious, the intelligent processing system will read the target class (Handler class) information related to the target service from the first configuration table. Here, the target class is actually a collection of predefined components specifically designed to handle suspected anomalies in a particular service. The first configuration table stores the attributes of various services, including whether suspicious account confirmation is required and the corresponding suspicious account processing logic.

[0054] Optionally, once the target class is accurately loaded, the intelligent processing system invokes the query service based on these component logics. The query service's task is to delve into the service call history logs to find all log records related to the target service call. These log records contain all the details of the service call process, including input parameters, output results, and any exceptions that occurred, providing a sufficient information basis for subsequent call status confirmation.

[0055] Optionally, the query service extracts key data related to the target service call status from the log information. This data may include the actual status of the transaction (such as success, failure, or incomplete), any relevant error messages, and other details that may help determine the call status. By analyzing this data, the query service can construct a complete call activity graph, thereby accurately determining the true status of the service call.

[0056] Optionally, after the query service completes its analysis and returns the query results, the intelligent processing system updates the call status flag of the target service based on these results. If the query results show that the service call has actually succeeded, the system will mark it as successful; if the query confirms that the call has failed, or confirms that the call status is still in an uncertain state, the system will mark it as failed. Through this marking process, batch jobs can immediately grasp the final status of each service call, ensuring that subsequent batch processing logic is executed correctly.

[0057] As described above, the intelligent processing system, by introducing a target class (Handler class), can intelligently invoke query services based on service characteristics and configurations, obtaining detailed logs of the call process. This allows for accurate determination of the call status, avoiding data conflicts and resource waste that may result from repeated calls. This approach not only improves the processing accuracy of batch jobs but also significantly enhances system stability and efficiency. Especially when handling high-concurrency, complex call scenarios, it effectively reduces operational burden and improves overall service quality.

[0058] In one optional embodiment, when the intelligent processing system detects that the query result is either a successful call or a failed call, it marks the call status of the target service according to the query result; when the query result is detected as a suspicious status, it performs R query processing on the log information to obtain the query result, where R is an integer greater than 1 and less than or equal to a first preset number of times; when the query results corresponding to the R query processing are all suspicious statuses, the call status of the target service is marked as a failed call; when the query result corresponding to any one of the R query processing is either a successful call or a failed call, the call status of the target service is marked according to the query result.

[0059] Optionally, when the intelligent processing system receives the query result and displays the service call status as either successful or failed, it immediately marks the call status of the target service without further processing. This instant confirmation mechanism ensures that the system can quickly respond to clear call results, avoiding unnecessary queries and retries, thereby saving computing resources and accelerating the execution speed of batch jobs.

[0060] Optionally, for suspicious states, the intelligent processing system will perform further R queries. Here, R is a predefined integer value that specifies the upper limit of the number of times the system will attempt to confirm when faced with uncertain call results. The value of R must be greater than 1 to ensure at least two confirmation attempts, and also less than or equal to the first preset number. This parameter can be flexibly set in the "Service Suspicious Account Retry Configuration" table according to service characteristics and system requirements, ensuring that status confirmation is performed within a controllable range and avoiding resource waste caused by infinite loops or excessive queries.

[0061] Optionally, during the R query processing steps, the intelligent processing system dynamically determines the call status of the target service based on each query result: if any query result in the R query processing steps shows a successful or failed call, the intelligent processing system will immediately mark the call status of the target service based on this query result, thereby quickly determining the final state of the service call, avoiding unnecessary subsequent query operations, and improving the decision-making efficiency of batch jobs. However, if after R query processing steps all query results still show a suspicious state, the intelligent processing system will ultimately mark the call status of the target service as a failed call. This mechanism ensures that after multiple confirmation attempts, the system can make a final decision, avoiding a long period of uncertainty and providing a deterministic basis for the subsequent processing of batch jobs.

[0062] As can be seen from the above, the core of the implementation steps lies in providing an automated R-times query confirmation mechanism for the results of non-deterministic service calls. Through the implementation of R-times query processing, the system can effectively cope with the uncertainty of service call states, ensuring that batch jobs can make decisions based on accurate service status information during execution. This method not only improves the accuracy and efficiency of batch job processing but also prevents system performance problems that may be caused by infinite loop queries by setting an upper limit on the number of queries, thus ensuring the stable operation of the system.

[0063] In one optional embodiment, when the intelligent processing system detects that the call to the target service is in a rate-limited state, it obtains the sleep time from the target configuration table, wherein the target configuration table is used to manage the parameter configuration during the service call process, and after the time for stopping the call to the target service is greater than the sleep time, it performs T call processing on the target service, wherein T is an integer greater than 1. When it is detected that T is greater than or equal to a second preset number of times, if the call to the target service is in a rate-limited state, the call status of the target service is marked as a call failure.

[0064] Optionally, rate limiting: Service rate limiting is a technical means to protect system resources and prevent overload. It ensures system stability and availability by limiting the frequency of user or system access to a service within a unit of time. In distributed systems, rate limiting is a crucial element, especially in high-traffic scenarios, as it prevents resources from being overused, thereby avoiding service crashes.

[0065] Optionally, the intelligent processing system continuously monitors the call status of the target service when making batch service calls. When the system detects that a service call has entered a rate-limiting state due to network congestion, resource limitations, or other reasons, meaning that the service is temporarily unable to accept or process new requests, the system will take immediate action to avoid further request surges and maintain stable system operation.

[0066] Optionally, once rate limiting is detected, the intelligent processing system will look up the sleep time associated with the service from the target configuration table. The target configuration table is an important parameter management component in the system, storing various configuration parameters during service calls, such as the number of retries, retry interval, and error code mapping. The sleep time here is to avoid frequent requests for the same service during rate limiting, which would cause unnecessary resource waste and system pressure.

[0067] Optionally, upon detecting a rate-limiting state, the system will suspend calls to the target service and enter a waiting mode. The waiting time must be longer than the sleep time; this interval provides sufficient buffer time for the server to process the backlog of requests and restore its processing capacity. After the waiting period ends, the intelligent processing system will process the target service T times, where T is an integer greater than 1, representing the number of times the system will attempt to re-call the service.

[0068] Optionally, during the processing of T calls, if T is greater than or equal to a second preset number, and the call to the target service remains in a rate-limited state, the intelligent processing system will determine that the service call cannot recover normally within a reasonable time, and thus mark the call status of the target service as a call failure. This decision-making mechanism ensures that batch jobs can react promptly when faced with a prolonged rate-limited state, avoiding indefinite waiting and resource waste.

[0069] As shown above, by introducing dynamic waiting and retry mechanisms, the rate-limiting state during service calls is effectively addressed, ineffective retries during rate-limiting periods are avoided, and the pressure on the server is reduced. By obtaining sleep time and retry count from the target configuration table, the intelligent processing system can intelligently adjust the retry strategy based on the service characteristics and the current network environment, ensuring that service calls can be quickly restored after rate limiting is lifted, thereby improving the processing efficiency of batch jobs and the robustness of the system.

[0070] In an optional embodiment, if the configuration information of the target service is not found in the first configuration table, the intelligent processing system will determine the processing logic of the target service according to the third configuration. The third configuration is used to uniformly manage and distribute configuration information, and the processing logic is used to characterize whether the target service is called multiple times. Then, the target service is processed according to the processing logic.

[0071] Optionally, the intelligent processing system first queries the "Service Suspicious Call Retry Configuration Table" (first configuration table) for the configuration information of the target service, including but not limited to the service's idempotency, retry policy, and error code mapping. This information is crucial for the intelligent processing system to determine how to handle the suspicious state of the service call.

[0072] Optionally, if the intelligent processing system cannot find the specific configuration for the target service in the first configuration table, it will automatically switch to the third configuration, which is a more general and flexible configuration management system. Here, the system will search for the default processing logic applicable to all services according to pre-defined rules. These rules cover basic retry strategies, error handling methods, and system stability assurance measures.

[0073] Optionally, the intelligent processing system extracts corresponding processing logic from the third configuration based on the characteristics of the target service (such as service type and service level). This processing logic may include whether to initiate a retry mechanism, the number of retries, the interval between each retrieval, and under what conditions to terminate retries and mark the service call as failed. This logic aims to ensure that even in the absence of personalized configuration information, the system can handle exceptional service call situations in a reasonable and efficient manner.

[0074] Optionally, once the processing logic is determined, the intelligent processing system will immediately begin execution, making an appropriate number of calls to the target service. If a retry mechanism is selected, the system will adhere to the waiting time specified in the third configuration between each retry to avoid overloading the server. This process will continue until the service call succeeds or the maximum number of retry attempts is reached. At this point, the service call status will be permanently marked, and the batch job will adjust its subsequent processing strategy accordingly.

[0075] As can be seen from the above, by implementing the steps described, the intelligent processing system can effectively handle unknown or unconfigured anomalies that occur during service calls, ensuring that the continuity and efficiency of batch operations are not affected. This method achieves a high degree of automation and flexibility in handling service call anomalies by introducing a hierarchical configuration management mechanism, namely the first configuration table and the third configuration table.

[0076] In one optional embodiment, the intelligent processing system first detects the service type of the target service, wherein the service type is a query service or an update service; when the service type of the target service is detected to be an update service, if an error code exists in the first configuration table, the error code type is determined to be the first type; when the service type of the target service is detected to be a query service, if an error code exists in the second configuration table, the error code type is determined to be the second type, wherein the second configuration table is used to manage the error code list corresponding to the query service, and all error codes in the error code list are of the second type.

[0077] Optionally, upon receiving a service call request, the intelligent processing system first performs service type detection to determine whether the target service is a query service or an update service. Service type detection is performed by analyzing the characteristics of the call request or querying a pre-defined list of service types. This step is crucial for selecting subsequent processing logic.

[0078] Optionally, when the intelligent processing system determines that the service type is an update service, it will check if there are any error codes related to that service in the first configuration table. If so, the intelligent processing system will mark these error codes as Type 1. Error code handling for update services is typically more complex because these services involve data modification, and errors may affect data consistency and integrity. Based on the definition and handling strategy of Type 1 error codes, the system will decide whether to perform a dispute confirmation or directly retry the call. This decision-making mechanism ensures that update services receive more careful and accurate handling when encountering errors.

[0079] Optionally, for query services, the intelligent processing system will turn to a second configuration table, namely the "retryable error code configuration table," to look up the relevant error codes. If an error code is found in the second configuration table, the system marks it as a second type. Unlike update services, error code handling strategies for query services tend to favor retries because query services are usually idempotent, and multiple calls do not produce side effects. Therefore, the intelligent processing system will automatically select whether to retry the target service call, as well as the specific number of retries and the interval, based on the list of second-type error codes.

[0080] Optionally, once the error code type is determined, the intelligent processing system will execute the next operation according to the corresponding processing logic. For update services marked with a Type 1 error code, the system may call the disputed account confirmation service to confirm the transaction status through additional queries, avoiding potential data errors caused by repeated calls. For query services marked with a Type 2 error code, the system will automatically retry in order to obtain accurate query results in a short time and improve the success rate of batch operations.

[0081] As shown above, by accurately identifying and classifying service types and error code types through an intelligent processing system, the most appropriate error handling strategies can be adopted for different categories of services. This approach not only improves the flexibility and efficiency of batch job processing but also reduces resource waste and user experience degradation caused by improper error handling.

[0082] In one alternative embodiment, Figure 2 This is an optional batch service suspicious status automatic retry filter link flowchart according to an embodiment of this application, such as... Figure 2As shown, the process begins with a service consumer, which sends requests to one or more online services via batch jobs to execute specific business logic. At this point, the service request includes relevant business parameters, transaction identifiers, and other information for server-side processing and response. When a service request arrives, AOP (Aspect-Oriented Programming) interceptors come into play, intercepting the batch service calls and subsequent responses. The intervention of the interceptors ensures that specific cross-cutting concerns, such as idempotency, suspicious acknowledgments, rate limiting, and monitoring, can be uniformly handled within the service call execution chain. Under the action of the AOP interceptors, requests are sent into a chain composed of multiple filters, each responsible for handling specific logic:

[0083] Idempotent Retry Filter: Checks whether the request is an idempotent operation. If the service supports idempotency, the consistency of the call result can be guaranteed even in the case of retries. For idempotent services, the filter will decide whether to allow automatic retries based on the configuration.

[0084] Suspicious Confirmation Filter: When the service response returns a suspicious status, such as timeout, transaction in progress, pending confirmation, or null response, this filter is responsible for calling the suspicious confirmation service to confirm the final status of the transaction and avoid data inconsistency caused by repeated calls.

[0085] Rate Limiting Exception Filter: In high-concurrency scenarios, this filter checks whether the service call has triggered a rate limiting mechanism. If so, the filter will decide whether to wait for a period of time and retry, based on the rate limiting policy in the configuration, to alleviate service pressure.

[0086] Service monitoring filter: Responsible for collecting and analyzing performance data of service calls, including response time, call success rate, etc., for system monitoring and optimization.

[0087] Upon receiving a request, each Filter performs a logical judgment based on its functionality. For example, if the error code in the request corresponds to a retryable error code configured in the idempotent retry Filter, that Filter will decide to execute the retry logic. Similarly, if a service call triggers a rate limiting exception, the rate limiting exception Filter will decide whether to wait and retry the call. In the Filter chain, the execution result of each Filter serves as the input for the next Filter until the request or response is processed.

[0088] After processing through the Filter chain, the request is finally sent to the server. The server executes the request and returns a response. The intelligent processing system calls the appropriate Filter for processing based on the service response. If the response indicates that the service call was successful or failed and is in a final state, the result is returned directly to the service consumer. If the result is questionable, the Filter will retry or confirm according to a predefined strategy until a clear final result is obtained, or the retry limit is reached. At this point, the system will mark the service call as failed and record relevant information for subsequent analysis and monitoring.

[0089] It should be noted that Filter: In a distributed service framework, Filter is used to add custom filtering logic during service calls. It provides an interceptor mechanism that can intercept and process the call process between service providers and consumers.

[0090] As described above, this embodiment utilizes the Filter interceptor provided by the distributed service framework, embedding it into the service call execution chain. By intercepting service requests and responses, it processes and returns suspicious transactions. The Filter interceptor also effectively separates automatic retries for suspicious transactions from business logic, increasing the program's flexibility and scalability. It integrates multiple functions such as idempotent retry filters, suspicious confirmation filters, rate limiting exception filters, and service monitoring filters into a filter chain to process service calls with suspicious states. Furthermore, this embodiment does not intervene in service calls that return only success or failure as the final state, avoiding impact on normal service calls.

[0091] In one alternative embodiment, Figure 3 This is a flowchart of an optional batch service call for automatic retry based on an embodiment of this application, such as... Figure 3 As shown, in this embodiment, query services have idempotency by default, while update services may or may not have idempotency. Parameter switch configuration: Before batch operations begin, system administrators or developers can configure parameter switches to determine whether to enable the automatic retry aspect for suspicious cases. This decision point determines whether the system should automatically execute retry logic when encountering suspicious states during batch service calls. If the parameter switch is enabled, the system will automatically jump to the retry or suspicious account confirmation process when a service call returns a suspicious result; if the parameter switch is disabled, the system will not automatically retry, but may directly mark the service call as failed according to the preset error handling process.

[0092] Batch job service invocation: In this stage, the batch job initiates an invocation request to the online service (update or query type). This is the starting point of the entire process and the foundation for all subsequent processing.

[0093] Rate limiting: If a service call encounters a rate limiting exception, that is, under high concurrency, the backend service may limit the frequency of frontend requests in order to protect system resources.

[0094] Suspicious: During a service call, if the response result is in an unexpected state, such as "transOk=2", "transOk is empty", or "transOk=1 and the error code is configured as a retryable error code", it is considered a suspicious state. In this case, the system needs to perform further confirmation or retry to ensure the integrity and consistency of the data.

[0095] The system queries the service idempotency information configured in the parameter module: It retrieves the specific attributes of the service from the configuration module, including whether it supports idempotency. Idempotency means that the result should be the same regardless of how many times the service call is executed, without causing side effects.

[0096] Anti-duplicate mechanism: For services that do not support idempotency, the system activates an anti-duplicate mechanism to avoid redundant work or data corruption caused by duplicate request submissions. This mechanism is particularly suitable for update-type services, as update operations may have a permanent impact on the data.

[0097] Is it idempotent? If the service is idempotent, the system will further check the retryable error code configuration table to determine which service calls under which error codes can be automatically retried; if the service is not idempotent, the system will query the service question account retry configuration table to determine whether the question account confirmation service needs to be invoked to confirm the question account status.

[0098] Automatic retry / suspicious confirmation: For idempotent services, if an error code meets the retry criteria, the system will automatically retry the original service, hoping to obtain a final result of success or clear failure; for non-idempotent services, the system will call the suspicious confirmation service to determine the actual status of the service call by querying logs and other means, avoiding potential problems caused by repeated calls.

[0099] The parameter configuration module is responsible for setting the maximum number of service retries, which helps prevent resource waste caused by infinite retries.

[0100] Final State: Success or Failure: The ultimate goal of a service call is to reach a definite state—either success or failure. A success state indicates that the service request has been processed correctly; a failure state requires recording detailed reasons for the failure and may trigger subsequent error handling procedures.

[0101] For example, for query services, if the transaction is actually successful, a success status is returned directly without retrying. If the service call is error-free but the response data shows a system busy message, the value of transOk, the return code, and the return information are retrieved from the message to determine whether a retry is necessary. If the return value is transOk=2, transOk is empty, or transOk=1 and the error code is configured as a retryable error code (i.e., it can be found in the retryable error code configuration table), which meets the conditions for being considered suspicious (i.e., a suspicious status), a retry is automatically initiated. The retry count is based on the number of retries configured in the parameter module. For example, if the number of retries is 3, and a suspicious status is still returned after 3 repeated calls, it is marked as a failure according to the failure handling result, and the record of multiple failed service retryes is registered for monitoring purposes.

[0102] For update services, if the transaction is actually successful, a success status is returned directly without any suspicious confirmation. If the service call returns a suspicious result, suspicious account confirmation is required first. If the return value is transOk=2, transOk is empty, transOk=1, and the error code is configured as a suspicious account query error code or a timeout return, the service is identified as suspicious. The idempotency information configured in the parameter module is then queried. If the service has idempotency, the processing flow is the same as for query services. If it does not have idempotency, the service suspicious account retry table is queried. If found, suspicious confirmation is required. Specifically, the name of the service to be confirmed is obtained, and the "Service Suspicious Account Retry Configuration" table is queried. If the service is configured as a suspicious account query service, the suspicious service is called for querying. The actual processing status is confirmed by checking the channel logs registered during the service call process, avoiding data status errors and resource waste caused by repeated calls. If the query returns a clear status, the result is updated and returned; if a suspicious status is still returned after three repeated queries, it is marked as failed.

[0103] When the query service encounters a rate-limiting exception, the retry sleep time is obtained through parameter configuration, and the service retryes after sleep to avoid peak traffic. The returned rate-limiting exception is then packaged and returned as the result. If rate-limiting is still returned after 3 retries, the service is marked as failed.

[0104] Furthermore, this embodiment employs an anti-duplicate mechanism, identifying the anti-duplicate service by querying the service suspicious account retry configuration table. This type of service is not allowed to be called repeatedly, as repeated calls may lead to incorrect data states. The suspicious account confirmation service needs to be invoked according to the configured suspicious account handling Handler class.

[0105] also Figure 3The system also includes a parameter configuration module, which extracts and integrates frequently changing and flexibly controllable elements during processing. For handling suspicious services, it allows setting the name of the idempotent service, the name of the suspicious service to be retried, the maximum number of service retries, the service error code, the service timeout, and the service rate-limiting sleep time. For program control, it allows setting parameters for enabling the idempotent service retry aspect and the suspicious service retry confirmation aspect. Through the parameter configuration module, the program can flexibly control the handling of various service types and complex situations, significantly improving the flexibility and versatility of the method, increasing program reusability, and reducing program development costs.

[0106] As described above, compared to existing methods, this embodiment implements a general batch automatic retry mechanism for suspicious cases. This implementation can be embedded in existing code and can be quickly deployed without modifying business code. It automatically resubmits or confirms suspicious statuses of called services, solving the problems of transaction timeouts and non-final states, reducing manual intervention in handling suspicious results, and improving the success rate of batch processing. The parameter configuration module greatly improves the program's flexibility and can flexibly support various scenarios by configuring parameters such as services and error codes, reducing maintenance and modification costs. In short, this embodiment implements a batch automatic retry mechanism for suspicious cases, automating the handling of suspicious results generated during service calls, avoiding program interruptions while ensuring that clear and reliable results are obtained when calling services, improving the success rate of service calls, and further optimizing system stability and user experience.

[0107] This application also provides a processing apparatus for service calls. It should be noted that the processing apparatus for service calls in this application can be used to execute the processing method for service calls provided in this application. The processing apparatus for service calls provided in this application will be described below.

[0108] According to an embodiment of this application, an apparatus for implementing the above-described processing method for service invocation is also provided. Figure 4 This is a schematic diagram of an optional processing apparatus for service invocation according to an embodiment of this application, such as... Figure 4As shown, the device includes: a first detection unit 401, used to detect whether the target service has an idempotent property, wherein the idempotent property is used to characterize that the number of calls to the target service does not affect the resource status on the server; a first processing unit 402, used to perform S call processing on the target service when the target service is detected to have an idempotent property and the call result of the target service is suspicious, and to mark the call status of the target service according to the processing result of the S call processing, wherein S is an integer greater than 1 and less than or equal to a preset number, the processing result is call success or call failure, and the suspicious status is a status other than call success or call failure; a first determination unit 403, used to determine whether the target service is a target abnormal service according to a first configuration table when the target service is detected to not have an idempotent property and the call result of the target service is suspicious, wherein the first configuration table is used to manage update-type service information that needs to be queried for call status; and a second processing unit 404, used to call a query service to query the target service when the target service is detected to be a target abnormal service, obtain the query result, and mark the call status of the target service according to the query result, wherein the query service is used to query the call information of the target service.

[0109] Optionally, the processing device for service calls further includes: a first acquisition unit, a second acquisition unit, and a second determination unit. The first acquisition unit is used to acquire the call result of the target service; the second acquisition unit is used to acquire a target value and an error code from the call result, wherein the target value represents the call status of the target service, and the error code represents the error cause; the second determination unit is used to determine that the call result of the target service is in a suspicious state when the target value and / or error code meet any of the following conditions: a first condition, wherein the first condition represents a target value of 2; a second condition, wherein the second condition represents a target value that is empty; a third condition, wherein the third condition represents a target value of 1 and the error code type is either a first type or a second type, wherein the first type represents a target service that requires call status confirmation, and the second type represents a target service that requires multiple re-call processing.

[0110] Optionally, the second processing unit includes: a first acquisition subunit, a second acquisition subunit, and a first marking subunit. The first acquisition subunit is used to acquire a target class from a first configuration table and call a query service based on the target class, wherein the target class is used to load components from the first configuration table for querying and confirming the call status of the target service. The second acquisition subunit is used to acquire log information of the target service during the call process through the query service. The first marking subunit is used to query the call status information of the target service from the log information, obtain the query result, and mark the call status of the target service based on the query result.

[0111] Optionally, the first marking subunit includes: a first marking module, a first query module, a second marking module, and a third marking module. The first marking module is used to mark the call status of the target service based on the query result when a query result indicates a successful or failed call. The first query module is used to perform R query operations on the log information to obtain query results when a query result indicates a suspicious status, where R is an integer greater than 1 and less than or equal to a first preset number of queries. The second marking module is used to mark the call status of the target service as a failed call when all R query results indicate a suspicious status. The third marking module is used to mark the call status of the target service based on the query result when any one of the R query operations indicates a successful or failed call.

[0112] Optionally, the processing device for service calls further includes: a third acquisition unit, a third processing unit, and a first marking unit. The third acquisition unit is used to acquire a sleep time from a target configuration table when it detects that the call to the target service is in a rate-limited state, wherein the target configuration table is used to manage parameter configurations during the service call process; the third processing unit is used to perform T call processing on the target service after the time for stopping the call to the target service exceeds the sleep time, wherein T is an integer greater than 1; the first marking unit is used to mark the call status of the target service as a call failure if the call to the target service is in a rate-limited state when it detects that T is greater than or equal to a second preset number of calls.

[0113] Optionally, the processing device for service invocation further includes a third determining unit and a fourth processing unit. The third determining unit is used to determine the processing logic for the target service based on a third configuration if the configuration information of the target service is not found in the first configuration table. The third configuration is used to uniformly manage and distribute configuration information, and the processing logic is used to indicate whether to perform multiple invocations of the target service. The fourth processing unit is used to process the target service according to the processing logic.

[0114] Optionally, the processing device for service calls further includes: a second detection unit, a fourth determination unit, and a fifth determination unit. The second detection unit is used to detect the service type of the target service, wherein the service type is a query service or an update service. The fourth determination unit is used to determine the error code type as a first type if an error code exists in the first configuration table when the target service type is detected as an update service. The fifth determination unit is used to determine the error code type as a second type if an error code exists in the second configuration table when the target service type is detected as a query service, wherein the second configuration table manages the error code list corresponding to query services, and all error codes in the error code list are of the second type.

[0115] According to another aspect of this application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the above-described processing method for service invocation.

[0116] According to another aspect of this application, an electronic device is also provided, including one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the above-described processing method for service invocation.

[0117] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps of the above-described processing method for service invocation.

[0118] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0119] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0121] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0123] If the integrated unit is implemented as 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 this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0124] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing service calls, characterized in that, include: Detect whether the target service has idempotent properties, wherein the idempotent properties are used to characterize that the number of times the target service is called does not affect the resource status on the server; When it is detected that the target service has the idempotent property and the call result of the target service is suspicious, the target service is processed by S calls, and the call status of the target service is marked according to the processing result of the S calls, where S is an integer greater than 1 and less than or equal to a preset number of times, the processing result is a successful call or a failed call, and the suspicious status is any status other than a successful call or a failed call. When it is detected that the target service does not have the idempotent property and the call result of the target service is in a suspicious state, the first configuration table is used to determine whether the target service is a target abnormal service. The first configuration table is used to manage the update service information that needs to be queried for call status. When the target service is detected as the target abnormal service, a query service is invoked to query the target service, obtain the query results, and mark the call status of the target service according to the query results. The query service is used to query the call information of the target service.

2. The method for processing service calls according to claim 1, characterized in that, Before detecting whether the target service has idempotent properties, the method further includes: Obtain the call result of the target service; Obtain the target value and error code from the call result, wherein the target value is used to characterize the call status of the target service, and the error code is used to characterize the error reason; When the target value and / or the error code meet any of the following conditions, the call result of the target service is determined to be in the suspicious state: The first condition is used to characterize the target value as 2; The second condition is used to characterize that the target value is empty; The third condition is used to characterize that the target value is 1 and the error code is of type 1 or type 2. The first type is used to characterize that the target service needs to be confirmed in the call status, and the second type is used to characterize that the target service needs to be re-called multiple times.

3. The service invocation processing method according to claim 1, characterized in that, The query service is invoked to query the target service, the query results are obtained, and the invocation status of the target service is marked according to the query results, including: The target class is obtained from the first configuration table, and the query service is called based on the target class, wherein the target class is used to load components from the first configuration table for querying and confirming the call status of the target service; The query service is used to obtain the log information of the target service during the invocation process; The call status information of the target service is queried from the log information to obtain the query result, and the call status of the target service is marked according to the query result.

4. The method for processing service calls according to claim 3, characterized in that, The call status information of the target service is queried from the log information to obtain the query result, and the call status of the target service is marked according to the query result, including: When the query result indicates that the call was successful or failed, the call status of the target service is marked according to the query result. When the query result is detected to be the suspicious state, the log information is queried R times to obtain the query result, where R is an integer greater than 1 and less than or equal to a first preset number of times; When it is detected that the query results corresponding to the R query processes are all in the suspicious state, the call status of the target service is marked as the call failed; When it is detected that the query result corresponding to any one of the R query processes is either a successful call or a failed call, the call status of the target service is marked according to the query result.

5. The method for processing service calls according to claim 1, characterized in that, The method further includes: When it is detected that the call to the target service is in a rate-limited state, the sleep time is obtained from the target configuration table, wherein the target configuration table is used to manage the parameter configuration during the service call process; After the time for which the target service is stopped is greater than the sleep time, the target service is called T times, where T is an integer greater than 1. When T is detected to be greater than or equal to the second preset number of times, if the call to the target service is in a rate-limited state, the call status of the target service is marked as the call failed.

6. The method for processing service calls according to claim 1, characterized in that, After determining whether the target service is a target abnormal service based on the first configuration table, the method further includes: If the configuration information of the target service is not found in the first configuration table, the processing logic of the target service is determined according to the third configuration, wherein the third configuration is used to uniformly manage and distribute configuration information, and the processing logic is used to characterize whether the target service is called multiple times. The target service is processed according to the processing logic.

7. The method for processing service calls according to claim 2, characterized in that, The method further includes: Detect the service type of the target service, wherein the service type is a query service or an update service; When the service type of the target service is detected to be the update service, if the error code exists in the first configuration table, then the type of the error code is determined to be the first type. When the service type of the target service is detected to be the query service, if the error code exists in the second configuration table, the type of the error code is determined to be the second type. The second configuration table is used to manage the error code list corresponding to the query service, and the error codes in the error code list are all of the second type.

8. A processing apparatus for service invocation, characterized in that, include: The first detection unit is used to detect whether the target service has an idempotent property, wherein the idempotent property is used to characterize that the number of times the target service is called does not affect the resource status on the server; The first processing unit is configured to perform S call processing on the target service when it is detected that the target service has the idempotent property and the call result of the target service is suspicious, and to mark the call status of the target service according to the processing result of the S call processing, wherein S is an integer greater than 1 and less than or equal to a preset number of times, the processing result is a call success or a call failure, and the suspicious status is a status other than the call success and the call failure. The first determining unit is used to determine whether the target service is a target abnormal service according to the first configuration table when it is detected that the target service does not have the idempotent attribute and the call result of the target service is in a suspicious state. The first configuration table is used to manage update service information that needs to be queried for call status. The second processing unit is used to call a query service to query the target service when the target service is detected to be an abnormal target service, obtain query results, and mark the call status of the target service according to the query results, wherein the query service is used to query the call information of the target service.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device in which the computer-readable storage medium is located performs the processing method for service invocation as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the processing method for a service call as described in any one of claims 1 to 7.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the processing method for service invocation as described in any one of claims 1 to 7.

Images