Upravit

Sdílet prostřednictvím

Styl n-úrovňové architektury

Azure Storage
Azure Cloud Services
Azure Virtual Machines

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

Logický diagram n-úrovňové architektury

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. 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 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.
  • 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.
  • 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.

Zaměstnanecké 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ářů.
  • Relativně nízké náklady tím, že řešení nepřechovává.
  • 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.
  • 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

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.

Fyzický diagram n-úrovňové architektury

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í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. To usnadňuje použití pravidel skupiny zabezpečení sítě a směrovacích tabulek 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 používat skupiny dostupnosti AlwaysOn pro zajištění vysoké dostupnosti. 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 úrovním. Například databázová úroveň umožňuje přístup jenom z obchodní úrovně.

Poznámka:

Vrstva označená jako "Obchodní úroveň" v našem referenčním diagramu je moniker na úroveň obchodní logiky. Podobně také nazýváme prezentační vrstvu webovou vrstvou. V našem příkladu se jedná o webovou aplikaci, i když vícevrstvé architektury se dají použít i pro jiné topologie (například desktopové aplikace). Pojmenujte vrstvy, které nejlépe vyhovuje vašemu týmu, aby komunikoval se záměrem této logické nebo fyzické vrstvy ve vaší aplikaci – můžete dokonce vyjádřit, že toto pojmenování v prostředcích, které zvolíte pro reprezentaci této úrovně (např. vmss-appName-business-layer).

Další důležité informace

  • 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ě.

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

  • 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. Je to virtuální počítač v síti, který správci používají pro připojení k jiný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 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.