(0) exportieren Drucken
Alle erweitern

Asynchrone Messagingmuster und hohe Verfügbarkeit

Letzte Aktualisierung: Januar 2014

Asynchrones Messaging kann auf viele verschiedene Arten implementiert werden. Bei Warteschlangen, Themen und Abonnements, die insgesamt als Messagingentitäten bezeichnet werden, unterstützt Windows Azure Service Bus Asynchronität über einen Speicherungs- und Weiterleitungsmechanismus. Beim normalen (synchronen) Vorgang werden Nachrichten an Warteschlangen oder Themen gesendet und von Warteschlangen und Abonnements erhalten. Von Ihnen erstellte Anwendungen hängen davon ab, dass diese Entitäten immer verfügbar sind. Wenn sich der Zustand aus verschiedenen Umständen ändert, müssen Sie eine Entität mit geringerer Funktionalität bereitstellen, die den größten Bedarf decken kann.

Bei Anwendungen werden normalerweise asynchrone Messagingmuster verwendet, um mehrere Kommunikationsszenarien zu ermöglichen. Sie können Anwendungen erstellen, bei denen Clients Nachrichten an Dienste senden können, selbst wenn der Dienst nicht ausgeführt wird. Bei Anwendungen, die Kommunikationen schubweise verarbeiten, kann eine Warteschlange dabei helfen, die Last durch Bereitstellen eines Puffers für die Kommunikationen auszugleichen. Schließlich können Sie einen einfachen und effektiven Lastenausgleich erstellen, der die Nachrichten über mehrere Maschinen verteilt.

Damit Sie die Verfügbarkeit dieser Entitäten aufrecht erhalten können, ziehen Sie mehrere verschiedene Arten in Betracht, in denen diese Entitäten für ein permanentes Nachrichtensystem unverfügbar erscheinen. Im Allgemeinen wird die Entität auf folgende Arten für Anwendungen unverfügbar:

  1. Nachrichten können nicht gesendet werden.

  2. Nachrichten können nicht empfangen werden.

  3. Entitäten können nicht verwaltet (erstellt, abgerufen, aktualisiert oder gelöscht) werden.

  4. Eine Verbindung mit dem Dienst kann nicht hergestellt werden.

Bei jedem dieser Fehler gibt es verschiedene Fehlermodi, die es einer Anwendung ermöglichen, bei geringerer Funktionalität weiterhin Aufgaben durchzuführen. Zum Beispiel kann ein System, das Nachrichten senden, aber nicht empfangen kann, noch Aufträge von Kunden empfangen, aber diese Aufträge nicht verarbeiten. In diesem Thema werden potenzielle Probleme behandelt und die Vorgehensweisen erläutert, die diese Probleme mindern können. Service Bus hat mehrere Maßnahmen eingeführt, die abonniert werden müssen, und in diesem Thema werden auch die Regeln beschrieben, die die Verwendung dieser abonnierten Maßnahmen steuern.

Zuverlässigkeit im Servicebus

Es gibt verschiedene Arten, Nachrichten- und Entitätenprobleme zu behandeln, und für die sachgemäße Verwendung dieser Maßnahmen gibt es Richtlinien. Zum Verstehen der Richtlinien, müssen Sie zuerst wissen, wann bei Service Bus ein Fehler auftreten kann. Diese Probleme sind meistens aufgrund des Entwurfs von Windows Azure-Systemen vorübergehend. Im Überblick gibt es die folgenden verschiedenen Gründe für Unverfügbarkeit:

  • Drosselung durch ein externes System, von dem Service Bus abhängt. Drosselung durch Interaktionen mit Speicher- und Rechenressourcen.

  • Problem eines Systems, von dem Service Bus abhängt. Zum Beispiel können bei einem bestimmten Teil des Speichers Probleme auftreten.

  • Fehler von Service Bus auf einem einzelnen Subsystem. In diesem Fall kann ein Serverknoten in einen inkonsistenten Zustand geraten und muss neu starten, wodurch alle Entitäten, denen dieser Serverknoten dient, die Last über andere Knoten ausgleichen müssen. Dies kann wiederum bewirken, dass Nachrichten für eine kurze Zeit langsam verarbeitet werden.

  • Fehler von Service Bus in einem Windows Azure Data Center. Dies ist der klassische schwerwiegende Fehler, bei dem das System viele Minuten oder ein paar Stunden lang nicht erreichbar ist.

noteHinweis
Der Begriff Speicher kann sich sowohl auf Windows Azure-Speicher als auch auf SQL Azure beziehen.

Service Bus enthält eine Anzahl von Maßnahmen für die oben genannten Probleme. In den folgenden Abschnitten werden alle Probleme und die entsprechenden Maßnahmen erläutert.

Drosselung

Bei Service Bus ermöglicht die Drosselung eine kooperative Nachrichtenratenverwaltung. Jeder einzelne Service Bus-Knoten enthält mehrere Entitäten. Jede dieser Entitäten stellt in Bezug auf CPU, Arbeitsspeicher, Speicher und andere Facets Forderungen an das System. Wenn eine dieser Facets erkennt, dass die Auslastung definierte Schwellenwerte überschreitet, kann Service Bus eine gegebene Anforderung verweigern. Der Anrufer empfängt eine ServerBusyException und versucht den Vorgang nach 10 Sekunden erneut.

Als Maßnahme muss der Code den Fehler lesen und alle Wiederholungsversuche für diese Nachricht mindestens 10 Sekunden lang stoppen. Da der Fehler bei mehreren Teilen der Kundenanwendung auftreten kann, wird erwartet, dass jeder Teil diese Wiederholungsversuchlogik unabhängig von anderen Teilen ausführt. Der Code kann durch Partitionierung einer Warteschlange oder eines Themas die Wahrscheinlichkeit der Drosselung verringern.

Problem bei einer Windows Azure-Abhängigkeit

Bei anderen Komponenten in Windows Azure können gelegentlich Dienstprobleme auftreten. Beispielsweise kann bei der Aktualisierung eines Systems, das Service Bus verwendet, dieses System vorübergehend geringere Funktionalität aufweisen. Um diese Arten von Problemen zu umgehen, werden Maßnahmen von Service Bus regelmäßig untersucht und implementiert. Diese Maßnahmen weisen Nebeneffekte auf. Beispielsweise implementiert Service Bus zur Behandlung vorübergehender Speicherprobleme ein System, das die konsistente Verarbeitung von Nachrichtensendevorgängen ermöglicht. Aufgrund der Natur der Maßnahme, kann es bis zu 15 Minuten lang dauern, bis eine gesendete Nachricht in der betroffenen Warteschlange oder im betroffenen Abonnement angezeigt wird und empfangen werden kann. Im Allgemeinen wird dieses Problem bei den meisten Entitäten nicht auftreten. Diese Maßnahme ist jedoch manchmal bei der Anzahl von Entitäten in Service Bus innerhalb von Windows Azure für eine kleine Untermenge von Service Bus-Kunden notwendig.

Servicebusfehler eines einzelnen Subsystems

Bei jeder Anwendung können verschiedene Umstände bewirken, dass eine interne Komponente von Service Bus inkonsistent wird. Wenn Service Bus dies erkennt, werdem Daten aus der Anwendung erfasst und damit eine Diagnose der Ereignisse durchgeführt. Sobald die Daten erfasst sind, wird die Anwendung in einem Versuch, zu einem konsistenten Zustand zurückzukehren, neu gestartet. Dieser Prozess wird ziemlich schnell ausgeführt und hat zur Folge, dass eine Entität ein paar Minuten lang unverfügbar erscheint, obwohl die normalen Ausfallzeiten viel kürzer sind.

In diesen Fällen generiert die Clientanwendung eine TimeoutException- oder MessagingException-Ausnahme. Das Service Bus .NET SDK enthält für dieses Problem eine Maßnahme in Form einer automatisierten Clientwiederholungsversuchlogik. Wenn der Wiederholungszeitraum abgelaufen ist und die Nachricht nicht zugestellt werden kann, können Sie andere Funktionen, wie z. B. Namespacepaare, verwenden. Namespacepaare erfordern andere Vorsichtsmaßnahmen, die später in diesem Dokument erläutert werden.

Fehler des Servicebuses in einem Azure Data Center

Der wahrscheinlichste Grund für einen Fehler im Azure Data Center ist ein Fehler bei der Bereitstellung einer Aktualisierung für Service Bus oder für ein abhängiges System. Wenn die Plattform voll entwickelt ist, nimmt die Wahrscheinlichkeit dieser Fehlerart ab. Ein Rechenzentrumsfehler kann auch u. a. aus folgenden Gründen auftreten:

  • Stromausfall (Stromversorgung und Strom werden getrennt).

  • Konnektivität (Internetverbindung zwischen Clienten und Windows Azure ist unterbrochen).

In beiden Fällen wird das Problem durch eine Naturkatastrophe oder durch eine von Menschen verursachte Katastrophe bewirkt. Um dieses Problem zu umgehen und sicherzustellen, dass Nachrichten noch gesendet werden können, können Sie Namespacepaare verwenden und somit Nachrichten an einen zweiten Speicherort senden, während der primäre Speicherort wieder fehlerfrei wird.

Namespacepaare

Die Funktion der Namespacepaare unterstützt Szenarien, bei denen eine Service Bus-Entität oder -Bereitstellung in einem Rechenzentrum unverfügbar wird. Obwohl dieses Ereignis selten auftritt, müssen verteilte System dennoch darauf vorbereitet sein, die schlimmsten Fälle zu verarbeiten. Normalerweise tritt dieses Ereignis auf, weil bei einem bestimmten Element, von dem Service Bus abhängt, ein vorübergehendes Problem auftritt. Damit die Verfügbarkeit der Anwendung bei einem Stromausfall aufrecht erhalten werden kann, können Service Bus-Benutzer zwei getrennte Namespaces (vorzugsweise in getrennten Rechenzentren) dazu verwenden, ihre Messagingentitäten zu hosten. Der Rest dieses Abschnitts verwendet die folgende Terminologie:

  • Primärer Namespace: Der Namespace, mit dem Ihre Anwendung für Sende- und Empfangsvorgänge interagiert.

  • Sekundärer Namespace: Der Namespace, der als Sicherung für den primären Namespace fungiert. Die Anwendungslogik interagiert mit diesem Namespace nicht.

  • Failoverintervall: Die Zeitspanne, in der normale Fehler akzeptiert werden können, bevor die Anwendung vom primären Namespace zum sekundären Namespace wechselt.

Namespacepaare unterstützen Sendeverfügbarkeit. Sendeverfügbarkeit konzentriert sich auf die Erhaltung der Nachrichtensendefunktion. Zur Verwendung der Sendeverfügbarkeit muss Ihre Anwendung die folgenden Anforderungen erfüllen:

  1. Nachrichten werden nur vom primären Namespace empfangen.

  2. Nachrichten, die an eine angegebene Warteschlange bzw. an ein angegebenes Thema gesendet werden, können in der falschen Reihenfolge ankommen.

  3. Bei Verwendung von Sitzungen in Ihrer Anwendung:

    1. Nachrichten in einer Sitzung können in der falschen Reihenfolge ankommen. Dies entspricht nicht der normalen Funktionalität von Sitzungen. Dies bedeutet vielmehr, dass Ihre Anwendung Sitzungen verwendet, um Nachrichten logisch zu gruppieren.

    2. Der Sitzungsstatus wird nur im primären Namespace verwaltet.

  4. Die primäre Warteschlange kann online sein und Nachrichten annehmen, bevor die sekundäre Warteschlange alle Nachrichten an die primäre Warteschlange liefert.

Dieser Abschnitt behandelt die API und die Art, in der APIs implementiert werden. Außerdem zeigt er Beispielcode, der diese Funktion verwendet. Bitte beachten Sie, dass diese Funktion mit Auswirkungen auf Ihre Abrechnung verbunden ist.

Die MessagingFactory.PairNamespaceAsync-API

Die Funktion der Namespacepaare führt die folgende neue Methode für die MessagingFactory-Klasse ein:

public Task PairNamespaceAsync(PairedNamespaceOptions options)

Wenn die Aufgabe abgeschlossen ist, ist die Kopplung der Namespaces ebenfalls beendet und kann für jeden MessageReceiver, QueueClient oder TopicClient fungieren, der mit der MessagingFactory erstellt wurde. PairedNamespaceOptions ist die Basisklasse für die verschiedenen Kopplungsarten, die bei einer MessagingFactory verfügbar sind. Die zurzeit einzige abgeleitete Klasse hat den Namen SendAvailabilityPairedNamespaceOptions. Sie implementiert die Anforderungen für die Sendeverfügbarkeit. SendAvailabilityPairedNamespaceOptions hat einen Satz von Konstruktoren, die alle aufeinander aufbauen. Wenn Sie sich den Konstruktor mit den meisten Parametern ansehen, können Sie das Verhalten der anderen Konstruktoren verstehen.

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

Dabei bedeuten diese Parameter Folgendes:

  • secondaryNamespaceManager: Eine initialisierte NamespaceManager-Instanz für den sekundären Namespace, die die PairNamespaceAsync-Methode zum Einrichten des sekundären Namespaces verwenden kann. Der Manager wird verwendet, um die Liste der Warteschlangen im Namespace abzurufen und sicherzustellen, dass die erforderlichen Backlogwarteschlangen vorhanden sind. Sind diese Warteschlangen nicht vorhanden, werden sie erstellt. Der NamespaceManager erfordert die Möglichkeit, ein Token mit dem Anspruch Verwalten zu erstellen.

  • messagingFactory: Die MessagingFactory-Instanz für den sekundären Namespace. Die MessagingFactory wird zum Senden und, wenn die EnableSyphon-Eigenschaft auf true festgelegt ist, zum Empfangen von Nachrichten aus den Backlogwarteschlangen verwendet.

  • backlogQueueCount: Die Anzahl der zu erstellenden Backlogwarteschlangen. Dieser Wert muss mindestens 1 sein. Wenn Nachrichten an die Backlogwarteschlangen gesendet werden, wird eine dieser Warteschlangen zufällig ausgewählt. Wenn Sie den Wert auf 1 festlegen, kann immer nur eine Warteschlange verwendet werden. Ist dies der Fall und bei der einzigen Backlogwarteschlange tritt ein Fehler auf, kann der Client keine andere Backlogwarteschlange versuchen und beim Senden Ihrer Nachricht tritt ein Fehler auf. Es wird empfohlen, diesen Werts auf einen höheren Wert festzulegen. Standardmäßig wird der Wert auf 10 eingestellt. Sie können diesen Wert je nach Datenmenge, die Ihre Anwendung pro Tag sendet, erhöhen oder verringern. Jede Backlogwarteschlange kann bis zu 5 GB an Nachrichten enthalten.

  • failoverInterval: Die Zeitspanne, in denen Fehler des primären Namespaces akzeptiert werden, bevor eine einzelne Entität auf den sekundären Namespace umgeschaltet wird. Failovers treten bei entitätsweise auf. Die Entitäten in einem einzelnen Namespace befinden sich häufig in verschiedenen Knoten im Service Bus. Ein Fehler in einer Entität beinhaltet nicht einen Fehler in einer anderen. Sie können diesen Wert auf Zero festlegen, um beim ersten dauerhaften Fehler sofort auf den sekundären Namespace überzugehen. Jede MessagingException, bei der die IsTransient-Eigenschaft auf False festgelegt ist und eine TimeoutException sind Fehler, die den Failovertimer auslösen. Andere Ausnahmen, wie z. B. UnauthorizedAccessException, lösen kein Failover aus, da diese angeben, dass der Client falsch konfiguriert ist. Eine ServerBusyException löst kein Failover aus, da beim richtigen Muster 10 Sekunden lang gewartet und die Nachricht danach erneut gesendet wird.

  • enableSyphon: Gibt an, dass diese bestimmte Kopplung auch Nachrichtensiphons vom sekundären Namespace zurück an den primären Namespace ausführen soll. Im Allgemeinen wird dieser Wert von Anwendungen, die Nachrichten senden, auf false festgelegt. Anwendungen, die Nachrichten empfangen, sollten diesen Wert auf true festlegen. Der Grund für diese Vorgehensweise ist die Tatsache, dass häufig weniger Nachrichtenempfänger als Nachrichtenabsender vorhanden sind. Je nach Anzahl der Empfänger können Sie eine einzelne Anwendungsinstanz für die Verarbeitung der Siphonaufgaben auswählen. Die Verwendung vieler Empfänger hat Auswirkungen auf die Abrechnung für jede Backlogwarteschlange.

Der Code wird verwendet, indem eine primäre MessagingFactory-Instanz, eine sekundäre MessagingFactory-Instanz, eine sekundäre NamespaceManager-Instanz und eine SendAvailabilityPairedNamespaceOptions-Instanz erstellt werden. Der Aufruf kann so einfach wie folgender Code sein:

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

Wenn die Aufgabe, die von der PairNamespaceAsync-Methode zurückgegeben wird, abgeschlossen ist, ist alles eingerichtet und kann verwendet werden. Es kann sein, dass Sie noch nicht alle Hintergrundarbeiten für das ordnungsgemäße Funktionieren der Kopplung abgeschlossen haben, wenn die Aufgabe zurückgegeben wird. Deshalb sollten Sie mit dem Senden von Nachrichten erst beginnen, wenn die Aufgabe zurückgegeben wird. Treten Fehler auf, wie z. B. falsche Anmeldeinformationen oder ein Fehler beim Erstellen der Backlogwarteschlangen, werden Ausnahmen ausgelöst, sobald die Aufgabe abgeschlossen ist. Sobald die Aufgabe zurückgegeben wird, überprüfen Sie durch Untersuchen der BacklogQueueCount-Eigenschaft Ihrer SendAvailabilityPairedNamespaceOptions-Instanz, dass die Warteschlangen gefunden bzw. erstellt wurden. Dieser Vorgang sieht beim vorstehenden Code folgendermaßen aus:

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft