© deomis/Shutterstock.com
Unter dem Druck der Ereignisse – Teil 5

Events in Azure II


Seit dem Erscheinen von Ted Faisons Lehrbuch zu Event-basierten Softwaresystemen gilt, dass Event-orientierte Programmierung und Architektur in der Welt der Microsoftschen Softwareentwicklung einen starken Stand haben.

Im vorherigen Teil dieser Serie, in Ausgabe 1.2021 des Windows Developer, haben wir damit begonnen, unsere bisher lokal durchgeführte Event-Verteilung in Richtung von Microsofts Cloud-Dienst Azure abzuschieben. Dazu standen insgesamt drei verschiedene Systeme zur Verfügung, die Tabelle 1 noch einmal kurz auflistet.

Dienst

Idealer Datentyp

Sondereignung laut Microsoft

Event Grid

Verteilung diskreter Events

exzellente Integration in andere Azure-Dienste

gut skalierbar

geringe Kosten

Event Hubs

Streaming serieller Events

sehr geringe Latenz

extrem hoher Durchsatz (im Bereich von Millionen Messages pro Sekunde)

Service Bus

Messages

fortgeschrittene Message-Zustellungsoptionen

garantierte Auslieferung von Nachrichten in Sequenz

sichere Auslieferung von Messages, auch dann, wenn asynchroner Betrieb erforderlich ist

Tabelle 1: Event-Dienste in Azure

Der letzte Artikel beschränkte sich dabei allerdings auf die Besprechung des Event Grids. Event Hub und Service Bus wurden bisher noch nicht besprochen, was wir an dieser Stelle nachholen wollen.

Events sind für alle da

Im letzten Teil hatten wir das Event Grid eingespannt, um Azure-Ereignisse innerhalb der verschiedenen Cloud-Features zu verteilen. Der Dienst ist eine preiswerte und gut skalierbare Lösung, die Ereignisse zwischen den einzelnen Modulen hin- und herliefert. Microsoft dürfte darüber froh sein, denn je mehr von einer Applikation in der Azure-Cloud lebt, desto höher sind die Mietkosten. Als Entwickler müssen Sie sich darüber allerdings nicht freuen, denn je mehr Events man lokal verarbeitet, desto geringer sind die Mietgebühren. Das ist im Grunde genommen der hinter dem Event Hub Service stehende Gedanke. Ein Event Hub ist eine Daten-Pipeline, die von einer Datenquelle emittierte Informationen – ein Klassiker wären Telemetriedaten – einsammelt und in Richtung von Datensenken weiterleitet.

Für die Erzeugung unseres Event Hubs wechseln wir in das Azure-Portal, wo wir im immer umfangreicher werdenden Ressourcengenerator im ersten Schritt nach dem String Event Hubs suchen und danach durch Anklicken des Create-Buttons den Erzeugungsprozess lostreten. Bei der Vergabe des Aufenthaltsorts und der Ressourcengruppe haben wir die freie Wahl. Die Vergabe des Namespace-Namens legt der URL fest, unter dem unser Dienst später ansprechbar sein wird. Der Autor entschied sich in den folgenden Schritten für den Wert sustest1234, was zum URL sustest1234.servicebus.windows.net führte. Bei den Pricing Tiers wollen wir uns für die Option Basic entscheiden. Ein solcher Hub kostet im Betrieb weniger, kann allerdings auch nur wenige Konsumenten betreuen und ist zudem im Bereich des Vorhaltens nicht abgerufener Messages weniger flexibel. Die eigentliche Übertragungsleistung wird von Microsoft dann in Throughput Units festgelegt. Eine Unit steht dabei für das Einlesen von entweder 1 MB an Daten oder 1000 Messages. Was zuerst erreicht wird, sorgt dafür, dass eine ServerBusy-Fehlermeldung auf dem Fuß folgt. Im Bereich der Datenauslieferung aus dem Event Hub zeigt sich Microsoft flexibler. Hier dürfen entweder bis zu 2 MB oder aber bis zu 4096 Ereignisse gleichzeitig ausgelassen werden. Da wir hier nur ein kleines Beispiel realisieren, soll uns eine Throughput Unit ausreichen. Mehr Informationen über die Skalierungsmöglichkeiten von Azure-Event-Systemen finden sich in der Dokumentation [1].

Im nächsten Schritt klicken wir auf den Next:Features-Knopf, um uns fortgeschrittene Optionen anzeigen zu lassen. Hier gibt es die Möglichkeit, den Hub zwecks besserer Redundanz zu verteilen. Das interessiert uns allerdings nicht; auch die Tags sind nicht relevant. Nach dem Abarbeiten der fortgeschrittenen Einstellungen überprüft das Backend noch die vorgenommenen Parameter; nach der erfolgreichen Validation befehlen wir durch Anklicken von Create ein erstmaliges Generieren der Arbeitsumgebung. Wundern Sie sich nicht, wenn der Prozess etwas Zeit in Anspruch nimmt. Nach getaner Arbeit fehlt ein Klick auf Go To Ressource. Innerhalb des soeben angelegten Namespace legen wir eine Unterkategorie an. Hierzu wechseln wir in den Eigenschaften des Event Hub Name-space in die Unterkategorie Entities | Event Hubs und klicken zum Anlegen eines neuen Objekts auf das +-Symbol. Auch hier ist ein Name erforderlich – der Autor entschied sich für susmeinhub. Die Partition-Einstellung ist ein weiteres Skalierungswerkzeug; der Autor entschied sich hier im Interesse der Bequemlichkeit für vier Partitions. Weitere Informationen hierzu finden sich im weiter oben erwähnten Skalierungsdokument. Auch hier fehlt dann noch ein Klick auf den Create-Knopf, um die eigentliche Erzeugung des Event Hubs abzuschließen.

Programmatische Einbindung

War unser im letzten Artikel verwendeter Event Grid für die Synchronisation von in der Cloud lebenden Ressourcen vorgesehen, so ist der Hub für Applikationscode ansprechbar. Das zeigt sich daran, dass Microsoft die folgenden fünf Programmiersysteme als First-Class-Citizens ansieht und mit einem SDK ausstattet:

Zusätzlich dürfen C-Programmi...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang