Microservice distributed transaction control method

Abstract

To provide a microservice distributed transaction control method enabling an external service that can cooperate to be extended more than before according to functionality of the external service.SOLUTION: An external service 131 is classified into a plurality of types according to a difference in how a function related to a trial request is provided, and executed the steps of: identifying a type of the cooperating external service 131 from a description of an external service cooperation processing designation 132; selecting a transaction control section adapted to a type of the cooperating external service 131 from a plurality of transaction control section 111 to 114 individually adapted to the plurality of types of the external service 131; executing transaction control between the microservice 104 and the cooperating external service 131 by applying the selected transaction control section.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a microservice distributed transaction control method. [Background technology]

[0002] In recent years, a design improvement technique called system modernization has been gaining importance. As part of system modernization, there is a technique for decomposing the functions of monolithic legacy systems into microservices that run on the cloud and operate them in a distributed manner.

[0003] In a modernized system, various functions are distributed across individual microservices that interact with each other. For example, business logic and RDBMS that previously ran on application servers are now microservices. Data stores such as data lakes are also targets for microservice conversion. Furthermore, external services that run on external web servers and are accessed via REST APIs, for example, also interact with each other as individual microservices.

[0004] Meanwhile, maintaining consistency of processing among multiple microservices operated in a distributed manner has been recognized as a new technical challenge. To address this issue, microservice execution platforms require a function to control distributed transactions. One such function is known as TCC (Try-Confirm / Cancel). TCC controls distributed transactions using a transaction coordinator. TCC also ensures atomicity of transactions by assuming that each microservice, including external services, has three functions: Try, Confirm, and Cancel. Try is the phase in which business processing (which generally involves updating the state) is tentatively executed. Confirm is the phase in which the results of this tentative execution are finalized. Cancel is the phase in which the tentative execution is canceled. Major microservice execution platforms support distributed transaction control among microservices according to the TCC design style.

[0005] Patent documents 1 to 3 disclose distributed transaction control between microservices.

[0006] In the technology disclosed in Patent Document 1, an orchestrator manages the overall processing flow of business logic. The orchestrator stores commands to each microservice and the execution result data as snapshots. If a command to one or more microservices fails, the orchestrator uses the snapshot data to recover each microservice. In this way, the orchestrator guarantees the eventual consistency of transactions. Here, "eventual consistency" means that although there may be periods of inconsistency, the state will eventually settle into a consistent state over time.

[0007] Furthermore, the technology disclosed in Patent Document 2 provides a channel for compensation processing (state update rollback processing) based on the messaging (Pub-Sub: Publish-Subscribe) relationship between microservices. Furthermore, in the technology described in Patent Document 2, the execution results of each microservice are reported via the same channel using aspect orientation. The technology described in Patent Document 2 also guarantees transaction result consistency by retrying compensation processing, assuming message idempotence. Here, "idempotence" refers to the property of obtaining the same result even if the same message is sent multiple times.

[0008] Furthermore, the technology disclosed in Patent Document 3 adopts an optimistic concurrency control method, assuming that the transaction control target is a CRUD-type data store. The optimistic concurrency control library links to the sub-business logic executed on each microservice. The optimistic concurrency control library also stores request parameters as snapshots for each read / write request to the data store. The optimistic concurrency control library then ensures strong consistency by updating the contents of the data store based on the snapshots when the transaction is settled. Here, "strong consistency" means that inconsistent periods cannot be observed externally and do not adversely affect the execution of other transactions running simultaneously. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] Chinese Patent Application Publication No. 110502319 [Patent Document 2] Chinese Patent Application Publication No. 113900840 [Patent Document 3] International Publication No. 2023 / 033153 Summary of the Invention [Problem to be solved by the invention]

[0010] The technologies described in Patent Documents 1 and 2 are based on the premise that all microservices, including external services, are equipped with all of the functions of Try, Confirm, and Cancel. Therefore, application to external services that are generally unmodifiable and lack any of the functions of Try, Confirm, or Cancel is not taken into consideration. Furthermore, even if the technologies described in Patent Documents 1 and 2 are applicable to external services that lack some of the above functions, the guarantee of strong consistency is not taken into consideration.

[0011] Furthermore, the technology described in Patent Document 3 assumes that the control target of a distributed transaction is a CRUD-type data store, and that it is operated only via read / write requests. For this reason, the technology described in Patent Document 3 does not take into consideration external services, whose functional specifications are generally defined in the form of a REST API, as the control target of a distributed transaction. In other words, the technologies described in Patent Documents 1 to 3 have the disadvantage of limiting the external services that can be linked in distributed transaction control of microservices.

[0012] The present invention has been made in consideration of the above circumstances, and its purpose is to provide a microservice distributed transaction control method that expands the number of external services that can be linked to more than ever before, depending on the functionality of the external services. [Means for solving the problem]

[0013] To solve the above problem, the present invention provides a microservice distributed transaction control method for controlling a microservice and an external service that is linked to the microservice, and includes the following steps (a) to (c) executed by a computer. (a) classifying external services into a plurality of types according to differences in how they have functions related to try requests; (b) identifying the type of external service to be linked from the description of the external service linkage process specification; (c) selecting a transaction control unit that is suited to the type of external service to be linked from a plurality of transaction control units that are individually suited to a plurality of types of external services; (d) applying the selected transaction control unit to execute transaction control between the microservice and the linked external service; [Effects of the Invention]

[0014] According to the present invention, it is possible to provide a microservice distributed transaction control method that expands the number of external services that can be linked with compared to conventional methods, depending on the functionality of the external services. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a block diagram illustrating an example of the configuration of a business system according to an embodiment of the present invention. [Figure 2] 10 is a flowchart showing a selection operation of a transaction control unit shown in FIG. [Figure 3] 2 is a block diagram showing the relationship between the business system, external service cooperation processing designation, and external service classifier shown in FIG. 1. FIG. [Figure 4] 2 is a flowchart showing the operation of the transaction control unit (confirmable type) shown in FIG. [Figure 5] 2 is a flowchart showing the operation of the transaction control unit (backward calculation type) shown in FIG. [Figure 6] 2 is a flowchart showing the operation of the transaction control unit (delayable type) shown in FIG. [Figure 7] 2 is a flowchart showing the operation of the transaction control unit (irrevocable type) shown in FIG. [Figure 8] 2 is a data structure diagram showing an example of data stored in a request information management unit shown in FIG. 1. FIG. [Figure 9]2 is a data structure diagram illustrating an example of data stored in a concurrency control unit illustrated in FIG. 1. FIG. [Figure 10] FIG. 2 is a block diagram showing an example of a business system to which the embodiment of FIG. 1 is applied. [Figure 11] 2 is a program configuration diagram showing an example of an external service cooperation process specification shown in FIG. 1. FIG. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, an embodiment of the present invention (hereinafter referred to as "the present embodiment") will be described with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and redundant explanations will be omitted.

[0017] FIG. 1 is a block diagram showing an example of the configuration of a business system according to this embodiment. 1, the business system according to this embodiment includes a transaction coordinator 101 and an orchestrator 102. The business system also includes multiple microservices 104 and 106. Furthermore, the business system cooperates with external services 131 and 133.

[0018] Of these, the transaction coordinator 101 directs transactions that are distributed and executed by multiple microservices 104 and 106. The orchestrator 102 accepts service requests from clients (not shown) and executes business logic corresponding to the service. The business logic defines the overall business flow of the service requested by the client. The microservices 104 and 106 execute sub-business logic that corresponds to partial processing of the business logic. The external services 131 and 133 operate in conjunction with each sub-business logic.

[0019] The orchestrator 102 includes a business logic execution unit 103 that executes business logic. The microservices 104 and 106 include sub-business logic execution units 105 and 107 that execute sub-business logic, respectively.

[0020] The business logic execution unit 103 makes a remote call to the sub-business logic execution units 105 and 107 to realize the processing of the entire business flow. The sub-business logic execution units 105 and 107 involve cooperation with external services 131 and 133. For this reason, the sub-business logic execution units 105 and 107 issue a remote call (hereinafter referred to as a "try request") to the external services 131 and 133 within the sub-business logic. At this time, the external service cooperation processing execution units 110 and 120 mediate the try request from the sub-business logic execution units 105 and 107 to the external services 131 and 133 while executing control related to the transaction.

[0021] Here, among the multiple external services 131, 133, some external services 131 (133) may fail to process the try request. In this case, the external service cooperation processing execution units 110, 120 need to maintain the consistency of transactions between microservices including the external services 131, 133. Therefore, for all external services 133 (131) that have successfully processed the try request, the transaction control units 121 to 124 (111 to 114) execute control to return them to the state before the try request was processed.

[0022] Here, the failure of the try request includes an invalid request to the external service 131 (133). For example, this may occur when tickets are sold out for a ticket issuing service. The failure of the try request also includes a malfunction of the external service 131 (133). For example, this may occur when the ticket issuing service is inaccessible due to overload or a malfunction.

[0023] In this embodiment, there are four types of transaction control units 111 to 114 and 121 to 124. First, the details of the four types will be explained.

[0024] When the business logic execution unit 103 has completed all the business logic corresponding to the service request received from the client, it notifies the transaction coordinator 101 of the timing of the completion. Upon receiving this notification, the transaction coordinator 101 instructs the external service cooperation processing execution units 110 and 120 to conclude the transaction (issues a conclusion instruction).

[0025] Prior to issuing a settlement instruction, the transaction coordinator 101 tallies whether each try request to the external services 131 and 133 was successful or failed via the external service cooperation processing execution units 110 and 120. If the result of this talliation indicates that all try requests are successful, the transaction coordinator 101 issues a settlement instruction of Confirm (confirmation request). On the other hand, if even one try request fails, the transaction coordinator 101 issues a settlement instruction of Cancel (cancellation request).

[0026] Here, the external services 131 and 133 do not necessarily have functions corresponding to confirmation requests and cancellation requests. In this embodiment, the external services are classified to correspond to different functionalities of the external services. That is, in this embodiment, the external services 131 and 133 are classified into the following four types based on how they have functions related to try requests.

[0027] [Confirmable type]: An external service that accepts both cancellation and confirmation requests. [Reverse Computable Type]: An external service that exposes a request that has the effect of canceling side effects in the external service that occur when a try request is executed. Here, "side effects" refer to effects that occur on the state of an external service. For example, in account balance management, a request to withdraw money has side effects because it changes the account balance. On the other hand, a request to check the balance does not have side effects because it does not affect the account balance. [Deferable]: An external service that can postpone the execution of a try request until the transaction is resolved. [Irrevocable]: External services that do not fall into any of the above three types.

[0028] The microservices 104 and 106 include transaction control units (confirmable type) 111 and 121, transaction control units (backcalculatable type) 112 and 122, transaction control units (delayable type) 113 and 123, and transaction control units (irrevocable type) 114 and 124, respectively.

[0029] The external service cooperation processing execution units 110 and 120 select the transaction control units 111-114 and 121-124 to use according to the type of the external service. Then, the external service cooperation processing execution units 110 and 120 use the selected transaction control unit to issue a predetermined request to the external services 131 and 133 via the external request issue units 117 and 127.

[0030] The microservices 104 and 106 also include request information management units 116 and 126 and concurrency control units 115 and 125, respectively. The request information management units 116 and 126 hold information (request arguments) required when issuing requests to the external services 131 and 133. The requests are cancellation requests, confirmed requests, or postponed try requests.

[0031] The arguments of the request are temporarily held until the transaction is settled. In addition, concurrency control units 115 and 125 perform control to ensure the isolation of transactions. Each transaction control unit 111 to 114 and 121 to 124 shares the request information management units 116 and 126 and the concurrency control units 115 and 125.

[0032] The external service cooperation processing execution units 110, 120 select and use the applicable transaction control units 111-114, 121-124 based on the external service cooperation processing specifications 132, 134. The external service cooperation processing specifications 132, 134 include an external API type specification 141, a concurrency control specification 142, an external cooperation processing specification 143, a cancellation processing specification 144, and a confirmation processing specification 145.

[0033] The external API type specification 141 specifies the type (one of the above four types) of the external services 131, 133. The concurrency control specification 142 specifies information necessary for control by the concurrency control units 115, 125. The external cooperation processing specification 143 defines the method for issuing a try request. The cancellation processing specification 144 defines the method for issuing a cancellation request. The confirmation processing specification 145 defines the method for issuing a confirmation request.

[0034] The concurrency control specification 142 specifies an identifier that identifies the processing target of the try request among the resources managed by the external services 131 and 133. The identifier is specified from available data among the arguments of the try request. The concurrency control units 115 and 125 use the identifier as a lock key to perform exclusive control when multiple try requests are issued simultaneously. In this way, the concurrency control units 115 and 125 guarantee transaction isolation.

[0035] 2, the external service cooperation processing execution units 110, 120 identify the types of the external services 131, 133 to be cooperated with from the description of the external API type specification 141 (S101). Furthermore, the external service cooperation processing execution units 110, 120 select a transaction control unit that matches the type of the external services 131, 133 to be cooperated with from the above-mentioned multiple transaction control units 111-114, 121-124 (S102). Then, the external service cooperation processing execution units 110, 120 apply the selected transaction control unit to execute transaction control between the external services 131, 133 to be cooperated with (S103).

[0036] FIG. 3 shows the relationship between the external service cooperation process specification 132, the external service classifier 202 that automates part of the definition, and the configuration of the business system.

[0037] The external service classifier 202 automatically generates the external API type specification 141, the cancellation processing specification 144, and the confirmation processing specification 145. Of these, the cancellation processing specification 144 and the confirmation processing specification 145 are automatically generated as needed. The external service classifier 202 uses the definition of the external collaboration process specification 143 and external service function specification information 201 as inputs for automatic generation. The external service function specification information 201 is specification information of requests published by the external service 131. The specification information includes, for example, the URI of the REST API of each request, the JSON structure that serves as an argument of the request, and field names.

[0038] The external API type specification 141, cancellation process specification 144, and confirmation process specification 145 can be automatically generated by mechanically inferring the behavior of the try request, and the existence and behavior of cancellation requests and confirmation requests corresponding to the try request. This mechanical inference can be made based on the last character string of the URI of the try request issued based on the external collaboration process specification 143, the structure of the JSON argument, and the field name. The last character string of the URI of the try request generally contains the request name.

[0039] Although this embodiment is not limited by the procedure of machine inference, an example is shown below. The external service classifier 202 determines the external API type designation 141 based on publicly available external service function specification information 201. If the determination result is a confirmable type or a reverse-calculatable type, the external service classifier 202 generates a cancellation processing specification 144 based on the external service function specification information 201. Furthermore, if the determination result is a confirmable type, the external service classifier 202 generates a confirmation processing specification 145 based on the external service function specification information 201.

[0040] To give a further specific example, the external service function specification information 201 may include information on whether or not a cancellation function is available for a try request. Furthermore, the external service function specification information 201 may include information on whether or not a function is available to cancel side effects caused by the execution of a try request. If the external service to be judged has a cancellation function, the external service classifier 202 can determine that the external service is a verifiable external service. Furthermore, if the external service to be judged has a function to cancel side effects, the external service classifier 202 can determine that the external service is a reverse-calculatable external service.

[0041] Furthermore, because the external service function specification information 201 describes the specifications for the cancellation process, the external service classifier 202 generates the cancellation process specification 144. Furthermore, because the external service function specification information 201 describes the specifications for the confirmation process, the external service classifier 202 generates the confirmation process specification 145. In this way, the external service classifier 202 can automatically generate the external API type specification 141, the cancellation process specification 144, and the confirmation process specification 145.

[0042] 3 does not illustrate the transaction control units 111 to 114, the concurrency control unit 115, and the request information management unit 116. Also, while Fig. 3 shows a pair of microservice 104 and external service cooperation processing specification 132, other pairs of microservice 106 and external service cooperation processing specification 134 can also be configured in the same way.

[0043] 4 is a flowchart showing the operation of the transaction control unit (confirmable type) 111. Below, the operation will be explained for one microservice 104, but it is the same for the other microservices 106. Furthermore, the "transaction control unit (confirmable type) 111" will be abbreviated as "transaction control unit 111" as appropriate.

[0044] The transaction control unit 111 first receives an external collaboration processing request from the sub-business logic execution unit 105 (S301). The external collaboration processing request requests that a try request be issued to the external service 131 in accordance with the external collaboration processing specification 143.

[0045] At this time, the transaction control unit 111 stores the parameters of the external collaboration processing request (arguments of the try request: JSON data, etc.) in the request information management unit 116 (S302). In addition, the transaction control unit 111 instructs the concurrency control unit 115 to perform exclusive control based on the lock key defined in the concurrency control specification 142 (S303).

[0046] If the lock for this exclusive control is successful (YES in S304), the transaction control unit 111 issues a try request to the external service 131 using the parameters of the external cooperation processing request (S305). The transaction control unit 111 also stores the return of the try request in the request information management unit 116 (S306). Furthermore, the transaction control unit 111 notifies the transaction coordinator 101 of the success or failure of the try request (S307).

[0047] When the business logic processing is completed and the transaction moves to the transaction settlement phase, the transaction control unit 111 receives a settlement instruction from the transaction coordinator 101 (S308). If the settlement instruction received in step S308 is Confirm (YES in S309), the transaction control unit 111 issues a confirmation request to the external service 131 in accordance with the confirmation processing specification 145 (S310). On the other hand, if the instruction is not Confirm in step S309 (NO in S309), the transaction control unit 111 issues a cancellation request to the external service 131 in accordance with the cancellation processing specification 144 (S311).

[0048] Finally, the transaction control unit 111 causes the concurrency control unit 115 to release the lock due to the exclusive control instructed in step S303 (S312).Then, the transaction control unit 111 deletes the information held in the request information management unit 116 (S313) and ends the transaction.

[0049] On the other hand, if the locking is not successful in step S304 (NO in S304), the process immediately proceeds to step S313, where the transaction ends. As a modified example, steps S303 and S304 may be repeated until the locking is successful in step S304.

[0050] 5 is a flowchart showing the operation of the transaction control unit (backward calculation type) 112. Below, the operation will be explained for one microservice 104, but it is the same for the other microservices 106. Furthermore, the "transaction control unit (backward calculation type) 112" will be abbreviated as "transaction control unit 112" as appropriate.

[0051] 5, the operations of steps S301 to S309, S312, and S313 are the same as those explained in FIG. 4, so duplicate explanations will be omitted. If the answer is Confirm in step S309 (YES in S309), the process proceeds directly to step S312. On the other hand, if the answer is Cancel in step S309 (NO in S309), the transaction control unit 112 issues a cancellation request to the external service 131 in accordance with the cancellation processing specification 144 (S401). This cancellation request is a request that has the effect of canceling the side effects of the corresponding try request.

[0052] 6 is a flowchart showing the operation of the transaction control unit (delayable type) 113. Below, the operation will be explained for one microservice 104, but it is the same for the other microservices 106. Furthermore, the "transaction control unit (delayable type) 113" will be abbreviated as "transaction control unit 113" as appropriate.

[0053] In Figure 6, the operations of steps S301 to S309, S312, and S313 are the same as those described in Figure 4, so duplicated explanations will be omitted. However, the processes corresponding to steps S305 and S306 in Figure 4 are not executed. Furthermore, in the process corresponding to step S307 in Figure 4, transaction control unit 113 notifies transaction coordinator 101, as a provisional process, that the try request has been successful.

[0054] If the answer is Confirm in step S309 (YES in S309), the transaction control unit 113 issues a try request to the external service 131 using the parameters of the external cooperation processing request held in step S302 as arguments (S501).On the other hand, if the answer is Cancel (NO in S309), the transaction control unit 113 proceeds directly to step S312.

[0055] 7 is a flowchart showing the operation of the transaction control unit (irrevocable type) 114. Below, the operation will be explained for one microservice 104, but it is the same for the other microservices 106. Furthermore, the "transaction control unit (irrevocable type) 114" will be abbreviated as "transaction control unit 114" as appropriate.

[0056] In Fig. 7, the operations of steps S301 to S308, S312, and S313 are the same as those described in Fig. 4, and therefore redundant description will be omitted. However, transaction control unit 114 does not execute the process corresponding to step S306 in Fig. 4. Furthermore, transaction control unit 114 does not execute the processes at the time of transaction settlement corresponding to steps S309 to S311 in Fig. 4.

[0057] Next, an example of the operation of the business system will be described with reference to FIGS. The business system shown in Fig. 10 is a system that provides a tour travel reservation service to coincide with an event. A travel reservation service 901 serving as an orchestrator 102 receives a request for a tour travel reservation from a client (not shown). In this embodiment, four microservices 919 to 949 cooperate with four external services 951 to 954, respectively. The travel reservation service 901 allocates the tour travel reservation process requested by the client to each of the microservices 919 to 949 and has them process the reservation.

[0058] Each of the microservices 919 to 949 cooperates with external services, such as a tour planning site 951, a sea route reservation system 952, a hotel reservation site 953, and a financial institution system 954. The processes shared by each of the microservices 919 to 949 are executed by a tour reservation processing execution unit 918, a sea route reservation processing execution unit 928, a hotel reservation processing execution unit 938, and a payment processing execution unit 948, which are sub-business logic execution units, respectively.

[0059] The sub-business logic execution units 918, 928, 938, and 948 cooperate with external services 951, 952, 953, and 954, respectively, via the external service cooperation processing execution units 910, 920, 930, and 940, the transaction control units 913, 914, 921, 932, and 943, and the external request issuing units 917, 927, 937, and 947.

[0060] Fig. 8 shows an example of data held by a request information management unit (not shown in Fig. 10) in the business system of Fig. 10. Fig. 8(a) shows a data structure 701 held by a request information management unit corresponding to the external service collaboration processing execution unit 910. Fig. 8(b) shows a data structure 702 held by a request information management unit corresponding to the external service collaboration processing execution unit 920. Fig. 8(c) shows a data structure 703 held by a request information management unit corresponding to the external service collaboration processing execution unit 930. Fig. 8(d) shows a data structure 704 held by a request information management unit corresponding to the external service collaboration processing execution unit 940.

[0061] In the example of data structures 701 to 704, it is assumed that a transaction with a transaction identifier (transaction ID) of "XID:1212" and a transaction with a transaction identifier (transaction ID) of "XID:1213" are processed almost simultaneously in parallel. However, it is assumed that "XID:1212" was issued slightly earlier. Here, it is assumed that the transactions with "XID:1212" and "XID:1213" correspond to tour participation requests from customer A and customer B, respectively.

[0062] The data structure 701 represents information held by the request information management unit in cooperation with the tour planning site 951. The request parameters on the first line represent a request from customer A to inquire (op:check) whether three people can attend an event to be held on April 28, 2024. The request parameters on the second line represent a request to make a reservation (op:reserve) based on the inquiry result ("available:true" on the first line, i.e., participation is possible). The request parameters on the third line represent a request from customer B to inquire whether two people can attend on the same day.

[0063] Also, the request return on the first line indicates that participation is possible, as described above. The request return on the second line " <deferred>" indicates that the tour planning site 951 as an external service is a delayable type, and therefore the issuance of the request is postponed until the transaction is settled. Also, the third line (blank) of the request return indicates that the request return has not yet been received. Here, if the participants are filled with customer A's request, the request return on the third line will be "available:false", meaning that participation is not possible. In that case, the reservation (op:reserve) request will not be issued.

[0064] The data structure 702 represents information held by the request information management unit in cooperation with the route reservation system 952. The request parameters in the first line represent a route reservation for customer A on the day before an event. The request parameters in the second line represent a reservation for customer B. The request parameters include the flight number, date, seat class, and number of passengers. The request return indicates the value of the reserved seat number for each request.

[0065] Data structure 703 represents information held by the request information management unit in cooperation with the hotel reservation site 953. The request parameters on the first line represent a two-night hotel reservation for customer A, starting the day before an event. The request parameters on the second line represent a reservation for customer B. Each request parameter includes the name of the accommodation facility, the date, the number of nights of stay, and the room grade. The request return indicates that both reservations have been made for each request.

[0066] Data structure 704 represents information held by the request information management unit in cooperation with financial institution system 954. The request parameters on the first line represent a payment request for customer A. The request parameters on the second line represent a payment request for customer B. Each request parameter includes the bank code, branch code, account number, transaction, and amount. The request return indicates that both requests are postponed until the transaction is settled.

[0067] These requests can be executed independently by each external service 951-954. However, if the execution of one of them fails, the other external services (which executed successfully) must also be treated as not having been executed. For example, if the request return value in the third line of data structure 701 is "available:false," that is, if customer B is unavailable at tour planning site 951, it is necessary to treat the requests issued to the other external services 952, 953, and 954 for customer B as not having been issued. Therefore, when the transaction for "XID:1213" is settled, a cancellation request is issued to the confirmable and reverse-calculatable external services. Furthermore, for the deferrable external services, the requests whose execution has been postponed are simply discarded.

[0068] Fig. 9 shows an example of data held by a concurrency control unit (not shown) in the business system of Fig. 10. Fig. 9(a) shows a data structure 801 held by a concurrency control unit corresponding to the external service cooperation processing execution unit 910. Fig. 9(b) shows a data structure 802 held by a concurrency control unit corresponding to the external service cooperation processing execution unit 920. Fig. 9(c) shows a data structure 803 held by a concurrency control unit corresponding to the external service cooperation processing execution unit 930. Fig. 9(d) shows a data structure 804 held by a concurrency control unit corresponding to the external service cooperation processing execution unit 940. In each of the data structures 801 to 804, the request target specification key (lock key) cannot store two or more identical values.

[0069] Data structure 801 represents a lock key used by the concurrency control unit to perform exclusive control in cooperation with tour planning site 951. Until customer A's participation in an event to be held on April 28, 2024 is confirmed, it is necessary to prevent other customers from participating in the event on the same day. For this reason, data structure 801 stores date information as a lock key. As shown in Figure 8(a), customer B has also requested participation in the event on the same day. However, because the request target specification key in the first line of data structure 801 matches the date, customer B's transaction ID cannot be added to data structure 801. As a result, the execution of the transaction "XID:1213" related to customer B is prevented.

[0070] On the other hand, the transaction ID "XID:1212" for customer A is recorded in data structure 801. The same transaction ID "XID:1212" is also used for the reservation process (op:reserve) after inquiring about participation in Figure 8(a), so that reservation process can be executed.

[0071] Data structure 802 represents the lock key used by the concurrency control unit to perform exclusive control in cooperation with the route reservation system 952. The request target specification key in the first line is the lock key for the route reservation for customer A. The request target specification key in the second line indicates the lock key for the reservation for customer B. The lock key is a combination of flight number, date, and seat class. Since customers A and B reserve different classes, both entries can be added to data structure 802. This allows the transactions of both customers to be carried out without mutual inhibition.

[0072] Data structure 803 represents the lock key used by the concurrency control unit to perform exclusive control in cooperation with hotel reservation site 953. The request target specification key on lines 1 and 2 is the lock key for customer A's hotel reservation. The request target specification key on lines 3 and 4 indicates the lock key for customer B's hotel reservation. The lock key is a combination of the accommodation facility name, date, and room grade. Since customer A and customer B reserve different accommodation facilities and grades, both entries can be added to data structure 803. This allows the transactions of both customers to be carried out without mutual inhibition.

[0073] Data structure 804 represents the lock key used by the concurrency control unit to perform exclusive control in cooperation with financial institution system 954. The request target specification key on the first line is the lock key for customer A's withdrawal. The request target specification key on the second line indicates the lock key for customer B's withdrawal. The lock key is a combination of the bank code, branch code, and account number. Since customer A and customer B have different accounts, both entries can be added to data structure 804. This allows the transactions of both customers to be executed without mutual inhibition. As described above, the concurrency control unit operates using data structures 801 to 804 so that each exclusive control is performed.

[0074] Here, the participation inquiry (op:check) to the tour planning site 951 is a reference-only process, and therefore does not include a cancellation request or a confirmation request. Furthermore, the result of this inquiry is used by the sub-business logic execution unit 918, and therefore it is not postponeable. Therefore, for participation inquiries, the irrevocable transaction control unit 914 is used. On the other hand, for reservation processing (op:reserve), even if participation in an event once reserved cannot be canceled, it is possible to determine in advance whether the reservation is possible or not from the result of the above-mentioned participation inquiry. For this reason, it is possible to postpone the execution of the reservation processing until the transaction is settled. Therefore, for reservation processing, the delayable transaction control unit 913 is used.

[0075] Furthermore, for the route reservation system 952, the phases for tentative reservation and reservation confirmation are separate, so a confirmation-enabled transaction control unit 921 is used. For the hotel reservation site 953, while the contract is finalized at the time of reservation, cancellation is possible before the stay, so a back-calculation-enabled transaction control unit 932 is used. For the financial institution system 954, payment only needs to be made when the transaction is finally settled to Confirm, so a delay-enabled transaction control unit 943 is used. As described above, the external service collaboration processing specification 132 corresponding to each microservice 919 to 949 is written so that a suitable transaction control unit can be selected.

[0076] Text information 1001 in Fig. 11 represents an example of the external service collaboration process specification 132 corresponding to the business system in Fig. 10. This text information 1001 is a program written in Java (registered trademark). The example in Fig. 11 shows the external service collaboration process specification 132 corresponding to the microservice 939 (hotel reservation process execution unit 938).

[0077] The specification of the inheriting class on line 02 corresponds to the external API type specification 141. In this example, a backward calculation type transaction control unit 932 is specified. Furthermore, the definition of the executeTry method on lines 8 to 15 corresponds to the external linkage processing specification 143. The annotation on line 7 added to the same method corresponds to the concurrency control specification 142.

[0078] In this example, it is defined that the lock key is a combination of the values ​​of the hotel, date, and room fields of the request parameter of the external linkage processing specification 143. The definition of the executeCancel method on lines 23 to 29 corresponds to the cancellation processing specification 144. The definition of the executeConfirm method on lines 18 to 20 corresponds to the confirmation processing specification 145. However, in this example, the external API type specification 141 specifies a back-calculatable type, so the confirmation processing specification 145 is not necessary. For this reason, the confirmation processing specification 145 is commented out.

[0079] Finally, the operations of the transaction coordinator 101, orchestrator 102, and microservices 104 and 106, including their internal components, are realized by a computer executing a predetermined program. The external service collaboration processing specification 132, the data structures 701-704 held by the request information management units 116 and 126, and the data structures 801-804 held by the concurrency control units 115 and 125 are stored in a storage area of ​​a storage device. The above programs may be distributed among multiple computers. The above storage areas may be distributed among multiple storage devices. The distributed computers and storage devices may be linked via a communication device and a computer network. The same applies to the business system shown in FIG. 10.

[0080] According to the present embodiment described above, external services are classified into multiple types according to the differences in how they are equipped with functions related to try requests, and a transaction control unit that matches the type of external service is selected and applied, thereby expanding the types of external services that can be linked compared to conventional methods.

[0081] In addition, since the type of external service to be linked is identified from the description of the external service linkage processing specification, linking with a new external service can be accommodated by simply changing the description of the external service linkage processing specification, thereby reducing the development effort required for linking with external services.

[0082] In addition, the information required when issuing cancellation requests and confirmation requests to external services is temporarily stored in the request information management unit until the transaction is completed, making it possible to ensure strong consistency in distributed transaction control even between microservices that work with different types of external services.

[0083] Furthermore, exclusive control between transactions is performed using an identifier that identifies the target of transaction control as a lock key, ensuring strong consistency of distributed transaction control between microservices that work with different types of external services.

[0084] In addition, the transaction control unit is available in four types: a confirmable type, a back-calculatable type, a deferrable type, and an irrevocable type that does not fall into any of the above categories, making it possible to link with any type of external service.

[0085] In addition, since the external service integration processing specification includes descriptions of the external API type specification, concurrency control specification, external integration processing specification, cancellation processing specification, and confirmation processing specification, not only can the transaction control unit to be used be specified, but the operation of the concurrency control unit, etc. can also be set by changing the description of the external service integration processing specification.

[0086] Furthermore, since it has the function of automatically generating external service integration processing specifications based on the functional specification information of the external service, the development effort required when integrating with a new external service can be further reduced compared to manually setting the external service integration processing specifications.

[0087] As described above, this embodiment enables modernization of systems that require collaboration with external services to enable collaboration with a variety of external services, including those that do not comply with the TCC design style. Furthermore, it also makes it possible to build distributed transactions that guarantee strong consistency while minimizing development efforts.

[0088] The present invention is not limited to the above-described embodiment, and it goes without saying that various other applications and modifications are possible without departing from the gist of the present invention as set forth in the claims. For example, the above-described embodiment has described the system configuration in detail and specifically to clearly explain the present invention, and is not necessarily limited to a system including all of the described configurations. Furthermore, it is also possible to add, delete, or replace part of the configuration of the present embodiment with other configurations. In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected.

[0089] For example, multiple components located within a single microservice of this embodiment may all run on a single computer, or may run on multiple different computers. Furthermore, multiple transaction control units running on two or more different computers may be connected to a single concurrency control unit. Similarly, multiple transaction control units running on two or more different computers may be connected to a single request information management unit. Furthermore, the orchestrator and transaction coordinator may run on a single computer as a single component that combines the functions of both. Furthermore, in the above embodiment, a configuration has been shown in which one microservice 104 cooperates with one external service 131, but one microservice 104 may also be configured to cooperate with multiple external services. When one microservice 104 cooperates with n external services, it is preferable to provide n sets of the external service cooperation processing execution unit 110, transaction control units 111 to 114, concurrency control unit 115, request information management unit 116, and external request issue unit 117. [Explanation of symbols]

[0090] 101...Transaction coordinator, 102...Orchestrator, 103...Business logic execution unit, 104, 106, 919, 929, 939, 949...Microservices, 105, 107...Sub-business logic execution unit, 110, 120, 910, 920, 930, 940...External service collaboration processing execution unit, 111, 121, 921...Transaction control unit (confirmable type), 112, 122, 932... Transaction control unit (reverse calculation type), 113, 123, 913, 943...Transaction control unit (deferrable type), 114, 124, 914...Transaction control unit (irrevocable type), 115, 125...Concurrency control unit, 116, 126...Request information management unit, 117, 127, 917, 927, 937, 947...External request issue unit, 131, 133...External service, 132, 134, 910, 920, 9 30, 940...External service integration processing specification, 141...External API type specification, 142...Concurrency control specification, 143...External integration processing specification, 144...Cancellation processing specification, 145...Confirmation processing specification, 201...External service function specification information, 202...External service classifier, 701-704, 801-804...Data structure, 901...Travel reservation service (orchestrator), 918...Tour reservation processing execution unit (sub-business logic execution unit), 928...Route reservation processing execution unit (sub-business logic execution unit), 938...Hotel reservation processing execution unit (sub-business logic execution unit), 948...Payment processing execution unit (sub-business logic execution unit), 951...Tour planning site (external service), 952...Route reservation system (external service), 953...Hotel reservation site (external service), 954...Financial institution system (external service), 1001...Text information< / deferred>

Claims

1. A microservice distributed transaction control method that controls a microservice and an external service linked to the microservice, The external services are classified into a plurality of types according to the difference in how they have functions related to the try request, Identifying the type of the external service to be linked from a description of an external service linkage process specification; selecting a transaction control unit that is suited to the type of the external service to be linked from a plurality of transaction control units that are individually suited to the plurality of types of the external service; and applying the selected transaction control unit to execute transaction control between the microservice and the linked external service. Microservices distributed transaction control method.

2. further comprising a step of temporarily storing information required when issuing a cancellation request and a confirmation request to the external service in a request information management unit until the transaction is completed. The microservice distributed transaction control method according to claim 1 .

3. further comprising a step of performing exclusive control between transactions using an identifier that identifies a processing target of the transaction control as a lock key. The microservice distributed transaction control method according to claim 2.

4. The plurality of transaction control units include: a transaction control unit (confirmable type) that is suitable when the external service publishes both a cancellation request and a confirmation request; a transaction control unit (reverse-calculation type) that is suitable when the external service publishes a request that has the effect of canceling side effects in the external service that occur due to the execution of the try request; a transaction control unit (delayable type) adapted to a case where execution of the try request of the external service can be postponed until the transaction is settled; A transaction control unit (irrevocable type) that is applied when none of the transaction control units are compatible. The microservice distributed transaction control method according to claim 1 .

5. The transaction control unit (confirmable type) a step of temporarily storing request parameter information at the time of issuing a try request and request return information from the external service in response to the try request in a request information management unit; When the transaction is finalized, if the finalization destination is Confirm, creating request parameters from the information temporarily stored in the request information management unit and issuing a confirmation request; If the destination is Cancel, creating a request parameter from the temporarily stored information and issuing a cancellation request. The microservice distributed transaction control method according to claim 4.

6. The transaction control unit (reverse calculation type) a step of temporarily storing request parameter information at the time of issuing a try request and request return information from the external service in response to the try request in a request information management unit; When the transaction is finalized, if the finalization destination is Confirm, no request is issued, but if the finalization destination is Cancel, a request parameter is created from the information temporarily stored in the request information management unit, and a cancellation request is issued. The microservice distributed transaction control method according to claim 4.

7. The transaction control unit (delayable type) a step of temporarily storing request parameter information for issuing a try request in a request information management unit without issuing the try request itself; and if the destination of the transaction is Confirm, issuing a try request to the external service by using the request parameter information for issuing the try request temporarily stored in the request information management unit as is when the transaction is settled. The microservice distributed transaction control method according to claim 4.

8. The transaction control unit (delayable type) When the transaction is settled, if the settlement destination is Cancel, no request is issued. The microservice distributed transaction control method according to claim 7.

9. The transaction control unit (irrevocable type) A step of temporarily storing request parameter information in a request information management unit when a try request is issued, but not issuing a request when the transaction is settled, is included. The microservice distributed transaction control method according to claim 4.

10. The microservice includes a step of executing a cooperative operation with the external service in accordance with an external service cooperative process specification; The external service cooperation processing designation is An external API type specification that specifies the type of external service to be linked; a concurrency control specification that specifies a method for generating information to be used as the lock key from parameters of the try request; An external linkage process specification that specifies a procedure for calling the try request to the external service; A cancellation process specification that specifies a procedure for invoking a cancellation request when a transaction is settled; A confirmation process specification that specifies a procedure for invoking a confirmation request when a transaction is settled. The microservice distributed transaction control method according to claim 3 .

11. determining the external API type designation based on publicly available functional specification information of the external service; generating the cancellation process specification based on the functional specification information when the result of the determination is the specification of the transaction control unit (confirmable type) or the specification of the transaction control unit (backward calculation type); If the result of the determination is that the transaction control unit (confirmable type) is specified, generating the confirmation process specification based on the function specification information. The microservice distributed transaction control method according to claim 10.

Images