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. Observera att listan inte är fullständig. 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.

Varje arkitekturstil har sina egna kompromisser. Innan du väljer något arkitekturformat bör du därför se 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. Du måste vara mer uppmärksam på varför du väljer en viss arkitekturstil än hur du implementerar den. 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.

Att välja en lämplig arkitekturstil bör göras helst med konsensus av informerade arbetsbelastningsintressenter. Arbetsbelastningsteamet bör först identifiera vilken typ av problem de försöker lösa. Sedan bör de identifiera affärsdrivande faktorer och motsvarande arkitekturegenskaper (även kallade icke-funktionella krav) och sedan prioritera dem. Om de till exempel behöver kortare tid till marknaden kan de prioritera underhåll, testbarhet och pålitlighet genom snabba distributionsfunktioner. Eller om arbetsbelastningsteamet har begränsad budget kan de prioritera genomförbarhet och enkelhet. Att välja och underhålla en arkitekturstil är inte en engångsaktivitet utan en kontinuerlig metod: arkitekturen bör kontinuerligt mätas, valideras och finjusteras över tid. Det finns vanligtvis betydande kostnader för att byta arkitekturstil, så mer arbete i förväg kan motiveras för långsiktig teameffektivitet och riskreducering.

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

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
• Mönster för molndesign
• Prestandatestning och antimönster för molnprogram
• Skapa lösningar för flera klientorganisationer i Azure
• Verksamhetskritisk arbetsbelastningsarkitektur i Azure
• Arkitektur för nystartade företag