Distributed system interface intelligent compensation method and device
By accurately identifying fault modes and implementing differentiated compensation strategies, the problems of resource waste and reliability in interface calls in existing technologies are solved, achieving high efficiency and reliability of distributed system interface calls, and applicable to HTTP/HTTPS interface calls.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-03
- Publication Date
- 2026-04-07
AI Technical Summary
Existing technologies suffer from coarse fault mode identification, homogenized compensation strategies, and rigid configurations, failing to meet the needs of precise and differentiated interface calls, leading to resource waste and reliability issues.
Through configurable adaptation, fault modes are accurately identified and differentiated compensation strategies are executed. Combined with a manual compensation fallback mechanism, this enables accurate identification and differentiated compensation of fault modes, adapting to the characteristics of different fault modes.
It improves the reliability and fault tolerance of distributed system interface calls, reduces resource waste, is suitable for various HTTP/HTTPS interface call scenarios, and can be quickly integrated without major modifications to existing business systems.
Smart Images
Figure CN121807615A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, specifically providing a method and apparatus for intelligent compensation of distributed system interfaces. Background Technology
[0002] With the widespread application of distributed architecture in the software industry, third-party API calls have become a core support for business collaboration. However, various failures encountered during API calls (such as call failures due to network fluctuations, service downtime, configuration errors, and business rule conflicts) seriously affect system reliability. Currently, mainstream API compensation solutions in the industry are mainly based on retry mechanisms and circuit breaker strategies. Representative technologies include the Spring Retry framework, the Resilience4j circuit breaker component, and the FailOver / FailBack fault tolerance pattern. However, these technologies have the following key shortcomings when facing clearly categorized failure modes, failing to meet the needs for precise and differentiated compensation:
[0003] 1. The fault mode identification is crude and cannot distinguish the core fault types.
[0004] Current technologies lack specific classification logic for determining API call failures, relying solely on a single exception type or status code for preliminary judgment, and cannot accurately identify the four core failure modes:
[0005] (1) Conflating “network fluctuations” with “system crashes” and applying the same retry strategy to both leads to frequent invalid retries and wasted resources when the system crashes, while timeout scenarios may reduce the recovery success rate due to unreasonable retry intervals.
[0006] (2) Failed to distinguish “interface configuration error” (such as configuration status codes such as 404, 400, etc.) from other recoverable faults, mistakenly included configuration errors in the retry scope, resulting in a large number of invalid requests;
[0007] (3) The identification of “business rule verification anomalies” (such as illegal input parameters or business status conflicts) relies on simple keyword matching. A standardized business anomaly judgment mechanism has not been established, which is easily confused with recoverable faults, leading to repeated execution of non-idempotent operations and causing data consistency problems.
[0008] 2. Compensation strategies are homogenized, lacking fault-oriented differentiated design.
[0009] Existing technologies generally adopt a "one-size-fits-all" compensation logic, without designing adaptation strategies for the characteristics of different failure modes.
[0010] (1) For temporary recoverable faults such as "call timeout", there is no precise adaptation mechanism for retrying at fixed intervals. Some solutions have retry intervals that are too long or too short, which affects recovery efficiency.
[0011] (2) When faced with faults such as "system crash" that require delayed recovery, there is a lack of intelligent strategies such as caching queues to temporarily store requests and delaying retries. Instead, immediate repeated calls are still executed, which not only fails to recover successfully but also occupies interface resources.
[0012] (3) For unrecoverable faults such as “interface configuration error” and “business rule verification error”, no clear compensation and termination mechanism is set up, and meaningless retry operations are still performed, increasing interface load and log redundancy.
[0013] 3. Rigid strategy configuration, lacking the ability to adapt to different scenarios.
[0014] Existing technologies often use globally fixed or hard-coded compensation parameters (such as the number of retries, intervals, and triggering conditions), which cannot adapt to the characteristics of different fault modes.
[0015] (1) The optimal fixed interval retry parameter was not configured for "call timeout", and a reasonable cache queue delay time was not set for "system crash". The parameter configuration lacks scenario specificity;
[0016] (2) No dynamic binding mechanism between fault modes and compensation strategies has been established, and the compensation logic cannot be automatically switched according to the fault type (such as timeout triggering immediate retry, and crash triggering queue caching).
[0017] (3) The lack of configuration verification mechanism makes it impossible to identify errors in core configurations such as URLs in advance. Exception handling is only triggered after a call fails, which prolongs the fault response cycle.
[0018] How to address the core shortcomings of existing technologies in areas such as accurate fault mode identification, differentiated compensation strategy design, and configuration adaptability is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0019] This invention addresses the shortcomings of the prior art by providing a highly practical intelligent compensation method for distributed system interfaces.
[0020] A further technical objective of this invention is to provide a reasonably designed, safe, and applicable intelligent compensation device for distributed system interfaces.
[0021] The technical solution adopted by this invention to solve its technical problem is:
[0022] A method for intelligent compensation of interfaces in a distributed system includes the following steps:
[0023] S1. The business side configures the call parameters through the compensation call interface configuration page, and after receiving the configuration parameters, it persists the data according to the interface configuration code.
[0024] S2. The business system initiates a request through the proxy interface, passing in the interface configuration code value. After receiving the business system's call request, the proxy system obtains the interface configuration parameters based on the code and then calls the configured interface URL.
[0025] S3. Receive the return result of the API call, and enter the fault mode detection and compensation based on the return result;
[0026] S4. Based on the fault modes classified in step S3, execute corresponding compensation strategies for different modes.
[0027] S5. If the compensation strategy has been executed but the compensation call still fails, then manual intervention will be performed.
[0028] Furthermore, in step S1, the calling parameters include the interface configuration code, the calling URL, the number of compensation calls, the compensation call time interval, the correct output parameter format of the calling interface, and the interface calling method.
[0029] Furthermore, in step S3, if the call is successful directly, i.e., when the response status code is 200, the output parameters returned by the interface are obtained and matched with the configured correct output parameter format. If the match is successful, it means that the interface call was successful; if the match fails, it means that the call does not meet expectations and is judged as a business exception.
[0030] If the call fails, i.e., the response status code is not 200, then the fault type is determined.
[0031] Furthermore, when determining the type of fault, the following factors are considered:
[0032] (1) For interface configuration errors, before calling, validate the URL format using regular expressions and catch MalformedURLException; or after calling, return a 404, 400, or 414 status code. If any of the above conditions are met, it is determined to be an interface configuration error.
[0033] (2) For “system crash”, use three steps, “configuration parsing + Ping detection + return”, to verify and achieve accurate judgment;
[0034] (3) For “network jitter”, if any of the exceptions SocketException, HttpTimeoutException or RpcTimeoutException are caught and the Ping interface URL is successfully detected, it can be determined as temporary network jitter.
[0035] Furthermore, the "configuration parsing + Ping detection + call verification" specifically includes:
[0036] a) Obtain the target interface URL or "service name + interface path" from the configuration;
[0037] b) Next, URL parsing and Ping testing are performed. The domain name in the URL is parsed, and the domain name connectivity is tested using the Java Ping utility class. Ping testing is performed on the provided domain name. If the Ping test for all domain names fails, it is determined that the system calling the interface has crashed.
[0038] c) Finally, call verification is performed. Multiple consecutive calls are initiated based on the URL or "service name + interface path". If "connection refused" or gateway 503 is triggered in all cases, and URL configuration errors are ruled out, it is determined that the system calling the interface is down.
[0039] Furthermore, step S4 includes:
[0040] (1) When the fault mode is determined to be a URL spelling error or a business exception, no compensation call is made and the log is recorded directly;
[0041] (2) When the fault mode is determined to be network jitter, according to the configured compensation execution strategy, if the interface call is retried at a fixed time interval, the scheduled task will initiate a retry at the configured interval. If the retry count is exhausted and the failure still occurs, the failure result will be returned.
[0042] (3) When the fault mode is determined to be system crash, the “cached queue delayed call” strategy is triggered, the request record, request time and retry count are stored in the Redis queue, the timer is started to scan the Redis queue according to the strategy of executing once a certain time, and the request is retrieved and called again after the set time is reached. If successful, the request is returned as successful.
[0043] If it fails, repeat step S4 to execute the compensation strategy until the configuration request count threshold is reached, and then terminate.
[0044] Finally, all compensation request calls are recorded in the log table.
[0045] Furthermore, in step S5, if the compensation call still fails after the compensation strategy has been executed, the business party initiates a manual retry through the interface based on the request ID recorded in the log, thus realizing manual intervention as a fallback after the automatic execution of the compensation strategy fails.
[0046] A distributed system interface intelligent compensation device includes: at least one memory and at least one processor;
[0047] The at least one memory is used to store a machine-readable program;
[0048] The at least one processor is used to call the machine-readable program to execute a distributed system interface intelligent compensation method.
[0049] Compared with the prior art, the intelligent compensation method and apparatus for distributed system interfaces of the present invention have the following outstanding advantages:
[0050] This invention improves system compatibility through configurable adaptation, reduces false positive rates through accurate fault identification, minimizes resource waste through differentiated strategies, and combines a manual compensation fallback mechanism to comprehensively enhance the reliability and fault tolerance of distributed system interface calls. It is applicable to various HTTP / HTTPS interface call scenarios and can be quickly integrated without significant modifications to existing business systems. Attached Figure Description
[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0052] Figure 1 This is a flowchart illustrating a distributed system interface intelligent compensation method.
[0053] Figure 2 This is a flowchart illustrating the process of entering fault mode detection and compensation based on the returned result in a distributed system interface intelligent compensation method.
[0054] Figure 3 This is a flowchart illustrating the execution of corresponding compensation strategies for different modes in a distributed system interface intelligent compensation method. Detailed Implementation
[0055] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to specific embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0056] The following is a preferred embodiment:
[0057] like Figure 1 As shown in this embodiment, a distributed system interface intelligent compensation method has the following steps:
[0058] S1. The business side configures the call parameters through the compensation call interface configuration page;
[0059] The service provider configures the call parameters through the compensation call interface configuration page provided by this device;
[0060] The core configuration parameters include: interface configuration code (globally unique identifier used to associate configuration information), call URL (target interface access address, or a combination of "service name + interface path"), compensation call count (maximum retry threshold, such as 3 times or 5 times), compensation call interval (retry interval, such as 1 second or 3 seconds), correct output parameter format of the call interface (preset valid response data format, such as JSON structure {"code":200,"data":{}}), and interface call method (ESB, CSB, or regular HTTP call method).
[0061] After receiving the configuration parameters, the configuration information is persistently stored according to the interface configuration code (e.g., stored in a MySQL database), and subsequent querying and modification of configuration information by code is supported.
[0062] S2. The business system initiates a request through the proxy interface, and initiates an interface call request through the exposed proxy interface. The request carries the interface configuration code value configured in step S1. After the compensation center obtains the business request, it queries the interface configuration management according to the passed code to obtain the corresponding complete interface configuration parameters (including call URL, call method, etc.).
[0063] Finally, the compensation center assembles the request according to the configured calling method, forwards the request to the configured target interface URL, and synchronously listens for the interface response results.
[0064] S3. Receive the return result of the API call, and enter the fault mode detection and compensation based on the return result;
[0065] like Figure 2 As shown, if the call succeeds directly, i.e., when the response status code is 200, the output parameter data of the interface return result is extracted first; the returned output parameter is matched with the "correct returned output parameter format" configured in step S1 using equal matching, the interface returned output parameter is converted into a Map structure, and then the output parameter result is traversed in a hierarchical order and compared with the "correct returned output parameter format" configured in step S1.
[0066] If the structure is completely consistent, the core fields exist and meet expectations, then the interface call is considered successful, the result is recorded in the log and returned to the business system, and this process is terminated.
[0067] If the structures are not completely consistent, the matching will fail, the business will be judged as abnormal, no compensation will be performed, and the process will jump to the logging stage.
[0068] If the call fails, i.e., the response status code is not 200, the fault type shall be determined according to the following rules and steps:
[0069] (1) For interface configuration errors, the call URL format is validated by regular expression. If the format is invalid, MalformedURLException is caught; or the target interface returns a 404 (path not found), 400 (request format error), or 414 (URL too long) status code; if any of the above conditions are met, it is determined that the interface configuration is incorrect.
[0070] (2) For “system crash”, accurate judgment is achieved through three steps: “configuration parsing + Ping detection + call verification”.
[0071] First, configure DNS resolution. Retrieve the URL of the target API from the configuration management, and then parse the domain name (e.g., api.user.com) from the URL.
[0072] Next, the connectivity of the domain name is checked using Java TCP Ping utility classes (such as Socket connection detection); when all ping tests for the domain name / IP fail (no response or timeout);
[0073] Finally, in the next verification stage, three consecutive calls were made based on the configured URL or "service name + interface path". All of them triggered a ConnectException (connection refused) or the gateway returned a 503 (service unavailable) status code. After ruling out interface configuration errors, it was finally determined that the system calling the interface was down.
[0074] (3) For “network jitter”, after excluding interface configuration errors and system crashes, capture any of the exceptions SocketException (Socket read / write interruption), HttpTimeoutException (HTTP timeout), and RpcTimeoutException (RPC timeout); at the same time, the URL domain Ping test result is successful (proving that the service is reachable and it is only a temporary network fluctuation); if the above conditions are met, it is determined to be network jitter.
[0075] S4. Based on the fault modes classified in step S3, execute corresponding compensation strategies for different modes.
[0076] like Figure 3 As shown:
[0077] (1) When the fault mode is “interface configuration error” or “business exception”, no compensation call operation is performed; the fault details (fault type, request parameters, timestamp, code, etc.) are recorded directly through the log and storage module, and a failure response is returned to the business system.
[0078] (2) The fault mode is "network jitter": the fixed interval retry strategy is executed according to the "compensation call count" and "compensation call time interval" configured in step S1; the compensation execution creates a scheduled task through ScheduledExecutorService and initiates interface retries at the configured time interval;
[0079] If the call succeeds during the retry process, the result is returned to the business system; if the number of retries is exhausted and the call still fails, the compensation process is terminated and a failure result is returned.
[0080] (3) When the fault mode is "system crash": the "cached queue delayed call" strategy is triggered, and the request record, including the request parameters, interface configuration code, request time, and current retry count, is stored in the Redis queue to ensure that the data is not lost.
[0081] Start a timer to scan the Redis queue every 10 seconds. For requests in the queue that have reached the set delay time, retrieve them and re-initiate the call.
[0082] Successful call: Returns a successful request result to the business system and removes the request from the Redis queue;
[0083] Call failure: Repeat the compensation strategy execution logic of this step until the “compensation call count” threshold configured in step S1 is reached. Once the threshold is reached, the compensation is terminated and a failure result is returned.
[0084] S5. If the compensation strategy has been executed but the compensation call still fails, then manual intervention will be performed.
[0085] Manual compensation is provided as a fallback. If the compensation strategy has been executed (including retries at fixed intervals reaching the maximum number in network jitter scenarios and cache queue delay retries reaching the threshold in system crash scenarios), but the compensation call still fails due to the recovery time of the target interface system or program exceeding the compensation period or other force majeure factors, the business can query the unique request ID of the faulty request through the log and storage module. Based on this request ID, a manual retry is initiated through the exposed manual compensation interface. The manual retry process is consistent with the automatic compensation process, realizing manual intervention as a fallback after the automatic execution of the compensation strategy fails, ensuring the reachability of requests in special scenarios.
[0086] Based on the above method, a distributed system interface intelligent compensation device in this embodiment includes: at least one memory and at least one processor;
[0087] The at least one memory is used to store a machine-readable program;
[0088] The at least one processor is used to call the machine-readable program to execute a distributed system interface intelligent compensation method.
[0089] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.
[0090] Memory is used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory devices, or other volatile solid-state storage devices.
[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for intelligent compensation of interfaces in a distributed system, characterized in that, It has the following steps: S1. The business side configures the call parameters through the compensation call interface configuration page, and after receiving the configuration parameters, it persists the data according to the interface configuration code. S2. The business system initiates a request through the proxy interface, passing in the interface configuration code value. After receiving the business system's call request, the proxy system obtains the interface configuration parameters based on the code and then calls the configured interface URL. S3. Receive the return result of the API call, and enter the fault mode detection and compensation based on the return result; S4. Based on the fault modes classified in step S3, execute corresponding compensation strategies for different modes. S5. If the compensation strategy has been executed but the compensation call still fails, then manual intervention will be performed.
2. The intelligent compensation method for distributed system interfaces according to claim 1, characterized in that, In step S1, the calling parameters include the interface configuration code, the calling URL, the number of compensation calls, the compensation call time interval, the correct output parameter format of the calling interface, and the interface calling method.
3. The intelligent compensation method for distributed system interfaces according to claim 2, characterized in that, In step S3, if the call is successful directly, i.e., the response status code is 200, the output parameters returned by the interface are obtained and matched with the correct output parameter format configured. If the match is successful, it means that the interface call was successful. If the match fails, it means that the call does not meet expectations and is judged as a business exception. If the call fails, i.e., the response status code is not 200, then the fault type is determined.
4. The intelligent compensation method for distributed system interfaces according to claim 3, characterized in that, When determining the fault type, the following should be included: (1) For interface configuration errors, before calling, validate the URL format using regular expressions and catch MalformedURLException; or after calling, return a 404, 400, or 414 status code. If any of the above conditions are met, it is determined to be an interface configuration error. (2) For "system crash", the three steps of "configuration parsing + Ping detection + return" are used to verify and achieve accurate judgment; (3) For "network jitter", if any of the exceptions SocketException, HttpTimeoutException or RpcTimeoutException are caught and the Ping interface URL is successfully detected, it can be determined as temporary network jitter.
5. The intelligent compensation method for distributed system interfaces according to claim 4, characterized in that, The "configuration parsing + Ping detection + call verification" specifically includes: a) Obtain the target interface URL or "service name + interface path" from the configuration; b) Next, URL parsing and Ping testing are performed. The domain name in the URL is parsed, and the domain name connectivity is tested using the Java Ping utility class. Ping testing is performed on the provided domain name. If the Ping test for all domain names fails, it is determined that the system calling the interface has crashed. c) Finally, perform call verification. If multiple consecutive calls are made based on the URL or "service name + interface path", and all of them trigger "connection refused" or gateway 503, and URL configuration errors are ruled out, it is determined that the system calling the interface is down.
6. The intelligent compensation method for distributed system interfaces according to claim 5, characterized in that, Step S4 includes: (1) When the fault mode is determined to be a URL spelling error or a business exception, no compensation call will be made and the log will be recorded directly. (2) When the fault mode is determined to be network jitter, the configured compensation execution strategy is followed. If the interface call is retried at a fixed time interval, the scheduled task will initiate a retry at the configured interval. If the retry count is exhausted and the failure still occurs, the failure result will be returned. (3) When the fault mode is determined to be system crash, the "cached queue delayed call" strategy is triggered, the request record, request time and retry count are stored in the Redis queue, the timer is started to scan the Redis queue according to the strategy of executing once a certain time, and the request is retrieved and called again after the set time is reached. If successful, the request is returned as successful. If it fails, repeat step S4 to execute the compensation strategy until the configuration request count threshold is reached, and then terminate. Finally, all compensation request calls are recorded in the log table.
7. The intelligent compensation method for distributed system interfaces according to claim 6, characterized in that, In step S5, if the compensation call still fails after the compensation strategy has been executed, the business party initiates a manual retry through the interface based on the request ID recorded in the log, thus realizing manual intervention as a fallback after the automatic execution of the compensation strategy fails.
8. A distributed system interface intelligent compensation device, characterized in that, include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to invoke the machine-readable program to perform the method according to any one of claims 1 to 7.