Dela via

Arkitekturstilar

En arkitekturstil är en serie arkitekturer som delar vissa egenskaper. N-nivån är till exempel ett vanligt arkitekturformat. På senare tid har mikrotjänstarkitekturer börjat få fördelar. Arkitekturformat kräver inte användning av vissa tekniker, men vissa tekniker passar bra för vissa arkitekturer. Containrar passar till exempel naturligt för mikrotjänster.

Vi har identifierat en uppsättning arkitekturformat som ofta finns i molnprogram. Artikeln för varje formatmall innehåller:

  • En beskrivning och ett logiskt diagram över stilen.
  • Rekommendationer för när du ska välja det här formatet.
  • Fördelar, utmaningar och metodtips.
  • En rekommenderad distribution med relevanta Azure-tjänster.

En snabb rundtur i stilarna

Det här avsnittet ger en snabb genomgång av de arkitekturformat som vi har identifierat, tillsammans med några övergripande överväganden för deras användning. Observera att listan inte är fullständig. Läs mer i de länkade ämnena.

N-nivå

Logiskt diagram över ett N-nivåarkitekturformat.

N-nivån är en traditionell arkitektur för företagsprogram. Beroenden hanteras genom att dela upp programmet i lager som utför logiska funktioner, till exempel presentation, affärslogik och dataåtkomst. Ett lager kan endast anropa lager som ligger under det. Den här vågräta skiktningen kan dock vara en belastning. Det kan vara svårt att införa ändringar i en del av programmet utan att röra resten av programmet. Det gör frekventa uppdateringar till en utmaning, vilket begränsar hur snabbt nya funktioner kan läggas till.

N-nivån passar naturligt för migrering av befintliga program som redan använder en arkitektur i flera lager. Därför ses N-nivån oftast i IaaS-lösningar (infrastruktur som en tjänst) eller program som använder en blandning av IaaS och hanterade tjänster.

Webb-kö-arbetare

Logiskt diagram över arkitekturformatet Web-Queue-Worker.

För en renodlad PaaS-lösning bör du överväga en web-queue-worker-arkitektur . I den här stilen har programmet en webbklientdel som hanterar HTTP-begäranden och en serverdelsarbetare som utför CPU-intensiva uppgifter eller långvariga åtgärder. Klientdelen kommunicerar med arbetaren via en asynkron meddelandekö.

Web-queue-worker är lämplig för relativt enkla domäner med vissa resursintensiva uppgifter. Precis som N-nivån är arkitekturen lätt att förstå. Användningen av hanterade tjänster förenklar distributionen och driften. Men med komplexa domäner kan det vara svårt att hantera beroenden. Front-end och arbetsprocessen kan enkelt bli stora, monolitiska komponenter som är svåra att underhålla och uppdatera. Precis som med N-nivån kan detta minska uppdateringsfrekvensen och begränsa innovationen.

Mikrotjänster

Logiskt diagram över arkitekturformatet för mikrotjänster.

Om ditt program har en mer komplex domän kan du överväga att flytta till en Arkitektur för mikrotjänster . Ett mikrotjänstprogram består av många små, oberoende tjänster. Varje tjänst implementerar en enda affärsfunktion. Tjänsterna är löst kopplade och kommunicerar via API-kontrakt.

Varje tjänst kan skapas av ett litet, fokuserat utvecklingsteam. Enskilda tjänster kan distribueras utan mycket samordning mellan team, vilket uppmuntrar till frekventa uppdateringar. En mikrotjänstarkitektur är mer komplex att bygga och hantera än både N-tier eller web-queue-worker. Det kräver en mogen utveckling och DevOps-kultur. Men om du gör rätt kan den här stilen leda till högre lanseringshastighet, snabbare innovation och en mer motståndskraftig arkitektur.

Händelsedriven arkitektur

Diagram över ett händelsedrivet arkitekturformat.

Event-Driven Architectures använder en publiceringsprenumereringsmodell (pub-sub), där producenter publicerar händelser och konsumenter prenumererar på dem. Producenterna är oberoende av konsumenterna och konsumenterna är oberoende av varandra.

Överväg en händelsedriven arkitektur för program som matar in och bearbetar en stor mängd data med mycket låg svarstid, till exempel IoT-lösningar. Formatet är också användbart när olika undersystem måste utföra olika typer av bearbetning på samma händelsedata.

Stordata, Storstarka beräkningar

Logiskt diagram över ett arkitekturformat för stordata.

Stordata och Big Compute är specialiserade arkitekturformat för arbetsbelastningar som passar vissa specifika profiler. Stordata delar upp en mycket stor datamängd i segment och utför parallell bearbetning över hela uppsättningen för analys och rapportering. Stor beräkning, även kallad högpresterande databehandling (HPC), gör parallella beräkningar över ett stort antal (tusentals) kärnor. Domäner omfattar simuleringar, modellering och 3D-rendering.

Arkitekturformat som begränsningar

Ett arkitekturformat begränsar designen, inklusive den uppsättning element som kan visas och de tillåtna relationerna mellan dessa element. Begränsningar vägleder en arkitekturs "form" genom att begränsa valuniversumet. När en arkitektur överensstämmer med begränsningarna för ett visst format uppstår vissa önskvärda egenskaper.

Till exempel omfattar begränsningarna i mikrotjänster:

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

Genom att följa dessa begränsningar uppstår ett system där tjänster kan distribueras oberoende av varandra, fel isoleras, frekventa uppdateringar ä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 överensstämmer med stilen på en ytlig nivå, men som inte uppnår hela potentialen för den stilen. 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 pragmatisk. Ibland är det bättre att lätta på en begränsning, snarare än 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 vilka typer av domäner som passar bäst för var och en.

Arkitekturstil Beroendehantering Domäntyp
N-nivå Vågräta nivåer indelade efter undernät Traditionell affärsdomän. Uppdateringsfrekvensen är låg.
Web-queue-worker Front-end och back-end jobb, frikopplade genom asynkron meddelandehantering. Relativt enkel domän med vissa resursintensiva uppgifter.
Mikrotjänster Vertikalt (funktionellt) neddelade tjänster som anropar varandra via API:er. Komplicerad domän. Frekventa uppdateringar.
Evenemangsstyrd arkitektur Producent/konsument. Självständig vy per undersystem. IoT- och realtidssystem.
Stordata Dela upp en enorm datamängd i små segment. Parallell bearbetning på lokala datauppsättningar. Batch- och realtidsdataanalys. Förutsägelseanalys med ML.
Storskalig beräkning Dataallokering till tusentals kärnor. Beräkningsintensiva domäner som simulering.

Överväg utmaningar och fördelar

Begränsningar skapar också utmaningar, så det är viktigt att förstå kompromisserna när du antar någon av dessa formatmallar. Uppväger fördelarna med arkitekturstilen utmaningarna för den här underdomänen och den avgränsade kontexten.

Här är några av de typer av utmaningar som du bör tänka på när du väljer ett arkitekturformat:

  • Komplexitet. Är arkitekturens komplexitet motiverad för din domän? Omvänt, är stilen för förenklad för din domän? I så fall riskerar du att få en "stor boll av lera", eftersom arkitekturen inte hjälper dig att hantera beroenden rent.

  • Asynkrona meddelanden och eventuell konsistens. Asynkrona meddelanden kan användas för att frikoppla tjänster och öka tillförlitligheten (eftersom meddelanden kan göras om) och skalbarhet. Detta skapar dock även utmaningar när det gäller att hantera eventuell konsekvens, samt möjligheten att duplicera meddelanden.

  • 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 nätverksbelastning (till exempel i en arkitektur för mikrotjänster).

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