Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Oracle Code One: Events and commands: developing asynchronous microservices

1,437 views

Published on

The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s accessible only indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging. In this session, you will learn how to solve these distributed data management challenges by using asynchronous messaging.

The presentation describes how to implement transactions with sagas, which are sequences of local transactions coordinated by use of messages. You will learn how to implement queries using command query responsibility segregation (CQRS), which uses events to maintain replicas, and will hear about the key role messaging plays in a microservice architecture.

Published in: Software
  • Be the first to comment

Oracle Code One: Events and commands: developing asynchronous microservices

  1. 1. @crichardson Events and commands: developing asynchronous microservices Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net http://learn.microservices.io Copyright © 2018. Chris Richardson Consulting, Inc. All rights reserved
  2. 2. @crichardson Presentation goal Using asynchronous messaging to implement transactions and queries in a microservice architecture
  3. 3. @crichardson About Chris
  4. 4. @crichardson About Chris Consultant and trainer focussed on helping organizations adopt the microservice architecture (http://www.chrisrichardson.net/)
  5. 5. @crichardson About Chris Founder of a startup that is creating an open-source/SaaS platform that simplifies the development of transactional microservices (http://eventuate.io)
  6. 6. @crichardson About Chris https://www.manning.com/books/microservices-patterns 40% discount with code cwtcodeone18
  7. 7. About Chris: microservices.io Microservices pattern language Articles Code examples Microservices Assessment Platform - coming soon
  8. 8. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS
  9. 9. The microservice architecture structures an application as a set of loosely coupled services
  10. 10. @crichardson API Service = independently deployable component Operations Event Publisher Commands Queries Synchronous REST/gRPC Asynchronous Messaging Events Event Subscriber API Client Invokes Operations Events Service Database
  11. 11. @crichardson Microservices enable continuous delivery/deployment Process: Continuous delivery/deployment Organization: Small, agile, autonomous, cross functional teams Architecture: Microservice architecture Enables Enables Enables Successful Software Development Services = testability and deployability Teams own services
  12. 12. @crichardson Let’s imagine that you are building an online store API createCustomer(creditLimit) createOrder(customerId, orderTotal) findOrdersForCustomer(customerId) findRecentCustomers() Order Management Customer Management REST API …
  13. 13. @crichardson Order Service createCustomer() createOrder() findOrdersForCustomer() findRecentCustomers() API Gateway createCustomer() createOrder() Order DatabaseCustomer Database Order tableCustomer table REST API REST API Essential for loose coupling Must reserve customer’s credit Retrieve data from both services Customer Service REST API availableCredit …. OrderTotal ….
  14. 14. @crichardson No ACID transactions that span services BEGIN TRANSACTION … SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ? … SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID = ? … INSERT INTO ORDERS … … COMMIT TRANSACTION Private to the Order Service Private to the Customer Service Distributed transactions
  15. 15. @crichardson Querying across services is not straightforward SELECT * FROM CUSTOMER c, ORDER o WHERE c.id = o.ID AND c.id = ? Private to Customer Service Private to Order Service Find customer and their orders
  16. 16. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS
  17. 17. @crichardson From a 1987 paper
  18. 18. @crichardson Saga Use Sagas instead of 2PC Distributed transaction Service A Service B Service A Local transaction Service B Local transaction Service C Local transaction X Service C https://microservices.io/patterns/data/saga.html
  19. 19. @crichardson Order Service Create Order Saga Local transaction Order state=PENDING createOrder() Customer Service Local transaction Customer reserveCredit() Order Service Local transaction Order state=APPROVED approve order() createOrder() Initiates saga
  20. 20. @crichardson Saga design challenges API design Synchronous REST API initiates asynchronous saga When to send back a response? Rollback compensating transactions Sagas are ACD - No I Sagas are interleaved anomalies, such as lost updates Must use countermeasures https://www.slideshare.net/chris.e.richardson/saturn-2018-managing-data-consistency-in-a-microservice-architecture-using-sagas
  21. 21. How do the saga participants communicate? Synchronous communication, e.g. REST = temporal coupling Client and server need to be both available Customer Service fails retry provided it’s idempotent Order Service fails Oops Order Service createOrder() REST Customer Service reserveCredit() REST
  22. 22. @crichardson Collaboration using asynchronous, broker-based messaging Order Service Customer Service …. Message broker At least once delivery ensures a saga completes when its participants are temporarily unavailable
  23. 23. @crichardson Saga step = a transaction local to a service Service Database Message Broker update publish message/event How to make atomic without 2PC?
  24. 24. @crichardson How to sequence the saga transactions? After the completion of transaction Ti “something” must decide what step to execute next Success: which T(i+1) - branching Failure: C(i - 1)
  25. 25. @crichardson Choreography: distributed decision making vs. Orchestration: centralized decision making
  26. 26. @crichardson Agenda Overview Choreography Orchestration Transactional messaging Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS
  27. 27. @crichardson Choreography-based coordination using events Order cancelled Order Service Customer Service DB DB Order created Domain event Subscriber updates its DB Abstracts message broker Message channel
  28. 28. @crichardson Message broker Choreography-based Create Order Saga Order created Credit Reserved Credit Limit Exceeded Create Order OR Customer creditLimit creditReservations Order state total create() reserveCredit() approve()/ reject() Order events channel Customer events channel Order Service Customer Service
  29. 29. @crichardson API Order Service Operations createOrder() Event Publisher Order events Event Subscriber Customer Events Service Database
  30. 30. @crichardson API Customer Service Operations createCustomer() Event Publisher Customer Events Event Subscriber Order Events Service Database
  31. 31. Benefits and drawbacks of choreography Benefits Simple, especially when using event sourcing Participants are loosely coupled Drawbacks Cyclic dependencies - services listen to each other’s events, e.g. Customer Service must know about all Order events that affect credit Overloads domain objects, e.g. Order and Customer know too much Events = indirect way to make something happen https://github.com/eventuate-examples/eventuate-examples-java-customers-and-orders
  32. 32. @crichardson Overview Choreography Orchestration Transactional messaging Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS
  33. 33. @crichardson Order Service Orchestration-based coordination using command messages Local transaction Order state=PENDING createOrder() Customer Service Local transaction Customer reserveCredit() Order Service Local transaction Order state=APPROVED approve order() createOrder() CreateOrderSaga InvokesInvokesInvokes
  34. 34. @crichardson Request/asynchronous reply- based communication Release credit Order Service Customer Service DB DB Reserve credit Command Customer service command channel Create Order saga Reply channel Reply Orchestrator Update Credit
  35. 35. @crichardson A saga (orchestrator) is a persistent object that tracks the state of the saga and invokes the participants
  36. 36. Saga orchestrator behavior On create: Invokes a saga participant Persists state in database Wait for a reply On reply: Load state from database Determine which saga participant to invoke next Invokes saga participant Updates its state Persists updated state Wait for a reply …
  37. 37. @crichardson Order Service CreateOrderSaga orchestrator Customer Service Create Order Customer creditLimit creditReservations ... Order state total… reserveCredit() CreateOrder Saga OrderService create() create() approve() Credit Reserved Customer command channel Saga reply channel
  38. 38. @crichardson API Order Service Operations createOrder() API Client Invokes Customer Service Service Database reserveCredit() releaseCredit()
  39. 39. @crichardson API Customer Service Operations createCustomer() reserveCredit() releaseCredit() Service Database Simple API
  40. 40. @crichardson Eventuate Tram Sagas Open-source Saga orchestration framework Currently for Java https://github.com/eventuate-tram/eventuate-tram-sagas https://github.com/eventuate-tram/eventuate-tram-sagas- examples-customers-and-orders
  41. 41. Benefits and drawbacks of orchestration Benefits Centralized coordination logic is easier to understand Reduced coupling, e.g. Customer Service knows less. Simply has API for managing available credit. Reduces cyclic dependencies Drawbacks Risk of smart sagas directing dumb services
  42. 42. @crichardson Overview Choreography Orchestration Transactional messaging Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS
  43. 43. @crichardson Messaging must be transactional Service Database Message Broker update publish How to make atomic without 2PC?
  44. 44. @crichardson Option: Event sourcing = Event centric approach to business logic and persistence http://eventuate.io/
  45. 45. @crichardson Event sourcing: persists an object as a sequence of events Event table Entity type Event id Entity id Event data Order 902101 …OrderApproved Order 903101 …OrderShipped Event type Order 901101 …OrderCreated Order create() approve() ship() Event Store
  46. 46. @crichardson Replay events to recreate in memory state Order state apply(event) Event table Entity type Event id Entity id Event data Order 902101 …OrderApproved Order 903101 …OrderShipped Event type Order 901101 …OrderCreated Event Store Load events by ID and call apply() Instantiate with default constructor Event store = database
  47. 47. @crichardson Event sourcing guarantees: state change -> event is published Event table Entity type Event id Entity id Event data Order 902101 …OrderApproved Order 903101 …OrderShipped Event type Order 901101 …OrderCreated Event Store Customer Service Subscribe Event store = message broker
  48. 48. @crichardson Preserves history of domain objects Supports temporal queries Built-in auditing Other benefits of event sourcing
  49. 49. @crichardson Evolving the schema of long-lived events Event store only supports PK- based access, requires CQRS Drawbacks of event sourcing
  50. 50. @crichardson Option: Traditional persistence (JPA, MyBatis,…) + Business logic calls event publishing API https://github.com/eventuate-tram/eventuate-tram-core
  51. 51. @crichardson Spring Data for JPA example Publish event Save order http://eventuate.io/exampleapps.html
  52. 52. @crichardson Atomically updating state and publishing events ACID transaction See BASE: An Acid Alternative, http://bit.ly/ebaybase DELETE ? Customer Service ORDER_ID CUSTOMER_ID TOTAL 99 CUSTOMER_CREDIT_RESERVATIONS table 101 1234 ID TYPE DATA DESTINATION MESSAGE table 84784 CreditReserved {…} … INSERT INSERT Message Publisher QUERY Message Broker Publish Local transaction reserveCredit()
  53. 53. @crichardson Publishing messages inserted into MESSAGE table Poll the MESSAGE table Simple But what about latency? Use Transaction log tailing a.k.a. change data capture Lower latency But implementation is database specific! MESSAGE Table Message Publisher Message Brokerhttp://eventuate.io/exampleapps.html
  54. 54. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS
  55. 55. @crichardson Queries often retrieve data owned by multiple services
  56. 56. @crichardson API Composition pattern Customer Service Customer … Order Service Order … API Gateway findOrdersForCustomer(customerId) GET /customer/id GET /orders?customerId=id FK query! https://microservices.io/patterns/data/api-composition.html
  57. 57. @crichardson Find recent, valuable customers SELECT * FROM CUSTOMER c, ORDER o WHERE c.id = o.ID AND o.ORDER_TOTAL > 100000 AND o.STATE = 'SHIPPED' AND c.CREATION_DATE > ? Customer Service Order Service …. is even more difficult!
  58. 58. API Composition would be inefficient 1 + N strategy: Fetch recent customers Iterate through customers fetching their shipped orders Lots of round trips high-latency Alternative strategy: Fetch recent customers Fetch recent orders Join 2 roundtrips but potentially large datasets inefficient
  59. 59. @crichardson Using events to update a queryable replica = CQRS Order Service Customer Service Order events Customer events findCustomersAndOrders() Order events channel Customer events channel Customer Order View Service Replica View Database https://microservices.io/patterns/data/cqrs.html
  60. 60. @crichardson Query side data model Command Query Responsibility Segregation (CQRS) Command side data model Commands Aggregate Message broker or Event Store Events Queries (Materialized) View Events POST PUT DELETE GET
  61. 61. @crichardson Queries database (type) Command side POST PUT DELETE Aggregate Event Store/Message Broker Events Query side GET /customers/id MongoDB Query side GET /orders?text=xyz ElasticSearch Query side GET … Neo4j
  62. 62. @crichardson A CQRS view can be part of a service Restaurant Service Restaurant events channel Transactional Source of truth CQRS replica for geo/text search createRestaurant() … findRestaurantsNear(location, keywords) MySQL Elastic
 Search
  63. 63. @crichardson Use a CQRS replica to validate commands Order Service createOrder() Customer Service Orders Customers creditLimit availableCredit Customer events Replica Checks available credit without invoking Customer Service
  64. 64. @crichardson Summary Use synchronous protocols, e.g. REST or gRPC: External APIs (Read only) API Composition Use asynchronous messaging to solve distributed data management problems Services publish events to implement choreography-based sagas queries using CQRS views Services publish events using either event sourcing or explicit publishing Services send command messages to implement orchestration-based sagas
  65. 65. @crichardson @crichardson chris@chrisrichardson.net http://learn.microservices.io Questions? 40% discount with code cwtcodeone18

×