Dela via


Arkitekturformat på N-nivå

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

Logiskt diagram som visar en arkitekturstil på N-nivå.

Lager separerar ansvarsområden och hanterar beroenden. Varje lager har ett specifikt ansvar. Ett högre lager kan använda tjänster i ett lägre lager, men ett lägre lager kan inte använda tjänster i ett högre lager.

Nivåerna separeras fysiskt och körs på separata datorer. Enligt avtal kan nivån ha strikta eller avslappnade kommunikationsmodeller. 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. En begäran skickas till exempel från brandväggen för webbprogram (WAF) till webbnivån, sedan till mellannivå 1 och fortsätter. Den avslappnade metoden gör det däremot möjligt för begäranden att hoppa över vissa nivåer om det behövs. Den strikta metoden har större svarstid och mer omkostnader. Den avslappnade metoden har fler kopplingar, vilket gör förändringar svårare. Du kan också kombinera båda metoderna i samma system.

En nivå kan anropa till en annan nivå direkt eller använda asynkrona meddelandemönster via en meddelandekö. Du kan hålla varje lager i sitt eget skikt, men detta tillvägagångssätt är inte nödvändigt. Du kan vara värd för flera lager på samma nivå. Fysisk uppdelning av nivåer förbättrar skalbarhet och återhämtning, men lägger även till svarstid från den extra nätverkskommunikationen.

Ett traditionellt program med tre nivåer har en presentationsnivå, en valfri mellannivå och en databasnivå. Mer komplexa program kan ha fler än tre nivåer. Det föregående diagrammet 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 alla lager under den.

En sluten skiktarkitektur begränsar beroendena mellan lager. Men den här arkitekturen kan skapa onödig nätverkstrafik om ett lager bara skickar begäranden till nästa lager.

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

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

  • Stöd för arkitekturkrav som fortfarande utvecklas.
  • Migrera ett lokalt program till Azure med minimala ändringar.
  • Utveckla program som omfattar både lokala miljöer och molnmiljöer.

N-nivåarkitekturer är vanliga i traditionella lokala system, vilket gör dem till en naturlig plats för att överföra befintliga arbetsbelastningar till Azure.

Implementera N-nivåarkitekturer effektivt med hjälp av hanterade tjänster som ger skalbarhet, tillförlitlighet och minskade driftkostnader eller virtuella datorer (VM). Dessa arbetsbelastningar drar ofta nytta av att även använda hanterade lösningar för viktiga komponenter som cachelagring, meddelanden och datalagring.

Fördelar

  • Portabel i molnet och lokalt och mellan molnplattformar
  • Kräver mindre inlärningskurva för de flesta utvecklare
  • Kostar relativt lite genom att inte omstrukturera lösningen
  • Följer en naturlig utveckling från den traditionella programmodellen
  • Stöder blandade miljöer som innehåller Windows och Linux

Utmaningar

  • En mellannivå kanske bara utför grundläggande crud-åtgärder (create, read, update, delete), vilket ger svarstid och komplexitet utan att leverera meningsfullt värde.
  • Monolitisk design förhindrar oberoende distribution av funktioner.
  • Stora system kan göra det svårt att hantera nätverkssäkerhet.
  • Användarbegäranden och data som flyttas genom flera nivåer gör testning och övervakning svårare.

Metodtips

  • Använd autoskalning för att hantera ändringar i belastningen. Mer information finns i Metodtips för automatisk skalning.
  • Använd asynkrona meddelanden för att frikoppla nivåer.
  • Cachelagrade data som inte ändras ofta. Mer information finns i 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 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 en mellannivå.

N-nivåarkitektur på virtuella datorer

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

Anmärkning

Använd virtuella datorer som värd för en N-teir-arkitektur om du planerar att migrera ett befintligt program till Azure med minimal refaktorisering. Annars bör du överväga att använda hanterade tjänster för att implementera arkitekturen, till exempel Azure App Service eller Azure Container Apps.

Diagram som visar en N-nivåarkitektur.

Varje nivå består av en VM-skalningsuppsättning som har två eller flera virtuella datorer. Flera virtuella datorer ger återhämtning om en virtuell dator misslyckas. Lastbalanserare distribuerar begäranden mellan de virtuella datorerna på en nivå. Du kan skala en nivå 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. Den här metoden 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. Använd där det är möjligt en hanterad databas, men du kan också vara värd för databaser på virtuella datorer. För Windows rekommenderar vi SQL Server med 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.

Anmärkning

Lagret med etiketten Affärsnivå i referensdiagrammet refererar till affärslogiknivån. Presentationsnivån är märkt webbnivå. Exemplet visar ett webbprogram, men du kan också använda arkitekturer på flera nivåer för andra topologier, till exempel skrivbordsappar. Använd tydliga, beskrivande namn för varje nivå som ditt team förstår. Du kan också använda dessa namn i dina Azure-resurser, vmss-appname-business-tiertill exempel .

Andra överväganden

  • N-nivåarkitekturer är inte begränsade till tre nivåer. Mer komplexa program har ofta 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åer skapar gränser 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.

  • Hitta platser i arkitekturen där du kan använda en hanterad tjänst utan betydande refaktorisering. Överväg särskilt cachelagring, meddelanden, lagring och databaser.

  • Placera ett perimeternätverk (även kallat DMZ, demilitariserad zon och skärmat undernät) framför programmet för högre säkerhet. Perimeternätverket innehåller virtuella nätverksinstallationer (NVA) som implementerar säkerhetsfunktioner som brandväggar och paketinspektion. Mer information finns i Implementera ett säkert hybridnätverk.

  • Använd två eller fler NVAs i en virtuell maskinskala uppsättning, med en extern lastbalanserare för att distribuera internetförfrågningar mellan instanserna för att uppnå hög tillgänglighet. Mer information finns i Distribuera NVA:er med hög tillgänglighet.

  • Blockera direkt RDP-åtkomst (Remote Desktop Protocol) eller SSH-åtkomst (Secure Shell) till virtuella datorer som kör programkod. Använd i stället Azure Bastion för att på ett säkert sätt ansluta till virtuella datorer via privata IP-adresser, vilket ger RDP- och SSH-anslutning. Mer information finns i Översikt över Azure Bastion.

  • 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 Referensarkitektur för hybridnätverk.

Nästa steg