Service calling compensation method, device and equipment and readable storage medium
By using compensation annotations and timing schedulers in the microservice architecture for service call compensation, the problem of low reliability of inter-service call exception handling in the microservice architecture is solved, and efficient exception handling with zero intrusion is achieved.
Patent Information
- Application Number
- CN202411880177.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-19
- Publication Date
- 2025-04-15
AI Technical Summary
In the microservice architecture, calls between services are frequent and complex, and exception handling has low reliability, resulting in increased complexity of dirty data and code.
By marking compensation annotations in the upstream service, the call compensation strategy of the downstream service is determined, and when the downstream service is executed abnormally, the timed scheduler uses the timer to compensate the service call based on the annotation to achieve zero service intrusion.
It improves the reliability of service calls, reduces the complexity of exception processing and the generation of dirty data, and realizes zero-invasion exception handling for business.
Smart Images
Figure CN119829307A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of microservice technology, and in particular to a service call compensation method, apparatus, device and readable storage medium. Background Art
[0002] Microservice architecture is a software design pattern based on service splitting, which splits the original complex monolithic application into a set of smaller and more independent service units. Each service unit has a clearly defined interface and function, and can be independently developed, tested and deployed.
[0003] In a microservice architecture, calls between services are frequent and complex, exceptions become more common, and exception handling becomes a key challenge. Traditional exception handling methods usually directly interrupt the program, return errors to users, or rely on databases and message queues for compensation, which leads to problems such as dirty data and increased code complexity, reducing the reliability of service calls.
[0004] Therefore, how to improve the reliability of service calls is a problem that technical personnel in this field need to solve urgently. Summary of the invention
[0005] Based on the above problems, the present application provides a service call compensation method, device, equipment and readable storage medium, which identifies the call compensation of the downstream service required for this call in the form of annotations in the upstream service, and performs timely service call compensation according to the annotations when the downstream service executes abnormally, thereby achieving zero business intrusion and improving the reliability of service calls.
[0006] In a first aspect, an embodiment of the present application provides a service call compensation method, including:
[0007] Receive business requests;
[0008] Determine an upstream service and a downstream service based on the business request;
[0009] Marking a compensation annotation in the upstream service based on the business request, wherein the compensation annotation is used to provide a basis for calling compensation of the downstream service;
[0010] When the downstream service is executed abnormally, service call compensation is performed based on the timing scheduler and the compensation annotation.
[0011] Optionally, the compensation annotation includes: an exception handling strategy;
[0012] The exception handling strategy includes a storage strategy, a retry strategy and a compensation stop condition.
[0013] Optionally, the performing service call compensation based on the timing scheduler and the compensation annotation includes:
[0014] The call information corresponding to the execution exception is stored hierarchically according to the storage strategy to form a call information stack;
[0015] Based on the timing scheduler, service call compensation is performed according to the call information stack and the retry strategy.
[0016] Optionally, the method further includes:
[0017] If the service call compensation reaches the compensation stop condition and the downstream service still has the execution exception, stop the service call compensation;
[0018] The execution exception is pushed to the integrated exception dashboard.
[0019] Optionally, the compensation stop condition includes: a preset processing time and a preset number of retries;
[0020] If the service call compensation reaches the compensation stop condition and the downstream service still has the execution exception, stopping the service call compensation includes:
[0021] If the service call compensation reaches the preset processing time or reaches the preset number of retries within the preset time, and the downstream service still has the execution exception, the service call compensation is stopped.
[0022] Optionally, the method further includes:
[0023] The execution exception is displayed to the user through the integrated exception dashboard, and function options are provided for the user to select; the function options include general processing options and customized processing options; the general processing options include archiving, retrying, and modifying and retrying;
[0024] The execution exception is processed based on the user's selection.
[0025] Optionally, when the downstream service is executed abnormally, before performing service call compensation based on the timing scheduler and the compensation annotation, the method further includes:
[0026] Based on aspect programming, capture the execution exceptions of the downstream service.
[0027] In a second aspect, an embodiment of the present application provides a service call compensation device, characterized in that it includes:
[0028] A receiving module, used for receiving a service request;
[0029] A determination module, used to determine an upstream service and a downstream service based on the business request;
[0030] A marking module, used for marking a compensation annotation in the upstream service based on the business request, wherein the compensation annotation is used to provide a basis for the call compensation of the downstream service;
[0031] The compensation module is used to perform service call compensation based on the compensation annotation based on the timing scheduler when the downstream service is executed abnormally.
[0032] In a third aspect, an embodiment of the present application provides a service call compensation device, characterized in that it includes:
[0033] Memory for storing computer programs;
[0034] A processor is used to implement the steps of the service call compensation method described above when executing the computer program.
[0035] In a fourth aspect, an embodiment of the present application provides a readable storage medium, characterized in that a computer program is stored on the readable storage medium, and when the computer program is executed by a processor, the steps of the service call compensation method as described above are implemented.
[0036] It can be seen from the above technical solutions that compared with the prior art, the present application has the following advantages:
[0037] This application first receives a business request. Then, based on the business request, the upstream service and the downstream service are determined, and the compensation annotation is marked in the upstream service based on the business request. Among them, the compensation annotation is used to provide a basis for the call compensation of the downstream service. Finally, when the downstream service execution is abnormal, based on the timing scheduler, the service call compensation is performed according to the compensation annotation. In this way, after determining the upstream and downstream services, the call compensation of the downstream service required for this call is marked in advance in the form of annotations in the upstream service, and timely service call compensation is performed according to the annotations when the downstream service execution is abnormal, achieving zero business intrusion and improving the reliability of service calls. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] Figure 1 A flowchart of a service call compensation method provided in an embodiment of the present application;
[0039] Figure 2 An overall flow chart of service call compensation provided in an embodiment of the present application;
[0040] Figure 3 A flowchart of a timing scheduler performing service scheduling compensation provided in an embodiment of the present application;
[0041] Figure 4 A schematic diagram of the structure of a service call compensation device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0042] As mentioned above, the existing exception handling methods have the problem of low reliability of service calls. Specifically, the existing exception handling methods mostly use the means of directly interrupting the program, returning errors to users, or relying on databases and message queues for compensation. This has many shortcomings, such as dirty data and increased code complexity, which impairs the user experience and reduces the reliability of service calls.
[0043] In order to solve the above problems, an embodiment of the present application provides a service call compensation method, comprising: first receiving a business request. Then determining the upstream service and the downstream service based on the business request, and marking the compensation annotation in the upstream service based on the business request. Among them, the compensation annotation is used to provide a basis for the call compensation of the downstream service. Finally, when the downstream service executes abnormally, based on the timing scheduler, the service call compensation is performed according to the compensation annotation.
[0044] In this way, after determining the upstream and downstream services, the call compensation of the downstream service required for this call is marked in the upstream service in advance in the form of annotations, and when the downstream service execution exception occurs, timely service call compensation is performed according to the annotations, achieving zero business intrusion and improving the reliability of service calls.
[0045] It should be noted that the service call compensation method, device, equipment and readable storage medium provided by the present application can be applied to the field of microservice technology. The above is only an example and does not limit the application field of the service call compensation method, device, equipment and readable storage medium provided by the present application.
[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0047] Figure 1 A flow chart of a service call compensation method provided in an embodiment of the present application. Figure 1 As shown, a service call compensation method provided by an embodiment of the present application may include:
[0048] S101: receiving a service request.
[0049] In actual applications, a user initiates a service request, and the service call compensation device receives the service request initiated by the user. For example, the service request may be an order service calling an inventory service to reserve inventory, or an order service calling a welfare service to issue points.
[0050] S102: Determine an upstream service and a downstream service based on the business request.
[0051] In actual applications, by parsing the business request, the corresponding call relationship can be obtained, and then the upstream service and downstream service corresponding to the business request can be determined. Continuing with the above example, when the business request is the order service calling the inventory service to reserve inventory, the order service is the upstream service and the inventory service is the downstream service; when the business request is the order service calling the welfare service to issue points, the order service is the upstream service and the welfare service is the downstream service.
[0052] S103: marking a compensation annotation in the upstream service based on the business request, where the compensation annotation is used to provide a basis for call compensation of the downstream service.
[0053] In actual applications, the corresponding upstream and downstream services can be determined by analyzing the business request, and then the upstream service can be marked with annotations to indicate that this call requires call compensation for the downstream service. It is understandable that different business requests generally correspond to different upstream and downstream services, and also to different compensation annotations. The compensation annotation clearly marks the compensation method and constraints when the call fails, thereby providing a basis for the call compensation of the downstream service.
[0054] In addition, since the forms of compensation annotations are not the same, the embodiments of the present application can illustrate a possible form of compensation annotations.
[0055] In one case, the compensation annotation includes: an exception handling strategy;
[0056] The exception handling strategy includes a storage strategy, a retry strategy and a compensation stop condition.
[0057] In actual applications, different businesses have different tolerances for the time limit for processing exceptions, so different exception handling strategies need to be formulated respectively. Then, after determining the upstream and downstream services corresponding to the business request, compensation annotations can be marked in the upstream service, that is, the corresponding exception handling strategy can be selected and marked in the upstream service. According to the different tolerances for the processing time limit, the exception handling strategy can generally be divided into H level, M level, and L level, among which H level is the highest level, M level is a higher level, and L level is a normal level. Different levels of exception handling strategies generally need to specify the corresponding storage strategy, retry strategy, and compensation stop conditions. For example, H level can specify that the medium used for calling information storage is local memory, the maximum processing time is 500ms, etc.; M level can specify that the medium used for calling information storage is distributed cache, the maximum processing time is 1s, the maximum number of retries is 10, and it is stipulated that the processing time and number are exceeded before entering the kanban board, etc.; L level can specify that the medium used for calling information storage is database, the maximum processing time is 1min, the maximum number of retries is 10, it is stipulated that the processing time and number are exceeded before entering the kanban board, and the retry algorithm, etc. The retry algorithm defaults to the backoff algorithm.
[0058] S104: When the downstream service is executed abnormally, based on the timing scheduler, service call compensation is performed according to the compensation annotation.
[0059] In actual applications, compensation annotations provide a basis for compensation of downstream service calls. When downstream services execute abnormally, the timer scheduler can perform service call compensation according to the compensation annotations marked in the upstream services.
[0060] In addition, since the methods for performing service call compensation are different, the embodiments of the present application can illustrate a possible method for performing service call compensation.
[0061] In one case, the timing scheduler is based on the compensation annotation to perform service call compensation, specifically including:
[0062] The call information corresponding to the execution exception is stored hierarchically according to the storage strategy to form a call information stack;
[0063] Based on the timing scheduler, service call compensation is performed according to the call information stack and the retry strategy.
[0064] In actual applications, different business requests generally correspond to different upstream services and downstream services, and different business requests generally require different corresponding compensation annotations. In combination with the above example, the scenario where the order service (upstream service) calls the inventory service (downstream service) to pre-occupy inventory has a low tolerance for the exception handling time limit, so the H-level exception handling strategy can be enabled. At this time, if an execution exception occurs in the process of the order service calling the inventory service, the call information of this time is stored in the local memory in the form of a stack to form a call information stack, and then the timer scheduler obtains the stack information in the call information stack, and the service call compensation is performed based on the retry strategy with the principle of giving priority to the latest exception; in addition, the scenario where the order service (upstream service) calls the welfare service (downstream service) to issue points has a high tolerance for the exception handling time limit, so the L-level exception handling strategy can be enabled. At this time, if an execution exception occurs in the process of the order service calling the welfare service, the call information of this time is stored in the database in the form of a stack, and a call information stack is formed, and then the timer scheduler obtains the stack information in the call information stack and retries according to the specified retry algorithm (retry strategy).
[0065] In addition, since the compensation results are not the same, the embodiment of the present application can illustrate a possible compensation result and a corresponding processing method.
[0066] In one embodiment, the method further comprises:
[0067] If the service call compensation reaches the compensation stop condition and the downstream service still has the execution exception, stop the service call compensation;
[0068] The execution exception is pushed to the integrated exception dashboard.
[0069] In actual applications, the exceptions that cannot be handled in the end will be stored in the integrated exception dashboard, and the compensation stop condition is the key to judging whether the current execution exception is an exception that cannot be handled in the end. Specifically, the embodiment of the present application sets different compensation stop conditions for exception handling strategies of different levels (such as H level, L level, M level), and defines whether or not to push the exceptions that cannot be handled in the end to the integrated exception dashboard for the exception handling strategies of different levels. In this way, when an exception occurs during execution of a business request of the corresponding level, and the service call compensation exceeds its corresponding compensation stop condition, the execution exception is determined to be an exception that cannot be handled in the end, and then the service call compensation for the execution exception is stopped. At the same time, if the exception handling strategy corresponding to the business request defines that the exception that cannot be handled in the end needs to be pushed to the integrated exception dashboard, then the execution exception also needs to be pushed to the integrated exception dashboard.
[0070] In summary, Figure 2The overall flow chart of a service call compensation provided by the embodiment of the present application. Figure 2 As shown, when a business request occurs, the upstream service uses compensation annotations to indicate that this call requires compensation for downstream service calls. Service compensation attempts to capture exceptions in downstream services in the form of aspect programming. If the exception is not captured, the process ends; if the exception is captured, the call information is stored hierarchically (storage media include local cache, distributed cache, and database) according to the hierarchical strategy defined on the compensation annotation and a call information stack is formed. At this time, the timer scheduler attempts to perform service call compensation based on the call information stack. If there are exceptions that cannot be handled in the end, they are pushed to the integrated exception dashboard. The integrated exception dashboard can display exceptions of different types (Class A, Class B, Class X) and their handling methods. The customer selects the appropriate handling method and executes it accordingly.
[0071] In addition, since the settings of the compensation stop condition are not the same, the embodiment of the present application can illustrate a possible setting of the compensation stop condition.
[0072] In one case, the compensation stop condition includes: a preset processing time and a preset number of retries;
[0073] If the service call compensation reaches the compensation stop condition and the downstream service still has the execution exception, stopping the service call compensation includes:
[0074] If the service call compensation reaches the preset processing time or reaches the preset number of retries within the preset time, and the downstream service still has the execution exception, the service call compensation is stopped.
[0075] In actual applications, the compensation stop conditions generally include a preset processing time and a preset number of retries. Different exception handling strategies are based on their corresponding processing time tolerance, and the preset processing time and preset number of retries are generally different. Continuing with the above example, the H level stipulates that the maximum processing time (preset processing time) is 500ms; while the L level can stipulate that the maximum processing time is 1min, the maximum number of retries (preset number of retries) is 10, and it is also stipulated that after exceeding the processing time and number, it will enter the integrated exception dashboard and stipulate the retry algorithm. Therefore, when the business request enables the H-level exception handling strategy, if the processing is unsuccessful within 500ms, it will return failure; when the business request enables the L-level exception handling strategy, it will retry according to the prescribed retry algorithm. If the processing is unsuccessful within 1min or more than 10 times, it will be pushed to the integrated exception dashboard. It is understandable that the parameters of the exception handling strategy can be set by the user within a reasonable range, such as changing 1min to 24h.
[0076] In summary, Figure 3A flow chart of a timing scheduler performing service scheduling compensation provided in an embodiment of the present application. Figure 3 As shown, if an exception is captured, the timer scheduler will request to handle the exception. Specifically, first, the call information is stored hierarchically according to the hierarchical strategy customized on the compensation annotation (the storage medium includes local cache, distributed cache and database) and a call information stack is formed. The call information stack stores information including call parameters, call methods, retry strategies and retried information. Retry the service call according to the captured exception information, and determine whether the maximum retry time has been reached. If so, determine whether to enter the exception board. If so, store the execution exception in the exception board. Otherwise, end directly. If the maximum retry time has not been reached, determine whether the maximum number of retries has been reached. If so, continue to determine whether to enter the exception board. If so, store the execution exception in the exception board. Otherwise, you can call the downstream service. If the call to the downstream service is successful, it ends; if it fails, it is re-stacked and waits for further retries.
[0077] In addition, since the functions of the integrated abnormality dashboard are not the same, the embodiment of the present application can illustrate one possible function.
[0078] In one embodiment, the method further comprises:
[0079] The execution exception is displayed to the user through the integrated exception dashboard, and function options are provided for the user to select; the function options include general processing options and customized processing options; the general processing options include archiving, retrying, and modifying and retrying;
[0080] The execution exception is processed based on the user's selection.
[0081] In actual applications, the exceptions that cannot be handled in the end will be stored in the integrated exception board. The integrated exception board provided in the embodiment of the present application integrates permissions according to functions and custom classifications, which can facilitate personnel with different permissions to view and handle related exceptions. In addition, the integrated exception board also provides functional options for users to select and handle exceptions. Specifically, the functional options include general processing options and customized processing options. The general processing options provide functions such as archiving, retrying, modifying and retrying. Customized processing options can be targeted according to different businesses and different exceptions. For example, when the after-sales service calls the refund service for refund processing, if the refund fails in the end, the execution exception will be stored in the integrated exception board for customer service to view, and the customer service will handle the refund accordingly. First, after the refund processing fails in the end, it is stored in the integrated exception board. The exception is the mall business and refund function. Therefore, the mall customer service has the authority to view the refund failure information and handle it in the end. The mall customer service can use general processing or custom processing for the exception according to the exception information. If the refund amount is incorrect, the customer service can modify it and submit it again for retry. If the third-party refund service does not support refunds due to time constraints, customer service can apply for customized processing and provide other compensation or transfers to users.
[0082] In addition, since the methods of monitoring abnormalities are different, the embodiments of the present application can illustrate a possible monitoring method.
[0083] In one case, when the downstream service is executed abnormally, before performing service call compensation according to the compensation annotation based on the timing scheduler, the method further includes:
[0084] Based on aspect programming, capture the execution exceptions of the downstream service.
[0085] In practical applications, aspect programming is a programming paradigm that improves the modularity of the code, and enhances the maintainability and scalability of the program by separating cross-cutting concerns, centralizing common functions, improving reusability, and improving development efficiency. The upstream service uses annotations to indicate that compensation for the downstream service call is required. This compensation, in the form of aspect programming, captures exceptions in the downstream service.
[0086] To summarize, the present application first receives a business request. Then, the upstream service and the downstream service are determined based on the business request, and the compensation annotation is marked in the upstream service based on the business request. Among them, the compensation annotation is used to provide a basis for the call compensation of the downstream service. Finally, when the downstream service execution is abnormal, based on the timing scheduler, the service call compensation is performed according to the compensation annotation. In this way, after determining the upstream and downstream services, the call compensation of the downstream service required for this call is marked in advance in the form of annotations in the upstream service, and timely service call compensation is performed according to the annotations when the downstream service execution is abnormal, achieving zero business intrusion and improving the reliability of service calls.
[0087] Figure 4 A schematic diagram of the structure of a service call compensation device provided in an embodiment of the present application. Figure 4 As shown, the service call compensation device 400 provided in the embodiment of the present application includes:
[0088] Receiving module 401, used for receiving a service request;
[0089] A determination module 402, configured to determine an upstream service and a downstream service based on the service request;
[0090] A marking module 403 is used to mark a compensation annotation in the upstream service based on the business request, and the compensation annotation is used to provide a basis for calling compensation of the downstream service;
[0091] The compensation module 404 is used to perform service call compensation based on the timing scheduler and the compensation annotation when the downstream service is executed abnormally.
[0092] As an implementation method, regarding how to set the compensation annotation, the above compensation annotation includes: an exception handling strategy;
[0093] The exception handling strategy includes a storage strategy, a retry strategy and a compensation stop condition.
[0094] As an implementation method, regarding how to perform service call compensation according to the compensation annotation, the compensation module 404 is specifically used to:
[0095] The call information corresponding to the execution exception is stored hierarchically according to the storage strategy to form a call information stack;
[0096] Based on the timing scheduler, service call compensation is performed according to the call information stack and the retry strategy.
[0097] As an implementation manner, regarding how to stop the service call compensation, the service call compensation device 400 further includes: a stop module;
[0098] A stopping module, configured to stop the service calling compensation if the service calling compensation reaches the compensation stopping condition and the downstream service still has the execution exception;
[0099] The execution exception is pushed to the integrated exception dashboard.
[0100] As an implementation manner, the above-mentioned compensation stop condition includes: a preset processing time and a preset number of retries.
[0101] As an implementation manner, regarding how to stop the service call compensation, the above-mentioned stop module is specifically used for:
[0102] If the service call compensation reaches the preset processing time or reaches the preset number of retries within the preset time, and the downstream service still has the execution exception, the service call compensation is stopped.
[0103] As an implementation method, with respect to how to interact with a user through an integrated abnormal dashboard, the service call compensation device 400 further includes: an interaction module;
[0104] An interactive module, used to display the execution exception to the user through the integrated exception dashboard and provide function options for the user to select; the function options include general processing options and customized processing options; the general processing options include archiving, retrying, and modifying and retrying;
[0105] The execution exception is processed based on the user's selection.
[0106] As an implementation method, in order to capture the execution exception of the downstream service, the service call compensation device 400 further includes: a capture module;
[0107] The capture module is used to capture execution exceptions existing in the downstream service based on aspect programming.
[0108] To summarize, the present application first receives a business request. Then, the upstream service and the downstream service are determined based on the business request, and the compensation annotation is marked in the upstream service based on the business request. Among them, the compensation annotation is used to provide a basis for the call compensation of the downstream service. Finally, when the downstream service execution is abnormal, based on the timing scheduler, the service call compensation is performed according to the compensation annotation. In this way, after determining the upstream and downstream services, the call compensation of the downstream service required for this call is marked in advance in the form of annotations in the upstream service, and timely service call compensation is performed according to the annotations when the downstream service execution is abnormal, achieving zero business intrusion and improving the reliability of service calls.
[0109] In addition, the present application also provides a pricing device for special sick body insurance, including:
[0110] Memory for storing computer programs;
[0111] A processor is used to implement the steps of the service call compensation method described above when executing the computer program.
[0112] In addition, the present application also provides a readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the service call compensation method as described above are implemented.
[0113] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A service call compensation method, characterized in that: The method comprises: Receive business requests; Determine an upstream service and a downstream service based on the business request; Marking a compensation annotation in the upstream service based on the business request, wherein the compensation annotation is used to provide a basis for calling compensation of the downstream service; When the downstream service is executed abnormally, service call compensation is performed based on the timing scheduler and the compensation annotation.
2. The method according to claim 1, characterized in that The compensation annotation includes: exception handling strategy; The exception handling strategy includes a storage strategy, a retry strategy and a compensation stop condition.
3. The method according to claim 2, characterized in that The timing scheduler is based on which the service call compensation is performed according to the compensation annotation, including: The call information corresponding to the execution exception is stored hierarchically according to the storage strategy to form a call information stack; Based on the timing scheduler, service call compensation is performed according to the call information stack and the retry strategy.
4. The method according to claim 2, characterized in that: The method further comprises: If the service call compensation reaches the compensation stop condition and the downstream service still has the execution exception, stop the service call compensation; The execution exception is pushed to the integrated exception dashboard.
5. The method according to claim 4, characterized in that The compensation stop conditions include: a preset processing time and a preset number of retries; If the service call compensation reaches the compensation stop condition and the downstream service still has the execution exception, stopping the service call compensation includes: If the service call compensation reaches the preset processing time or reaches the preset number of retries within the preset time, and the downstream service still has the execution exception, the service call compensation is stopped.
6. The method according to claim 4, characterized in that The method further comprises: The execution exception is displayed to the user through the integrated exception dashboard, and function options are provided for the user to select; the function options include general processing options and customized processing options; the general processing options include archiving, retrying, and modifying and retrying; The execution exception is processed based on the user's selection.
7. The method according to claim 1, characterized in that When the downstream service is executed abnormally, before performing service call compensation according to the compensation annotation based on the timing scheduler, the method further includes: Based on aspect programming, capture the execution exceptions of the downstream service.
8. A service call compensation device, characterized in that: include: A receiving module, used for receiving a service request; A determination module, used to determine an upstream service and a downstream service based on the business request; A marking module, used for marking a compensation annotation in the upstream service based on the business request, wherein the compensation annotation is used to provide a basis for the call compensation of the downstream service; The compensation module is used to perform service call compensation based on the compensation annotation based on the timing scheduler when the downstream service is executed abnormally.
9. A service call compensation device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the service call compensation method according to any one of claims 1 to 7 when executing the computer program.
10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the service call compensation method according to any one of claims 1 to 7 are implemented.