Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Saga about distributed business transactions in microservices world

Most of people nowadays think microservices architecture is a great way to build any system. They visit conference talks, read books and review tutorials, where ‘hello world’ applications are built just in several minutes using microservices approach. But the reality is not so wonderful and one of the biggest pain is hidden inside distributed business transactions. In monolith application this topic is almost completely covered with DB level transactions. In distributed world you have to face many issues trying to implement reliable and consistent business logic.

In this talk we will review different types of problems related to distributed business transactions, popular SAGA pattern, frameworks and techniques to simplify your life without compromising quality of the system.

  • Soyez le premier à commenter

Saga about distributed business transactions in microservices world

  1. 1. Saga about distributed business transactions in microservices world Mikalai Alimenkou @xpinjection https://t.me/xpinjection_channel https://xpinjection.com
  2. 2. Telegram channel https://t.me/xpinjection_channel
  3. 3. Disclaimer This talk is based on personal experience
  4. 4. Local ACID transactions universe
  5. 5. Developers love this universe High level abstractions like Spring Data hide real SQL requests from developer New generation of developers doesn’t pay attention to low level RDBMS rules Hibernate controls queries ordering and execution timeline Developers believe in transactions magic, so always feel comfortable about data consistency
  6. 6. Microservices destroyed this universe
  7. 7. Distributed transactions are everywhere
  8. 8. Real world transactions…
  9. 9. First rule of microservices club: be optimistic and don’t raise complex questions!
  10. 10. Hello world samples on conferences
  11. 11. Some books tell you truth about microservices complexity…
  12. 12. Saga pattern definition https://microservices.io/patterns/data/saga.html Implement each business transaction that spans multiple services as a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.
  13. 13. Very hot “modern” topic! https://bit.ly/2ObxFY5
  14. 14. SAGA pattern is our new reality!
  15. 15. Actually we have to deal with state machines https://bit.ly/2OaAfgG
  16. 16. Now I have to control every operation manually and think about compensations, Carl!
  17. 17. Domain Context is a king https://speakerdeck.com/mploed/implementing-ddd-with-the-spring-ecosystem
  18. 18. Conference attendee example https://speakerdeck.com/mploed/implementing-ddd-with-the-spring-ecosystem
  19. 19. Options to reduce Saga complexity Reorder steps to minimize business risks Hide intermediate data with flags or statuses Use CQRS or data replication for local consistency constraints Avoid synchronous communication between services Rely on retriable idempotent operations Prefer optimistic locking with data versioning Use distributed locking tools for critical cases
  20. 20. Choreography-based SAGA https://bit.ly/2XA090m
  21. 21. Kafka is a new king
  22. 22. Make messaging transactional
  23. 23. Use CDC tools and techniques
  24. 24. Orchestration-based SAGA
  25. 25. Orchestration-based SAGA https://bit.ly/2KIqKDi
  26. 26. Orchestration vs Choreography Centralized orchestration of the distributed transaction Services remain simple and don’t know about external transaction, could be reused in other scenarios Linear complexity for any number of services Easier to implement, visualize, test and maintain Rollback is easier to manage and track Single point of failure because logic is centralized Broken encapsulation on orchestrated services
  27. 27. Eventuate.io: usage pattern
  28. 28. Eventuate.io: Saga definition in code http://eventuate.io/abouteventuatetram.html
  29. 29. Eventuate.io: Saga definition in code https://bit.ly/2Oe2n2A
  30. 30. Axon: Saga implementation @SagaEventHandler for Saga related events handling SagaRepository to store and retrieve Saga context SagaManager as core component for Saga processing SagaStore for different storages support for Saga data (Jdbc, MongoDb, in memory, JPA) https://bit.ly/2QFBnea - reference documentation https://bit.ly/2KF4z12 - sample repository https://bit.ly/2D6gjp6 – how-to tutorial
  31. 31. Axon: Saga definition in code
  32. 32. Camunda: usage pattern https://github.com/berndruecker/trip-booking-saga-java https://www.youtube.com/watch?v=tBzMLH1K7NU
  33. 33. Camunda: graphical representation
  34. 34. Camunda: Saga definition in code
  35. 35. Serverless future is coming…
  36. 36. AWS Step Functions: usage pattern
  37. 37. AWS Step Functions: Saga definition https://yos.io/2017/10/30/distributed-sagas/
  38. 38. Summary and take aways Business transactions in microservices world are much more complex than local ACID You don’t always have to use Saga Pay attention to consistent messaging Try to rely on simple patterns to avoid Saga usage Use Events/Choreography for simple flows, switch to Command/Orchestration only for complex scenarios Don’t reinvent the wheel, prefer existing frameworks
  39. 39. @xpinjection https://xpinjection.com https://t.me/xpinjection_channel