Freigeben über

Web-Queue-Worker Architekturstil

Azure App Service

Die Kernkomponenten dieser Architektur sind ein Web-Front-End , das Clientanforderungen bedient, und ein Worker , der ressourcenintensive Aufgaben, lange ausgeführte Workflows oder Batchaufträge ausführt. Das Web-Front-End kommuniziert mit dem Worker über eine Nachrichtenwarteschlange.

Logisches Diagramm des Architekturstils

Andere Komponenten, die häufig in diese Architektur integriert sind, umfassen:

  • Mindestens eine Datenbank.
  • Ein Cache zum Speichern von Werten aus der Datenbank für schnelle Lesevorgänge.
  • CDN zum Bereitstellen statischer Inhalte
  • Remotedienste, z. B. E-Mail- oder SMS-Dienst. Häufig werden diese Features von Dritten bereitgestellt.
  • Identitätsanbieter für die Authentifizierung.

Das Web und der Worker sind beide zustandslos. Der Sitzungsstatus kann in einem verteilten Cache gespeichert werden. Alle lang ausgeführten Arbeiten werden asynchron vom Worker ausgeführt. Der Worker kann von Nachrichten in der Warteschlange ausgelöst oder für die Batchverarbeitung auf einem Zeitplan ausgeführt werden. Der Worker ist eine optionale Komponente. Wenn es keine vorgänge mit langer Ausführung gibt, kann der Worker weggelassen werden.

Das Front-End kann aus einer Web-API bestehen. Auf clientseitiger Seite kann die Web-API von einer einzelseitigen Anwendung genutzt werden, die AJAX-Aufrufe oder eine systemeigene Clientanwendung sendet.

Wann diese Architektur verwendet werden soll

Die Web-Queue-Worker-Architektur wird in der Regel mit verwalteten Computediensten implementiert, entweder Azure App Service oder Azure Cloud Services.

Berücksichtigen Sie diesen Architekturstil für:

  • Anwendungen mit einer relativ einfachen Domäne.
  • Anwendungen mit einigen lang ausgeführten Workflows oder Batchvorgängen.
  • Wenn Sie verwaltete Dienste anstelle der Infrastruktur als Dienst (IaaS) verwenden möchten.

Vorteile

  • Relativ einfache Architektur, die leicht zu verstehen ist.
  • Einfache Bereitstellung und Verwaltung
  • Klare Trennung von Bedenken.
  • Das Front-End wird mit asynchronen Nachrichten vom Worker entkoppelt.
  • Das Front-End und der Worker können unabhängig voneinander skaliert werden.

Herausforderungen

  • Ohne sorgfältiges Design können das Front-End und der Arbeiter zu großen, monolithischen Komponenten werden, die schwer zu verwalten und zu aktualisieren sind.
  • Möglicherweise gibt es ausgeblendete Abhängigkeiten, wenn das Front-End und der Worker Datenschemas oder Codemodule freigeben.
  • Das Web-Front-End kann nach dem erfolgreichen Speichern in der Datenbank fehlfunktionieren, aber bevor die Nachrichten in die Warteschlange ausgegeben werden. Dies kann zu möglichen Konsistenzproblemen führen, da der Worker seinen Teil der Logik nicht ausführt. Techniken wie das Transaktionsausgangsmuster können verwendet werden, um dieses Problem zu minimieren, aber das Routing ausgehender Nachrichten in eine separate Warteschlange zu ändern. Eine Bibliothek, die Unterstützung für diese Technik bietet, ist die NServiceBus Transactional Session.

Bewährte Methoden

Web-Queue-Worker in Azure App Service

In diesem Abschnitt wird eine empfohlene Web-Queue-Worker Architektur beschrieben, die Azure App Service verwendet.

Physisches Diagramm des Architekturstils

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

  • Das Front-End wird als Azure App Service-Web-App implementiert, und der Worker wird als Azure Functions-App implementiert. Die Web-App und die Funktions-App sind beide einem App Service-Plan zugeordnet, der die VM-Instanzen bereitstellt.

  • Sie können entweder Azure Service Bus - oder Azure Storage-Warteschlangen für die Nachrichtenwarteschlange verwenden. (Das Diagramm zeigt eine Azure Storage-Warteschlange.)

  • Azure Cache für Redis speichert den Sitzungszustand und andere Daten, die einen geringen Latenzzugriff benötigen.

  • Azure CDN wird verwendet, um statische Inhalte wie Bilder, CSS oder HTML zwischenzuspeichern.

  • Wählen Sie für den Speicher die Speichertechnologien aus, die den Anforderungen der Anwendung am besten entsprechen. Sie können mehrere Speichertechnologien (PolyglotPersistenz) verwenden. Zur Veranschaulichung dieser Idee zeigt das Diagramm Azure SQL-Datenbank und Azure Cosmos DB.

Weitere Informationen finden Sie in der Referenzarchitektur der App Service-Webanwendung und zum Erstellen von nachrichtengesteuerten Geschäftsanwendungen mit NServiceBus und Azure Service Bus.

Weitere Überlegungen

  • Nicht jede Transaktion muss die Warteschlange und der Worker zum Speichern durchlaufen. Das Web-Front-End kann einfache Lese-/Schreibvorgänge direkt ausführen. Mitarbeiter sind für ressourcenintensive Aufgaben oder lange ausgeführte Workflows konzipiert. In einigen Fällen benötigen Sie möglicherweise keinen Arbeiter.

  • Verwenden Sie das integrierte Feature für die automatische Skalierung von App Service, um die Anzahl der VM-Instanzen zu skalieren. Wenn die Last auf der Anwendung vorhersagbare Muster folgt, verwenden Sie die zeitplanbasierte Autoskalen. Wenn die Last unvorhersehbar ist, verwenden Sie metrikbasierte Autocaling-Regeln.

  • Erwägen Sie, die Web-App und die Funktions-App in separate App Service-Pläne zu integrieren. Auf diese Weise können sie unabhängig voneinander skaliert werden.

  • Verwenden Sie separate App Service-Pläne für Die Produktion und Tests. Andernfalls bedeutet dies, dass Ihre Tests auf Ihren Produktions-VMs ausgeführt werden, wenn Sie denselben Plan für Die Produktion und Tests verwenden.

  • Verwenden Sie Bereitstellungsplätze zum Verwalten von Bereitstellungen. Mit dieser Methode können Sie eine aktualisierte Version in einem Stagingplatz bereitstellen und dann in die neue Version wechseln. Außerdem können Sie wieder mit der vorherigen Version wechseln, wenn ein Problem mit dem Update aufgetreten ist.