Styl n-úrovňové architektury

N-vrstvá architektura rozdělí aplikaci na logické vrstvy a fyzické vrstvy.

Vrstvy představují způsob, jak oddělit zodpovědnosti a spravovat závislosti. Každá vrstva má určitou zodpovědnost. Vyšší vrstva může používat služby v nižší vrstvě, ale ne naopak.

Vrstvy jsou fyzicky oddělené a běží na samostatných počítačích. Smluvně může mít úroveň své komunikační modely přísné nebo uvolněné. V přísném modelu musí požadavek procházet sousedními vrstvami, jednu po druhé a nesmí přeskočit žádnou vrstvu mezi. Například z firewallu webových aplikací na webovou vrstvu, pak na střední vrstvu 1 atd. Naproti tomu v uvolněném přístupu může požadavek v případě potřeby přeskočit některé úrovně. Striktní přístup má větší latenci a režii a uvolněný přístup má více párů a následně je obtížnější se změnit. Systém může používat hybridní přístup: v případě potřeby má uvolněné i striktní úrovně.

Vrstva může volat přímo jinou vrstvu nebo používat vzory asynchronního zasílání zpráv prostřednictvím fronty zpráv. I když každá vrstva může být hostovaná ve vlastní vrstvě, není to nutné. Na stejné úrovni může být hostováno několik vrstev. Fyzické oddělení vrstev zlepšuje škálovatelnost a odolnost, ale také zvyšuje latenci od další síťové komunikace.

Tradiční třívrstvé aplikace má prezentační vrstvu, střední a databázovou vrstvu. Střední úroveň je volitelná. Složitější aplikace můžou mít více než tři úrovně. Výše uvedený diagram znázorňuje aplikaci se dvěma středními vrstvami, která zapouzdřuje různé oblasti funkčnosti.

N-vrstvá aplikace může mít uzavřenou architekturu vrstvy nebo architekturu otevřené vrstvy:

• V uzavřené architektuře vrstev může vrstva volat pouze další vrstvu okamžitě dolů.
• V otevřené architektuře vrstev může vrstva volat libovolnou vrstvu pod ní.

Uzavřená architektura vrstev omezuje závislosti mezi vrstvami. Pokud ale jedna vrstva jednoduše předává požadavky na další vrstvu, může to vytvořit nepotřebný síťový provoz.

Kdy použít tuto architekturu

N-úrovňové architektury se obvykle implementují jako aplikace IaaS (infrastruktura jako služba), přičemž každá vrstva běží na samostatné sadě virtuálních počítačů. N-vrstvá aplikace ale nemusí být čistá IaaS. Často je výhodné používat spravované služby pro některé části architektury, zejména ukládání do mezipaměti, zasílání zpráv a úložiště dat.

Zvažte n-úrovňovou architekturu pro:

• Jednoduché webové aplikace.
• Dobrým výchozím bodem, kdy ještě nejsou jasné požadavky na architekturu.
• Migrace místní aplikace do Azure s minimálním refaktoringem
• Jednotný vývoj místních a cloudových aplikací

N-úrovňové architektury jsou v tradičních místních aplikacích velmi běžné, takže se přirozeně hodí pro migraci stávajících úloh do Azure.

Výhody

• Přenositelnost mezi cloudem a místním prostředím a mezi cloudovými platformami.
• Menší křivka učení pro většinu vývojářů
• Relativně nízké náklady tím, že řešení nepřechovává.
• Přirozený vývoj z tradičního aplikačního modelu.
• Otevřené heterogenní prostředí (Windows/Linux)

Výzvy

• Je snadné skončit střední vrstvou, která provádí operace CRUD v databázi a přidává další latenci, aniž byste museli dělat užitečnou práci.
• Monolitický návrh zabraňuje nezávislému nasazení funkcí.
• Správa aplikace IaaS je více práce než aplikace, která používá pouze spravované služby.
• V rozsáhlém systému může být obtížné spravovat zabezpečení sítě.
• Toky uživatelů a dat se obvykle rozprostřují napříč několika úrovněmi a přidávají složitost obavám, jako je testování a pozorovatelnost.

Osvědčené postupy

• Pomocí automatického škálování můžete zpracovávat změny zatížení. Pro osvědčené postupy automatického škálování.
• K oddělení vrstev použijte asynchronní zasílání zpráv.
• Ukládání polostatických dat do mezipaměti Přečtěte si osvědčené postupyukládání do mezipaměti.
• Nakonfigurujte databázovou vrstvu pro vysokou dostupnost pomocí řešení, jako je skupiny dostupnosti AlwaysOn SQL Serveru.
• Umístěte firewall webových aplikací (WAF) mezi front-endem a internetem.
• Každou vrstvu umístěte do vlastní podsítě a používejte podsítě jako hranici zabezpečení.
• Omezte přístup k datové vrstvě tím, že povolíte požadavky pouze ze střední vrstvy.

N-úrovňová architektura na virtuálních počítačích

Tato část popisuje doporučenou N-vrstvou architekturu běžící na virtuálních počítačích.

Každá úroveň se skládá ze dvou nebo více virtuálních počítačů umístěných ve skupině dostupnosti nebo škálovací sadě virtuálních počítačů. V případě selhání jednoho virtuálního počítače zajišťuje více virtuálních počítačů odolnost. Nástroje pro vyrovnávání zatížení se používají k distribuci požadavků mezi virtuální počítače ve vrstvě. Vrstvu je možné horizontálně škálovat přidáním dalších virtuálních počítačů do fondu.

Každá úroveň se také umístí do vlastní podsítě, což znamená, že jejich interní IP adresy spadají do stejného rozsahu adres. To usnadňuje použití pravidel skupiny zabezpečení sítě a směrovacích tabulek na jednotlivé úrovně.

Webové a obchodní vrstvy jsou bezstavové. Jakýkoli virtuální počítač může zpracovat jakýkoli požadavek na danou úroveň. Datová vrstva by se měla skládat z replikované databáze. Pro Windows doporučujeme SQL Server používat skupiny dostupnosti AlwaysOn pro zajištění vysoké dostupnosti. Pro Linux zvolte databázi, která podporuje replikaci, například Apache Cassandra.

Skupiny zabezpečení sítě omezují přístup k jednotlivým úrovním. Například databázová vrstva umožňuje přístup pouze z obchodní vrstvy.

Další důležité informace

• N-úrovňové architektury nejsou omezeny na tři úrovně. U složitějších aplikací je běžné mít více vrstev. V takovém případě zvažte použití směrování vrstvy 7 ke směrování požadavků na konkrétní úroveň.

• Úrovně jsou hranicí škálovatelnosti, spolehlivosti a zabezpečení. Zvažte samostatné úrovně pro služby s různými požadavky v těchto oblastech.

• Použijte škálovací sady virtuálních počítačů pro automatické škálování.

• Hledejte místa v architektuře, kde můžete používat spravovanou službu bez významného refaktoringu. Konkrétně se podívejte na ukládání do mezipaměti, zasílání zpráv, úložiště a databází.

• Pokud chcete vyšší zabezpečení, umístěte před aplikaci síť DMZ. DMZ zahrnuje síťová virtuální zařízení (NVA), která implementují funkce zabezpečení, jako jsou brány firewall a kontrola paketů. Další informace najdete v tématu referenční architektura DMZ sítě.

• V případě vysoké dostupnosti umístěte dvě nebo více síťových virtuálních zařízení do skupiny dostupnosti s externím nástrojem pro vyrovnávání zatížení, který distribuuje internetové požadavky napříč instancemi. Další informace najdete v tématu Nasazení vysoce dostupných síťových virtuálních zařízení.

• Nepovolujte přímý přístup RDP nebo SSH k virtuálním počítačům, na kterých běží kód aplikace. Místo toho by se operátory měly přihlásit do jumpboxu, označovaného také jako hostitel bastionu. Jedná se o virtuální počítač v síti, který správci používají pro připojení k ostatním virtuálním počítačům. Jumpbox má skupinu zabezpečení sítě, která umožňuje protokol RDP nebo SSH jenom ze schválených veřejných IP adres.

• Virtuální síť Azure můžete rozšířit do místní sítě pomocí virtuální privátní sítě (VPN) typu site-to-site nebo Azure ExpressRoute. Další informace najdete v tématu Referenční architektura hybridní sítě.

• Pokud vaše organizace ke správě identity používá Active Directory, možná budete chtít rozšířit prostředí Active Directory na virtuální síť Azure. Další informace najdete v tématu Referenční architektura správy identit.

• Pokud potřebujete vyšší dostupnost než smlouva Azure SLA pro virtuální počítače, replikujte aplikaci do dvou oblastí a pro převzetí služeb při selhání použijte Azure Traffic Manager. Další informace najdete v tématu Spouštění virtuálních počítačů s Linuxem v několika oblastech.

Související zdroje informací

• n-vrstvé aplikace s využitím Apache Cassandra
• [N-vrstvá aplikace windows v Azure s SQL Serverem][n-tier-windows-SQL]
• modul Microsoft Learn: Prohlídka n-úrovňového stylu architektury
• azure Bastion
• Další informace o zasílání zpráv ve stylu n-úrovňové architektury v Azure