Styly architektury
Styl architektury je řada architektur, které sdílí určité vlastnosti. Běžným stylem architektury je například n-vrstvá architektura. V nedávné době si začaly získávat přízeň také architektury mikroslužeb. Styly architektury nevyžadují použití konkrétních technologií, ale některé technologie jsou vhodné pro určité architektury. Například kontejnery jsou přirozeně vhodné pro mikroslužby.
Identifikovali jsme sadu stylů architektury, které se běžně vyskytují v cloudových aplikacích. Články týkající se jednotlivých stylů obsahují:
- Popis a logický diagram daného stylu.
- Doporučení, kdy tento styl zvolit.
- Výhody, výzvy a osvědčené postupy.
- Doporučené nasazení s použitím příslušných služeb Azure.
Stručný přehled stylů
Tato část obsahuje stručný přehled stylů architektury, které jsme identifikovali, společně s několika obecnými důležitými informacemi o jejich použití. Upozorňujeme, že seznam není vyčerpávající. Další podrobnosti najdete v odkazovaných tématech.
N-vrstvá architektura
N-vrstvá architektura je tradiční architektura pro podnikové aplikace. Závislosti se spravují rozdělením architektury do vrstev, které provádí logické funkce, jako je prezentace, obchodní logika a přístup k datům. Každá vrstva může provádět volání pouze do vrstev, které se nacházejí pod ní. Toto horizontální vrstvení však může představovat i nevýhodu. Může být obtížné zavádět změny v jedné části aplikace bez zásahu do zbývajících částí aplikace. To komplikuje časté provádění aktualizací a omezuje rychlost přidávání nových funkcí.
N-vrstvá architektura je přirozeně vhodná pro migraci existujících aplikací, které již využívají vrstvenou architekturu. Z tohoto důvodu se n-vrstvá architektura nejčastěji vyskytuje v řešeních infrastruktury jako služby (IaaS) nebo aplikacích, které využívají kombinaci IaaS a spravovaných služeb.
Architektura web-fronta-pracovní proces
Pro řešení čistě PaaS zvažte architekturu web-fronta-pracovní proces. V tomto stylu má aplikace webový front-end, který zpracovává požadavky HTTP, a back-end pracovní proces, který provádí úlohy náročné na procesor nebo dlouhotrvající operace. Front-end komunikuje s pracovním procesem prostřednictvím asynchronní fronty zpráv.
Architektura web-fronta-pracovní proces je vhodná pro poměrně jednoduchá prostředí s některými úlohami náročnými na prostředky. Podobně jako n-vrstvá architektura je tato architektura snadno pochopitelná. Použití spravovaných služeb zjednodušuje nasazení a operace. U složitých prostředí však může být obtížné spravovat závislosti. Z front-endu a pracovního procesu se snadno můžou stát velké, monolitické komponenty, které se obtížně spravují a aktualizují. Stejně jako u n-vrstvé architektury to může snížit frekvenci aktualizací a omezit inovace.
Mikroslužby
Pokud je prostředí vaší aplikace složitější, zvažte přesun na architekturu mikroslužeb. Aplikace mikroslužeb se skládá z mnoha malých a nezávislých služeb. Každá služba implementuje jednu obchodní funkci. Služby jsou volně propojené a komunikují prostřednictvím kontraktů rozhraní API.
Každou službu může sestavit malý, úzce zaměřený vývojový tým. Nasazování jednotlivých služeb nevyžaduje spoustu koordinace mezi týmy, což podporuje častější aktualizace. Architektura mikroslužeb je složitější na sestavení a správu než n-vrstvá architektura i architektura web-fronta-pracovní proces. Vyžaduje vyspělý vývoj a kulturu DevOps. Pokud se ale použije správně, může tento styl vést k vyšší rychlosti vydávání verzí, rychlejším inovacím a odolnější architektuře.
Architektura založená na událostech
Architektury založené na událostech využívají model publikování a odběru, ve kterém producenti publikují události a konzumenti se přihlašují k jejich odběru. Producenti jsou nezávislí na konzumentech a konzumenti jsou nezávislí na sobě navzájem.
Architekturu založenou na událostech zvažte pro aplikace, které ingestují a zpracovávají velké objemy dat s velmi nízkou latencí, jako jsou například řešení IoT. Tento styl je užitečný také v případě, že různé typy zpracování stejných dat událostí musí provádět různé subsystémy.
Velký objem dat, velký objem výpočtů
Velký objem dat a Velký objem výpočtů jsou specializované styly architektury pro úlohy, které odpovídají určitým konkrétním profilům. Styl Velký objem dat rozděluje velmi velké datové sady do bloků dat a provádí paralelní zpracování celé sady pro účely analýzy a generování sestav. Styl Velký objem výpočtů, označovaný také jako vysokovýkonné výpočetní prostředí (HPC), provádí paralelní výpočty ve velkém počtu (tisících) jader. Mezi prostředí patří simulace, modelování a 3D vykreslování.
Styly architektury jako omezení
Každý styl architektury omezuje návrh, včetně sady elementů, které se můžou objevit, a povolených vztahů mezi těmito elementy. Omezení řídí „tvar“ architektury tím, že omezují celkové možnosti volby. Když se architektura podřídí omezením konkrétního stylu, ukáží se určité žádoucí vlastnosti.
Například mezi omezení mikroslužeb patří:
- Každá služba představuje jednu zodpovědnost.
- Všechny služby jsou vzájemně nezávislé.
- Data jsou privátní pro službu, která je vlastní. Služby nesdílejí data.
Když se podřídíte těmto omezením, vznikne systém, který umožňuje nezávislé nasazování služeb, izolaci chyb, časté aktualizace a snadné zavádění nových technologií do aplikace.
Každý styl architektury má své vlastní kompromisy. Proto před výběrem libovolného stylu architektury se ujistěte, že rozumíte základním principům a omezením daného stylu. Jinak můžete skončit s návrhem, který danému stylu odpovídá pouze na povrchové úrovni, ale nedosahuje jeho plného potenciálu. Potřebujete věnovat pozornost tomu, proč vybíráte určitý styl architektury, než jak ho implementovat. Důležitá je také účelnost. Někdy je lepší uvolnit omezení než trvat na čistotě architektury.
Volba vhodného architektonického stylu by měla být ideálně provedena s konsensus informovaných zúčastněných stran úloh. Tým úloh by měl nejprve identifikovat povahu problému, který se snaží vyřešit. Pak by měli identifikovat obchodní obchodní faktory a odpovídající charakteristiky architektury (označované také jako požadavky na nefunkční) a pak je určit prioritu. Pokud například potřebují kratší dobu uvedení na trh, mohou určit prioritu udržovatelnosti, testovatelnosti a spolehlivosti díky možnostem rychlého nasazení. Nebo pokud má tým úloh omezený rozpočet, může určit prioritu proveditelnosti a jednoduchosti. Volba a údržba stylu architektury není jednorázová aktivita, ale nepřetržitý přístup: architektura by se měla průběžně měřit, ověřovat a doladit v průběhu času. Při přechodu na architekturu obvykle dochází k významným nákladům, takže větší úsilí předem může být odůvodněno dlouhodobou efektivitou týmu a zmírněním rizik.
Následující tabulka shrnuje, jakým způsobem jednotlivé styly spravují závislosti, a typy prostředí, které jsou pro ně nejvhodnější.
| Styl architektury | Správa závislostí | Typ domény |
|---|---|---|
| N-vrstvá | Horizontální vrstvy rozdělené podsítí. | Tradiční obchodní prostředí. Frekvence aktualizací je nízká. |
| Web-queue-worker | Front-endové a back-endové úlohy oddělené asynchronním zasíláním zpráv. | Poměrně jednoduchá prostředí s některými úlohami náročnými na prostředky. |
| Mikroslužby | Vertikálně (funkčně) rozdělené služby, které se navzájem volají prostřednictvím rozhraní API. | Složitá prostředí. Časté aktualizace. |
| Architektura řízená událostmi | Producent a konzument. Nezávislé zobrazení jednotlivých subsystémů. | Systémy IoT a systémy v reálném čase. |
| Velké objemy dat | Rozdělení velmi velkých datových sad do malých bloků dat. Paralelní zpracování místních datových sad. | Analýza dat dávek a v reálném čase. Prediktivní analýza s využitím služby ML. |
| Velké výpočetní prostředky | Přidělení dat tisícům jader. | Prostředí náročná na výpočetní výkon, například simulace. |
Zvážení výzev a výhod
Omezení také vytvářejí výzvy, proto je důležité porozumět kompromisům, které z přijetí některého z těchto stylů vyplývají. Převažují pro toto dílčí prostředí a omezený kontext výhody daného stylu architektury nad výzvami?
Tady je několik typů výzev, které byste při výběru stylu architektury měli zvážit:
Složitost: Je složitost architektury odůvodnitelná pro vaše prostředí? A naopak, není daný styl pro vaše prostředí příliš zjednodušující? V takovém případě riskujete, že skončíte s „velkou hroudou bahna“, protože vám daná architektura nepomáhá spravovat závislosti čistým způsobem.
Asynchronní zasílání zpráv a konečná konzistence: Asynchronní zasílání zpráv je možné využít k oddělení služeb a zvýšení spolehlivosti (protože zasílání zpráv je možné opakovat) a škálovatelnosti. To však vytváří výzvy při zajištění konečné konzistence a také možnost duplicitních zpráv.
Komunikace mezi službami: Při rozdělování aplikace na samostatné služby existuje riziko, že komunikace mezi službami způsobí nepřijatelnou latenci nebo zahlcení sítě (například v architektuře mikroslužeb).
Možnosti správy: Jak obtížná je správa aplikace, monitorování, nasazování aktualizací atd.?
Související prostředky
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro