CN109491765B - Method and device for processing cross-domain service request - Google Patents
Method and device for processing cross-domain service request Download PDFInfo
- Publication number
- CN109491765B CN109491765B CN201811174610.8A CN201811174610A CN109491765B CN 109491765 B CN109491765 B CN 109491765B CN 201811174610 A CN201811174610 A CN 201811174610A CN 109491765 B CN109491765 B CN 109491765B
- Authority
- CN
- China
- Prior art keywords
- idempotent
- processing
- cross
- identifier
- service
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Abstract
According to one embodiment of the method, the same idempotent identifier extracted from a processing request and an inquiry request sent to a first system by a second system is used, the first system is used for processing the idempotent identifier of the cross-domain service according to the first processed processing request or one of the first processed inquiry requests, and if the inquiry request arrives before the processing request, the idempotent identifier of the cross-domain service can be landed, and the corresponding processing state (record) is determined to be a preset state. Therefore, for the cross-domain service needing to acquire the service state through query, the service state records of the cross-domain service of the two systems in which the cross-domain service occurs can be kept consistent.
Description
Technical Field
One or more embodiments of the present specification relate to the field of computer technology, and in particular, to a method and apparatus for processing a cross-domain service request by a computer.
Background
Cross-domain services are typically services that occur between two servitization systems deployed separately. In two systems with cross-domain service, if one system needs to complete the service related to the other system, the operation can only be completed by a service interface request provided by the other system. The two systems where cross-domain services occur may be, for example, two systems under different domain names, different APPs (applications), two subsystems under the same APP, and so on. For example, in a service-oriented architecture SOA, different functional units (which may also be referred to as services) of an application communicate through interfaces and contracts defined between these functional units. Since the interface is defined in a neutral manner, it is independent of the hardware platform, operating system and programming language that implement the service, which allows services built into a wide variety of systems to interact in a unified and universal manner under the SOA. At this time, the two systems where the cross-domain service occurs may be two different functional units (services) under the SOA.
In cross-domain services, timing control is often required. For example, in a financial system, after a cross-domain service sends a processing request, a processing result of the cross-domain service is often queried to obtain whether the cross-domain service is successfully processed. Due to network delay or jitter, if the query request arrives at the opposite system before the processing request, the recorded results of the cross-domain services of the two parties may be inconsistent, which may cause fund differences, increase the workload of the financial staff, or generate significant fund risks.
Therefore, an improved scheme is desired to avoid the possible time sequence abnormality in the cross-domain service, so as to ensure the state consistency of the cross-domain service.
Disclosure of Invention
One or more embodiments of the present specification describe a method and apparatus for processing cross-domain service requests for recipients that occur in both systems. When the service request of the cross-domain service is processed for the first time, the idempotent identification of the cross-domain service is recorded regardless of the processing request or the query request, so that possible time sequence disorder in the cross-domain service can be avoided, and the processing results of the first system and the second system on the cross-domain service are kept consistent.
According to a first aspect, a method for processing a cross-domain service request is provided, where the cross-domain service includes a service performed between a first system and a second system; the method is performed by the first system and comprises: receiving an inquiry request at a first moment, wherein the inquiry request is sent by the second system after a preset time interval after a processing request is sent, and is used for inquiring the processing state of the cross-domain service in the processing request, and the inquiry request comprises a service identifier which is consistent with the processing request and corresponds to the cross-domain service; extracting idempotent identifications of the cross-domain services from the query request, wherein the idempotent identifications at least comprise the service identifications, and the idempotent identifications are at least used for querying and/or recording processing states of the cross-domain services; determining a processing state of the cross-domain service based on the query of the idempotent identifier, wherein the idempotent identifier is recorded under the condition that the idempotent identifier is not queried, and the processing state corresponding to the idempotent identifier is determined to be a preset state; and sending the processing state corresponding to the idempotent identifier as a query result to the second system.
In one embodiment, the determining the processing state of the cross-domain service based on the query for idempotent service identification further comprises: and acquiring a processing state corresponding to the idempotent identifier under the condition that the idempotent identifier is inquired.
According to one embodiment, the method further comprises: at a second moment, receiving the processing request, wherein the processing request comprises the service identifier; extracting the idempotent identification from the processing request;
and processing the processing request according to the idempotency of the idempotency identification.
In one embodiment, the processing request according to the idempotency identified by the idempotency includes: querying the idempotent identifiers; responding to the idempotent identification which cannot be inquired, recording the idempotent identification, and processing the cross-domain service so as to record a processing result of the cross-domain service as a processing state corresponding to the idempotent identification; or, in response to querying the idempotent identifier, determining that the cross-domain service does not need to be processed.
In one embodiment, the idempotent identifier and the processing state of the cross-domain service are recorded by a service idempotent table.
In one embodiment, the idempotent identification further includes at least one of a system identification, a time identification of the second system.
According to a second aspect, there is provided a processing apparatus for a cross-domain service request, the cross-domain service including a service performed between a first system and a second system; the apparatus is provided in the first system, and includes: an obtaining unit, configured to receive, at a first time, an inquiry request, where the inquiry request is sent by the second system after a predetermined time interval after sending a processing request, and is used to inquire a processing state of a cross-domain service in the processing request, where the inquiry request includes a service identifier that is consistent with the processing request and corresponds to the cross-domain service; an extracting unit, configured to extract an idempotent identifier of the cross-domain service from the query request, where the idempotent identifier includes at least the service identifier, and the idempotent identifier is at least used for querying and/or recording a processing state of the cross-domain service; the determining unit is configured to determine a processing state of the cross-domain service based on query of the idempotent identifier, wherein the idempotent identifier is recorded under the condition that the idempotent identifier is not queried, and the processing state corresponding to the idempotent identifier is determined to be a preset state; and the sending unit is used for sending the processing state corresponding to the idempotent identifier to the second system as a query result.
According to a third aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first aspect.
According to a fourth aspect, there is provided a computing device comprising a memory and a processor, wherein the memory has stored therein executable code, and wherein the processor, when executing the executable code, implements the method of the first aspect.
In the method and the apparatus for processing a cross-domain service request provided in the embodiments of the present specification, the processing request and the query request sent from the second system to the first system include the same service identifier, and both the processing request and the query request can extract an idempotent identifier including at least the service identifier. The first system identifies according to an idempotent of a first processed processing request or a query request, and if the query request arrives before the processing request, the processing state corresponding to the idempotent identification can be landed (recorded) as a preset state (for example, processing failure, unprocessed state, etc.). Therefore, for an asynchronous service request (for a service, a processing request is sent first and then an inquiry request is sent, and subsequent processing is performed based on an inquiry result, wherein the processing request and the inquiry request are asynchronous service requests of the service), the processing state records of the cross-domain service by two systems in which the cross-domain service occurs can be kept consistent without being influenced by a request time sequence.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIGS. 1-3 are schematic diagrams illustrating an implementation scenario of an embodiment disclosed herein;
FIG. 4 illustrates a flow diagram of a method of processing a cross-domain service request, according to one embodiment;
fig. 5 shows a schematic block diagram of a processing device for cross-domain service requests according to one embodiment.
Detailed Description
The scheme provided by the specification is described below with reference to the accompanying drawings.
The embodiment of the specification is mainly applied to a process of cross-domain service between a first system and a second system. The first system and the second system are two systems with mutually independent functions, for example, the first system is an online shopping system, the second system is an online payment platform (such as a pay bank), and the cross-domain service may be a service of making payment for an order of the online shopping system through the online payment platform. To more clearly illustrate the aspects of the embodiments of the present description, the background of the application of the embodiments of the present description is first presented.
Fig. 1 is a sequence diagram of normal interactions between a second system and a first system in the case where a user initiates a service 1 associated with the first system through the second system. As shown in fig. 1, in a normal case, the second system first sends a processing request of service 1 to the first system at time t. The first system receives the processing request of the service 1, can directly process the service 1, or can store the processing request into a cache first, and process the service 1 at a certain time according to the service priority ranking sequence. When the first system processes the service 1, the first system may record the service 1, process the service 1, and record a processing result. The processing result may include processing success, processing failure, and the like. At time T, which has a predetermined time interval (e.g., 30 seconds) from time T, the second system sends a query request for service 1 to the first system. The first system queries the processing result of the service 1 and feeds back the processing result to the second system. In the process of processing the service 1, the first system may modify the database according to the processing condition, for example, the service 1 is a payment service for making a payment from an order of the first system to the second system, and the first system may subtract a relevant value from an account balance corresponding to the user in the database. At this time, the second system may also determine a payment result according to the query result of the service 1 returned by the first system, and perform subsequent processes, for example, if the payment is successful, an order to be shipped is generated. It should be noted that if the first system does not receive the service 1 processing request, a "not received" query result may also be returned. If the first system is abnormal, busy or processing the service 1, the corresponding result can be returned, at this time, the second system can circularly send the query request of the service 1 until receiving the information corresponding to the processing success, processing failure, non-reception and the like and defining the service processing result.
In addition, in the conventional technology, in order to ensure that the first system may receive the processing request of the same cross-domain service for multiple times under the conditions of network instability, delay, retransmission and the like, the first system often processes each cross-domain service according to the idempotency of the idempotent identifier. That is, for the same cross-domain service, no matter how many times the processing request is received, the processing request is processed only once, and only one processing result is provided. Specifically, for a normally received processing request, an idempotent identifier of a corresponding cross-domain service may be extracted first, the idempotent identifier is queried in an idempotent table recording the cross-domain service, and if the idempotent identifier is found, it is indicated that the corresponding cross-domain service is processed (or accepted) and is not processed any more. When the first system receives a query request for cross-domain services, the idempotent identifier is extracted first, and the processing state of the cross-domain services is queried from the service idempotent table.
Referring to fig. 2, it is assumed that a processing request of service 1 sent by the second system at time T has not been received by the first system at time T due to a network or hardware device failure. And at time T, the first system acquires the query request of the service 1 sent by the second system to the first system. The first system returns query results that are not received or not present, etc. And the second system continues the subsequent flow according to the query result and the service 1 processing failure. For example, the second system resends the payment request numbered service 2, etc. Then, the first system receives the processing request of the service 1 again, and processes the service 1, for example, subtracting a relevant value from the account balance corresponding to the user, and records the processing result. That is, the first system continues the subsequent flow in accordance with the normal processing for service 1. In this case, the processing result records of the service 1 by the first system and the second system are no longer consistent. In practical applications, a large time interval is set between time T and time T to avoid this situation as much as possible. However, on one hand, a larger time interval is set between the time T and the time T, which affects the efficiency of service interaction, and on the other hand, under the influence of an uncertain factor, it is difficult to find a better time interval, which ensures that the first system does not obtain the processing request of the service 1 after the time T and process the service 1.
In the above background, fig. 3 shows a schematic implementation scenario of an embodiment disclosed in this specification. In fig. 3, for a cross-domain service requested by a second system to a first system, after the second system sends a processing request to the first system, a query request is sent to the first system after a predetermined time interval. Specifically, the processing request and the query request sent by the second system to the first system may both include a service identifier corresponding to the cross-domain service. This service identification is, for example, an order number or serial number in the aforementioned payment service. When the first system receives a query request of the second system for the cross-domain service, the idempotent identifier of the cross-domain service can be extracted from the query request, and the processing state of the cross-domain service is queried based on the idempotent identifier, so that the processing state corresponding to the idempotent identifier is determined according to a query result. Wherein: under the condition that the idempotent identifier is inquired, the processing state corresponding to the idempotent identifier can be directly acquired; under the condition that the idempotent identifier is not inquired, the idempotent identifier can be recorded, and the processing state corresponding to the idempotent identifier is determined to be a preset state. Wherein the preset state may include, but is not limited to, one of the following: not received, not processed, processing failed, null status, etc. Then, the first system sends the processing state corresponding to the idempotent identifier to the second system as a query result. Wherein the idempotent identity may at least comprise the above-mentioned service identity. The first system accepts the service corresponding to the idempotent identifier only once according to the idempotent identifier. In other words, as long as the first system records the idempotent flag, the first system does not accept any more processing requests for the service corresponding to the idempotent flag. In some embodiments, idempotent identification may also include other identifications, such as a time identification (e.g., 2018, 9, 5), a system identification of the second system (e.g., system identification: number 2, etc.), and so forth.
Thus, in the case where the first system has normally processed the cross-domain service, it is the processing state of the normal processing that is returned to the second system. However, under the abnormal condition that the first system has not received the cross-domain service processing request, as shown in fig. 3, when the first system receives the query request of the service 1 first, because the first system has not received the processing request of the service 1, there is no record of the service 1 locally, and there is no record of the idempotent identifier of the service 1. At this time, on one hand, the first system may drop (e.g., record in the database) an idempotent identifier of the service 1 to stop the possibility that the cross-domain service is processed again subsequently, and record the corresponding processing state as a preset state (e.g., processing failure, etc.), and on the other hand, the first system returns the query result of the preset state of the service 1 to the second system. In this way, the second system may perform subsequent processes according to the preset state of the service 1, for example, the order payment fails, and a new payment request needs to be sent again or an order needs to be placed again. And then, even if the first system receives the processing request about the service 1 again, the first system does not process the service 1 any more because the idempotent identifier of the service 1 is landed in the first system and the result of the corresponding preset state is recorded. Therefore, the processing state or the processing result of the first system and the second system to the service 1 can be ensured to be consistent under the condition that the service request delivery time sequence caused by network reasons is not in accordance with the expectation.
As can be seen from the above description, the method for processing a cross-domain service request and a request for a cross-domain service according to the embodiments of the present disclosure is particularly suitable for a service request between two servitization systems having independent functions. The two servitization systems can communicate through a certain protocol and a certain interface. Because the interfaces are independent of the hardware platform, operating system, and programming language in which the services are implemented, services built into a wide variety of systems can interact in a uniform and versatile manner. For example, for a service-oriented architecture SOA, the first system and the second system may be two functional units of the same service platform, such as a financial unit (e.g., a balance treasured) and a payment unit (e.g., a money transfer) in one payment platform, or may be functional units under different types of service platforms, such as a computing unit under a hydropower management platform and a payment unit under a bank asset management platform, and the like. It can be understood that, since the first system and the second system may provide different services, after one system initiates a processing request of a cross-domain service to the other system, the processing condition of the cross-domain service needs to be queried again to ensure consistency of service states recorded by the cross-domain service between the two systems.
The specific implementation of the above scenario is described below.
FIG. 4 illustrates a flow diagram of a method for processing a cross-domain service request, according to one embodiment. The cross-domain service is a service occurring between two systems, such as a payment service occurring between an online shopping platform and an online payment platform, a deposit and withdrawal service occurring between a front subsystem and an accounting subsystem of a certain banking system, and the like. Here, the online shopping platform and the online payment platform are two systems, for example, a first system and a second system shown in fig. 1 to 3, respectively. The execution subject of the method may be the first system shown in fig. 1 to 3, and the like. The first system may be any system, device, apparatus, platform, or server having computing, processing capabilities. It is worth mentioning that the first system and the second system are only used for distinguishing two different systems, and do not represent other limitations. That is, the roles of the first system and the second system may be interchanged.
As shown in fig. 4, the method comprises the steps of: step 41, at a first time, receiving an inquiry request, where the inquiry request is sent by a second system after a predetermined time interval after sending a processing request, and is used to inquire a processing state of a cross-domain service in the processing request, where the inquiry request includes a service identifier consistent with the processing request and corresponding to the cross-domain service; step 42, extracting idempotent identifications of the cross-domain services from the query request, wherein the idempotent identifications at least comprise the service identifications, and the idempotent identifications are at least used for querying and/or recording the processing states of the cross-domain services; step 43, determining a processing state of the cross-domain service based on the query of the idempotent identifier, wherein the idempotent identifier is recorded under the condition that the idempotent identifier is not queried, and the processing state corresponding to the idempotent identifier is determined to be a preset state; and step 44, sending the processing state corresponding to the idempotent identifier to the second system as a query result.
It is worth noting that the flow of fig. 4 is particularly adapted to such scenarios: aiming at a cross-domain service requested by a second system to a first system, after the second system sends a processing request to the first system, a query request is sent to the first system after a preset time interval so as to query the processing state of the first system to the cross-domain service.
In the embodiment of the present specification, there may be a certain service identifier for a cross-domain service. The service identity corresponds to a cross-domain service. For example, for bank counter transactions, each transaction may uniquely correspond to a queuing number on each date. The service identification may be composed of at least one of a number, a character, a symbol, a letter, etc., and may be, for example, a serial number, an order number, etc. And the idempotent identifier is the basis for the first system to process the cross-domain service processing request or the query request. In case the service identity uniquely corresponds to a cross-domain service, the idempotent identity may only comprise the service identity. The idempotent identities may also include a limiting factor for a limited range, in case the service identity uniquely corresponds to a cross-domain service within the limited range.
For the same cross-domain service, the processing request and the query request sent by the second system to the first system may include the same service identifier. For the first system, it may receive the processing request first, or may receive the query request first.
Normally, the first system receives the processing request first. For processing requests, the first system may process the requests directly after receiving the requests, or may place the requests in a cache and process the requests in order according to task priority. In general, the time when the first system obtains the processing request can be regarded as the time when the first system is to process the cross-domain service. This time is referred to as the second time in order to be consistent with the summary of the invention. At this time, the first system may first query whether the cross-domain service has a record in the first system according to the idempotent identifier. In the case that the cross-domain service is recorded, it indicates that the cross-domain service has been accepted, and the first system may not process the cross-domain service any more, so as to avoid repeated processing. Under the condition that the cross-domain service is not recorded, the cross-domain service is not accepted, the first system can firstly fall to the ground (namely recording, such as writing into a database) by the idempotent identifier, and then the cross-domain service is processed according to the processing request, so that a corresponding processing result is obtained. After the first system processes the cross-domain service, the first system can also record the processing result to the corresponding processing state. For example, success and failure of the process in the process result may be recorded as the process status. At a third time, the second system sends a query request to the first system. The third time is later than the second time, and may have a time interval with the second time, such as 30 seconds.
It is assumed that the first system receives the query request at the first time, and the order of the first time and the second time cannot be predetermined. As such, the first system may perform the flow shown in fig. 4 when obtaining the query request.
First, in step 41, at a first time, a query request of the second system for the cross-domain service is received. It is to be understood that the query request is issued by the second system after a predetermined time interval after issuing the processing request, and the query request includes the service identifier corresponding to the cross-domain service consistent with the processing request. Because the service identifier and the cross-domain service are in a corresponding relationship, the first system can identify and process the corresponding cross-domain service based on the service identifier.
The idempotent identities of the cross-domain traffic are then extracted from the query request, via step 42. It is understood that the idempotent flag is a flag set by the first system to guarantee idempotent of processing requests of the service. An idempotent identifier may uniquely identify a service. The first system can also inquire and/or record the processing state of the cross-domain service according to the idempotent identification.
In some cases, the service identification may uniquely correspond to a particular service. For example, service identifiers can be uniformly allocated to services in all relevant systems, and in the case that the first system interacts with only one second system, the second system allocates corresponding serial numbers to each service according to a request sequence, and the like.
In other cases, the service identification may not uniquely correspond to a particular service. For example, each shopping platform of the plurality of shopping platforms can pay through a bank card of a certain bank, and the service identification of each platform can be an order number generated by the platform server. The bank's payment platform may act as a first system and each shopping platform as a second system, and since each shopping platform has a different server, the order numbers they generate may be identical, e.g., both 000000050827 (i.e., representing the 50827 th order placed among all users in the respective platform). In this case, a service is uniquely determined by the platform identifier of the shopping platform, i.e. the system identifier of the second system, together with the service identifier (order number).
In other cases, the service identification and the service may correspond uniquely within a limited range. For example, in a queuing system of a bank, if only one service can be processed by one queuing number in each date, the queuing number uniquely corresponds to the service. If the queuing number is used as the service identifier and the date is used as the time identifier, a service can be uniquely determined by the time identifier and the service identifier. In one embodiment, the time identification may further include a time stamp generated by the service request, and the like.
In more cases, a cross-domain service can be uniquely determined by various reasonable identifiers, which is not described herein again. In summary, these identifiers include at least the service identifier. When the second system sends a query request or a processing request of the cross-domain service to the first system, the identifiers capable of uniquely determining the cross-domain service can be extracted and used as idempotent identifiers. As mentioned earlier, idempotent identities may at least comprise traffic identities. But also includes, but is not limited to, at least one of: a time identification, a system identification of the second system, and so on.
Next, in step 43, the processing state of the cross-domain traffic is determined based on the query for idempotent identification. It will be appreciated that in the case of cross-domain services being processed, the first system may record the idempotent identification and processing state of the cross-domain service, and thus the first system may query the processing state of the cross-domain service with at least the idempotent identification as an index.
In one case, the first system queries the above idempotent flag to indicate that the first system has landed (recorded) the idempotent flag, which indicates that the cross-domain service has been accepted, i.e., the first system at least starts to process the cross-domain service. Meanwhile, the second time of acquiring the processing request by the first system is earlier than the first time of acquiring the query request. At this point, the first system may acquire a processing state corresponding to the idempotent identifier. In one embodiment, the processing status may be processing success. If at the first moment, the first system has successfully processed the cross-domain service, for example, successfully deduct money from the corresponding user account, the first system may obtain the processing state of successful processing according to the idempotent identifier. In another embodiment, the processing status may also be a processing failure. If the first system has already processed the cross-domain service at the first moment, but has not succeeded, for example, for the payment service, the account balance of the corresponding user is less than the payment amount, which results in the failure of deduction, the first system can obtain the processing state of the processing failure according to the idempotent identifier. In yet another embodiment, the processing state may also be in-process. If the first system has already processed the cross-domain service at the first time, but has not yet finished processing, and the processing state corresponding to the idempotent identifier is empty or in process, the first system may acquire the processing state in process according to the idempotent identifier.
It should be noted that there may be various expressions such as processing success, processing failure, processing, and the like, and the embodiments of the present specification do not limit this. For example, the expression of successful treatment may include, but is not limited to: one of a deducted fee, a deducted fee success, a payment success, a processed fee, and the like, the expression of a processing failure may include but is not limited to: one of a non-deduction, a payment failure, an error, etc., the expression in the processing may include but is not limited to: waiting for one of processing, and the like.
In some embodiments, if the processing state is in processing, the second system may further continue to send the same query request to the first system, that is, the sent query request includes the same service identifier, until it is determined that the processing state of the cross-domain service is processing success or processing failure.
In another case, the first system does not query the idempotent identifier, which means that the first system has not fallen to the idempotent identifier, which indicates that the cross-domain service has not been accepted yet, i.e. the first system has not at least started to process the cross-domain service. At this time, the first system may not have received a request for processing the cross-domain service, or may have received a request for processing the cross-domain service, but has not yet started processing. Accordingly, the processing state obtained from the idempotent identification may also be unreceived or unprocessed. In this case, the first system may floor to the idempotent identifier in the query request to indicate that the cross-domain service is being accepted at this time. The first system can record the idempotent identifier of the cross-domain service and determine the processing state of the cross-domain service as a preset state. The preset state is a preset state, which may include but is not limited to one of a processing failure, an unprocessed state, an empty state, and the like. Therefore, even if the subsequent first system acquires the processing request of the cross-domain service again, the first system does not repeatedly accept the cross-domain service because the first system already accepts the cross-domain service. Therefore, the problem that the first system and the second system record different processing states or carry out subsequent flow processing according to different processing states due to the fact that the first system repeatedly accepts the cross-domain service can be effectively avoided.
It is to be understood that the processing states listed above may be various other possible states besides the processing success, processing failure, processing, and the like, such as system failure, processing exception, and the like, which are not illustrated herein.
The processing state corresponding to the idempotent identifier is then sent to the second system as a query result, step 44. In this illustrative embodiment, the first system may feed back the processing state determined in step 43 to the second system as a query result. In some implementations, the first system may also feed back the corresponding processing status for each query, as the second system may continue to send the same query request to the first system. And the query result fed back each time is not necessarily consistent, for example, the first 4 times of feedback are processing, and the 5 th time of feedback is processing success. The second system may not send the query request any more after receiving feedback that the process was successful.
According to one embodiment, the idempotent identification and the processing state of the corresponding cross-domain service by the first system can be recorded by a service idempotent table. The service power table can take power identification as an index and record the processing state of the corresponding cross-domain service.
In the case that the idempotent identifier includes multiple identifiers, when the first system queries the idempotent identifier, a smaller search range may be determined according to one of the identifiers (e.g., the system identifier of the second system), and then the corresponding service identifier may be searched in the range corresponding to the identifier. In this way, the data processing amount of the query process can be reduced.
According to one possible design, after receiving the processing request for the cross-domain service at the second time, the first system may first extract the idempotent identifier from the processing request, and process the processing request according to the idempotent of the idempotent identifier. Specifically, the first system can query the idempotent identification first, according to the idempotent requirements of the processing request. In one case, the second time is earlier than the first time, and the first system may not record the corresponding idempotent identifier and may not query the corresponding idempotent identifier (the cross-domain service has not been accepted). At this time, the first system may record the idempotent flag to indicate the acceptance of the cross-domain service, and then process the cross-domain service to record the processing result of the cross-domain service as the processing state corresponding to the idempotent flag. In another case, the second time is later than the first time, and at this time, the first system already records the idempotent identifier according to the query request, and queries the corresponding idempotent identifier when querying. At this time, the first system may determine that the cross-domain service does not need to be processed (the processing state of the cross-domain service is already determined to be the preset state). It should be noted that, although the expressions "the second time is earlier than the first time" and "the second time is later than the first time" are used herein, the comparison between the first time and the second time by the first system is not meant herein, but is only for convenience of description and understanding. It is easy to understand that the second time is earlier than the first time, and corresponds to a case where the query does not reach the corresponding idempotent identifier, that is, the corresponding cross-domain service has not been accepted when the query request reaches the first system.
In some implementations, the first system may also be a distributed system, and the processing of the processing request and the query request may be performed by different computing devices. For example, the first system may include at least a processing server, a query server, and a storage server. The processing server completes processing of the processing request, the query server completes processing of the query request, and the processing server and the query server are connected with the storage server. The processing server or the query server queries the idempotent identifier from the storage server, and the idempotent identifier recorded by the processing server or the query server is also recorded in the storage server. Alternatively, the processing server may query the idempotent identities of the storage servers by sending a query request to the querying server.
In an embodiment, in step 43, in the case that the query request does not reach the corresponding idempotent identifier, the determined preset state may also be a processing state that is different from the processing state obtained by the first system for normally processing the cross-domain service, so that the second system can perform a subsequent process that is different from the processing state obtained by the first system for normally processing the cross-domain service according to the fed-back query result. For example, a new service identifier is regenerated, and a new cross-domain service processing request is sent again.
Reviewing the above process, through the same idempotent identifier included in the processing request and the query request sent by the second system to the first system, after receiving the query request, the first system queries the idempotent identifier, if the idempotent identifier is not queried, the idempotent identifier is landed (recorded) to indicate that the cross-domain service is accepted, and it is determined that the processing state corresponding to the idempotent identifier is a preset state (for example, processing fails), and then the first system can send the processing state corresponding to the idempotent identifier to the second system as a query result. Therefore, for asynchronous service requests, the method can not be influenced by time sequence confusion caused by networks or equipment, so that the processing state records of the cross-domain service of the two systems in which the cross-domain service occurs are kept consistent. Further, the effectiveness of cross-domain services can be improved.
According to another aspect of the embodiment, a device for processing cross-domain service requests is also provided. The application scenes of the device comprise: aiming at a cross-domain service requested by a second system to a first system, after the second system sends a processing request to the first system, a query request is sent to the first system after a preset time interval so as to query the processing state of the first system to the cross-domain service. Fig. 5 shows a schematic block diagram of a processing device for cross-domain service requests according to one embodiment. The apparatus 500 may be provided in the first system described above.
As shown in fig. 5, the apparatus 500 includes: an obtaining unit 51, configured to receive, at a first time, an inquiry request, where the inquiry request is sent by a second system after a predetermined time interval after sending a processing request, and is used to inquire a processing state of a cross-domain service in the processing request, where the inquiry request includes a service identifier corresponding to the cross-domain service and consistent with the processing request; an extracting unit 52 configured to extract an idempotent identifier of the cross-domain service from the query request, where the idempotent identifier at least includes a service identifier, and the idempotent identifier is at least used for querying and/or recording a processing state of the cross-domain service; the determining unit 53 is configured to determine a processing state of the cross-domain service based on query of the idempotent identifier, wherein the idempotent identifier is recorded and the processing state corresponding to the idempotent identifier is determined to be a preset state under the condition that the idempotent identifier is not queried; the sending unit 54 sends the processing state corresponding to the idempotent identifier to the second system as a query result.
According to an embodiment of an aspect, the determining unit 53 may be further configured to:
and acquiring a processing state corresponding to the idempotent identifier when the idempotent identifier is inquired.
In one possible design, the apparatus 500 further includes a service processing unit (not shown) configured to:
receiving a processing request aiming at the cross-domain service at a second moment, wherein the processing request comprises the idempotent identifier; extracting idempotent identifiers from the processing request; the processing request is processed according to the idempotency of the idempotency identification.
Specifically, the service processing unit may query the idempotent identifier;
on one hand, under the condition that the second moment is earlier than the first moment, the idempotent identifier cannot be inquired, the service processing unit can record the idempotent identifier and process the cross-domain service so as to record the processing result of the cross-domain service as the processing state corresponding to the idempotent identifier;
on the other hand, when the second time is later than the first time, the idempotent identifier is queried, and the service processing unit may determine that the cross-domain service does not need to be processed.
In one embodiment, the idempotent identifier and the processing state of the corresponding cross-domain service are recorded by a service idempotent table, which can be used to record the processing state of the corresponding cross-domain service with the idempotent identifier as an index.
In one embodiment, the service identifier may further include, but is not limited to: at least one of a system identification of the second system, a time identification.
It should be noted that the apparatus 500 shown in fig. 5 is an apparatus embodiment corresponding to the method embodiment shown in fig. 4, and the corresponding description in the method embodiment shown in fig. 4 is also applicable to the apparatus 500, and is not repeated herein.
With the above apparatus, the processing request and the query request which are sent from the second system and include the same service identifier and have the same idempotent identifier can be extracted, the idempotent identifier can be dropped according to the first processed request, and if the query request arrives before the processing request, the processing state corresponding to the idempotent identifier can be dropped (recorded) as a processing failure. Therefore, for asynchronous service requests, the method can not be influenced by time sequence disorder caused by networks or equipment, so that the processing state records of the cross-domain service of two systems in which the cross-domain service occurs are kept consistent, and the effectiveness of the cross-domain service is improved.
According to an embodiment of another aspect, there is also provided a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method described in connection with fig. 4.
According to an embodiment of yet another aspect, there is also provided a computing device comprising a memory and a processor, the memory having stored therein executable code, the processor, when executing the executable code, implementing the method described in connection with fig. 4.
Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.
Claims (14)
1. A processing method for cross-domain service request, the cross-domain service includes the service carried on between the first system and second system; the method is performed by the first system and comprises:
receiving an inquiry request at a first moment, wherein the inquiry request is sent by the second system after a preset time interval after a processing request is sent, and is used for inquiring the processing state of the cross-domain service in the processing request, and the inquiry request comprises a service identifier which is consistent with the processing request and corresponds to the cross-domain service;
extracting idempotent identifications of the cross-domain services from the query request, wherein the idempotent identifications at least comprise the service identifications, and the idempotent identifications are at least used for querying and/or recording processing states of the cross-domain services;
determining a processing state of the cross-domain service based on the query of the idempotent identifier, wherein the idempotent identifier is recorded under the condition that the idempotent identifier is not queried, and the processing state corresponding to the idempotent identifier is determined to be a preset state;
and sending the processing state corresponding to the idempotent identifier as a query result to the second system.
2. The method of claim 1, wherein the determining a processing state of the cross-domain traffic based on the query for the idempotent identification further comprises:
and acquiring a processing state corresponding to the idempotent identifier under the condition that the idempotent identifier is inquired.
3. The method of claim 1, wherein the method further comprises:
at a second moment, receiving the processing request, wherein the processing request comprises the service identifier;
extracting the idempotent identification from the processing request;
and processing the processing request according to the idempotency of the idempotency identification.
4. The method of claim 3, wherein the processing request by the idempotent identified by the idempotent comprises:
querying the idempotent identifiers;
responding to the idempotent identification which cannot be inquired, recording the idempotent identification, and processing the cross-domain service so as to record a processing result of the cross-domain service as a processing state corresponding to the idempotent identification; or
And determining that the cross-domain service does not need to be processed in response to querying the idempotent identifier.
5. The method of claim 1, wherein the idempotent identifier and the processing state of the cross-domain service are correspondingly recorded through a service idempotent table.
6. The method of claim 1, wherein the idempotent identification further comprises at least one of a system identification, a time identification of the second system.
7. A processing device for cross-domain service requests, wherein the cross-domain service comprises a service performed between a first system and a second system; the apparatus is provided in the first system, and includes:
an obtaining unit, configured to receive, at a first time, an inquiry request, where the inquiry request is sent by the second system after a predetermined time interval after sending a processing request, and is used to inquire a processing state of a cross-domain service in the processing request, where the inquiry request includes a service identifier that is consistent with the processing request and corresponds to the cross-domain service;
an extracting unit, configured to extract an idempotent identifier of the cross-domain service from the query request, where the idempotent identifier includes at least the service identifier, and the idempotent identifier is at least used for querying and/or recording a processing state of the cross-domain service;
the determining unit is configured to determine a processing state of the cross-domain service based on query of the idempotent identifier, wherein the idempotent identifier is recorded under the condition that the idempotent identifier is not queried, and the processing state corresponding to the idempotent identifier is determined to be a preset state;
and the sending unit is used for sending the processing state corresponding to the idempotent identifier to the second system as a query result.
8. The apparatus of claim 7, wherein the determining unit is further configured to:
and acquiring a processing state corresponding to the idempotent identifier under the condition that the idempotent identifier is inquired.
9. The apparatus of claim 7, wherein the apparatus further comprises a traffic processing unit configured to:
at a second moment, receiving and acquiring the processing request, wherein the processing request comprises the service identifier;
extracting the idempotent identification from the processing request;
and processing the processing request according to the idempotency of the idempotency identification.
10. The apparatus of claim 9, wherein the traffic processing unit is further configured to:
querying the idempotent identifiers;
responding to the idempotent identification which cannot be inquired, recording the idempotent identification, and processing the cross-domain service so as to record a processing result of the cross-domain service as a processing state corresponding to the idempotent identification; or
And determining that the cross-domain service does not need to be processed in response to querying the idempotent identifier.
11. The apparatus of claim 7, wherein the idempotent identifier and the processing state of the cross-domain service are correspondingly recorded through a service idempotent table.
12. The apparatus of claim 7, wherein the idempotent identification may further comprise at least one of a system identification, a time identification of the second system.
13. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-6.
14. A computing device comprising a memory and a processor, wherein the memory has stored therein executable code that, when executed by the processor, implements the method of any of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811174610.8A CN109491765B (en) | 2018-10-09 | 2018-10-09 | Method and device for processing cross-domain service request |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811174610.8A CN109491765B (en) | 2018-10-09 | 2018-10-09 | Method and device for processing cross-domain service request |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109491765A CN109491765A (en) | 2019-03-19 |
| CN109491765B true CN109491765B (en) | 2021-07-30 |
Family
ID=65690592
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811174610.8A Active CN109491765B (en) | 2018-10-09 | 2018-10-09 | Method and device for processing cross-domain service request |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109491765B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110266799B (en) * | 2019-06-21 | 2022-07-05 | 国网山西省电力公司忻州供电公司 | Method for realizing idempotency based on cache |
| CN110378826A (en) * | 2019-07-23 | 2019-10-25 | 腾讯科技（深圳）有限公司 | Data processing method, device, electronic equipment and computer readable storage medium |
| CN111324778A (en) * | 2020-01-22 | 2020-06-23 | 支付宝实验室(新加坡)有限公司 | Data and service processing method and device and electronic equipment |
| CN113240499A (en) * | 2021-06-08 | 2021-08-10 | 京东数科海益信息科技有限公司 | Order processing method and device based on system switching |
Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102306197A (en) * | 2011-09-22 | 2012-01-04 | 用友软件股份有限公司 | Device and method for guaranteeing consistency of data-source-crossing operation results |
| CN103797751A (en) * | 2012-07-27 | 2014-05-14 | 华为技术有限公司 | Method and device for querying for user online state |
| CN104303149A (en) * | 2012-02-23 | 2015-01-21 | 高通股份有限公司 | Method and system for scheduling requests in a portable computing device |
| CN104423982A (en) * | 2013-08-27 | 2015-03-18 | 阿里巴巴集团控股有限公司 | Request processing method and device |
| CN105988949A (en) * | 2015-02-15 | 2016-10-05 | 阿里巴巴集团控股有限公司 | Terminal equipment and data interactive processing method and system |
| CN106446296A (en) * | 2016-11-28 | 2017-02-22 | 泰康保险集团股份有限公司 | Method for processing trading messages and trading system |
| CN106648936A (en) * | 2016-12-29 | 2017-05-10 | Tcl集团股份有限公司 | Cooperative processing method and system based on microservices and server |
| CN106998344A (en) * | 2016-01-26 | 2017-08-01 | 中兴通讯股份有限公司 | A kind of business operation management method and its device, system |
| US10007566B1 (en) * | 2015-02-19 | 2018-06-26 | Appriver, LLC | Message ordering and idempotency enforcement process |
| US10013283B1 (en) * | 2016-08-15 | 2018-07-03 | Datacore Software Corporation | Methods and apparatus for data request scheduling in performing parallel IO operations |
| CN108449256A (en) * | 2018-02-10 | 2018-08-24 | 深圳壹账通智能科技有限公司 | Processing method, device, computer equipment and the storage medium of message push |
| CN108563693A (en) * | 2018-03-16 | 2018-09-21 | 阿里巴巴集团控股有限公司 | A kind of processing method of affairs, device and equipment |
| CN108596624A (en) * | 2018-03-14 | 2018-09-28 | 阿里巴巴集团控股有限公司 | Handling result, payment result acquisition methods and the device of service request |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9635121B2 (en) * | 2012-08-06 | 2017-04-25 | Paypal, Inc. | Systems and methods for caching HTTP post requests and responses |
| US9940269B2 (en) * | 2016-01-22 | 2018-04-10 | International Business Machines Corporation | Conditionally releasing locks in response to requests |
-
2018
- 2018-10-09 CN CN201811174610.8A patent/CN109491765B/en active Active
Patent Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102306197A (en) * | 2011-09-22 | 2012-01-04 | 用友软件股份有限公司 | Device and method for guaranteeing consistency of data-source-crossing operation results |
| CN104303149A (en) * | 2012-02-23 | 2015-01-21 | 高通股份有限公司 | Method and system for scheduling requests in a portable computing device |
| CN103797751A (en) * | 2012-07-27 | 2014-05-14 | 华为技术有限公司 | Method and device for querying for user online state |
| CN104423982A (en) * | 2013-08-27 | 2015-03-18 | 阿里巴巴集团控股有限公司 | Request processing method and device |
| CN105988949A (en) * | 2015-02-15 | 2016-10-05 | 阿里巴巴集团控股有限公司 | Terminal equipment and data interactive processing method and system |
| US10007566B1 (en) * | 2015-02-19 | 2018-06-26 | Appriver, LLC | Message ordering and idempotency enforcement process |
| CN106998344A (en) * | 2016-01-26 | 2017-08-01 | 中兴通讯股份有限公司 | A kind of business operation management method and its device, system |
| US10013283B1 (en) * | 2016-08-15 | 2018-07-03 | Datacore Software Corporation | Methods and apparatus for data request scheduling in performing parallel IO operations |
| CN106446296A (en) * | 2016-11-28 | 2017-02-22 | 泰康保险集团股份有限公司 | Method for processing trading messages and trading system |
| CN106648936A (en) * | 2016-12-29 | 2017-05-10 | Tcl集团股份有限公司 | Cooperative processing method and system based on microservices and server |
| CN108449256A (en) * | 2018-02-10 | 2018-08-24 | 深圳壹账通智能科技有限公司 | Processing method, device, computer equipment and the storage medium of message push |
| CN108596624A (en) * | 2018-03-14 | 2018-09-28 | 阿里巴巴集团控股有限公司 | Handling result, payment result acquisition methods and the device of service request |
| CN108563693A (en) * | 2018-03-16 | 2018-09-21 | 阿里巴巴集团控股有限公司 | A kind of processing method of affairs, device and equipment |
Non-Patent Citations (2)
| Title |
|---|
| Distributed dynamic programming for discrete-time stochastic control, and idempotent algorithms;William M. McEneaney;《Automatica》;20100615;全文 * |
| 基于消息通信的分布式系统最终一致性平台;徐进等;《计算机应用》;20170417;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109491765A (en) | 2019-03-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109491765B (en) | Method and device for processing cross-domain service request | |
| CN109949111B (en) | Electronic bill identification distribution method, electronic bill generation method, device and system | |
| CN109614209B (en) | Task processing method, application server and system | |
| CN109542980B (en) | Data processing method, device, equipment and medium for block chain | |
| EP3816910A1 (en) | Blockchain-based transaction processing method and apparatus, and electronic device | |
| US7694178B2 (en) | Method, apparatus and computer program product for transaction recovery | |
| CN110289999B (en) | Data processing method, system and device | |
| CN110910230A (en) | Accounting method, accounting system and storage medium | |
| EP3816912A1 (en) | Blockchain-based transaction processing method and apparatus, and electronic device | |
| US20140156785A1 (en) | Method and Apparatus for Generating User Notifications | |
| EP3552167B1 (en) | Utilizing nonce table to resolve concurrent blockchain transaction failure | |
| CN106096926B (en) | Event processing method, device, electronic device and storage medium | |
| CN108596587B (en) | Cash-up auditing method, apparatus, electronic device, program product and storage medium | |
| CN111127181A (en) | Voucher bookkeeping method and device | |
| CN113112344B (en) | Service processing method, device, storage medium and computer program product | |
| CN113360210A (en) | Data reconciliation method and device, computer equipment and storage medium | |
| CN113626218A (en) | Data processing method, data processing device, storage medium and computer equipment | |
| CN113052587A (en) | Transfer service processing method and device based on block chain | |
| CN111125168B (en) | Data processing method and device, electronic equipment and storage medium | |
| CN110297824B (en) | Data recording method, device, equipment and storage medium based on resource transfer | |
| CN106570685B (en) | Service processing method and device | |
| CN111367694B (en) | Event processing method, server and computer storage medium | |
| CN109347940B (en) | Method and device for processing cross-domain service request and request for cross-domain service | |
| CN115422184A (en) | Data acquisition method, device, equipment and storage medium | |
| CN111695901A (en) | Accounting voucher processing method, device, equipment 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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20201010 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20201010 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |