Auswählen einer Messagingplattform
Viele Kommunikationsplattformen stehen zur Verfügung, um die Zuverlässigkeit einer verteilten Anwendung zu verbessern, darunter auch mehrere in Microsoft Azure. Jede Plattform ist ein Tool, das einen anderen Zweck erfüllt. Es ist wichtig, dass Sie für jede Anforderung Ihrer Anwendung das richtige Tool wählen. Werfen Sie einen Blick auf Ihre Optionen in Azure Service Bus.
Die verteilte Architektur der geplanten Anwendung von Contoso Bicycles zur Bestellung und Nachverfolgung erfordert mehrere Komponenten, darunter Website, Datenspeicher und Back-End-Dienst. Sie können die Komponenten unserer Anwendung auf viele verschiedene Arten miteinander verbinden, wobei eine einzelne Anwendung mehrere Techniken nutzen kann.
Sie müssen entscheiden, welche Techniken in der neuen Contoso Bicycles-Anwendung zum Einsatz kommen sollen. Der erste Schritt besteht darin, jede Stelle zu bewerten, an der Kommunikation zwischen mehreren Komponenten stattfindet. Einige Komponenten müssen zeitnah ausgeführt werden, damit die Anwendung überhaupt ihre Arbeit verrichten kann. Andere sind zwar auch wichtig, aber nicht zeitkritisch. Wieder andere Komponenten, wie etwa Benachrichtigungen für mobile Apps, sind etwas optionaler.
Entscheiden zwischen Nachrichten und Ereignissen
Sowohl Nachrichten als auch Ereignisse sind Datagramme: Datenpakete, die von einer Komponente an eine andere gesendet werden. Sie unterscheiden sich in einer Hinsicht, die auf den ersten Blick unbedeutend erscheint, aber die Unterschiede können erhebliche Auswirkungen auf die Architektur Ihrer Anwendung haben.
Nachrichten
In der Terminologie verteilter Anwendungen ist das bestimmende Merkmal einer Nachricht, dass die allgemeine Integrität der Anwendung davon abhängen kann, dass Nachrichten empfangen werden. Sie können sich das Senden einer Nachricht so vorstellen, dass eine Komponente den Staffelstab eines Workflows an eine andere Komponente übergibt. Der gesamte Workflow kann ein wichtiger Geschäftsprozess sein. Dann sind Nachrichten der Kitt, der die einzelnen Bestandteile zusammenhält.
Eine Nachricht enthält im Allgemeinen die tatsächlichen Daten, nicht nur einen Verweis (z. B. eine ID oder URL) auf Daten. Das Senden von Daten als Teil eines Datagramms ist weniger fehleranfällig als das Senden eines Verweises. Die Benachrichtigungsarchitektur garantiert die Zustellung der Nachricht, und da keine zusätzlichen Nachschlagevorgänge erforderlich sind, wird die Nachricht zuverlässig verarbeitet. Die sendende Anwendung muss jedoch genau wissen, welche Daten enthalten sein müssen, um nicht zu viele Daten zu senden, wodurch die empfangende Komponente gezwungen wäre, unnötige Arbeiten auszuführen. In diesem Sinne sind Sender und Empfänger einer Nachricht oft durch einen strengen Datenvertrag verbunden.
In der neuen Architektur für Contoso Bicycles wird das Unternehmen bei der Erteilung einer Bestellung wahrscheinlich Nachrichten verwenden. Das Web-Front-End oder die mobile App würde eine Nachricht an die Back-End-Verarbeitungskomponenten senden. Im Back-End würden Schritte wie Weiterleitung an die dem Kunden nächstgelegene Filiale und Belastung einer Kreditkarte stattfinden.
Ereignisse
Ein Ereignis löst eine Benachrichtigung darüber aus, dass etwas passiert ist. Ereignisse sind einfacher als Nachrichten und werden am häufigsten für die Broadcastkommunikation verwendet.
Ereignisse weisen folgende Merkmale auf:
- Das Ereignis kann an mehrere Empfänger oder an gar keine Empfänger gesendet werden.
- Ereignisse sollen sich meist „weit verbreiten“ oder haben eine große Anzahl von Abonnenten für jeden Herausgeber.
- Der Ereignis-Herausgeber hat keinerlei Erwartungen hinsichtlich der Aktion, die eine empfangende Komponente ausführt.
Ihre Fahrradhandelskette würde wahrscheinlich Ereignisse verwenden, um Benutzer mittels Benachrichtigungen über Statusänderungen zu informieren. Die Statusänderungsereignisse könnten an Azure Event Grid, dann an Azure Functions und anschließend an Azure Notification Hubs gesendet werden, um eine vollständig serverlose Lösung zu erreichen.
Hierbei handelt es sich um einen wesentlichen Unterschied zwischen Ereignissen und Nachrichten, da Kommunikationsplattformen in der Regel entweder Ereignisse oder Nachrichten verarbeiten. Service Bus wurde für die Verarbeitung von Nachrichten entwickelt. Wenn Sie Ereignisse senden möchten, würden Sie sich wahrscheinlich für Event Grid entscheiden.
Azure bietet zwar auch Azure Event Hubs, aber diese Lösung wird jedoch am häufigsten für eine bestimmte Art von Kommunikation mit hohem Datenfluss für Analysen verwendet. Wenn Ihre Produktionshallen beispielsweise mit vernetzten Sensoren ausgestattet wären, könnten Sie Event Hubs in Verbindung mit Azure Stream Analytics verwenden, um nach Mustern bei Temperaturänderungen zu suchen, die auf einen unvorhergesehenen Brand oder Komponentenverschleiß hindeuten könnten.
Themen und Warteschlangen bei Service Bus
Azure Service Bus kann Nachrichten auf zwei verschiedene Arten austauschen: über Warteschlangen und Themen.
Was ist eine Warteschlange?
Eine Service Bus-Warteschlange ist ein einfacher temporärer Speicherort für Nachrichten. Eine sendende Komponente fügt der Warteschlange eine Nachricht hinzu. Eine Zielkomponente ruft die Nachricht am Anfang der Warteschlange ab. Unter normalen Umständen wird jede Nachricht von nur einem Empfänger empfangen.
Warteschlangen entkoppeln die Quell- und Zielkomponenten, um die Zielkomponenten bei einer hohen Nachfrage zu isolieren.
In Spitzenzeiten können Nachrichten schneller eintreffen, als die Zielkomponenten sie verarbeiten können. Da Quellkomponenten nicht direkt mit dem Ziel verbunden sind, ist die Quelle nicht betroffen, und die Warteschlange wächst. Zielkomponenten entfernen Nachrichten aus der Warteschlange, sobald sie in der Lage sind, diese zu verarbeiten. Wenn die Anforderungen abnehmen, können die Zielkomponenten aufholen, und die Warteschlange verkürzt sich.
Eine Warteschlange schafft bei hoher Nachfrage Abhilfe, ohne dem System Ressourcen hinzufügen zu müssen. Für Nachrichten, die schnell verarbeitet werden müssen, kann das Erstellen weiterer Instanzen der Zielkomponente jedoch die Aufteilung der Last ermöglichen. Jede Nachricht wird nur von einer Instanz verarbeitet. Dies ist eine effektive Möglichkeit, ihre gesamte Anwendung zu skalieren, indem Sie nur Ressourcen zu den Komponenten hinzufügen, die sie tatsächlich benötigen.
Was ist ein Thema?
Ein Service Bus-Thema ähnelt einer Warteschlange, aber für ein Thema kann es mehrere Abonnements geben. Dies bedeutet, dass mehrere Zielkomponenten ein bestimmtes Thema abonnieren können, sodass jede Nachricht an mehrere Empfänger übermittelt wird. Abonnements können die Nachrichten im Thema auch filtern, um nur Nachrichten zu empfangen, die relevant sind. Abonnements bieten die gleiche entkoppelten Kommunikation wie Warteschlangen und reagieren auf die gleiche Weise auf hohe Anforderungen. Verwenden Sie ein Thema, wenn jede Nachricht an mehrere Zielkomponenten übermittelt werden soll.
Hinweis
Themen werden für den Basic-Tarif nicht unterstützt.
Service Bus-Warteschlangen und Speicherwarteschlangen
Zwei Azure-Dienste weisen Nachrichtenwarteschlangen auf: Service Bus und Azure Storage. Im Allgemeinen sind Azure Storage-Warteschlangen einfacher nutzbar, aber weniger komplex und flexibel als Service Bus-Warteschlangen.
Zu den wichtigsten Vorteilen von Service Bus-Warteschlangen zählen u. a.:
- Unterstützt für Azure Storage-Warteschlangennachrichten höhere Nachrichtengrößen von 256 KB (Standard-Tarif) oder 100 MB (Premium-Tarif) pro Nachricht anstelle von 64 KB.
- Unterstützen die Zustellung nach dem Prinzip „höchstens einmal“ bzw. „mindestens einmal“. Wählen Sie zwischen einer sehr geringen Wahrscheinlichkeit, dass eine Nachricht verloren geht, oder einer sehr geringen Wahrscheinlichkeit, dass sie zweimal verarbeitet wird.
- Garantieren die FIFO-Reihenfolge (First In, First Out). Nachrichten werden in der Reihenfolge verarbeitet, in der sie hinzugefügt werden. FIFO stellt zwar den normalen Betrieb einer Warteschlange dar, das standardmäßige FIFO-Muster ändert sich jedoch, wenn die Organisation sequenzierte oder geplante Nachrichten einrichtet oder es zu Unterbrechungen wie einem Systemabsturz kommt. Weitere Informationen finden Sie unter Azure Storage-Warteschlangen und Azure Service Bus-Warteschlangen – Vergleich und Gegenüberstellung.
- Mehrere Nachrichten lassen sich in einer Transaktion gruppieren. Wenn eine Nachricht in der Transaktion nicht zugestellt werden kann, werden alle Nachrichten in der Transaktion nicht zugestellt.
- Unterstützung rollenbasierter Sicherheit.
- Sie erfordern nicht, dass Zielkomponenten die Warteschlange kontinuierlich abfragen.
Vorteile von Speicherwarteschlangen:
- Sie unterstützen eine unbegrenzte Warteschlangengröße (im Gegensatz zum Grenzwert von 80 GB bei Service Bus-Warteschlangen).
- Sie pflegen ein Protokoll aller Nachrichten.
Auswählen einer Kommunikationstechnologie
Sie haben die verschiedenen von Azure gebotenen Konzepte und Implementierungen kennengelernt. Als Nächstes sollten Sie überlegen, wie Ihr Entscheidungsprozess für jede Ihrer Kommunikationsaktivitäten aussehen sollte.
Überlegungen
Berücksichtigen Sie bei der Wahl einer Methode zum Senden und Empfangen von Nachrichten die folgenden Fragen:
Ist die Kommunikation ein Ereignis? Falls ja, sollten Sie Event Grid oder Event Hubs verwenden.
Soll eine einzelne Nachricht an mehrere Ziele übermittelt werden? Falls ja, verwenden Sie ein Service Bus-Thema. Verwenden Sie andernfalls eine Service Bus-Warteschlange.
Warteschlangen: Azure Service Bus im Vergleich zu Azure Storage
Wenn Sie feststellen, dass Sie eine Warteschlange benötigen, grenzen Sie Ihre Wahl weiter ein.
Wählen Sie in den folgenden Fällen eine Service Bus-Warteschlange:
- Sie benötigen eine Zustellungsgarantie nach dem Prinzip „höchstens einmal“.
- Sie benötigen eine FIFO-Garantie (wenn keine anderen Einstellungen die standardmäßige FIFO-Reihenfolge vorgeben).
- Sie müssen Nachrichten in Transaktionen gruppieren.
- Sie möchten Nachrichten empfangen, ohne die Warteschlange abzufragen.
- Sie benötigen rollenbasierten Warteschlangenzugriff.
- Sie müssen Nachrichten verarbeiten, die größer als 64 KB, aber kleiner als 256 KB im Standard-Tarif oder 100 MB im Premium-Tarif sind.
- Die Warteschlangengröße überschreitet 80 GB nicht.
- Sie möchten Nachrichtenbatches veröffentlichen und nutzen können.
Wählen Sie in den folgenden Fälle eine Azure Storage-Warteschlange:
- Sie benötigen eine einfache Warteschlange ohne besondere weitere Anforderungen.
- Sie benötigen serverseitige Protokolle aller Nachrichten, die die Warteschlange passieren.
- Sie gehen davon aus, dass die Größe der Warteschlange 80 GB überschreitet.
- Sie möchten den Verarbeitungsstatus einer Nachricht innerhalb der Warteschlange nachverfolgen.
Die Komponenten einer verteilten Anwendung können zwar direkt kommunizieren, doch durch Verwendung einer zwischengeschalteten Kommunikationsplattform wie Azure Event Hubs oder Azure Event Grid lässt sich häufig die Zuverlässigkeit dieser Kommunikation verbessern.
Event Hubs und Event Grid ist für Ereignisse konzipiert, die Empfänger nur über ein Ereignis informieren und nicht die diesem Ereignis zugeordneten Rohdaten enthalten. Azure Event Hubs wurde für Analyseereignisse mit hohem Datenfluss entwickelt.
Azure Service Bus und Speicherwarteschlangen sind für Nachrichten konzipiert und können zur Bindung der wesentlichen Bestandteile jedes Anwendungsworkflows verwendet werden.
Wenn Sie keine besonders komplexen Anforderungen haben, jede Nachricht nur an ein einzelnes Ziel senden oder möglichst schnell programmieren möchten, ist möglicherweise eine Speicherwarteschlange die beste Option. Andernfalls bieten Service Bus-Warteschlangen viele weitere Optionen und größere Flexibilität.
Wenn Sie Nachrichten an mehrere Abonnenten senden möchten, verwenden Sie ein Service Bus-Thema.