ArchitectuurstijlQueue-Worker web
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.
Andere onderdelen die vaak in deze architectuur worden opgenomen, zijn onder andere:
- Een of meer databases.
- Een cache voor het opslaan van waarden uit de database voor snelle leesbewerkingen.
- CDN voor statische inhoud
- Externe services, zoals e-mail of sms-service. Deze functies worden vaak geleverd door derden.
- Id-provider voor verificatie.
Het web en de werkrol zijn beide staatloos. Sessiestatus kan worden opgeslagen in een gedistribueerde cache. Langlopend werk wordt asynchroon uitgevoerd door de werkrol. De werkrol kan worden geactiveerd door berichten in de wachtrij of worden uitgevoerd volgens een schema voor batchverwerking. De werkrol is een optioneel onderdeel. Als er geen langdurige bewerkingen zijn, kan de werkrol worden weggelaten.
De front-end kan bestaan uit een web-API. Aan de clientzijde kan de web-API worden gebruikt door een toepassing met één pagina die AJAX-aanroepen of door een systeemeigen clienttoepassing maakt.
Wanneer u deze architectuur gebruikt
De web-Queue-Worker-architectuur wordt doorgaans geïmplementeerd met behulp van beheerde rekenservices, Azure App Service of Azure Cloud Services.
Houd rekening met deze architectuurstijl voor:
- Toepassingen met een relatief eenvoudig domein.
- Toepassingen met langlopende werkstromen of batchbewerkingen.
- Wanneer u beheerde services wilt gebruiken in plaats van IaaS (Infrastructure as a Service).
Voordelen
- Relatief eenvoudige architectuur die gemakkelijk te begrijpen is.
- Eenvoudig te implementeren en beheren.
- Duidelijke scheiding van zorgen.
- De front-end wordt losgekoppeld van de werkrol met behulp van asynchrone berichten.
- De front-end en de werkrol kunnen onafhankelijk worden geschaald.
Uitdagingen
- Zonder zorgvuldig ontwerp kunnen de front-end en de werkrol grote, monolithische onderdelen worden die moeilijk te onderhouden en bij te werken zijn.
- Er kunnen verborgen afhankelijkheden zijn, als de front-end en werkrol gegevensschema's of codemodules delen.
- De web-front-end kan defect raken nadat de database is behouden, maar voordat de berichten naar de wachtrij worden verzonden. Dit kan leiden tot mogelijke consistentieproblemen, omdat de werkrol het onderdeel van de logica niet uitvoert. Technieken zoals het transactionele postvak UIT-patroon kunnen worden gebruikt om dit probleem te verhelpen, maar vereisen dat de routering van uitgaande berichten eerst wordt gewijzigd in een afzonderlijke wachtrij. Een bibliotheek die ondersteuning biedt voor deze techniek is de NServiceBus Transactionele sessie.
Beste praktijken
- Een goed ontworpen API beschikbaar maken voor de client. Zie best practices voor API-ontwerp.
- Automatisch schalen om wijzigingen in de belasting te verwerken. Zie aanbevolen procedures voor automatisch schalen.
- Semi-statische gegevens in de cache opslaan. Zie aanbevolen procedures voor opslaan in cache.
- Gebruik een CDN om statische inhoud te hosten. Zie best practices voor CDN.
- Gebruik polyglotpersistentie indien van toepassing. Zie [Gebruik het beste gegevensarchief voor de taak][polyglot].
- Partitioneer gegevens om de schaalbaarheid te verbeteren, conflicten te verminderen en de prestaties te optimaliseren. Zie best practices voor gegevenspartitionering.
Web-Queue-Worker in Azure App Service
In deze sectie wordt een aanbevolen web-Queue-Worker-architectuur beschreven die gebruikmaakt van Azure App Service.
Een Visio-bestand van deze architectuur downloaden.
Werkproces
De front-end wordt geïmplementeerd als een Azure App Service-web-app en de werkrol wordt geïmplementeerd als een Azure Functions-app . De web-app en de functie-app zijn beide gekoppeld aan een App Service-plan dat de VM-exemplaren levert.
U kunt Azure Service Bus - of Azure Storage-wachtrijen gebruiken voor de berichtenwachtrij. (In het diagram ziet u een Azure Storage-wachtrij.)
Azure Cache voor Redis slaat de sessiestatus en andere gegevens op die toegang met lage latentie nodig hebben.
Azure CDN wordt gebruikt voor het opslaan van statische inhoud, zoals afbeeldingen, CSS of HTML.
Kies voor opslag de opslagtechnologieën die het beste aansluiten bij de behoeften van de toepassing. U kunt meerdere opslagtechnologieën (polyglot persistence) gebruiken. Ter illustratie van dit idee toont het diagram Azure SQL Database en Azure Cosmos DB.
Zie de referentiearchitectuur van de App Service-webtoepassing en het bouwen van berichtgestuurde bedrijfstoepassingen met NServiceBus en Azure Service Bus voor meer informatie.
Andere overwegingen
Niet elke transactie moet via de wachtrij en werkrol naar de opslag gaan. De webfront-end kan eenvoudige lees-/schrijfbewerkingen rechtstreeks uitvoeren. Werkrollen zijn ontworpen voor resource-intensieve taken of langlopende werkstromen. In sommige gevallen hebt u mogelijk helemaal geen werknemer nodig.
Gebruik de ingebouwde functie voor automatische schaalaanpassing van App Service om het aantal VM-exemplaren uit te schalen. Als de belasting van de toepassing voorspelbare patronen volgt, gebruikt u automatisch schalen op basis van schema's. Als de belasting onvoorspelbaar is, gebruikt u regels voor automatisch schalen op basis van metrische gegevens.
Overweeg om de web-app en de functie-app in afzonderlijke App Service-plannen te plaatsen. Op die manier kunnen ze onafhankelijk worden geschaald.
Gebruik afzonderlijke App Service-plannen voor productie en testen. Als u anders hetzelfde plan gebruikt voor productie en testen, betekent dit dat uw tests worden uitgevoerd op uw productie-VM's.
Gebruik implementatiesites om implementaties 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 met de update.