Was ist ereignisgesteuerte Architektur (EDA)?
Ereignisgesteuerte Architektur (EDA) ist ein modernes Architekturmuster, das aus kleinen, entkoppelten Services aufgebaut ist, die Ereignisse veröffentlichen, nutzen oder weiterleiten.
Ein Ereignis ist eine Statusveränderung oder eine Aktualisierung. Zum Beispiel: ein Artikel, der in einen Einkaufswagen gelegt wird, eine Datei, die in ein Speichersystem hochgeladen wird, oder eine Bestellung, die versandfertig wird. Ereignisse können entweder den Status (wie Artikelname, Preis, oder Anzahl innerhalb einer Bestellung) oder einfache Kennungen (zum Beispiel: Bestellung XY ist ausgeliefert) enthalten, die man braucht, um zugehörige Informationen zu finden.
Im Gegensatz zu traditionellen Modellen, die auf Anforderungen reagieren, kann EDA lose Verkoppelungen zwischen Hersteller- und Verbraucherservices ermöglichen. Dies vereinfacht die Skalierung, Aktualisierung und unabhängige Entwicklung separater Komponenten eines Systems.
Warum ist eine entkoppelte Architektur wichtig?
Viele Organisationen stellen fest, dass sich monolithische Anwendungen, Datenbanken und Technologien negativ auf die Innovation und die Verbesserung der Benutzerfreundlichkeit auswirken. Veraltete Anwendungen und Datenbanken verringern Ihre Möglichkeiten zur Einführung moderner technologischer Rahmenbedingungen und schränken Ihre Wettbewerbsfähigkeit und Innovation ein. Wenn Sie aber Anwendungen und ihre Datenspeicher modernisieren, lassen sie sich leichter skalieren und schneller entwickeln.
Eine entkoppelte Datenstrategie verbessert die Fehlertoleranz und Ausfallsicherheit, wodurch die Markteinführung neuer Anwendungsfunktionen beschleunigt wird.
Weitere Informationen zu den Vorteilen der Modernisierung monolithischer Anwendungen finden Sie unter Aktivierung der Datenpersistenz in Microservices im AWS Prescriptive Guidance.
Was sind die Vorteile von ereignisgesteuerten Architekturen (EDA)?
Die ereignisgesteuerte Architektur (EDA) fördert die lose Vefkoppelung zwischen den Komponenten eines Systems, was zu größerer Agilität führt. Microservices können unabhängig skaliert werden, ausfallen, ohne andere Services zu beeinträchtigen, und die Komplexität der Workflows reduzieren. Ereignisse können flexibel weitergeleitet, gepuffert und für Prüfungszwecke protokolliert werden. Push-basierte Abläufe von Ereignissen können in Echtzeit stattfinden, so dass die Kosten für die Erstellung und den Betrieb von Code, der die Systeme kontinuierlich auf Änderungen abfragt, gesenkt werden.
Skalieren und fehlschlagen unabhängig voneinander
Durch die Entkopplung von Services können die Komponenten in einer ereignisgesteuerten Architektur unabhängig voneinander skalieren und ausfallen, was die Ausfallsicherheit einer Anwendung erhöht. Dies wird immer bedeutender, da die Zahl der Integrationen zwischen den Services zunimmt. Wenn einer der Services ausfällt, können die anderen weiter ausgeführt werden.
Eine ereignisgesteuerte Architektur erleichtert auch die Entwicklung von Systemen, die nahezu in Echtzeit arbeiten, und unterstützt Organisationen dabei, sich von der stapelbasierten Verarbeitung zu distanzieren. Ereignisse werden generiert, wenn sich der Status einer Anwendung ändert. Wenn Ereignisse nach oben skaliert werden, kann dies auch für die Ebene geschehen, die die Ereignisse verarbeitet.
Ereignisse werden in der Regel in Messaging-Services veröffentlicht, die sich wie ein elastischer Puffer zwischen Microservices verhalten und die Skalierung unterstützen. Ereignisse können auch an einen Router-Service gesendet werden, der Nachrichten basierend auf dem Inhalt des Ereignisses filtern und weiterleiten kann. Dadurch werden ereignisbasierte Anwendungen skalierbarer und bieten eine größere Redundanz als monolithische Anwendungen.
Mit Agilität entwickeln
Mit ereignisgesteuerter Architektur und Ereignisroutern müssen Entwickler keinen benutzerdefinierten Code mehr schreiben, um Ereignisse abzufragen, zu filtern und weiterzuleiten. Ein Ereignisrouter filtert Ereignisse automatisch und leitet sie an Verbraucher weiter. Mit dem Router entfällt auch die Notwendigkeit einer aufwändigen Koordination zwischen Produzenten- und Konsumenten-Services, was die Agilität der Entwickler steigert.
Die ereignisgesteuerte Architektur ist Push-basiert, was bedeutet, dass alles bei Bedarf geschieht. Somit können Ereignisse an den Router und an nachgelagerte Systeme gesendet werden, ohne dass abhängige Services informiert werden müssen. Dadurch können Infrastruktur und Ressourcen mit dem Ereignisvolumen hoch- und herabskaliert werden, was die Kosten für die Verarbeitung von Workloads und den Betrieb bereitgestellter Anwendungen senkt.
Erweiterbare Systeme entwickeln
Eine ereignisgesteuerte Architektur ist außerdem in hohem Maße erweiterbar. Andere Teams können Funktionen erweitern und neue Funktionen hinzufügen, ohne die bestehenden Microservices zu beeinträchtigen. Durch die Veröffentlichung von Ereignissen kann eine Anwendung in bestehende Systeme integriert werden – und künftige Anwendungen können problemlos als Ereignis-Verbraucher integriert werden, ohne dass die bestehende Lösung geändert werden muss.
Ereignis-Produzenten kennen die Ereignis-Verbraucher nicht, so dass die Erweiterung des Systems weniger Reibungsverluste mit sich bringt und neue Funktionen oder Integrationen keine Abhängigkeiten schaffen, die die zukünftige Entwicklung verlangsamen.
Komplexität reduzieren
Microservices ermöglichen Entwicklern und Architekten, komplexe Workflows zu zerlegen. Sie können beispielsweise einen E-Commerce-Monolithen in Bestellannahme und Zahlungsprozesse mit separaten Bestands-, Abwicklungs- und Buchhaltungsservices aufteilen.
Ein Workload, deren Verwaltung und Orchestrierung in einem Monolithen komplex sein kann, wird zu einer Reihe einfacher, entkoppelter Services, die unabhängig verwaltet werden und asynchron mittels Ereignismeldungen kommunizieren.
Ein ereignisgesteuerter Ansatz ermöglicht es, Services zusammenzustellen und zu orchestrieren, die Daten mit unterschiedlichen Geschwindigkeiten verarbeiten. Im nachfolgenden Beispiel interagiert ein Microservice für die Auftragsannahme über eine Warteschlange mit einem Zahlungsverarbeitungssystem.
Im Beispiel kann der Service für die Auftragsannahme große Mengen an eingehenden Aufträgen speichern, indem er die Nachrichten in einer Warteschlange puffert.
Der Service für die Zahlungsverarbeitung, der aufgrund der Komplexität der Zahlungsabwicklung in der Regel langsamer ist, kann einen stetigen Strom von Nachrichten aus der Warteschlange entgegennehmen. Der Zahlungsservice wechselt aufgrund der Logik für Wiederholungen und Fehlerbehandlung zwischen verschiedenen Systemstatus. Der Workflow-Service orchestriert und verwaltet Zahlungsschritte basierend auf dem Systemstatus und erzeugt schließlich weitere Ereignisse, die für die Bestands-, Abwicklungs- und Buchhaltungsservices von Interesse sind.
Prüfung mit Leichtigkeit
Ein Ereignis-Router in einer ereignisgesteuerten Architektur dient als zentraler Ort, um Ihre Anwendung zu prüfen und Richtlinien festzulegen. Diese Richtlinien können einschränken, wer einen Router veröffentlichen und abonnieren darf, und steuern, welche Benutzer und Ressourcen die Berechtigung zum Zugriff auf Ihre Daten haben. Darüber hinaus können Sie Ihre Ereignisse sowohl während der Übertragung als auch im Ruhezustand verschlüsseln.
Kosten senken
EDAs sind Push-basiert, d. h. alles geschieht nach Bedarf, wenn das Ereignis im Router auftritt. Auf diesem Weg zahlen Sie nicht für ständige Abfragen, um ein Ereignis zu überprüfen. Das bedeutet weniger Verbrauch von Netzwerkbandbreite, weniger CPU-Auslastung, weniger ungenutzte Flottenkapazität und weniger SSL/TLS-Handshakes.
Wie funktioniert eine ereignisgesteuerte Architektur (EDA)?
Nachfolgend finden Sie ein Beispiel für eine ereignisgesteuerte Architektur (EDA) für eine E-Commerce-Website:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
Diese Beispielsite zeigt drei Hauptkomponenten von Ereignis-Produzenten und die Ereignisse, die diese produzieren. In diesem Szenario nimmt ein Ereignisrouter die Ereignisse auf und filtert sie. Anschließend sendet er ein oder mehrere Ereignisse an die Ereignisverbraucher.
Die ereignisgesteuerte Architektur ermöglicht es der Website, auf Änderungen aus einer Vielzahl von Quellen in Zeiten hoher Nachfrage zu reagieren, ohne die Anwendung zum Absturz zu bringen oder Ressourcen zu überlasten.
Welche Typen von Workloads eignen sich für eine ereignisgesteuerte Architektur (EDA)?
Ereignisgesteuerte Architekturen (EDAs) können einen effizienten Weg bieten, um die Anforderungen hoch skalierbarer und hoch verfügbarer Workloads zu erfüllen. EDA eignet sich auch gut für Workloads mit unvorhersehbaren oder „spitzen“ Verkehrsmustern.
Wie werden Anwendungen durch eine ereignisgesteuerte Architektur (EDA) verbessert?
Die ereignisgesteuerte Architektur (EDA) fördert die lose Verkoppelung zwischen Komponenten, was sie zu einem geeigneten Ansatz für die Entwicklung moderner, verteilter Anwendungen macht.
Die Ereignisproduzenten sind sich der Aktivitäten der nachgelagerten Verbrauchern der von ihnen produzierten Ereignisse nicht bewusst, sie kümmern sich nicht darum und werden nicht durch diese belastet. Die Ereignisse selbst repräsentieren eine Zustandsänderung und können, müssen aber nicht, Daten enthalten. Ereignisse sind sich über die Konsequenzen ihrer Existenz nicht bewusst. Die Verbraucher hören zu und verarbeiten die Ereignisse, die sie interessieren. Sie können neue Verbraucher online bringen, um neue Funktionen bereitzustellen, ohne dabei bestehende Workflows zu unterbrechen.
EDAs fördern die Aufteilung von monolithischen Systemen in kleinere Domänenmodelle. Entwickler können schneller und mit weniger kognitiver Belastung arbeiten und sind rascher produktiv. Wenn kritische Funktionen entkoppelt werden, besteht auch ein geringeres Risiko für die Bereitstellung von Updates und neuen Funktionen.
Was sind einige gängige Anwendungsfälle für eine ereignisgesteuerte Architektur (EDA)?
Microservices-Kommunikation für Web- und mobile Backends
Einzelhandels- oder Medien- und Unterhaltungswebsites müssen oft hochskaliert werden, um den unvorhersehbaren Datenverkehr zu bewältigen. Kunden besuchen eine E-Commerce-Website und machen eine Bestellung. Das Auftragsereignis wird an einen Ereignisrouter gesendet. Alle nachgelagerten Microservices können das Auftragsereignis zur Verarbeitung abholen. Beispielhafte Aktionen könnten sein: Übermittlung der Bestellung, Autorisierung der Zahlung und Übermittlung der Bestelldaten an ein Versandunternehmen.
Da die einzelnen Microservices unabhängig voneinander skalieren und ausfallen können, kann der Prozess bei Auftragsspitzen hochskaliert werden, ohne dass es zu Single-Points-of-Failure kommt.
Automatisierung von Geschäftsabläufen
Bei vielen Geschäftsabläufen, wie beispielsweise bei Finanzdienstleistungs-Transaktionen, müssen die gleichen Schritte wiederholt werden. Sie können diese Schritte mit einer ereignisgesteuerten Architektur (EDA) initiieren und automatisieren.
Wenn zum Beispiel ein Kunde ein neues Konto bei einer Bank beantragt, muss die Bank einige Datenprüfungen durchführen (Identitätsnachweis, Adresse usw.). Für einige Konten ist auch eine Genehmigung durch eine Person erforderlich. Sie können all diese Schritte über einen Workflow-Service orchestrieren, der automatisch abläuft, wenn neue Kontoanträge empfangen werden.
Sie können auch einen Workflow einrichten, um Kunden-Anwendungsdaten asynchron mit Machine Learning zu verarbeiten, um relevante Daten zu extrahieren und so potenziell Stunden der manuellen Datenerfassung und -validierung zu sparen.
SaaS-Anwendungsintegration
Eine der größten Herausforderungen für Software-as-a-Service (SaaS)-Umgebungen ist die unzureichende Transparenz der Benutzeraktivitäten und -daten. Um Datensilos zu öffnen, können ereignisgesteuerte Architekturen Ereignisse aus SaaS-Anwendungen erfassen oder Ereignisse an ihre SaaS-Anwendungen senden. Beispielsweise können Sie eine Middleware entwickeln, die eingehende Partner-Bestelldaten erfasst und die Bestellungen direkt an eine interne Auftragsverarbeitungs-Anwendung sendet.
Infrastruktur-Automatisierung
Bei rechenintensiven Workloads (wie beispielsweise Finanzanalysen, Genomforschung oder Medientranskodierung) können Sie die Rechenressourcen für die hochparallele Verarbeitung hochskalieren und nach Abschluss des Auftrags wieder herabskalieren.
Beispielsweise können Unternehmen in stark regulierten Branchen mit einer EDA als Reaktion auf einen Vorfall Sicherheitsressourcen aufrüsten oder Abhilfemaßnahmen ergreifen, sobald eine Sicherheitsrichtlinie ein Alarmereignis sendet.
Wann sollten Sie ereignisgesteuerte Architekturen (EDAs) verwenden?
Ereignisgesteuerte Architekturen (EDA) sind ideal, um die Agilität zu verbessern und schnell voranzukommen. Sie sind häufig in modernen Anwendungen zu finden, die Microservices verwenden, oder in allen Anwendungen, die über entkoppelte Komponenten verfügen.
Integration heterogener Systeme
Wenn Sie Systeme auf verschiedenen Stacks laufen haben, können Sie eine EDA verwenden, um ohne Kopplung Informationen zwischen ihnen auszutauschen. Der Ereignis-Router stellt eine indirekte Verbindung und Interoperabilität zwischen den Systemen her, so dass sie Nachrichten und Daten austauschen können, ohne dabei voneinander abhängig zu sein.
Konten- und regionenübergreifende Datenreplikation
Sie können eine EDA verwenden, um Systeme zwischen Teams zu koordinieren, die in verschiedenen AWS-Regionen und -Konten arbeiten und über diese hinweg bereitstellen. Durch den Einsatz eines Ereignis-Routers zur Datenübertragung zwischen Systemen können Sie Services unabhängig von anderen Teams entwickeln, skalieren und bereitstellen.
Überwachung des Status der Ressourcen und Warnung
Statt Ihre Ressourcen kontinuierlich zu überprüfen, können Sie eine EDA verwenden, um alle Anomalien, Änderungen und Aktualisierungen zu überwachen und entsprechende Warnmeldungen zu erhalten. Diese Ressourcen können Speicher-Buckets, Datenbanktabellen, Serverless-Funktionen, Rechenknoten und mehr umfassen.
Fanout und Parallelverarbeitung
Wenn Sie viele Systeme haben, die auf ein Ereignis reagieren müssen, können Sie eine EDA verwenden, um das Ereignis aufzufächern, ohne dafür benutzerdefinierten Code schreiben zu müssen, der an jeden Verbraucher weitergeleitet wird. Der Router leitet das Ereignis an die Systeme weiter, von denen jedes das Ereignis parallel zu einem anderen Zweck verarbeiten kann.
Was sind gängige Muster für eine ereignisgesteuerte Architektur (EDA)?
Viele kurze Funktionen
Erstellen Sie viele kurze Funktionen anstelle weniger größerer Funktionen. Wenn Sie die Funktionen für Ihren Workload hochspezialisieren, bedeutet dies, dass sie prägnant sind und im Allgemeinen die Verarbeitungszeit verkürzen. Jede Funktion sollte das Ereignis verarbeiten, das an die Funktion übergeben wird, ohne Kenntnis oder Erwartungen an den gesamten Workflow oder das Volumen der Transaktionen. Dadurch ist die Funktion unabhängig von der Quelle des Ereignisses und nur minimal mit anderen Services verbunden.
On-Demand-Verarbeitung statt Batches
Viele traditionelle Systeme sind so konzipiert, dass sie periodisch ausgeführt werden und Batches von Transaktionen verarbeiten, die sich im Laufe der Zeit ansammeln. Eine Anwendung für das Bankwesen könnte beispielsweise stündlich ausgeführt werden, um Geldautomaten-Transaktionen in zentralen Hauptbüchern zu verarbeiten.
In der ereignisgesteuerten Architektur (EDA) kann die benutzerdefinierte Verarbeitung auf jedes Ereignis reagieren. Das erlaubt es dem Service, bei Bedarf die Parallelität nach oben skalieren, um Transaktionen nahezu in Echtzeit zu verarbeiten.
Wiederherstellung nach Unterbrechung
Im Falle einer Unterbrechung kann ein Service automatisch aufgerufen werden, um die Verarbeitung eines Ereignisses zu wiederholen. Da der Service dasselbe Ereignis mehr als einmal empfangen kann, sollten Sie die Funktionen so konzipieren, dass sie idempotent sind. Dadurch wird sichergestellt, dass sich das Ergebnis nicht ändert, nachdem der Service das Ereignis zum ersten Mal empfängt.
Wenn ein Einzelhändler beispielsweise zweimal versucht, eine Kreditkarte zu verarbeiten, weil es einen erneut versuch gab, verarbeitet der Service die Zahlung nur beim ersten Versuch. Beim erneuten Versuch überprüft der Service den Zahlungsstatus und verwirft das Ereignis.
Was sind die Herausforderungen mit ereignisgesteuerter Architektur (EDA)?
Wenn Sie eine ereignisgesteuerte Architektur einführen, müssen Sie möglicherweise die Art und Weise wie Sie Ihre Anwendungen gestalten, neu überdenken.
Variable Latenz
Im Gegensatz zu monolithischen Anwendungen, die alles innerhalb desselben Speicherplatzes auf einem einzigen Gerät verarbeiten können, kommunizieren ereignisgesteuerte Anwendungen über Netzwerke hinweg. Dieses Konzept führt zu variablen Latenzen. Monolithische Anwendungen können zwar eine geringere oder weniger variable Latenz aufweisen, doch dies geschieht im Allgemeinen auf Kosten der Skalierbarkeit und Verfügbarkeit.
Die Serverless AWS-Services sind hochverfügbar, was bedeutet, dass sie in mehr als einer Availability Zone in einer AWS-Region betrieben werden. Im Falle einer Serviceunterbrechung werden die Services automatisch auf alternative Availability Zones umgeschaltet und Transaktionen wiederholt. Dies hat zur Folge, dass Transaktionen nicht fehlschlagen, sondern erfolgreich abgeschlossen werden können, jedoch mit höherer Latenz.
Workloads, die eine konstante Leistung mit geringer Latenz erfordern, sind keine guten Kandidaten für EDA. Zwei Beispiele sind Anwendungen für den Hochfrequenzhandel in Banken oder die Sub-Millisekunden-Automatisierung durch Roboter in Lagerhäusern.
Eventuelle Übereinstimmung
Ein Ereignis stellt eine Änderung des Status dar. Da viele Ereignisse zu einem bestimmten Zeitpunkt über verschiedene Services in einer Architektur ablaufen, sind solche Workloads oft allmählich konsistent. Dadurch wird es komplizierter, Transaktionen zu verarbeiten, Überschneidungen zu behandeln oder den genauen Gesamtstatus eines Systems zu bestimmen.
Einige Workloads sind aufgrund der Notwendigkeit von ACID-Eigenschaften nicht für EDA geeignet. Viele Workloads enthalten jedoch eine Kombination von Anforderungen, die allmählich konsistent (z. B. Gesamtbestellungen in der aktuellen Stunde) oder stark konsistent (z. B. aktueller Bestand) sind. Für die Funktionen, die eine hohe Datenkonsistenz erfordern, gibt es Architekturmuster, die dies unterstützen. Beispiel:
- DynamoDB kann stark konsistente Lesevorgänge bereitstellen, manchmal mit einer höheren Latenz, und es kann auch Transaktionen unterstützen, um die Datenkonsistenz aufrechtzuerhalten.
- Sie können relationale Datenbanken für Features verwenden, die ACID-Eigenschaften benötigen. Allerdings ist jede relationale Datenbank weniger skalierbar als ein NoSQL-Datenspeicher.
Werte an Aufrufer zurückgeben
In vielen Fällen sind ereignisbasierte Anwendungen asynchron. Das bedeutet, dass die aufrufenden Services nicht auf Anforderungen von anderen Services warten, bevor sie mit anderen Arbeiten fortfahren. Diese grundlegende Eigenschaft von EDAs ermöglicht Skalierbarkeit und Flexibilität, macht jedoch die Übergabe von Rückgabewerten oder Workflow-Ergebnissen komplexer als in synchronen Abläufen.
In vielen Fällen ist es weniger wichtig, einen Wert zurückzugeben, als den Erfolg oder Misserfolg der Verarbeitung des Ereignisses sicherzustellen. Funktionen, die die Verarbeitung von Ereignissen sicherstellen, können wichtiger sein als die Rückgabe von Werten an einen Aufrufer.
Bei interaktiven Workloads wie z. B. Web- und Mobilanwendungen erwartet der Endbenutzer in der Regel einen Rückgabewert oder den aktuellen Status einer Transaktion. Für diese Workloads gibt es mehrere Konzeptmuster, die dem Aufrufer ein umfassendes Ereignismodell zur Verfügung stellen können. Allerdings sind diese Implementierungen in einer ereignisgesteuerten Architektur komplexer als die Verwendung eines herkömmlichen asynchronen Rückgabewerts. Die Plattform kann diese Komplexität oft abschwächen.
Service- und funktionsübergreifendes Debugging
Das Debugging ereignisgesteuerter Systeme unterscheidet sich vom Debugging einer monolithischen Anwendung. Wie bei allen Microservice-basierten Anwendungen und verschiedenen Systemen und Services, die Ereignisse übertragen, kann es eine Herausforderung sein, den genauen Status mehrerer Services zu erfassen und zu reproduzieren, wenn ein Fehler auftritt. Da jeder Service- und Funktionsaufruf über separate Protokolldateien verfügt, kann es komplizierter sein, festzustellen, was mit einem bestimmten Ereignis passiert ist, das einen Fehler verursacht hat.
Orchestrierung
Es ist üblich, dass einfache Workflows im Laufe der Zeit komplexer werden. In einem typischen Monolithen kann dies zu enger gekoppelten Gruppen von Funktionen und Services sowie zu komplexem Code führen, der Routing und Ausnahmen behandelt.
Um den Status des Systems zu verfolgen, verwenden Workflows, die Verzweigungslogik, verschiedene Arten von Fehlermodellen und Wiederholungslogik beinhalten, normalerweise einen Orchestrator. Bei der Erstellung einer ereignisgesteuerten Serverless-Anwendung ist es wichtig zu ermitteln, wann dies der Fall ist, damit Sie diese Logik für eine ordnungsgemäße Orchestrierung in eine Zustandsmaschine migrieren können.
Welche AWS-Services verwenden eine ereignisgesteuerte Architektur (EDA)?
AWS-Services erzeugen oder nutzen in der Regel Ereignisse, was die Erstellung von Lösungen mit einer ereignisgesteuerten Architektur (EDA) erleichtert.
Darüber hinaus umfassen Services wie Amazon EventBridge, Amazon SNS, Amazon SQS und AWS Step Functions Funktionen, die Kunden dabei unterstützen, weniger Boilerplate-Code zu schreiben und EDAs schneller zu erstellen.
Amazon EventBridge
Sie können Amazon EventBridge nutzen, um Event Buses für ereignisgesteuerte Anwendungen in großem Umfang zu erstellen und dabei Ereignisse von SaaS-Anwendungen, anderen AWS-Services oder benutzerdefinierten Anwendungen zu verwenden.
EventBridge verwendet Regeln, um Ereignisse von Ereignisquellen an verschiedene Ziele weiterzuleiten. Ziele können AWS-Services wie AWS Lambda, Step Functions und Amazon Kinesis sein, oder jeder HTTP-Endpunkt über EventBridge-API-Ziele.
Eine beliebte Integration für EDA-Anwendungsfälle ist Step Functions, bei der Ereignisse bestimmte Workflows auslösen.
AWS Step Functions
AWS Step Functions enthält Workflow Studio, einen visuellen Workflow-Designer mit wenig Code, mit dem Entwickler verschiedene AWS-Services orchestrieren können. Sie können Workflow Studio verwenden, um verteilte Anwendungen zu erstellen, IT- und Geschäftsprozesse zu automatisieren, sowie Daten- und Machine-Learning-Pipelines mit AWS-Services zu entwickeln.
Amazon SNS
Wir empfehlen die Verwendung von Amazon Simple Notification Service (Amazon SNS) zur Erstellung von Anwendungen, die auf Ereignisse mit hohem Durchsatz und geringer Latenz reagieren, welche von anderen Anwendungen, Microservices oder AWS-Services veröffentlicht werden. Sie können Amazon SNS auch für Anwendungen verwenden, die einen sehr hohen Fanout an Tausende oder sogar Millionen von Endpunkten benötigen.
Amazon SQS
Amazon Simple Queue Service (Amazon SQS) bietet einen sicheren, dauerhaften und verfügbaren, gehosteten Warteschlangen-Service, den Sie zur Integration und Entkopplung verteilter Softwaresysteme und -komponenten verwenden können. Amazon SQS bietet gängige Konstrukte wie Warteschlangen für unzustellbare Nachrichten und Kostenzuordnungs-Tags.
AWS ereignisgesteuerte Architektur - nächste Schritte
Sie erhalten sofort Zugriff auf das kostenlose Kontingent von AWS.
Beginnen Sie mit der Entwicklung in der AWS-Managementkonsole.