Einblicke
Dieser Link führt zurück
Ereignisgesteuerte Entwicklung
,
Microservice-Architektur
,
Kafka
,

Ereignisgesteuerte Architektur und Kafka erklärt: Pro und Kontra

Ereignisgesteuerte Architektur und Kafka erklärt: Pro und Kontra
30.6.2023

Die ereignisgesteuerte Architektur wird bei der Entwicklung von Webanwendungen aufgrund ihrer Vorteile bei komplexen, umfangreichen Anwendungen zunehmend der traditionellen Anfrage-Antwort-Architektur vorgezogen. Im Gegensatz zur synchronen Kommunikation in der Anfrage-Antwort-Architektur ermöglicht die ereignisgesteuerte Architektur eine asynchrone Kommunikation, die den gleichzeitigen und unabhängigen Betrieb von Komponenten ermöglicht. Sie unterstützt die Datenverarbeitung in Echtzeit und erleichtert die Integration verschiedener Systeme und Dienste, wodurch sie sich gut für komplexe und dynamische Umgebungen eignet.

Was ist ein Ereignis?

Ein Ereignis ist eine Aktion, die eine Benachrichtigung auslöst oder den Zustand der Anwendung ändert. Ein Ereignis kann z. B. auftreten, wenn Sie etwas in sozialen Medien posten, eine Online-Bestellung aufgeben, eine finanzielle Transaktion durchführen oder sich für ein Konto registrieren. Diese Ereignisse enthalten relevante Kontextinformationen, die entsprechende Aktionen in anderen Komponenten auslösen, z. B. die Benachrichtigung von Followern, die Verwaltung von Beständen, die Verarbeitung von Zahlungen und die Ausführung von Bestellungen.

Nehmen wir ein Beispiel aus den sozialen Medien und sehen wir uns die Unterschiede zwischen einer ereignisgesteuerten Architektur und einer Request-Response-Architektur an.

‍Ereignisgesteuerte Architektur vs. Anfrage-Antwort-Architektur

Wenn Sie sich in einer ereignisgesteuerten Architektur an Social Media-Aktivitäten beteiligen, werden durch Aktionen wie das Posten einer neuen Nachricht oder das Liken eines Beitrags Ereignisse erzeugt, die verschiedene Aktionen wie das Aktualisieren von Zeitleisten, das Benachrichtigen von Followern und das Speichern von Inhalten auslösen. Diese Echtzeit-Ereignisverarbeitung ermöglicht unmittelbare Aktualisierungen und Interaktionen auf der gesamten Plattform und sorgt für ein dynamisches und ansprechendes Nutzererlebnis.

Bei einer herkömmlichen Anfrage-Antwort-Architektur hingegen werden bei der Interaktion mit sozialen Medien Anfragen an den Server für Aktionen wie das Posten oder Liken von Beiträgen gesendet. Der Server verarbeitet diese Anfragen, aktualisiert die erforderlichen Daten und antwortet Ihnen, um Ihnen den Erfolg oder Misserfolg des Vorgangs mitzuteilen. Ihr Browser wartet dann auf die Antwort, bevor er die Schnittstelle aktualisiert oder entsprechende Benachrichtigungen anzeigt. In diesem Fall kann es zu einer leichten Verzögerung kommen , während Sie auf die Antwort des Servers warten, was sich möglicherweise auf Ihre Wahrnehmung von Geschwindigkeit und Interaktivität auswirkt.

‍Ereignisgesteuerte Entwicklung: Microservice-Architektur

Im Bereich der sozialen Medien würde eine monolithische Architektur bedeuten, dass alle Funktionen wie Benutzerprofile, News-Feed, Benachrichtigungen und Nachrichten innerhalb einer einzigen Anwendung eng miteinander verbunden sind. Die Verwaltung und Aktualisierung dieser miteinander verbundenen Funktionalitäten wird mit dem Wachstum der Social-Media-Plattform komplex und schwierig.

In einer Microservice-Architektur mit ereignisgesteuerter Kommunikation werden die Funktionalitäten jedoch in separate Microservices aufgeteilt. Einzelne Microservices wären zum Beispiel für Benutzerprofile, Newsfeeds, Benachrichtigungen und Nachrichten. Wenn Sie etwas posten, wird ein Ereignis ausgelöst und an die entsprechenden Microservices weitergeleitet. Der für den News-Feed zuständige Microservice aktualisiert den Feed, der Benachrichtigungs-Microservice sendet Benachrichtigungen an Ihre Follower, und der Messaging-Microservice speichert und verarbeitet die Nachricht. Dieser modulare Ansatz ermöglicht es jedem Microservice, seine spezifischen Aufgaben unabhängig zu erledigen, was eine einfachere Entwicklung, Skalierbarkeit und Wartung der Social-Media-Plattform als Ganzes ermöglicht.

Kafka und Microservices

Apache Kafka ist wie ein Superheld für Microservices. Es meistert alle lästigen Probleme der Orchestrierung und bietet gleichzeitig Skalierbarkeit, Effizienz und blitzschnelle Geschwindigkeit. Kafka ist das Tool der Wahl für die Kommunikation zwischen den Diensten, das die Latenzzeit extrem niedrig hält und Ausfälle wie ein Champion behandelt. Es fungiert als zentrales Messaging-System, das den nahtlosen Datenaustausch und die Koordination zwischen verschiedenen Diensten ermöglicht. Dank seiner horizontalen Skalierbarkeit können Sie weitere Dienstinstanzen hinzufügen, wenn Ihre Arbeitslast wächst. Außerdem sorgt die verteilte Struktur für einen hohen Durchsatz und hält mit anspruchsvollen Arbeitslasten Schritt, ohne dass Sie ins Schwitzen kommen.

Effizienz? Mit dem Publish-Subscribe-Modell können Dienste Nachrichten in Themen veröffentlichen, und andere Dienste können diese Themen abonnieren, um die benötigten Benachrichtigungen zu erhalten. Dank dieser entkoppelten Struktur können sich die Dienste unabhängig voneinander entwickeln, so dass das System reibungslos und effizient läuft.

Und vergessen wir nicht die extrem niedrige Latenzzeit und Fehlertoleranz. Kafka speichert Nachrichten in verteilter und replizierter Form und garantiert so die Beständigkeit der Daten auch bei Ausfällen. Wenn also ein Dienst oder ein Knoten ausfällt, geht die Show weiter, ohne dass Daten verloren gehen oder der Arbeitsablauf durcheinander gerät.  

Wie funktioniert die ereignisgesteuerte Architektur mit Kafka?

Erzeuger und Verbraucher

In einer ereignisgesteuerten Architektur folgen Ereignisse einem unidirektionalen Fluss, der von einem Produzenten zu einem Konsumenten führt. Ein Produzent ist eine Einheit, die Ereignisse erzeugt und veröffentlicht, während ein Konsument eine Einheit ist, die diese Ereignisse abonniert und verarbeitet.

Stellen Sie sich eine Plattform für soziale Medien vor, auf der Sie Ihre Aktualisierungen veröffentlichen können. Wenn Sie einen neuen Beitrag erstellen, fungieren Sie als Ereignisproduzent. Im Gegensatz zu einem Telefonanruf, bei dem Sie eine direkte Antwort erwarten, geht der Ereignisproduzent in diesem Fall nicht von einer Antwort des Verbrauchers aus. Durch die asynchrone Natur von Ereignissen muss die Codeausführung nicht mehr blockiert werden, wodurch Zeitüberschreitungen vermieden und eine reibungslosere Verarbeitung gewährleistet wird.

Ereignisse treten aufgrund bestimmter Aktionen auf, und es gibt kein vordefiniertes Zielsystem. Stattdessen bekunden die Dienste ihr Interesse an den von anderen Diensten erzeugten Ereignissen. In unserem Beispiel für soziale Medien würde Dienst B, der den Newsfeed-Dienst repräsentiert, sein Interesse an den Ereignissen bekunden, die von Dienst A erzeugt werden, der den Nutzerposting-Dienst repräsentiert. Es kann jedoch auch andere Dienste geben, wie z. B. Dienst C oder D, die ebenfalls an diesen Ereignissen interessiert sind. Dies ermöglicht eine entkoppelte Architektur, in der Dienste unabhängig voneinander auf Ereignisse reagieren können, was die Flexibilität erhöht und die Skalierbarkeit fördert.

Aber wie können wir sicherstellen, dass ein von einem System ausgelöstes Ereignis alle interessierten Dienste erreicht?

Beispiele für Broker und Zookeeper in Kafka: Ereignisgesteuerte Entwicklung

Makler und Zoowärter

Bei der ereignisgesteuerten Entwicklung sind Message Broker für die Entkopplung von Anwendungen und die Gewährleistung der Verfügbarkeit unerlässlich. Sie dienen als Vermittler zwischen Ereignisproduzenten und -konsumenten und ermöglichen Skalierbarkeit durch Hinzufügen weiterer Knoten nach Bedarf. Diese Broker arbeiten als verteiltes System zusammen und replizieren und liefern Nachrichten für den Verbrauch.

Zookeeper verwaltet verschiedene Koordinierungsaufgaben. Er verwaltet die Konfigurationsinformationen für den Kafka-Cluster, einschließlich Broker-Standorte und Themen. Außerdem verwaltet er die Leader-Wahlen für Partitionen und gewährleistet so die Nachrichtenreplikation und Verfügbarkeit auch bei Ausfällen. Zookeeper verwaltet die Offsets der Verbraucher, so dass diese nach einem Neustart oder Ausfall das Lesen dort fortsetzen können, wo sie aufgehört haben.

Zusammenfassend lässt sich sagen, dass die Social-Media-Plattform durch die Kombination von Brokern und Zookeeper in Kafka in der Lage ist, die Speicherung, Verteilung und Koordinierung von Ereignissen zu übernehmen, die durch Nutzeraktivitäten generiert werden. Dieses Setup bietet ein zuverlässiges und skalierbares Messaging-System für die ereignisgesteuerte Architektur der Plattform.

Thema, Partition, Offset in Kafka

Thema, Partition, Offset
Thema

In Kafka ist ein Topic ein Nachrichtenstrom, der aufgeteilt und über mehrere Broker im Cluster verteilt werden kann. Sie können viele Produzenten und Konsumenten für ein Topic haben, und es ist einfach, sie nach Bedarf zu erstellen und zu verwalten.

‍Teilung

Eine Partition ist wie ein Teil von Nachrichten innerhalb eines Themas, das auf einem einzigen Broker läuft. Partitionen helfen Kafka, hohe Arbeitslasten zu bewältigen, indem sie die Speicherung und Bereitstellung von Nachrichten auf verschiedene Broker aufteilen. Jede Partition hat eine eindeutige ID, die als Partitionsschlüssel bezeichnet wird und mit deren Hilfe bestimmt werden kann, welcher Broker die Nachrichten in dieser Partition bearbeitet.

Versetzt

Ein Offset ist eine spezielle ID, die jeder Nachricht in einer Partition zugewiesen wird. Sie zeigt die genaue Position der Nachricht innerhalb der Partition an. Mit Hilfe von Offsets können die Nutzer nachvollziehen, welche Nachrichten sie bereits aus einem Thema gelesen haben, so dass sie leicht dort weitermachen können, wo sie aufgehört haben.

Schema-Register

Schemaregister und Avro

Schema Registry ist ein zentraler Dienst, der Schemata für die Datenserialisierung in einem verteilten System speichert und verwaltet. Es stellt ein Repository für die Registrierung und den Abruf von Schemata bereit und ermöglicht es Datenproduzenten und -konsumenten, die Kompatibilität und Konsistenz ihrer Datenstruktur sicherzustellen. Durch die Verwaltung von Schemata vereinfacht das Schema-Register die Arbeit mit verschiedenen Datenformaten und -versionen und erleichtert die nahtlose Integration und Interoperabilität in datengesteuerten Anwendungen.

Die Schemaregistrierung in Kafka ist wie ein praktischer Dienst, der die Avro-Schemata aufzeichnet. Sie speichert und verwaltet Schemas, sodass Produzenten neue Schemas registrieren können und Konsumenten beim Lesen von Nachrichten aus einem Topic einfach auf die neuesten Versionen zugreifen können. Apropos Avro: Avro ist ein raffiniertes Format, das in Kafka verwendet wird, um Nachrichten schön und kompakt zu gestalten. Mit Avro-Schemata können Sie definieren, wie Ihre Daten aussehen sollen, indem Sie die Typen der einzelnen Felder und alle verschachtelten Strukturen angeben.

Wenn Sie eine neue Nachricht posten oder einen Beitrag in sozialen Medien liken, müssen die Daten, die diese Aktion repräsentieren, kodiert und übertragen werden; hier kommen die Avro-Schemata ins Spiel. Das Avro-Schema definiert die Datenstruktur, indem es die Typen der einzelnen Felder und alle verschachtelten Strukturen angibt. Das Schema kann zum Beispiel Felder wie "user_id", "post_id", "timestamp" und "action_type" definieren. Die Schemaregistratur speichert und verwaltet diese Avro-Schemata für die Social Media-Plattform.  

Außerdem bietet das Schemaregister Kompatibilitätsprüfungen. Es stellt sicher, dass Produzenten und Konsumenten kompatible Versionen des Schemas verwenden. Dies ist wichtig, da sich das Schema ändern kann, wenn sich die Social-Media-Plattform weiterentwickelt, um neue Funktionen oder Datenfelder zu integrieren. Die Kompatibilitätsprüfungen tragen dazu bei, Probleme zu vermeiden, bei denen ein Produzent Daten sendet, die von den Konsumenten aufgrund von Schemafehlern nicht richtig interpretiert oder verarbeitet werden können.

Hier ist eine Demo-Anwendung, die Ihnen helfen kann, die oben genannten Konzepte besser zu verstehen:
https://github.com/PRODYNA/insights-kafka-demo

‍Pround Contra der ereignisgesteuerten Entwicklung mit Kafka

Vorteile:

Schnell und wütend: Kafka ist ein Datenverarbeitungsmonster, das große Datenmengen blitzschnell verschlingt und sich perfekt für das Datenstreaming in Echtzeit eignet.

Erhöhen Sie die Leistung: Sie brauchen mehr Leistung? Mit seiner Architektur können Sie Ihre Datenverarbeitung durch Hinzufügen von weiteren Brokern und Partitionen aufstocken.

Der beste Freund der Daten: Er bewahrt Ihre Daten sicher und zuverlässig auf und speichert sie für die Ewigkeit. Analysieren Sie also diesen Schatz an Informationen.

Datenverarbeitung in Echtzeit: Mit Kafka können Sie Daten in Echtzeit verarbeiten und analysieren, was Unternehmen den Vorteil verschafft, schnelle, datengesteuerte Entscheidungen zu treffen.

Tausendsassa in allen Bereichen: Kafka ist vielseitig und eignet sich für verschiedene Szenarien wie Messaging, Stream Processing und Datenintegration. Es ist das Schweizer Taschenmesser der Datenverarbeitung.

Nachteile:

‍Komplexität: Das Einrichten und Verwalten eines Kafka-Clusters kann eine Denksportaufgabe sein, die profundes Know-how und ständige Überwachung erfordert.  

Hungerspiele: Es kann ein Ressourcenfresser sein, vor allem wenn es um große Datenmengen geht. Wir optimieren die Ressourcenzuweisung und verwenden raffinierte Komprimierungstechniken, um die Dinge in Schach zu halten.

Datenverlust macht Angst: Auch wenn das System auf Robustheit ausgelegt ist, besteht dennoch eine geringe Chance auf Datenverlust, wenn ein Broker ausfällt. Bei PRODYNA konfigurieren wir Replikationsfaktoren und bauen Fehlertoleranz auf, um mögliche Risiken zu minimieren.

Integrationspuzzle: Die Integration in Ihre bestehenden Arbeitsabläufe und technischen Systeme erfordert möglicherweise Anpassungen und kompatible Konnektoren. Nutzen Sie das reichhaltige Kafka-Ökosystem, verlassen Sie sich auf die unterstützende Community und machen Sie sich die Magie der Middleware zunutze, um die Dinge zu vereinfachen.

Kosten: Das Einrichten und Verwalten eines Kafka-Clusters kann ein Loch in Ihre Tasche reißen. Wir untersuchen Cloud-basierte Kafka-Dienste und intelligente Ressourcenzuweisung, um diese Kosten in Grenzen zu halten. Es geht darum, mit dem Geld sparsam umzugehen.

Mit Messaging-Lösungen wie Kafka bietet die ereignisgesteuerte Architektur viele Vorteile für den Aufbau verteilter, Microservices-basierter Anwendungen. Sie bietet Skalierbarkeit, Reaktionsfähigkeit und Ausfallsicherheit und ist damit eine attraktive Wahl für Unternehmen.  

-----

Als Softwarearchitekt liebe ich Kafka und die ereignisgesteuerte Architektur aus mehreren Gründen. Erstens ist die Kafka-Community hervorragend und bietet wertvolle Unterstützung und Ressourcen. Die umfassende Dokumentation macht es einfach, Kafka zu verstehen und in verschiedenen Projekten zu implementieren. Zweitens bietet Kafka umfangreiche Funktionen und Flexibilität, die es mir ermöglichen, skalierbare und belastbare Systeme zu entwickeln, die auf spezifische Anforderungen zugeschnitten sind. Und schließlich machen die nahtlosen Integrations- und Testmöglichkeiten, insbesondere mit Java und Spring Boot, die Arbeit mit Kafka zu einem Vergnügen und gewährleisten die Zuverlässigkeit meiner Anwendungen. Die Verfügbarkeit von Kafka-Testcontainern vereinfacht den Testprozess weiter und macht ihn noch komfortabler.

Nützliche Links:

https://kafka.apache.org/documentation/

https://docs.spring.io/spring-kafka/reference/html/

https://avro.apache.org/docs/1.11.1/

https://github.com/confluentinc/examples

https://developer.confluent.io/get-started/spring-boot/

Bojana Belojevic
Bojana Belojevic
Software Architekt
Bojana Belojevic ist eine erfahrene Softwarearchitektin mit 9 Jahren Erfahrung. Ihr Schwerpunkt liegt auf der Anwendung eines ganzheitlichen Ansatzes zur Entwicklung robuster Softwarelösungen.

Weitere verwandte Themen

weißer Pfeil, der nach unten zeigt

Weiter scrollen, um zurückzukehren

Dies ist ein "Zurück zum Anfang" Button