De belangrijkste onderdelen van deze architectuur zijn een web-front-end, die aanvragen van clients verzorgt, en een werkrol die bronintensieve taken, langlopende werkstromen of batchtaken uitvoert. De web-front-end communiceert via een berichtenwachtrij met de werkrol.
Andere onderdelen die gewoonlijk in deze architectuur zijn opgenomen, zijn onder andere:
- Een of meer databases.
- Een cache voor het opslaan van waarden uit de database om snelle leesbewerkingen uit te voeren.
- CDN voor het leveren van statische inhoud
- Externe services, zoals e-mail of sms. Deze functies worden vaak geleverd door derden.
- Id-provider voor verificatie.
De web-front-end en de werkrol zijn beide staatloos. Sessiestatus kan worden opgeslagen in een gedistribueerde cache. Langlopende bewerkingen worden asynchroon door de werkrol uitgevoerd. De werkrol kan worden geactiveerd door berichten in de wachtrij of aan de hand van een schema voor batchverwerking worden uitgevoerd. De werkrol is een optioneel onderdeel. Als er geen langlopende bewerkingen zijn, kan de werkrol worden weggelaten.
De front-end kan uit een web-API bestaan. Aan de client-zijde kan de web-API worden gebruikt door een toepassing met één pagina die AJAX-aanroepen uitvoert, of door een systeemeigen clienttoepassing.
Wanneer gebruikt u deze architectuur?
De Werkrol-voor-webwachtrij-architectuur wordt gewoonlijk geïmplementeerd met behulp van beheerde rekenservices. Dat kan Azure App Service of Azure Cloud Services zijn.
Deze architectuurstijl is geschikt voor:
- Toepassingen met een relatief eenvoudig domein.
- Toepassingen met enige langlopende werkstromen of batchbewerkingen.
- Als u beheerde services wilt gebruiken in plaats van infrastructuur als een dienst (IaaS).
Vergoedingen
- Relatief eenvoudige architectuur, die gemakkelijk te begrijpen is.
- Eenvoudig te implementeren en beheren.
- Duidelijke scheiding van taken.
- De front-end is losgekoppeld van de werkrol dankzij 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 de 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.
Aanbevolen procedures
- Maak een goed ontworpen API voor de client beschikbaar. Zie Aanbevolen procedures voor API-ontwerp.
- Pas automatisch schalen toe om wijzigingen in de belasting te verwerken. Zie Aanbevolen procedures voor automatisch schalen.
- Plaats semi-statische gegevens in de cache. Zie Aanbevolen procedures voor caching.
- Gebruik een CDN om statische inhoud te hosten. Aanbevolen procedures voor het gebruik van netwerken voor contentlevering (CDN).
- Gebruik zo mogelijk meertalige persistentie. Zie [Gebruik het beste gegevensarchief voor de taak][polyglot].
- Partitioneren van gegevens kan helpen de schaalbaarheid te verbeteren, conflicten te verminderen en de prestaties te optimaliseren. Gegevenspartitionering.
Werkrol-voor-webwachtrij in Azure App Service
In deze sectie wordt een aanbevolen Werkrol-voor-webwachtrij-architectuur beschreven die gebruikmaakt van Azure App Service.
Een Visio-bestand van deze architectuur downloaden.
Werkstroom
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. (Het diagram toont een Azure Storage-wachtrij.)
Azure Cache voor Redis sessiestatus en andere gegevens opslaat die toegang met lage latentie nodig hebben.
Azure CDN wordt gebruikt voor het opslaan van statische inhoud, zoals afbeeldingen, CSS of HTML.
Kies als opslag de opslagtechnologieën die het best passen bij de behoeften van de toepassing. U kunt gebruikmaken van meerdere opslagtechnologieën (meertalige persistentie). 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 hoeft via de wachtrij en de werkrol naar de opslag te gaan. De web-front-end kan eenvoudige lees-/schrijfbewerkingen rechtstreeks uitvoeren. Werkrollen zijn ontworpen voor resource-intensieve taken of langlopende werkstromen. In sommige gevallen heeft u niet eens een werkrol nodig.
Gebruik de ingebouwde functie van App Service om het aantal VM-exemplaren uit te schalen. Als de belasting op de toepassing een voorspelbaar patroon volgt, gebruikt u automatisch schalen op basis van een schema. Als de belasting niet voorspelbaar 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 namelijk hetzelfde plan gebruikt voor productie en testen, dan worden de tests uitgevoerd op uw productie-VM's.
Gebruik implementatieslots 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 er ook mee teruggaan naar de vorige versie als de update problemen heeft opgeleverd.