Bewerken

Delen via

Architecturen met meerdere lagen

Azure Storage
Azure Cloud Services
Azure Virtual Machines

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

Logisch diagram van een architectuurstijl met N-laag

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. Contractueel kan de laag hun communicatiemodellen strikt of ontspannen hebben. In het strikte model moet een aanvraag door aangrenzende lagen lopen, één voor één, en kan er geen laag tussendoor worden overgeslagen. Bijvoorbeeld van de webtoepassingsfirewall naar de weblaag, vervolgens naar middelste laag 1, enzovoort. In de ontspannen benadering kan de aanvraag daarentegen bepaalde lagen overslaan als dit nodig is. De strikte benadering heeft meer latentie en overhead en de ontspannen benadering heeft meer koppelingen en vervolgens is het moeilijker om te veranderen. Een systeem kan een hybride benadering gebruiken: waar nodig zowel ontspannen als strikte lagen hebben.

Een laag kan rechtstreeks aanroepen naar een andere laag of Asynchrone berichtpatronen gebruiken via een berichtenwachtrij. 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.
  • Een goed uitgangspunt wanneer de architectuurvereisten nog niet duidelijk zijn.
  • 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.

Vergoedingen

  • Overdraagbaarheid tussen cloud en on-premises en tussen cloudplatforms.
  • Kortere leercurve voor de meeste ontwikkelaars.
  • Relatief lage kosten door de oplossing niet opnieuw te ontwerpen
  • 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.
  • Gebruikers- en gegevensstromen omvatten doorgaans meerdere lagen, wat complexiteit toevoegt aan problemen zoals testen en waarneembaarheid.

Aanbevolen procedures

Architectuur met meerdere lagen op virtuele machines

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

Fysiek diagram van een N-tier-architectuur

Elke laag bestaat uit twee of meer VM's, 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. Hierdoor kunt u eenvoudig regels voor netwerkbeveiligingsgroepen 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 SQL Server aan om AlwaysOn-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.

Notitie

De laag met het label 'Bedrijfslaag' in ons referentiediagram is een moniker voor de bedrijfslogicalaag. Op dezelfde manier noemen we ook de presentatielaag de 'weblaag'. In ons voorbeeld is dit een webtoepassing, hoewel architecturen met meerdere lagen ook kunnen worden gebruikt voor andere topologieën (zoals bureaublad-apps). Geef uw lagen een naam die het beste werkt voor uw team om de intentie van die logische en/of fysieke laag in uw toepassing te communiceren. U kunt deze naam zelfs uitdrukken in resources die u kiest om die laag weer te geven (bijvoorbeeld vmss-appName-business-layer).

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 toestaat vanaf goedgekeurde openbare IP-adressen.

  • 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.