CN109245941B - Service compensation method and device - Google Patents

Service compensation method and device Download PDF

Info

Publication number
CN109245941B
CN109245941B CN201811196352.3A CN201811196352A CN109245941B CN 109245941 B CN109245941 B CN 109245941B CN 201811196352 A CN201811196352 A CN 201811196352A CN 109245941 B CN109245941 B CN 109245941B
Authority
CN
China
Prior art keywords
service
target service
client
compensation
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201811196352.3A
Other languages
Chinese (zh)
Other versions
CN109245941A (en
Inventor
张君华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Transfar Zhilian Co Ltd
Original Assignee
Transfar Zhilian Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Transfar Zhilian Co Ltd filed Critical Transfar Zhilian Co Ltd
Priority to CN201811196352.3A priority Critical patent/CN109245941B/en
Publication of CN109245941A publication Critical patent/CN109245941A/en
Application granted granted Critical
Publication of CN109245941B publication Critical patent/CN109245941B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • G06Q50/40
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5045Making service definitions prior to deployment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/133Protocols for remote procedure calls [RPC]

Abstract

The application provides a service compensation method and a device, wherein the method is applied to a client and can comprise the following steps: according to the received service configuration instruction, configuring service parameters predefined in a preset service definition table to obtain a target service, and configuring strategy parameters of a compensation strategy; sending a request instruction aiming at the target service to a server, so that the server responds to the request instruction and outputs the target service to the client; and when the server fails to output the target service, compensating the target service according to the configured compensation strategy.

Description

Service compensation method and device
Technical Field
The present application relates to the field of communications technologies, and in particular, to a service compensation method and apparatus.
Background
In the field of OLTP (On-Line Transaction Processing), Transaction consistency is a problem in most business scenarios. Especially, in the case of a large internet system containing hundreds of distributed transactions, how to efficiently ensure that the implementation modes of rollback, commit or retry of each distributed transaction are completely consistent is an extremely important issue.
Disclosure of Invention
In view of this, the present application provides a service compensation method and apparatus, so that when implementing distributed service consistency, a developer only needs to set specific values of service parameters and parameters of a compensation policy, and does not need to care about design of each service and scheduling and management of compensation, thereby improving efficiency.
In order to achieve the above purpose, the present application provides the following technical solutions:
according to a first aspect of the present application, a service compensation method is provided, which is applied to a client; the method comprises the following steps:
according to the received service configuration instruction, configuring service parameters predefined in a preset service definition table to obtain a target service, and configuring strategy parameters of a compensation strategy;
sending a request instruction aiming at the target service to a server, so that the server responds to the request instruction and outputs the target service to the client;
and when the server fails to output the target service, compensating the target service according to the configured compensation strategy.
According to a second aspect of the present application, a service compensation method is provided, which is applied to a server; the method comprises the following steps:
receiving a request instruction aiming at a target service sent by a client, wherein the target service is obtained by configuring predefined service parameters in a preset service definition table by the client according to the received service configuration instruction;
outputting the target service to the client in response to the request instruction;
when the target service is failed to be output, the client compensates the target service according to a configured compensation strategy, and the compensation strategy is obtained by configuring a predefined compensation strategy in a preset service definition table by the client according to a received service configuration instruction.
According to a third aspect of the present application, a service compensation apparatus is provided, which is applied to a client; the device comprises:
the configuration unit is used for configuring predefined service parameters in a preset service definition table according to the received service configuration instruction to obtain target service and configuring strategy parameters of a compensation strategy;
a sending unit, configured to send a request instruction for the target service to a server, so that the server outputs the target service to the client in response to the request instruction;
and the compensation unit is used for compensating the target service according to the configured compensation strategy when the target service output by the service terminal fails.
According to a fourth aspect of the present application, a service compensation apparatus is provided, which is applied to a server; the device comprises:
the system comprises a receiving unit, a service configuration unit and a service configuration unit, wherein the receiving unit is used for receiving a request instruction aiming at a target service sent by a client, and the target service is obtained by configuring predefined service parameters in a preset service definition table by the client according to a received service configuration instruction;
an output unit that outputs the target service to the client in response to the request instruction;
when the target service is failed to be output, the client compensates the target service according to a configured compensation strategy, and the compensation strategy is obtained by configuring a predefined compensation strategy in a preset service definition table by the client according to a received service configuration instruction.
According to the technical scheme, the service definition table is configured in advance and used for defining the distributed service. The service definition table includes definitions of service parameters and compensation policies. Therefore, when a developer calls each distributed service through the client, the developer only needs to set specific values of the service parameters and the parameters of the compensation strategy, and does not need to care about the design of each service and the design, scheduling and management of compensation, so that the efficiency is improved. Meanwhile, based on the definition and configuration of the compensation strategy, the consistency of the distributed service can be ensured.
Drawings
Fig. 1 is a flow chart illustrating a service compensation method according to an exemplary embodiment of the present application.
Fig. 2 is a flow chart illustrating another service compensation method according to an exemplary embodiment of the present application.
Fig. 3 is an interaction diagram illustrating a service compensation method according to an exemplary embodiment of the present application.
Fig. 4 is a schematic diagram illustrating an architecture of a service compensation system according to an exemplary embodiment of the present application.
Fig. 5 is a flow chart illustrating marking a request record by a client according to an exemplary embodiment of the present application.
Fig. 6 is a flowchart illustrating a server record processing state according to an exemplary embodiment of the present application.
Fig. 7 is a flowchart illustrating a client performing a compensation operation according to an exemplary embodiment of the present application.
Fig. 8 is a schematic structural diagram of an electronic device based on a client side according to an exemplary embodiment of the present application.
Fig. 9 is a block diagram illustrating a service compensation apparatus according to an exemplary embodiment of the present application.
Fig. 10 is a schematic structural diagram of an electronic device based on a server side according to an exemplary embodiment of the present application.
Fig. 11 is a block diagram illustrating another service compensation apparatus according to an exemplary embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Referring to fig. 1, fig. 1 is a flowchart illustrating a service compensation method according to an exemplary embodiment of the present application. As shown in fig. 1, the method applied to the client may include the following steps:
step 102, according to the received service configuration instruction, configuring service parameters predefined in a preset service definition table to obtain a target service, and configuring policy parameters of a compensation policy.
And 104, sending a request instruction for the target service to a server, so that the server responds to the request instruction and outputs the target service to the client.
And 106, when the target service output by the server side fails, compensating the target service according to a configured compensation strategy.
In this embodiment, by configuring a service definition table in advance for the distributed services (the service definition table includes definitions of service parameters and compensation policies), when a developer invokes each distributed service through a client, the developer only needs to set specific values of the service parameters and the parameters of the compensation policies, and does not need to care about design of each service and design, scheduling, and management of the compensation policies, thereby improving efficiency. Meanwhile, based on the definition and configuration of the compensation policy, when the server fails to output the target service, the target service can be compensated (for example, retried) according to the configured compensation policy, so as to ensure the consistency of the target service.
In this embodiment, the service parameter may include at least one of: service name, service request identifier, service type, request parameter, request processing state; the policy parameters may include at least one of: retry number, compensation mode, retry interval; wherein, the compensation mode comprises: retransmit, rollback, ignore. Therefore, when the developer realizes the consistency of the distributed service, the developer only needs to configure the values of the parameters and does not need to design the business codes related to the compensation strategy, thereby effectively improving the efficiency.
In this embodiment, different calling manners may be adopted between the client and the server according to the type (including the strong consistency service and the weak consistency service) of the target service (which may be, for example, a distributed service). Specifically, the client can judge the type of the target service, and when the target service belongs to strong consistency service, the client requests the server to call the target service in a remote procedure call mode; when the target service belongs to the weak consistency service, the target service can be requested to be called from the server side in a message queue mode. For the strong consistency service, the service is called by using an RPC (Remote Procedure Call), so that the real-time property of the service (i.e., the real-time property is high) can be ensured. For the weak consistency service, the MQ (Message Queue) mode is adopted for calling, so that the throughput can be improved, and the efficiency of calling the service is improved.
Accordingly, referring to fig. 2, fig. 2 is a flowchart illustrating another service compensation method according to an exemplary embodiment of the present application. As shown in fig. 2, the method applied to the server may include the following steps:
step 202, receiving a request instruction aiming at a target service sent by a client, wherein the target service is obtained by configuring predefined service parameters in a preset service definition table by the client according to the received service configuration instruction;
step 204, responding to the request instruction, and outputting the target service to the client; when the target service is failed to be output, the client compensates the target service according to a configured compensation strategy, and the compensation strategy is obtained by configuring a predefined compensation strategy in a preset service definition table by the client according to a received service configuration instruction.
In this embodiment, by configuring the service definition table in advance for the distributed services (the service definition table includes definitions of service parameters and compensation policies), when a developer calls each distributed service through a client, the developer only needs to set specific values of the service parameters and the parameters of the compensation policies, and does not need to care about design of each service and design, scheduling, and management of the compensation policies, thereby improving efficiency. Meanwhile, based on the definition and configuration of the compensation strategy, when the server fails to output the target service, the target service can be compensated (for example, retried) according to the configured compensation strategy, so that the consistency of the target service is ensured.
In this embodiment, the compensation record of each service may be stored in a third-party device different from the client and the server, so that the client and the server actively read from the third-party device. The compensation records are stored in the third-party equipment and are actively read by the client and the server, so that the storage space of the client and the server can be saved. In addition, the preset service definition table can also be stored in the third-party device, so that the client can actively read the preset service definition table from the third-party device.
For the convenience of understanding, the technical solutions of the present application will be described in detail below with reference to specific examples and the accompanying drawings.
Referring to fig. 3, fig. 3 is an interaction diagram illustrating a service compensation method according to an exemplary embodiment of the present application. As shown in fig. 3, the method may include the steps of:
in step 302, the client generates a request command.
Step 304, the client configures a compensation policy.
In this embodiment, the service definition table may be configured in advance for the developer to configure the parameters included therein. The service definition table includes definitions of service parameters and compensation policies. Based on the pre-configuration of the service definition table, when a developer calls each distributed service through a client, the developer only needs to set specific values of the service parameters and the parameters of the compensation strategy, and does not need to care about the design of each service and the design of the compensation strategy (for example, the design, scheduling and management of service codes for realizing compensation to ensure consistency), so that the efficiency is improved. Meanwhile, based on the definition and configuration of the compensation strategy, when the server fails to output the target service, the target service can be compensated (for example, retried) according to the configured compensation strategy, so that the consistency of the target service is ensured.
For example, the service definition table may be as shown in table 1:
Figure BDA0001828848170000061
Figure BDA0001828848170000071
TABLE 1
Wherein, the distributed service definition id (distTransId) is used for representing a service request identifier, the message Name (message Name) is used for representing a service Name, the message Type (msg Type) and the message SubType (message SubType) are used for representing a service Type, and the return state (return Code) is used for representing a request processing state; the return status response Type (result Action Type) is used to indicate a compensation mode, including retransmission, rollback, ignore, etc. Based on the service definition table shown in table 1, the developer only needs to assign values to the field values of the fields, and can complete the formulation of the target service and the compensation policy for the target service.
And for the storage of the service definition table, the service definition table can be stored in a third-party device which is different from the client and the server. As shown in fig. 4, the client 41 interacts with the server 42, and the service definition table may be stored in the database 43 to be actively read from the database 43 by the client 41 and the server 42.
Step 306, the client sends a request instruction to the server to call the target service.
In this embodiment, a client (as a service consumer) sends a request instruction for a target service to a server (as a service provider), so that the server outputs (provides) the target service to the client in response to the request instruction.
In step 308, the client stores the request record.
In this embodiment, the request record may be stored in the message record table to record the specific per-service call process. This is explained below with reference to fig. 5. As shown in fig. 5, the process may include the steps of:
in step 502, it is determined whether the target service requires automatic compensation, if so, step 504 is performed, otherwise, the process is ended.
In step 504, an identifier of the request instruction is obtained.
In step 506, it is determined whether there is a request record with the same identifier in the message record table, if so, the procedure is terminated, otherwise, the procedure proceeds to step 508.
In step 508, the request instruction is marked as sent.
For example, the message record table may be as shown in table 2:
Figure BDA0001828848170000081
Figure BDA0001828848170000091
Figure BDA0001828848170000101
TABLE 2
Wherein, the message processing number (distTransMsgId) is used for representing the service name, the service information number is used for representing (businessmsgId) is used for representing the identifier (the identifier is unique) of the request instruction; the compensation methods include retransmission, rollback, ignoring, etc. For example, when it is determined that there is no request record of the same identifier in the message record table, the field "message processing Status (msgProcess Status)" is marked as transmitted. The message record table may be stored in the client, or may be stored in the database 43.
At step 310, the server processes the request command.
In step 312, the server records the processing status.
In this embodiment, the processing status may be recorded in the consumption record table to record the processing status for each received request instruction. This will be explained with reference to fig. 6. As shown in fig. 6, the process may include the steps of:
in step 602, it is determined whether the target service requires automatic compensation, if yes, go to step 604, otherwise, end.
In step 604, an identifier of the received request instruction is obtained.
In step 606, it is determined whether there is a request record with the same identifier in the consumption record table, if so, the process ends, otherwise, the process proceeds to step 608.
In step 608, it is determined whether the requested command is a non-repeatable command or "in process", if so, the process is terminated, otherwise, the process proceeds to step 610.
In step 610, the request instruction is marked as in-process.
In step 612, the request instruction is processed.
In step 614, the update request instruction is in a process complete state.
For example, the consumption record table may be as shown in table 3:
Figure BDA0001828848170000102
Figure BDA0001828848170000111
TABLE 3
The message processing state comprises processing and processing completion. The consumption record table may be stored in the server side, or may be stored in the database 43.
And step 314, when the server fails to output the target service, compensating the target service according to the configured compensation strategy.
Step 316, when the server finishes processing the request command by the compensation operation, the processing status is updated to be finished.
Step 318, the server returns the processing status to the client.
In step 320, the client updates the processing status corresponding to the request command in the message record table to be completed.
In this embodiment, when the client fails to invoke the target service (i.e., the server fails to output the target service), the target service may be compensated according to the compensation policy configured in step 304, so as to achieve consistency of the target service.
Taking the compensation method in the compensation strategy as retry as an example, as shown in fig. 7, the compensation process may include the following steps:
in step 702, the client traverses the request command whose status is sent in the message record table.
Step 704, determining whether the current time reaches the retry interval, if yes, turning to step 706, otherwise, turning to step 702.
And step 706, re-sending the request instruction to the server.
For example, assuming that the number of retries configured in the compensation policy (the compensation manner is configured as retries) is 10, the retry interval (which can be understood as a period of retries) is 6 s; then, when the state of the request instruction is sent, the client resends the request instruction to the server according to the cycle of 6s until the number of times of sending the request instruction (the same request instruction) reaches 10 times.
For another example, when a developer needs to add logic for deducting a renewal fee after a deposit operation, parameters such as a message or request name, an identifier of the message or request, a parameter body, a rollback message or request name, a rollback parameter body, a compensation mode, and the like of a distributed transaction may be determined at a service logic level according to the service definition table shown in table 1, so that consistent development of the distributed transaction may be completed without writing a skeleton code. For example, the configuration shown in table 4 may be made:
Figure BDA0001828848170000121
TABLE 4
Based on the above configuration, when the client requests to invoke the deduction service, if any error of RET001, RET002, RET003 occurs, the deduction service is automatically attempted to be invoked every 3 minutes until 0 or success is returned (indicating success), or until the number of attempts exceeds a specified number.
It should be noted that, in the service compensation scheme of the present application, the client may determine the type of the target service, and when the target service belongs to the strong consistency service, request the server to call the target service in a remote procedure call manner; when the target service belongs to the weak consistency service, the target service can be requested to be called from the server side in a message queue mode. For the strong consistency service, the service is called by using an RPC (Remote Procedure Call), so that the real-time property of the service (i.e., the real-time property is high) can be ensured. For the weak consistency service, the MQ (Message Queue) mode is adopted for calling, so that the throughput can be improved, and the efficiency of calling the service is improved.
Fig. 8 shows a schematic block diagram of a client side based electronic device according to an exemplary embodiment of the present application. Referring to fig. 8, at the hardware level, the electronic device includes a processor 802, an internal bus 804, a network interface 808, a memory 808, and a non-volatile memory 810, but may also include hardware required for other services. The processor 802 reads a corresponding computer program from the non-volatile memory 810 into the memory 808 and runs the computer program, thereby forming a service compensation apparatus on a logical level. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 9, in a software implementation, the service compensation apparatus may include:
the configuration unit 91, according to the received service configuration instruction, configures predefined service parameters in a preset service definition table to obtain a target service, and configures policy parameters of a compensation policy;
a sending unit 92, configured to send a request instruction for the target service to a server, so that the server outputs the target service to the client in response to the request instruction;
and the compensation unit 93 is configured to compensate the target service according to a configured compensation policy when the target service output by the service terminal fails.
Alternatively to this, the first and second parts may,
further comprising: a judging unit 94 that judges the type of the target service;
the sending unit 92 is specifically configured to: when the target service belongs to strong consistency service, calling the target service to the server side in a remote procedure calling mode; and when the target service belongs to weak consistency service, requesting to call the target service from the server side by adopting a message queue mode.
Optionally, the service parameter includes at least one of: service name, service request identifier, service type, request parameter, request processing state; the policy parameters include at least one of: retry number, compensation mode, retry interval; wherein, the compensation mode comprises: retransmit, rollback, ignore.
Fig. 10 shows a schematic block diagram of a server-side based electronic device according to an exemplary embodiment of the present application. Referring to fig. 10, at the hardware level, the electronic device includes a processor 1002, an internal bus 1004, a network interface 10010, a memory 10010, and a non-volatile memory 1010, although it may also include hardware required by other services. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 into the memory 10010 and runs the computer program, thereby forming a service compensation device on a logic level. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 11, in a software implementation, the service compensation apparatus may include:
the receiving unit 1101 is configured to receive a request instruction for a target service sent by a client, where the target service is obtained by configuring, by the client, service parameters predefined in a preset service definition table according to a received service configuration instruction;
an output unit 1102 that outputs the target service to the client in response to the request instruction;
when the target service is failed to be output, the client compensates the target service according to a configured compensation strategy, and the compensation strategy is obtained by configuring a predefined compensation strategy in a preset service definition table by the client according to a received service configuration instruction.
Optionally, the compensation record of each service is stored in a third-party device different from the client and the server, so that the client and the server actively read from the third-party device.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.
In an exemplary embodiment, there is also provided a non-transitory computer-readable storage medium, such as a memory, including instructions executable by a processor of a service compensation apparatus to perform the method described above, which may include:
according to the received service configuration instruction, configuring service parameters predefined in a preset service definition table to obtain a target service, and configuring strategy parameters of a compensation strategy;
sending a request instruction aiming at the target service to a server, so that the server responds to the request instruction and outputs the target service to the client;
and when the server fails to output the target service, compensating the target service according to the configured compensation strategy.
Optionally, the method further includes: judging the type of the target service;
the sending a request instruction for the target service to a server includes: when the target service belongs to strong consistency service, calling the target service to the server side in a remote procedure calling mode; and when the target service belongs to the weak consistency service, requesting to call the target service from the server side in a message queue mode.
Optionally, the service parameter includes at least one of: service name, service request identifier, service type, request parameter, request processing state; the policy parameters include at least one of: retry number, compensation mode, retry interval; wherein, the compensation mode comprises: retransmit, rollback, ignore.
The non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc., which is not limited in this application.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims (8)

1. A service compensation method is applied to a client; the method comprises the following steps:
according to the received service configuration instruction, configuring service parameters predefined in a preset service definition table to obtain a target service, and configuring strategy parameters of a compensation strategy;
sending a request instruction aiming at the target service to a server, so that the server responds to the request instruction and outputs the target service to the client;
when the server fails to output the target service, compensating the target service according to a configured compensation strategy;
further comprising: judging the type of the target service;
the sending a request instruction for the target service to a server includes: when the target service belongs to strong consistency service, calling the target service to the server side in a remote procedure calling mode; and when the target service belongs to the weak consistency service, requesting to call the target service from the server side in a message queue mode.
2. The method of claim 1, wherein the service parameters comprise at least one of: service name, service request identifier, service type, request parameter, request processing state; the policy parameters include at least one of: retry number, compensation mode, retry interval; wherein, the compensation mode comprises: retransmit, rollback, ignore.
3. A service compensation method is characterized in that the method is applied to a server; the method comprises the following steps:
receiving a request instruction aiming at a target service sent by a client, wherein the target service is obtained by configuring predefined service parameters in a preset service definition table by the client according to the received service configuration instruction; the request instruction is sent by the client after the type of the target service is judged, and when the target service belongs to strong consistency service, the target service is requested to be called to the server by the client in a remote procedure calling mode; when the target service belongs to weakly consistent service, the target service is requested to be called from the client to the server in a message queue mode;
outputting the target service to the client in response to the request instruction;
when the target service is failed to be output, the client compensates the target service according to a configured compensation strategy, and the compensation strategy is obtained by configuring a predefined compensation strategy in a preset service definition table by the client according to a received service configuration instruction.
4. The method of claim 3, wherein the compensation record for each service is stored in a third-party device distinct from the client and the server for active reading by the client and the server into the third-party device.
5. A service compensation device is applied to a client; the device comprises:
the configuration unit is used for configuring predefined service parameters in a preset service definition table according to the received service configuration instruction to obtain target service and configuring strategy parameters of a compensation strategy;
a sending unit, configured to send a request instruction for the target service to a server, so that the server outputs the target service to the client in response to the request instruction;
the compensation unit is used for compensating the target service according to a configured compensation strategy when the target service output by the service terminal fails;
further comprising: a judging unit that judges a type of the target service;
the sending unit is specifically configured to: when the target service belongs to strong consistency service, calling the target service to the server side in a remote procedure calling mode; and when the target service belongs to the weak consistency service, requesting to call the target service from the server side in a message queue mode.
6. The apparatus of claim 5, wherein the service parameters comprise at least one of: service name, service request identifier, service type, request parameter, request processing state; the policy parameters include at least one of: retry times, compensation mode, retry interval; wherein, the compensation mode comprises: retransmit, rollback, ignore.
7. A service compensation device is characterized by being applied to a service end; the device comprises:
the system comprises a receiving unit, a service configuration unit and a service configuration unit, wherein the receiving unit is used for receiving a request instruction aiming at a target service sent by a client, and the target service is obtained by configuring predefined service parameters in a preset service definition table by the client according to a received service configuration instruction; the request instruction is sent by the client after the type of the target service is judged, and when the target service belongs to strong consistency service, the target service is requested to be called from the client to the server in a remote process calling mode; when the target service belongs to weakly consistent service, the target service is requested to be called from the client to the server in a message queue mode;
an output unit that outputs the target service to the client in response to the request instruction;
when the target service is failed to be output, the client compensates the target service according to a configured compensation strategy, and the compensation strategy is obtained by configuring a predefined compensation strategy in a preset service definition table by the client according to a received service configuration instruction.
8. The apparatus of claim 7, wherein the compensation record for each service is stored in a third-party device distinct from the client and the server for being actively read into the third-party device by the client and the server.
CN201811196352.3A 2018-10-15 2018-10-15 Service compensation method and device Active CN109245941B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811196352.3A CN109245941B (en) 2018-10-15 2018-10-15 Service compensation method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811196352.3A CN109245941B (en) 2018-10-15 2018-10-15 Service compensation method and device

Publications (2)

Publication Number Publication Date
CN109245941A CN109245941A (en) 2019-01-18
CN109245941B true CN109245941B (en) 2022-05-31

Family

ID=65053715

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811196352.3A Active CN109245941B (en) 2018-10-15 2018-10-15 Service compensation method and device

Country Status (1)

Country Link
CN (1) CN109245941B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110471746B (en) * 2019-08-22 2022-04-19 中国工商银行股份有限公司 Distributed transaction callback method, device and system
CN112783665B (en) * 2019-11-07 2023-11-03 北京京东振世信息技术有限公司 Interface compensation method and device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106874073A (en) * 2016-07-01 2017-06-20 阿里巴巴集团控股有限公司 The implementation method and device of affairs under SOA framework
CN108156208A (en) * 2016-12-02 2018-06-12 阿里巴巴集团控股有限公司 A kind of dissemination method of application data, device and system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8934336B2 (en) * 2011-03-16 2015-01-13 Qualcomm Incorporated System and method for preserving session context during inter-radio access technology service retry

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106874073A (en) * 2016-07-01 2017-06-20 阿里巴巴集团控股有限公司 The implementation method and device of affairs under SOA framework
CN108156208A (en) * 2016-12-02 2018-06-12 阿里巴巴集团控股有限公司 A kind of dissemination method of application data, device and system

Also Published As

Publication number Publication date
CN109245941A (en) 2019-01-18

Similar Documents

Publication Publication Date Title
US11621824B2 (en) Blockchain transaction manager
CN103038788B (en) Providing multiple network resources
US8014994B2 (en) Simulation business object for service oriented architecture
CN103312549B (en) A kind of office management method and device and system
US7890959B2 (en) System and method for message lifetime management
US8538793B2 (en) System and method for managing real-time batch workflows
EP3489825A1 (en) Method, apparatus and computer readable storage medium for processing service
CN111199379A (en) Examination and approval method, examination and approval device and storage medium of workflow engine
CN108446172B (en) Data calling method and device, computer equipment and storage medium
CN111667334B (en) Audit failure order processing method and device, computer equipment and storage medium
CN109245941B (en) Service compensation method and device
CN110532025A (en) Data processing method, device, equipment and storage medium based on micro services framework
US20220377556A1 (en) Internet-of-things device registration method and apparatus, device, and storage medium
CN108647105B (en) Idempotent control method, device and system in system switching process
CN115984022B (en) Unified account checking method and device for distributed payment system
CN111327680A (en) Authentication data synchronization method, device, system, computer equipment and storage medium
CN112995262A (en) Distributed transaction submission method, system and computing equipment
CN111767200B (en) Method, device and computer equipment for processing service based on service log
CN116095074A (en) Resource allocation method, device, related equipment and storage medium
CN113987035A (en) Block chain external data access method, device, system, equipment and medium
CN112148803A (en) Method, device and equipment for calling tasks in block chain and readable storage medium
CN110874713A (en) Service state management method and device
CN113704274B (en) Data reading method and electronic equipment
CN108763247B (en) Method and device for processing user request in data migration process
CN110837536B (en) Information processing method, device and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant