Dieser Artikel wurde maschinell übersetzt.

Microsoft Azure

Der Aufstieg der auf Ereignisdatenströme ausgerichteten Systeme

Christopher Bennage

Es ist alles über Daten in diesen Tagen. Daten hilft uns, fundierte Entscheidungen zu treffen. Big Data hilft uns fundierte und aufschlussreiche Entscheidungen zu treffen. Große Datenströme helfen uns informierte, aufschlussreiche und zeitnahe Entscheidungen zu treffen. Diese kontinuierlich fließenden Datenströme werden oft Ereignisströme genannt. Es ist zunehmend üblich, Software-Systeme zu bauen, deren Hauptaufgabe darin besteht, Ereignisströme zu verarbeiten.

Sogar in verschiedenen Branchen und Domänen gibt es eine erkennbare Gemeinsame Architekturmuster rund um diese Veranstaltung streamorientierten Systeme. Dieses Muster für modernes Event-Stream-orientierte Systeme spielt die gleiche grundlegende Rolle, die die klassische n-Tier-Architektur für traditionellen lokalen Unternehmenssysteme gehalten. Ich werde durch die Erforschung einer Miniaturansichten Skizze dieses entstehende Muster beginnen.

Das Muster zu identifizieren

Zuerst sollte ich klären, was mit dem Begriff Ereignis gemeint ist. Hier bedeutet es lediglich ein wenig Daten anzeigt, dass etwas passiert in einem System. Ereignisse sind meist klein, im Bereich von Byte oder Kilobyte. Sie hören auch Begriffe wie Nachrichten, Telemetrie oder auch nur Daten anstelle von Ereignis.

Als nächstes gibt es Event-Produzenten. Diese Hersteller könnte fast alles sein — verbunden, Autos, intelligente Thermostate, Spielkonsolen, persönliche Fitness-Geräte oder sogar ein Softwaresystem, das Generieren von selbst-­Diagnoseereignisse. Es ist wichtig zu erkennen, aber dass in den meisten dieser Systeme, Sie mit zahlreichen Event-Produzenten tun haben.

Viele Systeme rechnen mit Zahlen von Event-Produzenten in die Zehntausende und in zig Millionen oder mehr reichen. Dies bedeutet, dass diese Systeme neigen zu hohem Volumen und hoher Geschwindigkeit haben. Hohes Volumen bedeutet, dass es eine große Datenmenge, die insgesamt und hohe Geschwindigkeit bedeutet, dass die Daten häufig generiert werden.

Es gibt auch Ereignisconsumer. Verbraucher sind der eigentliche Kern dieser Arten von Systemen. Sie sind verantwortlich für die Analyse, Interpretation und reagieren auf Ereignisse. Die Zahl der Verbraucher in einem typischen System vielleicht von ein paar bis ein paar Dutzend reichen. Ereignisse sind nicht an bestimmte Verbraucher weitergeleitet. Jeder Verbraucher schaut den gleichen Satz von Ereignissen. Im Rahmen der Microsoft Azure sind die Verbraucher am ehesten Cloud-Services.

Betrachten Sie dieses Beispiel. Es ist ein Ereignisstream, die finanzielle Transaktionen darstellt. Die Event-Produzenten in diesem Szenario sind am Point of Sale Systeme im Handel erhältlich. Ein Verbraucher besitzt die Verantwortung für den Stream für betrügerische Aktivitäten zu analysieren und Warnungen zu erhöhen. Einen anderen Verbraucher analysiert den gleichen Stream um just-in-Time Supply Chain Optimierungen machen. Schließlich ist ein Dritter Consumer verantwortlich für die Ereignisse in kalten Langzeitspeicher für spätere Analysen zu übersetzen.

In Kombination mit den Realitäten der High-Volume und High -­Velocity-Veranstaltungen, dieses Muster der Erzeuger und Verbraucher stellt ein paar interessante Probleme:

• Wie verhindern Sie Ereignis Produktion Überspannung von überwältigenden Verbraucher? Das heißt, wie sollte das System reagieren wenn die Rate von Ereignis-Produktion beginnt, die Rate des Verbrauchs zu überschreiten?
• Da Ereignis Geschwindigkeit hoch ist, wie können Sie eine einzelne Ereignisconsumer skalieren?

Der Schlüssel zur Lösung ist die Verwendung eines Ereignismakler (siehe Abbildung 1). Dies ist genau die Rolle, durchgeführt von der kürzlich veröffentlichten Azure-Ereignis-Hubs.

Abbildung 1 die himmelblau-Ereignis-Hub-Architektur

Wie löst genau, mit einem Broker wie Ereignis-Hubs Probleme, die ich bisher beschrieben habe?

Ereignis-Hubs zu verstehen

Ereignis-Hubs stellt die Elastizität benötigt zum absorbieren und beibehalten von Veranstaltungen bis nachgeschalteten Verbraucher aufholen können. Ereignis-Hubs können effektiv heraus Variabilität im Falle Stream Rate Ebene damit Verbraucher nicht zu kümmern. Ohne diese Nivellierung, könnte einem empfangenden Verbraucher überwältigt zu werden und beginnen zu scheitern.

Mit einem Makler isoliert die Event-Produzenten und Ereignisverbraucher von einander. Diese Isolierung ist besonders wichtig für die anspruchsvollere Versionen des architektonischen Musters, wenn notwendig sind, zusätzliche Vermittler zwischen den Erzeugern und den Verbrauchern. Ereignis-Hubs ist eine Komposition, eine Naht oder Begrenzung in der Architektur. Alle Komponenten, die durch ein Ereignis-Hub interagieren benötigen keine spezifische Kenntnisse der jeweils anderen.

An diesem Punkt wäre es einfach zu verwechseln Ereignis Hubs mit Tradi­Tional Unternehmens-messaging-Dienste, die die gleiche Art von Isolation bieten. Ereignis-Hubs unterscheidet sich jedoch in mehrere wichtige Möglichkeiten, die es ideal für dieses architektonische Muster machen.

Unabhängigen Verbraucher

Ereignis-Hubs verwendet eine veröffentlichen und abonnieren Modell; jedoch hat jeder Verbraucher einen unabhängigen Überblick über den gleichen Ereignisstream. In einigen traditionellen messaging-Systemen mit mehreren Consumern werden Nachrichten für jeden interessierten Consumer kopiert. Dies kann in Bezug auf Geschwindigkeit und Speicherplatz ineffizient, aber der Vorteil ist, dass jeder Verbraucher seinen eigenen "Posteingang". Während Verbraucher Nachrichten verarbeitet, wird sie aus ihren Posteingang entfernt. Weil sie ihre eigenen Kopien im eigenen Posteingang haben, gibt es keine Auswirkungen auf andere Verbraucher.

Mit Event-Hubs ist eine Gruppe der unveränderlichen Ereignisse, und weil sie unveränderlich sind, nur muss es ein Exemplar eines jeden Turniers. Ebenso entfernen Verbraucher nie Ereignisse vom Computer. Alle Verbraucher betrachten den gleichen Satz von Ereignissen. Aus diesem Grund eigenen Verbraucher, die Verantwortung für die Verfolgung der stream im Falle wo sie sind. Sie tun dies durch ihren nicht im Ereignisstream verfolgen. Es gibt tatsächlich eine API für das in das SDK integriert.

Zeit-basierte Aufbewahrung

In herkömmlichen Messagingsystemen obliegt der Verbraucher das System zu sagen, wenn es mit der Nachricht fertig ist. Das System kann die Nachricht dann loswerden. Weil ein Ereignis Hubs-Verbraucher für seine eigene Position innerhalb des Ereignis-Streams nachzuverfolgen verantwortlich ist, weiß wie ein Ereignis-Hub, wenn der Verbraucher mit den Ereignissen fertig ist? Kurz gesagt, tut es nicht. Mit Event-Hubs Sie konfigurieren eine Aufbewahrungszeit und Ereignisse werden gespeichert, damit so viel Zeit. Dies bedeutet, dass Ereignisse auf ihre eigene, unabhängige Handlungen Verbraucher ablaufen.

Die Folgerung des Zeit-basierte Aufbewahrung ist, dass der Verbraucher muss prüfen und Verarbeiten von Ereignissen, bevor sie ablaufen. Jeder Verbraucher hat mit Zeit-basierte Aufbewahrung Druck zu halten. Glücklicherweise kann das zugrundeliegende Design Event Hubs einzelne Verbraucher Skala nach Bedarf.

Ereignis-Hubs unterstützt dies durch Partitionierung ist physisch den Ereignisstream. Sie legen die Anzahl der Partitionen, bei der Bereitstellung von einem Ereignis-Hub. Finden Sie die offizielle Dokumentation unter bit.ly/11QAxOY für weitere Details.

Wie Events an einen Event-Hub veröffentlicht werden, sind sie in Partitionen abgelegt. Ein bestimmtes Ereignis befindet sich in nur einer Partition. Ereignisse werden standardmäßig auf Partitionen im Round-Robin-gleichmäßig verteilt. Es gibt Mechanismen für die Bereitstellung von Partition Affinität. Am häufigsten können Sie eine Partition Key-Eigenschaft für ein Ereignis festlegen, und alle Ereignisse mit demselben Schlüssel werden auf die gleiche Partition zugestellt.

Wie hilft ein partitionierte Ereignisstream Verbraucher mit Zeit-basierte Aufbewahrung? Im Rahmen der Veranstaltung Hubs ist die korrekte Bezeichnung eigentlich Verbrauchergruppe. Der Grund für bezeichnete es eine Gruppe ist, dass jeder Verbraucher wirklich von mehreren Instanzen besteht. Jede Gruppe hat eine Instanz pro Partition. Ab diesem Zeitpunkt Verbrauchergruppe bezieht sich auf den Konsumenten als Ganzes und Verbraucher Instanz bezieht sich auf das Mitglied der Gruppe Interesse an einer bestimmten Partition.

Dies bedeutet, dass eine Verbrauchergruppe Stream Veranstaltungen parallel verarbeitet werden kann. Jeder Verbraucher-Instanz in der Gruppe kann eine Partition, die unabhängig von anderen Instanzen verarbeiten. Diese Verbraucher-Instanzen können alle in einer Maschine, mit jeder Verbraucher-Instanz läuft isoliert voneinander befinden. Sie konnten alle auf mehreren Rechnern bis hin zu jeder Verbraucher-Instanz läuft auf einem dedizierten Computer verteilt werden. Auf diese Weise umgeht Ereignis Hubs einige typische Probleme im Zusammenhang mit dem klassischen Muster der konkurrierenden Verbraucher.

Isolation ist ein wichtiges Konzept hier. Erstens Sie sind isolieren, Event-Produzenten und Ereignisverbraucher von einander, wodurch flexible Architektur Zusammensetzung, sowie Abgleich zu laden. Zweitens sind Verbrauchergruppen isoliert voneinander, reduzieren die Möglichkeit für kaskadierenden Fehler über Verbrauchergruppen. Drittens sind Verbraucher-Instanzen in einer bestimmten Verbrauchergruppe aktivieren, horizontale Skalierung für einzelne Verbrauchergruppen voneinander isoliert.

Verwenden Sie Ereignis-Hubs

Es gibt mehrere gute Tutorials für den Einstieg mit Ereignis-Hubs. Schauen Sie sich die offizielle Dokumentation bei bit.ly/11QAxOY und folgen Sie die Anleitung, die die Plattform Ihrer Wahl verwendet.

Sie müssen zuerst einen Ereignis-Hub bereitstellen. Der Prozess ist einfach. Sie können es leicht mit einer Azure-Testzugang ausprobieren. Die Azure Management Portal navigieren Sie zum Abschnitt Service Bus. Sie müssen einen Service Bus-Namespace zu erstellen, wenn Sie nicht bereits ein haben. Danach sehen Sie eine Registerkarte mit der Bezeichnung Ereignis-Hubs, die Anweisungen zum Erstellen einer Ereignis-Hub hat (siehe Abbildung 2).

Abbildung 2 Erstellen Sie einen Ereignis-Hub

Außerdem müssen Sie eine gemeinsame Richtlinie für Ereignis-Hub eingerichtet, bevor Sie anfangen können. Diese Richtlinien verwalten der Sicherheit für einen Event-Hub. Navigieren Sie im Portal zu der soeben erstellten Ereignis-Hub, und wählen Sie die Registerkarte "Konfigurieren".

Wählen Sie verwalten für die Berechtigungen und geben der Politik einen Namen wie "super" oder "-Not-Einsatz-in-Produktion." Danach wechseln Sie zurück zur Registerkarte "Dashboard" und klicken Sie am unteren Verbindungsinformationen. Sie wollen, notieren Sie sich die Verbindungszeichenfolge gibt, als auch den Namen gab Sie Ihr Event-Hub.

Ereignisse produzieren

Der Code, den ich hier zeigen werde verwendet das .NET SDK, aber können Sie jede Plattform, die HTTP oder AMQP unterstützt. Sie müssen das Microsoft Azure Service Bus NuGet-Paket verweisen. Die Klassen, die Sie benötigen sind im Microsoft.ServiceBus.Messaging-Namespace. Alles, was Sie tun müssen, ist einen Client zu erstellen, erstellen Sie ein Ereignis und senden:

var client = EventHubClient.CreateFromConnectionString (
  connectionString,
  eventHubName);
var body = Encoding.UTF8.GetBytes("My first event");
var eventData = new EventData (body);
await client.SendAsync (eventData);

Trotz der Einfachheit, es gibt ein paar interessante Elemente darauf hinweisen. Der Körper des Ereignisses ist nur ein Byte-Array. Alle Verbrauchergruppen, die Verarbeitung dieses Ereignisses müssen wissen, wie man diese Bytes zu interpretieren. Es ist wahrscheinlich die Verbrauchergruppen benötigen eine Art von Hinweis zu bestimmen, wie den Körper zu deserialisieren. Bevor das Ereignis gesendet wird, kann mit Metadaten beizufügen:

eventData.Properties.Add ("event-type", "utf8string");

Dies bedeutet, mit Schlüsseln und Werten, die von Produzenten und Verbrauchergruppen bekannt sind. Wenn Sie sicherstellen möchten, dass eine Reihe von Ereignissen auf die gleiche Partition geliefert wird, können Sie eine Partition-Taste festlegen:

eventData.PartitionKey = "something-meaningful-to-your-domain";

Sie erhalten bessere Leistung, wenn Ereignisse Affinität mit Partitionen nicht. In einigen Fällen sollten Sie jedoch eine Reihe von Veranstaltungen, die an eine einzelne Verbraucher-Instanz zur Verarbeitung weitergeleitet. Veranstaltungen in eine bestimmte Partition sind garantiert in der Reihenfolge, die sie empfangen wurden. Ebenso gibt es keine einfache Möglichkeit, die Reihenfolge der Ereignisse auf verschiedenen Partitionen in einem Ereignis-Hub zu garantieren. Dies ist oft die Motivation für den Wunsch Veranstaltungen Affinität zu einer bestimmten Partition haben.

Beispielsweise wenn Sie smart-Autos aktivieren, soll alle Ereignisse für ein bestimmtes Auto in der gleichen Partition sein. Sie können das Fahrzeug Identifikation Nummer (VIN) für den Partitionsschlüssel. Oder Ihr System möglicherweise intelligente Gebäude mit Hunderten von Geräten in jedem Gebäude produzieren Ereignisse behandeln. In diesem Fall können Sie die Identität des Gebäudes selbst, da die Partition key also alle Ereignisse von allen Geräten im gleichen Gebäude Land in der gleichen Partition.

Insgesamt Partition Affinität ganz ungefährlich ist und Sie sollten es nur vorsichtig verwenden. Eine schlechte Wahl der Partitionsschlüssel kann eine ungleichmäßige Event-Verteilung auf Partitionen führen. Dies könnte letztlich bedeuten, dass Verbrauchergruppen Skalierung Probleme hätte. Die gute Nachricht ist, dass Sie viele Male das Systemdesign für Partition Affinität zu vermeiden ändern können.

Verarbeiten von Ereignissen

Möglicherweise sorgen, wie Sie all dies geschafft werden. Ihr Verbraucher-Gruppen benötigt werden, um zu verfolgen ihren nicht an der Veranstaltung streamen. Jede Gruppe muss eine Instanz für jede Partition haben. Glücklicherweise gibt es eine API dafür.

Verweisen das NuGet Paket Microsoft Azure Service Bus Hub-Ereignis-­ProcessorHost. Die Klassen, die Sie benötigen sind im Microsoft.ServiceBus.Messaging-Namespace. Der Einstieg ist so einfach wie eine einzige Schnittstelle implementieren: IEventProcessor.

Sobald Sie Ihr Ereignisprozessor implementiert haben, erstellen Sie eine Instanz von EventProcessorHost um Ihre Ereignisprozessor zu registrieren. Der Host verarbeitet der Routinearbeit für Sie. Wenn es wird gestartet, wird sie prüfen Ihre Event-Hub um zu sehen, wie viele Partitionen hat. Es wird dann eine Instanz der Ereignisprozessor für jedes verfügbare Partition erstellt.

Es gibt drei Methoden, die Sie implementieren müssen. Die ersten beiden sind OpenAsync und CloseAsync. Der Host ruft gewährt OpenAsync wenn der Prozessor Ereignisinstanzen erstmalig eine Partition-Lease. Dies bedeutet, dass der Prozessor Ereignisinstanzen hat exklusiven Zugriff auf die Partition für die Verbrauchergruppe in Frage. Ebenso ruft der Host CloseAsync, wenn die Lease verloren geht oder wenn es heruntergefahren wird. Während Sie begonnen erhalten sind, können Sie eine sehr einfache Implementierung:

public Task OpenAsync(PartitionContext context)
{
  return Task.FromResult(true);
}
public Task CloseAsync(PartitionContext context, CloseReason reason)
{
  return Task.FromResult(true);
}

Beide Methoden erhalten ein PartitionContext Argument. Die verbleibende Methode erhält, sowie. Sie können dieses Argument überprüfen, wenn Sie Informationen über die jeweilige Partition verpachtet an den Ereignisprozessor anzeigen möchten. Die letzte Methode ist, dass tatsächlich die Ereignisse wird (siehe Abbildung 3).

Abbildung 3 die letzte Methode, der die Ereignisse liefert

public async Task ProcessEventsAsync (PartitionContext context, 
  IEnumerable<EventData> messages)
{
  foreach (var message in messages)
  {
    var eventType = message.Properties["event-type"];
    var bytes = message.GetBytes();
    if (eventType.ToString() == "utf8string") {
      var body = System.Text.Encoding.UTF8.GetString (bytes);
      // Do something interesting with the body
    } else {
      // Record that you don't know what to do with this event
    }
  }
  await context.CheckpointAsync();
  // This is not production-ready code
}

Wie Sie sehen können, ist dies einfach. Sie erhalten eine aufzählbare Menge von Ereignissen, die Sie durchlaufen können und tun, was auch immer Arbeit nötig ist. Sie haben auch dieser Aufruf des Kontexts.CheckpointAsync am Ende der Methode. Dem Host wird veranlaßt, Sie haben erfolgreich verarbeitet, dieser Satz von Ereignissen und Sie möchte einen Checkpoint. Der Prüfpunkt ist der Offset des letzten Ereignisses im Batch.

Das ist, wie Ihre Verbrauchergruppe verfolgen der kann welche Ereignisse für jede Partition verarbeitet wurden. Nach ein Host gestartet wird, versucht es, eine Lease für jede verfügbare Partition zu erwerben. Wenn es mit der Verarbeitung für eine Partition beginnt, wird es die Checkpoint-Informationen für diese Partition prüfen. Aktueller als der letzte geprüfte Offset nur Ereignisse sind an ihren jeweiligen Prozessoren gesendet.

Der Host stellt auch Automatischer Abgleich computerübergreifend. Nehmen wir zum Beispiel haben Sie einen Event-Hub mit 16 Partitionen. Das bedeutet, es werden 16 Instanzen der Ereignisprozessor – eine für jede Partition. Wenn Sie den Host auf einem einzigen Computer ausführen, werden alle 16 Instanzen auf demselben Computer erstellt. Wenn Sie einen anderen Host auf einem zweiten Computer und es ist Teil der gleichen Verbrauchergruppe starten, werden den beiden Hosts beginnen, um die Verteilung von Ereignisinstanzen Prozessor zwei computerübergreifend zu ebnen. Letztlich gibt es acht Prozessor-Ereignisinstanzen pro Maschine. Ebenso nimmst du Sie den zweiten Computer, übernimmt dann der erste Wirt zurück die verwaisten Partitionen.

Angenommen Sie, die Implementierung der IEventProcessor MyEventProcessor. Instanziieren den Host kann so einfach sein:

var host = new EventProcessorHost(
  hostName,
  eventHubName,
  consumerGroupName,
  eventHubConnectionString,
  checkpointConnectionString);
await host.RegisterEventProcessorAsync<MyEventProcessor>();

Die EventHubConnectionString und EventHubName sind die gleichen Werte, die beim Senden von Veranstaltungen im vorherigen Beispiel verwendet. Es ist am besten, Verbindungszeichenfolgen mit freigegebenen Richtlinien verwenden, die Nutzung zu beschränken, auf nur was notwendig ist.

Der HostName bezeichnet die Instanz von der EventProcessorHost. Wenn der Host in einem Cluster (d. h. mehrere Computer) ausgeführt wird, empfiehlt es sich, dass Sie einen Namen angeben, der die Identität des Computers entspricht, auf dem es ausgeführt wird.

Das ConsumerGroupName-Argument bezeichnet die logische Verbrauchergruppe, die diesen Host darstellt. Gibt es eine Standard-Verbraucher-Gruppe Sie verweisen können, verwenden die Konstante EventHubConsumer­Group.DefaultGroupName. Ein anderer Name müssen Sie erste Bestimmung der Consumer Group. Dazu erstellen eine Instanz von Microsoft.ServiceBus.NamespaceManager und Methoden z. B. CreateConsumerGroupAsync.

Schließlich müssen Sie eine Verbindungszeichenfolge für eine Azure Storage-Konto, das mit CheckpointConnectionString zu bieten. Dieser Speicher ist in dem Ereignis offsets und der Host überwacht alle Zustand über Partitionen. Dieser Zustand wird in Blobs im Klartext gespeichert, die Sie leicht prüfen können.

Es gibt andere Azure Services, die mit Ereignis Hubs Out-of-the-Box integriert sind. Azure Stream Analytics (derzeit in der Vorschau) stellt eine deklarative SQL-ähnliche Syntax zum Transformieren und Analyse Ereignisströme mit Ursprung in Ereignis-Hubs. Ebenso bietet Event-Hubs ein Wasserhahn für den sehr populären Apache Sturm, jetzt erhältlich als Vorschau auf Azure durch HDInsight.

Zusammenfassung

Die hier beschriebenen Architekturmuster ist nur der Anfang. Wenn Sie ein Real-World-System zu implementieren, gibt es zahlreiche andere Bedenken, die Sie benötigen, zu berücksichtigen. Diese Bedenken beinhalten erweiterte Sicherheit, Bereitstellung und Verwaltung von Event-Produzenten, Protokoll Übersetzung und ausgehende Kommunikation. Dennoch sind Sie nun mit den grundlegenden Konzepten notwendig, Aufbau eines Systems mit einer Ereignis-Broker wie Ereignis-Hubs ausgestattet.

---

Christopher Bennage ist ein Mitglied der Microsoft Patterns &Praktiken Team.  Er liebt es, Dinge mit Computern machen.

Dank den folgenden technischen Experten von Microsoft für die Überprüfung dieses Artikels: Mostafa Elhemali und Dan Rosanova