Co je n-úrovňová architektura?

Dokončeno

N-úrovňová architektura dělí aplikaci na logické vrstvy a fyzické úrovně. Písmeno n označuje počet fyzických úrovní, na něž je aplikace rozdělená, což obvykle odpovídá počtu vrstev. Teoreticky můžeme mít dvouúrovňovou architekturu (klient-server), nebo dokonce pětiúrovňovou architekturu. Je ale běžné (a často i nejlepší) nepoužívat více než čtyři úrovně.

Pojďme si vysvětlit, co vrstvy a úrovně tvoří.

Co jsou vrstvy?

Vrstvy logicky rozdělují kód, který tvoří aplikaci. Každá vrstva je zodpovědná za konkrétní úkoly, například zpracovávání požadavků uživatelů, provoz obchodní logiky nebo ukládání dat.

Když aplikaci rozdělíme na tyto logické vrstvy, pracujeme s každou z nich samostatně. Díky tomuto oddělení jsou komponenty aplikace modulární a umožňuje nám snadněji udržovat aplikaci. Aplikaci můžeme pro každou z odpovědností optimalizovat. Vrstva zpracovávající webové požadavky se soustředí na svou hlavní úlohu – zpracování těchto požadavků. Nezabývá se ukládáním dat ani provozem obchodní logiky. Vrstva přístupu k datům se naopak zaměřuje na optimalizaci komunikace s úložištěm dat a ignoruje podrobnosti o tom, jak uživateli prezentuje data. Tento princip zaměření pozornosti na konkrétní funkce se nazývá oddělení oblastí zájmu.

Na diagramu níže jsou zobrazené vrstvy v běžné n-úrovňové aplikaci. Každá vrstva zajišťuje jeden aspekt aplikace. Obchodní vrstva spravuje komunikaci mezi vrstvou uživatelského rozhraní a vrstvou přístupu k datům.

Visualization of layers.

Co jsou úrovně?

Úrovně představují fyzické rozčlenění částí aplikace do samostatných výpočetních prostředků. Obecně platí, že na každé fyzické úrovni je spuštěná jedna logická vrstva aplikace.

Rozdělení architektury na fyzické úrovně přináší několik výhod:

  • Součásti aplikace můžete škálovat odděleně, a to přidáním prostředků do každé z úrovní.
  • Aplikace může být odolnější přidáním vyrovnávání zatížení ke zjištění neúspěšných prostředků a přesměrováním požadavků na systémy, které jsou v pořádku.
  • Aplikace může být bezpečnější omezením síťové komunikace mezi vrstvami a povolením pouze požadovaného přístupu.

Architektura určuje, že komunikace mezi vrstvami by měla být shora dolů. Každá úroveň může komunikovat s další úrovní pod ní, ale obecně není povoleno přeskočit úrovně. Tento návrh zlepšuje zabezpečení omezením vystavené plochy vrstvy.

Visualization of tiers.

Tříúrovňová architektura

Tříúrovňová architektura je ze všech n-úrovňových architektur nejběžnější. Odpovědnost a název každé z vrstev a úrovní se může lišit v závislosti na aplikaci a podniku. Tříúrovňová aplikace ale obvykle má prezentační úroveň, aplikační neboli střední úroveň a datovou úroveň. Tato architektura je nejběžnější n-úrovňový styl. Ve zbytku tohoto modulu budeme odkazovat na třívrstvý model s každou vrstvou, na které běží jedna vrstva aplikace, a budeme na ně odkazovat jako na vrstvy.

Prezentační úroveň

Prezentační úroveň obvykle zpracovává požadavky uživatelů. Tyto požadavky můžou být uživatelé, kteří přistupují na webovou stránku, nebo veřejný přístup k vaší aplikaci prostřednictvím vystaveného rozhraní API. Fokus na této úrovni je v uživatelském prostředí. Poskytuje například intuitivní rozhraní a zajišťuje zabezpečenou komunikaci mezi koncovým uživatelem a vaší aplikací.

Na této úrovni se nezajímáte o samotná data, kromě způsobu jejich prezentování uživateli. Obvykle na této úrovni nedochází ke zpracování dat ani přístupu k datům. To je zodpovědností nižších úrovní.

Aplikační úroveň

Aplikační úroveň (často označovaná jako střední úroveň) se typicky zaměřuje na zajišťování obchodní logiky aplikace. Může se jednat o zpracovávání objednávek od zákazníků, sledování zásilek nebo aktualizace skladových zásob na základě přijatých materiálů. Tato úroveň je odpovědná za aktivity vytváření, čtení, aktualizací a odstraňování („operace CRUD“) proti datové úrovni. Představuje také vhodné místo pro volání do závislých služeb, jako jsou externí rozhraní API.

Tato úroveň se nezajímá o to, jak se informace zobrazují uživateli, ani se nezabývá tím, jak se data ukládají a načítají. Soustředí se jen na obchodní logiku potřebnou k plnění požadavků přijatých aplikací.

Datová vrstva

Na této úrovni se zaměřujeme na úložiště dat. Její zodpovědností je ukládat data v tabulkách, souborech nebo jiném médiu. Pro přístup k datům poskytuje rozhraní, jako je například T-SQL. V rámci tříúrovňové architektury zajišťuje přístup dat k aplikační úrovni.

Tato úroveň se nezaměřuje na způsob, jakým se data zobrazují uživateli, ani se nezaměřují na žádnou logiku týkající se dat. Použití uložených procedur může být v této vrstvě, ale většina logiky kolem dat by se měla zpracovávat na vyšší úrovni.

Kdy používat n-úrovňovou architekturu

Teď, když jsme mluvili o N-vrstvé architektuře, popíšeme si, kdy byste použili architekturu tohoto stylu. Zvažte n-úrovňovou architekturu v těchto případech:

  • Malé až střední webové aplikace
  • Migrace místní aplikace do Azure s minimálním refaktoringem.
  • Používání dovedností, schopností a zkušeností místních vývojářů

K architekturám tohoto stylu se dobře hodí webové aplikace. N-úrovňové architektury s nimi mohou dobře fungovat díky své menší složitosti a často přirozenému rozdělení odpovědností, které se u webových aplikacích používá. Tyto aplikace můžou být veřejně přístupné nebo obchodní aplikace používané interně organizací. U menších nebo jednodušších aplikací může stačit dvouúrovňová architektura (klient-server), v níž nejsou prezentační a aplikační úrovně oddělené, ale naopak sloučené.

N-úrovňové architektury jsou běžné u tradičních místních aplikací, takže jsou přirozeně vhodné pro migraci stávajících úloh do Azure. Aplikace tohoto stylu se často migrují do Azure s minimálním refaktoringem nebo úpravami, což zjednodušuje počáteční migraci. Jakmile budete v Azure, můžete využít výhod služeb PaaS (Platforma jako služba), abyste aplikaci dále vylepšili.

Vzhledem k tomu, že se jedná o běžný styl architektury, mají technici často vyšší úroveň zkušeností a znají ho. Pokud se pro ni rozhodnete, můžete při nasazování aplikace využít stávajících dovedností, aniž byste museli přecházet na nová schémata.

Prověřte si své znalosti

1.

Potřebujete aktualizovat třívrstvou aplikaci pro integraci s partnerským rozhraním API. Do které vrstvy byste tuto funkci měli přidat?

2.

Ve které vrstvě je přijatelné povolit přístup uživatelů?