Eventing mit Kafka (Sebastian Gauder) - Archi-Lab/fae-team-2 GitHub Wiki

Probleme bei REST-only Architekturen:

Wiederstandsfähigkeit gegenüber einzelnen Service-Ausfällen ist gering (Lack of Resilience) und es existiert ein Performanzverlust durch Antwortzeiten.

Grundlegendes

• Ziel des Eventings: Es Services ermöglichen sich asynchron und performant mit Daten zu versorgen, bevor sie in einem Request benötigt werden.
• Ein Event betrifft genau:
  • 1 domain entity
  • 1 state change
• Ein Event enthält:
  • Event-ID,
  • Key (Welche Entität ist betroffen?),
  • Version,
  • Time (when did it occur?),
  • Type (Kind of action that happened),
  • Payload (Details): Hier gesamte Entities versenden.

Regeln

• Events müssen selfcontained sein (nicht mit einem nachgezogenen Rest-Aufruf) Achtung: Dies wurde in anderen Vorträgen angezweifelt.
• Transaktionale Vollständigkeit: Man darf kein Folge-Event benötigen, um wieder in einen konsistenten Systemzustand zu gelangen
• "Only true facts must be published / committed" (z.b. ERST in DB speichern, dann Event über Datenpersistierung abschicken. Andersherum wäre ein Verstoß gegen diese Regel.)

Gründe auf Events zu verzichten:

• Write operations: Events können nur GET-Operations ersetzen
• Clientkommunikation benötigt HTTP/REST
• Zeitkritischer Datenfluss: Hier kann eventual consistency problematisch sein, d.h. REST ggf. sinnvoller
• Daumenregel: "Bei schnellen UI Interaktionen sollte man sich nicht auf Events verlassen."

Implementierung: Kafka

4 Typen von Kafka-APIs liegen vor:

• producer
  • Nur EIN context produziert ein topic.
  • Alle producer müssen events reproduzieren könnten, z.b. wenn kafka abgestürzt ist und wieder gestartet wurde.
  • Eigentliche Herausforderung: So implementieren, dass wirklich keinerlei Nachrichten verloren gehen können
• consumer
  • Nachrichten idem-potent verarbeiten (wenn also ein Event 2 mal ankommt, muss nach dem 2. event die Applikation im gleichen Zustand sein wie nach dem 1. )
  • blue/green deployments: Consumer wird nur nach einem succesfull processing des events verantwortlich dieses zu committen
  • Error Repository anstatt Error Log, so dass Fehlermeldungen gut wiederbeschafft und aufbereitet werden können.
• stream
  • In unserem Kontext eher irrelevant
• connect
  • Ähnelt der Interaktion mit Datenbanken
  • Ist sinnvoll für DB Replikation, wäre für REWE sogar besser geeigenet

Weitere Hinweise

• Logging: Nur die most recent version für das jeweilige Event
• In den REST-APIs: REST-APIs müssen trotz Eventing immer vollständig sein, es gibt immer GET-Schnittstellen um Daten abzuholen, auch wenn man an manchen Stellen bevorzugt auf Events zurückgreift. REST muss also als Fallback vorhanden sein.
• Consumer driven: Consumer entscheidet dann selbst ob er Informationen als Event oder REST abholen möchte.