Distributed transaction solutions for MicroServices architectures

In a distributed system architecture, a distributed transaction problem is a challenge that is not in the past. And the popularity of micro-service architecture, so that distributed issues increasingly prominent!

Below we are in the e-commerce shopping payment process, in the major participant system may encounter distributed transaction problem scenarios for detailed analysis!

As shown, it is assumed that the systems of the three participating platforms (e-commerce platform, payment platform, bank) have distributed system architecture split and analyzed according to the process steps in the previous number:

1, e-commerce platform to create orders: Reserve inventory, pre-deduction points, lock coupons, at this time in the e-commerce platform between the services there will be distributed transaction issues, because at this time has to be across multiple internal services to modify data;

2, the payment platform to create payment orders (choose Bank card Payment): Query account, query restrictions rules, meet the conditions of the creation of payment orders and jump to the bank, there will be no distributed transaction problems, because the data will not be changed across the service;

3. Create a trading order in the Bank platform: Find an account, create a transaction, determine the account balance and debit, add points, notify the payment platform, there will also be distributed transaction issues (if it is a service-based architecture);

4. Payment platform receives bank debit result: Change Order status, add Money to account, add points to points account, generate accounting entries, notify e-commerce platform, etc., there will be distributed issues;

5, e-commerce platform received payment platform payment results: Change Order status, deduction of inventory, deduction points, the use of coupons, increase consumption points, etc., the system internal calls will also encounter distributed issues;

For example, the payment platform after receiving the bank debit results of the internal processing process:

1, payment platform of the payment gateway to the bank to verify the results of the notification, and then call the payment order service execution payment order processing;

2. The payment order service changes the status of the payment order according to the bank debit result;

3, call the Fund account service to the e-commerce platform of the merchant account (the actual process may also have a variety of cost billing, if the balance is paid, it may also be deducted from the user account, to the merchant account to add money);

4, the call points service to the user points account to increase points;

5, call accounting services to the Accounting (financial) system to write into the transaction of the original document to generate accounting entries;

6, call Notification Service will pay the processing results notify the e-commerce platform;

For example, the code scenario for a distributed transaction problem is extracted from the successful callback processing process of the bank debit in the payment system:

/** Payment Order Processing **/

@Transactional (rollbackfor = exception.class)

public void CompleteOrder () {

Orderdao.update (); Order Service Update order status locally

Accountservice.update (); Call funds account service to fund account Plus

Pointservice.update (); Call Points service to add points to points account

Accountingservice.insert (); Call Accounting service to write accounting source documents to accounting system

Merchantnotifyservice.notify (); Call Merchant Notification Service to send payment result notification to merchant

}

is local transaction control possible?

The above distributed transaction problems require a variety of distributed transaction solutions for processing.

Order Processing: Local transactions

Capital account Plus, points account added points: TCC type Transaction (or two-phase commit transaction), real-time requirements are relatively high, the data must be reliable.

Accounting: Asynchronous guaranteed transactions (based on the final consistency of reliable messages, can be asynchronous, but the data must never be lost, and be sure to keep the accounting successful)

Merchant Notification: Maximum effort notification type transaction (according to the regular notification, does not guarantee that the data will be able to notify the success, but will provide a queryable interface to check)

For the issue of distributed transactions, it is recommended to refer to the "Distributed transaction solution for MicroServices Architecture" tutorial in Http://www.roncoo.com, a detailed and complete solution

Distributed transaction solutions for MicroServices architectures