Vortrag IV Stichpunkte

Vortrag 30.11.2018, Sebastian Gauder, Eventing with Apache Kafka

Having data is better than needing data

Motivation MS einzuführen: einziger guter Grund, sehr schnell viel wachsen, große Probleme in kleine zerlegen, nicht nur weil es gerade "in" ist

Erneut: "Keine Abhängigkeiten", nicht während der Entwicklung, Deployment, Laufzeit dazu: Eventing sehr praktisch

Einführung Kafka 2016, eine zeitlang ausschließlich synchron, aber bereits absehbar

Probleme mit synchronen Aufrufen: Netflix OpenSourceStack -> Framework synchrone komm 2.Probleme.

1. Widerstandfähigkeit ist nicht hoch, wenn ein Service ausfällt fallen ganze Strukturen aus bei 270 Services häufiges Problem; der ganze Request kann nicht beantwortet werden Gegenmaßnahmen: Timeouts (Timeouts kurz 300ms); Retry; Circuit Braker Probleme mit langen Timeouts: durch Workerthreads kann sich das Problem aufschaukeln Wenn Timeouts: dann Fallbacks, Hinweis o. ä. Circuit Braker: noch besser, Threadpools werden nicht belegt, Service mit überlast wird entlastet
2. Unperformant Ketten von MS zu bilden, bei naiver Implementierung addiert sich die Laufzeit dauer evtl. länger als im Monolithen: Gegenmaßnahmen: Parallelisieren, Caching (aber auch gefährlich)

Alle Ansätze lösen das eigentliche Problem nicht

Lösung: having data before needing data

Lösung: Eventing (kein definierter Terminus) Ziel des Eventing: Ansatatt die Daten der einzelnen Daten der Services zu holen, eine Art DB-Replikation aller Teile die benötigt werden. Bevor der Request kommt hat der Service sich schon mit benötigten Daten versorgt

Was hat das mit Events zu tun: Event ist eine Repräsentation von etwas, das in der Domäne in der Vergangenheit stattgefunden hat 2 Zutaten: Entität die das Event betrifft und State Change (crud oder komplexer wie ware zugestellt) 2 Funktionen des Events: Beschreibt die Domäne, Events tragen zu ubitiqouus langugae bei.

Event ist das Vehikel für die Datenbankreplikation, wenn ein Services alle Events abspeichert hat er alle Daten vorliegen

Form: json id, key(pk der enitity), version, time, type (art des events), payload(komplette entitiy) unterschied zu eventsourcing: keine deltas immer vollständiger zustand, events können groß werden

Don't repeat yourself gilt nicht mehr

Pitfalls

Events müssen self contained sein, es soll kein synchroner Aufruf danach erforderlich sein

Es darf kein weiteres Event erforderlich sein um in einen konsistenten Zustand zu kommen Es darf nicht erforderlich sein ein weiteres Event von der gleichen oder einer andren Queue zu erhalten um in einen konsistenten Zustand zu kommen: !transaktionale Vollständigkeit!

Only true fachts must be published commited nur das was sicher passiert und abgespeichert ist darf publiziert werden

andersrum auch, erst wenn gelesen wurde dann als gelesen markieren

ein event muss das ganze aggregat enthalten wenn eine liste geändert wird, muss die ganze liste neu übertragen werden

Warum überhaupt noch REST Eventmechanismus ersetzt immer nur get Event stellt nur etwas da was passiert ist es können niemals aufforderungen etwas zu tun herausgegeben werden

Kommunikation mit Clients über REST

Eventual consistency; Time critical data flow Zeitkritischer Datenfluss, Events garantieren keine Fluss Daten die direkt abhängig sind, schnelle UI interaktionen keine Events

Eventing als Teil der APIs typischer Service drei Teilapis: REST (json); UI-API, Events

API sollte vollständig sein (mit Events) wenn neuer service an den Start geht

Apache Kafka

Kafka hat Topics, Message stream zu einem Thema Topic werden Partiotioniert einzelne Keys werden immer dem gleichen Topic zugeordnet, zeitliche reihenfolge auf Partitionen garantiert

weil keys immer auf gleiche partition -> zeitliche abfolge für events zu keys gegeben

jede Partiton wird einem oder mehreren Consumern zugeordnet (MS) (load balancing?)

Präsentation ansehen!

Log compaction wenn mehrere versionen eines events auf kafka liegen werden alte events weggeworfen

wenn ein service startet wird die komplette eventqueue wieder eingespielt jedes einmal emittierte event in der neuesten version wird wieder gelesen

wie schreibt man einen producer

nur ein kontext publiziert (mehrere instanzen möglich), wenn 2 services das tun sollten domänendesign überarbeiten

producer müssen in der lage sein alle events neu zu publizieren, kafka wird nicht gebackupt

producer hat repositorys für event repo; enity repo und published ver. repositorys im event repo liegen rohevents die so nach kafka publiziert werden können

Strategie at least once, jede Nachricht min. 1 mal, aber mehrfach möglich

Kopieren ist in Ordnung: KOPIE IST IN ORDNUNG, DENN KOPIE HEIẞT: KEINE ABHÄNGIGKEIT schlechte Erfahrung mit Librarys, besser kopieren

wie schreibt man einen consumer

nachrihten müssen idempotent verarbeitet werden

events können doppelt ankommen, zustand muss dann gleich sein

keine events in der form: erhöhe den betrag um 100€

Schwierigkeit: Blue-Green deployment Consumer müssen in der Lage sein alles von anfang an zu re-konsummieren

wenn neu daten erforderlich sind, muss offset für kafka zurückgesetzt werden und alles neu eingelesen werden

3 repositorys entitiy repo, processed version repo (kv-store), error repo

error repo, falls nicht in die datenbank geschrieben werden kann einfach warten, wenn event ungültig (felder o. ä.) error repo -> patchen -> einspielen

kafka tool, graifsche darstellung von kafka

git.io/vA2MY

REST und EVENT API sind redundant. Jeder Service bietet die Funktionen auch per REST an