Azure Event Grid on Kubernetes – Konzepte

  • Artikel

Dieser Artikel beschreibt die wichtigsten Konzepte in Event Grid auf Kubernetes mit Azure Arc (Vorschau).

Wichtig

Event Grid in Kubernetes mit Azure Arc befindet sich derzeit in der öffentlichen Vorschau. Diese Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und ist nicht für Produktionsworkloads vorgesehen. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Ereignisse

Bei einem Ereignis handelt es sich um einen Datensatz, der eine Tatsache bezüglich des Betriebs eines Softwaresystems ankündigt. In der Regel kündigt ein Ereignis eine Zustandsänderung aufgrund eines vom System ausgelösten Signals oder eines vom System beobachteten Signals an. Ereignisse enthalten zwei Arten von Informationen:

  • Ereignisdaten, die das Auftreten einer Zustandsänderung darstellen.

  • Kontextattribute, die kontextbezogene Informationen zum Auftreten des Ereignisses bereitstellen.

    Sowohl Ereignisdaten als auch Kontextattribute können zum Filtern von Ereignissen verwendet werden.

Event Grid in Kubernetes unterstützt die CloudEvents-Schemaspezifikation. Hier sehen Sie ein Beispiel für ein Ereignis, welches das CloudEvents-Schema verwendet. Event Grid unterstützt ein Ereignis mit einer Größe von bis zu 1 MB.

[{
       "specVersion": "1.0",
       "type" : "orderCreated",
       "source": "myCompanyName/us/webCommerceChannel/myOnlineCommerceSiteBrandName",
       "id" : "eventId-n",
       "time" : "2020-12-25T20:54:07+00:00",
       "subject" : "account/acct-123224/order/o-123456",
       "dataSchema" : "1.0",
       "data" : {
          "orderId" : "123",
          "orderType" : "PO",
          "reference" : "https://www.myCompanyName.com/orders/123"
      }
}]

`Source`

Das Quellattribut beschreibt den Kontext, in dem das Ereignis aufgetreten ist. Die Quelle ist möglicherweise der Verursacher von Ereignissen. In einigen Fällen gibt es jedoch Produzenten, die Ereignisse erstellen und veröffentlichen. Und diese Produzenten unterscheiden sich von der Quelle. Der Einfachheit halber wird in diesem Artikel angenommen, dass die Quelle der Produzent der Ereignisses ist.

Jede Event-Quelle erzeugt Ereignisse eines oder mehrerer Ereignistypen. Als Quelle von Ereignissen definiert eine Anwendung einen Satz von zusammenhängenden Ereignissen, um ihre Zustandsänderungen anzukündigen. Jedes Ereignis enthält allgemeine Informationen wie Quelle des Ereignisses, Zeitpunkt, an dem das Ereignis aufgetreten ist, und den eindeutigen Bezeichner. Jedes Ereignis hat auch spezifische Informationen, die nur für die jeweilige Art von Ereignis relevant sind. Die Unterstützung für ein Ereignis von einer Größe bis zu 1 MB ist derzeit in der Vorschauversion verfügbar.

Für die Eigenschaften, die in einem Ereignis enthalten sind, siehe CloudEvents-Schema.

Herausgeber

Bei Ereignisherausgebern handelt es sich um Anwendungen oder Systeme, die Ereignisse an Event Grid senden, um sie an Ereignisabonnenten zu liefern.

Themen

Ein Thema ist eine Art Eingabekanal, der einen Endpunkt verfügbar macht, an den Herausgeber Ereignisse an Event Grid senden.

Ein Thema kann für eine Sammlung von zusammenhängenden Ereignissen verwendet werden. Sie könnten für jede Kategorie von verwandten Ereignissen ein Thema erstellen. In einigen Fällen kann die Quelle verwendet werden, um Ereignisse in Kategorien zu organisieren, da Quellen in der Regel mit einer Reihe von eng verwandten Ereignistypen („MyApp.OrderCreated“, „MyApp.OderDeleted“, „MyApp.OrderRejected“, usw.) verbunden sind.

Betrachten Sie eine Anwendung, die Ereignisse im Zusammenhang mit der Verwaltung von Benutzerkonten und der Verarbeitung von Bestellungen sendet. Es ist unwahrscheinlich, dass ein Ereignisabonnent daran interessiert ist, beide Ereigniskategorien zu konsumieren. Erstellen Sie zwei benutzerdefinierte Themen, und lassen Sie Ereignishandler das jeweils relevante Thema abonnieren. Für kleine Lösungen empfiehlt es sich ggf., alle Ereignisse an ein Thema zu senden.

Ereignisabonnenten

Bei Ereignisabonnenten handelt es sich um Softwaresysteme wie z. B. Microservices, die Endpunkte exponieren, an die Event Grid Events Ereignisse liefert.

Ereignisabonnements

Ein Ereignisabonnement teilt Event Grid mit, welche Ereignisse Sie zu einem Thema empfangen möchten (Ereignisfilterung), und wohin diese gesendet werden sollen (Ereignisrouting). Beim Erstellen eines Ereignisabonnements geben Sie einen Endpunkt für die Behandlung des Ereignisses an. Sie können die Ereignisse auswählen, die an Ihren Endpunkt geliefert werden sollen, indem Sie Filterklauseln für das Ereignisabonnement konfigurieren.

Ereignishandler

Beim Ereignishandler handelt es sich um ein Softwaresystem, das einen Endpunkt bereitstellt, an den Ereignisse gesendet werden. Der Handler empfängt das Ereignis und führt Aktionen zur Verarbeitung des Ereignisses aus. Event Grid unterstützt verschiedene Handlertypen. Als Handler können Sie einen unterstützten Azure-Dienst verwenden, der auf Kubernetes oder Azure gehostet wird, oder Ihre eigene Lösung, die einen Webhook (Endpunkt) bereitstellt, wo immer dieser gehostet wird. Je nach Handlertyp übermittelt Event Grid die Ereignisse auf unterschiedliche Art und Weise. Wenn es sich beim Ziel-Ereignishandler um ein HTTP-Webhook handelt, wird das Ereignis wiederholt, bis der Handler den Statuscode 200 - OK zurückgibt. Weitere Informationen finden Sie unter Eeignishandler.

SAS-Authentifizierung

Event Grid in Kubernetes bietet die SAS-Schlüsselbasierte Authentifizierung zum Veröffentlichen von Ereignissen in Themen.

Ereignisbereitstellung

Event Grid in Kubernetes bietet einen zuverlässigen Liefer- und Erneut-Versuchen-Mechanismus. Wenn Event Grid nicht bestätigen kann, dass ein Ereignis vom Endpunkt des Ereignishandlers empfangen wurde, wird das Ereignis erneut geliefert. Weitere Informationen finden Sie unter Event Grid – Nachrichtenübermittlung und -wiederholung.

Batch-Ereignisveröffentlichung

Wenn Sie ein Thema verwenden, müssen die Ereignisse immer in einem Array veröffentlicht werden. Bei Szenarios mit geringem Durchsatz hat das Array nur einen Ereignis. Für Anwendungsfälle mit hohem Volumen wird aber empfohlen, pro Veröffentlichung mehrere Ereignisse zu Batches zusammenzufassen, um eine höhere Effizienz zu erzielen. Batches können eine Größe von bis zu 1 MB haben. Für die einzelnen Ereignisse sollte trotzdem eine Größe von 1 KB nicht überschritten werden. Weitere Informationen finden Sie unter Batch-Ereignislieferung.

Azure Event Grid on Kubernetes Komponenten

  • Der Event Grid-Operator implementiert das Operator-Muster. Er überwacht die Zustandsänderungen von Event-Grid-Ressourcen als Ergebnis von Steuerungsebenen-Anforderungen, die an den API-Server von Kubernetes gestellt werden. Wenn eine Anforderung vorhanden ist, die den Zustand einer der Event Grid-Ressourcen beeinflusst, synchronisiert der Event Grid-Operator diesen Zustand mit dem Event Grid-Broker.

  • Der Event Grid Broker dient sowohl als Steuerungsebenen- als auch als Datenebenen-Vorgänge.

    Als ein Dienst auf der Steuerungsebene ist er dafür verantwortlich, den Zustand von Event Grid in den vom Event Grid-Operator mitgeteilten gewünschten Zustand zu bringen. Wenn z. B. eine Anforderung zum Erstellen eines neuen Themas gestellt wird, wird diese Anforderung erfüllt und die Metadaten des Dienstes werden aktualisiert.

    Als Datenebenen-Dienst verarbeitet er alle Event-Veröffentlichungsanforderungen und übermittelt Ereignisse an die Ziele, die in Ereignisabonnements konfiguriert sind.

Nächste Schritte

Informationen zu den ersten Schritten finden Sie unter Erstellen von Themen und Abonnements.