Orleans-Streamanbieter
Streams können verschiedene Formen haben. Einige Streams können Ereignisse über direkte TCP-Links übermitteln, während bei anderen die Übermittlung von Ereignissen über dauerhafte Warteschlangen erfolgt. Verschiedene Streamtypen können unterschiedliche Batchverarbeitungsstrategien, Zwischenspeicherungsalgorithmen oder Rückstauverfahren anwenden. Um zu vermeiden, dass Streaminganwendungen nur auf eine Teilmenge dieser Verhaltensentscheidungen beschränkt werden, sind Streamanbieter Erweiterbarkeitspunkte für die Orleans Streaming Runtime, die es Benutzer*innen ermöglichen, beliebige Arten von Streams zu implementieren. Dieser Erweiterbarkeitspunkt ähnelt Orleans-Speicheranbietern.
Azure Event Hubs-Streamanbieter
Azure Event Hubs ist ein vollständig verwalteter Echtzeitdienst für die Datenerfassung, der Millionen von Ereignissen pro Sekunde empfangen und verarbeiten kann. Er dient dazu, die Erfassung von Daten aus mehreren Quellen mit hohem Durchsatz und geringer Latenz und die anschließende Verarbeitung dieser Daten durch mehrere Consumer zu handhaben.
Event Hubs wird häufig als Grundlage einer größeren Architektur zur Ereignisverarbeitung verwendet und dient dort als „Eingangstür“ für eine Ereignispipeline. Der Dienst kann dazu verwendet werden, Daten aus einer Vielzahl von Quellen zu erfassen, z. B. Feeds sozialer Medien, IoT-Geräte und Protokolldateien. Einer der wichtigsten Vorteile von Event Hubs ist die Möglichkeit zum Aufskalieren, um die Anforderungen höchst umfangreicher Workloads für die Ereignisverarbeitung zu erfüllen. Der Dienst ist hoch verfügbar und fehlertolerant und bietet mehrere Datenreplikate, die über mehrere Azure-Regionen verteilt sind, um eine hohe Verfügbarkeit sicherzustellen.
Das NuGet-Paket Microsoft.Orleans.Streaming.EventHubs enthält den Event Hubs-Streamanbieter.
Azure Queue-Streamanbieter (AQ)
Der Azure Queue-Streamanbieter (AQ) übermittelt Ereignisse über Azure Queues. Auf Producerseite reiht der AQ-Streamanbieter Ereignisse direkt in Azure Queue ein. Auf Consumerseite verwaltet der AQ-Streamanbieter eine Reihe von Pull-Agents, die Ereignisse aus Azure Queue-Gruppen pullen und an den Anwendungscode übermitteln, der sie nutzt. Sie können sich die Pull-Agents als verteilten „Microservice“ vorstellen – eine partitionierte, hochverfügbare und elastisch verteilte Komponente. Die Pull-Agents werden in den gleichen Silos ausgeführt, die Anwendungs-Grains hosten. Daher ist es nicht erforderlich, separate Azure-Workerrollen auszuführen, um Pulls aus den Warteschlangen auszuführen. Die Pull-Agents, ihre Verwaltung sowie Rückstaus, Ausbalancieren der Warteschlangen zwischen ihnen und das Übergeben von Warteschlangen von einem fehlerhaften Agent an einen anderen Agent werden vollständig von Orleans Streaming Runtime verwaltet und sind transparent für jeden Anwendungscode, der Streams verwendet.
Das NuGet-Paket Microsoft.Orleans.Streaming.AzureStorage enthält den Azure Queue Storage-Streamanbieter.
Warteschlangenadapter
Verschiedene Streamanbieter, die Ereignisse über dauerhafte Warteschlangen übermitteln, weisen ein ähnliches Verhalten auf und unterliegen einer ähnlichen Implementierung. Daher bieten wir einen generischen erweiterbaren PersistentStreamProvider, der es Entwicklern ermöglicht, verschiedene Arten von Warteschlangen einzubinden, ohne dass ein völlig neuer Streamanbieter von Grund auf neu geschrieben werden muss. PersistentStreamProvider verwendet eine IQueueAdapter-Komponente, die spezifische Details zur Implementierung der Warteschlange abstrahiert und Mittel für die enqueue- und dequeue-Ereignisse bereitstellt. Der gesamte Rest wird von der Logik im PersistentStreamProvider verarbeitet. Der oben erwähnte Azure Queue-Anbieter ist auch auf diese Weise implementiert: Es handelt sich um eine Instanz von PersistentStreamProvider, die einen AzureQueueAdapterverwendet.
Einfacher Nachrichtenstreamanbieter
Der einfache Nachrichtenstreamanbieter, der auch als SMS-Anbieter bezeichnet wird, übermittelt Ereignisse über TCP mit regulärem Orleans-Grain-Messaging. Da Ereignisse in SMS über unzuverlässige TCP-Links übermittelt werden, garantiert SMS keine zuverlässige Ereignisübermittlung und sendet fehlerhafte Nachrichten für SMS-Streams nicht automatisch erneut. Standardmäßig gibt der Aufruf von OnNextAsync durch den Producer eine Task zurück, die den Verarbeitungsstatus des Streamconsumers repräsentiert. Dieser informiert den Producer darüber, ob der Consumer das Ereignis erfolgreich empfangen und verarbeitet hat. Wenn bei dieser Aufgabe ein Fehler auftritt, kann der Producer sich entscheiden, dasselbe Ereignis erneut zu senden, wodurch Zuverlässigkeit auf Anwendungsebene erreicht wird. Obwohl die Streamnachrichtenübermittlung nach dem Best-Effort-Prinzip erfolgt, sind die SMS-Streams selbst zuverlässig. Das heißt, die beim Veröffentlichen/Abonnieren durchgeführte Bindung zwischen Abonnent und Producer ist vollständig zuverlässig.
