Wie in so vielen Dingen ist die Natur ein großartiger Architekt und hat sich diese Konzepte ausgedacht, lange bevor Entwickler und Architekten überhaupt daran gedacht haben.
Spinnen nutzen seit Jahrtausenden erfolgreich ereignisbasierte Konzepte. Ereignisgesteuerte Architekturen bieten die Möglichkeit, hocheffizient und in Echtzeit über relevante Änderungen informiert zu werden und darauf zu reagieren.
Die meisten Spinnen sind sehr effiziente Räuber. Sie setzen eine Vielzahl von Strategien ein, um Beute zu fangen. Die häufigste ist das verwenden klebriger Netze. Die Methode des klebrigen Netzes zum Fangen von Beute ist diejenige, an der wir hier interessiert sind.
Nachdem die Spinne ihr Netz gesponnen hat, wartet sie darauf, dass sich die Beute darin verfängt. Die Spinne spürt den Aufprall und den Kampf eines Beutetiers durch Vibrationen, die durch das Netz übertragen werden. Nachdem sie eine Vibration wahrgenommen hat, bewertet die Spinne , ob die Vibrationen von einem Beutetier oder von etwas anderem verursacht wird, das die Spinne nicht interessier, wie z.B. ein Blatt. Wenn sich ein Blatt in einem Spinnennetz verfängt , ignoriert die Spinne diese Veränderung in ihrem Netz einfach. Wenn jedoch ein Beutetier
Die Beute oder das Blatt im Netz ist ein Ereignis - eine bedeutende Veränderung des Zustands des Spinnennetzes.
Das Spinnennetz ist der Even-Broker, der Ereignisse über die Schwingungen des Netzes transportiert.
Die Spinne ist der Event-Consumer. Sie wird über wesentliche Änderungen des Netzstatus informiert und reagiert entsprechend den erhaltenen Informationen.
Nun zu den Bausteine Event based Architektur
Eine Event based Architecture ist eine Softwarearchitektur, die Ereignisse als zentrales Mittel für die Interaktion zwischen ihren Softkomponenten verwendet. Die umfasst die Erfassung, Kommunikation, Verarbeitung und Persistenz von Ereignissen. Bei Softwarekomponenten in ereignisgesteuerten Architekturen handelt es sich in der Regel um Microservices, aber es können auch andere arten von Software-Systemen das ist der Vorteil der event-based Architektur.
Ereignisgesteuerte Architekturen stellen einen architektonischen Ansatz dar und basieren. Nicht auf einer bestimmten Programiersprachen. Tatsächlich kann eine ereignisgesteuerte Architektur in fast jeder modernen Programmiersprache erstellt werden. Ereignisgesteuerte Architekturen eignen isch hervorragend für verteilte Softwareumgebungen und ermöglichen eine minimale Kopplung. Diese natürliche Verbreitung von ereignisgesteuerten Architekturen wird noch dadurch verstärkt, dass ein Ereignis - eine signifikante Änderung - fast alles sein kann. Daraus ergibt sich eine große Anzahl von möglichen Ereignisquellen.
Komponenten von ereignisgesteuerten Architekturen
Ereignisgesteuerte Architekturen bestehen aus einer sehr begrenzten Anzahl von Architekturkomponenten wie folgt:
Event producer
Der Eignisproduzent ist die Quelle des Ereignisses und sendet das Ereignis aus, um anzuzeigen , dass es eingetreten ist. Der Ereignisproduzent weiß nur, dass das Ereignis eingetreten ist; er weiß nicht, wer sich für das Ereignis interessiert oder wie die interessierten Parteien auf die Information über das Ereignis reagieren werden.
Event broker
Der Ereignisbroker ist ein Vermittler, der Ereignisse vermittelt und verwaltet. Wenn man es mit den Definitionen sehr genau nimmt, kann der Broker sogar als optional betrachtet werden, wenn der Produzent ein. Ereignis-Broker eingesetzt werden.
Event consumer
Ereigniskonsumenten sind Softwarekomponenten, die wissen müssen, dass ein Ereignis eingetreten ist, und sich in der Regel beim Ereignisbroker anmelden, um über Ereignisse informiert zu werden.
Die Kombination dieser begrenzten Anzahl von Komponenten kann zu hochkomplexes und leistungsfähigen Architekturen führen, die sich durch extreme Skalierbarkeit und Flexibilität auszeichnen.
Daten und Events oder Events und Daten?
Früher gab es einen klaren Fokus auf Daten, z.B. zunächst in Backend-Systemen und später in Data Lakes. Die Quelle der Wahrheit war klar: Die Daten standen im Vordergrund, und die Landschaften und Systeme folgten einem datenorierten Modell. Im Rahmen dieses Modells wurden Teilmengen von Daten gesammelt, gespeichert und so effizient wie möglich abgerufen.
Mit dem Aufkommen der ereignisgesteuerten Architekturen hat sich der Schwerpunkt von Daten auf Ereignisse verlagert. Die Frage ist nun, wie weit diese Verlagerung gehen soll. Einige sagen, dass jetzt Ereignisse am wichtigsten sind und dass die Quelle der Wahrheit in erster Linie aus Ereignissen besteht, während Daten nur die zweite Quelle sind. Es gibt zwei Schulen von ereignisgesteuerten Architekturen: die ereignisprotokollbasierten Architekturen, die bis zu einem gewissen Grad Ereignisse an die erste und Daten an die zweite Stelle setzen , und die ereignisbrokerbasierten Architekturen, die immer noch Daten an die erste und Ereignisse an die zweite Stelle setzen.
Diese beiden Ansätze beruhen auf zwei unterschiedlichen Mechanismen, nämlich Pub/Sub und Event Streaming :
Ereignis-Broker-basiertes Messaging
Dieser Ansatz stützt sich auf ein Veröffentlichungs- und Abonnementkonzept (Pub/Sub) , das auf Abbonnements beim Ereignisbroker aufbaut. Nachdem ein Ereignis eingetreten ist, wird es veröffentlicht, und die Abonnenten werden benachrichtigt. Ein Ereignisbroker übernimmt die Rolle des Vermittlers, führt aber kein Protokoll.
Nachdem das Ereigniss konsumiert wurde, gibt es in der Regel keine Möglichkeit, das Ereignis erneut abzuspielen. Die Quelle der Wahrheit sind bei diesem Ansatz also immer noch die Daten. Ereignisse können als Echtzeit-Auslöser für die Druchführung von Aktionen mit den Daten betrachtet werden. Bei diesem Ansatz sind sowohl Benachrichtigugnsereignisse als auch Datenereignisse möglich, wenn man es genau nimmt.
Ereignisprotokoll-basiertes Messaging
Dieser Ansatz stützt sich auf ein Ereignisprotokoll und schreibt alle auftretenden Ereignisse in dieses Protokoll. Die Ereignisse werden in der Regel für einen bestimmten Zeitraum im Ereignisprotokoll gespeichert.
Ereignisprotokoll ermöglichten es Ihnen, Ereignisse auszuspielen, um den Zustand Ihrer Anwendung anhand der protokollierten Ereignisse zu reproduzieren. Dies wird als Ereignisprotokollierung bezeichnet, wenn Sie nur Ereignisse protokollieren, oder als Event Sourcing, wenn Sie in der Lage sind, den Zustand der Anwendung aus diesen protokollierten Ereignisse zu reproduzieren. Bei diesem Ansatz gilt also: Ereignisse vor Daten . Die Ereignisse sind die Quelle der Wahrheit. Ereignisse müssen bei diesem Ansatz als relevanten Daten enthalten und daher Datenereignisse sein.
Bei den Daten und Ereignissen gibt es einen höchst interessanten Unterschied in Bezug auf das Alter. Daten altern gut, aber Ereignisse nicht. Das bedeutet, dass auch alte Daten immer noch die Quelle der Wahrheit sind, so dass die höchste Priorität darin besteht, keine Daten zu verlieren. So ist beispielsweise die Adresse eines Geschäftspartners , die vor Jahrzehnten in ein ERP-System eingegeben wurde, immer noch gültig , sofern sie nicht aktualisiert wurde. Bei Ereignissen ist das anders. Je jünger ein Ereignis ist, desto wertvoller ist es; je älter es wird, desto weniger Wert hat es. Bei ereignisgesteuerten Architekturen geht es in erster Linie darum, so schnell wie möglich auf Ereignisse zu reagieren. Dies gilt sowohl für Ereignisbroker als auch für eriegnissprotokollbasierte Ansätze.
Vorteile und Herausforderungen der ereignisgesteuerten Architektur
Vorteile:
Lose Kopplung
Extreme Skalierung und hoher Durchsatz
Inkrementelles Wachstum
Fehlertoleranz
Erkenntnisse in (real)Echtzeit
Geringe Latenz
Effiziente Abläufe
Vorhersage
Herausforderungen
Überwachung und Verständnis
Verfolgung und Fehlersuche
Maskierung von Fehlern
Sicherheit der Daten
Zentraler Ereignisbroker
Synchrone Abfrage
Keine Kommentare:
Kommentar veröffentlichen