Method and device for processing distributed transactions under micro-service architecture

Abstract

The embodiment of the invention provides a distributed transaction processing method and device under a micro-service architecture, and the method comprises the steps: determining a stage to which each business participant belongs according to two pre-defined stages of a transaction and the business characteristics of a current business; adding the stage arrangements of all the business participants into the transaction; checking whether the sequence of the stages of the business participants arranged in the transaction meets a transaction integrity condition or not; if yes, submitting the transaction to a transaction management service, so that the transaction management service generates a transaction identifier and stores the transaction identifier; the two stages of the transaction comprise the first stage of Execute / Commit and the second stage of Rollback. And sequentially executing the affairs according to the sequence of the business participants, and if the affairs fail, executing the second stage in the business participants. The problem of long transaction resource locking time caused by the defect that inconsistency between services of a business system cannot be guaranteed in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method for processing distributed transactions under a microservice architecture, a device for processing distributed transactions under a microservice architecture, an electronic device, and a computer-readable medium. Background Art

[0002] Distributed transaction issues are an unavoidable topic for distributed systems. With the prevalence of microservices and DDD (Domain-Driven Design) ideas, business systems have been split from monolithic application architectures to microservices, and have become multiple independently deployed microservices with relatively independent businesses. Therefore, a unified distributed transaction solution is needed to solve the call consistency problem between various services.

[0003] Common common protocols for distributed transactions include 2PC (Two Phase Commit Protocol), 3PC (Three-phase commit protocol), TCC (Try-Confirm-Cancel), XA, Paxos, Raft (Reliable, Replicated, Redundant, And Fault-Tolerant), etc. However, business services usually use 2PC and TCC. Because 2PC and TCC have common characteristics: the transaction process is simple and easy to understand, the transaction participants are simple to implement, and the access cost is low. And these two protocols can fully meet the overall needs of the business.

[0004] 2PC: Two-phase commit. A transaction needs to be executed in two phases: Prepare+Commit. If either Prepare or Commit fails, Rollback is executed.

[0005] Disadvantages of the protocol: In the Prepare phase, many operations need to lock rows first to ensure data consistency. In addition, the application and each sub-transaction process need to be blocked, and resources can only be released after the entire transaction is completed. This results in a relatively long resource locking time, low concurrency, and a large number of transactions often queued.

[0006] TCC: TCC is three words: Try, Commit, and Cancel. The Try phase is preprocessing, locking related resources, and the last two phases are executed without locks. The Commit phase commits. The Cancel phase rolls back. Compared with 2PC, the transaction locks resources for a shorter period of time and has a higher throughput.

[0007] Disadvantages of the protocol: Code intrusion is required to implement distributed transaction rollback, which requires a large amount of development and requires code to provide specific operations for each stage. Summary of the invention

[0008] The embodiment of the present invention provides a method and device for processing distributed transactions under a microservice architecture to solve the problem in the prior art that data needs to be locked, the resource locking time is relatively long, and the concurrency is not high.

[0009] The embodiment of the present invention discloses a method for processing distributed transactions under a microservice architecture, including:

[0010] According to the two pre-defined transaction phases, determine the phase to which each business participant belongs based on the business characteristics of the current business;

[0011] Add the stage arrangement of all business participants to the transaction;

[0012] Check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity conditions;

[0013] If satisfied, the transaction is submitted to the transaction management service so that the transaction management service generates and stores a transaction identifier;

[0014] The two phases of the transaction include: the first phase Execute / Commit and the second phase Rollback.

[0015] Optionally, it also includes:

[0016] In the non-asynchronous transaction phase, the transaction is executed in the order of the business participants. If it fails, the second phase among the business participants is executed;

[0017] For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

[0018] Optionally, executing the transaction in sequence according to the order of the business participants includes:

[0019] Store transaction data during execution;

[0020] Transaction data includes: transaction metadata and transaction status data;

[0021] Transaction metadata is stored in DB, and transaction status data is stored in cache.

[0022] Optionally, the transaction metadata includes: parameters of business participants, processing flow, transaction phase information, and transaction identifier;

[0023] The transaction status data includes: the execution status of the transaction at this stage, and the execution status includes: execution success, execution failure, and execution in progress.

[0024] Optionally, executing the transaction in sequence according to the order of the business participants includes:

[0025] Execute all Executes. If all are successful, execute all Commits.

[0026] Execute all Executes. If at least one fails, perform Rollback of all Executes.

[0027] Optionally, the transaction execution is implemented by calling a GRPC interface or an HTTP interface, and the interfaces of all business participants have idempotence.

[0028] Optionally, check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity condition, including:

[0029] The phases for checking business participants in order include: Execute or Commit;

[0030] If none of them are included, the inspection fails;

[0031] If Execute or Commit is included, determine whether the business participant has information about asynchronous execution;

[0032] If there is information about asynchronous execution, and the only phase of the business participant with asynchronous execution is Commit, the check passes;

[0033] If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the order is a phase that cannot be rolled back, then the phase of the business participant with asynchronous execution is only Commit, and the check passes;

[0034] If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the sequence is a phase that does not include Rollback, the check passes.

[0035] The embodiment of the present invention further discloses a distributed transaction processing device under a microservice architecture, including:

[0036] The phase acquisition unit is used to determine the phase to which each business participant belongs according to the two phases of the predefined transaction and the business characteristics of the current business;

[0037] The transaction registration unit is used to add the stage arrangement of all business participants into the transaction;

[0038] A transaction checking unit, used to check whether the sequence of the phases of each business participant arranged in the transaction satisfies the transaction integrity condition;

[0039] The transaction submission phase is used to submit the transaction to the transaction management service when the transaction integrity condition is met, so that the transaction management service generates and stores the transaction identifier;

[0040] The two phases of the transaction include: the first phase Execute / Commit and the second phase Rollback.

[0041] Optionally, it also includes:

[0042] A transaction execution unit, for executing the transaction in sequence according to the order of the business participants for the non-asynchronous transaction phase, and if it fails, executing the second phase among the business participants;

[0043] For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

[0044] The embodiment of the present invention further discloses an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0045] The memory is used to store computer programs;

[0046] The processor is used to implement the method described in the embodiment of the present invention when executing the program stored in the memory.

[0047] The embodiment of the present invention further discloses one or more computer-readable media on which instructions are stored. When executed by one or more processors, the processors are enabled to execute the method described in the embodiment of the present invention.

[0048] The embodiments of the present invention include the following advantages:

[0049] The method of the embodiment of the present invention only defines two stages of a transaction, and then determines the stage of each participant, and arranges them in sequence to implement a set of lightweight distributed transaction processing methods, reducing the three stages of the prior art to two stages, thereby reducing business access costs; by means of judging the transaction integrity conditions, a consistency guarantee mechanism is provided, thereby improving transaction execution efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1It is a flowchart of a method for processing distributed transactions under a microservice architecture provided in an embodiment of the present invention;

[0051] Figure 2 It is a flowchart of the overall transaction process provided in an embodiment of the present invention;

[0052] Figure 3 It is a schematic diagram of a transaction data storage method in a corresponding transaction execution process provided in an embodiment of the present invention;

[0053] Figure 4 is a flowchart of transaction integrity detection provided in an embodiment of the present invention;

[0054] Figure 5 is a flowchart of a transaction execution process provided in an embodiment of the present invention;

[0055] Figure 6 It is a structural block diagram of a distributed transaction processing device under a microservice architecture provided in an embodiment of the present invention;

[0056] Figure 7 is a block diagram of an electronic device provided in an embodiment of the present invention;

[0057] Figure 8 is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0058] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0059] In the microservice architecture, distributed transactions are a common challenge. In traditional monolithic applications, transaction management is relatively simple because all operations are performed in the same database or the same process. In the microservice architecture, each service usually has its own database, and the interaction between services involves transactions across multiple services, which requires a more complex transaction management mechanism. The embodiment of the present invention provides a method for processing distributed transactions under a microservice architecture, which can easily achieve the final consistency of transactions and facilitate auditing and debugging. The application scenarios can be scenarios that require strong consistency, such as bank transfers and stock transactions. In these scenarios, the integrity and consistency of transactions are very important, and there cannot be any data inconsistencies. In addition, the method of the embodiment of the present invention can also be used for operations such as order creation, payment, and inventory deduction on e-commerce platforms that require coordination between multiple services to ensure the atomicity and consistency of transactions. The method of this embodiment ensures the consistency of transactions. At the same time, in a distributed database, cross-node transaction management can be achieved, which improves availability. Further, the method of this embodiment can also be applied to complex business processes involving multiple services, such as travel reservations (air tickets, hotels, etc.), supply chain operations involving multiple links, such as procurement, production, logistics, etc., with high flexibility and can handle complex business logic.

[0060] Reference Figure 1 , shows a flowchart of a method for processing distributed transactions under a microservice architecture provided in an embodiment of the present invention, which may specifically include the following steps:

[0061] 101. According to the two pre-defined transaction phases, determine the phase to which each business participant belongs according to the business characteristics / business scenario of the current business.

[0062] The two phases of the transaction in this embodiment include: the first phase is Execute / Commit, and the second phase is Rollback. The description of the phases is shown in Table 1 below.

[0063] For each transaction, it is necessary to classify different transactions according to the transaction scenario, that is, according to the business characteristics of the current business, determine the stage to which each business participant belongs. The following Table 2 shows the information of different transaction stages according to the transaction scenario.

[0064] 102. Add the stage arrangement of all business participants to the transaction.

[0065] 103. Check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity condition.

[0066] 104. If satisfied, the transaction is submitted to the transaction management service so that the transaction management service generates and stores a transaction identifier.

[0067] The transaction identifier may be an ID, a UUID or a serial number used to represent the transaction.

[0068] In this embodiment, through the two stages of the predefined transaction, for a business participant, the business participant can participate in at most two transaction interface implementations, which does not affect the original business of the business participant.

[0069] Table 1: Description of transaction phases:

[0070]

[0071] Table 2: Information about different transaction stages according to transaction scenarios:

[0072]

[0073]

[0074] The method of this embodiment implements a set of lightweight distributed transaction processing methods, reduces transaction stages, reduces service access costs, provides a consistency guarantee mechanism, and improves transaction execution efficiency.

[0075] In practical applications, the above method further includes the following step 105:

[0076] 105. In the non-asynchronous transaction phase, the transaction is executed in the order of the business participants. If it fails, the second phase among the business participants is executed;

[0077] For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

[0078] In this embodiment, scenarios that require asynchronous processing, such as notification after order creation, log records, etc. The message queue can be used to decouple the dependencies between services, improve availability, and handle emergencies.

[0079] See also Figure 2 As shown, this embodiment provides an overall transaction flow chart, which includes:

[0080] Transaction registration: The transaction initiator starts the transaction and adds each transaction participant to the transaction according to the expected arrangement.

[0081] Transaction check: Check whether the order in which each participant registers in a transaction satisfies the transaction integrity conditions.

[0082] Transaction submission: Submit the transaction to the transaction management service, generate a transaction ID and save it in the database.

[0083] Transaction execution: Execute in sequence according to the order of transaction participants. If it fails, execute the corresponding Rollback phase.

[0084] Transaction compensation: supports asynchronous transaction stages. If a commit fails in the first stage, the maximum number of transaction executions is used to ensure asynchronous execution without affecting the main transaction process.

[0085] In a specific implementation, the transactions are executed in sequence according to the order of the business participants to generate transaction data, and the method of this embodiment further includes: storing the transaction data during the execution process.

[0086] Transaction data includes: transaction metadata and transaction status data;

[0087] Transaction metadata is stored in DB, and transaction status data is stored in cache.

[0088] For example, when a transaction is created and stored in a database, cache data is generated during the process; during the transaction execution, cache status data is updated; after the transaction ends (failure or completion), the database data is updated.

[0089] The transaction metadata in this embodiment includes: parameters of business participants, processing flow, transaction stage information, transaction identification such as ID, etc.;

[0090] The transaction status data includes: the execution status of the transaction at this stage, and the execution status includes: execution success, execution failure, and execution in progress.

[0091] It should be noted that databases (DB) are mainly used for long-term storage and management of structured data. Databases provide rich query languages ​​(such as SQL) and powerful transaction management functions, which are suitable for complex data operations and persistent storage; the data stored in the database is persistent, and the data will not be lost even if the system is restarted or fails. Due to the need for disk I / O operations and complex query optimization, the access speed of the database is relatively slow. Cache is mainly used to temporarily store frequently accessed data to improve the performance and response speed of the application; the cache is usually not used as the only storage point for data, but as a supplement to the database to reduce the number of direct accesses to the database; the data in the cache system (such as Redis) is usually based on memory storage, and the access speed is very fast, and data reading and writing operations can be completed at the microsecond level.

[0092] In terms of the update strategy for transaction metadata and transaction status data, transaction metadata only needs to record and update the start and end of transaction execution, while transaction status data needs to be updated frequently on each node. When there are many transactions, the update and reading pressure of transaction status data is relatively high.

[0093] like Figure 3As shown, this embodiment uses the method of storing transaction metadata in the DB and storing transaction status in the cache to improve the overall transaction efficiency. By using the method of storing transaction data in a strongly consistent manner, the execution of the entire transaction is guaranteed. At the same time, in order to improve the execution efficiency of transactions, the status data that is frequently updated in the transaction is recorded in a weakly consistent cache. If the status data is lost, the consistency of the transaction status is guaranteed by retrying.

[0094] In this embodiment, if Figure 2 As shown, the transaction registration sequence and the process of checking the integrity of the transaction in the above step 103 are specifically described as follows:

[0095] Due to the redefinition of transaction phases, in order to ensure that the overall transaction can be executed as expected and to ensure the atomicity of the transaction, a transaction registration order check mechanism is added during transaction registration to ensure that the order of registration of transaction participants is normal and that the overall transaction can proceed normally. If the order check fails, execution is rejected.

[0096] Examples of legal order of transaction registration:

[0097] A transaction has three transaction participants:

[0098] A includes Execute+Rollback;

[0099] B includes Exeute;

[0100] C includes Commit;

[0101] The legal registration sequence combinations are:

[0102] A+B+C;

[0103] A+C;

[0104] A+B;

[0105] B+C;

[0106] A;

[0107] B;

[0108] C;

[0109] The registration pseudo code is as follows:

[0110] NewTrans(ctx);

[0111] RegisterMember("A",Execute:ExecuteHandler,Rollback:RollbackHandler);

[0112] RegisterMember("B",Execute:ExecuteHandler);

[0113] ResigerMember("C",Commit:CommitHander).

[0114] Check the process as Figure 4 As shown,

[0115] The phases for checking business participants in order include: Execute or Commit;

[0116] If none of them are included, the inspection fails;

[0117] If Execute or Commit is included, determine whether the business participant has information about asynchronous execution;

[0118] If there is information about asynchronous execution, and the only phase of the business participant with asynchronous execution is Commit, the check passes;

[0119] If there is no information about asynchronous execution, and the stage of the business participant before the current business participant in sequence is a stage that cannot be rolled back, then the stage of the business participant with asynchronous execution is only Commit, and the check passes; wherein, the stage of the business participant before the current business participant is a stage that cannot be rolled back, which means: the stage of the business participant before the current business participant is Commit or Execute without rollback;

[0120] If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the sequence is a phase that does not include Rollback, the check passes.

[0121] In other words, the transaction registration order check mechanism is actually to ensure that the order in which business participants are registered in a transaction is arranged in the order of Execute with rollback - Execute without rollback - Commit, thereby ensuring that the order in which transaction participants are registered is normal and that the overall transaction can proceed normally. If the transaction registration order check fails, execution is rejected.

[0122] This embodiment takes the business of participating in executing order transactions in online shopping software as an example, and provides a distributed transaction processing method in a specific application scenario, including steps 101 to 105, which are specifically as follows:

[0123] 101. According to the two pre-defined transaction phases, determine the phase to which each business participant belongs according to the business characteristics / business scenario of the current business.

[0124] The two phases of the above transaction include: the first phase Execute / Commit and the second phase Rollback.

[0125] Specifically, the services that online shopping software participates in executing order transactions include: order services, inventory services, warehousing services, notification services, etc. Among them, the online shopping software responds to the user's order and payment operation. After the order action is completed, the order service generates the consumer's order. At the same time, the inventory service reduces the order quantity from the inventory of the corresponding goods, the warehousing service creates an outbound order to notify the warehouse to ship the goods, and the notification service notifies the user that the order is successful.

[0126] Among them, the notification business belongs to Commit, which is used to notify the user of the success of the order after the user places the order; the order business, inventory business and warehousing business belong to Execute including rollback. Each rollback is used to roll back the data when any Execute of the order business, inventory business and warehousing business fails to execute, so as to maintain the consistency of resources of all businesses corresponding to the order. Commit will be executed only when all Executes are executed successfully.

[0127] 102. Arrange the stages of all the above business participants in the order of order business, inventory business, warehousing business, and notification business and add them into the transaction. Among them, the order business, inventory business, and warehousing business all contain Execute with rollback. The order of the three can be adjusted, but the notification business belonging to Commit must be arranged after the above three.

[0128] 103. Check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity condition.

[0129] Specifically, the inspection process includes:

[0130] 103-1. The phases of checking business participants in order include: Execute or Commit;

[0131] If neither is included, the check fails; if included, jump to 103-2.

[0132] 103-2. If Execute or Commit is included, determine whether the business participant has information about asynchronous execution;

[0133] If there is information about asynchronous execution, and the only phase of the business participant with asynchronous execution is Commit, the check passes;

[0134] If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the order is a phase that cannot be rolled back, then the phase of the business participant with asynchronous execution is only Commit, and the check passes;

[0135] If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the sequence is a phase that does not include Rollback, the check passes.

[0136] 104. If the check passes, the transaction is submitted to the transaction management service so that the transaction management service generates and stores a transaction identifier.

[0137] 105. In the non-asynchronous transaction phase, the transaction is executed in sequence according to the order of the business participants. If it fails, the second phase among the business participants is executed.

[0138] For the transaction execution process in step 105, Figure 5 The specific instructions are as follows:

[0139] Execute all Executes. If at least one fails, perform Rollback of all Executes.

[0140] Execute all Executes. If all are executed successfully, execute all Commits. Commit supports asynchronous execution, which executes the transaction in the order of business participants and executes asynchronously according to the maximum number of transaction executions. If each execution fails, the second stage of the business participant is executed until the maximum number of executions is reached.

[0141] The Commit phase of the transaction in this embodiment can be executed asynchronously, replacing the local message table, to ensure the overall execution efficiency of the transaction.

[0142] The transaction execution is implemented by calling the GRPC interface or HTTP interface, and the interfaces of all business participants have idempotence to facilitate transaction retry.

[0143] The idempotence of an interface means that when an operation is executed multiple times, the result is the same as if it was executed only once. In other words, no matter how many times the operation is executed, the state of the system will not change. Idempotence is very important in distributed transaction processing because it ensures that the final state of the system remains consistent when network delays, retry mechanisms, or other abnormal situations occur. In general, the idempotence of an interface can be effectively achieved by using unique identifiers, state checks, version control, and logging, thereby improving the reliability and consistency of the system.

[0144] Among them, the GRPC interface is a high-performance Remote Procedure Call (RPC) framework. When applied to inter-service communication in distributed transaction systems, it has an efficient and compact serialization format, which can significantly reduce the size of data transmission and parsing time, and supports two-way streaming communication, allowing efficient data exchange between clients and servers, reducing round-trip time and improving overall performance. Moreover, the GRPC interface supports cross-language communication and uses Protocol Buffers to define service interfaces and message formats, providing strong type security and reducing runtime errors. In addition, GRPC provides a built-in retry mechanism that can automatically retry requests when the network is interrupted or the service is unavailable. In addition, GRPC supports multiple load balancing strategies that can evenly distribute requests to multiple service instances, improve system availability and performance, and provide good support for distributed transaction processing.

[0145] To better understand the above Figures 1 to 5 The process shown takes the creation of elastic network load balancing as an example.

[0146] The overall process includes creating LB information (LB service), applying for LB network card data from VPC (VPC service), and notifying resource changes and updates (other dependent configuration services)

[0147] From the business process, we can know that this process includes three transaction participants, namely LB service, VPC service and other dependent configuration services

[0148] Then the pseudo code for creating the overall transaction process is as follows:

[0149] NewTrans(ctx);

[0150] RegisterMemeber("vpc",Execute:CreatePort,Rollback:DeletePort);

[0151] RegiserMember("LB",Execute:CreateLB);

[0152] ResigterMember("Notify",Commit:Notify).

[0153] The method of this embodiment defines two stages for transactions. After determining the stage of each business participant, the transactions are arranged in sequence and the integrity conditions of the transactions are checked at the same time. This eliminates the defects of the prior art in that the operation data needs to be locked in advance, the locking time is long, and the concurrency is low. At the same time, distributed transaction processing is used to reduce the business volume and improve the overall transaction efficiency.

[0154] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0155] Reference Figure 6 , shows a structural block diagram of a distributed transaction processing device under a microservice architecture provided in an embodiment of the present invention, which may specifically include the following units:

[0156] The phase acquisition unit is used to determine the phase to which each business participant belongs according to the two phases of the predefined transaction and the business characteristics of the current business;

[0157] The transaction registration unit is used to add the stage arrangement of all business participants into the transaction;

[0158] A transaction checking unit, used to check whether the sequence of the phases of each business participant arranged in the transaction satisfies the transaction integrity condition;

[0159] The transaction submission phase is used to submit the transaction to the transaction management service when the transaction integrity condition is met, so that the transaction management service generates and stores the transaction identifier;

[0160] The two phases of the transaction include: the first phase Execute / Commit and the second phase Rollback.

[0161] Furthermore, it also includes:

[0162] A transaction execution unit, for executing the transaction in sequence according to the order of the business participants for the non-asynchronous transaction phase, and if it fails, executing the second phase among the business participants;

[0163] For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

[0164] The device of this embodiment only defines two phases of the transaction in the phase acquisition unit, and then determines the phase of each participant. It implements a set of lightweight distributed transaction processing methods arranged in sequence through the transaction registration unit, the transaction checking unit and the transaction submission unit, thereby reducing the service access cost; it provides a consistency guarantee mechanism with the help of the judgment of the transaction integrity condition, thereby improving the transaction execution efficiency.

[0165] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0166] In addition, an embodiment of the present invention further provides an electronic device, such as Figure 7 As shown, it includes a processor 1301, a communication interface 1302, a memory 1303 and a communication bus 1304, wherein the processor 1301, the communication interface 1302, and the memory 1303 communicate with each other through the communication bus 1304.

[0167] Memory 1303, used for storing computer programs;

[0168] The processor 1301 is used to implement the following steps when executing the program stored in the memory 1303:

[0169] According to the two pre-defined transaction phases, determine the phase to which each business participant belongs based on the business characteristics of the current business;

[0170] Add the stage arrangement of all business participants to the transaction;

[0171] Check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity conditions;

[0172] If satisfied, the transaction is submitted to the transaction management service so that the transaction management service generates and stores a transaction identifier;

[0173] The two phases of the transaction include: the first phase Execute / Commit and the second phase Rollback.

[0174] In the non-asynchronous transaction phase, the transaction is executed in the order of the business participants. If it fails, the second phase among the business participants is executed;

[0175] For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

[0176] The communication bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0177] The communication interface is used for communication between the above terminal and other devices.

[0178] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0179] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0180] like Figure 8 As shown, in another embodiment provided by the present invention, a computer-readable storage medium 1401 is also provided, in which instructions are stored. When the computer-readable storage medium 1401 is run on a computer, the computer executes a method for processing distributed transactions under a microservice architecture described in the above embodiment.

[0181] In another embodiment provided by the present invention, a computer program product including instructions is also provided. When the computer is run on the computer, the computer executes the method for processing distributed transactions under a microservice architecture described in the above embodiment.

[0182] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0183] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0184] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0185] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for processing distributed transactions under a microservice architecture, characterized in that: include: According to the two pre-defined transaction phases, determine the phase to which each business participant belongs based on the business characteristics of the current business; Add the stage arrangement of all business participants to the transaction; Check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity conditions; If satisfied, the transaction is submitted to the transaction management service so that the transaction management service generates and stores a transaction identifier; The two phases of the transaction include: the first phase Execute / Commit and the second phase Rollback.

2. The method according to claim 1, characterized in that: Also includes: In the non-asynchronous transaction phase, the transaction is executed in the order of the business participants. If it fails, the second phase among the business participants is executed; For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

3. The method according to claim 2, characterized in that Execute the transactions in the order of the business participants, including: Store transaction data during execution; Transaction data includes: transaction metadata and transaction status data; Transaction metadata is stored in DB, and transaction status data is stored in cache.

4. The method according to claim 3, characterized in that The transaction metadata includes: parameters of business participants, processing flow, transaction phase information, and transaction identification; The transaction status data includes: the execution status of the transaction at this stage, and the execution status includes: execution success, execution failure, and execution in progress.

5. The method according to claim 3, characterized in that: Execute the transactions in the order of the business participants, including: Execute all Executes. If all are successful, execute all Commits. Execute all Executes. If at least one fails, perform Rollback of all Executes.

6. The method according to claim 5, characterized in that The transaction execution is implemented by calling the GRPC interface or HTTP interface, and the interfaces of all business participants have idempotence.

7. The method according to claim 1, characterized in that Check whether the order of the phases of each business participant arranged in the transaction meets the transaction integrity conditions, including: The phases for checking business participants in order include: Execute or Commit; If none of them are included, the inspection fails; If Execute or Commit is included, determine whether the business participant has information about asynchronous execution; If there is information about asynchronous execution, and the only phase of the business participant with asynchronous execution is Commit, the check passes; If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the order is a phase that cannot be rolled back, then the phase of the business participant with asynchronous execution is only Commit, and the check passes; If there is no information about asynchronous execution, and the phase of the business participant before the current business participant in the sequence is a phase that does not include Rollback, the check passes.

8. A distributed transaction processing device under a microservice architecture, characterized in that: include: The phase acquisition unit is used to determine the phase to which each business participant belongs according to the two phases of the predefined transaction and the business characteristics of the current business; The transaction registration unit is used to add the stage arrangement of all business participants into the transaction; A transaction checking unit, used to check whether the sequence of the phases of each business participant arranged in the transaction satisfies the transaction integrity condition; The transaction submission phase is used to submit the transaction to the transaction management service when the transaction integrity condition is met, so that the transaction management service generates and stores the transaction identifier; The two phases of the transaction include: the first phase Execute / Commit and the second phase Rollback.

9. The device according to claim 8, characterized in that Also includes: A transaction execution unit, for executing the transaction in sequence according to the order of the business participants for the non-asynchronous transaction phase, and if it fails, executing the second phase among the business participants; For transaction phases that support asynchrony, the transactions are executed in sequence according to the order of the business participants, and are executed asynchronously according to the maximum number of transaction executions; if a failure occurs during each execution, the second phase among the business participants is executed until the maximum number of executions is reached.

10. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is used to store computer programs; The processor is used to implement the method according to any one of claims 1 to 7 when executing the program stored in the memory.

Images