Styl n-úrovňové architektury

N-úrovňová architektura dělí aplikaci na logické vrstvy a fyzické úrovně.

Vrstvy představují způsob oddělení odpovědností a správy závislostí. Každá vrstva má konkrétní zodpovědnost. Vyšší vrstva může používat služby v nižší vrstvě, ale ne naopak.

Úrovně jsou fyzicky oddělené, běží na samostatných počítačích. Úroveň může volat jinou úroveň přímo, nebo použít asynchronní zasílání zpráv (frontu zpráv). I když každá vrstva může být hostovaná ve své vlastní úrovni, není to nutné. Několik vrstev může být hostovaných ve stejné úrovni. Fyzické oddělení úrovní zlepšuje škálovatelnost a odolnost proti chybám, ale také zvyšuje latenci díky další síťové komunikaci.

Tradiční tříúrovňová aplikace obsahuje prezentační úroveň, střední úroveň a databázovou úroveň. Střední úroveň je volitelná. Složitější aplikace můžou mít více než tři úrovně. Uvedený diagramu zobrazuje aplikaci se dvěma středními úrovněmi, které zapouzdřují různé funkční oblasti.

N-úrovňová aplikace může mít uzavřenou architekturu vrstev nebo otevřenou architekturu vrstev:

• V uzavřené architektuře vrstev může vrstva volat jenom další vrstvu bezprostředně pod ní.
• V otevřené architektuře vrstev může vrstva volat všechny vrstvy pod ní.

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

Kdy použít tuto architekturu

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

Zvažte n-úrovňovou architekturu v těchto případech:

• Jednoduché webové aplikace.
• Migrace místní aplikace do Azure s minimálním refaktoringem.
• Unifikovaný vývoj místních i cloudových aplikací.

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

Výhody

• Přenositelnost mezi cloudem a místním prostředím nebo mezi cloudovými platformami.
• Méně strmá křivka osvojování znalostí pro většinu vývojářů.
• Přirozený přechod z tradičního aplikačního modelu.
• Otevřenost pro heterogenní prostředí (Windows nebo Linux).

Výzvy

• Je snadné skončit se střední úrovní, která provádí jenom operace CRUD v databázi a zvyšuje latenci bez provádění jakékoli užitečné práce.
• Monolitický návrh zabraňuje nezávislému nasazení funkcí.
• Správa aplikace IaaS představuje víc práce než u aplikace, která používá jenom spravované služby.
• Může být obtížné spravovat zabezpečení sítě v rozsáhlém systému.

Osvědčené postupy

• Použijte automatické škálování pro případ změn v zatížení. Přečtěte si osvědčené postupy automatického škálování.
• Oddělte úrovně pomocí asynchronního zasílání zpráv .
• Semistatic data mezipaměti. Přečtěte si osvědčené postupy pro ukládání do mezipaměti.
• nakonfigurujte databázovou vrstvu pro vysokou dostupnost pomocí řešení, jako je například SQL Server skupiny dostupnosti Always On.
• Umístíte firewall webových aplikací (WAF) mezi front-end a internet.
• Umístěte každou úroveň do vlastní podsítě a používejte podsítě jako hranici zabezpečení.
• Omezte přístup k datové úrovni tím, že povolíte požadavky jenom ze střední úrovně (nebo úrovní).

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

Tato část popisuje doporučenou n-úrovňovou 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čů, které jsou umístěné ve skupině dostupnosti nebo v sadě škálování virtuálního počítače. Víc virtuálních počítačů poskytuje odolnost v případě, že jeden virtuální počítač selže. Nástroje pro vyrovnávání zatížení se používají k distribuci požadavků mezi virtuální počítače v úrovni. Úroveň můžete škálovat horizontálně tak, že přidáte další virtuální počítače do fondu.

Každá úroveň je také umístěná uvnitř vlastní podsítě, což znamená, že jejich vnitřních IP adresy patří do stejného rozsahu adres. Díky tomu je snadné použít pravidla skupiny zabezpečení sítě a směrovací tabulky na jednotlivé úrovně.

Webová a obchodní úroveň je bezstavová. Všechny žádosti pro tuto úroveň můžou zpracovávat všechny virtuální počítače. Datová úroveň by měla sestávat z replikované databáze. pro Windows doporučujeme SQL Server pomocí skupin dostupnosti Always On pro vysokou dostupnost. Pro Linux vyberte databázi, která podporuje replikaci, jako je například Apache Cassandra.

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

Další informace o spouštění N-vrstvých aplikací v Azure:

• Spuštění virtuálních počítačů s Windows pro n-vrstvou aplikaci
• Windows N-vrstvá aplikace v Azure s SQL Server
• Microsoft Learn modul: prohlídka stylu architektury N-vrstvých
• Azure Bastion

Další aspekty

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

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

• K automatickému škálování použijte Virtual Machine Scale Sets.

• Vyhledejte v architektuře místa, kde můžete použít 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áze.

• Kvůli vyššímu zabezpečení umístěte před aplikace DMZ sítě. DMZ zahrnuje síťová virtuální zařízení (NVA), která implementují funkce zabezpečení, jako jsou brány firewall a kontrolu paketů. Další informace najdete v popisu referenční architektury DMZ sítě.

• Pro zajištění vysoké dostupnosti umístěte dvě nebo více zařízení NVA do skupiny dostupnosti s externím nástrojem pro vyrovnávání zatížení, aby se internetové požadavky distribuovaly mezi instancemi. Další informace najdete v tématu Nasazení vysoce dostupných síťových virtuálních zařízení.

• Nepovolujte přímý přístup pomocí protokolu RDP nebo SSH k virtuálním počítačům, na kterých běží kód aplikace. Místo toho by se operátoři měli přihlašovat k jumpboxu, označovanému také jako hostitel typu bašta. Toto je 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 RDP nebo SSH jenom ze schválených veřejných IP adres.

• Virtuální síť Azure můžete rozšířit k místní síti pomocí virtuální privátní sítě (VPN) typu Site-to-Site nebo Azure ExpressRoute. Další informace najdete v popisu referenční architektury hybridní sítě.

• Pokud vaše organizace používá Active Directory ke správě identit, můžete chtít rozšířit prostředí Active Directory do virtuální sítě Azure. Další informace najdete v popisu referenční architektury správy identit.

• Pokud potřebujete vyšší dostupnost, než poskytuje 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ématech o spuštění virtuálních počítačů s Windows v několika oblastech nebo spuštění linuxových virtuálních počítačů v několika oblastech.