Der stärkste Grund für die Einführung einer ereignisgesteuerten Architektur liegt nicht darin, dass sie modern klingt. Es liegt daran, dass es Systemen ermöglicht, auf dieselbe Änderung zu reagieren, ohne eng an denselben Anforderungspfad gekoppelt zu sein.
Das ist nützlich, wenn:
- mehrere Dienste an demselben Domainereignis interessiert sind
- Reaktionen in nahezu Echtzeit wichtig sind
- Verbraucher unabhängig weiterentwickelt werden sollten
Kafka ist eine Möglichkeit, dies zu erreichen, da es Ihnen ein dauerhaftes Protokoll von Ereignissen anstelle eines Punkt-zu-Punkt-Aufrufs bietet.
Was sich ändert
Anstatt dass ein Dienst jeden abhängigen System direkt aufruft, veröffentlicht er ein Ereignis und macht weiter. Die nachgelagerten Systeme entscheiden, wie sie es konsumieren.
Ein einfaches Ereignisprotokoll könnte wie folgt aussehen:
{
"type": "order.created",
"orderId": "ord_123",
"customerId": "cus_456",
"occurredAt": "2024-07-20T10:00:00Z"
}
Das bringt Ihnen Entkopplung. Es bringt Ihnen jedoch auch mehr betriebliche Komplexität:
- Reihenfolgenfragen
- Idempotenz
- Wiederholverhalten
- Verzögerung und Verbraucher-Gesundheit
Das eigentliche Argument für Kafka ist also nicht "Echtzeit ist besser als Cron-Jobs" als Slogan. Es ist, dass einige Domänen davon profitieren, geschäftliche Änderungen als Ereignisstrom auszudrücken, anstatt als eine Reihe von eng verknüpften synchronen Aufrufen.
Wann es sich lohnt
Verwenden Sie eine ereignisgesteuerte Architektur, wenn mehrere unabhängige Reaktionen von Bedeutung sind.
Verwenden Sie Kafka nicht nur, um einfach Anwendungs-Code für ein einfaches CRUD-System zu vermeiden.
Weiterführende Literatur