Azure Service Bus-Drosselungsbedingungen, die in der Messaging-Plattform zu beachten sind

In diesem Blog werden die verschiedenen Drosselungsbedingungen für Azure Service Bus zur ständigen Überwachung der Azure-Dienstfunktionen erläutert.

Beim Entwerfen einer Lösung in Azure ist es immer wichtig, alle möglicherweise geltenden Einschränkungen zu berücksichtigen. Diese Einschränkungen können nicht nur von der Wahl des Levels herrühren, sondern auch von technischen Einschränkungen. Hier werfen wir einen Blick auf die Service Bus-Drosselungsbedingungen und deren Handhabung. Wenn Sie sich auf der Dokumentationsseite befinden, ist klar, dass es mehrere Schwellenwerte gibt, die sich auf die erreichte maximale Leistung auswirken, bevor Sie auf Drosselungsbedingungen stoßen.

• Warteschlangen-/Themengröße
• Anzahl gleichzeitiger Verbindungen in einem Namensraum
• Anzahl gleichzeitiger Empfangsanforderungen in einer Warteschlange/einem Thema/einer abonnierenden Entität
• Nachrichtengröße für eine Warteschlange/ein Thema/eine abonnierende Entität
• Anzahl der Nachrichten pro Transaktion

Jede dieser Erkrankungen hat ihre Besonderheiten und Möglichkeiten, sie zu bewältigen, wenn sie auftreten. Es ist wichtig, jeden einzelnen zu verstehen, da er es uns ermöglicht, Entscheidungen über die nächsten Schritte zu treffen. Und richten Sie eine robuste Architektur ein, um das Risiko zu minimieren. Werfen wir einen Blick auf die einzelnen Optionen und die Optionen, um diese Schwellenwerte zu verringern.

Warteschlangen-/Themengröße

Dieser Schwellenwert stellt die maximale Größe einer Service Bus-Entität dar und wird beim Erstellen der Warteschlange oder des Themas definiert. Wenn Nachrichten nicht von der Entität abgerufen oder langsamer abgerufen als gesendet werden. Die Entität wird gefüllt, bis sie diese Größe erreicht. Sobald die Entität dieses Limit erreicht, weist sie neue eingehende Nachrichten zurück und gibt eine QuotaExceededException an den Absender zurück. Die maximale Entitätsgröße kann 1, 2, 3, 4 oder 5 GB für den Basic- oder Standard-Tarif ohne Partitionierung betragen. 80 GB Standard-Tarif mit aktivierter Partitionierung sowie für den Premium-Tarif.

In diesem Fall besteht eine Möglichkeit darin, weitere Nachrichtenempfänger hinzuzufügen, um sicherzustellen, dass unser Unternehmen mit den aufgenommenen Nachrichten Schritt halten kann. Wenn die Entität nicht unter unserer Kontrolle steht, wäre eine andere Option, die Ausnahme abzufangen und einen exponentiellen Backoff-Wiederholungsmechanismus zu verwenden. Durch die Implementierung von exponentiellem Backoff erhalten Empfänger die Möglichkeit, die Verarbeitung der Nachrichten in der Warteschlange nachzuholen. Eine weitere Option besteht darin, die Empfänger dazu zu bringen, Prefetch zu verwenden, was eine höhere Leistung ermöglicht und Nachrichten in unserer Entität schneller löscht.

Anzahl gleichzeitiger Verbindungen in einem Namensraum

Der zweite in diesem Beitrag besprochene Schwellenwert betrifft die Anzahl der Verbindungen, die gleichzeitig in einem Service Bus-Namespace geöffnet werden können. Sobald alle Verbindungen verwendet werden, lehnt unsere Entität nachfolgende Verbindungsanforderungen ab und löst eine QuotaExceededException aus. Um diesen Zustand abzumildern, ist es wichtig zu wissen, dass Warteschlangen ihre Verbindungen zwischen Sendern und Empfängern teilen. Themen hingegen haben einen separaten Pool von Verbindungen für Sender und Empfänger. Das für die Kommunikation verwendete Protokoll ist ebenfalls kritisch, da NetMessaging 1.000 Verbindungen zulässt, während AMQP uns 5.000 Verbindungen ermöglicht.

Das bedeutet, dass Sie als Eigentümer der Entitäten von Warteschlangen zu Themen wechseln können, wodurch sich die Anzahl der Verbindungen effektiv verdoppelt. Seien Sie jedoch vorsichtig, dies erhöht nur die Anzahl der insgesamt zulässigen Verbindungen, aber wenn es bereits eine große Anzahl von Sendern oder Empfängern gibt, erhalten wir immer noch die maximale Anzahl von Verbindungen, die uns das gewählte Protokoll für jede dieser Verbindungen gibt. Wenn der sendende oder empfangende Client unter unserer Kontrolle steht, besteht auch die Möglichkeit, das Protokoll zu wechseln, was uns durch den Wechsel von NetMessaging zu AMQP die fünffache Anzahl von Verbindungen bringen könnte.

Anzahl gleichzeitiger Empfangsanforderungen in einer Warteschlange/einem Thema/einer abonnierenden Entität

Dieser Schwellenwert gilt für die Anzahl der Empfangsvorgänge, die für eine Service Bus-Entität aufgerufen werden.Jede unserer Entitäten kann maximal 5.000 Empfangsanforderungen gleichzeitig verarbeiten. Bei Themenabonnements teilen sich alle Themenabonnements diese Empfangsvorgänge. Sobald die Entität dieses Limit erreicht, lehnt sie nachfolgende Empfangsanforderungen ab, bis die Anzahl der Anforderungen geringer ist, und gibt eine ServerBusyException an den Empfänger zurück. Um diese Einschränkung zu umgehen, gibt es wieder die Möglichkeit, eine exponentielle Backoff-Wiederholungsstrategie zu implementieren, wenn Nachrichten von unserer Service Bus-Entität empfangen werden.Alternativ wäre es, die Gesamtzahl der Empfänger zu reduzieren.

wiederholt

Für einige der Drosselungsbedingungen ist ein erneuter Versuch eine plausible Lösung, um sicherzustellen, dass unser Client seine Nachrichten zuletzt übermittelt. Dies ist in jeder Situation der Fall, in der die Zeit zur Lösung des Problems beitragen kann. Die Lösung kann darin bestehen, Nachrichten abzurufen, Verbindungen zu schließen oder die Anzahl der Clients zu verringern. Es ist jedoch wichtig zu beachten, dass Wiederholungsversuche nicht unter all diesen Drosselungsbedingungen helfen. Wenn beispielsweise eine Nachricht zu groß ist, wird es nie gelingen, diese Nachricht erneut zu versuchen. Daher ist es wichtig, die tatsächliche Ausnahme zu überprüfen, die Sie erhalten, wenn Sie sie abfangen. Je nach Art der Nachricht können Sie Entscheidungen über die nächsten Schritte treffen.

Außerdem werden standardmäßig alle 10 Sekunden Wiederholungen durchgeführt. Obwohl dies für viele Gelegenheiten akzeptabel ist, könnte es besser sein, stattdessen einen exponentiellen Wiederholungsmechanismus zu implementieren. Dieser Mechanismus wiederholt sich in zunehmendem Intervall, z. B. zuerst nach 10 Sekunden, dann nach 30 Sekunden, dann nach 1 Minute und so weiter. Dieser Mechanismus ermöglicht eine schnelle Lösung zeitweise auftretender Probleme. Aber es hilft auch bei lang andauernden Ausnahmen dank des immer länger werdenden Intervalls zwischen abgemilderten Wiederholungen, das durch einen exponentiellen Backoff-Wiederholungsmechanismus bereitgestellt wird.

Überwachung

Bei der Arbeit mit Service Bus ist es entscheidend, eine geeignete Überwachungsstrategie zu implementieren. Dazu gibt es mehrere Möglichkeiten, von den in Azure integrierten Tools bis hin zur Verwendung eines Drittanbieterprodukts wie z Kein Server 360. Jede dieser Lösungen hat ihre Stärken und Schwächen. Wenn es darum geht, den Drosselungszustand von Service Bus zu betrachten, blauer Monitor hat kürzlich neue Metriken hinzugefügt, die uns genau das ermöglichen. Diese Funktionen befinden sich derzeit in der Vorschauphase und stellen mehrere Metriken bereit, um Service Bus-Namespaces und -Entitäten im Auge zu behalten.Eine dieser Metriken ist Drosselungsanforderungen, die uns einen Einblick in die Anzahl der Drosselungsanforderungen gibt.

Später ist es sogar möglich, zusätzlich zu diesen Metriken Warnungen zu konfigurieren, was Sie über Azure Monitor erreichen können. Fügen Sie eine Warnungsregel für dieses Szenario hinzu. Diese Regeln definieren, wann Warnungen ausgelöst werden und welche Maßnahmen zu ergreifen sind.

Diese Aktionen reichen vom Senden einer E-Mail oder SMS bis zum Aufrufen von Webhooks oder Aufrufen von Logik-Apps. Diese letzten Optionen geben uns die Möglichkeit, benutzerdefinierte Workflows zu starten, bestimmte Teams zu benachrichtigen, ein Ticket zu erstellen und vieles mehr. Geben Sie dazu in der Alert-Regel eine Aktionsgruppe mit einer oder mehreren Aktionen an. Folglich ist es sogar möglich, mehrere Aktionsgruppen für verschiedene Arten von Warnungen zu erstellen. Hier können Sie allgemeine Warnungen an das Betriebsteam und dienstspezifische Warnungen an Eigentümer dieses Dienstes innerhalb der Organisation senden.

Serverless360 bietet einfache Konfigurations- und Benachrichtigungsoptionen für Azure Service Bus-Überwachung und Generieren von Warnungen für Servicebus-Drosselungsbedingungen.

Fazit

Beim Aufbau einer Architektur mit Azure-Diensten ist es immer wichtig, die Fähigkeiten im Auge zu behalten. In diesem Fall haben wir die Service Bus-Drosselungsbedingungen untersucht.Eine Minderung erfolgt häufig durch Anpassen einiger unserer Clienteigenschaften oder durch Implementieren einer Wiederholungsstrategie. Auch, um eine klare Sicht auf unsere Umgebung zu behalten., müssen wir eine Überwachungsstrategie für unsere Situation implementieren. Wo Warnungen aktiviert werden, falls eine dieser einschränkenden Bedingungen eintritt.

Quelle: Kostenlose Artikel von ArticlesFactory.com