Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Styl architektury je řada architektur, které sdílejí určité charakteristiky. N-tier je běžným stylem architektury například. V poslední době začaly architektury mikroslužeb získávat laskavost. Styly architektury nevyžadují použití konkrétních technologií, ale některé technologie jsou vhodné pro určité architektury. Kontejnery jsou například přirozeně 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 zahrnuje:
- Popis a logický diagram stylu
- Doporučení pro volbu tohoto stylu
- Výhody, výzvy a osvědčené postupy
- Doporučené nasazení s využitím příslušných služeb 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í. Upozorňujeme, že seznam není vyčerpávající. Další podrobnosti najdete v odkazovaných tématech.
N-vrstvá
N-tier architektura je tradiční architektura pro podnikové aplikace. Závislosti se spravují rozdělením aplikace na vrstvy , které provádějí logické funkce, jako je prezentace, obchodní logika a přístup k datům. Vrstva může volat pouze do vrstev, které jsou pod ní. Toto horizontální vrstvení však může být odpovědností. Může být obtížné zavést změny v jedné části aplikace, aniž by se dotkla zbytku aplikace. Díky tomu jsou časté aktualizace náročné a omezují, jak rychle je možné přidávat nové funkce.
N-vrstvá je přirozeným doplňkem pro migraci stávajících aplikací, které už používají vrstvenou architekturu. Z tohoto důvodu se n-vrstvá řešení nejčastěji používají v řešeních infrastruktury jako služby (IaaS) nebo v aplikacích, které používají kombinaci IaaS a spravovaných služeb.
Web –Queue-Worker
Pro čistě paaS řešení zvažte architekturu web-queue-worker . V tomto stylu má aplikace webový front-end, který zpracovává požadavky HTTP a back-endový pracovní proces, který provádí úlohy náročné na procesor nebo dlouhotrvající operace. Front-end komunikuje s pracovníkem prostřednictvím asynchronní fronty zpráv.
Web-queue-worker je vhodný pro relativně jednoduché domény s některými úlohami náročnými na prostředky. Architektura je stejně jako n-vrstvá, snadno pochopitelná. Použití spravovaných služeb zjednodušuje nasazení a operace. U složitých domén ale může být obtížné spravovat závislosti. Front end a pracovní proces se můžou snadno stát velkými monolitickými komponentami, které se obtížně udržují a aktualizují. Stejně jako u N-vrstvých to může snížit frekvenci aktualizací a omezit inovace.
Mikroslužby
Pokud má vaše aplikace složitější doménu, zvažte přechod na architekturu mikroslužeb . Aplikace mikroslužeb se skládá z mnoha malých nezávislých služeb. Každá služba implementuje jednu obchodní funkci. Služby jsou volně svázané a komunikují prostřednictvím kontraktů rozhraní API.
Každou službu může vytvořit malý vývojový tým zaměřený na danou problematiku. Jednotlivé služby je možné nasadit bez velkého množství koordinace mezi týmy, což podporuje časté aktualizace. Architektura mikroslužeb je složitější na sestavení a správu než N-vrstvá nebo webová fronta-pracovník. Vyžaduje vyspělou vývojovou a devOps kulturu. Tento styl však může vést k vyšší rychlosti vydávání, rychlejším inovacím a odolnější architektuře.
Architektura založená na událostech
Event-Driven Architektury používají model publikování a odběru (pub-sub), kde producenti publikují události a uživatelé se k nim přihlašují. Producenti jsou nezávislí na spotřebiteli a spotřebitelé jsou navzájem nezávislí.
Zvažte architekturu řízenou událostmi pro aplikace, které ingestují a zpracovávají velký objem dat s velmi nízkou latencí, jako jsou řešení IoT. Tento styl je také užitečný, když různé subsystémy musí provádět různé typy zpracování na stejných datech událostí.
Velké objemy dat, velké výpočetní prostředky
Big Data a Big Compute jsou specializované styly architektury pro úlohy, které odpovídají určitým konkrétním profilům. Velké objemy dat rozdělují velmi velkou datovou sadu na bloky dat a provádějí paralelní zpracování celkové sady pro analýzu a vytváření sestav. Velký výpočetní výkon, označovaný také jako vysokovýkonné výpočetní prostředí (HPC), umožňuje paralelní výpočty napříč velkým počtem (tisíci) jader. Mezi domény patří simulace, modelování a prostorové vykreslování.
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.
Dodržováním těchto omezení se vynořuje systém, ve kterém se služby dají nasadit nezávisle, chyby jsou izolované, časté aktualizace jsou možné a je snadné zavést do aplikace nové technologie.
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. V opačném případě můžete skončit s návrhem, který odpovídá stylu na povrchní úrovni, ale nedosáhne plného potenciálu tohoto stylu. Potřebujete věnovat pozornost tomu, proč vybíráte určitý styl architektury, než jak ho implementovat. Je také důležité být pragmatičtější. Někdy je lepší uvolnit omezení, spíše než trvat na čistotě architektury.
Volba vhodného architektonického stylu by měla být ideálně provedena s konsensem informovaných zúčastněných stran pracovní zátěže. Tým úloh by měl nejprve identifikovat povahu problému, který se snaží vyřešit. Pak by měli identifikovat obchodní faktory a odpovídající charakteristiky architektury (označované také jako nefunkční požadavky), a poté stanovit jejich priority. 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 změně architektonického stylu obvykle vznikají značné náklady, takže větší úsilí vynaložené 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 jednotlivé styly spravují závislosti a typy domén, které jsou pro každý z nich 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á. |
| Pracovník webové fronty | 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/spotřebitel. Nezávislé zobrazení pro každý dílčí systém. | Systémy 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í ML. |
| 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ů. Výhody stylu architektury převáží výzvy pro tuto subdoménu a ohraničený kontext.
Tady je několik typů problémů, které je potřeba vzít v úvahu při výběru stylu architektury:
Složitost: Je složitost architektury pro vaši doménu odůvodněná? A naopak, je styl příliš zjednodušený pro vaši doménu? V takovém případě riskujete, že skončíte s "neuspořádaným systémem", protože architektura vám nepomůže spravovat závislosti čistě.
Asynchronní zasílání zpráv a konečná konzistence Asynchronní zasílání zpráv se dá použít k oddělení služeb a ke zvýšení spolehlivosti (protože je možné opakovat zprávy) a škálovatelnosti. To ale také vyvolává problémy při zpracování konečné konzistence a také možnosti duplicitních zpráv.
Komunikace mezi službami. Při dekompilování aplikace do samostatných služeb existuje riziko, že komunikace mezi službami způsobí nepřijatelnou latenci nebo vytvoří zahlcení sítě (například v architektuře mikroslužeb).
Spravovatelnost. Jak těžké je spravovat aplikaci, monitorovat, nasazovat aktualizace atd.?