Arkitekturformat på N-nivå

En N-nivåarkitektur delar upp ett program i logiska lager och fysiska nivåer.

Lager är ett sätt att separera ansvarsområden och hantera beroenden. Varje lager har ett specifikt ansvar. Ett högre lager kan använda tjänster i ett lägre lager, men inte tvärtom.

Nivåerna är fysiskt avgränsade och körs på separata datorer. Avtalsmässigt kan nivån ha sina kommunikationsmodeller strikta eller avslappnade. I den strikta modellen måste en begäran gå igenom angränsande nivåer, en i taget, och kan inte hoppa över någon nivå däremellan. Till exempel från brandväggen för webbprogram till webbnivån, sedan till mellannivå 1 och så vidare. I den avslappnade metoden kan begäran däremot hoppa över vissa nivåer om det behövs. Den strikta metoden har mer svarstid och omkostnader, och den avslappnade metoden har fler kopplingar och därefter är det svårare att ändra. Ett system kan använda en hybridmetod: att ha både avslappnade och strikta nivåer där det behövs.

En nivå kan anropa till en annan nivå direkt eller använda asynkrona meddelandemönster via en meddelandekö. Även om varje lager kan finnas på sin egen nivå krävs det inte. Flera lager kan finnas på samma nivå. Fysiskt avgränsande av nivåerna förbättrar skalbarheten och motståndskraften, men lägger också till svarstid från den ytterligare nätverkskommunikationen.

Ett traditionellt program med tre nivåer har en presentationsnivå, en mellannivå och en databasnivå. Mellannivån är valfri. Mer komplexa program kan ha fler än tre nivåer. Diagrammet ovan visar ett program med två mellannivåer som kapslar in olika funktionsområden.

Ett N-nivåprogram kan ha en sluten lagerarkitektur eller en arkitektur med öppet lager:

• I en sluten lagerarkitektur kan ett lager bara anropa nästa lager omedelbart nedåt.
• I en arkitektur med öppet lager kan ett lager anropa något av lagren under den.

En sluten skiktarkitektur begränsar beroendena mellan lager. Det kan dock skapa onödig nätverkstrafik om ett lager helt enkelt skickar begäranden till nästa lager.

När du ska använda den här arkitekturen

N-nivåarkitekturer implementeras vanligtvis som IaaS-program (infrastruktur som tjänst), där varje nivå körs på en separat uppsättning virtuella datorer. Ett N-nivåprogram behöver dock inte vara ren IaaS. Ofta är det fördelaktigt att använda hanterade tjänster för vissa delar av arkitekturen, särskilt cachelagring, meddelanden och datalagring.

Överväg en N-nivåarkitektur för:

• Enkla webbprogram.
• En bra utgångspunkt när arkitekturkraven inte är tydliga ännu.
• Migrera ett lokalt program till Azure med minimal refaktorisering.
• Enhetlig utveckling av lokala program och molnprogram.

N-nivåarkitekturer är mycket vanliga i traditionella lokala program, så det passar naturligt för migrering av befintliga arbetsbelastningar till Azure.

Fördelar

• Portabilitet mellan molnet och lokalt och mellan molnplattformar.
• Mindre inlärningskurva för de flesta utvecklare.
• Relativt låg kostnad genom att inte omorganera lösningen
• Naturlig utveckling från den traditionella programmodellen.
• Öppna för heterogen miljö (Windows/Linux)

Utmaningar

• Det är enkelt att få en mellannivå som bara utför CRUD-åtgärder i databasen, vilket ger extra svarstid utan att göra något användbart arbete.
• Monolitisk design förhindrar oberoende distribution av funktioner.
• Att hantera ett IaaS-program är mer arbete än ett program som endast använder hanterade tjänster.
• Det kan vara svårt att hantera nätverkssäkerhet i ett stort system.
• Användar- och dataflöden sträcker sig vanligtvis över flera nivåer, vilket ökar komplexiteten i frågor som testning och observerbarhet.

Metodtips

• Använd autoskalning för att hantera ändringar i belastningen. Se metodtips för automatisk skalning.
• Använd asynkrona meddelandefunktioner för att frikoppla nivåer.
• Cachelagrade semistatiska data. Se metodtips för cachelagring.
• Konfigurera databasnivån för hög tillgänglighet med hjälp av en lösning som SQL Server AlwaysOn-tillgänglighetsgrupper.
• Placera en brandvägg för webbprogram (WAF) mellan klientdelen och Internet.
• Placera varje nivå i ett eget undernät och använd undernät som en säkerhetsgräns.
• Begränsa åtkomsten till datanivån genom att endast tillåta begäranden från mellannivåerna.

N-nivåarkitektur på virtuella datorer

I det här avsnittet beskrivs en rekommenderad N-nivåarkitektur som körs på virtuella datorer.

Varje nivå består av två eller flera virtuella datorer, placerade i en tillgänglighetsuppsättning eller vm-skalningsuppsättning. Flera virtuella datorer ger återhämtning om en virtuell dator misslyckas. Lastbalanserare används för att distribuera begäranden mellan de virtuella datorerna på en nivå. En nivå kan skalas vågrätt genom att lägga till fler virtuella datorer i poolen.

Varje nivå placeras också i ett eget undernät, vilket innebär att deras interna IP-adresser ligger inom samma adressintervall. Det gör det enkelt att tillämpa regler för nätverkssäkerhetsgrupper och dirigera tabeller till enskilda nivåer.

Webb- och affärsnivåerna är tillståndslösa. Alla virtuella datorer kan hantera alla begäranden för den nivån. Datanivån bör bestå av en replikerad databas. För Windows rekommenderar vi SQL Server med hjälp av AlwaysOn-tillgänglighetsgrupper för hög tillgänglighet. För Linux väljer du en databas som stöder replikering, till exempel Apache Cassandra.

Nätverkssäkerhetsgrupper begränsar åtkomsten till varje nivå. Till exempel tillåter databasnivån endast åtkomst från affärsnivån.

Ytterligare överväganden

• N-nivåarkitekturer är inte begränsade till tre nivåer. För mer komplexa program är det vanligt att ha fler nivåer. I så fall bör du överväga att använda layer-7-routning för att dirigera begäranden till en viss nivå.

• Nivåerna är gränsen för skalbarhet, tillförlitlighet och säkerhet. Överväg att ha separata nivåer för tjänster med olika krav på dessa områden.

• Använd vm-skalningsuppsättningar för automatisk skalning.

• Leta efter platser i arkitekturen där du kan använda en hanterad tjänst utan betydande refaktorisering. Titta särskilt på cachelagring, meddelanden, lagring och databaser.

• För högre säkerhet placerar du ett DMZ-nätverk framför programmet. DMZ innehåller virtuella nätverksinstallationer (NVA) som implementerar säkerhetsfunktioner som brandväggar och paketinspektion. Mer information finns i DMZ-referensarkitektur för nätverk.

• För hög tillgänglighet placerar du två eller flera NVA:er i en tillgänglighetsuppsättning med en extern lastbalanserare för att distribuera Internetbegäranden mellan instanserna. Mer information finns i Distribuera virtuella nätverksinstallationer med hög tillgänglighet.

• Tillåt inte direkt RDP- eller SSH-åtkomst till virtuella datorer som kör programkod. Operatorer bör i stället logga in på en jumpbox, även kallad skyddsvärd. Det här är en virtuell dator i nätverket som administratörer använder för att ansluta till de andra virtuella datorerna. Jumpboxen har en nätverkssäkerhetsgrupp som endast tillåter RDP eller SSH från godkända offentliga IP-adresser.

• Du kan utöka det virtuella Azure-nätverket till ditt lokala nätverk med hjälp av ett virtuellt privat nätverk (VPN) eller Azure ExpressRoute. Mer information finns i hybridnätverksreferensarkitektur.

• Om din organisation använder Active Directory för att hantera identiteter kanske du vill utöka Din Active Directory-miljö till det virtuella Azure-nätverket. Mer information finns i referensarkitekturen för identitetshantering.

• Om du behöver högre tillgänglighet än vad azure-serviceavtalet för virtuella datorer tillhandahåller replikerar du programmet mellan två regioner och använder Azure Traffic Manager för redundans. Mer information finns i Köra virtuella Linux-datorer i flera regioner.

Relaterade resurser

• N-nivåprogram med Apache Cassandra
• [Windows N-nivåprogram i Azure med SQL Server][n-tier-windows-SQL]
• Microsoft Learn-modul: Gå igenom arkitekturstilen på N-nivå
• Azure Bastion
• Mer information om meddelanden i en arkitekturstil på N-nivå i Azure