Delen via

Web-Queue-Worker-architectuurstijl

De belangrijkste onderdelen van deze architectuur zijn een webfront-end die clientaanvragen verwerkt en een werkrol die resource-intensieve taken, langlopende werkstromen of batchtaken uitvoert. De webfront-end communiceert met de werkrol via een berichtenwachtrij.

Een logisch diagram met de web-Queue-Worker-architectuur.

De volgende onderdelen zijn doorgaans opgenomen in deze architectuur:

  • Een of meer databases

  • Een cache voor het opslaan van waarden uit de database voor snelle leesbewerkingen

  • Een netwerk voor contentlevering voor statische inhoud

  • Externe services, zoals e-mail of Short Message Service (SMS), die niet-Microsoft-serviceproviders doorgaans bieden

  • Een id-provider voor verificatie

Het web en de worker zijn beide staatloos, en de sessiestatus kan worden opgeslagen in een gedistribueerde cache. De taakverwerker verwerkt langdurige taken asynchroon. Berichten in de wachtrij kunnen de werknemer starten, of een schema kan deze uitvoeren voor batchverwerking. De werknemer is optioneel als de toepassing geen langlopende bewerkingen heeft.

De front-end kan een web-API bevatten. Een toepassing met één pagina kan de web-API gebruiken door asynchrone HTTP-aanvragen te maken, of een systeemeigen clienttoepassing kan deze rechtstreeks gebruiken.

Wanneer u deze architectuur gebruikt

De web-Queue-Worker-architectuur wordt doorgaans geïmplementeerd met behulp van beheerde rekenservices zoals Azure App Service, Azure Kubernetes Service of Azure Container Apps.

Houd rekening met deze architectuur voor de volgende gebruiksvoorbeelden:

  • Toepassingen met een relatief eenvoudig domein

  • Toepassingen met langlopende werkstromen of batchbewerkingen

  • Scenario's waarin u de voorkeur geeft aan beheerde services via IaaS (Infrastructure as a Service)

Voordelen

  • Een architectuur die eenvoudig en eenvoudig te volgen is

  • Implementatie en beheer met minimale inspanning

  • Duidelijke scheiding van verantwoordelijkheden

  • Ontkoppeling van de front-end en werkrol via asynchrone berichten

  • Onafhankelijk schalen van de front-end en werkrol

Uitdagingen

  • Zonder zorgvuldig ontwerp kunnen de frontend en de werkkracht uitgroeien tot grote monolithische componenten die moeilijk te onderhouden en te updaten zijn.

  • Er kunnen verborgen afhankelijkheden zijn als de front-end en de worker gegevensschema's of codemodules delen.

  • De webfront-end kan mislukken nadat deze zich in de database bevindt, maar voordat berichten naar de wachtrij worden verzonden. Dit veroorzaakt consistentieproblemen omdat de worker zijn deel van de logica niet uitvoert. Om dit probleem te verhelpen, kunt u technieken zoals het Transactional Outbox-patroon gebruiken. Hiervoor moeten uitgaande berichten eerst teruggaan via een afzonderlijke wachtrij. De NServiceBus Transactional Session Library ondersteunt deze techniek.

Beste praktijken

Web-Queue-Worker in App Service

In deze sectie wordt een aanbevolen web-Queue-Worker-architectuur beschreven die gebruikmaakt van App Service.

Diagram dat de Web-Queue-Worker-architectuur toont.

Een Visio-bestand van deze architectuur downloaden.

Werkproces

  • De front-end wordt geïmplementeerd als een App Service-web-app, en de worker wordt geïmplementeerd als een Azure Functions-app. De web-app en de Functions-app zijn beide gekoppeld aan een App Service-plan.

  • U kunt Azure Service Bus - of Azure Storage-wachtrijen gebruiken voor de berichtenwachtrij. In het vorige diagram wordt een opslagwachtrij gebruikt.

  • Azure Managed Redis slaat de sessiestatus en andere gegevens op waarvoor toegang met lage latentie is vereist.

  • Azure Content Delivery Network wordt gebruikt om statische inhoud in de cache op te cachen, zoals afbeeldingen, CSS of HTML.

  • Kies voor opslag technologieën die het beste aansluiten bij de behoeften van uw toepassing. Deze benadering, ook wel polyglot persistence genoemd, maakt gebruik van meerdere opslagtechnologieën in hetzelfde systeem om aan verschillende vereisten te voldoen. Ter illustratie van dit idee toont het diagram zowel Azure SQL Database als Azure Cosmos DB.

Zie Basislijn voor maximaal beschikbare zone-redundante webtoepassing en berichtgestuurde bedrijfstoepassingen bouwen met NServiceBus en Service Bus voor meer informatie.

Andere overwegingen

  • Niet elke transactie hoeft via de wachtrij en werknemer naar de opslag te gaan. De webfront-end kan eenvoudige lees- en schrijfbewerkingen rechtstreeks uitvoeren. Werkers zijn ontworpen voor resource-intensieve taken of langdurige werkstromen. In sommige gevallen hebt u mogelijk helemaal geen werknemer nodig.

  • Schaal het aantal exemplaren uit met behulp van de ingebouwde functie voor automatische schaalaanpassing van uw rekenplatform. Als de belasting van de toepassing voorspelbare patronen volgt, gebruikt u auto-scaling op basis van een schema. Als de belasting onvoorspelbaar is, gebruikt u automatisch schalen op basis van metrische gegevens.

  • Overweeg om de web-app en de Functions-app in afzonderlijke App Service-abonnementen te plaatsen, zodat ze onafhankelijk van elkaar kunnen worden geschaald.

  • Gebruik afzonderlijke App Service-plannen voor productie en testen.

  • Gebruik implementatieslots om implementaties voor App Service-plannen te beheren. Met deze methode kunt u een bijgewerkte versie implementeren naar een staging-site en vervolgens overschakelen naar de nieuwe versie. U kunt ook terugschakelen naar de vorige versie als er een probleem is tijdens de update.

  • Last updated on