Overwegingen voor n-laag-architecturen
We hebben gekeken naar wat een N-laag-architectuur is en we hebben een voorbeeld van een architectuur met drie lagen geïmplementeerd. Laten we eens kijken naar de voordelen en uitdagingen van deze architectuurstijl en naar de best practices om deze te optimaliseren voor prestaties en beveiliging.
Vergoedingen
Deze kracht van deze architectuurstijl zit hem in zijn eenvoud. Het is een vaak gebruikt en goed gedefinieerd architectuurpatroon, zowel voor implementaties on-premises als in de cloud, en kan werken met een breed scala aan toepassingen.
Het is een platform-agnostische architectuur en geschikt voor toepassingen die op Windows of Linux zijn geïmplementeerd. Zoals we in onze voorbeeldomgeving hebben laten zien, kunt u PaaS- of IaaS-services op elke laag gebruiken.
Als de toepassing is gescheiden in lagen kan elke laag onafhankelijk worden geschaald, bijgewerkt of vernieuwd. Als aanvragen voor onze website toenemen, kunnen we meer webservers toevoegen aan de belasting zonder dat dit van invloed is op de andere lagen. En als aanvragen naar onze gegevenslaag toenemen, kunnen we onze database schalen om meer capaciteit te hebben om de aanvragen te verwerken.
Netwerkscheiding is een natuurlijk bijkomend gevolg van deze architectuur. Omdat de toepassing is gescheiden in lagen, moeten we elke laag isoleren en alleen de benodigde netwerktoegang toestaan. De presentatielaag kan worden blootgesteld aan internet, de database kan volledig worden beveiligd achter meerdere netwerklagen en onze toepassing functioneert precies hetzelfde. Door netwerktoegang tussen lagen te beveiligen, verminderen we de kwetsbaarheid voor aanvallen van de toepassing en verhogen we de beveiliging.
Problemen en overwegingen
Als u uw toepassing in meerdere lagen verdeelt, voorkom dan middenlagen die alleen databasebewerkingen uitvoeren. Elke laag moet een specifieke waarde toevoegen. Extra lagen voegen complexiteit, verwerkingstijd, latentie en uiteindelijk vertraging toe aan de gebruiker.
Omdat de API's voor elk domein op toepassingsniveau niet zijn gescheiden in afzonderlijke services, moeten ze worden geschaald. Als voor een enkele toepassingsmethode meer verwerkingskracht is vereist of als deze meer aanvragen moet verwerken dan andere, moet niet een afzonderlijke service, maar de toepassingslaag in zijn geheel worden uitgebreid om de belasting te verwerken.
In sommige gevallen zou u een toepassing kunnen ontwikkelen als een n-laag-architectuur, maar nog steeds inzetten als een monoliet. Als u elke laag volledig wilt scheiden, moet u deze onafhankelijk van elkaar implementeren. Volledige scheiding omvat het verwijderen van gedeelde afhankelijkheden en een grotere afhankelijkheid van API-aanroepen tussen lagen. Wanneer u dit goed doet, zorgt dit ervoor dat uw toepassingsimplementaties flexibel zijn.
Toepassingen in een N-tier-architectuur worden vaak geïmplementeerd op VM's. Dit is een goede eerste stap, maar het ontwikkelen van uw toepassing voor het gebruik van PaaS-services biedt tal van voordelen op het gebied van beveiliging, schaalbaarheid en beheer. Deze evolutie wordt vaak over het hoofd gezien en N-tier architecturen blijven aanwezig op VM's.
N-laag is een klassieke architectuurstijl, maar in veel scenario's wordt deze vervangen door andere moderne ontwerppatronen, zoals een microservicesarchitectuur. Het is vaak de moeite waard om tijd te investeren om andere architecturen te evalueren om te zien of ze beter geschikt zijn voor uw toepassing.
Best practices voor n-laag-architecturen
Er zijn verschillende dingen die u moet doen om ervoor te zorgen dat uw n-laag-architectuur optimaal werkt. Het volgende diagram laat visueel zien hoe u verbeteringen in een n-laag-architectuur kunt aanbrengen.
Prestaties optimaliseren
Laten we kijken naar manieren om een n-laag-architectuur te optimaliseren voor zowel prestaties als beveiliging.
Automatisch schalen
Nu de toepassing is gescheiden in lagen, kunnen we cloudfuncties, zoals automatisch schalen, gebruiken om zich aan te passen aan de systeembelasting. Naarmate gebruikers of aanvragen toenemen, gebruikt u automatisch schalen op meerdere lagen om meer resources toe te voegen om aanvragen te verwerken. Naarmate aanvragen afnemen, vermindert automatisch schalen de rekenresources, waardoor ook uw factuur lager wordt. Met automatisch schalen kunt u ervoor zorgen dat uw gebruikers de beste ervaring hebben en dat uw kosten laag blijven. Virtuele-machineschaalsets van Azure kunnen worden gebruikt voor vm-workloads en veel PaaS-services, zoals Azure-app Service, hebben ingebouwde mogelijkheden voor automatisch schalen.
Load balancing
Als u uw toepassing uitbreidt met automatisch schalen, wordt het gebruik van taakverdeling een noodzakelijk onderdeel van uw architectuur. Wanneer u met taakverdeling meer rekenresources toevoegt aan uw laag, worden deze toegevoegd aan uw load balancer-distributie om te profiteren van de extra verwerkingskracht. Als een systeem echter uitvalt, wordt het verwijderd uit de belasting om de impact van de gebruiker te minimaliseren door slechte prestaties of mislukte aanvragen. Dit zorgt ervoor dat gebruikersaanvragen foutloos naar systemen gaan. Azure Load Balancer is een ingebouwde functie van de netwerkmogelijkheden en Application Gateway biedt een meer functionele HTTP-taakverdeling.
Berichten
Het gebruik van een berichtenservice tussen lagen heeft een positief effect op de prestaties, met name op aanvragen die asynchroon van aard zijn. De service plaatst een bericht in een wachtrij, waar het blijft staan totdat het wordt verwerkt, waardoor de impact van downstreambelasting wordt verschoven. Als er een systeemstoring optreedt, zorgt een berichtenservice ervoor dat uw bericht nog steeds wordt verwerkt. Het bericht blijft in de wachtrij en wordt verwerkt nadat het systeem weer online is. Azure biedt verschillende oplossingen voor berichtverzending waaruit u kunt kiezen, afhankelijk van uw vereisten. Azure Service Bus, Azure Storage-wachtrijen en Azure Event Hubs zijn er een paar om naar te kijken wanneer u op zoek bent naar een berichtenservice.
Gegevens opslaan in cache
Gebruik een cache voor gegevens die vaak worden gebruikt en een lage wijzigingssnelheid hebben, of voor gegevens waarvoor geen persistentie op de lange termijn is vereist, zoals sessiestatus. Caching-systemen zitten tussen lagen. Hiermee wordt het ophalen van gegevens voor dit soort gegevens gereduceerd. Azure Cache for Redis is een PaaS-service die zeer geschikt is voor dit scenario.
Beveiliging optimaliseren
Het optimaliseren van uw toepassing voor beveiliging is vaak een taak die nooit 'gedaan' is. Hoewel de toepassing is gescheiden in lagen, moeten er nog steeds goed geplande beveiligingsprocedures in de architectuur worden geweven. Hoe meer lagen u toevoegt, hoe meer u moet beveiligen en hoe meer u complexiteit in het systeem introduceert. Er zijn verschillende dingen die u moet doen om ervoor te zorgen dat uw architectuur een beveiligde omgeving biedt om uw toepassing uit te voeren.
Netwerkisolatie
Wanneer u een N-tier-architectuur uitvoert op VM's, moet u ervoor zorgen dat elke laag zich in een eigen subnet bevindt. Dit subnet fungeert als een beveiligingsgrens, zodat u connectiviteit kunt isoleren via lijsten met netwerktoegangsbeheer. Het subnet vereenvoudigt ook het beheer door ervoor te zorgen dat nieuwe systemen in het subnet dezelfde regels ontvangen. In Azure wordt dit systeemeigen uitgevoerd met netwerkbeveiligingsgroepen (NSG's). Soortgelijke overwegingen moeten worden gemaakt voor PaaS-services, maar de netwerkintegratiemogelijkheden verschillen per service en moeten op zichzelf worden beoordeeld. Het is een aanbevolen procedure om ervoor te zorgen dat elke laag alleen kan communiceren naar de volgende laag eronder. De presentatielaag moet alleen kunnen communiceren met de toepassingslaag en de toepassingslaag moet alleen kunnen communiceren met de gegevenslaag. Het minimaliseren van deze connectiviteit biedt een gelaagde benadering van netwerkbeveiliging en verbetert de algehele beveiligingsstatus van een architectuur.
Web Application Firewall
Nu de beveiligingsisolatie tussen subnetten aanwezig is, wilt u ervoor zorgen dat uw openbaar blootgestelde front-end veilig is en alleen toegang heeft tot wat er nodig is. U moet uw presentatielaag alleen beschikbaar maken voor inkomend internetverkeer. Een WAF-technologie (Web Application Firewall) voor uw presentatielaag verbetert de beveiliging op deze laag. WAF's controleren het verkeer op kwaadaardige activiteiten, zorgen ervoor dat de communicatie wordt versleuteld en waarschuwen u bij ongewone zaken en activiteiten is. In Azure is Application Gateway een HTTP-load balancer met een ingebouwde WAF die u kunt inschakelen.