Overwegingen voor n-laag-architecturen

• 7 minuten

We hebben gekeken naar waar een n-laag-architectuur deel van maakt 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.

Voordelen

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, kunnen PaaS- of IaaS-services op elke laag worden gebruikt.

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 de netwerktoegang tussen lagen te beveiligen, wordt de aanvalslaag van de toepassing verkleind en wordt de beveiliging ervan vergroot.

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 zorgen voor complexiteit, verwerkingstijd, latentie en uiteindelijk vertraging voor de gebruiker.

Omdat de API's voor elk domein op toepassingsniveau niet zijn gescheiden in afzonderlijke services, moeten ze samen 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. Dit omvat het verwijderen van gedeelde afhankelijkheden en een grotere afhankelijkheid van API-aanroepen tussen lagen. Als dit goed wordt gedaan, zorgt dit ervoor dat de implementaties van uw toepassing flexibel zijn.

Toepassingen in een N-laag-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-laag-architecturen blijven op VM's staan.

Dit is een klassieke architectuurstijl, maar in veel scenario's is het vervangen door andere moderne ontwerppatronen, zoals een architectuur met microservices. Het is vaak de moeite waard om enige tijd te investeren in het evalueren van andere architecturen om te zien of deze 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. Automatisch schalen maakt het eenvoudig om ervoor te zorgen dat uw gebruikers de beste ervaring hebben en dat uw kosten laag blijven. Azure Virtual Machine Scale Sets kunnen worden gebruikt voor VM-workloads en veel PaaS-services, zoals Azure App Service, hebben ingebouwde mogelijkheden voor automatisch schalen.

Taakverdeling

Als u uw toepassing uitbreidt met automatisch schalen, wordt het gebruik van taakverdeling een noodzakelijk onderdeel van uw architectuur. Wanneer u meer rekenresources toevoegt aan uw laag, worden deze met taakverdeling toegevoegd aan uw load balancer om te profiteren van de extra verwerkingskracht. Wanneer een systeem daarentegen uitvalt, wordt het uit de belasting verwijderd om de gevolgen voor de gebruiker te minimaliseren door slechte prestaties of foute 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 positieve invloed op de prestaties, met name op aanvragen die asynchroon van aard zijn. Een bericht wordt in een wachtrij geplaatst, waar het blijft totdat het wordt verwerkt, om de impact van downstreambelasting te compenseren. Als er een systeemstoring is, zorgt dit er tevens voor dat uw bericht nog steeds wordt afgehandeld. Deze 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

Bij het optimaliseren voor beveiliging is dit vaak een taak die nooit 'klaar' is. Zelfs als de toepassing is opgedeeld in lagen, moeten er nog steeds goed geplande beveiligingsprocedures in de architectuur worden verweven. Hoe meer lagen worden toegevoegd, hoe meer beveiliging u nodig hebt en hoe complexer het systeem is. 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

Zorg ervoor dat bij het uitvoeren van een n-laag-architectuur op VM's elke laag zich in een eigen subnet bevindt. Dit subnet fungeert als een beveiligingsgrens, zodat u connectiviteit kunt isoleren via netwerktoegangsbeheerlijsten, maar het beheer vereendt door ervoor te zorgen dat nieuwe systemen in het subnet dezelfde regels ontvangen. In Azure wordt dit standaard gedaan 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

Met de beveiligingsisolatie tussen subnetten wilt u ervoor zorgen dat uw openbaar beschikbaar gemaakt front-end veilig is en alleen toegang toestaat tot wat nodig is. Alleen uw presentatielaag moet worden blootgesteld aan inkomend internetverkeer. Met WAF-technologie (webapplicatie-firewall) voor uw presentatielaag verbetert u de beveiliging op dit niveau. 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 Application Gateway een HTTP-load balancer met een ingebouwde WAF die u kunt inschakelen.

Test uw kennis