Arkitekturformat

Ett arkitekturformat är en familj med arkitekturer som delar samma egenskaper. Till exempel är N-nivå ett vanligt arkitekturformat. På senare tid har mikrotjänstarkitekturer börjat vinna terräng. Arkitekturformat kräver inte att vissa tekniker används men vissa tekniker passar bra för vissa arkitekturer. Till exempel passar containrar bra för mikrotjänster.

Vi har identifierat en uppsättning arkitekturformat som vanligtvis hittas i molnprogram. Artikeln innehåller följande information för varje format:

• En beskrivning av och ett logiskt diagram för formatet.
• Rekommendationer för när du ska välja det här formatet.
• Fördelar, utmaningar och bästa metoder.
• En rekommenderad distribution som använder relevanta Azure-tjänster.

En snabb genomgång av formaten

Det här avsnittet ger en snabb genomgång av de arkitekturformat som vi har identifierat samt några övergripande överväganden för deras användning. Mer detaljerad information finns i de länkade avsnitten.

N-nivå

N-nivå är en traditionell arkitektur för företagsprogram. Beroenden hanteras genom att dela in programmet i lager som utför logiska funktioner, till exempel presentation, affärslogik och dataåtkomst. Ett lager kan bara anropa i lager som finns nedanför. Men de här vågräta lagren kan vara en belastning. Det kan vara svårt att introducera ändringar i en del av programmet utan att röra resten av programmet. Det gör frekventa uppdateringar till en utmaning och begränsar hur snabbt nya funktioner kan läggas till.

N-nivå passar utmärkt för migrering av befintliga program som redan använder lagerarkitektur. Därför finns N-nivå oftast i lösningar med infrastruktur som en tjänst (IaaS) eller program som använder en blandning av IaaS och hanterade tjänster.

Web-Queue-Worker

För en ren PaaS-lösning bör du använda en Web-Queue-Worker -arkitektur. I det här formatet har programmet en webbklient som hanterar HTTP-begäranden och en serverarbetsroll som utför processorintensiva uppgifter eller långvariga åtgärder. Klientdelen kommunicerar med arbetsrollen via en asynkron meddelandekö.

Web-Queue-Worker passar för relativt enkla domäner med några resursintensiva uppgifter. Liksom N-nivå är arkitekturen lätt att förstå. Användningen av hanterade tjänster förenklar distribution och drift. Men med komplexa domäner kan det vara svårt att hantera beroenden. Klientdelen och arbetsrollen kan lätt bli stora, monolitiska komponenter som är svåra att underhålla och uppdatera. Som med N-nivå kan det här minska frekvensen för uppdateringar och begränsa innovation.

Mikrotjänster

Om programmet har en mer komplex domän bör du flytta till en arkitektur med mikrotjänster . Ett mikrotjänstprogram består av många små, oberoende tjänster. Varje tjänst implementerar en affärsfunktion. Tjänsterna är löst sammansatta med kommunikation via API-kontrakt.

Varje tjänst kan bestå av ett litet, fokuserat utvecklingsteam. Enskilda tjänster kan distribueras utan mycket samordning mellan teamen, vilket skapar bra förutsättningar för frekventa uppdateringar. En mikrotjänstarkitektur är mer komplex att skapa och hantera än N-nivå eller Web-Queue-Worker. Den kräver en mogen utvecklings- och DevOps-kultur. Men rätt utfört kan det här formatet leda till högre hastighet, snabbare innovation och en mer återhämtningsbar arkitektur.

Händelsedriven arkitektur

Händelsedriven arkitektur använder en publicera/prenumerera-modell, där producenter publicerar händelser och konsumenter prenumererar på dem. Producenterna är oberoende av konsumenterna och konsumenterna är oberoende av varandra.

Du kan använda en händelsedriven arkitektur för program som matar in och bearbetar en stor mängd data med mycket låg fördröjning. Formatet är också användbart när olika undersystem måste utföra olika typer av bearbetning på samma händelsedata.

Stordata, Big Compute

Stordata och Big Compute är specialiserade arkitekturformat för arbetsbelastningar som passar för vissa specifika profiler. Stordata delar in en mycket stor datauppsättning i segment och utför parallell bearbetning i hela uppsättningen, för analys och rapportering. Big Compute, även kallat databehandling med höga prestanda (HPC), gör parallella beräkningar i ett stort antal (tusentals) kärnor. Domäner omfattar simuleringar, modellering och 3D-rendering.

Arkitekturformat som begränsningar

Ett arkitekturformat sätter begränsningar på designen, inklusive uppsättningen element som kan visas och de tillåtna relationerna mellan de elementen. Begränsningar guidar ”formen” för en arkitektur genom att begränsa den totala mängden val. När en arkitektur följer begränsningarna för ett visst format kommer vissa önskvärda egenskaper fram.

Till exempel är begränsningarna i mikrotjänster:

• En tjänst representerar ett enda ansvar.
• Varje tjänst är oberoende av de andra.
• Data är privata för tjänsten som äger dem. Tjänster delar inte data.

Genom att följa de här begränsningarna växer ett system fram där tjänster kan distribueras separat, felen är isolerade, uppdateringar ofta är möjliga och det är enkelt att introducera nya tekniker i programmet.

Innan du väljer ett arkitekturformat ser du till att du förstår de underliggande principerna och begränsningarna för det formatet. Annars kan du få en design som följer formatet på en ytlig nivå men som inte uppnår det formatets fulla potential. Det är också viktigt att vara pragmatiskt. Ibland är det bättre att lätta på en begränsning, istället för att insistera på arkitektonisk renhet.

I följande tabell sammanfattas hur varje format hanterar beroenden och de domäntyper som passar bäst för vart och ett.

Arkitekturformat	Beroendehantering	Domäntyp
N-nivå	Vågräta nivåer delade av undernät	Traditionell företagsdomän. Uppdateringsfrekvensen är låg.
Web-queue-worker	Klient- och serverjobb, fristående med asynkrona meddelanden.	Relativt enkel domän med några resursintensiva uppgifter.
Mikrotjänster	Lodrätt (funktionellt) uppdelade tjänster som anropar varandra vida API:er.	Komplicerad domän. Frekventa uppdateringar.
Händelsedriven arkitektur	Producent/konsument. Oberoende vy per undersystem.	IoT- och realtidssystem.
Stordata	Dela upp stor datauppsättning i små segment. Parallell bearbetning av lokala datauppsättningar.	Batchanalys och dataanalys i realtid. Förutsägningsanalys med ML.
Big Compute	Dataallokering till tusentals kärnor.	Beräkningsintensiva domäner som simulering.

Tänk på utmaningar och fördelar

Begränsningar skapar även utmaningar, så det är viktigt att förstå avvägningarna när du antar något av de här formaten. Väger fördelarna med arkitekturformatet upp utmaningarna, för den här underdomänen och begränsade kontexten.

Här är några av typerna av utmaningar att tänka på när du väljer ett arkitekturformat:

• Komplexitet. Är arkitekturens komplexitet motiverad för domänen? Och omvänt: är formatet för enkelt för domänen? I så fall riskerar du att få en "stor lerklump" eftersom arkitekturen inte hjälper dig att hantera beroenden på rätt sätt.

• Asynkrona meddelanden och slutlig konsekvens. Asynkrona meddelanden kan användas till att frikoppla tjänster och öka pålitligheten (eftersom meddelanden kan göras om) och skalbarheten. Detta medför emellertid även utmaningar med att hantera slutlig konsekvens, samt möjliga dubblettmeddelanden.

• Kommunikation mellan tjänster. När du delar upp ett program i separata tjänster finns det en risk att kommunikationen mellan tjänster orsakar oacceptabla svarstider eller skapar överbelastning på nätverket (t.ex. i en mikrotjänstarkitektur).

• Hanterbarhet. Hur svårt är det att hantera programmet, övervaka, distribuera uppdateringar och så vidare?

Relaterade resurser

• Tio designprinciper för Azure-program
• Skapa program i Microsoft Cloud
• Metodtips i molnprogram
• Designmönster för molnet
• Prestandatestning och antimönster för molnprogram
• Skapa lösningar för flera klientorganisationer i Azure
• Arkitektur för verksamhetskritisk arbetsbelastning i Azure
• Arkitektur för nystartade företag