Eine ereignisgesteuerte Architektur ist ein Softwaredesignmuster, bei dem Mikrodienste auf Statusänderungen, die als Ereignisse bezeichnet werden, reagieren. Ereignisse können entweder einen Bundesstaat (z. B. den Preis eines Artikels oder eine Lieferadresse) oder Ereignisse (z. B. eine Benachrichtigung, dass eine Bestellung eingegangen ist oder gesendet wurde) enthalten. Die Ereignisse lösen Mikrodienste aus, die zusammen ein gemeinsames Ziel erreichen möchten, aber außer dem Ereignisformat nichts übereinander wissen müssen. Obwohl der Mikrodienst zusammen arbeitet, kann jeder Mikrodienst eine andere Geschäftslogik anwenden und seine eigenen Ausgabeereignisse ausgeben.
Ein Ereignis hat folgende Merkmale:
- Es ist ein Datensatz zu etwas, das geschehen ist.
- Erfasst eine unveränderliche Tatsache, die nicht geändert oder gelöscht werden kann.
- Dies geschieht unabhängig davon, ob ein Dienst Logik bei der Nutzung anwendet.
- Sie können unbegrenzt und in großem Umfang gespeichert und so oft wie nötig genutzt werden.
In einem ereignisgesteuerten System werden Ereignisse von Ereigniserstellern generiert und von einem Event-Router (oder Broker) gefiltert und dann per Fan-out an die entsprechenden Ereignisnutzer (oder Senken) verteilt. Die Ereignisse werden an Abonnenten weitergeleitet, die durch einen oder mehrere übereinstimmende Trigger definiert werden. Diese drei Komponenten – Ereignisersteller, Ereignisrouter, Ereignisnutzer – sind entkoppelt und können unabhängig voneinander bereitgestellt, aktualisiert und skaliert werden:
Der Ereignisrouter verknüpft die verschiedenen Dienste und ist das Medium, über das Nachrichten gesendet und empfangen werden. Es führt eine Antwort auf das ursprüngliche Ereignis aus, die von einem Ereignisersteller generiert wurde, und sendet diese Antwort nachgelagert an die entsprechenden Nutzer. Ereignisse werden asynchron behandelt und ihre Ergebnisse werden bestimmt, wenn ein Dienst auf ein Ereignis reagiert oder davon betroffen ist, wie im folgenden Diagramm eines sehr vereinfachten Ereignisablaufs gezeigt:
Anwendungsfälle für ereignisgesteuerte Architekturen
Beachten Sie beim Entwerfen Ihres Systems die folgenden Verwendungen.
- Für Monitoring und Empfang von Benachrichtigungen bei Anomalien oder Änderungen an Storage-Buckets, Datenbanktabellen, virtuellen Maschinen oder anderen Ressourcen.
- Für Fan-Outs einzelner Ereignisse für mehrere Nutzer. Der Ereignisrouter überträgt das Ereignis per Push an die entsprechenden Nutzer, ohne dass Sie benutzerdefinierten Code schreiben müssen. Jeder Dienst kann das Ereignis dann parallel, jedoch unterschiedlich verarbeiten.
- Für die Interoperabilität zwischen verschiedenen Technologiestacks bei gleichzeitiger Unabhängigkeit der einzelnen Stacks.
- Koordinieren von Systemen und Teams, die in verschiedenen Regionen und Konten tätig sind und bereitstellen. Sie können die Inhaberschaft von Mikrodiensten neu organisieren. Es gibt weniger teamübergreifende Abhängigkeiten und Sie können schneller auf Änderungen reagieren, die andernfalls durch Hindernisse für den Datenzugriff blockiert werden.
Vorteile ereignisgesteuerter Architekturen
Dies sind einige der Vorteile beim Erstellen einer ereignisgesteuerten Architektur.
Lose Kopplung und verbesserte Agilität für Entwickler
Ereignisersteller werden logisch von Ereignisnutzern getrennt. Diese Entkopplung zwischen der Produktion und dem Verbrauch von Ereignissen bedeutet, dass Dienste interoperabel sind, aber unabhängig voneinander skaliert, aktualisiert und bereitgestellt werden können.
Die lose Kopplung reduziert Abhängigkeiten und ermöglicht die Implementierung von Diensten in verschiedenen Sprachen und Frameworks. Sie können Ereignisersteller und Empfänger hinzufügen oder entfernen, ohne die Logik in einem einzelnen Dienst ändern zu müssen. Sie müssen keinen benutzerdefinierten Code schreiben, um Ereignisse abzufragen, zu filtern und weiterzuleiten.
Asynchrone Ereignisse und Ausfallsicherheit
In einem ereignisgesteuerten System werden Ereignisse asynchron generiert und können so ausgegeben werden, wie sie auftreten, ohne auf eine Antwort zu warten. Lose gekoppelte Komponenten bedeuten, dass bei einem Ausfall eines Dienstes die anderen nicht betroffen sind. Bei Bedarf können Sie Ereignisse protokollieren, damit der empfangende Dienst ab dem Zeitpunkt des Fehlers fortgesetzt werden kann oder frühere Ereignisse wiedergeben kann.
Push-basierte Nachrichten, Echtzeit-Ereignisstreams und geringere Kosten
Ereignisgesteuerte Systeme ermöglichen eine Push-basierte Benachrichtigung und Clients können Aktualisierungen erhalten, ohne kontinuierlich Remotedienste auf Statusänderungen abfragen zu müssen. Diese Push-Nachrichten können direkt für die Datenverarbeitung und -transformation sowie für Echtzeitanalysen verwendet werden. Außerdem reduziert sich bei den weniger Abfragen der Netzwerk-E/A-Wert und die Kosten werden verringert.
Vereinfachtes Auditing und Event Sourcing
Der zentralisierte Standort des Ereignisrouters vereinfacht die Prüfung und ermöglicht Ihnen, zu steuern, wer mit einem Router interagieren kann und welche Nutzer und Ressourcen Zugriff auf Ihre Daten haben. Sie können Ihre Daten auch während der Übertragung und im inaktiven Zustand verschlüsseln.
Darüber hinaus können Sie das Event Sourcing nutzen. Bei diesem Architekturmuster werden alle Änderungen am Zustand einer Anwendung in derselben Reihenfolge aufzeichnet, in der sie ursprünglich angewendet wurden. Event Sourcing bietet ein Log unveränderlicher Ereignisse, das zu Auditing-Zwecken, zur Neuerstellung von Verlaufszuständen oder als kanonische Beschreibung aufbewahrt werden kann, um eine geschäftsbezogene Entscheidung zu erklären.
Hinweise zur Architektur
Eine ereignisgesteuerte Architektur erfordert möglicherweise einen neuen Ansatz für Ihr Anwendungsdesign. Dieses Architekturmuster eignet sich zwar gut für Anwendungen, die Mikrodienste oder lose gekoppelte Komponenten nutzen, doch sollten Sie auch Folgendes in Betracht ziehen:
Kann Ihre Ereignisquelle die Zustellung garantieren, wenn Sie jedes einzelne Ereignis verarbeiten müssen?
Es sollte eine robuste und zuverlässige Ereignisquelle sein.
Kann Ihre Anwendung mehrere asynchrone Anfragen verarbeiten?
Die Systemleistung sollte nicht von einem globalen Bereich oder elastischen Datenbanken abhängig sein.
Wie möchten Sie den Ereignisfluss verfolgen?
Eine ereignisgesteuerte Architektur unterstützt dynamisches Tracking mithilfe von Monitoringdiensten, jedoch nicht statisches Tracking mit Codeanalyse.
Möchten Sie die Daten in der Ereignisquelle zur Neuerstellung des Zustands verwenden?
Sie müssen eine geeignete Methode zum Deduplizieren und Sortieren Ihrer Daten finden.
Nächste Schritte
- Informationen zur Verarbeitung von Ereignissen durch Eventarc finden Sie in der Übersicht zu Eventarc.
- Informationen zum Erstellen einen Ereignis-Triggers