Bewerken

Delen via

Architectuurstijl N-laag

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Een N-tier-architectuur verdeelt een toepassing in logische lagen en fysieke lagen.

logisch diagram van de architectuurstijl 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 in een lagere laag gebruiken, maar niet andersom.

Lagen worden fysiek gescheiden en worden uitgevoerd op afzonderlijke machines. 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 een andere laag aanroepen of Asynchrone berichtpatronen via een berichtenwachtrij gebruiken. Hoewel elke laag in een eigen laag kan worden gehost, is dat niet vereist. Er kunnen verschillende lagen worden gehost op dezelfde laag. Het fysiek scheiden van de lagen verbetert de schaalbaarheid en tolerantie, maar voegt ook latentie toe van 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, waarin verschillende functionaliteitsgebieden worden ingekapseld.

Een N-tier-toepassing kan een gesloten laagarchitectuur hebben of een open laagarchitectuur:

  • In een gesloten laagarchitectuur kan een laag alleen de volgende laag direct omlaag aanroepen.
  • In een open laagarchitectuur kan een laag een van de onderliggende lagen aanroepen.

Een architectuur met gesloten lagen beperkt de afhankelijkheden tussen lagen. Het kan echter onnodig netwerkverkeer creëren, als één laag alleen aanvragen doorgeeft aan de volgende laag.

Wanneer u deze architectuur gebruikt

Architecturen met N-lagen worden doorgaans geïmplementeerd als IaaS-toepassingen (Infrastructure-as-Service), waarbij elke laag wordt uitgevoerd op een afzonderlijke set virtuele machines. Een N-tier-toepassing hoeft echter geen pure IaaS te zijn. Vaak is het handig om beheerde services te gebruiken voor sommige onderdelen van de architectuur, met name caching, berichten en gegevensopslag.

Overweeg een N-tier-architectuur voor:

  • Eenvoudige webtoepassingen.
  • Een goed uitgangspunt wanneer de architectuurvereisten nog niet duidelijk zijn.
  • Een on-premises toepassing migreren naar Azure met minimale herstructurering.
  • Geïntegreerde ontwikkeling van on-premises en cloudtoepassingen.

Architecturen met N-lagen zijn zeer gebruikelijk in traditionele on-premises toepassingen, dus het is natuurlijk geschikt voor het migreren van bestaande workloads naar Azure.

Voordelen

  • Portabiliteit tussen cloud en on-premises, en tussen cloudplatforms.
  • Minder leercurve voor de meeste ontwikkelaars.
  • Relatief lage kosten door de oplossing niet opnieuw te ontwerpen
  • Natuurlijke evolutie van het traditionele toepassingsmodel.
  • Open voor heterogene omgeving (Windows/Linux)

Uitdagingen

  • Het is eenvoudig om te eindigen met een middelste laag die alleen CRUD-bewerkingen op de database uitvoert, waardoor u extra latentie toevoegt zonder nuttig werk te doen.
  • Monolithisch ontwerp voorkomt onafhankelijke implementatie van functies.
  • Het beheren 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 N-lagen op virtuele machines

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

fysiek diagram van een architectuur met N-lagen

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 voor het distribueren van aanvragen over de VM's in een laag. Een laag kan horizontaal worden geschaald door meer VM's toe te voegen aan de pool.

Elke laag wordt ook in een eigen subnet geplaatst, wat betekent dat hun 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 verwerken. De gegevenslaag moet bestaan uit een gerepliceerde database. Voor Windows raden we SQL Server aan om AlwaysOn-beschikbaarheidsgroepen te gebruiken voor hoge beschikbaarheid. Kies voor Linux een database die replicatie ondersteunt, zoals Apache Cassandra.

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

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 N-lagen zijn niet beperkt tot drie lagen. Voor complexere toepassingen is het gebruikelijk om meer lagen te hebben. In dat geval kunt u overwegen laag-7-routering te gebruiken om aanvragen naar een bepaalde laag te routeren.

  • Lagen vormen de grens van schaalbaarheid, betrouwbaarheid en beveiliging. Overweeg om afzonderlijke lagen voor services met verschillende vereisten in deze gebieden te hebben.

  • Virtuele-machineschaalsets gebruiken voor automatisch schalen.

  • Zoek naar plaatsen in de architectuur waar u een beheerde service kunt gebruiken zonder dat u belangrijke herstructureringen hoeft uit te voeren. Kijk met name naar caching, berichten, opslag en databases.

  • Voor een hogere beveiliging plaatst u een netwerk-DMZ vóór de toepassing. De DMZ bevat virtuele netwerkapparaten (NVA's) die beveiligingsfunctionaliteit implementeren, zoals firewalls en pakketinspectie. Zie Netwerk DMZ-referentiearchitectuurvoor meer informatie.

  • Voor hoge beschikbaarheid plaatst u twee of meer NVA's in een beschikbaarheidsset, met een externe load balancer om internetaanvragen over de exemplaren te distribueren. Zie Virtuele netwerkapparaten met hoge beschikbaarheid implementerenvoor meer informatie.

  • Sta directe RDP- of SSH-toegang niet 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 VIRTUELE machine 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 met behulp van een site-naar-site virtueel particulier netwerk (VPN) of Azure ExpressRoute. Zie referentiearchitectuur voor hybride netwerkenvoor meer informatie.

  • Als uw organisatie Gebruikmaakt van Active Directory voor het beheren van identiteiten, kunt u uw Active Directory-omgeving uitbreiden naar het Azure VNet. Zie Referentiearchitectuur voor identiteitsbeheervoor meer informatie.

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