WO2023273028A1

WO2023273028A1 - Transaction processing method and related product

Info

Publication number: WO2023273028A1
Application number: PCT/CN2021/125230
Authority: WO
Inventors: 李海兵
Original assignee: 深圳市商汤科技有限公司
Priority date: 2021-06-29
Filing date: 2021-10-21
Publication date: 2023-01-05
Also published as: CN113360299A; CN113360299B

Abstract

A transaction processing method and a related product. The transaction processing method comprises: creating a first microservice by a server (201); creating a chained transaction manager when the first microservice corresponds to at least two transactions, when the at least two transactions comprise a first transaction and a second transaction, and when a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction (202); and processing, by the chained transaction manager, the transaction corresponding to the first data source and the transaction corresponding to the second data source (203). The method can ensure data consistency of the transactions involved in the microservice.

Description

Transaction processing methods and related products

Cross References to Related Applications

This disclosure is based on a Chinese patent application with application number 202110726140.7 and a filing date of June 29, 2021, and claims the priority of this Chinese patent application. The entire content of this Chinese patent application is hereby incorporated into this disclosure by reference.

technical field

The present disclosure relates to the technical field of the Internet, in particular to a transaction processing method and related products.

Background technique

In microservice-based e-commerce platforms and other microservice-based products, business splitting allows each microservice to be deployed and run independently, and the transactions involved in the same microservice may correspond to data update operations from different data sources. How to ensure the data consistency of transactions involved in microservices is an urgent problem to be solved.

Contents of the invention

Embodiments of the present disclosure provide a transaction processing method and related products.

The first aspect of an embodiment of the present disclosure provides a transaction processing method, including: creating a first microservice; at least two transactions corresponding to the first microservice, the at least two transactions including the first transaction and the second transaction, and the first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction, then create a chained transaction manager; through the chained transaction manager, the The transaction corresponding to the first data source is processed with the transaction corresponding to the second data source.

In some optional embodiments of the present disclosure, the method further includes: if the first microservice corresponds to at least one transaction and the at least one transaction corresponds to the same target data source, creating a single data source A transaction manager; the at least one transaction is processed by the single data source transaction manager.

In some optional embodiments of the present disclosure, the creating a single data source transaction manager includes: when the target data source is a default data source, configuring the default transaction manager through annotations, the default A transaction manager implements transaction support of the default data source, and the single data source transaction manager includes the default transaction manager.

In some optional embodiments of the present disclosure, the creating a chained transaction manager includes: creating a transaction manager, and setting an attribute of the transaction manager as a chained transaction manager through annotations.

In some optional embodiments of the present disclosure, before creating the first microservice, the method further includes: receiving a service request initiated by the client; determining at least one microservice involved in the service request, and the at least one The microservice includes the first microservice.

In some optional embodiments of the present disclosure, the at least one microservice further includes a second microservice, and the method further includes: creating the second microservice, creating a first message table or a first message set; A first message related to the service request is delivered to a first message queue, and the second microservice is used to obtain the first message from the first message queue; Whether there is a message identical to the identifier of the first message in the first message table or first message set; there is no identifier of the first message in the first message table or first message set In the case of the same message, process the first message through the second microservice;

In some optional embodiments of the present disclosure, after the processing of the first message, the method further includes: when the first message queue does not receive the message for the first message returned by the second microservice If the message processing of the message succeeds in confirming the message, the second microservice is notified through the first message queue using a best effort notification policy.

In some optional embodiments of the present disclosure, after processing the first message, the method further includes: after the first message is successfully processed, persisting the first message to the first in the message table or the first message set.

In some optional embodiments of the present disclosure, the method further includes: if there is a message with the same identifier as the first message in the first message table or first message set, discarding the first news.

In some optional embodiments of the present disclosure, after creating the first message table or the first message set, the method further includes: defining the table name of the first message table or the first The collection name of the message collection.

In some optional embodiments of the present disclosure, the method further includes: defining an application listener through a service discovery mechanism, and the application listener is used to configure a packet scanning path of the first microservice.

In some optional embodiments of the present disclosure, the creating the first microservice includes: implementing dynamic configuration and registration of the first microservice through an automatic configuration mechanism.

In some optional embodiments of the present disclosure, the method is implemented based on automatically configured pluggable components.

A second aspect of an embodiment of the present disclosure provides a transaction processing device, including:

The first creation unit is configured to create the first microservice;

The second creation unit is configured to correspond to at least two transactions in the first microservice, the at least two transactions include a first transaction and a second transaction, and the first data source corresponding to the first transaction and the If the second data source corresponding to the second transaction is different, create a chained transaction manager;

The transaction processing unit is configured to process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager.

A third aspect of the embodiments of the present disclosure provides a server, including a processor and a memory, the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions , execute the step instruction in the first aspect of the embodiment of the present disclosure.

A fourth aspect of the embodiments of the present disclosure provides a computer-readable storage medium, wherein the above-mentioned computer-readable storage medium is used to store a computer program, and the above-mentioned computer program enables the computer to execute the method described in the first aspect of the embodiments of the present disclosure. some or all of the steps.

A fifth aspect of the embodiments of the present disclosure provides a computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a computer, the computer executes the parts described in the first aspect of the embodiments of the present disclosure or all steps. The computer program product may be a software installation package.

A sixth aspect of the embodiments of the present disclosure provides a computer program. When the computer program is executed by a processor, some or all of the steps described in the first aspect of the embodiments of the present disclosure are implemented.

In the embodiment of the present disclosure, the server creates a first microservice; the first microservice corresponds to at least two transactions, the at least two transactions include a first transaction and a second transaction, and the first transaction corresponds to If the first data source and the second data source corresponding to the second transaction are different, then create a chained transaction manager; through the chained transaction manager, the transaction corresponding to the first data source and the The transaction corresponding to the second data source is processed. The embodiment of the present disclosure can process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager. Since the chained transaction manager can realize the transaction support of multiple data sources, the first transaction can be guaranteed Execute successfully or fail at the same time as the second transaction, so that the data consistency between the first transaction and the second transaction corresponding to the first microservice can be guaranteed.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only These are some embodiments of the present disclosure. For those skilled in the art, other drawings can also be obtained according to these drawings without creative work.

FIG. 1 is an architecture diagram of a communication connection between a client and a server provided by an embodiment of the present disclosure;

FIG. 2 is a schematic flowchart of a transaction processing method provided by an embodiment of the present disclosure;

FIG. 3 is a schematic flowchart of another transaction processing method provided by an embodiment of the present disclosure;

FIG. 4 is a schematic flowchart of another transaction processing method provided by an embodiment of the present disclosure;

FIG. 5 is a schematic flowchart of another transaction processing method provided by an embodiment of the present disclosure;

FIG. 6 is a schematic structural diagram of a transaction processing device provided by an embodiment of the present disclosure;

Fig. 7 is a schematic structural diagram of a server provided by an embodiment of the present disclosure.

detailed description

The following will clearly and completely describe the technical solutions in the embodiments of the present disclosure with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are only some of the embodiments of the present disclosure, not all of them. Based on the embodiments in the present disclosure, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present disclosure.

The terms "first", "second" and the like in the specification and claims of the present disclosure and the above drawings are used to distinguish different objects, rather than to describe a specific order. Furthermore, the terms "comprising" and "having", as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes unlisted steps or units, or optionally further includes For other steps or units inherent in these processes, methods, products or devices.

Reference in the present disclosure to an "embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present disclosure. The occurrences of this phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is understood explicitly and implicitly by those skilled in the art that the embodiments described in this disclosure can be combined with other embodiments.

The electronic devices involved in the embodiments of the present disclosure may include devices with computing capabilities and communication capabilities, such as mobile phones, tablets, and personal computers. A personal computer may also be called a user computer, and may include a desktop computer, a notebook computer, and the like. For convenience of description, the devices mentioned above are collectively referred to as electronic devices. The client is a program that provides local services for the user, and the client can run on the electronic device.

The server involved in the embodiments of the present disclosure may be a server in a micro-server cluster, and the server may run on the server. The server is for the client, and the content of the service includes providing services to the client (for example, online order service, online payment service, online query service, etc.), saving client data, and so on.

Please refer to FIG. 1 . FIG. 1 is a structural diagram of a communication connection between a client and a server provided by an embodiment of the present disclosure. As shown in FIG. 1 , the server 100 can communicate with at least one client 101 . The client can establish a communication connection with the server directly, or establish a communication connection with the server through other devices. The server can provide various types of services, and the client can initiate a service request to the server, and the service request can include an order request, payment request, query request, etc. The server creates the first microservice; if the first microservice corresponds to at least two transactions, the at least two transactions include the first transaction and the second transaction, and the first data source corresponding to the first transaction and the second transaction corresponding to the second transaction If the data sources are different, a chain transaction manager is created; the transaction corresponding to the first data source and the transaction corresponding to the second data source are processed through the chain transaction manager. The embodiment of the present disclosure can process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager. Since the chained transaction manager can realize the transaction support of multiple data sources, the first transaction can be guaranteed Execute successfully or fail at the same time as the second transaction, so that the data consistency between the first transaction and the second transaction corresponding to the first microservice can be guaranteed, and the data consistency of all transactions involved in a microservice can be improved.

The server can provide many microservices, and the server can create microservices in response to business requests initiated by the client. A business request initiated by a client may involve data aggregation or data update of multiple microservices. For example, when a user initiates a product purchase request on a mobile phone, the data update may include: update of product inventory data, update of product information in the shopping cart, update of order data, etc.; data aggregation may include: the user simultaneously displays the inventory on the product browsing interface Aggregation of information, product information, product discount information and other data.

Microservice, a software development technique, is a variant of Service-Oriented Architecture (SOA), which constructs an application as a set of loosely coupled services. A microservice can implement a certain function.

Transaction refers to a program execution unit that accesses and possibly updates various data items in the database. A microservice may correspond to one transaction, or at least two transactions.

In an example, the first microservice may be an order service, and at least two transactions corresponding to the first microservice may include: a commodity order information saving transaction, an inventory message queue delivery transaction, and a shopping cart message queue delivery transaction. For example, after a user initiates a product purchase request on a mobile phone, an order service can be created. The order service creates an order, and the order service stores the order data (for example, order number) in the first data source (for example, MySQL database), which is the order For the first transaction corresponding to the service, you can store the detailed data of the order (for example, the time of placing the order, the quantity of the ordered goods, the details of the purchased goods, the purchase amount, etc.) in the second data source (for example, the MongoDB database), which is the order For the second transaction corresponding to the service, the order service can also deliver a message to the message queue of the inventory service (for example, Kafka message queue), so that the inventory minus the quantity of purchased goods (for example, subtract 1 from the inventory data), and deliver another A message to the cart service's message queue (for example, a Kafka message queue) to ask the cart service to delete the item. Data sources can include databases or database servers used by database applications.

The transactions involved in the same microservice may correspond to different data sources. If the transactions of different data sources are implemented separately, since multiple transactions involved in the same microservice are processed separately, it is difficult to ensure that the transactions involved in the same microservice data consistency.

The first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction, and the type of the first data source may be different from the type of the second data source. The first data source corresponding to the first transaction refers to the first data source that the first transaction needs to access, and the second data source corresponding to the second transaction refers to the second data source that the second transaction needs to access.

Chained transaction manager is a kind of transaction manager, which can define a transaction chain, and multiple transactions are submitted sequentially in the chained transaction manager. For example, the first microservice corresponds to three transactions: commodity order information storage transaction, inventory message queue delivery transaction, and shopping cart message queue delivery transaction, and the commodity order information storage transaction, inventory message queue delivery transaction, and shopping cart message queue delivery transaction can be submitted in sequence affairs. The chained transaction manager can support transaction processing of multiple types of data sources, and ensure that the three transactions corresponding to the first microservice are executed successfully or fail at the same time, thereby ensuring the data consistency of the three transactions corresponding to the first microservice.

The data consistency in the embodiments of the present disclosure may include strong data consistency or weak data consistency. Data weak consistency can also be called data final consistency. For e-commerce platforms, it is enough to ensure the final consistency of data. For example, a user places an order for a product on an e-commerce platform. After the order service creates an order, if the order service is executed successfully, the inventory service will decrease the inventory by 1, and the shopping cart service will delete the product in the user's shopping cart. If the order is successfully executed, the inventory is reduced by 1, and the product in the user's shopping cart is deleted, the three are consistent, and the data consistency is considered. The final consistency does not require that the three must be completed at the same time, only that they are consistent in the end. Can. Strong data consistency requires that all three must be completed at the same time. If the order service is executed successfully and the inventory has not changed, or the product in the user's shopping cart has not been deleted, the data is considered inconsistent and data consistency is not satisfied.

Please refer to FIG. 2 . FIG. 2 is a schematic flowchart of a transaction processing method provided by an embodiment of the present disclosure. The method is applied to the server shown in FIG. 1, and as shown in FIG. 2, the transaction processing method may include the following steps.

201. The server creates a first microservice.

In the embodiment of the present disclosure, the server can create the first microservice at the request of the user, or can create the microservice by itself. For example, when the client initiates an order request to the server, the server can create the first microservice, namely the order service; when the client initiates a payment request to the server, the server can create the first microservice, namely the payment service . For another example, when the server needs to query data in the database, the server can actively create the first microservice, that is, the query service.

202. When the first microservice corresponds to at least two transactions, the at least two transactions include the first transaction and the second transaction, and the first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction , the server creates a chained transaction manager.

In the embodiment of the present disclosure, a microservice may correspond to at least one transaction. When one microservice corresponds to at least two transactions, the data sources corresponding to the at least two transactions may be the same or different. When the data sources corresponding to the at least two transactions are different, a chained transaction manager may be created, and the at least two transactions are processed through the chained transaction manager.

For example, if the first microservice includes an order service, the order service may correspond to an order information saving transaction, an inventory message queue delivery transaction, and a shopping cart message queue delivery transaction. The data source corresponding to the order information saving transaction can be a MySQL database, the data source corresponding to the inventory message queue delivery transaction can be a Kafka (kafka) message queue, and the data source corresponding to the shopping cart message queue delivery transaction can be kafka.

Transaction (Transaction) generally refers to something to be done or done. In computer terms, it refers to a program execution unit (unit) that accesses and possibly updates various data items in a database. Transactions are usually caused by the execution of user programs written in advanced database manipulation languages or programming languages (such as SQL, C++ or Java), and are defined by statements (or function calls) such as begin transaction and end transaction. A transaction consists of all operations performed between the begin transaction and the end transaction.

The server may create a chained transaction manager when at least two transactions corresponding to the first microservice have transactions with different data sources. The chained transaction manager can connect at least two transactions in series. After connecting the above two transactions, the chained transaction manager can process them in a unified manner. The above at least two transactions either fail at the same time or succeed at the same time, thus ensuring that the first micro The data consistency of the above at least two transactions corresponding to the service.

In some optional embodiments, in step 202, the server creates a chained transaction manager, which may include the following steps: the server creates a transaction manager, and sets the property of the transaction manager as a chained transaction manager through annotations.

In the embodiments of the present disclosure, annotations can be understood as special tags in the code, and these tags can be read during compilation, class loading, and runtime, and corresponding processing is performed. Through annotations, software developers can embed supplementary information in source code without changing the original code and logic. By way of annotation, it may be determined whether to set the property of the transaction manager according to all the data sources involved in the first microservice corresponding to at least two transactions. If the first microservice corresponds to at least two transactions involving all data sources including at least two different data sources, since the transaction annotation is set to the default transaction manager by default, the default transaction manager can only implement transactions of one default data source If it is supported, it is necessary to reset the property of the transaction manager to be a chained transaction manager, so that the chained transaction manager can realize the above-mentioned transaction support of at least two different data sources. If all the data sources involved in at least two transactions of the first microservice are the same data source, since the transaction annotation is set as the default transaction manager by default, there is no need to reset the properties of the transaction manager. The embodiments of the present disclosure can enable transactions through annotations and set transaction manager types.

Exemplarily, in the code, the transaction annotation may be @transactional annotation. In the embodiment of the present disclosure, @Transactional annotation can be added at the place where transaction management is required. The @Transactional annotation can be applied to interface definitions and interface methods, class definitions, and public methods of classes. The @Transactional annotation can be added to the service layer.

203. The server processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

In the embodiment of the present disclosure, the chained transaction manager may sequentially process the transaction corresponding to the first data source and the transaction corresponding to the second data source. Specifically, the chained transaction manager may process the first transaction and the second transaction in sequence.

The chained transaction manager can realize the transaction support of multiple data sources. If the above-mentioned at least two transactions correspond to two different data sources: the first data source and the second data source, the created chained transaction manager can realize the second The transaction support of a data source and a second data source; if the above-mentioned at least two transactions correspond to three different data sources: the first data source, the second data source and the third data source, then the created chain transaction manager can Implement transaction support for the first data source, the second data source, and the third data source, and so on.

The embodiment of the present disclosure can process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager. Since the chained transaction manager can realize the transaction support of multiple data sources, the first transaction can be guaranteed Execute successfully or fail at the same time as the second transaction, so that the data consistency of the first transaction and the second transaction corresponding to the first microservice can be guaranteed, and the data consistency of all transactions involved in a microservice can be guaranteed.

Please refer to FIG. 3 . FIG. 3 is a schematic flowchart of another transaction processing method provided by an embodiment of the present disclosure. Fig. 3 is further optimized on the basis of Fig. 2. As shown in Fig. 3, the transaction processing method may include the following steps.

301. The server creates a first microservice.

302, when the first microservice corresponds to at least two transactions, the at least two transactions include the first transaction and the second transaction, and the first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction , the server creates a chained transaction manager.

303. The server processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

Wherein, the specific implementation of steps 301 to 303 may refer to steps 201 to 203 shown in FIG. 2 , which will not be repeated here.

304. In the case that the first microservice corresponds to at least one transaction, and at least one transaction corresponds to the same target data source, the server creates a single data source transaction manager.

A single data source transaction manager can implement transaction support for one data source. If at least one transaction corresponds to the same target data source as the default data source, the server configures the default transaction manager through annotations, and the default transaction manager can implement the transaction support of the default data source. If at least one transaction corresponds to the same target data source that is not the default data source, the server sets the property of the transaction manager through the transaction annotation as the target transaction manager that supports the target data source, and the target transaction manager can implement the transaction of the target data source support.

Optionally, in step 304, the server creates a single data source transaction manager, which may specifically include the following steps: when the target data source is the default data source, configure the default transaction manager by means of annotations, the A default transaction manager implements transaction support of the default data source, and the single data source transaction manager includes the default transaction manager. In the embodiment of the present disclosure, when the target data source is associated with the default data source, transactions can be enabled through annotations, and the transaction manager type can be determined as the default transaction manager.

In the embodiment of the present disclosure, if the target data source is associated with the default data source, there is no need to reset the properties of the transaction manager, and the default transaction manager can be configured directly through annotations, and the default transaction manager can implement the transactions of the default data source Yes, the default transaction manager is a single data source transaction manager.

305. The server processes at least one transaction through the single data source transaction manager.

In the embodiment of the present disclosure, the single data source transaction manager can process multiple transactions of the same data source at the same time, and multiple transactions can be carried out at the same time. Compared with the transaction serial processing of the chained transaction manager, the single data source The transaction manager is more efficient in transaction processing. The transaction in the embodiments of the present disclosure may be a data update transaction.

Please refer to FIG. 4 . FIG. 4 is a schematic flowchart of another transaction processing method provided by an embodiment of the present disclosure. FIG. 4 is further optimized on the basis of FIG. 2 . As shown in FIG. 4 , the transaction processing method may include the following steps.

401. The server receives a service request initiated by the user.

In the embodiment of the present disclosure, the service request may include an order request, a payment request, a query request, etc., and the type of the service request is not limited in this embodiment.

402. The server determines at least one microservice involved in the service request, where the at least one microservice includes the first microservice.

In the embodiments of the present disclosure, different service requests involve different microservices. For example, an order request may involve order service, inventory service, shopping cart service, etc., and more microservices are involved in the order request; query requests may only involve query services, and fewer microservices are involved in query requests. The correspondence between business requests and the number and types of microservices can be pre-stored on the server side, and different business requests can correspond to different numbers of microservices and different types of microservices.

The embodiment of the present disclosure can decide which microservices to create and the number of microservices to create according to the number and type of microservices involved in the business request initiated by the user, neither occupying redundant microservice resources nor creating fewer microservices Microservices prevent business requests from being processed, and microservices can be created flexibly to better implement business requests initiated by clients.

403. The server creates the first microservice.

404, when the first microservice corresponds to at least two transactions, the at least two transactions include the first transaction and the second transaction, and the first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction , the server creates a chained transaction manager.

405. The server processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

Wherein, the specific implementation of steps 403 to 405 may refer to steps 201 to 203 shown in FIG. 2 , which will not be repeated here.

Please refer to FIG. 5 . FIG. 5 is a schematic flowchart of another transaction processing method provided by an embodiment of the present disclosure. Fig. 5 is further optimized on the basis of Fig. 4. As shown in Fig. 5, the transaction processing method may include the following steps.

501. The server receives a service request initiated by the user.

502. The server determines at least two microservices involved in the service request, and the at least two microservices include a first microservice and a second microservice.

503. The server creates a first microservice and a second microservice, and creates a first message table or a first message set.

In the embodiment of the present disclosure, if a service request involves at least two microservices, the at least two microservices may be created at the same time, or the at least two microservices may be created separately. The first message table or the first message set can be created in the data source corresponding to the second microservice, and the second microservice can process the first message. After the processing is successful, the first message can be persisted to the in the first message table. Different files can be defined in different databases to store messages. For example, a message table can be created in a MySQL database to store messages, and a message collection can be created in a MongoDB database to store messages.

Optionally, in step 502, the server creates the first microservice, which may specifically include the following steps: implementing dynamic configuration and registration of the first microservice through an automatic configuration mechanism.

In the embodiment of the present disclosure, microservices can be dynamically created according to the activation status and attribute values of annotations, and the created effective microservices can be registered in the container, so as to realize dynamic configuration and registration of microservices. Exemplarily, when creating a microservice, the configuration file of the resource file (for example, properties or yml configuration) can be read through the pre-set components. If the startup class of the microservice is configured in the configuration file, use Enable annotation, the Enable annotation starts automatic configuration, configures and registers related microservices according to the property value of the Enable annotation, and realizes the creation of microservices. Since the enabling status and attribute values of the Enable annotation can be set by developers, microservices can be dynamically created according to project needs. If the startup class of the microservice configured in the configuration file does not use the Enable annotation, the microservice can be created according to the default configuration. The container in this embodiment of the disclosure may be a Spring container.

504. The server delivers the first message related to the service request to the first message queue, and the second microservice is used to obtain the first message from the first message queue.

In the embodiments of the present disclosure, the message queue is a container for storing messages during message transmission. Messages can be as simple as containing only text strings, or more complex as possibly containing embedded objects. A topic (topic) for consumption by the second microservice (consumer) can be created for the first message queue. The second microservice can pull the first message corresponding to the second microservice topic from the first message queue. The first The message queue can also actively push the first message to the second microservice. Similarly, another topic for consumption by the third microservice (consumer) can also be created for the first message queue.

The message queue has an asynchronous decoupling function. In the embodiment of the present disclosure, the message queue is used for message transmission, which can greatly improve the throughput of the interface, and at the same time achieve the purpose of traffic peak shaving.

Asynchronous: The transaction of the first microservice and the transaction of the second microservice do not need to be executed synchronously. Through the message queue, after the first microservice delivers the first message to the first message queue, it can also deliver other messages to For other message queues, there is no need to wait for the second microservice to process the first message, which can greatly improve the throughput of the interface.

Decoupling: Assume that the first microservice and the second microservice are two classes respectively. If the first microservice directly calls a method of the second microservice, then the first microservice will have a dependency (that is, coupling) on the second microservice. If the code of the second microservice changes in the future, it may affect the first microservice. If a message queue is used, both the first microservice and the second microservice depend on the message queue, and there is no direct dependence between the first microservice and the second microservice, and the coupling is correspondingly reduced.

Wherein, the first message related to the service request may be generated by the first microservice, and the server may generate the first message through the first microservice. For example, if the business request is an order request, the first microservice is the order service, and the second microservice is the inventory service, the first message related to the business request can be generated by the order service, and the first message can include the order number, Commodity details (for example, the quantity of the commodity, the model of the commodity, etc.) and the like. After the second microservice obtains the first message, it may subtract the quantity of the commodity in the commodity detail from the stock quantity of the corresponding commodity model in the commodity detail according to the commodity detail included in the first message.

Optionally, the at least two microservices may include a first microservice, a second microservice and a third microservice. The server may generate a third message through the first microservice, and deliver the third message to the second message queue, and the third microservice is used to obtain the third message from the second message queue.

A topic for consumption by the third microservice (consumer) can be created for the second message queue, the third microservice can pull the third message from the second message queue, and the second message queue can also actively send the third microservice Push the third message.

The third message may be generated by the first microservice, and the server may generate the third message through the first microservice. For example, if the business request is an order request, the first microservice is an order service, the second microservice is an inventory service, and the third microservice is a shopping cart service, the third message may include an order number. After the third microservice obtains the third message, it can remove the commodity corresponding to the order number from the shopping cart according to the order number included in the third message.

505. The server determines whether there is a message with the same identifier as the first message in the first message table or the first message set according to the identifier of the first message.

506. There is no message with the same identifier as the first message in the first message table or the first message set, and the server processes the first message through the second microservice.

Optionally, after performing step 506, the following steps may also be performed:

507. In the case that the first message queue does not receive the message processing success confirmation message for the first message returned by the second microservice, the server notifies the second microservice through the first message queue using a best effort notification policy.

In the embodiment of the present disclosure, after the second microservice processes the first message, it may obtain a processing result of processing success or processing failure. If the processing is successful, as long as the second microservice does not fail, the second microservice will return a message processing success confirmation message for the first message to the first message queue. If the second microservice fails, such as the service hangs up or the network fails, the second microservice cannot send the processing result to the first message queue, and the server can notify the second microservice through the first message queue using the best effort notification strategy. Service, to ensure the final consistency of data for transactions corresponding to multiple microservices, thereby ensuring the final consistency of multiple data source transactions. If the processing fails, the second microservice will return a message processing failure message for the first message to the first message queue. The microservice processes the first message until receiving a message processing success confirmation message for the first message returned by the second microservice.

A best-effort notification policy is a policy that uses best efforts to notify. For example, the first message queue can periodically notify the second microservice to let the second microservice return the processing result for the first message until the first message queue receives the processing result for the first message returned by the second microservice until. For another example, the first message queue can notify the second microservice with a notification policy with a gradually increasing period, and let the second microservice return the processing result for the first message until the first message queue receives the response to the second microservice. until the processing result of the first message. For another example, after the service hangs and restarts or the network resumes and restarts, the second microservice can actively pull the first message from the first message queue for processing, and return the processing result to the first message queue.

Optionally, when the first message queue receives the processing result for the first message returned by the second microservice, the server can notify the first microservice through the first message queue, and the first microservice is used to communicate with The second microservice synchronizes data, thereby ensuring the consistency of transaction data of multiple microservices.

508, when the first microservice corresponds to at least two transactions, the at least two transactions include the first transaction and the second transaction, and the first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction , the server creates a chained transaction manager.

509, the server processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

Wherein, for the specific implementation of steps 508 to 509, reference may be made to steps 202 to 203, which will not be repeated here.

Optionally, after step 506 is performed, the method shown in FIG. 5 may further include the following steps: after the first message is successfully processed, the server persists the first message to the first message table or in the first message collection.

In the embodiment of the present disclosure, the service data of the service request may include data required to execute the service request. For example, if the business request is an order request, the data required for the order request may include: order data (for example, order number), order detail data (for example, order time, quantity of ordered goods, details of purchased goods , purchase amount, etc.).

Data persistence is a collective term for converting an in-memory data model to a storage model, and converting a storage model to an in-memory data model. For example, to persist the first message in the first message table or first message set, the first message may be stored in the first message table or first message set.

Optionally, the method shown in Figure 5 may also include the following steps:

If there is a message with the same identifier as the first message in the first message table or first message set, the server discards the first message.

In the embodiment of the present disclosure, the server can create a first message table in the data source corresponding to the second microservice. The first message table is used to store messages. Each message can correspond to an identifier. This identifier can be a global Unique identifier (globally unique identifier, GUID). Since business requests can correspond to multiple microservices, these multiple microservices can be executed in multiple devices on the network, and each message can be marked with a global identifier among these multiple microservices to distinguish different messages. Exemplarily, the second microservice may be inventory service or shopping cart service.

In the embodiment of the present disclosure, the identifier of each message is unique. In order to prevent the same message from being executed multiple times, it may be determined according to the identifier of the message whether it will be executed multiple times. If the identifiers of the first message and the second message in the first message table are the same, it indicates that the first message is put into the first message table for the second time, and the first message is directly discarded. If the identifiers of the first message and the second message are different, it indicates that the first message is put into the first message table for the first time, and the server processes the first message through the second microservice. After the first message is successfully processed, The server persistently stores the first message in the first message table through the second microservice. The embodiment of the present disclosure can realize the idempotency check of the transaction message through the message table and the identifier of the message, so as to ensure the idempotence of the transaction message.

Optionally, after step 503 is performed, the following step may also be performed: the server defines the table name of the first message table or the set name of the first message set through an expression language.

In the embodiment of the present disclosure, the expression language may be Spring Expression Language (Spring Expression Language, SpEL). SpEL expressions can realize the automatic configuration of table names or collection names, and can flexibly define table names or collection names.

Optionally, the above method may further include: defining an application listener through a service discovery mechanism (Service Provider Interface, SPI), and the application listener is used to configure a packet scanning path of the first microservice.

In the embodiment of the present disclosure, SPI is a service discovery mechanism provided inside the Java development toolkit. SPI searches for files in the META-INF/services folder under the ClassPath path, and automatically loads the classes defined in the files. The SPI may define an application listener, and the application listener is used to configure the packet scanning path of the first microservice. It does not require users to add package scanning paths to the startup class, reducing the difficulty of user development.

The methods in the embodiments of the present disclosure can be implemented by pluggable components based on automatic configuration. This component can be used in the development of the Spring project, and can be used in the e-commerce platform based on micro-service development and other micro-service development products.

In some optional embodiments, the software product of the embodiments of the present disclosure may be a pluggable component. For example, the Spring Boot Starter component can be quickly introduced in any Spring project, using the default configuration, or simply configuring it in the project's configuration file (for example, Properties or yml) as needed. The introduction of the component will not have any impact on its own project. Only when the microservice startup class uses the enable (Enable) annotation to enable the automatic configuration (AutoConfigure) support of this message transaction component will the configuration and registration of related services be performed.

Among them, the component development process may include the following steps:

1. Create a Spring Boot Starter project and introduce related dependencies (for example, maven dependencies);

2. Create transaction message entity classes, map to MySQL data tables and MongoDB collections, and dynamically define table names or collection names through SpEL expressions;

3. Develop and operate the service (Service) of MySQL data tables and MongoDB collections. At the same time, MongoDB's Service can dynamically decide whether to add its update operation to the transaction according to whether its version supports transactions;

4. Define the Enable annotation for whether automatic configuration is enabled, and add the attribute of the message persistence method to determine whether to use the MySQL database or the MongoDB database to store transaction messages, and at the same time decide to register in the Spring container to process the MySQL message table Service is also the Service of MongoDB message collection;

5. Define the application listener through the service provider interface (SPI) mechanism to configure the path for Spring package scanning;

6. Define transaction managers for multiple data sources such as MySQL, MongoDB, and Kafka and the conditions for creating them, and create chained transaction managers for various combinations of the above data sources;

7. Define the Kafka (kafka) message producer Service class for transaction message encapsulation and delivery. At the same time, it can dynamically manage the registration of the Service to the Spring container according to whether the business microservice introduces kafka dependencies, and can support it according to the kafka version. Transaction and whether to open the transaction to decide whether to add its message delivery operation to the transaction;

8. Realize the accurate delivery of messages through kafka's transaction support, and ensure the final consistency of transactions through its message consumption confirmation or submission mechanism, kafka message persistence characteristics and message offset.

Among them, the use of components in the project may include the following steps:

1. The user creates a business microservice project and adds components;

2. Configure the default name of the table name or collection name for transaction message persistence in the configuration file (for example, the default name is transfer message), and configure the default transaction manager (for example, MySQL by default);

3. Add annotations to the startup class for automatic configuration and registration of message persistence services;

4. Execute local transactions. If the data source is associated with the default transaction manager and does not involve multiple data sources, use the annotation directly without setting attributes; if the data source is associated with other transaction managers, the annotation must set the attribute as The chained transaction manager provided by the component;

5. If the business microservice needs to use Kafka, since the components will not import Kafka by default, you need to add Kafka-related dependencies in the microservice, and inject the Kafka message deliverer into the business through automatic assembly In the service, it is used for delivery of Kafka messages;

6. Create another consumer business microservice, similarly introduce related dependencies, and then create a Kafka message listener for processing transaction messages. The service (MessageService) for message persistence and idempotence verification automatically assembled based on this component can realize the idempotence judgment of transaction messages.

The components of the disclosed embodiment can realize the transaction support of MySQL, MongoDB and Kafka multi-type data sources, and can dynamically create a single data source transaction manager and a chained transaction manager according to the dependencies referenced by the project and the transaction opening state; transaction message Persistent table names or collections can be dynamically defined, making the configuration of microservices more flexible. Each microservice can use the same database, and distinguish the persistent transaction messages of different microservices through different table names and collection names; it can be used through SPI The mechanism defines the application listener to realize the Spring package scanning of microservices, and does not require the user to add the package scanning path of this component on the startup class; the component can dynamically create a Service according to the enablement of the user's Enable annotation and the attribute value, and will effectively Service is registered to the Spring container, and invalid redundant services will not be registered; previous versions of Kafka and MongoDB do not support transactions, and Kafka transactions need to be manually enabled through configuration or coding. Based on this component, users do not need to make repeated judgments. It will dynamically manage transactions according to the data source's support for transactions and the opening status; integrate multi-type data source transaction support and the realization of multi-instance data source transaction consistency, and do not need to develop different components for the two scenarios; cross-service multi-data source transactions Consistency is the final consistency based on the best effort notification of the Kafka message queue. Compared with rigid transactions and compensating transactions, the throughput is greatly improved, and it can meet the traffic peak shaving in high concurrency scenarios and guarantee service Stability; based on automatic configuration of pluggable components, business microservices will not be affected after adding this component dependency, and no additional configuration is required. Only when the user actively enables the automatic configuration of this component will the relevant functions be enabled, and the component The automatic configuration mechanism and default configuration can meet most of the needs, and basically do not require users to do additional configuration.

The foregoing mainly introduces the solutions of the embodiments of the present disclosure from the perspective of executing the process on the method side. It can be understood that, in order to realize the above functions, the electronic device includes hardware structures and/or software modules corresponding to each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of the examples described in the embodiments provided herein, the present disclosure can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software drives hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementation should not be considered beyond the scope of the present disclosure.

The embodiments of the present disclosure may divide the functional units of the server and the electronic device according to the above method examples. For example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units. It should be noted that the division of the units in the embodiment of the present disclosure is schematic, and is only a logical function division, and there may be another division manner in actual implementation.

Please refer to FIG. 6. FIG. 6 is a schematic structural diagram of a transaction processing device provided by an embodiment of the present disclosure. The transaction processing device 600 is applied to the server. 602 and transaction processing unit 603, wherein:

The first creation unit 601 is configured to create a first microservice;

The second creating unit 602 is configured to correspond to at least two transactions in the first microservice, the at least two transactions include a first transaction and a second transaction, and the first data source and the first transaction correspond to the first transaction If the second data source corresponding to the above second transaction is different, create a chained transaction manager;

The transaction processing unit 603 is configured to process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

Optionally, the second creating unit 602 is further configured to create a single data source transaction manager when the first microservice corresponds to at least one transaction and the at least one transaction corresponds to the same target data source;

The transaction processing unit 603 is further configured to process the at least one transaction through the single data source transaction manager.

Optionally, the second creating unit 602 is configured to configure a default transaction manager through annotations when the target data source is a default data source, and the default transaction manager implements the default data source The transaction support of the single data source transaction manager includes the default transaction manager.

Optionally, the second creation unit 602 is configured to create a transaction manager, and set the attribute of the transaction manager as a chained transaction manager through annotations.

Optionally, the transaction processing apparatus 600 may further include a receiving unit 604 and a determining unit 605 .

The receiving unit 604 is configured to receive a service request initiated by a client;

The determining unit 605 is configured to determine at least one microservice involved in the service request, where the at least one microservice includes the first microservice;

The first creating unit 601 is configured to create a first microservice after the determining unit 605 determines at least one microservice involved in the service request.

Optionally, the at least one microservice further includes a second microservice, and the transaction processing apparatus 600 may further include a delivery unit 606 , a judging unit 609 and a message processing unit 610 .

The first creating unit 601 is further configured to create the second microservice after the determining unit 605 determines at least one microservice involved in the service request, and create a first message table or a first message set;

The delivery unit 606 is configured to deliver the first message related to the service request to a first message queue, the second microservice is configured to obtain the first message from the first message queue; and;

The judging unit 609 is configured to judge whether there is a message with the same identifier as the first message in the first message table or first message set according to the identifier of the first message;

The message processing unit 610 is configured to process the first message through the second microservice when the determination result of the determination unit 609 is negative.

The transaction processing device 600 may also include a notification unit 607;

The notification unit 607 is configured to use best effort through the first message queue when the first message queue does not receive the message processing success confirmation message for the first message returned by the second microservice The notification policy notifies the second microservice.

Optionally, the transaction processing apparatus 600 may further include a persistence unit 608 .

The persisting unit 608 is configured to persist the first message in the first message table or first message set after the first message is successfully processed.

Optionally, the message processing unit 610 is further configured to discard the first message when the judging result of the judging unit 609 is yes.

Optionally, the transaction processing device 600 may also include a first definition unit;

The definition unit is configured to define the table name of the first message table or the set name of the first message set through an expression language after the first creation unit 601 creates the first message table or the first message set .

Optionally, the transaction processing apparatus 600 may also include a second definition unit;

The second definition unit is configured to define an application listener through a service discovery mechanism SPI, and the application listener is used to configure a packet scanning path of the first microservice.

Optionally, the first creating unit 601 is configured to implement dynamic configuration and registration of the first microservice through an automatic configuration mechanism.

Among them, the receiving unit 604 in the embodiment of the present disclosure may be the input and output device of the server, the first creation unit 601, the second creation unit 602, the transaction processing unit 603, the determination unit 605, the delivery unit 606, the notification unit 607, the persistent The unit 608, the judging unit 609, the message processing unit 610, the first defining unit and the second defining unit may be processors of the server.

In the embodiment of the present disclosure, the transaction corresponding to the first data source and the transaction corresponding to the second data source can be processed through the chained transaction manager. The first transaction and the second transaction execute successfully or fail at the same time, so that the data consistency of the first transaction and the second transaction corresponding to the first microservice can be guaranteed.

Please refer to FIG. 7. FIG. 7 is a schematic structural diagram of a server provided by an embodiment of the present disclosure. As shown in FIG. 7, the server 700 includes a processor 701 and a memory 702. connect. The communication bus 703 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus or the like. The communication bus 703 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used in FIG. 7 , but it does not mean that there is only one bus or one type of bus. The memory 702 is used to store computer programs, the computer programs include program instructions, and the processor 701 is configured to call the program instructions, and the above programs are included to execute the methods in FIGS. 2 to 5 .

Processor 701 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (Application-Specific Integrated Circuit, ASIC), or one or more integrated circuits used to control the execution of the programs of the above solutions.

The memory 702 may be a read-only memory (Read-Only Memory, ROM) or other types of static storage devices that can store static information and instructions, and a random access memory (Random Access Memory, RAM) or other types that can store information and instructions It can also be an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a read-only disc (Compact Disc Read-Only Memory, CD-ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be programmed by a computer Any other medium accessed, but not limited to. The memory can exist independently and be connected to the processor through the bus. Memory can also be integrated with the processor.

Optionally, the server 700 may further include an input and output device 704, and the input and output device 704 may include an input and output device such as a radio frequency circuit and an antenna.

An embodiment of the present disclosure also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program enables the computer to perform any transaction as described in the above-mentioned method embodiments Some or all steps of a processing method.

Embodiments of the present disclosure further provide a computer program, which implements some or all steps of any transaction processing method described in the foregoing method embodiments in the embodiments of the present disclosure when the computer program is executed by a processor.

It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations, but those skilled in the art should know that the present disclosure is not limited by the described action sequence. Because of this disclosure, certain steps may be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification belong to preferred embodiments, and the actions and modules involved are not necessarily required by the present disclosure.

In the foregoing embodiments, the descriptions of each embodiment have their own emphases, and for parts not described in detail in a certain embodiment, reference may be made to relevant descriptions of other embodiments.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or can be Integrate into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the disclosure may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented not only in the form of hardware, but also in the form of software program modules.

The integrated units may be stored in a computer-readable memory if implemented in the form of a software program module and sold or used as an independent product. Based on such an understanding, the essence of the technical solution of the present disclosure or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a memory. Several instructions are included to make a computer device (which may be a personal computer, server or network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present disclosure. The aforementioned memory includes various media capable of storing program codes such as U disk, ROM, RAM, mobile hard disk, magnetic disk or optical disk.

Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above-mentioned embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable memory, and the memory can include: a flash disk , read-only memory, random access device, magnetic disk or optical disk, etc.

The embodiments of the present disclosure have been introduced in detail above, and the principles and implementation methods of the present disclosure have been explained by using specific examples in this article. The descriptions of the above embodiments are only used to help understand the methods and core ideas of the present disclosure; at the same time, for Those skilled in the art may have changes in specific implementation methods and application scopes based on the idea of the present disclosure. In summary, the contents of this specification should not be construed as limiting the present disclosure.

Claims

A transaction processing method comprising:

Create the first microservice;

The first microservice corresponds to at least two transactions, the at least two transactions include a first transaction and a second transaction, and the first data source corresponding to the first transaction and the second transaction corresponding to the second transaction If the data sources are different, create a chained transaction manager;

The transaction corresponding to the first data source and the transaction corresponding to the second data source are processed by the chained transaction manager.
The method according to claim 1, wherein the method further comprises:

In the case where the first microservice corresponds to at least one transaction and the at least one transaction corresponds to the same target data source, then create a single data source transaction manager;

The at least one transaction is processed by the single data source transaction manager.
The method according to claim 2, wherein said creating a single data source transaction manager comprises:

In the case where the target data source is a default data source, the default transaction manager is configured through annotations, the default transaction manager realizes the transaction support of the default data source, and the single data source transaction manager includes all Describes the default transaction manager.
The method according to claim 1, wherein said creating a chained transaction manager comprises:

Create a transaction manager, and set the property of the transaction manager as a chained transaction manager through annotations.
The method according to any one of claims 1 to 4, wherein, before creating the first microservice, the method further comprises:

Receive the service request initiated by the client;

Determine at least one microservice involved in the service request, where the at least one microservice includes the first microservice.
The method according to claim 5, wherein said at least one microservice further comprises a second microservice, said method further comprising:

Create the second microservice, create a first message table or a first message set;

posting a first message related to the service request to a first message queue, and the second microservice is used to obtain the first message from the first message queue;

judging according to the identifier of the first message whether there is a message identical to the identifier of the first message in the first message table or the first message set;

If there is no message with the same identifier as the first message in the first message table or first message set, the first message is processed through the second microservice.
The method according to claim 6, wherein after the processing of the first message, the method further comprises:

In the case that the first message queue does not receive the message processing success confirmation message for the first message returned by the second microservice, the first message queue uses the best effort notification strategy to notify the The second microservice.
The method according to claim 6, wherein after the processing of the first message, the method further comprises:

After the first message is successfully processed, the first message is persisted in the first message table or first message set.
The method according to claim 6, wherein the method further comprises:

If there is a message with the same identifier as the first message in the first message table or first message set, the first message is discarded.
The method according to claim 6, wherein, after creating the first message table or the first message set, the method further comprises:

The table name of the first message table or the set name of the first message set is defined by an expression language.
The method according to claim 1, wherein the method further comprises:

An application listener is defined through a service discovery mechanism, and the application listener is used to configure a packet scanning path of the first microservice.
The method according to claim 1, wherein said creating the first microservice comprises:

The dynamic configuration and registration of the first microservice is realized through an automatic configuration mechanism.
The method according to any one of claims 1 to 11, wherein the method is implemented based on automatically configured pluggable components.
A transaction processing device comprising:

The first creation unit is configured to create the first microservice;

The second creation unit is configured to correspond to at least two transactions in the first microservice, the at least two transactions include a first transaction and a second transaction, and the first data source corresponding to the first transaction and the If the second data source corresponding to the second transaction is different, create a chained transaction manager;

The transaction processing unit is configured to process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager.
The device according to claim 14, wherein the second creation unit is further configured to: in the case where the first microservice corresponds to at least one transaction and the at least one transaction corresponds to the same target data source, then Create a single data source transaction manager;

The transaction processing unit is further configured to process the at least one transaction through the single data source transaction manager.
The device according to claim 15, wherein the second creation unit is configured to configure a default transaction manager through annotations when the target data source is a default data source, and the default transaction manager The transaction support of the default data source is realized, and the single data source transaction manager includes the default transaction manager.
The device according to claim 14, wherein the second creation unit is configured to create a transaction manager, and set the property of the transaction manager as a chained transaction manager through annotation.
The device according to any one of claims 14 to 17, wherein the device further comprises a receiving unit and a determining unit; wherein,

The receiving unit is configured to receive a service request initiated by a client;

The determining unit is configured to determine at least one microservice involved in the service request, and the at least one microservice includes the first microservice.
The device according to claim 18, wherein the at least one microservice further includes a second microservice, and the device further includes a delivery unit, a judging unit, and a message processing unit; wherein,

The first creating unit is further configured to create the second microservice, create a first message table or a first message set;

The delivery unit is configured to deliver a first message related to the service request to a first message queue, and the second microservice is used to obtain the first message from the first message queue;

The judging unit is configured to judge whether there is a message with the same identifier as the first message in the first message table or the first message set according to the identifier of the first message;

The message processing unit is configured to process the second message through the second microservice when there is no message with the same identifier as the first message in the first message table or the first message set. a message.
The device according to claim 19, wherein the device further comprises a notification unit configured to receive the second microservice in the first message queue after the message processing unit processes the first message In the case of the returned message processing success confirmation message for the first message, the second microservice is notified through the first message queue using a best-effort notification policy.
The device according to claim 19, wherein the device further comprises a persistence unit configured to persist the first message to the first message table or the first message table after the first message is successfully processed. in the message collection.
The device according to claim 19, wherein the message processing unit is further configured to, when a message with the same identifier as the first message exists in the first message table or the first message set, The first message is discarded.
The device according to claim 19, wherein the device further comprises a first definition unit configured to define the first The table name of the message table or the set name of the first message set.
The device according to claim 14, wherein the device further comprises a second definition unit configured to define an application listener through a service discovery mechanism, and the application listener is used to configure the packet scanning path of the first microservice .
The device according to claim 14, wherein the first creating unit is configured to implement dynamic configuration and registration of the first microservice through an automatic configuration mechanism.
A server, comprising a processor and a memory, the memory is used to store a computer program, the computer program includes program instructions, the processor is configured to invoke the program instructions, and execute any one of claims 1 to 13 method described in the item.
A computer-readable storage medium, the computer-readable storage medium stores a computer program, the computer program includes program instructions, and the program instructions, when executed by a processor, cause the processor to perform the any one of the methods described.
A computer program, which implements the transaction processing method according to any one of claims 1 to 13 when the computer program is executed by a processor.