Freigeben über

Web-Queue-Worker Architekturstil

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

Ein logisches Diagramm, das die Web-Queue-Worker Architektur zeigt.

Die folgenden Komponenten sind häufig in diese Architektur integriert:

  • Mindestens eine Datenbank

  • Ein Cache zum Speichern von Werten aus der Datenbank für schnelle Lesevorgänge

  • Ein Netzwerk für die Inhaltsübermittlung zur Bereitstellung statischer Inhalte

  • Remotedienste wie E-Mail oder Sms (Short Message Service), die von Nicht-Microsoft-Dienstanbietern in der Regel bereitgestellt werden

  • Ein Identitätsanbieter für die Authentifizierung

Das Web und der Worker sind zustandslos, und der Sitzungszustand kann in einem verteilten Cache gespeichert werden. Der Worker bearbeitet lang andauernde Aufgaben asynchron. Nachrichten in der Warteschlange können den Worker starten, oder ein Zeitplan kann ihn für die Batchverarbeitung auslösen. Der Worker ist optional, wenn die Anwendung keine langandauernden Operationen hat.

Das Front-End kann eine Web-API enthalten. Eine einzelseitige Anwendung kann die Web-API nutzen, indem AJAX-Aufrufe getätigt werden, oder eine systemeigene Clientanwendung kann sie direkt nutzen.

Wann diese Architektur verwendet werden soll

Die Web-Queue-Worker-Architektur wird in der Regel mithilfe verwalteter Computedienste wie Azure App Service oder Azure Kubernetes Service implementiert.

Berücksichtigen Sie diese Architektur für die folgenden Anwendungsfälle:

  • Anwendungen mit einer relativ einfachen Domäne

  • Anwendungen mit langlaufenden Workflows oder Batchvorgängen

  • Szenarien, in denen Managed Services gegenüber Infrastructure as a Service (IaaS) bevorzugt werden

Vorteile

  • Eine Architektur, die einfach und einfach zu folgen ist

  • Bereitstellung und Verwaltung mit minimalem Aufwand

  • Klare Trennung von Zuständigkeiten

  • Entkopplung der Frontend- und Worker-Architektur durch asynchrones Messaging

  • Unabhängige Skalierung von Frontend und Worker

Herausforderungen

  • Ohne sorgfältiges Design kann das Front-End und der Worker zu großen monolithischen Komponenten werden, die schwer zu verwalten und zu aktualisieren sind.

  • Wenn das Front-End und der Worker Datenschemas oder Codemodule freigeben, gibt es möglicherweise ausgeblendete Abhängigkeiten.

  • Das Web-Frontend kann nach dem Speichern in der Datenbank fehlschlagen, jedoch bevor Nachrichten an die Warteschlange gesendet werden, was Konsistenzprobleme verursacht, da der Worker seinen Teil der Logik nicht ausführt. Um dieses Problem zu beheben, können Sie Techniken wie das Transaktionsausgangsmuster verwenden, bei dem ausgehende Nachrichten zunächst durch eine separate Warteschlange zurückgeleitet werden müssen. Die NServiceBus Transactional Session Library unterstützt diese Technik.

Bewährte Methoden

Web-Queue-Worker im App-Dienst

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

Diagramm, das die Architektur von Web-Queue-Worker zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

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

  • Sie können entweder Azure Service Bus - oder Azure Storage-Warteschlangen für die Nachrichtenwarteschlange verwenden. Im vorherigen Diagramm wird eine Speicherwarteschlange verwendet.

  • In Azure Managed Redis werden der Sitzungszustand und andere Daten gespeichert, für die ein Zugriff mit geringer Latenz erforderlich ist.

  • Azure Content Delivery Network wird verwendet, um statische Inhalte wie Bilder, CSS oder HTML zwischenzuspeichern.

  • Wählen Sie für den Speicher Technologien aus, die den Anforderungen Ihrer Anwendung am besten entsprechen. Dieser Ansatz, der als Polyglotpersistenz bezeichnet wird, verwendet mehrere Speichertechnologien im selben System, um unterschiedliche Anforderungen zu erfüllen. Zur Veranschaulichung dieser Idee zeigt das Diagramm sowohl azure SQL-Datenbank als auch Azure Cosmos DB.

Weitere Informationen finden Sie unter Grundkonfiguration hochverfügbarer, zonenredundanter Webanwendungen und Nachrichtengesteuerte Geschäftsanwendungen mit NServiceBus und Service Bus erstellen.

Weitere Überlegungen

  • Nicht jede Transaktion muss über die Warteschlange und den Worker zum Speicher gehen. Das Web-Front-End kann einfache Lese- und 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 die integrierte Auto-Skalierungsfunktion Ihrer Computeplattform, um die Anzahl der Instanzen zu skalieren. Wenn die Last auf der Anwendung vorhersagbare Muster befolgt, verwenden Sie die zeitplanbasierte automatische Skalierung. Wenn die Last unvorhersehbar ist, verwenden Sie die metrikbasierte automatische Skalierung.

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

  • Verwenden Sie separate App Service-Pläne für Die Produktion und Tests.

  • 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 während des Updates ein Problem auftritt.

  • Last updated on