Styly architektury

Styl architektury je řada architektur, které sdílejí specifické vlastnosti. N-tier je běžným stylem architektury například. V poslední době začínají architektury mikroslužeb získávat laskavost. Styly architektury nevyžadují použití konkrétních technologií, ale některé technologie jsou vhodnější pro určité architektury. Kontejnery jsou například vhodné pro mikroslužby.

Identifikovali jsme sadu stylů architektury, které se běžně vyskytují v cloudových aplikacích. Článek pro každý styl obsahuje následující součásti:

• Popis a logický diagram stylu
• Doporučení, kdy zvolit tento styl
• Výhody, výzvy a osvědčené postupy
• Doporučené nasazení, které používá relevantní služby Azure

Rychlá prohlídka stylů

Tato část obsahuje stručný přehled stylů architektury, které jsme identifikovali, spolu s některými důležitými aspekty jejich použití. Tento seznam není vyčerpávající. Další podrobnosti najdete v odkazovaných článcích.

N-vrstvá

Diagram znázorňuje vrstvenou strukturu N-úrovňové architektury s jasným oddělením mezi komponentami. Požadavky klientů se před dosažením webové vrstvy zadávají prostřednictvím firewallu webových aplikací (WAF), který poskytuje filtrování zabezpečení. Webová vrstva slouží jako prezentační vrstva. Zpracovává interakce uživatelů a požadavky směrování na příslušné součásti obchodní logiky. Z webové vrstvy se vynoří dvě odlišné cesty: jedna cesta je přímo do střední vrstvy pro synchronní operace, zatímco jiná cesta používá infrastrukturu zasílání zpráv ke komunikaci se střední vrstvou dvě pro asynchronní zpracování. Obě střední vrstvy představují vrstvy obchodní logiky, které zpracovávají požadavky a pracují s datovou vrstvou prostřednictvím mechanismů ukládání do mezipaměti za účelem optimalizace výkonu. Datová vrstva slouží jako základ. Ukládá a spravuje data aplikací a současně podporuje obě střední vrstvy prostřednictvím vzorů přístupu k datům uloženým v mezipaměti.

N-vrstvá je tradiční architektura pro podnikové aplikace, která rozděluje aplikaci na logické vrstvy a fyzické vrstvy. Každá vrstva má určitou odpovědnost a vrstvy spravují závislosti pouze voláním do vrstev pod nimi. Mezi typické vrstvy patří prezentace, obchodní logika a přístup k datům.

N-úrovňové architektury jsou vhodné pro migraci stávajících aplikací, které už používají vrstvenou architekturu. Tento přístup vyžaduje minimální změny při přechodu na Azure a podporuje smíšená prostředí s místními i cloudovými komponentami. Horizontální vrstvení ale může ztížit zavedení změn, aniž by to ovlivnilo více částí aplikace, což omezuje flexibilitu pro časté aktualizace.

Web –Queue-Worker

Diagram znázorňuje čisté oddělení mezi komponentami pro zpracování na pozadí a uživatelským rozhraním. Interakce klientů začínají ověřováním prostřednictvím zprostředkovatele identity před dosažením webového front-endu, který slouží jako primární uživatelské rozhraní. Webový front-end udržuje tři odlišné provozní vztahy: může přímo komunikovat se vzdálenými službami pro externí integrace, přistupovat k databázi pro okamžité operace s daty a vytvořit frontu pracovních položek pro zpracování na pozadí. Fronta slouží jako mechanismus oddělení. Umožňuje komponentě pracovního procesu zpracovávat úlohy náročné na prostředky nebo dlouhotrvající úlohy nezávisle na uživatelských požadavcích. Pracovník načte úlohy z fronty a provádí operace s databází, přičemž infrastruktura ukládání do mezipaměti podporuje jak webový front-end, tak i pracovníka pro optimalizovaný přístup k datům. Statický obsah je také distribuován prostřednictvím sítě pro doručování obsahu (CDN), aby se zlepšil výkon klientských aplikací.

Web-Queue-Worker je architektura, která se skládá z webového front-endu, fronty zpráv a back-endového pracovního procesu. Webový front-end zpracovává požadavky HTTP a interakce uživatelů, zatímco pracovní proces provádí úlohy náročné na prostředky, dlouhotrvající pracovní postupy nebo dávkové operace. Komunikace mezi front-endem a pracovním procesem probíhá prostřednictvím asynchronní fronty zpráv.

Tato architektura je ideální pro aplikace s relativně jednoduchými doménami, které mají určité požadavky na zpracování náročné na prostředky. Je snadné pochopit a nasadit spravované Azure služby, jako je App Service a Azure Functions. Front-end a pracovní proces můžete škálovat nezávisle, abyste zajistili flexibilitu při přidělování prostředků. Ale bez pečlivého návrhu se obě komponenty mohou stát velkými a monolitickými.

Mikroslužby

Diagram znázorňuje architekturu distribuovaných mikroslužeb uspořádanou do různých funkčních vrstev. Klientské aplikace a externí systémy na levé straně iniciují požadavky, které procházejí centralizovanou bránou rozhraní API, která slouží jako jediný vstupní bod a mechanismus směrování pro celý systém. Brána rozhraní API směruje požadavky na příslušnou vrstvu mikroslužeb, která obsahuje více typů služeb: doménové služby, které zapouzdřují specifické obchodní funkce, služby složení, které orchestrují interakce mezi doménovými službami a jednotlivými službami, které zpracovávají diskrétní funkce. Každá mikroslužba udržuje autonomii dat prostřednictvím vlastní vyhrazené databáze. Diagram znázorňuje polyglotní přístup k ukládání dat pomocí databází SQL i NoSQL přizpůsobených specifickým potřebám dat každé služby. Mikroslužby komunikují asynchronně prostřednictvím middlewaru orientovaného na zprávy. Tento přístup umožňuje volné propojení pomocí vydavatelsko-odběratelských vzorů a interakcí řízených událostmi. Tři základní vrstvy infrastruktury podporují tuto distribuovanou architekturu: systémy pozorovatelnosti poskytují komplexní monitorování, protokolování a distribuované trasování napříč hranicemi služeb. Platformy pro správu a orchestraci zpracovávají automatizované nasazení, škálování a zjišťování služeb. Sady nástrojů DevOps umožňují průběžné integrace, testování a kanály doručování pro nezávislá nasazení služeb.

Architektura mikroslužeb rozloží aplikace do kolekce malých autonomních služeb. Každá služba implementuje jednu obchodní funkci v rámci omezeného kontextu a je samostatná s vlastním úložištěm dat. Služby komunikují prostřednictvím dobře definovaných rozhraní API a dají se vyvíjet, nasazovat a škálovat nezávisle.

Mikroslužby umožňují týmům pracovat nezávisle a podporovat časté aktualizace s vyšší rychlostí vydávání. Tato architektura je vhodná pro složité domény, které vyžadují časté změny a inovace. Přináší ale významnou složitost v oblastech, jako je zjišťování služeb, konzistence dat a správa distribuovaných systémů. Úspěch vyžaduje vyspělé postupy vývoje a DevOps, díky kterým je vhodnější pro organizace s pokročilými technickými možnostmi.

Architektura založená na událostech

Diagram znázorňuje oddělený asynchronní komunikační model, který je zásadní pro architektury řízené událostmi. Více výrobců událostí funguje nezávisle. Generované streamy událostí založené na obchodních aktivitách, interakcích uživatelů nebo změnách stavu systému bez jakýchkoli znalostí podřízených spotřebitelů. Producenti odvádějí své události do centralizovaného systému pro příjem událostí, který slouží jako inteligentní zprostředkovatel. Zprostředkovatel přijímá, ověřuje, udržuje a spolehlivě distribuuje události napříč architekturou. Komponenta pro příjem událostí slouží jako kritický bod oddělení. Zajišťuje, aby producenti zůstali izolovaní od spotřebitelů, zatímco poskytují záruky ohledně doručování, objednávání a stálosti událostí. Z tohoto centrálního uzlu se události distribuují prostřednictvím vzoru rozvětvení několika nezávislým příjemcům událostí umístěným na pravé straně diagramu. Každý uživatel představuje jedinečnou obchodní schopnost nebo službu, která se přihlašuje k odběru konkrétních typů událostí, které jsou relevantní pro její povinnosti v doméně. Příjemci zpracovávají události asynchronně a paralelně, což systému umožňuje horizontálně škálovat při zachování volného párování. Tento model architektury odstraňuje přímé závislosti mezi producenty a spotřebiteli. Dovoluje každé komponentě vyvíjet se, škálovat a nasazovat nezávisle a současně zachovává odolnost systému díky možnostem ukládání do vyrovnávací paměti a opětovného pokusu zprostředkovatele událostí.

Architektury řízené událostmi používají model publikování a odběru , kde producenti událostí generují streamy událostí a příjemci událostí reagují na tyto události téměř v reálném čase. Producenti a spotřebitelé jsou od sebe odděleni, přičemž komunikace probíhá prostřednictvím kanálů událostí nebo zprostředkovatelů. Tato architektura podporuje jednoduché zpracování událostí i komplexní analýzu vzorů událostí.

Architektury řízené událostmi jsou excelované ve scénářích, které vyžadují zpracování v reálném čase s minimální latencí. Mezi příklady patří řešení IoT, finanční obchodní systémy nebo aplikace, které potřebují zpracovávat velké objemy streamovaných dat. Architektury řízené událostmi poskytují vynikající škálovatelnost a izolaci chyb, ale představují problémy související s zaručeným doručováním, řazením událostí a konečnou konzistencí napříč distribuovanými komponentami.

Velký objem dat

Diagram představuje komplexní architekturu velkých objemů dat se dvěma doplňkovými kanály zpracování, které zpracovávají různé rychlosti dat a analytické požadavky. Kanál dávkového zpracování začíná různými zdroji dat, které se oddávají do škálovatelných systémů úložiště dat, obvykle datových jezer nebo distribuovaných systémů souborů umožňujících ukládat obrovské objemy strukturovaných, částečně strukturovaných a nestrukturovaných dat. Komponenta dávkového zpracování provádí rozsáhlé transformace, agregace a analytické výpočty historických dat. Funguje v naplánovaných intervalech nebo v případech, kdy se hromadí dostatečná data. Výsledky dávkového zpracování procházejí dvěma způsoby: přímo do analytických systémů a systémů generování sestav pro okamžitou spotřebu a do úložišť analytických dat, kde jsou zpracovávaná data trvale uložena v optimalizovaných formátech pro komplexní dotazy a historickou analýzu. Kanál zpracování v reálném čase zachycuje streamovaná data prostřednictvím systémů pro příjem zpráv v reálném čase, které zpracovávají vysokorychlostní datové proudy ze zdrojů, jako jsou zařízení IoT, webové aplikace nebo transakční systémy. Komponenty zpracování datových proudů analyzují tato data v pohybu, provádějí agregace v reálném čase, filtrování a detekci vzorů za účelem generování okamžitých přehledů. Výsledky v reálném čase také následují dvě cesty: dodávají se přímo do analýz a reportování pro okamžité dashboardy a upozornění a zároveň do stejných analytických úložišť dat, aby vytvořily jednotné zobrazení, které kombinuje historická a aktuální data. Vrstva orchestrace pokrývá obě pipeline. Koordinuje složité pracovní postupy, spravuje závislosti mezi dávkovými a streamovanými úlohami, plánuje úlohy zpracování a zajišťuje konzistenci dat v celé architektuře. Tato orchestrace umožňuje vytvářet architektury lambda, ve kterých může dávkové i zpracování v reálném čase pracovat se stejnými datovými sadami a poskytuje komplexní historickou analýzu i okamžitou provozní inteligenci.

Architektury velkých objemů dat zpracovávají příjem, zpracování a analýzu dat, která jsou pro tradiční databázové systémy příliš velká nebo složitá. Mezi tyto architektury obvykle patří komponenty pro úložiště dat (například datová jezera), dávkové zpracování pro historickou analýzu, zpracování datových proudů pro přehledy v reálném čase a analytické úložiště dat pro generování sestav a vizualizaci.

Architektury velkých objemů dat jsou nezbytné pro organizace, které potřebují extrahovat přehledy z masivních datových sad, podporovat prediktivní analýzy pomocí strojového učení nebo zpracovávat streamovaná data ze zařízení IoT v reálném čase. Moderní implementace často používají spravované služby, jako je Microsoft Fabric, aby zjednodušily vytváření a údržbu řešení pro velké objemy dat.

Výkonné výpočetní systémy

Diagram znázorňuje sofistikovaný systém distribuce úloh a operačního systému navrženého pro vysoce výkonné výpočetní úlohy. Klientské aplikace v vstupním bodě odesílaly výpočetní úlohy prostřednictvím rozhraní fronty úloh, které funguje jako vyrovnávací paměť a mechanismus příjmu příchozích žádostí o práci. Úlohy se přetékají do centralizovaného plánovače nebo koordinační komponenty, která slouží jako inteligentní mozek systému, který zodpovídá za analýzu charakteristik úloh, požadavků na prostředky a výpočetních závislostí. Plánovač provádí důležité funkce, včetně rozkladu úloh, plánování přidělení prostředků a optimalizace úloh na základě dostupných výpočetních prostředků a vzájemné závislosti úloh. Z tohoto centrálního koordinačního bodu plánovač inteligentně směruje práci na dvou různých cestách operací na základě výpočetních charakteristik jednotlivých úloh. První cesta směruje práci do prostředí paralelního zpracování úloh navržených pro trapné paralelní úlohy, kde se jednotlivé úlohy můžou spouštět nezávisle bez nutnosti komunikace mezi jednotkami zpracování. Tyto paralelní úlohy se distribuují napříč stovkami nebo tisíci jader současně, přičemž každá jádro zpracovává samostatné jednotky práce izolovaně. Druhá cesta zpracovává úzce propojené úlohy, které vyžadují častou komunikaci mezi procesy, přístup ke sdílené paměti nebo vzory synchronizovaných operací. Tyto úzce propojené úlohy obvykle používají vysokorychlostní propojení, jako je InfiniBand nebo sítě vzdáleného přímého přístupu do paměti (RDMA), aby bylo možné rychle vyměňovat data mezi uzly zpracování. Plánovač nepřetržitě monitoruje obě provozní prostředí, spravuje přidělování prostředků, zpracovává odolnost proti chybám a optimalizuje výkon dynamickým přizpůsobením distribuce práce na základě systémové kapacity, priorit úloh a požadavků na dokončení. Rozdělený přístup umožňuje architektuře efektivně zpracovávat rozmanité výpočetní úlohy a zároveň maximalizovat využití prostředků napříč celou výpočetní infrastrukturou.

Architektury velkých výpočetních prostředků podporují rozsáhlé úlohy, které pro výpočetně náročné operace vyžadují stovky nebo tisíce jader. Práce se dá rozdělit na samostatné úlohy, které běží na mnoha jádrech současně, přičemž každý úkol přijímá vstup, zpracovává je a vytváří výstup. Úkoly můžou být nezávislé (trapně paralelní) nebo úzce propojené vyžadující vysokorychlostní komunikaci.

Velký výpočetní výkon je nezbytný pro simulace, modelování finančních rizik, vědecké výpočty, analýzu technického zatížení a 3D vykreslování. Azure nabízí možnosti, jako je Azure Batch pro spravované úlohy s velkými výpočetními prostředky nebo sadu HPC Pack pro tradiční správu clusterů. Tyto architektury můžou v případě potřeby rozšířit kapacitu na vyžádání a škálovat na tisíce jader.

Styly architektury jako omezení

Styl architektury umisťuje omezení návrhu, včetně sady prvků, které se můžou objevit, a povolených vztahů mezi těmito prvky. Omezení řídí "tvar" architektury omezením vesmíru voleb. Když architektura odpovídá omezením určitého stylu, objeví se některé žádoucí vlastnosti.

Mezi omezení v mikroslužbách patří například:

• Služba představuje jedinou odpovědnost.
• Každá služba je nezávislá na ostatních službách.
• Data jsou pro službu, která je vlastníkem, soukromá. Služby nesdílely data.

Když dodržujete tato omezení, získáte systém, který vám umožní provést následující akce:

• Nezávisle nasaďte služby.
• Izolujte chyby.
• Nabízení častějších aktualizací
• Jednodušší zavedení nových technologií do aplikace

Každý styl architektury má své vlastní kompromisy. Než zvolíte styl architektury, je nezbytné porozumět základním principům a omezením. Bez toho, abyste porozuměli, riskujete, že vytvoříte návrh, který povrchně odpovídá stylu, aniž by si uvědomil jeho plné výhody. Zaměřte se více na to, proč vybíráte konkrétní styl, než jak ho implementovat. Buďte praktickí. Někdy je lepší uvolnit omezení než honit čistotu architektury.

V ideálním případě by měla být volba stylu architektury vykonána se vstupem od informovaných zúčastněných stran, které se podílejí na pracovních úlohách. Tým úloh by měl začít identifikací povahy problému, který řeší. Pak by měly definovat klíčové obchodní faktory a odpovídající charakteristiky architektury, označované také jako nefunkční požadavky, a určit jejich prioritu. Pokud je například čas uvedení na trh kritický, může tým určit prioritu udržovatelnosti, testovatelnosti a spolehlivosti, aby umožnil rychlé nasazení. Pokud má tým úzká rozpočtová omezení, může mít přednost proveditelnost a jednoduchost. Výběr a udržování stylu architektury není jednorázový úkol. Vyžaduje průběžné měření, ověřování a upřesnění. Vzhledem k tomu, že pozdější změna směru architektury může být nákladná, je často vhodné investovat více úsilí předem, aby podporovala dlouhodobou efektivitu a snížila rizika.

Následující tabulka shrnuje, jak jednotlivé styly spravují závislosti a typy domén, které jsou pro každý styl nejvhodnější.

Styl architektury	Správa závislostí	Typ domény
N-vrstva	Vodorovné vrstvy dělené podsítím	Tradiční obchodní doména. Frekvence aktualizací je nízká.
Web-Queue-Worker	Front-endové a back-endové úlohy oddělené asynchronním zasíláním zpráv.	Relativně jednoduchá doména s některými úlohami náročnými na prostředky
Mikroslužby	Vertikálně (funkčně) rozložené služby, které se vzájemně volají prostřednictvím rozhraní API.	Složitá doména. Časté aktualizace.
Architektura řízená událostmi	Producent nebo spotřebitel. Nezávislé zobrazení pro každý subsystém.	Internet věcí (IoT) a systémy v reálném čase.
Velké objemy dat	Rozdělte obrovskou datovou sadu na malé bloky dat. Paralelní zpracování místních datových sad	Analýza dat v dávkovém režimu a v reálném čase. Prediktivní analýza pomocí strojového učení
Velké výpočetní prostředky	Přidělení dat tisícům jader	Domény náročné na výpočetní prostředky, jako je simulace.

Zvažte výzvy a výhody

Omezení také vytvářejí výzvy, takže je důležité pochopit kompromisy při přijetí některého z těchto stylů. Určete, jestli výhody stylu architektury převáží problémy , pro tuto subdoménu a ohraničený kontext.

Při výběru stylu architektury zvažte následující typy problémů:

• Komplexnost: Složitost architektury musí odpovídat doméně. Pokud je příliš zjednodušená, může to vést k velkému míči bláta, kde závislosti nejsou dobře spravované a struktura se rozpadne.

• Asynchronní zasílání zpráv a konečná konzistence: Asynchronní zasílání zpráv se používá k oddělení služeb a ke zlepšení spolehlivosti, protože je možné opakovat zprávy. Zvyšuje také škálovatelnost. Asynchronní zasílání zpráv ale také vytváří problémy při zpracování konečné konzistence a možnosti duplicitních zpráv.

• Komunikace mezi službami: Rozložení aplikace do samostatných služeb může zvýšit komunikační režii. V architekturách mikroslužeb toto přetížení často vede k problémům s latencí nebo zahlcení sítě.

• Ovladatelnost: Správa aplikace zahrnuje úlohy, jako je monitorování, nasazování aktualizací a udržování provozního stavu.

Související prostředky

• Deset principů návrhu pro aplikace Azure

Další kroky

• Vytváření aplikací v Microsoft Cloudu
• Osvědčené postupy v cloudových aplikacích
• Vzory návrhů pro cloud
• Testování výkonu a antipatterny pro cloudové aplikace
• Navrhněte řešení pro více nájemníků na Azure
• Architektura pracovních zátěží kritických pro provoz na Azure
• Architektura pro startupy