Orleans Streamanbieter

Ströme können in unterschiedlichen Gestalten und Formen auftreten. Einige Datenströme liefern möglicherweise Ereignisse über direkte TCP-Links, während andere Ereignisse über dauerhafte Warteschlangen bereitstellen. Verschiedene Datenstromtypen können unterschiedliche Batchverarbeitungsstrategien, Zwischenspeicherungsalgorithmen oder Backpressure-Verfahren verwenden. Streamanbieter sind Erweiterbarkeitspunkte in der Orleans Streaming-Runtime, die es Ihnen ermöglichen, einen beliebigen Streamtyp zu implementieren, um Einschränkungen für Streaminganwendungen nur für eine Teilmenge dieser Verhaltensentscheidungen zu vermeiden. Dieser Erweiterbarkeitspunkt ist ähnlich wie Orleans bei Speicheranbietern.

Azure Event Hub-Streamanbieter

Azure Event Hubs ist ein vollständig verwalteter Echtzeitdatenaufnahmedienst, der Millionen von Ereignissen pro Sekunde empfangen und verarbeiten kann. Es wurde entwickelt, um den hohen Durchsatz, die Erfassung von Daten mit geringer Latenz aus mehreren Quellen und die anschließende Verarbeitung dieser Daten durch mehrere Verbraucher zu verarbeiten.

Event Hubs werden häufig als Grundlage einer größeren Ereignisverarbeitungsarchitektur verwendet, die als "Front door" für eine Ereignispipeline dient. Sie können es verwenden, um Daten aus verschiedenen Quellen aufzunehmen, einschließlich Social Media-Feeds, IoT-Geräte und Protokolldateien. Einer der wichtigsten Vorteile von Event Hubs ist die Möglichkeit, horizontal zu skalieren, um die Anforderungen der größten Ereignisverarbeitungsworkloads zu erfüllen. Es ist auch hochverfügebar und fehlertolerant, mit mehreren Datenreplikaten, die über mehrere Azure-Regionen verteilt sind, um eine hohe Verfügbarkeit sicherzustellen.

Das Microsoft.OrleansStreaming.EventHubs NuGet-Paket enthält den Event Hubs-Streamanbieter.

Azure Queue (AQ)-Streamanbieter

Der Azure Queue (AQ)-Streamanbieter liefert Ereignisse über Azure-Warteschlangen. Auf der Produzentenseite fügt der AQ-Stream-Anbieter Ereignisse direkt in die Azure Queue ein. Auf der Verbraucherseite verwaltet der AQ-Streamanbieter eine Reihe von Pull-Agents , die Ereignisse aus einer Reihe von Azure-Warteschlangen abrufen und an den Anwendungscode übermitteln, der sie nutzt. Sie können sich die Pull-Agents als verteiltes "Microservice" vorstellen – eine partitionierte, hochverwendbare und elastisch verteilte Komponente. Die Pull-Agents arbeiten in denselben Silos, die Anwendungskörner hosten. Daher ist es nicht notwendig, separate Azure-Workerrollen auszuführen, um aus den Warteschlangen zu ziehen. Die Orleans Streaming-Runtime verwaltet das Vorhandensein von Pull-Agents, deren Verwaltung, den Rückdruck, das Ausgleichen der Warteschlangen zwischen ihnen und das Übergeben von Warteschlangen von einem fehlgeschlagenen Agenten an einen anderen Agenten. Dies ist für Anwendungscode, der Datenströme verwendet, transparent.

Das Microsoft.Orleans.Streaming.AzureStorage NuGet-Paket enthält den Azure Queue Storage Streamanbieter.

Warteschlangenadapter

Verschiedene Streamanbieter, die Ereignisse über dauerhafte Warteschlangen bereitstellen, weisen ein ähnliches Verhalten auf und unterliegen ähnlichen Implementierungen. Daher bieten wir ein generisches, erweiterbares PersistentStreamProvider an, mit dem Sie verschiedene Arten von Warteschlangen anschließen können, ohne einen völlig neuen Stream-Anbieter von Grund auf neu zu schreiben. PersistentStreamProvider verwendet eine IQueueAdapter Komponente, die spezifische Implementierungsdetails der Warteschlange abstrahiert und Mittel für Enqueue- und Dequeue-Ereignisse bereitstellt. Die Logik im Inneren PersistentStreamProvider behandelt alles andere. Der oben erwähnte Azure-Warteschlangenanbieter wird auch auf diese Weise implementiert: Es handelt sich um eine Instanz von PersistentStreamProvider, die ein AzureQueueAdapter nutzt.

.NET Aspire-Integration für Streaming

.NET Aspire vereinfacht die Orleans Streamingkonfiguration durch die automatische Verwaltung der Ressourcenbereitstellung und -verbindung.

Azure Queue Storage Streaming mit Aspire

AppHost-Projekt (Program.cs):

var builder = DistributedApplication.CreateBuilder(args);

var storage = builder.AddAzureStorage("storage");
var queues = storage.AddQueues("streaming");

var orleans = builder.AddOrleans("cluster")
    .WithClustering(builder.AddRedis("redis"))
    .WithStreaming("AzureQueueProvider", queues);

builder.AddProject<Projects.MySilo>("silo")
    .WithReference(orleans)
    .WithReference(queues);

builder.Build().Run();

Silo-Projekt (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

builder.AddServiceDefaults();
builder.AddKeyedAzureQueueServiceClient("streaming");
builder.UseOrleans();

builder.Build().Run();

Tipp

Während der lokalen Entwicklung verwendet Aspire automatisch den Azurite-Emulator für Azure Queue Storage. In Produktionsbereitstellungen verbindet Sich Aspire basierend auf Ihrer Azure-Bereitstellungskonfiguration mit Ihrem echten Azure Storage-Konto.

Von Bedeutung

Sie müssen AddKeyedAzureQueueServiceClient aufrufen, um den Warteschlangenclient im Abhängigkeitsinjektionscontainer zu registrieren. Orleans Streaming-Anbieter suchen Ressourcen anhand ihres Schlüsseldienstnamens. Wenn Sie diesen Schritt überspringen, kann Orleans den Warteschlangenclient nicht auflösen, und zur Laufzeit tritt ein Fehler bei der Abhängigkeitsauflösung auf.

In-Memory-Streaming für die Entwicklung

Für lokale Entwicklungs- und Testszenarien können Sie speicherinternes Streaming verwenden, für das keine externen Abhängigkeiten erforderlich sind:

AppHost-Projekt (Program.cs):

var builder = DistributedApplication.CreateBuilder(args);

var orleans = builder.AddOrleans("cluster")
    .WithDevelopmentClustering()
    .WithMemoryStreaming("MemoryStreamProvider");

builder.AddProject<Projects.MySilo>("silo")
    .WithReference(orleans);

builder.Build().Run();

Silo-Projekt (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

builder.AddServiceDefaults();
builder.UseOrleans();

builder.Build().Run();

Warnung

In-Memory-Streams sind nicht dauerhaft und gehen verloren, wenn das Silo neu gestartet wird. Verwenden Sie In-Memory-Streaming nur für Entwicklung und Tests – niemals für Produktionsworkloads, die eine Nachrichtenbeständigkeit erfordern.

Broadcast-Kanäle mit Aspire

Übertragungskanäle bieten einen einfachen Pub/Sub-Mechanismus zum Übertragen von Nachrichten an alle Abonnenten:

AppHost-Projekt (Program.cs):

var builder = DistributedApplication.CreateBuilder(args);

var orleans = builder.AddOrleans("cluster")
    .WithDevelopmentClustering()
    .WithBroadcastChannel("BroadcastChannel");

builder.AddProject<Projects.MySilo>("silo")
    .WithReference(orleans);

builder.Build().Run();

Silo-Projekt (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

builder.AddServiceDefaults();
builder.UseOrleans();

builder.Build().Run();

Eine umfassende Dokumentation zur Orleans und .NET Aspire-Integration finden Sie unter Orleans und .NET Aspire-Integration.

Einfacher Nachrichtenstreamanbieter

Der einfache Nachrichtenstromanbieter, auch bekannt als der SMS-Anbieter, überträgt Ereignisse über TCP unter Verwendung regulärer Grain-Nachrichten. Da SMS-Ereignisse über unzuverlässige TCP-Links übermittelt werden, garantiert SMS keine zuverlässige Ereignisübermittlung und sendet nicht automatisch fehlgeschlagene Nachrichten für SMS-Datenströme erneut. Standardmäßig gibt der Aufruf OnNextAsync des Produzenten einen Task Wert zurück, der den Verarbeitungsstatus des Datenstromanwenders darstellt. Dadurch wird dem Produzenten mitgeteilt, ob der Verbraucher das Ereignis erfolgreich empfangen und verarbeitet hat. Wenn dieser Vorgang fehlschlägt, kann der Produzent sich entscheiden, dasselbe Ereignis erneut zu senden, wodurch die Zuverlässigkeit auf Anwendungsebene erreicht wird. Obwohl die Nachrichtenübermittlung bei Streams nach dem Best-Effort-Prinzip erfolgt, sind die Nachrichtenströme selbst zuverlässig. Das heißt, die von Pub-Sub durchgeführte Abonnent-zu-Produzent-Bindung ist voll zuverlässig.

Siehe auch

• Orleans Stream-Implementierungsdetails