Arkitekturstilar

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

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

• En beskrivning och ett logiskt diagram över formatet
• Rekommendationer för när du ska välja det här formatet
• Fördelar, utmaningar och metodtips
• En rekommenderad distribution som använder 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 överväganden på hög nivå för deras användning. Den här listan är inte fullständig. Läs mer i de länkade artiklarna.

N-nivå

N-nivån är en traditionell arkitektur för företagsprogram som delar upp ett program i logiska lager och fysiska nivåer. Varje lager har ett specifikt ansvar, och lager hanterar beroenden genom att bara anropa i lager under dem. Vanliga lager är presentation, affärslogik och dataåtkomst.

N-nivåarkitekturer passar bra för migrering av befintliga program som redan använder en arkitektur i flera lager. Den här metoden kräver minimala ändringar när du flyttar till Azure och stöder blandade miljöer med både lokala komponenter och molnkomponenter. Men den vågräta skiktningen kan göra det svårt att införa ändringar utan att påverka flera delar av programmet, vilket begränsar flexibiliteten för frekventa uppdateringar.

Webb-kö-arbetare

Web-Queue-Worker är en arkitektur som består av en webbklientdel, en meddelandekö och en serverdelsarbetare. Webbklientdelen hanterar HTTP-begäranden och användarinteraktioner, medan arbetaren utför resursintensiva uppgifter, långvariga arbetsflöden eller batchåtgärder. Kommunikationen mellan klientdelen och arbetaren sker via en asynkron meddelandekö.

Den här arkitekturen är perfekt för program med relativt enkla domäner som har vissa resursintensiva bearbetningskrav. Det är enkelt att förstå och distribuera med hanterade Azure-tjänster som App Service och Azure Functions. Du kan skala frontend-delen och arbetarprocessen oberoende av varandra för att ge flexibilitet i resursallokeringen. Men utan noggrann design kan båda komponenterna bli stora och monolitiska.

Mikrotjänster

Mikrotjänstarkitekturen delar upp program i en samling små, autonoma tjänster. Varje tjänst implementerar en enda affärsfunktion i en begränsad kontext och är fristående med sin egen datalagring. Tjänster kommunicerar via väldefinierade API:er och kan utvecklas, distribueras och skalas separat.

Mikrotjänster gör det möjligt för team att arbeta autonomt och stödja frekventa uppdateringar med högre lanseringshastighet. Den här arkitekturen passar bra för komplexa domäner som kräver frekventa ändringar och innovation. Men det medför betydande komplexitet inom områden som tjänstidentifiering, datakonsekvens och distribuerad systemhantering. Framgång kräver mogen utveckling och DevOps-metoder, vilket gör det mer lämpligt för organisationer som har avancerade tekniska funktioner.

Händelsedriven arkitektur

Händelsedrivna arkitekturer använder en publiceringsprenumereringsmodell där händelseproducenter genererar strömmar av händelser och händelsekonsumenter svarar på dessa händelser nästan i realtid. Producenter och konsumenter frikopplas från varandra, med kommunikation som sker via händelsekanaler eller mäklare. Den här arkitekturen stöder både enkel händelsebearbetning och komplex händelsemönsteranalys.

Händelsedrivna arkitekturer utmärker sig i scenarier som kräver realtidsbearbetning med minimal svarstid. Några exempel är IoT-lösningar, finansiella handelssystem eller program som behöver bearbeta stora mängder strömmande data. Händelsedrivna arkitekturer ger utmärkt skalbarhet och felisolering, men medför utmaningar kring garanterad leverans, händelseordning och eventuell konsistens mellan distribuerade komponenter.

Stordata

Stordataarkitekturer hanterar inmatning, bearbetning och analys av data som är för stora eller komplexa för traditionella databassystem. Dessa arkitekturer omfattar vanligtvis komponenter för datalagring (t.ex. datasjöar), batchbearbetning för historisk analys, dataströmbearbetning för realtidsinsikter och analysdatalager för rapportering och visualisering.

Stordataarkitekturer är viktiga för organisationer som behöver extrahera insikter från massiva datamängder, stödja förutsägelseanalys med hjälp av maskininlärning eller bearbeta strömmande data i realtid från IoT-enheter. Moderna implementeringar använder ofta hanterade tjänster som Microsoft Fabric för att förenkla komplexiteten med att skapa och underhålla stordatalösningar.

Storskalig Beräkning

Stora beräkningsarkitekturer stöder storskaliga arbetsbelastningar som kräver hundratals eller tusentals kärnor för beräkningsintensiva åtgärder. Arbetet kan delas upp i diskreta uppgifter som körs över många kärnor samtidigt, där varje uppgift tar indata, bearbetar den och producerar utdata. Uppgifter kan vara antingen oberoende (pinsamt parallella) eller nära kopplade som kräver höghastighetskommunikation.

Stor beräkning är viktigt för simuleringar, modellering av finansiella risker, vetenskaplig databehandling, teknisk stressanalys och 3D-rendering. Azure tillhandahåller alternativ som Azure Batch för hanterade stora beräkningsarbetsbelastningar eller HPC Pack för mer traditionell klusterhantering. Dessa arkitekturer kan öka kapaciteten på begäran och skala till tusentals kärnor när det behövs.

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.

När du följer dessa begränsningar får du ett system som gör att du kan vidta följande åtgärder:

• Distribuera tjänster oberoende av varandra.
• Isolera felaktigheter.
• Skicka mer frekventa uppdateringar.
• Introducera ny teknik i programmet enklare.

Varje arkitekturstil har sina egna kompromisser. Innan du väljer ett arkitekturformat är det viktigt att du förstår de underliggande principerna och begränsningarna. Utan den förståelsen riskerar du att skapa en design som ytligt överensstämmer med stilen utan att inse dess fulla fördelar. Fokusera mer på varför du väljer ett specifikt format än på hur du implementerar det. Var praktisk. Ibland är det bättre att lätta på en begränsning än att jaga arkitektonisk renhet.

Helst bör valet av arkitekturstil göras med indata från informerade arbetsbelastningsintressenter. Arbetsbelastningsteamet bör börja med att identifiera vilket problem de löser. De bör sedan definiera viktiga affärsdrivrutiner och motsvarande arkitekturegenskaper, även kallade icke-funktionella krav, och prioritera dem. Om tiden till marknaden till exempel är kritisk kan teamet prioritera underhåll, testbarhet och tillförlitlighet för att möjliggöra snabb distribution. Om teamet har snäva budgetbegränsningar kan genomförbarhet och enkelhet ha företräde. Att välja och upprätthålla ett arkitekturformat är inte en engångsuppgift. Det kräver löpande mätning, validering och förfining. Eftersom det kan bli dyrt att ändra arkitekturriktningen senare är det ofta värt att investera mer arbete i förväg för att stödja långsiktig effektivitet och minska riskerna.

I följande tabell sammanfattas hur varje format hanterar beroenden och vilka typer av domäner som passar bäst för varje formatmall.

Överväg utmaningar och fördelar

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

Tänk på följande typer av utmaningar när du väljer ett arkitekturformat:

• Komplexitet: Arkitekturens komplexitet måste matcha domänen. Om det är för förenklat kan det resultera i en stor boll av lera, där beroenden inte hanteras väl och strukturen bryts ner.

• Asynkrona meddelanden och eventuell konsekvens: Asynkrona meddelanden används för att frikoppla tjänster och förbättra tillförlitligheten eftersom meddelanden kan göras om. Det förbättrar även skalbarheten. Men asynkrona meddelanden skapar också utmaningar när det gäller att hantera eventuell konsekvens och möjligheten att duplicera meddelanden.

• Kommunikation mellan tjänster: Att dela upp ett program i separata tjänster kan öka kommunikationskostnaderna. I mikrotjänstarkitekturer resulterar den här kostnaden ofta i problem med svarstid eller nätverksbelastning.

• Hanterbarhet: Hantering av programmet omfattar uppgifter som övervakning, distribution av uppdateringar och underhåll av drifthälsa.

Relaterade resurser

• Tio designprinciper för Azure-applikationer

Nästa steg

• Skapa program i Microsoft Cloud
• Metodtips i molnprogram
• Mönster för molndesign
• Prestandatestning och antimönster för molnprogram
• Designa multitenanta lösningar på Azure
• Verksamhetskritisk arbetsbelastningsarkitektur i Azure
• Arkitektur för nystartade företag