Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
@crichardson
Events and Commands:
Developing Asynchronous
Microservices
Chris Richardson
Founder of Eventuate.io
Founder o...
@crichardson
Presentation goal
Implementing transactions and
queries in a microservice
architecture using
asynchronous mes...
@crichardson
Presentation goal
Microservices > REST
Microservices > Events
Microservices != Event Sourcing
Apache Kafka !=...
@crichardson
About Chris
microservices.io eventuate.io
@crichardson
About Chris
https://microservices.io/book
@crichardson
Agenda
Transactions, queries and microservices
Managing transactions with sagas
Implementing queries with CQR...
The microservice architecture
structures
an application as a
set of loosely coupled
services
@crichardson
API
Service = independently deployable
component
Operations
Event
Publisher
Commands
Queries
Synchronous
REST...
@crichardson
Microservices enable
continuous delivery/deployment
Process:
Continuous delivery/deployment
Organization:
Sma...
@crichardson
Let’s imagine that you are
building an online store API
createCustomer(creditLimit)
createOrder(customerId, o...
@crichardson
Order
Service
createCustomer()
createOrder()
findOrdersForCustomer()
findRecentCustomers()
API Gateway
createCu...
@crichardson
No ACID transactions that span
services
BEGIN TRANSACTION
…
SELECT ORDER_TOTAL
FROM ORDERS WHERE CUSTOMER_ID ...
@crichardson
Querying across services is
not straightforward
SELECT *
FROM CUSTOMER c, ORDER o
WHERE
c.id = o.ID
AND c.id ...
@crichardson
Agenda
Transactions, queries and microservices
Managing transactions with sagas
Implementing queries with CQR...
@crichardson
From a 1987 paper
@crichardson
Saga
Use Sagas instead of 2PC
Distributed transaction
Service A Service B
Service A
Local
transaction
Service...
@crichardson
Order Service
Create Order Saga
Local transaction
Order
state=PENDING
createOrder()
Customer Service
Local tr...
@crichardson
Saga design challenges
API design
Synchronous REST API initiates asynchronous saga
When to send back a respon...
How do the saga participants
communicate?
Synchronous
communication, e.g. REST
= temporal coupling
Client and server need ...
@crichardson
Collaboration using asynchronous,
broker-based messaging
Order Service
Customer
Service
….
Message broker
@crichardson
About the message broker
At least once delivery
Ensures a saga completes when its participants are temporaril...
@crichardson
Saga step = a transaction
local to a service
Service
Database Message Broker
update publish message/event
How...
@crichardson
How to sequence the saga
transactions?
After the completion of transaction Ti “something” must
decide what st...
@crichardson
Choreography: distributed decision making
vs.
Orchestration: centralized decision making
@crichardson
Transactions, queries and microservices
Managing transactions with sagas
Implementing queries with CQRS
Imple...
@crichardson
Message broker
Choreography-based Create Order
Saga
Order created
Credit Reserved
Credit Limit Exceeded
Creat...
Benefits and drawbacks of
choreography
Benefits
Simple, especially when using event
sourcing
Participants are loosely couple...
@crichardson
Agenda
Transactions, queries and microservices
Managing transactions with sagas
Implementing queries with CQR...
@crichardson
Order Service
Orchestration-based coordination using
command messages
Local transaction
Order
state=PENDING
c...
@crichardson
A saga (orchestrator)
is a persistent object
that
implements a state machine
and
invokes the participants
Saga orchestrator behavior
On create:
Invokes a saga participant
Persists state in database
Wait for a reply
On reply:
Loa...
@crichardson
Order Service
CreateOrderSaga orchestrator
Customer Service
Create Order
Customer
creditLimit
creditReservati...
Benefits and drawbacks of
orchestration
Benefits
Centralized coordination
logic is easier to understand
Reduced coupling, e....
@crichardson
Agenda
Transactions, queries and microservices
Managing transactions with sagas
Implementing queries with CQR...
@crichardson
Queries often retrieve data
owned by multiple services
@crichardson
API Composition pattern
Customer Service
Customer
…
Order Service
Order
…
API Gateway
findOrdersForCustomer(cu...
@crichardson
Find recent, valuable
customers
SELECT *
FROM CUSTOMER c, ORDER o
WHERE
c.id = o.ID
AND o.ORDER_TOTAL > 10000...
API Composition would be
inefficient
1 + N strategy:
Fetch recent customers
Iterate through customers
fetching their shippe...
@crichardson
Using events to update a queryable
replica = CQRS
Order
Service
Customer
Service
Order events
Customer events...
@crichardson
Persisting a customer and
order history in MongoDB
{
"_id" : "0000014f9a45004b 0a00270000000000",
"name" : "F...
@crichardson
Query side data model
Command Query Responsibility
Segregation (CQRS)
Command side data model
Commands
Aggreg...
@crichardson
Queries database (type)
Command side
POST
PUT
DELETE
Aggregate
Event Store/Message Broker
Events
Query side
G...
@crichardson
CQRS views are disposable
Rebuild when needed from source of truth
Using event sourcing
(Conceptually) replay...
@crichardson
Handling replication lag
Lag between updating command side and CQRS view
Risk of showing stale data to user
E...
@crichardson
Agenda
Transactions, queries and microservices
Managing transactions with sagas
Implementing queries with CQR...
@crichardson
Messaging must be
transactional
Service
Database Message Broker
update publish
How to
make atomic
without 2PC?
Publish to message broker
first?
Guarantees atomicity
BUT
Service can’t read its own
writes
Difficult to write business
logi...
@crichardson
Option: Event sourcing
=
Event centric approach to
business logic and persistence
http://eventuate.io/
@crichardson
Event sourcing: persists an object
as a sequence of events
Event table
Entity type
Event
id
Entity
id
Event
d...
@crichardson
Replay events to recreate in memory state
Order
state
apply(event)
Event table
Entity type
Event
id
Entity
id...
@crichardson
FYI:
Apache Kafka != event store
@crichardson
Event sourcing guarantees: state
change event is published
Event table
Entity type
Event
id
Entity
id
Event
d...
@crichardson
Preserves history of domain objects
Supports temporal queries
Simplifies retroactive correction
Built-in audit...
@crichardson
Unfamiliar programming model
Evolving the schema of long-lived events
Event store only supports PK-based acce...
@crichardson
Good fit for choreography-based sagas
BUT orchestration is more challenging
Use event handler to translate eve...
@crichardson
Option:
Traditional persistence
(JPA, MyBatis,…)
+
Transactional outbox pattern
https://github.com/eventuate-...
@crichardson
Spring Data for JPA example
Publish event
Save order
http://eventuate.io/exampleapps.html
@crichardson
Transactional outbox pattern
ACID
transaction
See BASE: An Acid Alternative, http://bit.ly/ebaybase
DELETE
?
...
@crichardson
Transaction log tailing
Order
Service
Datastore
ORDER table
Transaction log
Update
Transaction log
miner
Mess...
@crichardson
Polling the message table
Simple
Works for all databases
BUT what about polling frequency
MESSAGE
Table
Messa...
@crichardson
Summary
Use asynchronous messaging to solve distributed data management problems
Services publish events to i...
@crichardson
@crichardson chris@chrisrichardson.net
http://learn.microservices.io
Questions?
Nächste SlideShare
Wird geladen in …5
×

YOW2018 - Events and Commands: Developing Asynchronous Microservices

948 Aufrufe

Veröffentlicht am

The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging.

In this presentation, you will learn how to solve these distributed data management challenges using asynchronous messaging. I describe how to implement transactions using sagas, which are sequences of local transactions, coordinated using messages. You will learn how to implement queries using Command Query Responsibility Segregation (CQRS), which uses events to maintain replicas. I describe how to use event sourcing, which is an event-centric approach to business logic and persistence, in a microservice architecture.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

YOW2018 - 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 Implementing transactions and queries in a microservice architecture using asynchronous messaging
  3. 3. @crichardson Presentation goal Microservices > REST Microservices > Events Microservices != Event Sourcing Apache Kafka != Event Store
  4. 4. @crichardson About Chris microservices.io eventuate.io
  5. 5. @crichardson About Chris https://microservices.io/book
  6. 6. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS Implementing transactional messaging
  7. 7. The microservice architecture structures an application as a set of loosely coupled services
  8. 8. @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
  9. 9. @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
  10. 10. @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 …
  11. 11. @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 ….
  12. 12. @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
  13. 13. @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
  14. 14. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS Implementing transactional messaging
  15. 15. @crichardson From a 1987 paper
  16. 16. @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
  17. 17. @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
  18. 18. @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
  19. 19. 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
  20. 20. @crichardson Collaboration using asynchronous, broker-based messaging Order Service Customer Service …. Message broker
  21. 21. @crichardson About the message broker At least once delivery Ensures a saga completes when its participants are temporarily unavailable Ordered delivery Mechanism for scaling consumers that preserves ordering e.g. Apache Kafka consumer group ActiveMQ message group …
  22. 22. @crichardson Saga step = a transaction local to a service Service Database Message Broker update publish message/event How to make atomic without 2PC?
  23. 23. @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)
  24. 24. @crichardson Choreography: distributed decision making vs. Orchestration: centralized decision making
  25. 25. @crichardson Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS Implementing transactional messaging Overview Choreography Orchestration Agenda
  26. 26. @crichardson Message broker Choreography-based Create Order Saga Order created Credit Reserved Credit Limit Exceeded Create Order OR Customer availableCredit ... Order state total create() reserveCredit() approve()/ reject() Order events channel Customer events channel Order Service Customer Service
  27. 27. Benefits and drawbacks of choreography Benefits Simple, especially when using event sourcing Participants are loosely coupled Drawbacks Decentralized implementation - potentially difficult to understand 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
  28. 28. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS Implementing transactional messaging Overview Choreography Orchestration
  29. 29. @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
  30. 30. @crichardson A saga (orchestrator) is a persistent object that implements a state machine and invokes the participants
  31. 31. 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 …
  32. 32. @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 https://github.com/eventuate-tram/eventuate-tram-sagas-examples-customers-and-orders
  33. 33. 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
  34. 34. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS Implementing transactional messaging
  35. 35. @crichardson Queries often retrieve data owned by multiple services
  36. 36. @crichardson API Composition pattern Customer Service Customer … Order Service Order … API Gateway findOrdersForCustomer(customerId) GET /customer/id GET /orders?customerId=id https://microservices.io/patterns/data/api-composition.html
  37. 37. @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!
  38. 38. 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
  39. 39. @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
  40. 40. @crichardson Persisting a customer and order history in MongoDB { "_id" : "0000014f9a45004b 0a00270000000000", "name" : "Fred", "creditLimit" : { "amount" : "2000" }, "orders" : { "0000014f9a450063 0a00270000000000" : { "state" : "APPROVED", "orderId" : "0000014f9a450063 0a00270000000000", "orderTotal" : { "amount" : "1234" } }, "0000014f9a450063 0a00270000000001" : { "state" : "REJECTED", "orderId" : "0000014f9a450063 0a00270000000001", "orderTotal" : { "amount" : "3000" } } } } Denormalized = efficient lookup Customer information Order information
  41. 41. @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
  42. 42. @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
  43. 43. @crichardson CQRS views are disposable Rebuild when needed from source of truth Using event sourcing (Conceptually) replay all events from beginning of time Using traditional persistence “ETL” from source of truth databases
  44. 44. @crichardson Handling replication lag Lag between updating command side and CQRS view Risk of showing stale data to user Either: Update UI/client-side model without querying Use updated aggregate version to “wait” for query view to be updated
  45. 45. @crichardson Agenda Transactions, queries and microservices Managing transactions with sagas Implementing queries with CQRS Implementing transactional messaging
  46. 46. @crichardson Messaging must be transactional Service Database Message Broker update publish How to make atomic without 2PC?
  47. 47. Publish to message broker first? Guarantees atomicity BUT Service can’t read its own writes Difficult to write business logic Service Database Message Broker update publish
  48. 48. @crichardson Option: Event sourcing = Event centric approach to business logic and persistence http://eventuate.io/
  49. 49. @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
  50. 50. @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
  51. 51. @crichardson FYI: Apache Kafka != event store
  52. 52. @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
  53. 53. @crichardson Preserves history of domain objects Supports temporal queries Simplifies retroactive correction Built-in auditing Other benefits of event sourcing
  54. 54. @crichardson Unfamiliar programming model Evolving the schema of long-lived events Event store only supports PK-based access requires CQRS less consistent reads Drawbacks of event sourcing
  55. 55. @crichardson Good fit for choreography-based sagas BUT orchestration is more challenging Use event handler to translate event into command/reply message Drawbacks of event sourcing
  56. 56. @crichardson Option: Traditional persistence (JPA, MyBatis,…) + Transactional outbox pattern https://github.com/eventuate-tram/eventuate-tram-core
  57. 57. @crichardson Spring Data for JPA example Publish event Save order http://eventuate.io/exampleapps.html
  58. 58. @crichardson Transactional outbox pattern 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() DomainEventPublisher
  59. 59. @crichardson Transaction log tailing Order Service Datastore ORDER table Transaction log Update Transaction log miner Message Broker Publish Changes MySQL binlog Postgres WAL AWS DynamoDB table streams MongoDB change streams http://eventuate.io/
  60. 60. @crichardson Polling the message table Simple Works for all databases BUT what about polling frequency MESSAGE Table Message Publisher Message Broker SELECT * FROM MESSAGE… UPDATE MESSAGE
  61. 61. @crichardson Summary Use asynchronous messaging to solve distributed data management problems Services publish events to implement choreography-based sagas queries using CQRS views Services send command/reply messages to implement orchestration-based sagas Services must atomically update state and send messages Event sourcing Transactional outbox
  62. 62. @crichardson @crichardson chris@chrisrichardson.net http://learn.microservices.io Questions?

×