Event Sourcing: Einführung und Best Practices
Melden
Michael PlödFolgen
Principal Consultant um innoQ Deutschland GmbH22. Oct 2015•0 gefällt mir•5,831 Aufrufe
Event Sourcing: Einführung und Best Practices
22. Oct 2015•0 gefällt mir•5,831 Aufrufe
Downloaden Sie, um offline zu lesen
Melden
Software
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.
Michael PlödFolgen
Principal Consultant um innoQ Deutschland GmbH
Event Sourcing: Einführung und Best Practices
- Event SourcingEinführung & Best Practices
- Michael Plöd Principal Consultant bei innoQ @bitboss
- Die klassische, bewährte N-Tier Software- Architektur
- IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident DTO Incident View Model RDBMS Incident ER-Model Netzwerk Netzwerk
- Charakteristika
- 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
- 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
- 3 Grobgranulares Deployment IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Client RDBMS Frontend-Server Backend-Server Datenbank-Server
- Die meisten Systeme speichern derzeit nur den aktuellen Zustand beim Verarbeiten von Transaktionen
- 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
- 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
- So haben wir das schon immer gemacht!
- Zahlreiche Anwendungen fahren mit der klassischen Architektur gut
- Es gibt dennoch Bereiche, in denen dieses Architekturmodell an seine Grenzen stößt
- ?Probleme
- 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
- Event Sourcing ist ein Architekturstil bei dem der Zustand der Daten einer Anwendung aus einer Sequenz von Domain Events bestimmt wird
- 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
- Den Verlauf der Events in der Queue nennt man Event Stream tjetzt EventEventEventEventEvent
- 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“
- Ein Event ist etwas, das in der Vergangenheit passiert ist t jetzt EventEventEventEventEvent
- Die Benennung von Events ist Teil der Ubiquitous Language D D D
- ShipmentDeliveredEvent CustomerVerifiedEvent CartCheckedOutEvent CreateCustomerEvent WillSaveItemEvent DoStuffEvent
- 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(); } }
- Scoping von Events auf Basis von Aggregaten D D D
- Ein Event ist immer immutable Es gibt auch kein Delete!
- 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
- t now EventEventEventEventEvent Der Event Bus wird üblicherweise durch einen Message Broker implementiert
- Lasst uns den ESB aus dem gescheiterten SOA Projekt nehmen
- NEIN
- NEIN
- NEIN
- ! Dumb pipes with smart endpoints
- 1 Kompletter Rebuild möglich 2 Zeitbasierte Abfragen 3 Event Replay
- Das Event Log hat einen sehr hohen Business Value
- Laufe ich bei Abfragen nicht in ein Performance Problem, wenn ich den Zustand aus dem Event Store errechnen muss
- Ja, vor allem bei vielen Events
- Application State Vorhalten von Application State Anwendung Event Queue Event Handler Event Store Application State Die Anwendung stellt Abfragen gegen den Application State
- CQRS
- Command Query Responsibility Separation
- IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident DTO Incident View Model RDBMS Incident ER-Model Netzwerk Netzwerk
- IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO RDBMS Netzwerk IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO CQRS ist eigentlich einfach
- 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
- Was wäre denn ein sauberer Weg für die Trennung des Datenmodells?
- Event Sourcing & CQRS Event Store EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
- 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)
- Event Sourcing und CQRS sind interessante Optionen. Allerdings gibt es diverse Herausforderungen
- 1 Konsistenz 2 Validierung 3 Parallele Updates
- JA
- ! Systeme, die auf CQRS und Event Sourcing basieren, sind eventually consistent
- Eventual Consistency Event Store EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
- ABER
- Ihre Fachdomäne sollte den Konsistenz-Grad treiben, nicht Technologien Deeper Insight D D D
- 1 Konsistenz 2 Validierung 3 Parallele Updates
- 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
- Wir verarbeiten mehr als 2 Mio Registrierungen pro Tag. Ein Nutzer kann ihre / seine Email-Adresse ändern. Selbige muss unique sein.
- ? Wie hoch ist die Wahrscheinlichkeit, das eine Validierung fehl schlägt? Welche Daten werden benötigt und wo werden diese gespeichert?
- € Was ist der Impact einer fehlerhaften Validierung? Wie hoch sind die Kosten? Wie hoch ist die Wahrscheinlichkeit, dass ein Fehler auftritt?
- Ihre Fachdomäne sollte den Konsistenz-Grad für Validierungen treiben Deeper Insight D D D
- 1 Validiere über den Event Store 2 Validiere über den Read Store 3 Führe Validierung im Event Handler durch
- Validiere NIEMALS über den Event Store
- 1 Konsistenz 2 Validierung 3 Parallele Updates
- 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
- Was passiert wenn sich Alice und Bob einen Account teilen und beide ändern parallel die EMail- Adresse?
- ? Was würden wir in einer „klassischen old school Architektur“ machen
- UserRestController UserBusinessService UserDAO User ID EMAIL PASSWORD … … … 2341 alice_bob@xyz.com lksjdaslkdjas … … … Pessimistisches oder optimistisches Locking Update
- ! Pessimistisches Locking auf Datenebene wird mit Event Sourcing nicht funktionieren
- EventHandler EventsEvents Read Storage Events Event Store UserRestController UserBusinessService UserDAO User Commands Fachlicher Lock mit UserLockedEvent Fachlicher Lock
- ? Benötigen wir WIRKLICH pessimistisches Locking Die meisten „klassischen Architekturen“ laufen sehr gut mit optimistischem Locking
- 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
- 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
- Ihre Fachdomäne treibt die Locking Qualität Deeper Insight D D D
- 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
- Danke! Michael Plöd Principal Consultant bei innoQ @bitboss http://slideshare.net/mploed michael.ploed@innoq.com