Överväganden för N-nivåarkitekturer
Vi har tittat på vad som utgör en N-nivåarkitektur och vi har distribuerat ett exempel på en arkitektur på 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örmåner
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 vår exempelmiljö kan du använda PaaS- eller IaaS-tjänster på valfri nivå.
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 till 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 uppdelat 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 attackyta 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. Extra nivåer lägger till komplexitet, bearbetningstid, svarstid och slutligen fördröjning 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. Fullständig separation innebär borttagning av delade beroenden och ett större beroende av API-anrop mellan nivåer. När det görs på rätt sätt säkerställer det att dina programdistributioner är flexibla.
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 förblir bosatta på virtuella datorer.
N-nivån är en klassisk arkitekturstil, men i många scenarier ersätts den av andra moderna designmönster, till exempel en arkitektur för mikrotjänster. Det är ofta värt att investera lite tid för att utvärdera andra arkitekturer för att se om de passar bättre för ditt program.
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
Med programmet indelat i nivåer kan vi använda molnfunktioner, till exempel autoskalning, för att anpassa till systembelastning. 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 har den bästa upplevelsen och att dina kostnader förblir låga. Skalningsuppsättningar för virtuella Azure-datorer 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. När du lägger till fler beräkningsresurser på din nivå läggs de till i lastbalanserarens distribution för att dra nytta av den extra bearbetningskraften. När ett system misslyckas tas det däremot bort från belastningen för att minimera användarpåverkan genom dåliga prestanda eller felaktiga 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.
Meddelandefunktion
Användningen av en meddelandetjänst mellan nivåer har en positiv effekt på prestanda, särskilt på begäranden som är asynkrona. Tjänsten placerar ett meddelande i en kö, där det finns kvar tills det bearbetas, vilket förskjuter effekten av nedströmsbelastning. Om ett systemstopp inträffar ser en meddelandetjänst till att meddelandet fortfarande hanteras. Meddelandet 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
Att optimera ditt program för säkerhet är ofta ett jobb som aldrig är "gjort". Även om programmet är indelat i nivåer måste det fortfarande finnas välplanerade säkerhetsrutiner invävda i arkitekturen. Ju fler nivåer du lägger till, desto mer behöver du skydda och ju mer du introducerar komplexitet 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.
Nätverksisolering
När du kör en N-nivåarkitektur på virtuella datorer kontrollerar du att varje nivå finns i ett eget undernät. Det här undernätet fungerar som en säkerhetsgräns så att du kan isolera anslutningen via listor över nätverksåtkomstkontroll. Undernätet underlättar också hanteringen genom att se till att nya system i undernätet får samma regler. I Azure görs detta internt 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äkerhetsisoleringen mellan undernät på plats vill du se till att din offentligt exponerade klientdel är säker och endast ger åtkomst till det som behövs. Du bör bara exponera presentationsnivån för inkommande Internettrafik. En waf-teknik (brandvägg för webbprogram) framför presentationsnivån förbättrar 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 är Application Gateway en HTTP-lastbalanserare som har en inbyggd WAF som du kan aktivera.