Skip to content

Latest commit

 

History

History
270 lines (185 loc) · 7.96 KB

saga-jbug.adoc

File metadata and controls

270 lines (185 loc) · 7.96 KB
Raw

Saga over REST for microservices

Ondra Chaloupka / ochaloup@redhat.com

!

narayana logo

  • earlier Arjuna, renamed to Narayana

  • JTA implementation in JBoss/WildFly

  • JTS distributed transaction over IIOP

  • webservice transactions (WS-AT/WS-BA)

  • STM for Vert.x

  • saga transactions over REST

Agenda

  • What is meant under term microservice in scope of this presentation

  • How the the distributed transactions and 2PC works

  • What is saga and why could be good fit for microservice architecture

  • What are and how to use Narayana Long Running Actions

!

background

Distributed transactions

posta msa with wfly

An ACID transaction

  • An atomic unit of the work where everything or nothing is finished

    • usually in regards of data manipulation

  • Protecting shared resources from multiple users

  • A notion of a global consensus

  • ACID properties guaranteed

!

test tubes

  • A�tomicity

  • C�onsistency

  • I�solation

  • D�urability

Note
Atomicity

"all or nothing", all operations in a transaction succeed or every operation is rolled back

Consistency

on the completion of a transaction, the database is structurally sound that covers e.g. preserve foreign keys, uniqueness defined by schema etc.

Isolation

transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.

Durability

the results of applying a transaction are permanent, even in the presence of failures

Distributed vs. XA transaction

  • distributed transaction runs over multiple services

  • XA transaction joins operations over multiple resources

XA handling

xa handling

XA transaction: 2PC

2pc

Demo

posta msa with wfly xa

Note

ACID distributed transactions: assuming

  • closely coupled environment

    • harder to scale

    • tight data coupling

  • short duration

    • locking reduces parallelism

Microservice architecture: expecting

  • loosely coupling

  • scaling

  • long duration activities

Sagas

  • Transactional model for long living transaction

  • Saga paper (H. Garcia-Molina, K. Salem; 1987)

  • Relaxing ACID properties

  • Eventual consistent

  • Web services: WS-BA specification, SOA design pattern

  • REST and event sourcing: microservices

Note

Original paper talks about Saga as a solution for long-lived database transactions. We can use it for distributed environment too for not using two phase commit (a.k.a. locks).

Other names:

Sagas (#2)

saga confirm

  • consists of a sequence of autonomous operations, each immediatelly visible to outer world

  • responsibility of failures handling to developer (handlers)

  • transaction manager is responsible for calling handlers

Sagas (#3)

saga compensate

  • compensation handler defined by developer, called by transaction manager

Saga transaction

saga

Note

The concept of the original paper talks about single node database but it could be applied to distributed transactions (as was already shown).

Saga could be classified as Base transaction (at least from my understanding) as it does not lock resources a.k.a locks and letting data of resources being available for other transactions to work with.

As you could see the transaction handling introduced by Saga requires the application to define compensation actions or define actions as idempotent (you can repeat operation on the resource multiple times and you will get the same result - operation being repeated not leading to a different outcome).

Still you can handle all the data integrity yourself in your application and design your system architecture to handle with failures. It’s up to you if concept of Saga is useful for you or not.

Narayana and Sagas

  • XTS: WS-BA (Web Services Business Activity)

  • Compensating transactions (CDI annotations)

  • LRA (Long Running Actions, over REST)

Note

Narayana LRA

  • LRA: Long Running Actions

  • Saga implementation for REST calls

  • based on the Eclipse MicroProfile stack (JAX-RS, CDI)

Demo

msa calls

Note

To get logs for the particular services:

  • oc logs -f `oc get pods | grep ^ola | grep Running | awk '{ print $1 }'`

  • oc logs -f `oc get pods | grep ^hola | grep Running | awk '{ print $1 }'`

  • oc logs -f `oc get pods | grep ^aloha | grep Running | awk '{ print $1 }'`

  • oc logs -f `oc get pods | grep ^bonjour | grep Running | awk '{ print $1 }'`

Summary

  • Narayana LRA - implementation of Saga for REST calls

  • a better fit for MSA than ACID transactions

  • a tool that can help in desiging the application

    • MSA principles should be preserved

!

cajk