Architecturen met meerdere lagen

Met een n-laag-architectuur verdeelt u een toepassing in logische lagen en fysieke lagen.

Lagen zijn een manier om verantwoordelijkheden te scheiden en afhankelijkheden te beheren. Elke laag heeft een specifieke verantwoordelijkheid. Een hogere laag kan services uit een lagere laag gebruiken, maar niet andersom.

Lagen worden fysiek gescheiden en worden uitgevoerd op afzonderlijke computers. Een laag kan ook rechtstreeks een andere laag aanroepen of asynchrone berichten (berichtenwachtrij) gebruiken. Hoewel elke laag kan worden gehost in een eigen laag, is dit niet vereist. Meerdere lagen kunnen worden gehost in dezelfde laag. Door lagen fysiek te scheiden verbetert u de schaalbaarheid en tolerantie, maar neemt ook de latentie toe vanwege de extra netwerkcommunicatie.

Een traditionele toepassing met drie lagen heeft een presentatielaag, een middelste laag en een databaselaag. De middelste laag is optioneel. Complexere toepassingen kunnen meer dan drie lagen hebben. In het bovenstaande diagram ziet u een toepassing met twee middelste lagen die verschillende soorten functionaliteit omvatten.

Een toepassing met meerdere lagen kan een architectuur met gesloten lagen of een architectuur met open lagen hebben:

• In een architectuur met gesloten lagen kan een laag alleen de volgende laag direct eronder aanroepen.
• In een architectuur met open lagen kan een laag elk van de lagen eronder aanroepen.

Een architectuur met gesloten lagen beperkt de afhankelijkheden tussen lagen. Dit kan echter onnodig netwerkverkeer veroorzaken wanneer één laag enkel aanvragen doorgeeft naar de volgende laag.

Wanneer gebruikt u deze architectuur?

Architecturen met meerdere lagen worden doorgaans geïmplementeerd als IaaS-toepassingen (infrastructuur als een service), waarbij elke laag wordt uitgevoerd in een afzonderlijke set VM's. Een toepassing met meerdere lagen hoeft echter geen pure IaaS te zijn. Vaak is het gunstiger om beheerde services te gebruiken voor sommige onderdelen van de architectuur, met name voor caching, berichten en gegevensopslag.

Overweeg een n-laag-architectuur voor:

• Eenvoudige webtoepassingen.
• Het migreren van een on-premises toepassing naar Azure met minimale herstructurering.
• Eenvormige ontwikkeling van on-premises en cloudtoepassingen.

Architecturen met meerdere lagen zijn heel gebruikelijk in traditionele on-premises toepassingen, dus deze liggen voor de hand om bestaande workloads naar Azure te migreren.

Voordelen

• Overdraagbaarheid tussen cloud en on-premises en tussen cloudplatforms.
• Kortere leercurve voor de meeste ontwikkelaars.
• Natuurlijke ontwikkeling van het traditionele toepassingsmodel.
• Open voor heterogene omgeving (Windows/Linux)

Uitdagingen

• Het kan makkelijk gebeuren dat u eindigt met een middelste laag die enkel CRUD-bewerkingen in de database uitvoert, wat leidt tot extra latentie zonder dat deze laag nuttig werk doet.
• Monolithisch ontwerp voorkomt onafhankelijke implementatie van functies.
• Het beheer van een IaaS-toepassing is meer werk dan een toepassing die alleen beheerde services gebruikt.
• Het kan lastig zijn om netwerkbeveiliging in een groot systeem te beheren.

Aanbevolen procedures

• Gebruik automatisch schalen om wijzigingen in de belasting te verwerken. Zie Aanbevolen procedures voor automatisch schalen.
• Gebruik asynchrone berichten om lagen los tekoppelen.
• Semistatische gegevens in de cache opslaan. Zie Aanbevolen procedures voor caching.
• Configureer de databaselaag voor hoge beschikbaarheid met behulp van een oplossing zoals SQL Server Always On-beschikbaarheidsgroepen.
• Plaats een Web Application Firewall (WAF) tussen de front-end en internet.
• Plaats elke laag in een eigen subnet en gebruik subnetten als beveiligingsgrens.
• Beperk toegang tot de gegevenslaag door aanvragen van de middelste laag of lagen toe te staan.

Architectuur met meerdere lagen op virtuele machines

In deze sectie wordt een aanbevolen architectuur met meerdere lagen beschreven die wordt uitgevoerd op VM's.

Elke laag bestaat uit twee of meer virtuele machines, geplaatst in een beschikbaarheidsset of virtuele-machineschaalset. Meerdere VM's bieden tolerantie voor het geval één VM uitvalt. Load balancers worden gebruikt om aanvragen te verdelen over de VM's in een laag. U kunt een laag horizontaal schalen door meer VM's toe te voegen aan de pool.

Elke laag wordt ook in een eigen subnet geplaatst, wat betekent dat interne IP-adressen binnen hetzelfde adresbereik vallen. Zo kunt u eenvoudig regels voor netwerkbeveiligingsgroep en routetabellen toepassen op afzonderlijke lagen.

De web- en bedrijfslagen zijn staatloos. Elke VM kan elke aanvraag voor die laag afhandelen. De gegevenslaag moet bestaan uit een gerepliceerde database. Voor Windows raden we u aan om SQL Server Always On-beschikbaarheidsgroepen te gebruiken voor hoge beschikbaarheid. Voor Linux kiest u een database die replicatie ondersteunt, zoals Apache Cassandra.

Netwerkbeveiligingsgroepen beperken de toegang tot elke laag. De databaselaag staat bijvoorbeeld alleen toegang vanaf de bedrijfslaag toe.

Voor meer informatie over het uitvoeren van toepassingen met meerdere lagen in Azure:

• Windows-VM's uitvoeren voor een toepassing met meerdere lagen
• Windows N-tier-toepassing in Azure met SQL Server
• Microsoft Learn module: Een rondleiding door de architectuurstijl met meerdere lagen
• Azure Bastion

Aanvullende overwegingen

• Architecturen met meerdere lagen zijn niet beperkt tot drie lagen. Voor complexere toepassingen is het gangbaar om meer lagen te gebruiken. In dat geval kunt u overwegen laag-7 routering te gebruiken om aanvragen door te sturen naar een bepaalde laag.

• Lagen vormen de grens voor schaalbaarheid, betrouwbaarheid en beveiliging. Overweeg afzonderlijke lagen te gebruiken voor services met verschillende vereisten op die gebieden.

• Virtuele-machineschaalsets gebruiken voor automatisch schalen.

• Zoek naar plaatsen in de architectuur waar u een beheerde service kunt gebruiken zonder ingrijpende herstructurering. Let met name op caching, berichten, opslag en databases.

• Voor een betere beveiliging plaatst u een netwerk-DMZ vóór de toepassing. De DMZ omvat virtuele netwerkapparaten (NVA's) die beveiligingsfunctionaliteit, zoals firewalls en pakketinspecties, implementeren. Zie Referentiearchitectuur voor netwerk-DMZ voor meer informatie.

• Voor een hogere beschikbaarheid plaatst u twee of meer NVA's in een beschikbaarheidsset met een externe load balancer die internetaanvragen verdeelt over de exemplaren. Zie Virtuele netwerkapparaten met hoge beschikbaarheid implementeren voor meer informatie.

• Sta geen directe RDP- of SSH-toegang toe tot VM's waarop toepassingscode wordt uitgevoerd. In plaats daarvan moeten operators zich aanmelden bij een jumpbox, ook wel een bastionhost genoemd. Dit is een VM in het netwerk die beheerders gebruiken om verbinding te maken met de andere VM's. De jumpbox heeft een netwerkbeveiligingsgroep die RDP of SSH alleen van goedgekeurde openbare IP-adressen toestaat.

• U kunt het virtuele Azure-netwerk uitbreiden naar uw on-premises netwerk via een site-naar-site virtueel particulier netwerk (VPN) of Azure ExpressRoute. Zie Referentiearchitectuur voor hybride netwerk voor meer informatie.

• Als uw organisatie Active Directory gebruikt om identiteit te beheren, wilt u uw Active Directory-omgeving mogelijk uitbreiden naar het Azure VNet. Zie Referentiearchitectuur voor identiteitsbeheer voor meer informatie.

• Als u een hogere beschikbaarheid nodig hebt dan de Azure-SLA voor VM's biedt, repliceert u de toepassing tussen twee regio's en gebruikt u Azure Traffic Manager voor failover. Zie Windows-VM's uitvoeren in meerdere regio’s of Linux-VM's uitvoeren in meerdere regio's voor meer informatie.