Event Sourcing: Einführung und Best Practices

2.826 Aufrufe

Veröffentlicht am

The Architecture Gathering 2015

Unter Event Sourcing versteht man einen Architekturstil in dem Änderungen am Zustand der verwalteten Daten als eine Sequenz von Events festgehalten werden. Durch diese Herangehensweise können jederzeit Snapshots des Datenzustands erstellt und abgefragt werden. Des Weiteren ermöglicht uns das Persistieren von Events eine Optimierung der lesenden Zugriffe durch eine Denormalisierung des „Lese-Modells“ der Daten. Letzerer Aspekt ist aktuell insbesondere durch den Architekturansatz CQRS in aller Munde.

Veröffentlicht in: Software

Event Sourcing: Einführung und Best Practices

  1. 1. Event SourcingEinführung & Best Practices
  2. 2. Michael Plöd Principal Consultant bei innoQ @bitboss
  3. 3. Die klassische, bewährte N-Tier Software- Architektur
  4. 4. IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident
 DTO Incident
 View
 Model RDBMS Incident
 ER-Model Netzwerk Netzwerk
  5. 5. Charakteristika
  6. 6. 1 Wir lesen und schreiben Daten über den identischen Weg IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident
 DTO Incident
 View
 Model RDBMS Incident
 ER-Model Netzwerk Netzwerk WRITE READ
  7. 7. 2 Wir verwenden für Lesen und Schreiben das gleiche Modell IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident
 DTO Incident
 View
 Model RDBMS Incident
 ER-Model Netzwerk Netzwerk
  8. 8. 3 Grobgranulares Deployment IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Client RDBMS Frontend-Server Backend-Server Datenbank-Server
  9. 9. Die meisten Systeme speichern derzeit nur den aktuellen Zustand beim Verarbeiten von Transaktionen
  10. 10. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATUM TEXT 1 23423 11.03.2014 Maus defekt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Klassische Architektur
  11. 11. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATUM TEXT 1 23423 11.03.2014 Maus ist kaputt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Update Der Datensatz wird direkt geändert. 
 Keine Historie
  12. 12. So haben wir das schon immer gemacht!
  13. 13. Zahlreiche Anwendungen fahren mit der klassischen Architektur gut
  14. 14. Es gibt dennoch Bereiche, in denen dieses Architekturmodell an seine Grenzen stößt
  15. 15. ?Probleme
  16. 16. 1 Das Datenmodell ist ein Kompromiss 2 Lesen und Schreiben können nicht unabhängig voneinander skaliert werden 3 Keine Historie, keine Snapshots, kein Replay 4 Tendenz zum Monolithen
  17. 17. Event Sourcing ist ein Architekturstil bei dem der Zustand der Daten einer Anwendung aus einer Sequenz von Domain Events bestimmt wird
  18. 18. Aufbau / Bestandteile Anwendung Event Bus (Queue) Anwendung stellt Events asynchron in Queue Event Handler Handler verarbeitet Events und reagiert darauf Event Store Store speichert sämtliche Events
  19. 19. Den Verlauf der Events in der Queue nennt man Event Stream tjetzt EventEventEventEventEvent
  20. 20. Exemplarischer Event Stream IncidentCreatedEvent
 
 incidentNumber: 1
 userNumber: 23423 timestamp: 11.03.2014 12:23:23
 text: „Mouse broken“ status: „open“ IncidentTextChangedEvent
 
 incidentNumber: 1
 text: „Left button of mouse broken“ IncidentClosedEvent
 
 incidentNumber: 1
 solution: „Mouse replaced“ status: „closed“
  21. 21. Ein Event ist etwas, das in der Vergangenheit passiert ist t jetzt EventEventEventEventEvent
  22. 22. Die Benennung von Events ist Teil der 
 Ubiquitous Language D D D
  23. 23. ShipmentDeliveredEvent
 CustomerVerifiedEvent CartCheckedOutEvent CreateCustomerEvent WillSaveItemEvent DoStuffEvent
  24. 24. Code Beispiel public class CustomerVerifiedEvent { private String eventId; private Date eventDate; private CustomerNumber customerNumber; private String comment; public CustomerVerifiedEvent(CustomerNumber custNum, 
 String comment) {
 this.customerNumber = cusNum; this.comment = comment; this.eventDate = new Date(); } }
  25. 25. Scoping von Events auf 
 Basis von
 Aggregaten D D D
  26. 26. Ein Event ist immer immutable Es gibt auch kein Delete!
  27. 27. Ein Delete ist einfach ein weiterer Event IncidentCreatedEvent
 
 incidentNumber: 1
 userNumber: 23423 timestamp: 11.03.2014 12:23:23
 text: „Maus defekt“ status: „offen“ IncidentTextChangedEvent
 
 incidentNumber: 1
 text: „Maus ist Kaputt“ IncidentClosedEvent
 
 incidentNumber: 1
 solution: „Neue Maus“ status: „geschlossen“ IncidentRemovedEvent
 
 incidentNumber: 1

  28. 28. t now EventEventEventEventEvent Der Event Bus wird üblicherweise durch einen Message Broker implementiert
  29. 29. Lasst uns den ESB aus dem gescheiterten SOA Projekt nehmen
  30. 30. NEIN
  31. 31. NEIN
  32. 32. NEIN
  33. 33. ! Dumb pipes with smart endpoints
  34. 34. 1 Kompletter Rebuild möglich 2 Zeitbasierte Abfragen 3 Event Replay
  35. 35. Das Event Log hat einen sehr hohen Business Value
  36. 36. Laufe ich bei Abfragen nicht in ein Performance Problem, wenn ich den Zustand aus dem Event Store errechnen muss
  37. 37. Ja, vor allem bei vielen Events
  38. 38. Application State Vorhalten von Application State Anwendung Event Queue Event Handler Event Store Application State Die Anwendung stellt Abfragen gegen den Application State
  39. 39. CQRS
  40. 40. Command Query Responsibility Separation
  41. 41. IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident
 DTO Incident
 View
 Model RDBMS Incident
 ER-Model Netzwerk Netzwerk
  42. 42. IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO RDBMS Netzwerk IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO CQRS ist eigentlich einfach
  43. 43. IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO RDBMS Netzwerk IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO Getrenntes Model Read
 Model Write
 Model Achtung: aktuell laufen beide Models noch auf ein gemeinsames Datenbank- Modell zusammen
  44. 44. Was wäre denn ein sauberer Weg für die Trennung des Datenmodells?
  45. 45. Event Sourcing & CQRS Event Store EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
  46. 46. 1 Individuelle Skalier- und Deploybarkeit 2 Technologie-Freiheit für Query-, Command- und EventHandler Code 3 Sehr guter Fit für Bounded Context (Domain Driven Design)
  47. 47. Event Sourcing und CQRS sind interessante Optionen. Allerdings gibt es diverse Herausforderungen
  48. 48. 1 Konsistenz 2 Validierung 3 Parallele Updates
  49. 49. JA
  50. 50. ! Systeme, die auf CQRS und Event Sourcing basieren, sind eventually consistent
  51. 51. Eventual Consistency Event Store EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
  52. 52. ABER
  53. 53. Ihre Fachdomäne sollte den Konsistenz-Grad treiben, nicht Technologien
 Deeper Insight D D D
  54. 54. 1 Konsistenz 2 Validierung 3 Parallele Updates
  55. 55. User
 Guid id String email String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent
 
 Guid id Date timestamp String email String password EmailChangedEvent
 
 Guid userId Date timestamp String email Beispiel Domäne
  56. 56. Wir verarbeiten mehr als 2 Mio Registrierungen pro Tag. Ein Nutzer kann ihre / seine Email-Adresse ändern. Selbige muss unique sein.
  57. 57. ? Wie hoch ist die Wahrscheinlichkeit, das eine Validierung fehl schlägt? Welche Daten werden benötigt und wo werden diese gespeichert?
  58. 58. € Was ist der Impact einer fehlerhaften Validierung? Wie hoch sind die Kosten? Wie hoch ist die Wahrscheinlichkeit, dass ein Fehler auftritt?
  59. 59. Ihre Fachdomäne sollte den Konsistenz-Grad für Validierungen treiben
 Deeper Insight D D D
  60. 60. 1 Validiere über den Event Store 2 Validiere über den Read Store 3 Führe Validierung im Event Handler durch
  61. 61. Validiere NIEMALS über den Event Store
  62. 62. 1 Konsistenz 2 Validierung 3 Parallele Updates
  63. 63. User
 Guid id String email String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent
 
 Guid id Date timestamp String email String password EmailChangedEvent
 
 Guid userId Date timestamp String email Beispiel Domäne
  64. 64. Was passiert wenn sich Alice und Bob einen Account teilen und beide ändern parallel die EMail- Adresse?
  65. 65. ? Was würden wir in einer „klassischen old school Architektur“ machen
  66. 66. UserRestController UserBusinessService UserDAO User ID EMAIL PASSWORD … … … 2341 alice_bob@xyz.com lksjdaslkdjas … … … Pessimistisches oder optimistisches Locking Update
  67. 67. ! Pessimistisches Locking auf Datenebene wird mit Event Sourcing nicht funktionieren
  68. 68. EventHandler EventsEvents Read Storage Events Event Store UserRestController UserBusinessService UserDAO User Commands Fachlicher Lock mit UserLockedEvent Fachlicher Lock
  69. 69. ? Benötigen wir 
 WIRKLICH pessimistisches Locking Die meisten „klassischen Architekturen“ laufen sehr gut mit optimistischem Locking
  70. 70. Einführung eines Version Fields User
 Guid id Long version String email String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent
 
 Guid id Date timestamp String email String password EmailChangedEvent
 
 Guid userId Date timestamp String email Long version
  71. 71. Jeder Schreib Event erhöht die Version {guid: 12, version: 0,
 email: alicebob@xyz.com, password:
 werwe2343} {guid: 12, version: 1,
 email: alice_bob@xyz.com, password: 
 werwe2343} {guid: 12, version: 2,
 email: alice@xyz.com, password: 
 werwe2343} UserRegisteredEvent EmailChangedEvent version: 0 EmailChangedEvent version: 1 EmailChangedEvent version: 1 EmailChangeFailedEvent
  72. 72. Ihre Fachdomäne treibt die Locking Qualität
 Deeper Insight D D D
  73. 73. ToolsEvent
 Sourcing Hazelcast, RabbitMQ, MQSeries, RDBMS, MongoDB, Redis, Apache Kafka, und viele mehr Treiben Sie das Thema Event Sourcing nicht aus Tooling Sicht sondern adaptieren Sie, das was für Ihre Organisation und Domäne Sinn macht
  74. 74. Danke! Michael Plöd Principal Consultant bei innoQ
 @bitboss http://slideshare.net/mploed michael.ploed@innoq.com

×