Överväganden för N-nivåarkitekturer

• 7 minuter

Vi har tittat på vad som utgör en N-nivåarkitektur och vi har distribuerat ett exempel på en arkitektur med tre nivåer. Nu ska vi utforska några av fördelarna och utmaningarna med det här arkitekturformatet och de bästa metoderna att optimera det för prestanda och säkerhet.

Fördelar

Enkelheten i den här typen av arkitektur är en fördel. Det är ett välanvänt och väldefinierat arkitekturmönster både för lokala och molnbaserade distributioner, och det fungerar med en mängd olika program.

Det är en plattformsoberoende arkitektur som passar program som distribueras i Windows eller Linux. Som vi visade i exempelmiljön kan PaaS- eller IaaS-tjänster användas på alla nivåer.

När programmet delas upp i olika nivåer kan varje nivå skalas, uppdateras och uppgraderas separat. Om begäranden för vår webbplats ökar kan vi lägga till fler webbservrar i belastningen utan att påverka de andra nivåerna. Om antalet förfrågningar till vår datanivå okar kan vi också skala databasen så att kapaciteten ökar och den kan hantera förfrågningarna.

Nätverksseparation är en naturlig biprodukt i den här arkitekturen. Eftersom programmet är indelat i nivåer bör vi isolera varje nivå och endast tillåta nödvändig nätverksåtkomst. Presentationslagret kan exponeras för internet, databasen kan säkras helt bakom flera nätverksnivåer och vårt program fungerar ändå på samma sätt. Genom att skydda nätverksåtkomsten mellan nivåer minskar vi programmets angreppsyta och ökar dess säkerhet.

Utmaningar och saker att tänka på

När du delar upp ditt program i flera nivåer bör du undvika mellannivåer som bara utför databasåtgärder. Varje nivå bör lägga till specifikt värde. Ytterligare nivåer ökar komplexiteten, bearbetningstiden, svarstiden och i slutänden fördröjningen för användaren.

Eftersom API:erna för varje domän på programnivå inte är uppdelade i enskilda tjänster måste de skalas tillsammans. Om en enda programmetod kräver mer bearbetningskraft eller behöver hantera fler begäranden än andra, måste programnivån skalas ut som helhet, inte bara en enskild tjänst, för att kunna hantera belastningen.

I en del fall kan du utveckla ett program som en N-nivåarkitektur men ändå köra distributioner som monolit. När du separerar de olika nivåerna helt bör du distribuera dem separat. Detta omfattar borttagning av delade beroenden och medför större beroende av API-anrop mellan nivåer. När detta görs korrekt säkerställer det flexibla programdistributioner.

Program i en N-nivåarkitektur distribueras ofta på virtuella datorer. Detta är ett bra första steg, men att utveckla programmet för PaaS-tjänster ger många fördelar vad gäller säkerhet, skalbarhet och administration. Den här utvecklingen förbises ofta och N-nivåarkitekturer finns kvar på virtuella datorer.

Detta är ett klassiskt arkitekturformat men i många scenarier har det fått stå tillbaka för andra, moderna designmönster, som mikrotjänstarkitekturer. Det är ofta värt investeringen att lägga lite tid på att utvärdera andra arkitekturer och se om de passar ditt program bättre.

Bästa metod för N-nivåarkitekturer

Det finns flera saker du bör göra för att få din N-nivåarkitektur att köras på bästa sätt. I följande diagram visas hur du kan förbättra en N-nivåarkitektur.

Optimera prestanda

Vi ska titta på några sätt att optimera en N-nivåarkitektur för prestanda och säkerhet.

Automatisk skalning

När programmet är indelat i nivåer kan vi använda molnfunktioner, till exempel automatisk skalning, för att anpassa oss efter systembelastningen. När antalet användare eller förfrågningar ökar kan vi använda automatisk skalning för att lägga till mer resurser för att hantera förfrågningarna. När antalet förfrågningar minskar, minskas även beräkningsresurserna med hjälp av den automatiska skalningen – vilket också gör fakturan mindre. Autoskalning gör det enkelt att se till att användarna får bästa möjliga upplevelse och att kostnaderna förblir låga. Azure Virtual Machine Scale Sets kan användas för VM-baserade arbetsbelastningar och många PaaS-tjänster, till exempel Azure App Service, har inbyggda funktioner för automatisk skalning.

Belastningsutjämning

När du skalar ut programmet med automatisk skalning blir belastningsutjämning en viktig del i arkitekturen. Lastbalansering fungerar så att när du lägger till mer beräkningsresurser till din nivå läggs de till lastbalanserarens distribution så att de kan utnyttja mer processorkraft. Om ett system misslyckas tas det däremot bort från belastningen för att minimera användarpåverkan genom dåliga prestanda eller misslyckade begäranden. Detta säkerställer att användarens förfrågningar går till felfria system. Lastbalanseraren i Azure är en inbyggd funktion i nätverksfunktionerna, och Application Gateway ger en mer funktionsrik lösning för HTTP-lastbalansering.

Meddelandetjänster

Användningen av en meddelandetjänst mellan nivåer har en positiv inverkan på prestanda, särskilt för begäranden som är asynkrona till sin natur. Ett meddelande placeras i en kö, där det finns kvar tills det bearbetas, vilket påverkar effekten av nedströmsbelastningen. Det säkerställer också att meddelandet hanteras även vid avbrott i systemet. Den finns kvar i kön och bearbetas när systemet är online igen. Azure har flera meddelandelösningar att välja bland, beroende på dina krav. Azure Service Bus, Azure Storage-köer och Azure Event Hubs är några lösningar du kan titta på när du letar efter en meddelandetjänst.

Cachelagring av data

Använd en cache för data som används ofta och som har låg ändringsfrekvens eller för data som inte kräver långsiktigt bevarande, till exempel sessionstillstånd. Cachelagringssystemen finns mellan nivåerna och minskar tiderna för datahämtning av för de här typerna av data. Azure Cache för Redis är en PaaS-tjänst som passar det här scenariot.

Optimera säkerheten

När du optimerar för säkerhet är detta ofta ett jobb som aldrig är "klart". Även om programmet är uppdelat i nivåer måste det finnas välplanerade säkerhetsrutiner invävda i arkitekturen. Ju fler nivåer som läggs till, desto mer behöver du skydda och säkra, och desto mer komplexitet byggs in i systemet. Det finns flera saker du bör göra för att säkerställa att arkitekturen är en säker miljö för dina program.

Isolering av nätverk

Se till att varje nivå finns i ett eget undernät när du kör en N-nivåarkitektur på virtuella datorer. Det här undernätet fungerar som en säkerhetsgräns, så att du kan isolera anslutningar via åtkomstkontrolllistor för nätverk, men underlätta hanteringen genom att se till att nya system i undernätet får samma regler. I Azure görs detta inbyggt med nätverkssäkerhetsgrupper (NSG:er). Liknande överväganden bör göras för PaaS-tjänster, men funktionerna för nätverksintegrering varierar mellan olika tjänster och bör utvärderas var för sig. Det är en bra idé att se till att varje nivå endast kan kommunicera med nivån närmast under. Presentationsnivån bör endast ska kunna kommunicera med programnivån, och programnivån bör endast kunna kommunicera med datanivån. Minimering av anslutningarna ger nätverkssäkerhet i flera nivåer och förbättrar den övergripande säkerheten i arkitekturen.

Brandvägg för webbaserade program

Med säkerhetsisolering mellan undernät på plats vill du se till att den offentligt exponerade fronten är säker och endast ger åtkomst till det som behövs. Endast presentationsnivån bör exponeras för inkommande internettrafik, och en brandvägg för webbaserade program (WAF) framför presentationsnivån höjer säkerheten på den här nivån. WAF genomsöker trafiken efter skadlig aktivitet, se till att kommunikationen är krypterad och varnar dig om något verkar onormalt. I Azure Application Gateway en HTTP-lastbalanserare som har en inbyggd WAF som du kan aktivera.

Testa dina kunskaper