Die Hauptkomponenten dieser Architektur sind ein Web-Front-End, mit dem Clientanforderungen bereitgestellt werden, und ein Worker, der ressourcenintensive Aufgaben, Workflows mit langer Ausführungsdauer oder Batchaufträge durchführt. Das Web-Front-End kommuniziert mit dem Worker über eine Nachrichtenwarteschlange.
Andere Komponenten, die häufig in diese Architektur eingebunden werden, sind:
- Eine oder mehrere Datenbanken
- Ein Cache zum Speichern von Werten aus der Datenbank, um schnelle Lesevorgänge zu ermöglichen
- CDN zur Bereitstellung von statischem Inhalt
- Remotedienste, z.B. E-Mail- oder SMS-Dienst Häufig werden diese Features von Drittanbietern bereitgestellt.
- Identitätsanbieter für die Authentifizierung
Web und Worker sind jeweils zustandslos. Der Sitzungsstatus kann in einem verteilten Cache zwischengespeichert werden. Alle Vorgänge mit langer Ausführungsdauer werden asynchron vom Worker durchgeführt. Der Worker kann über Nachrichten in der Warteschlange ausgelöst oder nach einem Zeitplan für die Batchverarbeitung ausgeführt werden. Der Worker ist eine optionale Komponente. Wenn keine Vorgänge mit langer Ausführungsdauer vorhanden sind, kann der Worker weggelassen werden.
Das Front-End kann aus einer Web-API bestehen. Auf Clientseite kann die Web-API von einer Single-Page-Anwendung, die AJAX-Aufrufe durchführt, oder von einer nativen Clientanwendung genutzt werden.
Einsatzmöglichkeiten für diese Architektur
Die Architektur „Web-Warteschlange-Worker“ wird häufig mit verwalteten Computediensten implementiert (entweder Azure App Service oder Azure Cloud Services).
Ziehen Sie diese Art von Architektur in folgenden Fällen in Betracht:
- Anwendungen mit einer relativ einfachen Domäne
- Anwendungen mit Workflows mit langer Ausführungsdauer oder Batchvorgängen
- Bei Verwendung von verwalteten Diensten anstelle von IaaS (Infrastructure-as-a-Service).
Vorteile
- Relativ einfache Architektur, die leicht zu verstehen ist
- Einfache Bereitstellung und Verwaltung
- Klare Trennung von Zuständigkeiten
- Das Front-End ist vom Worker per asynchronem Messaging entkoppelt
- Front-End und Worker können unabhängig voneinander skaliert werden
Herausforderungen
- Ohne eine sorgfältige Vorgehensweise beim Entwerfen können das Front-End und der Worker zu großen, monolithischen Komponenten werden, die schwierig zu verwalten und zu aktualisieren sind.
- Es können versteckte Abhängigkeiten vorhanden sein, wenn das Front-End und der Worker Datenschemas oder Codemodule gemeinsam nutzen.
- Für das Web-Front-End können nach dem erfolgreichen persistenten Speichern in die Datenbank, aber noch vor Ausgabe der Nachrichten in die Warteschlange, Fehler auftreten. Dies kann zu möglichen Konsistenzproblemen führen, da der Worker seinen Teil der Logik nicht ausführt. Methoden wie das Transaktionsausgangsmuster können verwendet werden, um dieses Problem zu beheben, jedoch ist eine Änderung des Routings ausgehender Nachrichten erforderlich, um zunächst ein „Loopback“ über eine separate Warteschlange auszuführen. Eine Bibliothek, die Unterstützung für diese Methode bietet, heißt NServiceBus Transactional Session.
Bewährte Methoden
- Machen Sie für den Client eine sorgfältig entworfene API verfügbar. Weitere Informationen finden Sie unter Bewährte Methoden beim API-Design.
- Führen Sie die automatische Skalierung durch, um Änderungen der Last zu bewältigen. Weitere Informationen finden Sie unter Bewährte Methoden bei der automatischen Skalierung.
- Speichern Sie halbstatische Daten zwischen. Weitere Informationen finden Sie unter Bewährte Methoden beim Caching.
- Verwenden Sie ein CDN zum Hosten von statischem Inhalt. Weitere Informationen finden Sie unter Bewährte Methoden für CDNs.
- Verwenden Sie „Polyglot Persistence“, falls zutreffend. Weitere Informationen finden Sie unter [Verwenden des besten Datenspeichers für den Auftrag][polyglot].
- Partitionieren Sie Daten, um die Skalierbarkeit zu verbessern, Konflikte zu reduzieren und die Leistung zu optimieren. Weitere Informationen finden Sie unter Bewährte Methoden bei der Datenpartitionierung.
Web-Warteschlange-Worker in Azure App Service
In diesem Abschnitt wird eine empfohlene Architektur vom Typ „Web-Warteschlange-Worker“ beschrieben, für die Azure App Service verwendet wird.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Das Front-End wird als Web-App vom Typ Azure App Service und der Worker als App vom Typ Azure Functions implementiert. Die Web-App und Funktions-App werden beide einem App Service-Plan zugeordnet, über den die VM-Instanzen bereitgestellt werden.
Sie können entweder Azure Service Bus- oder Azure Storage-Warteschlangen als Nachrichtenwarteschlange verwenden. (Im Diagramm ist eine Azure Storage-Warteschlange dargestellt.)
Azure Cache for Redis speichert den Sitzungszustand und andere Daten, für die Zugriff mit geringer Wartezeit erforderlich ist.
Azure CDN wird verwendet, um statische Inhalte wie Bilder, CSS oder HTML zwischenzuspeichern.
Wählen Sie für die Speicherung die Speichertechnologie aus, mit der die Anforderungen der Anwendung am besten erfüllt werden. Sie können auch mehrere Speichertechnologien („Polyglot Persistence“) verwenden. Zur Verdeutlichung sind im Diagramm die Komponenten Azure SQL-Datenbank und Azure Cosmos DB dargestellt.
Weitere Informationen finden Sie in der Referenzarchitektur für App Service-Webanwendungen sowie unter Erstellen von nachrichtengesteuerten Geschäftsanwendungen mit NServiceBus und Azure Service Bus.
Weitere Überlegungen
Nicht jede Transaktion muss über die Warteschlange und den Worker in den Speicher verlaufen. Das Web-Front-End kann einfache Lese- und Schreibvorgänge direkt durchführen. Worker sind für ressourcenintensive Aufgaben oder Workflows mit langer Ausführungsdauer ausgelegt. In einigen Fällen benötigen Sie unter Umständen gar keinen Worker.
Verwenden Sie die integrierte App Service-Funktion für die automatische Skalierung, um für die Anzahl von VM-Instanzen das horizontale Hochskalieren durchzuführen. Verwenden Sie die automatische Skalierung nach Zeitplan, wenn die Last der Anwendung vorhersagbaren Mustern folgt. Falls die Last nicht vorhersagbar ist, sollten Sie auf Metriken basierende Regeln für die automatische Skalierung nutzen.
Erwägen Sie, die Web-App und Funktions-App in getrennten App Service-Plänen anzuordnen. Auf diese Weise können sie unabhängig voneinander skaliert werden.
Verwenden Sie separate App Service-Pläne für die Produktion und für das Testen. Wenn Sie denselben Plan verwenden, bedeutet dies sonst, dass Ihre Tests auf den VMs für die Produktion durchgeführt werden.
Verwenden Sie Bereitstellungsslots, um die Bereitstellungen zu verwalten. Mit diese Methode stellen Sie eine aktualisierte Version in einem Stagingslot bereit und wechseln dann zur neuen Version. Außerdem können Sie zurück zur vorherigen Version wechseln, falls ein Problem mit dem Update auftritt.