Redigera

Dela via

Arkitekturformat på N-nivån

Azure Storage
Azure Cloud Services
Azure Virtual Machines

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

Logiskt diagram över ett arkitekturformat på N-nivå

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 undre lager, men inte tvärtom.

Nivåer ä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ö. Varje lager kan finnas på en egen nivå, men det är inget krav. Flera lager kan finnas på samma nivå. Fysiskt avgränsade nivåer ger bättre skalbarhet och återhämtning, men medför också fördröjning på grund av extra nätverkskommunikation.

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 stängd lagerarkitektur eller en öppen lagerarkitektur:

  • I en stängd lagerarkitektur kan ett lager endast anropa nästa lager nedåt.
  • I en öppen lagerarkitektur kan ett lager anropa alla lager som finns nedanför.

I en stängd lagerarkitektur begränsas beroenden mellan lager. Om ett lager bara skickar begäranden vidare till nästa lager kan det dock skapa onödig nätverkstrafik.

När ska den här arkitekturen användas?

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

N-nivåarkitektur kan vara ett alternativ för:

  • Enkla webbprogram.
  • En bra utgångspunkt när arkitekturkraven inte är tydliga ännu.
  • Att migrera ett lokalt program till Azure med minsta möjliga omstrukturering.
  • Enhetlig utveckling av lokala program och molnprogram.

N-nivåarkitekturen är mycket vanlig i traditionella lokala program, och den är därför lämplig för migrering av befintliga arbetsbelastningar till Azure.

Förmåner

  • Portabilitet mellan molnet och lokala installationer och mellan molnplattformar.
  • Kortare inlärningskurva för de flesta utvecklare.
  • Relativt låg kostnad genom att inte omorganera lösningen
  • En naturlig utveckling från den traditionella programmodellen.
  • Öppen för heterogena miljöer (Windows/Linux)

Utmaningar

  • Det är lätt hänt att mellannivån bara utför CRUD-åtgärder på databasen, vilket medför mer fördröjning utan att mer betydande arbete genomförs.
  • Den monolitiska utformningen förhindrar oberoende distribution av funktioner.
  • Det är mer arbete att hantera ett IaaS-program än ett program som endast tillämpar hanterade tjänster.
  • Det kan vara svårt att hantera nätverkssäkerheten 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.

Bästa praxis

N-nivåarkitektur på virtuella datorer

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

Fysiskt diagram över en N-nivåarkitektur

Varje nivå består av två eller flera virtuella datorer, placerade i en tillgänglighetsuppsättning eller vm-skalningsuppsättning. Flera virtuella datorer ger bättre återhämtning om det uppstår fel i en virtuell dator. Med lastbalanserare distribueras begäranden till de virtuella datorerna på en nivå. En nivå kan skalas horisontellt genom att lägga till fler virtuella datorer till 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 verksamhetsnivåer är tillståndslösa. Valfri virtuell dator kan hantera begäranden för den nivån. Datanivån ska 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 bör du välja en databas som har stöd för replikering, till exempel Apache Cassandra.

Nätverkssäkerhetsgrupper begränsar åtkomsten till varje nivå. Databasnivån tillåter till exempel bara åtkomst från verksamhetsnivån.

Kommentar

Lagret med etiketten "Affärsnivå" i vårt referensdiagram är en moniker till affärslogiknivån. På samma sätt kallar vi även presentationsnivån för "webbnivå". I vårt exempel är detta ett webbprogram, även om arkitekturer på flera nivåer kan användas även för andra topologier (t.ex. skrivbordsappar). Ge dina nivåer det som passar bäst för ditt team att kommunicera avsikten med den logiska och/eller fysiska nivån i ditt program – du kan till och med uttrycka att namngivning i resurser som du väljer att representera den nivån (t.ex. vmss-appName-business-layer).

Ytterligare överväganden

  • N-nivåarkitekturer är inte begränsade till tre nivåer. Det är vanligt att mer komplexa program har fler nivåer. I sådana fall kan du använda Layer-7-routning för begäranden till en viss nivå.

  • Nivåer utgör gränsen för skalbarhet, tillförlitlighet och säkerhet. Överväg separata nivåer för tjänster med olika krav inom respektive 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 någon större omstrukturering. Titta särskilt på cachelagring, meddelanden, lagring och databaser.

  • Uppnå högre säkerhet genom att placera ett nätverks-DMZ framför programmet. DMZ innehåller virtuella nätverksinstallationer (NVA) som implementerar säkerhetsfunktioner, till exempel brandväggar och paketgranskning. Du hittar mer information på sidan om referensarkitekturer för nätverks-DMZ.

  • Uppnå hög tillgänglighet genom att placera två eller flera NVA:er i en tillgänglighetsuppsättning, med en extern lastbalanserare för att distribuera Internet-begäranden till alla instanser. Mer information finns på sidan om hur du distribuerar virtuella nätverksinstallationer med hög tillgänglighet.

  • Tillåt inte direkt RDP- eller SSH-åtkomst till virtuella datorer som kör programkod. Användare bör i stället logga in på en jumpbox. Den kallas även för en skyddsmiljö-värd. Det här är en virtuell dator i nätverket som administratörer använder för anslutning till andra virtuella datorer. Jumpboxen har en nätverkssäkerhetsgrupp som endast tillåter RDP eller SSH från godkända offentliga IP-adresser.

  • Det virtuella Azure-nätverket kan utökas till ett lokalt nätverk med hjälp av ett virtuellt privat nätverk (VPN) plats-till-plats eller Azure ExpressRoute. Du hittar mer information på sidan om referensarkitekturer för hybridnätverk.

  • Om din organisation använder Active Directory för identitetshantering, kan det hända att Active Directory-miljön bör utökas till det virtuella Azure-nätverket. Du hittar mer information på sidan om referensarkitekturer för identitetshantering.

  • Om du behöver högre tillgänglighet än Azure-serviceavtalet för virtuella datorer ger kan du replikera programmet mellan två regioner och använda Azure Traffic Manager för redundans. Läs mer på sidan om hur du kör virtuella Windows-datorer i flera regioner eller på sidan om hur du kör virtuella Linux-datorer i flera regioner.