Azure Event Grid
Besonders im Kontext von Microservices aber auch in anderen Architekturen spielt die lose Kopplung der Services eine wichtige Rolle. Die Microsoft Azure Plattform bietet hierfür mit dem Azure Event Grid einen Build-In Service, um ereignisgesteuerte Architekturen zu erstellen.
Azure Event Grid ist ein Dienst, der es erlaubt, Ereignisse (Events) zwischen Services zu verschicken. Dabei kann das Event, das von einer Instanz geschickt wird, von mehreren Instanzen, die an dem Event interessiert sind, empfangen und bearbeitet werden. Das Routing der Ereignisse findet durch ein „Publish-Subscriber-Modell“ statt. Dabei registrieren sich Event-Handler für bestimmte Eventtypen („Topics“) bei den Instanzen, die Ereignisse veröffentlichen.
Folgende Grafik verdeutlicht dieses Modell:
Events
Events sind Nachrichten, die geschickt werden, um über das Eintreffen eines Ereignisses in der Event-Quelle informieren. Dabei können mehrere Events in einem Aufruf in Form eines JSON-Arrays geschickt werden. Die Größe dieses Arrays darf 1 MB nicht überschreiten.
Jedes Event besteht aus einem JSON-Objekt, das 5 String-Properties, die für alle Event-Typen gleich sind (topic, subject, id, eventTime und eventType) sowie ein Daten-Property, dessen Struktur von der jeweiligen Event-Quelle abhängt, enthält. Hinzukommen können noch zwei Properties für die Version der Daten und der Metadaten (dataVersion und metadataVersion).
Damit hat ein Event folgendes Aussehen:
[ { "topic": string, "subject": string, "id": string, "eventType": string, "eventTime": string, "data":{ object-unique-to-each-publisher }, "dataVersion": string, "metadataVersion": string }]Die Größe pro Events darf 64 kB nicht überschreiten. Werden die genannten Größen überschritten, reagiert Azure Event Grid mit der Antwort „413 Payload too large“.
Event-Quellen
Als Event-Quellen werden derzeit folgende Dienste unterstützt:
- Event Hubs
- IoT Hubs
- Resource Groups
- Verwaltungsvorgänge in Azure Subscriptions
- General-purpose storages
- Service Bus
- Storage Blobs
- Custom Topics
Bei den oben genannten Diensten handelt es sich um bekannte Azure-Standard-Ressourcen, die Events bei „Änderung ihres Zustandes“ versenden (z.B. neues Objekt in einem Storage oder Größenänderung einer VM).
Bei dem letztgenannten Punkt „Custom Topics“ muss eine Ressource vom Typ „Event Grid Topic“ erzeugt werden. Diese bietet die Möglichkeit, ein Event durch das Aufrufen eines bereitgestellten REST-Endpunktes (HTTP POST) auszulösen.
Event-Handler
Event Handler sind die Konsumenten der von den Event-Quellen gesendeten Events. Das geschieht, indem der Event-Handler über eine Event-Subscription bei einer Event-Quelle registriert wird. Dabei kann das Abonnement auf bestimmte Event-Typen eingeschränkt werden.
Event Subscription
Das Abonnieren eines Events erfolgt durch das Erzeugen einer Resource vom Typ „Event Grid Subscription“. Diese wird beim Anlegen durch die ResourceId bzw. durch Resource Group und den Topic-Namen (im Fall „Custom Topic“) mit der Event-Quelle verknüpft.
Bei der Zuordnung mit dem Event-Handler kann man zwischen der direkten Zuordnung zu einem EventHub und der Zuordnung zu einem WebHook mit einer Endpunkt-URL wählen.
Folgende Beispiele zeigen das Anlegen einer Subscription in Azure CLI für einen Blob Storage durch die ResourceId:
az eventgrid event-subscription create \ --resource-id $storageid \ --name <event_subscription_name> \ --endpoint <endpoint_URL>az eventgrid event-subscription create \-g gridResourceGroup \--topic-name <topic_name> \--name <event_subscription_name> \--endpoint <endpoint_URL>
Bei jeder Event Subscription lassen sich durch den Einsatz eines Filters die Events einschränken, auf die die Subscription reagieren soll. Der Filter kann den Event-Typ und das Event-Subject (SubjectBeginsWith, SubhectEndsWith und SubjectIsCaseSensitive) beinhalten. Per Default wird die Subscription bei allen Events ausgelöst.
Übermittlung von Nachrichten
Jedes für ein Topic auftretende Event wird unmittelbar an die durch eine Subscription angemeldeten Event-Handler weitergeleitet. Dabei wird die Übermittlung als erfolgreich angesehen, wenn der Event-Handler innerhalb von 60 Sekunden mit dem Return Code 200 (OK) oder 202 (Accepted) antwortet. Dadurch werden Return Codes der Nummernkreise 4xx oder 5xx oder fehlende Antworten als fehlerhafte Übermittlung interpretiert.
Für den Fall einer fehlerhaften Übermittlung sieht Event Grid eine erneute Übermittlung der Events vor. Dabei werden die Zeitabstände für die erneute Übermittlung immer größer. Folgende Abstände sind für die Übermittlungsversuche vorgesehen:
- 10 Sekunden
- 30 Sekunden
- 1 Minute
- 5 Minuten
- 10 Minuten
- 30 Minuten
- 1 Stunde
Die Übermittlung wird anschließend jede Stunde wiederholt. Nach 24 Stunden werden alle Events, die nicht zugestellt werden konnten, als abgelaufen markiert und damit gelöscht.
Durch diesen Mechanismus gewährt Azure Event Grid ein gewisses Maß an Sicherheit für die erfolgreiche Datenübermittlung. Es wird sichergestellt, dass auch Event-Handler, die nur kurzzeitig nicht aktiv sind (z.B. durch einen planmäßigen oder unvorhergesehenen Neustart), in der Zeit ihrer Abwesenheit aufgetretene Ereignisse informiert werden und entsprechend reagieren können.
Mit Azure Event Grid lassen sich Events zwischen mehreren Instanzen und Komponenten der Azure Umgebung, welche an einem bestimmten Event interessiert sind, versenden und empfangen.
Vorteile
Event-Verursacher und -Konsumenten müssen sich nicht kennen und sind nur lose miteinander gekoppelt. Event Grid bietet damit in einem System von mehreren oder sogar vielen Komponenten die Möglichkeit, Datenströme zu steuern und zu überwachen, ohne dass die Komponenten voneinander abhängig sind.
Außerdem kann eine Beschleunigung der automatisierten Bearbeitung von Daten in einem System erreicht werden, indem unmittelbar nach dem Eintreffen neuer Daten, z.B. in einem Event-Hub, die nachgelagerten Komponenten über die neuen Daten mit einem Event informiert werden und auf diese Nachricht mit der sofortigen Bearbeitung reagieren.
Durch das Zwischenspeichern der Events und durch die mehrfachen Versuche, die Events im Fehlerfall erneut zuzustellen, bietet Event Grid auch in serverlosen Architekturen eine gewisse Sicherheit für die Gewährleistung der Datenströme.
Nachteile
Manchmal ist es nicht unbedingt von Vorteil, dass es keinen expliziten Datenaustausch zwischen Sender und Empfänger geben kann. Beispielsweise wird in einem System, in das von außen kontinuierlich größere Datenmengen eingespielt werden, neben dem Mechanismus über die Benachrichtigung noch ein zweiter Mechanismus zum temporären Abspeichern und dem Verarbeiten der Daten nötig.
Natürlich ist der Datenfluss am besten gewährleistet, wenn immer alle Empfänger einer Nachricht auch ansprechbar sind. Ansonsten kann es aufgrund des beschriebenen Mechanismus zum erneuten Senden der Daten zu Problemen mit der Performance bzw. dem Datenfluss kommen. Das Vorgehen ist wie oben beschrieben in Azure Event Grid vorgegeben und kann nicht beeinflusst werden.
Derzeit gibt es keinen zentralen Punkt, an dem man die ausgelösten Events loggen kann. Logs können entweder auf Seiten der Event Handler bzw. im Custom Event Grid Topic oder bei den Empfängern von Events konfiguriert werden. Dies bedeutet, man hat auch keine Möglichkeit, den Mechanismus zum mehrfachen Versenden von Events im Fehlerfall zu überwachen. Will man eine Möglichkeit haben, alle Events in einem System zu protokollieren, muss man sich einen eigenen Mechanismus schaffen.
Quellen:
