Pro Yearly is on sale from $80 to $50! »

Events First: Resiliente und skalierbare Microservices

Events First: Resiliente und skalierbare Microservices

Die Erwartungen an Microservices sind groß: Sie sollen nicht nur die Entwicklung beschleunigen, sondern auch höchste Qualitätsanforderungen erfüllen. Wo monolithische Enterprise-Systeme unter Last ächzen, versprechen sie Stabilität und Skalierbarkeit. In der Umsetzung bleibt dies mitunter auf der Strecke. Es werden Systeme gebaut, in denen jeder Service auf alle anderen Services angewiesen ist, oder deren Durchsatz durch ineffiziente Kommunikation begrenzt wird. Event-basierte Architekturmuster können das Versprechen der resilienten, skalierbaren Systeme einlösen.
Der Events-First-Ansatz betrifft nicht nur die Kommunikation zwischen Services, sondern auch, wie wir mit (globalem) Zustand umgehen. Ein solches System zu entwerfen ist eine Herausforderung für Softwarearchitektinnen und -architekten. Aus der Domain-driven-Design-Community kommt die Technik des Event Stormings. Sie hilft uns, den Fokus zunächst weniger auf die statischen Eigenschaften der Domäne wie dem Datenmodell zu legen.
Der Vortrag zeigt, wie eine eventbasierte Architektur zu besseren Microservices führt, und wo wir dafür in der Architektur umdenken müssen.

Vortrag von der W-JAX 2018, München, am 7.11.2018

1e34ccfd8a1eaf8715214472b6ca8140?s=128

Lutz Hühnken

November 07, 2018
Tweet

Transcript

  1. Events First: Resiliente & Skalierbare Microservices 7.11.2018
 W-JAX @lutzhuehnken

  2. „CRUD“ Service Service RDMBS Außen welt

  3. Außen welt Service A Service B Service C RDBMS RDBMS

    RDMBS „Synchrone“ µServices
  4. Wie skalieren wir? Service RDMBS Außen welt

  5. Service B RDBMS „Stateless“ Services Service B Service B

  6. Service B Master Master / Replica Service B Service B

    Replica Replica
  7. Außen welt Service A Service B Service C RDBMS RDBMS

    RDMBS Wie resilient sind wir?
  8. Außen welt Service A Service B Failure RDBMS RDBMS RDMBS

    Fehler kaskadieren
  9. 9 „A distributed system is one in which the failure

    of a computer you didn't even know existed can render your own computer unusable.“ Leslie Lamport
  10. Was könnte nur die Lösung sein?

  11. Event • Events sind Fakten • immer in Vergangenheitsform, etwas,

    was passiert ist • Events können nicht zurückgenommen werden • sie können höchstens ignoriert werden • Events sind unveränderlich
  12. Arten von Events (nach Martin Fowler: What do you mean

    by “Event-Driven”?) • Event Notification • es ist etwas passiert • Event-Carried State Transfer • das hier sind die Änderungen • Event-Sourcing • speichere Events statt Zustand
  13. 1. Skalierbarkeit: Event Sourcing 2. Resilienz: Event Streaming 3. Design:

    Event Storming Was uns interessiert
  14. EVENTSOURCING

  15. Ziel: Scale Out

  16. Event Sourcing - Prinzip Event Event Event Command A A'

    • Wir senden ein Kommando an unser „Aggregat“ A. • A validiert Kommando, es resultiert in Fehler oder Event(s). • Die Events werden persistiert. • Als Reaktion auf einen Event ändert A seinen Zustand zu A’
  17. Event Sourcing - Philosophie

  18. Wie skalieren wir? Node A Node B Node C X

    B A Z X Y N M „Cluster Sharding“
  19. Service B Event Journal Wie skalieren wir? Service B Service

    B Event Journal Event Journal
  20. State, Locks, Contention.. Shared Mutable Share Nothing Immutable

  21. „All computers wait at the same speed.“ 21

  22. S S Service B RDBMS Die „Stateless“ Illusion Service B

    Service B Stateless Shared Mutable State
  23. S Service B Event Journal „Embrace the state“ Service B

    Service B Event Journal Event Journal Share-nothing Mutable State
  24. Projection Read Side Wie lesen wir? CQRS Event Journal Read

    Side Projection
  25. ES / CRQS- Technologie Event Sourcing / Command Query Responsibility

    Segregation • Write Side (Event Journal) • z.B. Cassandra - skaliert, schnelle Schreibzugriffe • Read Side • z.B. RDMBS - erlaubt SQL Tooling zu nutzen • oder.. Elastic Search, Hadoop/Spark, .. • „Polyglot Persistence“ (CQRS Read Side heißt immer: Eventual Consistency)
  26. EVENTSTREAMING

  27. Ziel: Bulkheads

  28. Außen welt Service A Service B Service C Event Journal

    Event Journal Event Journal Ohne Event Streaming
  29. Außen welt Service A Service B Service C Event Journal

    Event Journal Event Journal Mit Event Streaming Event Stream
  30. Event Streaming • Services sprechen nicht mehr synchron miteinander, sondern

    publizieren und abonnieren Events • Tell, don’t ask! • Availability vs. Authority • Wieder: Eventual Consistency
  31. Außen welt Service A Service B Failure Event Journal Event

    Journal Event Journal Resilienz Event Stream
  32. Event Streaming - Technologie • Platzhirsch: Apache Kafka • Bewährt,

    aber Vorsicht vor Marketing-Versprechen • Auf AWS: Kinesis • Möglicherweise Alternativen (nicht getestet) • Chronicle Queue • NATS • Pulsar
  33. EVENTSTORMING

  34. PPT Master 16:9 / Edition 2018 „Going to microservices is

    like going from Newton’s physics to Einstein’s physics. Newton’s time marched forward uniformly with instant knowledge at a distance. Before microservices, distributed computing strove to make many systems look like one with RPC, 2PC etc.. In Einstein’s universe, everything is relative to one’s perspective.“ Pat Helland
  35. Die Rettung: Event Storming!

  36. EventStorming Starte mit Events. Erzähle eine Geschichte. Seat selected

  37. EventStorming Wenn die Geschichte erzählt ist, überlege, was / wer

    die Events auslöst. Seat selected Choose seat
  38. EventStorming Wer muss was wissen, um das Kommando zu verarbeiten?

    So finden wir unsere Aggregate. Seat selected Choose seat Seat map
  39. None
  40. „It is not the things that matter in early stages

    of design… …it is the things that happen.“ Russ Miles http:/ /www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd 40
  41. Wenn ihr nur eine Sache mitnehmt aus diesem Vortrag…

  42. Fazit • Ihr könnt wirklich skalierbare und resiliente Microservices bauen,

    die Technologie ist da.* • Die wahre Hürde ist das Design: Die asynchrone, verteilte Natur, und die damit verbundene Unsicherheit (eventual consistency), akzeptieren und damit arbeiten. • Event Storming kann dabei eine sehr große Hilfe sein. (Ich hab’s ausprobiert, funktioniert ;)
  43. Außen welt Service A Service B Service C Event Journal

    Event Journal Event Journal Bedenkenträger: Event Stream ist SPOF Failure
  44. Bedenkenträger: Zu komplex • CQRS heißt ja schonmal mindestens zwei

    Datenbanken • Cassandra heißt mind. 3 Knoten • Kafka heißt mindestens 3 Knoten für Kafka plus mindestens 3 Knoten für Zookeeper
  45. 45 Scalability cannot be an after-thought. It requires applications and

    platforms to be designed with scaling in mind, … Werner Vogels
  46. Projection Read Side Bedenkenträger: Änderungen sofort sehen Event Journal Read

    Side Projection Aggregate (can be read)
  47. Bedenkenträger: Out-of-Order Events, Duplicates… Außen welt Service A Service B

    Service C Event Event Event Event Stream Deal with Uncertainty!
  48. 1. Skalierbar mit Event Sourcing ✔ 2. Resilient mit Event

    Streaming ✔ 3. Events First mit Event Storming ✔ Yeah, Events!
  49. Bitte lesen / anschauen • Pat Helland • „Beyond Distributed

    Transactions“ • „Data on the Outside versus Data on the Inside“ • Jonas Boner • „Designing Events First Microservices“ • alles andere auch • Vaughn Vernon • „Dealing with Uncertainty“
  50. Fragen, bitte! www.innoq.com Kontakt: Lutz Hühnken lutz.huehnken@innoq.com @lutzhuehnken INNOQ seit

    1.11. auch in Hamburg. Wir suchen Verstärkung für unser Hamburger Team! INNOQ auf der W-JAX: Auf diesem Stockwerk (Obergeschoss), gegenüber von Audi.
  51. Noch ein paar Links • http://www.russmiles.com/essais/going-events-first-for- microservices-with-event-storming-and-ddd • http://ziobrando.blogspot.de/2013/11/introducing-event- storming.html

    • https://leanpub.com/introducing_eventstorming • https://www.lagomframework.com • https://blog.redelastic.com/corporate-arts-crafts-modelling- reactive-systems-with-event-storming-73c6236f5dd7