current position:Home>Chapter 4 of the reading notes of microservice architecture design pattern uses saga to manage transactions

Chapter 4 of the reading notes of microservice architecture design pattern uses saga to manage transactions

2022-01-27 04:06:56 Polychlorinated cyclohexane


Preface

The traditional distributed transaction management method is not a good choice for modern applications , Cross service operations must use the so-called Saga( A message driven sequence of local transactions ) To maintain data consistency , instead of ACID Business ( Atomicity 、 Uniformity 、 Isolation and persistence ).

Saga One of the challenges is to only meet ACD( Atomicity 、 Consistency and persistence ) characteristic , And the lack of it ACID Isolation of transactions . Therefore, the application must use the so-called countermeasures (countermeasure), Find ways to prevent or reduce concurrent exceptions caused by lack of isolation

This is a book about microservice architecture design , Here are my study notes . Some symbols are explained below :

() To supplement , Usually the content in books ;
[] The symbol is the author's note ;


1. Transaction management in microservice architecture

Transactions under microservice architecture often need to span multiple services , Each service has its own private database . under these circumstances , Applications must use some more advanced transaction management mechanisms to manage transactions .

1.1 The challenge of distributed transactions

In multiple services 、 The traditional method of data consistency between database and message agent is distributed transaction .

The de facto standard for distributed transaction management is XA standard :

  • XA use Two-phase commit To ensure that all participants in the transaction commit at the same time , Or roll back at the same time in case of failure ;
  • The entire technology stack in the application needs to meet XA standard ( Include database 、 The message broker 、 Database driven 、 news API etc. );

The challenges are :

  • Many new technologies , Include NoSQL database ( Such as MongoDB and Cassandra), I won't support it XA Standard distributed transactions ;
  • Some popular message brokers ( Such as RabbitMQ and Apache Kafka) Distributed transactions are not supported ;
  • Distributed transactions are essentially synchronous interprocess communication , It will reduce the availability of Distributed Systems ;

1.2 One Saga An example of

Sage Pattern : By using asynchronous messages to coordinate a series of local transactions , So as to maintain data consistency among multiple services .

Create Order Saga Example
When the local transaction completes , The service will release messages . then , This message will trigger Saga The next step in .

1.3 Saga Use compensation transactions to roll back changes made

Saga Unable to automatically roll back transaction , Because each step commits its changes to the local database .

Saga Compensation Affairs
Note that not all steps require transaction compensation , Such as read-only steps 、 When the operation after a certain step will always succeed, etc .


2. Saga The coordination model of

Saga The implementation of includes coordination Saga The logic of the steps .

2.1 Two kinds of Saga Coordination mode

  • Collaborative (choreography): hold Saga The decision-making and execution order logic of is distributed in Sage Of every participant in , They communicate by exchanging Events ;
  • Choreography (orchestration):【 recommend 】 hold Saga The logic of decision-making and execution order is concentrated in one Saga In the choreographer class .Saga The choreographer sends command messages to each Saga Participant , Specify these participant services to complete specific operations ( Local transactions );

2.2 Achieve collaborative Create Order Saga

Participants communicate by exchanging events , Each participant from Order Service Start , Update its database and publish the event that triggers the next participant .

  • When the first 5 When step fails , The event name created is :Credit card authorization failed;

 Achieve collaborative Create Order Saga
The illustration

  1. Order Service Create a place in APPROVAL_PENDING State of Order And publish OrderCreated event ;
  2. Consumer Service consumption OrderCreated event , Verify that consumers can place orders , And publish ConsumerVerified event ;
  3. Kitchen Service consumption OrderCreated event , verification Order, Create a place in CREATE_PENDING Back kitchen work order in status Ticket, And publish TicketCreated event ;
  4. Accounting Service consumption OrderCreated Event and create one in PENDING State of CreditCardAuthorization;
  5. Accounting Service consumption TicketCreated and ConsumerVerified event , Charging consumers for their credit cards , And publish CreditCardAuthorized event ;
    • If you fail , Then release CreditCardAuthorizationFailed event ;
  6. Kitchen Service consumption CreditCardAuthorized event , take Ticket Is changed to AWAITING_ACCEPTANCE;
    • If you fail , Consumption CreditCardAuthorizationFailed event , take Ticket Is changed to REJECTED;
  7. Order Service receive CreditCardAuthorized event , take Order Change the status of APPROVED, And publish OrderApproved event ;
    • If you fail , Consumption CreditCardAuthorizationFailed event , take Order Is changed to REJECTED;

2.3 Collaborative Sage Problems related to inter service communication

In the implementation of Collaborative Saga when , Some issues related to communication between services need to be considered :

  • Make sure Saga Participants will update their local database and publish events as part of the database transaction ;
    • for example : stay Create Order Saga in ,Kitchen Service Accept CreditCarAuthorized event , establish Ticket, Publish to TicketCreated event ; Database updates and event publishing must be atomic ;
    • solve :Saga Participants must use transactional messages ;
  • Make sure Saga Participants must be able to map each event they receive to their own data ;
    • for example : When Order Service received CreditCardAuthorized When an event is , It must be able to find the corresponding Order;
    • solve : Give Way Saga Participant releases contain The correlation ID Events ;

2.4 Collaborative Sage Advantages and disadvantages

benefits

  • Simple : The service is creating 、 Publish events when updating and deleting business objects ;
  • loose coupling : Participants subscribe to events and are not coupled to each other ;

disadvantages

  • It's harder to understand : Coordinated Saga The logic of is distributed in the implementation of each service ; Developers sometimes have difficulty understanding specific Saga How it works ;
  • Circular dependencies between services :Saga Participants subscribe to each other's events , It usually leads to circular dependencies ;
  • Risk of tight coupling : Every Saga Participants need to subscribe to all events that affect them ;

2.5 Realize choreographic Create Order Saga

Developers define an orchestrator class , The only duty of this class is to tell Saga What should the participants do .Saga The choreographer uses the command / Asynchronous response mode and Saga Participant service communication .
Based on choreography is Saga Each step of includes a service that updates the database and publishes messages .

 Realize choreographic Create Order Saga

The illustration

Order Service First create ( Instantiation ) One Order Object and a Create Order Saga Choreographer object , After everything is normal, the process is as follows :

  1. Saga The choreographer to Consumer Service send out Verify Consumer command ;
  2. Consumer Service reply Consumer Verified news ;
  3. Saga The choreographer to Kitchen Service send out Create Ticket command ;
  4. Kitchen Service reply Ticket Created news ;
  5. Saga The choreographer to Accounting Service send out Authorize Card news ;
  6. Accounting Service Use Card Authorized Message reply ;
  7. Saga The choreographer to Kitchen Service send out Approve Ticket command ;
  8. Saga The choreographer to Order Service send out Approve Ordere command ( Imperative messages );

2.6 hold Saga The choreographer is treated as a state machine

A state machine consists of transitions between a set of States and a set of States triggered by events . Each transition can have an action , Yes Saga For example, an action is a call to a participant .

take Saga Modeling as a state machine is very useful , Because it describes all possible scenarios ( It can be a success or a failure ).

Create Order Saga State machine model

  • Verifying Consumer: The initial state . When in this state , The Saga Is waiting for Consumer Service Verify that consumers can place orders ;
  • Creating Ticket: The Saga Waiting for Create Ticket A reply to an order ;
  • Authorizing Card: wait for Authorizing Service Authorized consumer's credit card ;
  • Order Approved: A final state , It means that we should Saga Has been successfully completed ;
  • Order Rejected: A final state , Express Order Rejected by one of the participants ;

2.7 Choreography Saga Advantages and disadvantages

benefits

  • Simpler dependencies : Circular dependencies are not introduced ;
  • Less coupling : Each service implements the services that are invoked by the choreographer API, So it doesn't need to know Saga Events posted by participants ;
  • Improve focus isolation , Simplify business logic :Saga The coordination logic is localized in Saga In the choreographer ; Domain objects are simpler , And you don't need to know what they're involved in Saga;

disadvantages

  • There is a risk of concentrating too much business logic in the choreographer ;
    • terms of settlement : You can avoid this problem by designing a choreographer that is only responsible for sorting , And does not contain any other business logic ;

3. Solve the isolation problem

ACID The isolation of transactions ensures that the results of executing multiple transactions at the same time are the same as those of executing them sequentially . and Saga Only satisfied ACD( Atomicity 、 Uniformity 、 persistence ), Does not satisfy the isolation .

3.1 Saga Only satisfied ACD

  • Atomicity :Saga Implementation ensures that all transactions are executed or all changes are undone ;
  • Uniformity : Referential integrity within services (referential integrity) Processed by the local database ; Referential integrity between services is handled by services ;
  • persistence : Processed by the local database ;

3.2 Problems caused by lack of isolation

Lack of isolation will lead to the following three exceptions .

  • Lost update : One Saga No updates were read , It directly covers another Saga Changes made ;
  • Dirty reading : A transaction or a Saga Read unfinished Saga Updates made ;
  • Vague or unrepeatable : One Saga Two different steps of reading the same data get different results , Because the other Saga It has been updated ;

3.3 Saga Structural model terminology

One Saga There are three types of transactions .

  • Compensatory transactions : Transactions that can be rolled back using compensation transactions ;
  • Key issues :Saga Key nodes in the execution process . If a critical transaction succeeds , be Saga Will run until complete . A critical transaction is not necessarily a compensatory transaction , Or repeatable transactions . But it can be the last reimbursable transaction or the first repeatable transaction ;
  • Repeatable transactions : Transactions after critical transactions , Guarantee success ;

 One Saga There are three types of transactions .png

3.4 Countermeasures to solve the isolation problem

  • Semantic lock : Application level locks ;
    • Saga A compensatory transaction of sets a flag in any record it creates or updates , This flag indicates that the record is not submitted and may fail ;
    • Such as : Add... To the operation object when the compensatory transaction is executed *_PENDING state , To tell the other... Of the object Saga, The object is currently in a Saga In the process of processing ;
  • Swap update : The update operation is designed to be executed in any order ;
    • Design update operations to be exchangeable ;
    • Such as : account debit() and credit() Operations are interchangeable ;
  • Pessimistic view : reorder Saga Steps for , To minimize business risk ;
    • reorder Saga Steps for , To minimize the business risk caused by dirty reading ;
  • Reread value : Prevent dirty writes by rewriting data , To verify that the data remains unchanged before overwriting it ;
    • Using this countermeasure Saga Reread the record before updating , Verify that it has not changed , Then root record ; If the record has changed , be Saga Will abort and possibly restart . This countermeasure is a form of optimistic offline lock mode ;
    • Such as : It can be used to deal with Order Cancellation during the approval process ;
  • Version file : Record the updates , So that they can be reordered ;
    • Record the operations performed on the data , So that they can be reordered ;
    • Such as : When Accounting Service Receive first Cancel Authorization request , Again Authorize Card When asked , It will notice that it has received Cancel Authorization Request and skip authorized credit cards ;
  • Business risk rating (by value): Use the business risk of each request to dynamically select the concurrency mechanism ;
    • The application that uses this countermeasure uses the properties of each request to decide to use Saga And distributed transactions ;

4. Order Service and Create Order Saga The design of the

Example : Using semantic lock game Create Order Saga Detailed design and implementation of .

4.1 Order Service Design and application of Saga

Order Service Design and application of Saga

  • The business logic of a service consists of traditional business logic classes , Just like traditional business , The core business consists of OrderServiceOrder and OrderRepository Class implementation ;
  • Some more Saga Choreographer class , Include CreateOrderSaga class , It can be arranged Create Order Saga;
  • Order Service It's a Saga Choreographer , Also a Saga Participant ;Order Service Participate in its own Saga, It has one OrderCommandHandlers The adapter class , The adapter class calls Order Service To process command messages ;

4.2 OrderService class

A service by API Domain services invoked by layer , Responsible for creating and managing orders .

OrderService Of UML Class diagram
OrderService Of UML Class diagram
OrderService Class and createOrder() Method

 Insert picture description here

4.3 Create Order Saga The implementation of the

Use Eventuate Tram Saga Framework preparation , It provides a domain specific language (DSL), Used for definition Saga The state of .

OrderService Of Saga UML Class diagram
OrderService Of Saga

  • CreateOrderSaga: Definition Saga Singleton class of state machine ; It calls CreateOrderSagaState To create imperative messages , And use Saga Party agent class ( Such as KitchenServiceProxy) The specified message channel sends them to the participants ;
  • CreateOrderSagaState: One Saga Persistent state of , Used to create imperative messages ;
  • Saga Agent class of the participant ( Such as KitchenServiceProxy): Each proxy class defines a Saga Messages from participants API, It consists of a command channel 、 Command message and reply type .

4.4 CreateOrderSaga Choreographer

CreateOrderSaga Class implements the 2.6 Point state machine ; It USES Eventuate Tram Saga Framework provided DSL To define Create Order Saga Steps for ; The core code is Saga The definition of , as follows :

CreateOrderSaga The definition of a class

4.5 CreateOrderSagaState class

CreateOrderSagaState Class represents Saga Instance status ; This is due to OrderService establish , And by the Eventuate Tram Saga The framework is persisted in the database ; Its responsibility is to create and send to Saga Messages from participants ;

CreateOrderSagaState preservation Saga Status of the instance

4.6 KitchenServiceProxy class

Proxy classes are not necessary , There are two benefits of using proxy classes : Proxy classes define statically typed endpoints , This reduces Saga The possibility of sending an error message to the service ; A proxy class is a well-defined method for invoking services API, Make service code easier to understand and test ;

KitchenServiceProxy class

4.7 Eventuate Tram Saga frame

Eventuate Tram Saga It's one for writing Saga Choreographer and Saga The framework of the participants ; It USES Eventuate Tram Transactional messaging capabilities .

Eventuate Tram Saga frame
Eventuate Tram Saga frame

OrderService establish Create Order Saga The sequence of events at the time of the instance
OrderService establish Create Order Saga The sequence of events at the time of the instance

When SagaManager Received from Saga The sequence of events when a participant replies to a message

 When SagaManager Received from Saga The sequence of events when a participant replies to a message

4.8 OrderCommandHandlers class

Order Service Participate in their own Saga;OrderCommandHandlers Class defines these Saga The handler method that initiates the imperative message .

OrderCommandHandlers UML Class diagram

OrderCommandHandlers UML Class diagram

Order Service Command handler for

Order Service Command handler for

4.9 OrderServiceConfiguration class

Order Service Use Spring frame ;OrderServiceConfiguration It's a @Configuration class , Use Spring @Bean Instantiate and assemble together .

OrderServiceConfiguration class


5. Summary of this chapter

  • Some system operations need to update data scattered across multiple services . Traditional based on XA / 2PC Distributed transactions are not suitable for modern applications . A better way is to use Saga Pattern .Saga Is a set of local transaction sequences coordinated using the message mechanism . Each local transaction updates data in a single service . Because every local transaction commits changes , So if it is caused by a violation of business rules Saga Must roll back , You must perform a compensation transaction to explicitly undo the changes ;
  • You can use collaboration or orchestration to coordinate Saga Steps for . Based on collaboration Saga in , The local transaction publishes events that trigger other participants to execute local transactions . Based on choreography Saga in , Centralized Saga The orchestrator sends an imperative message to the participants , Tell them to perform local transactions . It can be done by putting Saga The choreographer is modeled as a state machine to simplify development and testing , ordinary Saga Collaborative... Can be used , But the layout is usually complex Saga Better choice for ;
  • The design is based on Saga Your business logic can be challenging , Because with ACID Transactions are different ,Saga Not isolated from each other . You must always use various countermeasures , That is to prevent ACD Design strategy of concurrency exception caused by transaction model . Applications may even need to use locks to simplify logic , Even if this causes a deadlock .


Last

New people make , If there is a mistake , Welcome to point out , Be deeply grateful !
Welcome to the official account , Will share something more everyday !
If you want to reprint , Please mark the source !

copyright notice
author[Polychlorinated cyclohexane],Please bring the original link to reprint, thank you.
https://en.cdmana.com/2022/01/202201270406547872.html

Random recommended